Đừng gọi xác minh thu nhập là OCR

Xác minh thu nhập không thua ở model. Nó thua ở hợp đồng dữ liệu, ngưỡng tự động duyệt và khả năng gom chứng cứ khi tài liệu bẩn.

Bụi Wire

2026-07-30

“Team mình chỉ cần OCR bảng lương rồi hỏi model có đủ điều kiện vay không, đúng không?”

Câu này nghe quen tới mức mình muốn dựng một cái chuông nhỏ trên bàn: mỗi lần ai nói “chỉ cần OCR” là ting một phát. Không phải để chê, mà để nhắc rằng nhiều hệ thống AI trong tài chính chết không phải vì model kém thông minh, mà vì đầu vào không có kỷ luật.

Niềm tin phổ biến là: công cụ document parsing càng xịn, model càng mới, workflow xác minh thu nhập càng tự động. Nghe hợp lý. Nhưng nhìn kỹ vào bài toán income verification của LlamaIndex, cộng thêm hướng LiteParse mở gRPC server và cách pplx CLI thiết kế contract cho coding agent, mình thấy điểm đáng bàn nằm ở chỗ khác: builder nên thiết kế xác minh thu nhập như một hệ thống kiểm chứng có bằng chứng, không phải một pipeline đọc chữ.

Nói thẳng ra thì: đừng hỏi “parser nào đọc PDF tốt nhất?” trước. Hãy hỏi “khi parser đọc sai, hệ thống của mình biết dừng ở đâu chưa?”

Sơ đồ minh họa cho bài Đừng gọi xác minh thu nhập là OCR

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

Thứ đang diễn ra: document AI đang rời khỏi demo đẹp

Xác minh thu nhập là bài toán rất đời: duyệt khoản vay, thuê nhà, mortgage underwriting, xét quyền lợi. Nhưng dữ liệu thì không đời chút nào. Một hồ sơ có thể gồm payslip, bank statement, tax form, thư xác nhận việc làm, ảnh chụp màn hình app ngân hàng, file scan nghiêng, bảng lương song ngữ, hoặc PDF có table vỡ hàng.

Trong ngữ cảnh này, document parsing là bước biến tài liệu không cấu trúc thành dữ liệu có thể xử lý: text, bảng, trường thông tin, metadata. LlamaIndex đang đẩy mạnh hướng API hóa luồng income verification: parse, extract, index, rồi kiểm tra income dựa trên tài liệu. LiteParse thì đi theo lớp hạ tầng thấp hơn: thư viện Rust parse PDF, Office file, image, có bindings cho Node.js, Python, WebAssembly, và giờ thêm gRPC server.

gRPC là giao thức gọi service hiệu năng cao, thường dùng nội bộ giữa các service. Điểm hay ở đây không phải “ồ, có thêm protocol”. Điểm hay là parsing đang được kéo ra thành một service có contract rõ, thay vì nằm lẫn trong đống script backend.

Cùng lúc, pplx CLI của Perplexity lại đưa một tín hiệu khác: tool cho agent không nhất thiết phải là chat. Nó có hai bề mặt rất hẹp: search web và fetch content, trả JSON, dùng exit code để báo thành công/thất bại, stdout cho kết quả, stderr cho lỗi. Đây là kiểu kỷ luật mà hệ thống tài chính rất cần.

Trong dojo, đai trắng thường ham đá cao. Đai đen biết thế thủ quan trọng hơn cú đẹp. Với document AI cũng vậy: demo đọc được một file mẫu là cú đá đẹp; production cần thế thủ khi file xấu, thiếu, giả, hoặc mâu thuẫn.

Mổ xẻ: xác minh thu nhập cần bốn lớp, không phải một model

Nếu bạn đang build hệ thống này cho ngân hàng số, fintech, insurtech, nền tảng cho thuê, hoặc back-office tài chính, mình sẽ tách bài toán thành bốn lớp.

1. Lớp nhập tài liệu: file nào được vào võ đường?

Đừng cho mọi file đi thẳng vào model. Trước khi parse, hệ thống cần kiểm tra:

loại file có hỗ trợ không;
file có bị khóa, quá mờ, quá nặng, thiếu trang không;
tài liệu thuộc nhóm nào: payslip, bank statement, tax form, employment letter;
thông tin định danh có khớp người nộp không.

Ví dụ cụ thể: một user upload ba file: bảng lương tháng 5, sao kê ngân hàng tháng 6, và ảnh chụp màn hình chuyển khoản lương. Nếu pipeline chỉ extract số tiền cao nhất rồi kết luận “income đủ”, bạn đang để hệ thống tự chọn bằng chứng có lợi nhất. Trong tài chính, đó là đường ngắn dẫn tới rủi ro.

2. Lớp trích xuất: schema trước, prompt sau

Schema là khuôn dữ liệu mà hệ thống yêu cầu trả về. Với income verification, schema không nên chỉ có monthly_income. Nó nên có cả:

{
  "applicant_name": "...",
  "employer_name": "...",
  "pay_period": "...",
  "gross_income": "...",
  "net_income": "...",
  "currency": "...",
  "document_type": "...",
  "evidence_spans": ["..."]
}

Trường evidence_spans rất quan trọng: nó lưu đoạn bằng chứng trong tài liệu dẫn tới kết luận. Evidence ở đây là dấu vết kiểm chứng, giống như trọng tài cần thấy đòn chạm đích chứ không nghe võ sinh kể rằng mình đã đánh trúng.

Không có evidence, bạn chỉ có một câu trả lời. Có evidence, bạn có cơ sở để audit, debug và chuyển hồ sơ cho người xử lý khi cần.

3. Lớp đối chiếu: một con số chưa phải sự thật

Income verification khó vì income không nằm trong một ô Excel sạch sẽ. Gross income khác net income. Lương cố định khác bonus. Sao kê ngân hàng có thể có nhiều khoản chuyển vào. Payslip có thể ghi kỳ lương hai tuần, không phải một tháng.

Vì vậy hệ thống cần reconciliation — đối chiếu nhiều nguồn để tìm kết luận nhất quán. Nếu payslip nói net income là X, bank statement phải có khoản tiền tương ứng trong khoảng thời gian hợp lý. Nếu employment letter ghi mức lương năm, hệ thống cần quy đổi kỳ lương và ghi rõ giả định.

Đây là chỗ nhiều team hiểu sai về “accuracy”. Accuracy của parser chỉ là một phần. Accuracy của quyết định còn phụ thuộc vào rule, đối chiếu, ngưỡng tin cậy và chính sách fallback.

4. Lớp quyết định: STP không phải mục tiêu tuyệt đối

Straight-through processing, viết tắt STP, là tỷ lệ hồ sơ được xử lý tự động từ đầu tới cuối mà không cần người can thiệp. Trong bài toán tài chính, STP nghe rất hấp dẫn vì giảm thao tác tay. Nhưng STP cao bằng mọi giá là nguy hiểm.

Bạn cần một STP threshold — ngưỡng cho phép tự động duyệt hoặc tự động từ chối. Dưới ngưỡng đó, hồ sơ nên chuyển sang human review. Không phải vì AI “dở”, mà vì chi phí của quyết định sai có thể lớn hơn chi phí review.

Giả sử đây là ví dụ minh họa: team bạn đặt rule rằng chỉ tự động xác minh khi ba điều kiện cùng đúng: tên khớp, kỳ lương khớp, và ít nhất hai tài liệu độc lập xác nhận cùng một mức thu nhập trong biên độ cho phép. Nếu thiếu một điều kiện, hệ thống không cố đoán; nó trả về trạng thái needs_review kèm lý do.

Đó mới là automation có trách nhiệm.

Điều đáng giữ: contract nhỏ, output sạch, lỗi có hình dạng

Mình thích nhất ở tín hiệu từ LiteParse gRPC và pplx CLI là tinh thần contract-first: tool không cố làm tất cả, nhưng nói rất rõ nó nhận gì, trả gì, lỗi ra sao.

Với builder, đây là framework quyết định khá thực dụng:

| Câu hỏi thiết kế | Nếu trả lời mơ hồ | Nên khóa lại thành contract |
|---|---|---|
| Parser trả gì? | Text dài, bảng lẫn lộn | JSON theo schema version |
| Lỗi nằm đâu? | Log rải rác | Error object có code, message, hint |
| Bằng chứng ở đâu? | Model nói “theo tài liệu” | Evidence spans hoặc page references |
| Khi không chắc thì sao? | Model vẫn kết luận | Trạng thái needs_review |
| Agent đọc bao nhiêu? | Nhồi toàn bộ tài liệu | Token budgeting và preview có giới hạn |

Token budgeting là kiểm soát lượng nội dung đưa vào model để tránh tốn chi phí và tràn ngữ cảnh. Với tài liệu dài, bạn không muốn agent nuốt cả bộ sao kê rồi lạc trong đó. Bạn muốn full result được lưu ở file hoặc storage, còn stdout chỉ trả preview đủ để bước tiếp theo quyết định có cần đọc sâu không.

pplx CLI làm khá rõ tinh thần này: kết quả machine-readable, lỗi machine-readable, không giả vờ thành chatbot. Với hệ thống income verification, mình sẽ học đúng phần đó: tool càng gần production càng nên ít màu mè, nhiều hợp đồng.

Điều nên bỏ qua: cuộc đua “model nào đọc giấy tờ hay hơn”

Có ba thứ mình sẽ không lấy làm trung tâm quyết định.

Thứ nhất, đừng chọn stack chỉ vì một demo đọc PDF trông sạch. Demo thường chọn tài liệu đẹp. Production gặp scan lệch, bảng bị cắt, watermark, dấu mộc, chữ ký, file ghép từ nhiều nguồn.

Thứ hai, đừng để model tự đưa ra chính sách tín dụng. Model có thể extract và giải thích, nhưng quyết định tài chính cần rule, audit trail và trách nhiệm rõ. Nếu policy nói không tính bonus chưa ổn định, model không được tự “linh hoạt” vì câu chữ trong thư xác nhận nghe thuyết phục.

Thứ ba, đừng gom fraud detection vào một prompt khổng lồ. Fraud detection trong bối cảnh này là phát hiện dấu hiệu giả mạo hoặc mâu thuẫn: tên không khớp, font bất thường, số tiền không ăn với sao kê, metadata đáng ngờ, mẫu tài liệu lạ. Một phần có thể dùng model, nhưng phần còn lại nên là rule, checksum, kiểm tra nguồn, và review.

Đai đen không thắng vì thuộc nhiều chiêu hơn, mà vì biết lúc nào không nên ra đòn. Hệ thống AI tài chính cũng vậy: đôi khi quyết định đúng nhất là dừng lại và yêu cầu thêm bằng chứng.

Khung nghĩ mới cho builder: build “verification harness”

Sau bài này, mình muốn bạn đổi một câu hỏi.

Thay vì hỏi: “Dùng API nào để tự động xác minh thu nhập?”

Hãy hỏi: “Mình đã có verification harness chưa?”

Verification harness là lớp bao quanh model và parser để kiểm tra đầu vào, chuẩn hóa output, đối chiếu bằng chứng, chấm độ tin cậy, và quyết định tự động hay chuyển người.

Một buổi chiều, bạn có thể phác thảo bản đầu tiên như sau:

Chọn ba loại tài liệu thật mà team hay gặp nhất: payslip, bank statement, tax form.
Viết schema extraction có trường evidence và confidence.
Tạo năm case lỗi: thiếu trang, tên không khớp, kỳ lương lệch, số tiền mâu thuẫn, ảnh mờ.
Quy định ba trạng thái duy nhất: verified, rejected, needs_review.
Log mọi quyết định kèm tài liệu, rule đã chạy, và bằng chứng được dùng.

Nếu parser đổi, model đổi, hoặc API đổi, harness này vẫn là thứ giữ hệ thống đứng vững. Còn nếu không có nó, bạn chỉ đang đưa võ sinh mới lên sàn đối luyện mà chưa dạy thế thủ.

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