Agent không biết đọc — xây gì cũng đổ

Mọi người đang scale agent lên hàng trăm con, nhưng khâu parsing tài liệu — bước số 0 — thì chưa ai benchmark nghiêm túc.

Bạn có chắc agent của mình đọc đúng không?

Mình hỏi thật: lần cuối bạn kiểm tra xem con agent parse file PDF có chính xác không là khi nào?

Hầu hết team mình biết đều dồn sức vào prompt engineering, chọn model, tối ưu retrieval... rồi lướt qua một bước tưởng nhỏ mà cực kỳ quan trọng: con agent có đọc đúng tài liệu đầu vào không. Không phải "gần đúng". Không phải "đọc được phần lớn". Mà đúng — từng bảng, từng cột, từng dòng footnote.

LlamaIndex vừa tung ParseBench — benchmark đầu tiên chuyên đo chất lượng document parsing cho AI agent. Và kết quả thì... Plot twist: rất nhiều pipeline đang "đọc nhầm" mà chẳng ai hay.

Chẩn đoán sai thì chữa đúng cách nào?

Hình dung thế này: bạn vào bệnh viện, bác sĩ siêu giỏi, phòng mổ hiện đại, nhưng kết quả xét nghiệm máu bị sai. Bác sĩ giỏi mấy cũng chữa nhầm bệnh.

Document parsing trong pipeline AI agent y hệt cái phòng xét nghiệm đó. Nó là bước đầu tiên, âm thầm nhất, nhưng nếu sai thì mọi thứ phía sau đều đổ. Model xịn cỡ nào, prompt chuẩn đến mấy, retrieval tối ưu ra sao — nếu input đã sai thì output chỉ là rác được đóng gói đẹp.

ParseBench test khả năng parse các loại tài liệu thực tế — PDF có bảng phức tạp, hợp đồng nhiều cột, invoice có header lặp, tài liệu scan chất lượng kém. Đúng những thứ team nào cũng gặp nhưng ít ai ngồi đo một cách có hệ thống.

Hai kịch bản mà team Việt Nam sẽ quen lắm

Kịch bản 1: Team fintech parse hợp đồng tín dụng

Giả sử team bạn 4 người, đang xây agent tự động review hợp đồng tín dụng. File PDF từ ngân hàng gửi qua — mỗi ngân hàng một format, có file scan, có file digital, có file nửa scan nửa digital (kiểu ai đó in ra rồi scan lại vì... thủ tục).

Agent đọc sai một ô trong bảng lãi suất? Không ai phát hiện cho đến khi khách hàng complaint. Lúc đó mới ngồi debug thì mới biết — ô "lãi suất 8.5%" bị parse thành "85%" vì parser nhầm dấu chấm thập phân với dấu chấm kết thúc câu. Một dấu chấm, cả pipeline nổ tung.

Kịch bản 2: Team logistics parse vận đơn

Giả sử bạn xây automation cho công ty logistics, agent cần đọc bill of lading từ hàng chục hãng tàu khác nhau. Mỗi hãng một layout, một font, một kiểu bảng. Agent parse đúng 95% — nghe ổn phết? Nhưng 5% sai đó rơi đúng vào trường container number hoặc trọng lượng hàng. Hậu quả: hàng đi nhầm cảng, đội chi phí thật.

Nói cho vuông: parsing không phải bài toán "gần đúng là được". Đúng hoặc sai, và sai thì hậu quả dội xuống toàn bộ pipeline.

Hệ sinh thái đang chạy nhanh hơn nền móng

Trong khi parsing vẫn là khâu yếu chưa ai đo đàng hoàng, thế giới xung quanh lại đang scale rất nhanh.

AWS vừa ra Agent Registry trong AgentCore — một nơi tập trung để doanh nghiệp đăng ký, chia sẻ, và tái sử dụng agent across toàn tổ chức. Khi công ty có hàng trăm agent, bạn cần biết con nào làm gì, ai build, ai maintain. Không có registry thì agent sprawl — mỗi team tự build một con trùng chức năng, không ai govern, compliance risk tăng vù vù.

Pinecone thì ra Assistant — một managed knowledge layer gom hết document ingestion, chunking, embedding, retrieval, reranking vào một service duy nhất. Thay vì team phải tự ghép từng component như ráp mô hình giải phẫu trong lớp y khoa, Pinecone bảo: "Đưa tài liệu đây, để mình lo."

Hai hướng bổ trợ nhau: AWS lo quản lý agent ở quy mô lớn, Pinecone lo biến document thành knowledge đáng tin cậy. Nhưng cả hai đều đứng trên một giả định ngầm: tài liệu đầu vào được parse đúng ngay từ đầu.

ParseBench quan trọng vì nó là lần đầu có ai đứng ra nói: "Khoan, đo cái nền đã rồi hãy xây lên."

Thử ngay chiều nay: audit pipeline parsing của bạn

Không cần chờ benchmark chính thức. Chiều nay, thử 5 bước sau:

1. Lấy 10 file thật từ production — chọn đa dạng: PDF scan, PDF digital, file có bảng, file có hình nhúng.
2. Chạy qua parser hiện tại của bạn (dù là LlamaParse, Unstructured, hay PyPDF), lưu output dạng text.
3. Mở file gốc và output ra song song, đọc bằng mắt. Đặc biệt soi: bảng có giữ đúng cấu trúc không? Số liệu có bị nhảy hàng không? Footnote có bị nuốt không?
4. Ghi lại error rate — bao nhiêu file trong 10 file bị sai ít nhất 1 trường quan trọng?
5. So sánh ít nhất 2 parser trên cùng bộ file. Kết quả khác nhau rõ rệt — mình đảm bảo.

Nếu team thiên về open-source, Unstructured và Docling là hai lựa chọn đáng thử. Nếu cần managed service, LlamaParse (bạn đọc bài cũ của mình về LlamaIndex thì đã quen) là một option đáng cân nhắc.

Cái bẫy mà team nào cũng từng bước vào

Sai lầm kinh điển: team demo agent trên vài file mẫu "sạch đẹp", kết quả ngon lành, tự tin deploy. Rồi file thật từ khách hàng gửi qua — scan nghiêng, font lạ, watermark đè lên text — mọi thứ vỡ.

Để mình minh họa: một team quen build agent review CV cho công ty tuyển dụng. Demo trên 20 file CV format chuẩn — xuất sắc. Production nhận CV thật: có bạn gửi file Word mà bên trong nhúng ảnh chụp bằng lái, có bạn gửi PDF nhưng thật ra là 5 trang screenshot dán vào. Parser bó tay, agent trả kết quả lung tung, HR complaint ngược lại team dev.

Bài học ở đây: benchmark trên data sạch không nói lên điều gì cả. ParseBench đáng chú ý chính vì nó dùng tài liệu thực tế — đúng cái loại "bẩn" mà production sẽ ném vào mặt bạn.

Một dòng mang về

Trước khi tối ưu prompt, trước khi chọn model mới, trước khi scale lên registry quản lý hàng trăm agent — hãy quay lại kiểm tra bước số 0: agent của bạn có thật sự đọc đúng tài liệu không.

Vì xây bệnh viện 5 sao mà phòng xét nghiệm trả nhầm kết quả thì cuối cùng cũng chỉ là... khám bệnh theo kiểu xổ số.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng