# When Agents Meet Physical Data: The Other Physics of Agent Harnesses

Dmitry Petrov · DataChain · AI Engineer World's Fair 2026: Online Track

> Vì sao coding agent hỏng với video và sensor data, và cách dựng data harness bốn phần: see, run, verify, remember, với demo DataChain và Claude Code.

Topics: Agents, Coding Agents, Context Engineering, Databases

Canonical: https://homus.dev/talks/when-agents-meet-physical-data-the-other-physics-of-agent-harnesses

## 1. Coding agent giỏi code, nhưng không giỏi data

Dmitry mở đầu bằng một câu hỏi: coding agent làm việc với physical data thì sẽ ra sao? Physical data ở đây là video recording, sensor data, robot telemetry, và nhiều khi là tất cả những thứ đó gộp chung trong một project multimodal. Nếu bạn đã từng thử, nhiều khả năng bạn đã thấy nó hỏng tệ đến mức nào. Talk này bàn về lý do, về những "định luật vật lý" nằm sau các vấn đề đó, và về cách sửa.

Năm nay, hai frontier lab đã công bố những kết quả rất thú vị và khá bất ngờ: nhìn chung agent không giỏi làm việc với data. Anthropic công bố rằng độ chính xác của agent của họ trên các data project chỉ là 21%, cho tới khi bạn gắn thêm data harness chuyên biệt và cung cấp context cho chúng. OpenAI thì công bố cả một hệ nhiều lớp context, sáu lớp context, chỉ để làm cho data agent của họ chạy được.

![Slide: Coding agents are great at code. Not data. 21% lên 95%](https://homus.dev/photos/bUJgirn4_yc-0040.jpg)

"Coding agent giỏi code, không giỏi data." Với cùng một model Claude, độ chính xác khi trả lời câu hỏi về data đi từ 21% với vanilla harness lên 95% với data harness. Phía dưới slide dẫn hai nguồn: data agent nội bộ của OpenAI (tháng 1/2026) và bài về data analytics của Anthropic.

Điều đáng chú ý là tất cả những kết quả đó đều làm trên structured data: dữ liệu nằm trong warehouse, có bảng, có execution engine, có đủ mọi thứ "xa xỉ" như vậy. Dmitry nói rằng trong đời mình, anh không có sự xa xỉ đó, vì anh sống ở một đầu rất cực đoan của vũ trụ dữ liệu: dữ liệu lộn xộn, không có cấu trúc (unstructured data).

![Slide Physical AI: cross into a black hole, the laws change](https://homus.dev/photos/bUJgirn4_yc-0112.jpg)

"Physical AI: đi vào một hố đen, các định luật thay đổi." Bên trái là phiên bản dễ dãi (structured warehouse, có schema, index và query engine); bên dưới là thế giới của Dmitry: hàng petabyte file trong S3 hoặc GCS, gồm video, sensor data và robot telemetry.

Anh đã làm việc với data khoảng mười năm. Anh là người tạo ra project [Data Version Control (DVC)](https://dvc.org), một kiểu "Git cho data", và hiện đang làm [DataChain](https://github.com/datachain-ai/datachain).

## 2. Brain đã có, phần còn lại của cơ thể phải dựng lại

Để agent làm được việc với unstructured data, với physical data, ta cần xây không chỉ bộ não. Bộ não thì ta đã có rồi: đó là LLM. Thứ còn thiếu là harness, cụ thể là một data harness, để agent hiểu được thế giới vật lý này.

Dmitry chia data harness thành bốn bộ phận, như bốn phần của một cơ thể:

- **Mắt (SEE):** agent phải nhìn thấy data một cách đúng đắn.

- **Chân (RUN):** agent phải chạy được việc tính toán, nói nôm na là "cho nó một đôi chân".

- **Tay (VERIFY):** agent phải chạm được vào data, kiểm tra kết quả, chạy test.

- **Trí nhớ (REMEMBER):** agent phải nhớ những dataset quan trọng, những kết quả quan trọng, để thông tin đó có thể dùng lại trong các project sau.

![Slide The body, rebuilt: See, Run, Verify, Remember](https://homus.dev/photos/bUJgirn4_yc-0144.jpg)

"The body, rebuilt": model là bộ não, còn trong thế giới này mọi bộ phận khác của cơ thể đều phải dựng lại. SEE gắn với Dataset (nhìn được data mà bạn không thể ôm hết), RUN gắn với Engine (chạy thứ không vừa trong máy), VERIFY gắn với "the built slice" (kiểm thứ bạn không thể nhìn bằng mắt), REMEMBER gắn với Knowledge base.

Phần đầu tiên là cách agent "nhìn" data.

## 3. SEE: 2.000 file là một ngôi sao neutron

Muốn hiểu được tất cả những file binary phức tạp đang nằm trong object storage của bạn thì cần những gì? Trên thực tế, bề ngoài nó thường trông rất đơn giản: chỉ có vài file, đôi khi vài nghìn file. Nghe thì có vẻ chẳng có gì to tát.

Nhưng điều thường xảy ra là bên trong những file đó rất phức tạp. Chính điều này làm cho unstructured multimodal data trở nên khó. Một video recording có thể chứa các clip. Clip chứa các frame. Frame chứa các object. Mỗi object lại có confidence, type, class, label. Và giữa các mảnh đó có những liên kết với nhau. Tất cả tạo ra một kiểu "vụ nổ" về số lượng.

Dmitry so sánh nó với một ngôi sao neutron: kích thước bề mặt rất nhỏ, chỉ cỡ một thành phố, nhưng khối lượng thì khủng khiếp, lớn hơn cả khối lượng Mặt Trời. Tương tự, hai nghìn file video có thể dễ dàng sinh ra hàng triệu object bên trong.

![Slide 2,000 files is a neutron star](https://homus.dev/photos/bUJgirn4_yc-0248.jpg)

"2.000 file là một ngôi sao neutron": bán kính là số file (2.000, cỡ một thành phố), khối lượng là số object (100 triệu, nặng hơn Mặt Trời). Slide kết luận: 100 triệu object không bao giờ vừa một context window, nên agent bị "mù".

## 4. Hai lối thoát quen thuộc, và vì sao cả hai đều hỏng

Người ta thường xử lý vấn đề này thế nào? Thường họ đi qua hai bước lớn.

Bước thứ nhất: "Thôi thì cứ ghi meta information ra file JSON và đặt lên S3 cạnh các ảnh." Kết quả là bạn có hàng triệu file JSON, latency kinh khủng, không hiệu quả, không nhất quán.

Ý tưởng tiếp theo: "Sao không dùng database?" Rất hay. Và những team tiên tiến nhất làm đúng như vậy: dựng một database tập trung chứa toàn bộ metadata. Tốt thôi, nhưng theo cách này bạn kết thúc với hai hệ thống, hai ngôn ngữ lập trình, và đủ thứ lộn xộn xoay quanh hai stack khác nhau. Mà stack này lại vô dụng với phần lớn researcher, vì họ không muốn dính vào độ phức tạp đó.

![Slide JSON sprawl, then two languages](https://homus.dev/photos/bUJgirn4_yc-0352.jpg)

"JSON tràn lan, rồi đến hai ngôn ngữ." Option A, một đống JSON: hàng triệu file nhỏ, chậm, không có versioning, và vẫn chưa phải một dataset. Option B, một database: Python cộng với những "hòn đảo" SQL, hai ngôn ngữ phải bảo trì, còn tệ hơn cho agent. Hai lối thoát khỏi đống file lộn xộn, cả hai đều hỏng.

Đội của Dmitry nhận ra rằng cách dễ nhất để researcher và developer làm việc với schema là [Pydantic](https://docs.pydantic.dev). Như vậy bạn dùng cùng một ngôn ngữ cho data, cho schema, và cho code. Không còn "hòn đảo SQL" nào trong code base của bạn. Theo cách đó, bạn chuyển từ thế giới lộn xộn của unstructured data sang thế giới có cấu trúc. Thứ duy nhất cần thêm là một transpiler từ Python sang SQL, và anh sẽ cho xem nó hoạt động thế nào. Đó là cách để bạn tạo schema và làm việc với schema một cách hiệu quả.

![Slide Now the agent can see: objects.filter chạy trong 12 ms](https://homus.dev/photos/bUJgirn4_yc-0512.jpg)

"Bây giờ agent đã nhìn thấy." Một lệnh `objects.filter(label=="pedestrian", velocity > 0)` quét 100 triệu object, xong trong 12 ms và không nạp byte nào vào RAM; bên phải là bảng kết quả gồm thời điểm, class pedestrian và tốc độ (1,4 m/s, 0,9 m/s, 1,8 m/s).

Dmitry nhấn mạnh rằng vấn đề đang giải ở đây rất đặc thù cho unstructured data, cho physical data. Nó không tồn tại trong thế giới structured data. Chẳng hạn các blog post của OpenAI và Anthropic làm việc với business logic có cấu trúc; còn đội của anh làm việc với physical data, với file binary và những thứ tương tự.

## 5. Demo: cài DataChain, cài skill, mở Claude Code

Đến phần demo. Dmitry dùng project open source DataChain, đi kèm một data harness dành cho coding agent.

Đầu tiên bạn cần cài công cụ bằng `pip install`; bước này đã làm sẵn. Sau đó cần cài skill: bạn chọn coding tool mình đang dùng. Trong demo anh dùng [Claude Code](https://docs.anthropic.com/en/docs/claude-code), nhưng DataChain còn hỗ trợ thêm ba coding agent khác. Rồi bạn chạy coding agent yêu thích của mình. Tất nhiên, anh bỏ qua bước xin quyền (skip permissions) cho nhanh.

![Terminal: datachain skill install và claude --dangerously-skip-permissions](https://homus.dev/photos/bUJgirn4_yc-0640.jpg)

Lệnh `datachain skill install --local --target claude` cài ba skill (core, knowledge, jobs) vào thư mục `.claude/skills` của project, sau đó mở Claude Code với `--dangerously-skip-permissions` và gõ yêu cầu xây fleet detections từ các clip dashcam trên S3.

```
datachain skill install --local --target claude
claude --dangerously-skip-permissions
```

Rồi bạn viết prompt và giải bài toán của mình. Trong trường hợp này, bài toán là phân tích chuyển động trong video camera, dùng một open dataset gồm các đoạn ghi hình từ dashcam. Video là một use case rất phổ biến trong các project physical AI: phần lớn project đều có video recording là một trong các modality, nhiều khi là modality chính. Theo Dmitry, đây cũng là một trong những bài toán thú vị và khó nhất trong thế giới physical AI, nên anh lấy modality này làm ví dụ.

Prompt trên màn hình yêu cầu đúng việc đó:

```
Build fleet detections from the dashcam clips in s3://dc-readme/fleet-cameras/2026-01/front/
Detected objects with velocity. Save is as dashcam-jan dataset.
```

## 6. Data harness hỏi lại trước khi chạy

Data harness đặt vài câu hỏi cho người dùng để hiểu phạm vi rõ hơn. Câu đầu tiên là chọn model. Agent quyết định dùng một model YOLO, và cần chọn kích cỡ; Dmitry chọn bản nhỏ nhất.

Tiếp theo là cách tính velocity. Có vài cách để theo dõi tốc độ, anh chọn cách đơn giản nhất. Phương án thứ hai sẽ thêm nhiều thứ hơn, hay nói đúng hơn là đòi hỏi nhiều thời gian compute hơn.

![Câu hỏi của agent về cách định nghĩa velocity](https://homus.dev/photos/bUJgirn4_yc-0744.jpg)

Câu hỏi về velocity: vì bản thân dashcam đang di chuyển, tốc độ thật tính bằng m/s không thể khôi phục nếu không có camera calibration và độ sâu. Ba lựa chọn: image-plane (px/s, đơn giản, được khuyến nghị cho v1), ego-compensated (trừ chuyển động nền để vật đứng yên đọc gần 0, nhưng tốn thêm khoảng 50% thời gian), hoặc lưu cả hai.

Câu kế tiếp là granularity: mỗi dòng dữ liệu ứng với cái gì, theo từng detection frame hay theo từng track. Ở đây anh chọn theo từng frame. Câu cuối là về chính dataset: anh yêu cầu dữ liệu tháng 1, tức 91 clip, nhưng agent cũng hỏi có cần mở rộng phạm vi để phân tích thêm ảnh hay không. Anh giữ nguyên phạm vi.

Agent mất 24 phút để phân tích khoảng chín mươi video đó, và giờ toàn bộ thông tin đã có sẵn.

![Agent làm việc 24 phút và tóm tắt dataset dashcam-jan](https://homus.dev/photos/bUJgirn4_yc-0904.jpg)

Sau 24 phút, agent tóm tắt: đã xây dataset `dashcam-jan` gồm 121.528 object detection (YOLOv8n cộng ByteTrack) có image-plane velocity trên toàn bộ 91 clip camera trước của tháng 1, đồng thời cập nhật knowledge base. Ngay sau đó Dmitry hỏi: "how many videos have people in it".

## 7. Hỏi đáp trên dữ liệu đã tính: 82 trên 91 clip

Giờ có thể đặt câu hỏi về dữ liệu. Ví dụ: có bao nhiêu video có người? Thông tin này nằm trong database, như đã bàn ở trên, nên agent có thể query database rất nhanh và trả về kết quả. Đáp án: 82 trên 91 clip có phát hiện người (Dmitry lỡ đọc thành chín mươi hai rồi sửa lại ngay).

Bạn không cần lục qua toàn bộ file JSON, tải về, phân tích, parse. Thông tin nằm ngay trong database cục bộ, nên agent trả lời câu hỏi dễ dàng và nhanh chóng.

![Agent trả lời 82 of the 91 clips have at least one person detection](https://homus.dev/photos/bUJgirn4_yc-0952.jpg)

Câu trả lời: 82 trên 91 clip có ít nhất một detection là person. Agent ghi chú đây là một query tốn khoảng 0,001 USD trên lớp dữ liệu đã lưu, thay vì một lượt chạy detection lại mất khoảng 13 phút, và nói rõ một lưu ý: con số tính mọi clip có ít nhất một person với confidence từ 0,25 trở lên, nên nếu muốn định nghĩa chặt hơn thì có thể siết filter.

Còn có thể xem cả source code. Đó là một đoạn Python ngắn, gọn: lấy dataset, áp vài filter đơn giản (label bằng person), đếm số lượng, rồi so với tổng. Và vì nó chạy trên database nên cực nhanh.

![Code Python agent dùng để trả lời câu hỏi](https://homus.dev/photos/bUJgirn4_yc-1016.jpg)

Đoạn code chính xác agent đã chạy: đọc dataset `dashcam-jan`, đếm số clip khác nhau, lọc các dòng có label person rồi đếm clip khác nhau. Agent giải thích cả hai phép đếm đều chạy như SQL trên các dòng lưu trong warehouse, không phải vòng lặp Python, nên gần như tức thì.

```
import datachain as dc

d = dc.read_dataset("dashcam-jan")
total = d.distinct("det.source.path").count()
with_people = d.filter(dc.C("det.label") == "person").distinct("det.source.path").count()
print(f"clips with >=1 person detection: {with_people} / {total}")
```

Tiếp theo, dataset lớn đến đâu? Có bao nhiêu record? Đó chính là kích cỡ của "ngôi sao neutron" lúc nãy. Nó không lớn lắm vì mới phân tích khoảng chín mươi video, nhưng chín mươi video đã sinh ra khoảng một trăm nghìn record. Vụ nổ diễn ra đúng như vậy. Nếu phân tích hàng nghìn video, con số lên tới cỡ triệu. Và nếu đi sâu hơn vào bên trong các object, nó dễ dàng nhân thêm mười, hai mươi, thậm chí hàng trăm lần.

## 8. Data model: một class Pydantic bình thường

Hãy nhìn vào source code. Code này do agent sinh ra, agent được tăng sức nhờ harness. Phần "phép màu" ở đây là data model: một data class được sinh ra dựa trên yêu cầu của người dùng, và nó chỉ là một Pydantic data model bình thường.

Trong đó có file (chính là file video), frame ID, timestamp, class ID (để biết đó là người, ô tô hay một vật nào khác), confidence score, bounding box, và vài trường khác nữa. Object được lồng nhau: nếu nhìn vào bounding box thì đó là vài cột. Nhưng trường file mới thú vị hơn. File có path và checksum, tức version của file, có ETag, có kích thước file. Tức là mọi thứ mà nhà cung cấp cloud storage của bạn cung cấp.

![Class Detection kế thừa BaseModel trong file build_dashcam_jan.py](https://homus.dev/photos/bUJgirn4_yc-1136.jpg)

Class `Detection(BaseModel)` do agent sinh ra: `source` là một `dc.VideoFile` (con trỏ có kiểu về clip gốc), rồi `frame_idx`, `timestamp`, `track_id` (id của ByteTrack, duy nhất trong một clip), `label`, `class_id`, `confidence`, `bbox`, tâm `cx`/`cy`, velocity theo trục x và y tính bằng px/s, `speed_px_s` và `direction_deg`. Ngưỡng confidence đặt ở 0,25.

Thông tin này trở thành một dòng trong database, thay vì một file JSON trên S3. Đó là lý do bạn có thể dễ dàng trả lời mọi câu hỏi phân tích. Như câu hỏi lúc nãy, có bao nhiêu người, thì chỉ là chuyện một đoạn Python đơn giản chạy trên database và trả kết quả cực nhanh.

Đó là cách bạn hiểu được đống dữ liệu lộn xộn đang nằm trong storage dưới dạng file, nhưng lại phân tích nó bằng các công cụ và mẹo phân tích quen thuộc. Với schema, bạn thấy được bên trong object có gì, và thấy được quy mô của vấn đề.

## 9. RUN: data harness cần execution engine của riêng nó

Nhưng làm sao để làm phần việc nặng thật sự khi phải xử lý hàng terabyte dữ liệu lộn xộn này? Data harness bắt buộc phải có execution engine để làm việc với physical data. Engine đó phải chạy hiệu quả. Có khi nó tiêu tốn rất nhiều tài nguyên, và cả token nếu bạn dùng LLM; nếu nó hỏng ở đâu đó giữa chừng, bạn phải khôi phục được và nối tiếp được mọi kết quả đã xử lý, để không phí tài nguyên.

Trong thế giới SQL, thế giới structured data, execution engine chính là data warehouse của bạn. Điều đó hiển nhiên và dễ dàng. Trong thế giới unstructured data, bạn phải tự phát minh lại một cái. Một số team dùng các loại orchestration tool khác nhau, hoặc distributed compute trên [Ray](https://www.ray.io) hay Spark. Dmitry thích mô hình của [Dask](https://www.dask.org), vốn nối compute với data, nhưng là structured data. Unstructured data cần một cách tiếp cận riêng, trong đó Python và schema được nối với execution engine.

![Slide Like Ray, with a data model plus a database backend](https://homus.dev/photos/bUJgirn4_yc-1440.jpg)

"Giống Ray, nhưng có data model và database backend." So sánh: DataChain (file-native, có database phía sau), Dask (nghĩ theo DataFrame, theo dòng), Ray (distributed Python, compute đa dụng), các orchestrator như Airflow, Prefect, Dagster (cho data engineering). Mô hình: worker sinh ra typed rows (Pydantic) ghi thẳng vào một database có thể query. Câu chốt: đơn vị ở đây không phải một dòng, mà là một file.

Nói đơn giản, bạn có thể nối các hàm Python, các Pydantic schema (tham số đầu vào, tham số đầu ra của hàm), data warehouse chứa toàn bộ meta information, và các file trên storage lại với nhau thành một trải nghiệm thống nhất. Như vậy developer code đơn giản hơn, và engine cũng dễ phân phối job ra nhiều máy hoặc nhiều thread khác nhau dựa trên file chúng xử lý, schema chúng sinh ra, và vân vân. Nếu muốn, có thể gọi đó là cách tiếp cận kiểu Dask, nhưng cho thế giới unstructured data.

## 10. Một hàm Python, một dòng parallel, và checkpoint

Để chạy hiệu quả, bạn cần chạy các hàm xử lý, "nghiền" dữ liệu một cách hiệu quả, tức là song song hoặc phân tán. Đội của anh dùng data model và storage model rất nhiều. Hàm xử lý nối file (một file trong S3 bucket của bạn) với kết quả (một tập các detection object đi vào data warehouse). Tức là hàm này nối storage với data warehouse theo cách Python bình thường.

Đó là code Python rất điển hình, không có giả định đặc biệt nào. Thậm chí không dùng decorator nào cho hàm. Nó chỉ là một hàm có khai báo kiểu. Kiểu dữ liệu rất quan trọng, và tất cả đều là Pydantic. Còn kết quả thì bạn chỉ việc sinh ra các object, engine sẽ lo nối mọi storage và warehouse lại với nhau.

![Hàm detect_track nhận dc.VideoFile, trả về Iterator Detection](https://homus.dev/photos/bUJgirn4_yc-1552.jpg)

Hàm `detect_track(file: dc.VideoFile, model) -> Iterator[Detection]`: lấy fps của file, duyệt từng frame với một bước nhảy, chạy `model.track` của YOLO với ngưỡng confidence, rồi với mỗi bounding box tính tâm và velocity dựa trên vị trí trước đó của cùng track.

Đây là chỗ bạn định nghĩa lớp song song hoá (parallelization). Bạn có thể nói "tôi cần chạy cái này trên 40 máy". Với researcher, chạy distributed compute được kỳ vọng là dễ như vậy: bạn chỉ cần nói mình cần bao nhiêu tài nguyên, và bạn có nó.

![Chain read_storage, settings parallel, setup, gen, save](https://homus.dev/photos/bUJgirn4_yc-1656.jpg)

Phần cuối của script: chain đọc storage với `dc.read_storage(SRC, type="video", update=True, delta=True)`, đặt `.settings(parallel=4)`, `.setup(model=load_model)`, `.gen(det=detect_track)` rồi `.save("dashcam-jan")`.

Còn chính hàm thì chỉ cần dùng nó: chạy qua một generator, hoặc một mapper kiểu một đối một. Mapper là một hàm, một file, trả về một object vào database; generator là một hàm trả về nhiều object vào database. Và kết quả được lưu thành một dataset, bên dưới là một bảng trong database của bạn.

```
chain = (
dc.read_storage(SRC, type="video", update=True, delta=True)
.settings(parallel=4)
.setup(model=load_model)
.gen(det=detect_track)
.save("dashcam-jan")
)
```

Xử lý những file nặng như vậy thường tốn nhiều thời gian, và nhiều khi rất đắt, vì bạn dùng LLM để hiểu bên trong file binary có gì. Điều cuối cùng bạn muốn là mất phần compute đó. Thật đáng buồn khi bạn xử lý hàng trăm nghìn file rồi nó hỏng giữa chừng vì bug hay vì lỗi gọi API, và bạn không muốn chạy lại mọi thứ từ đầu. Bạn mất trọn một nửa phần compute, và đôi khi chuyện đó lặp đi lặp lại.

Incremental update và data checkpoint là thứ bắt buộc phải có trong thế giới data này. Nếu hỏng, bạn sửa bug, chạy lại, và nối tiếp từ mọi kết quả đã có. Nếu bucket có thêm file, bạn chạy lại script, nó chỉ lấy các file mới và cập nhật dữ liệu dựa trên phần compute mới, không tính lại phần còn lại.

Incremental update và checkpoint: kết quả đã tính được giữ lại, lần chạy sau (sau khi sửa bug, hoặc khi bucket có thêm file) chỉ xử lý phần còn thiếu.

## 11. VERIFY: trong data chỉ có một đáp án đúng

![Slide Part 3 of 4: VERIFY, Is the answer right?](https://homus.dev/photos/bUJgirn4_yc-1912.jpg)

Phần 3 trên 4, "đôi tay": VERIFY. Câu trả lời có đúng không?

Chạy test là một phần rất căn bản của coding agent. Chúng chạy test liên tục: để kiểm soát chất lượng, để suy luận, để hiểu rõ hơn những gì đang có xung quanh trong "vũ trụ" của chúng. Test giống như đôi tay của agent, đôi tay của harness.

Trong data, chạy test là một quá trình cực chậm. Vậy làm thế nào, khi chất lượng và độ chính xác của câu trả lời trong data project còn quan trọng hơn cả trong software project? Như Anthropic đã nói rất đúng: trong software project có rất nhiều cách để giải một bài toán cụ thể; còn trong data, thường chỉ có một cách, và chỉ có một đáp án đúng.

Làm sao trả lời câu hỏi thật nhanh trên đống dữ liệu binary lộn xộn của bạn? Trước hết, hãy thôi chạy những script Python phức tạp trực tiếp trên raw data. Đó là cách đắt nhất và chậm nhất.

## 12. Data modeling: agent tự dựng lớp metadata trước khi trả lời

Thay vào đó, bạn cần tổ chức một lớp meta information, tức các dataset hay các bảng xoay quanh raw data, có thể trả lời những câu hỏi này rất nhanh. Đây là điều ngành data đã biết từ hàng chục năm nay: dimensional modeling, multidimensional data modeling, star schema, cách tiếp cận one big table, và đủ loại lý thuyết hay ho xoay quanh nó. Ta cần dùng chúng nhiều hơn để việc xử lý unstructured data khối lượng lớn trở nên hiệu quả hơn.

![Slide The answer is data modeling](https://homus.dev/photos/bUJgirn4_yc-2008.jpg)

"Câu trả lời là data modeling." Raw file (.mp4, .json, .bin, .log) được biến thành đúng những "slice" dạng bảng cần thiết (ví dụ pedestrian 1,4, cyclist 0,9). Một kỷ luật đã có hàng chục năm: [dbt](https://www.getdbt.com), dimensional modeling, star schema. Có engine mà không có model thì mỗi câu hỏi là một job chậm; có model thì gần như tức thì. Physical data chưa có gì trong số đó, và lại cần nó nhất.

Đội của anh đã đưa những kỹ thuật này vào trong agent. Khi bạn hỏi một câu, thay vì trả lời ngay, agent tự hỏi: "Mình đã có dataset phù hợp, metadata phù hợp để trả lời câu này nhanh chóng bằng một query kiểu SQL hay chưa?" Nếu chưa, nó sẽ cố dựng lớp đó. Nó cố làm cho lớp này đủ tổng quát để trả lời không chỉ câu hỏi cụ thể của bạn, mà cả một nhóm câu hỏi liên quan tới câu bạn hỏi.

Đó là cách bạn dựng lên từng lớp, từng lớp thông tin có thể được dùng lại bởi chính bạn và đồng đội. Bạn đã bỏ ra rất nhiều thời gian và tài nguyên để tính ra những "lát cắt" hữu ích của dữ liệu, và giờ có thể dùng chúng để trả lời những câu hỏi thú vị một cách hiệu quả, không phải chạy lại phần compute đắt đỏ.

Agent kiểm tra lớp metadata trước khi trả lời; lớp được dựng ra sẽ dùng lại cho các câu hỏi sau.

## 13. REMEMBER: đừng trả tiền hai lần cho cùng một việc

![Slide Part 4 of 4: REMEMBER, Never pay twice](https://homus.dev/photos/bUJgirn4_yc-2144.jpg)

Phần 4 trên 4, trí nhớ: REMEMBER. Đừng bao giờ trả tiền hai lần.

Và đoán xem? Người ta cứ làm đi làm lại cùng một việc. Bạn trả giá gấp đôi, gấp ba, gấp bốn để giải cùng một bài toán. Vậy nên nếu bạn đã phát hiện ra ngôi sao neutron hay hố đen đó, tốt hơn là chia sẻ thông tin với mọi người, để họ không phí tài nguyên và thời gian làm lại việc này.

![Slide You built the perfect slice. Now watch it die.](https://homus.dev/photos/bUJgirn4_yc-2200.jpg)

"Bạn đã dựng được slice hoàn hảo. Giờ hãy nhìn nó chết." Hàng trăm dataset như `fleet_detections`, `fleet_v2_final`, `fleet_FINAL_final`, `corp_facts_2026`: cái nào mới là bản hiện hành? Ô "Paid twice" ghi 5.000 USD hai lần, bạn trả rồi đồng đội trả lại. Code thì có git, ai cũng clone được; data thì không có thứ tương đương.

Coding agent cũng như data agent đều dùng các mẹo về memory rất nhiều. Coding agent của bạn, như Copilot, Codex hay Pi, biết rất nhiều về source code của bạn, với đủ loại index và những thứ tương tự. Còn với data harness, bạn phải tự dựng và tự cung cấp context đó cho agent.

![Slide Memory is solved, for tables](https://homus.dev/photos/bUJgirn4_yc-2256.jpg)

"Memory đã được giải, nhưng cho bảng." Với code, có CLAUDE.md và AGENTS.md: một file context do cả team viết, commit vào git. Các lab (OpenAI, Anthropic, Databricks, Snowflake, Google) có một context layer, nhưng là cho dữ liệu dạng bảng. Dải dưới cùng của slide (bị che một phần) ghi "+<1%" cạnh dòng "Anthropic gave the agent grep over everything": cho agent grep trên mọi thứ gần như không cải thiện được gì, vì nút thắt không phải là quyền truy cập, mà là cấu trúc và độ tin cậy.

Và context đó không chỉ là việc "này, có một dataset ở đây". Bạn cần cung cấp nhiều thông tin hơn thế: vì sao dataset này được dựng, tức context từ chính phiên làm việc; mô tả của dataset, thường được LLM làm giàu thêm; và source code. Source code có lẽ là phần quan trọng nhất, và đó cũng là một trong những kết luận của blog post về data agent của OpenAI. Thông tin này cần được phơi ra dưới dạng một knowledge base, một hình thức mà agent và con người đều dễ dùng, để bạn không phí thời gian làm đi làm lại.

## 14. Knowledge base: một thư mục file Markdown

Knowledge base được tổ chức theo một cách rất truyền thống: chỉ là một tập file MD. Dmitry mở thư mục của mình cho xem; khi có thêm dataset, sẽ có thêm file. Dataset vừa tạo trong demo có file MD riêng của nó.

![Trang knowledge base của dataset dashcam-jan: mô tả và Session Context](https://homus.dev/photos/bUJgirn4_yc-2408.jpg)

Trang knowledge base của `dashcam-jan`: phần mô tả (YOLOv8n cộng ByteTrack trên 91 clip camera trước tháng 1, 720p ở 30 fps, mỗi clip khoảng 40 giây, lấy mẫu mỗi frame thứ sáu, 121.528 detection trên 91 clip và 1.326 track, velocity là image-plane chứ không phải m/s thật) và phần Session Context giải thích vì sao dataset được dựng theo đúng yêu cầu trong phiên làm việc.

Trong đó có mô tả của dataset; session context, tức vì sao dataset được tạo ra, dựa trên cuộc trao đổi; dependency tới storage, tới thư mục đã trỏ tới từ đầu; preview dữ liệu, rất hữu ích để có cảm giác về dữ liệu; schema; vài thống kê trên dữ liệu; và source code. Như đã nói, source code là phần then chốt nhất để hiểu dữ liệu nói về cái gì.

![Phần source code trong trang knowledge base](https://homus.dev/photos/bUJgirn4_yc-2440.jpg)

Phần source code nằm ngay trong trang: docstring nói rõ đây là việc dựng lớp dữ liệu `dashcam-jan`, phương pháp (YOLOv8n cộng ByteTrack), cách lấy mẫu (mỗi frame thứ sáu, khoảng 5 fps trên nguồn 30 fps), ngưỡng confidence 0,25, và đường dẫn S3 nguồn.

Tất cả các mảnh này gộp lại: dữ liệu nguồn trong bucket, source code trong knowledge base, kết quả trong data warehouse, tạo thành data lineage. Mọi thứ được nối với nhau. Agent biết mọi thứ. Nếu bạn chia sẻ knowledge graph, thì mọi đồng đội của bạn cũng đã biết về dataset này, và biết bạn đã tiêu tốn bao nhiêu tài nguyên để xử lý nó. Lần sau, nếu ai đó hỏi về thư mục này, việc tính lại sẽ không xảy ra. Agent sẽ dùng kết quả của bạn, kết quả dựa trên những tài nguyên bạn đã bỏ ra. Đó là phép màu của data harness khi agent biết mọi thứ về dữ liệu của bạn.

## 15. Ghép lại thành một stack

Ghép mọi mảnh lại thành một stack. Ở đáy stack là một khối khổng lồ unstructured physical data nằm trong object storage. Không ai hiểu được khối dữ liệu này, và bạn phải chạy compute đắt đỏ, các lời gọi LLM, để trích xuất meta information thông qua compute engine, rồi tổ chức meta information đó thành dataset, thành các dataset slice, thông qua một Dataset DB. Knowledge base là cách bạn chia sẻ thông tin này.

![Slide The stack: Raw files, Compute engine, Dataset DB, Knowledge base](https://homus.dev/photos/bUJgirn4_yc-2600.jpg)

The stack, từ dưới lên: raw file trên S3 (khối lượng), compute engine (RUN), Dataset DB (SEE, VERIFY), knowledge base (REMEMBER). Mũi tên bên trái ghi "build once", bên phải ghi "read forever": dựng một lần, đọc mãi mãi.

Đây là thế giới mà các coding agent yêu thích của bạn như Copilot, Codex, Claude Code không vận hành hiệu quả. Trực giác của chúng đẩy chúng đi sai hướng, vì các định luật vật lý đã thay đổi. Và để làm được, bạn không dùng model mạnh hơn: ai cũng đang dùng frontier model rồi. Thay vào đó, bạn xây data harness, một data harness hiểu các định luật của physical data. Đó là cách để coding agent yêu thích của bạn làm việc hiệu quả với những bài toán này.

![Slide The body, rebuilt, bản đã ghép đủ](https://homus.dev/photos/bUJgirn4_yc-2552.jpg)

"The body, rebuilt" bản ghép đủ: SEE là Pydantic schema (100 triệu object), RUN là efficient compute (hàng giờ compute), VERIFY là kiểm tra trở nên rẻ (đáp án chính xác), REMEMBER là knowledge base. Vẫn là harness mà coding agent của bạn đang chạy, nhưng được dựng lại cho một thế giới mà việc tính lại là kẻ thù.

Đội của anh đã hiện thực một số nguyên tắc này trong project DataChain, là open source. Lời kết của Dmitry: hãy xem thử, và "đặt thêm chút khối lượng cho agent của bạn". Cảm ơn.

## Nguồn và liên kết

- [DataChain trên GitHub](https://github.com/datachain-ai/datachain): project open source dùng trong demo · [tài liệu DataChain](https://docs.datachain.ai)

- [DVC (Data Version Control)](https://dvc.org): project trước đó của Dmitry, "Git cho data"

- [Claude Code](https://docs.anthropic.com/en/docs/claude-code): coding agent dùng trong demo

- [Pydantic](https://docs.pydantic.dev): thư viện schema dùng cho data model

- [Ultralytics YOLOv8](https://docs.ultralytics.com/models/yolov8/) và [ByteTrack](https://github.com/ifzhang/ByteTrack): model detection và tracker agent chọn trong demo

- [Dask](https://www.dask.org), [Ray](https://www.ray.io): các mô hình distributed compute được so sánh

- [dbt](https://www.getdbt.com): công cụ data modeling được nhắc trên slide

- [GitHub của Dmitry Petrov](https://github.com/dmpetrov) · X: @FullStackML