Đừng giao hết tài liệu cho một model

Playbook chọn pipeline nhiều model cho xử lý tài liệu: khi nào tách nhiệm vụ, khi nào giữ một model, và rủi ro vận hành cần tính trước.

Bụi Wire

2026-07-01

“Cứ đưa nguyên file scan cho model mạnh nhất xử lý hết đi.”

Câu này mình nghe nhiều tới mức có thể đoán được đoạn tiếp theo: demo chạy đẹp, vài trang đầu trông ổn, team hí hửng nối vào batch job, rồi hóa đơn và lỗi edge case bắt đầu gõ cửa. Không phải vì model dở. Mà vì mình đang bắt một model vừa làm thợ đo, thợ xây, kỹ sư kết cấu, vừa ký biên bản nghiệm thu.

Luận điểm của bài này gọn thôi: xử lý tài liệu bằng AI không nên bắt đầu bằng câu hỏi “model nào thông minh nhất?”, mà bằng câu hỏi “việc nào cần model thông minh, việc nào chỉ cần model đủ rẻ và ổn định?”

AWS có một ví dụ khá đáng học: dùng Amazon Nova 2 Lite để trích xuất nội dung đa phương thức từ trang kỷ yếu scan, rồi dùng Claude Sonnet 4.6 để suy luận không gian, ghép tên với khuôn mặt. Trên 336 trang, pipeline tạo 3.122 cặp tên-khuôn mặt, 93% đạt confidence từ 0.95 trở lên, và chi phí mỗi trang thấp hơn khoảng hai phần ba so với cách ném toàn bộ việc cho một vision-language model duy nhất.

Nhưng bài này không phải để bảo bạn “hãy dùng đúng combo đó”. Điểm đáng giữ lại là cách chia việc.

Sơ đồ minh họa cho bài Đừng giao hết tài liệu cho một model

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

Quyết định trước: một model hay nhiều model?

Nếu bạn đang build hệ thống đọc tài liệu scan, invoice, hồ sơ nhân sự, hồ sơ bảo hiểm, hợp đồng cũ, hoặc tài liệu lưu trữ, có ba hướng phổ biến:

| Hướng | Khi nào hợp | Điểm mạnh | Cái giá phải trả |
|---|---|---|---|
| Một model mạnh làm tất cả | Volume thấp, schema thay đổi liên tục, cần ra demo nhanh | Đơn giản, ít glue code | Đắt, khó debug lỗi từng bước |
| OCR/classic pipeline trước, LLM sau | Tài liệu nhiều chữ, layout tương đối rõ | Rẻ, dễ audit text layer | Yếu khi cần hiểu ảnh, box, quan hệ không gian |
| Hai model chia vai | Có cả text, ảnh, layout; volume đủ lớn | Tối ưu chi phí và chất lượng theo từng việc | Phải thiết kế contract giữa các stage |

Nói thẳng ra thì: pipeline nhiều model chỉ đáng làm khi bạn biết rõ ranh giới giữa “trích xuất” và “suy luận”. Nếu không, bạn chỉ đang dựng thêm giàn giáo cho một căn nhà chưa có bản vẽ.

Trong ví dụ kỷ yếu, Nova 2 Lite làm phần gần với “nhìn và đo”: phát hiện ảnh chân dung, trả bounding boxes, đọc tên thấy được trên trang, kèm vị trí tương đối. Claude làm phần “suy luận quan hệ”: tên nào nằm gần ảnh nào, layout trang đang theo cột hay cụm, trường hợp nào cần confidence thấp hơn.

Đây là khác biệt rất thực dụng. Không phải bước nào cũng cần model giỏi lập luận. Có bước chỉ cần model trả JSON đều, nhanh, và rẻ.

Checklist chọn kiến trúc trong một buổi chiều

Trước khi mở console và gọi API, bạn nên trả lời 6 câu này. In ra giấy cũng được, vì nhiều team fail không phải ở prompt mà ở quyết định mơ hồ.

1. Tài liệu của bạn có mấy loại tín hiệu?

Chỉ text scan → OCRmyPDF/Tesseract hoặc OCR managed có thể đủ cho bước đầu.
Text + bảng + ảnh → cần model đa phương thức, tức model đọc được cả chữ lẫn hình.
Text + ảnh + quan hệ vị trí → cần thêm stage suy luận không gian.

2. Output cuối cùng là gì?

Đừng ghi “extract document”. Ghi cụ thể:

{
  "person_name": "...",
  "face_box": [x1, y1, x2, y2],
  "name_box": [x1, y1, x2, y2],
  "confidence": 0.0,
  "reason": "name appears below the portrait in same column"
}

Output càng rõ, bạn càng dễ biết stage nào đang sai.

3. Bạn cần audit lỗi ở đâu?

Nếu sai, bạn muốn biết do OCR đọc sai tên, detect ảnh thiếu, hay model ghép nhầm vì layout lạ? Nếu dùng một model làm hết, lỗi thường thành một cục bê tông: nhìn thấy nứt nhưng không biết nứt từ móng hay từ trần.

4. Volume có đủ lớn để tối ưu chi phí không?

Với vài trăm trang/tháng, đơn giản có thể thắng. Với hàng chục nghìn trang, mỗi token vision đắt sẽ bắt đầu đau. Đây là lúc tách stage có ý nghĩa.

5. Team có đủ sức vận hành không?

Pipeline hai model cần logging, retry, schema validation, versioning prompt, và regression set. Nếu team chỉ có một backend dev kiêm DevOps kiêm người trả lời Slack khách hàng, hãy tính thật tỉnh.

6. Quyền truy cập model nằm ở đâu?

Nếu công ty bạn có nhiều AWS account, việc model nào được gọi từ account nào không phải chuyện phụ. Managed entitlements trên Amazon Bedrock cho phép subscribe model từ account trung tâm rồi phân phối quyền dùng cho các account khác qua AWS License Manager. Với team nhỏ, có thể chưa cần. Với tổ chức nhiều account, đây là phần governance nên quyết trước khi pipeline mọc khắp nơi.

Playbook triển khai: tách theo năng lực, không tách theo cảm hứng

Hình dung thế này: bạn có một tập PDF scan hồ sơ cũ, trong đó có ảnh, tên người, mã hồ sơ và vài dòng ghi chú. Mục tiêu là tạo bản ghi có cấu trúc để search và kiểm tra thủ công khi confidence thấp.

Bước 1: Tạo “bộ mẫu xấu” trước khi tạo prompt hay

Lấy 30-50 trang đại diện, nhưng đừng chỉ chọn trang đẹp. Cần có:

scan nghiêng;
chữ mờ;
nhiều cột;
ảnh sát nhau;
tên bị xuống dòng;
trang có noise hoặc dấu mộc che chữ;
trang đã có text layer và trang chỉ là ảnh.

Nếu tài liệu chủ yếu là PDF scan thuần text, chạy thử OCRmyPDF để tạo searchable PDF và sidecar text — file text đi kèm để downstream dễ đọc. Đây là baseline rẻ và dễ kiểm tra. Nếu baseline đã đạt yêu cầu, đừng kéo vision model vào chỉ vì nó mới hơn.

Bước 2: Stage 1 chỉ được phép “nhìn và trích xuất”

Stage 1 nên trả dữ liệu thô có tọa độ, không suy luận quá nhiều:

{
  "page": 12,
  "images": [
    {"id": "img_1", "box": [120, 80, 260, 240], "type": "portrait"}
  ],
  "texts": [
    {"id": "txt_9", "text": "Nguyen Van An", "box": [118, 250, 270, 280]}
  ],
  "metadata": {
    "layout": "multi_column",
    "rotation_detected": false
  }
}

Ở bước này, model như Nova 2 Lite trong ví dụ AWS hợp lý vì nhiệm vụ chính là native multimodal extraction — trích xuất trực tiếp từ ảnh và chữ trong cùng một lượt gọi. Bạn có thể thay bằng model khác, miễn nó trả được box và text đủ ổn.

Bước 3: Stage 2 mới được suy luận quan hệ

Stage 2 nhận JSON từ stage 1, không cần nhìn lại toàn bộ ảnh nếu không bắt buộc. Việc của nó là quyết định:

text nào thuộc image nào;
confidence bao nhiêu;
lý do ghép là gì;
trường hợp nào cần review thủ công.

Đây là nơi model mạnh hơn như Claude có đất diễn, vì spatial reasoning — suy luận dựa trên vị trí — cần hiểu layout chứ không chỉ đọc chữ.

Prompt nên ép model trả lý do ngắn, không văn chương:

Given detected portrait boxes and text boxes, associate each portrait with the most likely name.
Return JSON only.
If layout is ambiguous, set confidence below 0.8 and explain briefly.
Do not invent names that are not present in text boxes.

Bước 4: Chặn lỗi bằng schema và ngưỡng review

Đừng để output model đi thẳng vào database production. Tối thiểu cần:

JSON schema validation;
kiểm tra box có nằm trong page boundary không;
kiểm tra name có xuất hiện trong text list không;
confidence threshold để đưa vào hàng review;
lưu raw input/output theo version prompt.

Ví dụ cụ thể: giả sử team bạn xử lý hồ sơ nhân sự scan. Nếu model ghép nhầm ảnh với tên, hậu quả không chỉ là search sai; có thể kéo theo quyền truy cập, xác minh danh tính, hoặc báo cáo nội bộ sai. Với loại dữ liệu này, confidence cao vẫn không thay thế được sampling review.

Bẫy hay gặp: tối ưu model nhưng bỏ quên contract

Builder rất dễ bị cuốn vào câu hỏi “model A hay model B?”. Nhưng trong pipeline tài liệu, thứ giữ hệ thống đứng vững là contract giữa các stage.

Contract ở đây là thỏa thuận máy đọc được: stage trước phải trả field nào, kiểu dữ liệu gì, tọa độ theo hệ nào, confidence tính thế nào, lỗi được biểu diễn ra sao. Không có contract, mỗi lần đổi model là mỗi lần đập tường sửa nhà.

Một vài lỗi mình sẽ soi rất kỹ khi review thiết kế:

Tọa độ không chuẩn hóa: model trả pixel theo ảnh đã resize, stage sau tưởng là ảnh gốc.
Confidence không có nghĩa vận hành: 0.95 nhưng không biết dùng để auto-approve hay chỉ để xếp hàng review.
Không có negative case: prompt chỉ test trang đẹp, không test trang không có ảnh hoặc tên bị thiếu.
Không log intermediate output: sai ở stage cuối nhưng không truy được stage đầu đã nhìn thấy gì.
Governance để sau: dev account gọi được model, production account lại thiếu entitlement hoặc bị chặn region.

Nguồn PyGraphistry về graph investigation gợi thêm một ý hay: khi pipeline bắt đầu nhiều entity và quan hệ, đôi khi bạn cần visualization để điều tra lỗi. Không nhất thiết dựng graph hoành tráng, nhưng với các cặp document → page → box → entity → decision, một view quan hệ đơn giản có thể giúp tìm pattern sai nhanh hơn log tuyến tính.

Nếu là mình, mình sẽ chọn thế nào?

Với team builder ở Việt Nam, mình sẽ chia quyết định như sau:

Chọn một model làm hết nếu bạn đang ở giai đoạn proof-of-concept, dưới vài nghìn trang, tài liệu thay đổi liên tục, và chi phí chưa phải nút thắt. Mục tiêu lúc này là học bài toán, không phải xây lâu đài.

Chọn OCR trước, LLM sau nếu tài liệu chủ yếu là chữ, layout không quá quan trọng, và bạn cần searchable archive. OCRmyPDF là một baseline đáng thử vì nó tạo PDF/A, sidecar text và hỗ trợ batch processing. Dùng baseline rẻ trước giúp bạn biết phần nào thật sự cần AI.

Chọn pipeline hai model nếu tài liệu có ảnh, box, layout, quan hệ không gian, và volume đủ lớn để chi phí mỗi trang thành vấn đề. Khi đó, hãy để model rẻ hơn làm phần trích xuất ổn định, model mạnh hơn làm phần suy luận khó.

Đổi quyết định khi một trong ba điều xảy ra:

Chi phí vision/token vượt ngân sách vận hành.
Lỗi không debug được vì output quá nguyên khối.
Governance nhiều account bắt đầu làm chậm rollout.

Sau bài này, điều mình muốn bạn nghĩ khác là: model mạnh nhất không nhất thiết là móng tốt nhất cho pipeline tài liệu. Móng tốt là phần chia việc rõ, contract chắc, và biết chỗ nào cần người kiểm tra.

AI đọc tài liệu giỏi thật, nhưng đừng bắt nó vừa xây nhà vừa tự cấp sổ hồng.

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