PDF to JSON: chọn dao trước khi nấu

PDF to JSON: chọn dao trước khi nấu

Đừng chọn model PDF vì nó mới. Với team builder, quyết định đúng bắt đầu từ câu hỏi: bạn cần lấy field hay dựng lại tài liệu?

“Em có một folder 40.000 file PDF, cuối tuần này làm chatbot hỏi đáp được không chị?”

Câu này mình nghe trong một buổi cà phê với một tech lead ở Sài Gòn. Bạn ấy không nói đùa. Folder đó có hợp đồng scan, báo giá, hóa đơn, phụ lục có chữ ký, và mấy file PowerPoint export thành PDF từ thời ai đó còn dùng font VNI. Team đã có RAG, có agent, có vector database. Cái thiếu là phần ít được khoe trên demo: biến đống tài liệu kia thành JSON đủ sạch để hệ thống dùng.

Va chạm bắt đầu khi một bạn trong team bảo: “Lấy model mới nhất parse hết PDF thành Markdown đi.” Bạn khác phản biện: “Không, mình chỉ cần số hợp đồng, ngày hết hạn, tổng tiền, mã khách hàng. Parse cả trang làm gì?”

Đây là tranh luận đáng tiền. Không phải vì ai đúng tuyệt đối, mà vì hai người đang nói về hai bài toán khác nhau dưới cùng một nhãn “PDF to JSON”.

Sơ đồ minh họa cho bài PDF to JSON: chọn dao trước khi nấu

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

Tranh luận thật sự: lấy field hay dựng lại tài liệu?

Trong pipeline AI, “PDF to JSON” thường bị gom chung như một bước tiền xử lý. Nhưng với builder, gom chung như vậy dễ dẫn tới chọn sai tool, sai benchmark, sai chi phí.

Có hai hướng chính:

  1. Schema-driven extraction — trích xuất theo schema. Bạn định nghĩa trước các field cần lấy, model trả JSON đúng cấu trúc đó. Ví dụ: invoice_number, vendor_name, total_amount, due_date.
  2. Document parsing — phân tích cấu trúc tài liệu. Model cố dựng lại layout, thứ tự đọc, bảng, công thức, code, heading, rồi xuất ra JSON hoặc Markdown.

Nói thẳng ra thì: schema extraction giống bạn đưa công thức món cần nấu và hỏi “cho tôi đúng từng nguyên liệu này”; document parsing giống bạn bảo “hãy chép lại toàn bộ cuốn sổ tay bếp sao cho người sau đọc được”. Cả hai đều hữu ích, nhưng đổi nhầm là cháy bếp.

Với hóa đơn, form, hợp đồng có field ổn định, schema extraction thường thắng vì bạn quan tâm kết quả cuối. Với tài liệu kỹ thuật, slide deck, manual, policy dài để đưa vào RAG, document parsing hợp lý hơn vì bạn cần ngữ cảnh và cấu trúc.

Biến số 1: output contract — bạn muốn JSON để kiểm hay JSON để đọc?

Điểm nhiều team hiểu sai: JSON không tự động đồng nghĩa với “structured”. Một blob Markdown nhét trong JSON vẫn có thể vô dụng nếu downstream không biết kiểm tra.

Output contract — hợp đồng đầu ra — là thứ bạn nên chốt trước khi chọn model. Nó trả lời: output có thể validate tự động không, sai thì phát hiện ở đâu, retry theo field hay retry cả trang?

Ví dụ cụ thể: team bạn xử lý hợp đồng thuê mặt bằng. Nếu mục tiêu là cảnh báo hợp đồng sắp hết hạn, schema có thể như sau:

{
  "contract_id": "string",
  "tenant_name": "string",
  "start_date": "YYYY-MM-DD",
  "end_date": "YYYY-MM-DD",
  "monthly_fee": "number",
  "termination_notice_days": "number"
}

Ở đây, model như lift đáng chú ý vì nó là vision model 9B cho schema-driven extraction, có schema-constrained decoding — hiểu ngắn là cơ chế ép output khớp schema hợp lệ thay vì để model viết JSON theo cảm hứng. Theo benchmark 225 tài liệu của Datalab, lift đạt 90,2% field accuracy với median latency 9,5 giây; cao hơn NuExtract3 81,5% và Qwen3.5-9B 76,3%, nhưng thấp hơn Gemini Flash 3.5 ở mức 91,3%.

Con số này không nói “hãy dùng lift ngay”. Nó nói một điều thực dụng hơn: nếu bạn đo theo field accuracy, hãy chọn nhóm model sinh ra để điền field. Đừng lấy benchmark đọc layout để quyết định bài toán kiểm hợp đồng.

Ngược lại, nếu bạn cần dựng corpus cho RAG, field accuracy không đủ. Bạn phải hỏi: bảng có giữ được hàng/cột không? Heading có đúng cấp không? Thứ tự đọc có bị đảo không? Caption hình có đi cùng hình không? Đây là đất của document parsing.

Biến số 2: độ dài tài liệu và cái giá của cache

PDF doanh nghiệp hiếm khi ngoan. Một file có thể 3 trang, cũng có thể 80 trang scan, thêm phụ lục bảng dài lê thê. Với document parsing, độ dài không chỉ là chuyện “chờ lâu hơn”. Nó đụng tới KV cache — bộ nhớ trung gian lưu key/value attention khi model sinh token. Output càng dài, cache thường càng phình; latency và memory kéo nhau tăng.

Đây là lý do các model như Unlimited OCR của Baidu đáng để builder nhìn dưới góc vận hành, không chỉ nhìn điểm benchmark. Nó là model 3B Mixture-of-Experts — kiến trúc nhiều “nhánh chuyên gia”, nhưng chỉ kích hoạt một phần khi chạy — với 500M tham số active ở inference. Điểm kỹ thuật nổi bật là Reference Sliding Window Attention (R-SWA), cách attention giữ KV cache gần như cố định bằng việc cho token mới nhìn vào reference tokens và một cửa sổ output gần nhất.

Theo công bố, Unlimited OCR parse hàng chục trang trong một forward pass dưới giới hạn 32K, đạt 93,23 trên OmniDocBench v1.5 và hơn baseline DeepSeek OCR 6,22 điểm. Phần đáng để bạn ghi vào sổ không phải “3B cũng ngon”, mà là: với long-document parsing, kiến trúc cache có thể quan trọng ngang kích thước model.

Điều này nối với bài học từ VibeThinker-3B: reasoning có cấu trúc có thể nén tốt, nhưng factual knowledge rộng thì không. Dịch sang bài toán PDF: một model nhỏ, chuyên đúng việc, có thể rất ổn cho layout/OCR/extraction có kiểm chứng; nhưng đừng kỳ vọng nó thay cả hệ thống hiểu nghiệp vụ, kiểm pháp lý, và nhớ mọi ngoại lệ ngành.

Bảng quyết định: đừng hỏi “model nào tốt nhất”

Nếu team đang đứng giữa các lựa chọn, mình sẽ đặt cạnh nhau như sau:

| Câu hỏi | Chọn schema-driven extraction khi... | Chọn document parsing khi... |
|---|---|---|
| Bạn biết trước field cần lấy? | Có, field ổn định | Không, cần giữ toàn bộ nội dung |
| Output cần validate tự động? | Rất cần: type, required field, enum | Cần validate theo cấu trúc: heading, table, reading order |
| Tài liệu dài nhiều trang? | Chỉ cần vài giá trị xuyên trang | Cần parse nhiều trang thành corpus |
| Downstream là gì? | Workflow, reconciliation, audit, automation | RAG, search, agent đọc tài liệu |
| Sai ở đâu nguy hiểm hơn? | Sai một field quan trọng | Sai layout làm mất ngữ cảnh |

Bản chất thật sự: bạn không chọn model, bạn chọn kiểu lỗi chấp nhận được.

Nếu dùng schema extraction, lỗi thường là thiếu field, nhầm giá trị, lấy sai trang. Bạn có thể viết rule kiểm: ngày hết hạn phải sau ngày bắt đầu, tổng tiền phải là số dương, mã số thuế đúng format.

Nếu dùng document parsing, lỗi thường âm thầm hơn: bảng bị flatten, đoạn văn bị đảo thứ tự, header/footer lẫn vào nội dung, footnote trôi sang chunk khác. RAG phía sau vẫn trả lời được, nhưng câu trả lời có thể dựa trên ngữ cảnh méo.

Nếu là team Việt Nam 5 người, mình sẽ chọn thế này

Giả sử team bạn 5 người, có một GPU nội bộ vừa phải, tài liệu chứa dữ liệu khách hàng không muốn gửi ra ngoài. Mình sẽ không bắt đầu bằng “đổi model”. Mình sẽ bắt đầu bằng một ma trận quyết định nhỏ trong một buổi chiều:

Bước 1: Chia tài liệu thành 3 rổ

Bước 2: Viết schema tối thiểu cho rổ A/B

Đừng viết 60 field ngay. Chọn 8-12 field thật sự đi vào workflow. Field nào không có người dùng hoặc rule kiểm thì để sau. Nêm schema cũng như nêm nước dùng: tham field quá sớm là mặn, ít field quá thì nhạt.

Bước 3: Chạy song song hai pipeline nhỏ

Bước 4: Đo bằng lỗi downstream, không chỉ đo output đẹp

Với extraction, log theo field: field nào hay sai, sai vì OCR, vì schema mơ hồ, hay vì tài liệu thiếu thông tin.

Với parsing, lấy 20 câu hỏi RAG thật, kiểm xem câu trả lời sai do retrieval, do chunking, hay do parser làm hỏng layout. Đây là nơi nhiều demo đẹp bị lộ: Markdown nhìn sạch, nhưng bảng giá bị tách khỏi điều khoản áp dụng.

Bước 5: Đặt cổng an toàn cho open-source

Open weights hấp dẫn vì cost và privacy, nhưng kéo model về tự chạy không có nghĩa là hết rủi ro. Bạn vẫn cần scan dependency, pin version, ghi provenance của model, và có quy trình patch. Câu chuyện Akrites của Linux Foundation nhắc một điều hơi lạnh gáy: AI làm việc tìm lỗi trong open-source nhanh hơn, nên vận hành open-source cũng phải có kỷ luật hơn.

Kết luận: chọn theo món cần dọn ra bàn

Sau bài này, điều mình muốn bạn nghĩ khác là: PDF to JSON không phải một category tool, mà là một quyết định kiến trúc về output và failure mode.

Model mới, điểm benchmark cao, context dài — tất cả đều đáng xem. Nhưng nếu team chưa trả lời “mình cần field để hành động hay cấu trúc để đọc lại?”, thì mọi lựa chọn phía sau chỉ là nấu món chưa biết khách gọi gì.

Nếu là mình, mình sẽ chọn schema extraction cho workflow có field rõ, document parsing cho RAG cần giữ ngữ cảnh, và chỉ ghép cả hai khi tài liệu thật sự vừa cần kiểm field vừa cần đọc sâu. Dao sắc rất tốt, nhưng trước hết phải biết mình đang thái hành hay lọc cá.

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

Nguồn tham khảo