Đừng parse PDF nếu không giữ chứng cứ

Đừng parse PDF nếu không giữ chứng cứ

Granular bounding boxes không chỉ là tính năng OCR đẹp hơn. Với builder, nó là cách biến extraction thành thứ có thể kiểm tra, debug và chịu trách nhiệm.

Có một kiểu demo AI tài liệu rất dễ làm cả phòng họp gật gù: thả một file PDF vào, model nhả ra bảng dữ liệu gọn gàng, ai đó nói “xịn đó”, rồi team bắt đầu nghĩ đến chuyện đưa vào workflow thật.

Rồi đến ngày kế toán hỏi: “Con số này lấy từ dòng nào?”

Im lặng.

Không phải vì model chắc chắn sai. Mà vì hệ thống không giữ được chứng cứ. Nó chỉ đưa kết quả, không chỉ được tọa độ gốc trên trang. Với tài liệu doanh nghiệp — payroll report, financial filing, audit record, invoice — câu trả lời đúng chưa đủ. Bạn còn phải chứng minh nó đúng ở đâu.

Đó là lý do mình thấy phần đáng bàn trong granular bounding boxes của LlamaParse không nằm ở chuyện “parser mới ngon hơn”. Điểm hay hơn là: document AI đang dịch chuyển từ extraction-first sang evidence-first.

Sơ đồ minh họa cho bài Đừng parse PDF nếu không giữ chứng cứ

Sơ đồ tóm tắt ý chính của bài viết.

Niềm tin phổ biến: parser càng thông minh càng tốt

Nhiều team đang nhìn pipeline tài liệu như một bài toán trích xuất:

Nếu output đúng schema là vui. Nếu model trả JSON hợp lệ là càng vui. Nếu chạy được trên nhiều loại PDF thì coi như qua vòng gửi xe.

Nhưng trong production, câu hỏi khó hơn thường là:

Bounding box là vùng tọa độ bao quanh nội dung trên trang. Trước đây, nhiều parser chỉ trả về bounding box ở mức thô: cả đoạn văn, cả khối layout, hoặc cả bảng. Cách này giống như một bạn nhân sự mới bảo “em thấy thông tin đó trong phòng kế toán”, nhưng không chỉ được nó nằm ở bàn nào, tập hồ sơ nào.

Granular bounding boxes đi vào mức chi tiết hơn: thay vì chỉ khoanh cả khối, hệ thống cố gắng gắn vị trí cụ thể hơn cho phần thông tin được parse. Với builder, khác biệt này không phải trang trí UI. Nó quyết định bạn có debug được pipeline hay không.

Mổ lớp đầu: extraction precision chưa phải vạch đích

LlamaParse đặt vấn đề khá đúng: Agentic Document AI có hai yêu cầu song song.

Một là extraction precision — độ chính xác khi kéo giá trị ra khỏi tài liệu phức tạp. Ví dụ: trong một báo cáo lương dày đặc, hệ thống phải lấy đúng “net pay”, không lấy nhầm “gross pay”.

Hai là attribution precision — độ chính xác khi chỉ ra giá trị đó đến từ đâu trên trang. Ví dụ: không chỉ trả net_pay: 18,500,000, mà còn biết nó nằm ở trang nào, vùng nào, dòng nào.

Nói thẳng ra thì: extraction là “trả lời đúng”, attribution là “đưa bằng chứng”.

Với chatbot hỏi đáp tài liệu nội bộ, đôi khi citation ở mức đoạn văn đã tạm ổn. Nhưng với workflow có người duyệt, có kiểm toán, có rủi ro tiền bạc hoặc pháp lý, citation mơ hồ sẽ thành nợ kỹ thuật.

Ví dụ cụ thể: team bạn làm hệ thống đọc invoice. Model lấy ra tổng tiền là 42 triệu. Nếu bounding box chỉ khoanh cả bảng 30 dòng, reviewer vẫn phải dò bằng mắt. Nếu bounding box trỏ đúng ô chứa tổng tiền, reviewer kiểm nhanh hơn và biết lỗi nằm ở parser, OCR, hay rule mapping.

Đây là khác biệt giữa “AI có vẻ biết đọc” và “AI có thể làm đồng nghiệp trong quy trình thật”. Đồng nghiệp mới không chỉ gửi kết quả; họ phải để lại dấu vết công việc đủ rõ để lead review.

Mổ lớp hai: bounding box càng chi tiết, tradeoff càng thật

Đừng hiểu granular bounding boxes là cứ bật lên là mọi thứ tự nhiên sạch đẹp. Với builder, nó mở thêm năng lực, đồng thời mở thêm trách nhiệm thiết kế.

1. Bạn phải quyết định lưu gì

Nếu pipeline chỉ lưu text output, bạn debug rất nghèo. Nhưng nếu lưu toàn bộ tọa độ chi tiết cho mọi token, mọi trang, mọi lần parse, storage và complexity tăng lên.

Một hướng thực dụng:

{
  "field": "invoice_total",
  "value": "42,000,000 VND",
  "page": 3,
  "bbox": [120, 680, 420, 710],
  "source_text": "Total amount: 42,000,000 VND",
  "confidence_note": "matched total row, not subtotal"
}

Đây chỉ là ví dụ minh họa, không phải format bắt buộc. Ý chính là mỗi field quan trọng nên đi kèm evidence payload — gói dữ liệu chứng cứ đủ để người và máy kiểm lại.

2. UI review phải đi cùng backend

Có tọa độ mà không hiển thị được thì giống daily standup có ghi action item nhưng không ai mở lại. Nếu sản phẩm của bạn có human-in-the-loop — tức người kiểm tra trước khi chốt — hãy thiết kế màn hình review ngay từ đầu:

Granular bounding boxes đáng giá nhất khi nó rút ngắn vòng lặp giữa “AI nói” và “người kiểm”.

3. Evaluation nên chấm cả vị trí, không chỉ chấm value

Nhiều bộ test nội bộ chỉ hỏi: value extracted có đúng không? Nhưng nếu hai hệ thống cùng trả đúng value, hệ thống nào chỉ được nguồn tốt hơn sẽ đáng tin hơn trong production.

Bạn có thể thêm một cột đánh giá:

| Tiêu chí | Câu hỏi cần chấm |
|---|---|
| Field accuracy | Giá trị lấy ra có đúng không? |
| Source accuracy | Vùng được trỏ tới có đúng chỗ không? |
| Review friction | Người kiểm có xác nhận được nhanh không? |
| Failure clarity | Khi sai, có biết sai ở OCR, layout hay reasoning không? |

Điểm cuối cùng mới quan trọng. Một pipeline sai nhưng dễ hiểu đôi khi còn sửa được. Một pipeline sai mà không để lại dấu vết thì chỉ còn cầu may.

Thứ nên giữ: framework “giá trị nào cần chứng cứ?”

Không phải field nào cũng cần granular bounding box. Nếu bạn bắt hệ thống lưu chứng cứ cho mọi mẩu text, pipeline có thể phình ra không cần thiết.

Mình sẽ chia field thành ba nhóm:

Nhóm A — field quyết định tiền, pháp lý, compliance
Ví dụ: tổng tiền, số tài khoản, điều khoản phạt, ngày hiệu lực, mã định danh, kết quả xét duyệt. Nhóm này nên có bbox chi tiết, source text, page number, và log sửa đổi.

Nhóm B — field hỗ trợ tìm kiếm hoặc phân loại
Ví dụ: loại tài liệu, tên phòng ban, nhãn chủ đề. Nhóm này có thể cần citation nhẹ hơn, tùy mức rủi ro.

Nhóm C — field tiện ích giao diện
Ví dụ: summary ngắn, gợi ý tiêu đề, mô tả tự động. Nhóm này không nhất thiết cần tọa độ chi tiết, miễn là không dùng để ra quyết định cứng.

Hình dung thế này: không phải nhân viên nào trong công ty cũng cần OKR chi tiết từng giờ. Nhưng người ký hợp đồng, duyệt tiền, hoặc xử lý compliance thì cần dấu vết rõ hơn nhiều. Document AI cũng vậy.

Thứ nên bỏ qua: khoe highlight đẹp nhưng không đổi workflow

Có một cái bẫy khá phổ biến: thêm highlight trên PDF rồi gọi đó là “trust layer”. Nếu highlight không gắn với audit log, không giúp reviewer sửa nhanh hơn, không đi vào evaluation, thì nó chỉ là lớp sơn giao diện.

Với team builder, câu hỏi nên là:

Nếu câu trả lời vẫn là dò tay, bạn chưa có evidence layer. Bạn mới có extraction output.

Một buổi chiều để kiểm lại pipeline của bạn

Nếu đang build hệ thống đọc tài liệu, bạn không cần đập đi làm lại ngay. Hãy dành một buổi chiều audit nhẹ theo bốn bước:

  1. Chọn 20 tài liệu khó nhất: file scan mờ, bảng nhiều cột, layout lệch, nhiều con số giống nhau.
  2. Liệt kê 10 field quan trọng nhất: ưu tiên field có rủi ro tiền, hợp đồng, compliance.
  3. Với mỗi field, hỏi “chứng cứ nằm đâu?”: nếu chỉ có value mà không có page, bbox, source text, ghi là thiếu.
  4. Thử review bằng người thật: đưa output cho một teammate chưa build hệ thống, xem họ mất bao lâu để xác nhận đúng/sai.

Sau bước này, bạn sẽ biết mình cần granular bounding boxes ở đâu, không cần ở đâu, và phần nào của workflow đang giả vờ tự động hóa nhưng thật ra vẫn bắt người dùng đi mò.

Góc nhìn mới: parser không chỉ đọc, parser phải chịu kiểm tra

Granular bounding boxes của LlamaParse đáng chú ý không phải vì nó làm PDF trở nên “thông minh” hơn theo kiểu demo. Nó đáng chú ý vì nó đẩy một câu hỏi production lên mặt bàn: mỗi giá trị AI trích xuất có đi kèm bằng chứng đủ tốt chưa?

Sau bài này, nếu bạn đang chọn document parser, đừng chỉ hỏi “tool nào extract đúng hơn?”. Hãy hỏi thêm: “tool nào giúp mình chứng minh, review và debug kết quả tốt hơn?”.

AI đọc tài liệu mà không giữ chứng cứ thì giống đồng nghiệp gửi file cuối ngày nhưng xóa hết comment trong task — nhìn có vẻ xong việc, đến lúc sai thì cả team cùng đi tìm kim trong đống PDF.

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

Nguồn tham khảo