OCR hóa đơn, hợp đồng bằng Document AI: kiến trúc triển khai thực tế

Document AI khác OCR thông thường ở đâu?

OCR nhận diện ký tự từ ảnh hoặc PDF. Nhưng một hóa đơn còn có bên bán, số chứng từ, ngày, thuế, tổng tiền và nhiều dòng hàng; một hợp đồng có bên tham gia, mốc thời gian, điều khoản và phụ lục. Nếu chỉ trả về một khối văn bản phẳng, hệ thống phía sau vẫn chưa biết trường nào cần ghi vào đâu và nhân viên vẫn phải đọc lại gần như toàn bộ tài liệu.

Document AI bổ sung nhận biết bố cục, bảng, cặp khóa–giá trị, phân loại tài liệu và trích xuất theo schema. Google Cloud mô tả Invoice Parser có thể lấy số hóa đơn, nhà cung cấp, số tiền, thuế, ngày và dòng hàng; công cụ layout parser giữ bảng, danh sách và tiêu đề thay vì làm phẳng tài liệu. Vì vậy bài toán triển khai phải bắt đầu từ dữ liệu đầu ra mà quy trình cần, không phải từ việc chọn một dịch vụ OCR trước.

• ✓OCR: ký tự, tọa độ và đôi khi là chất lượng nhận diện.
• ✓Document understanding: loại tài liệu, cấu trúc, bảng và trường nghiệp vụ.
• ✓Workflow: chuẩn hóa, đối chiếu, duyệt, ghi hệ thống và audit trail.
• ✓Kết quả tốt phải truy ngược được về tài liệu và vị trí nguồn.

Mục tiêu của Document AI không phải đọc được một PDF. Mục tiêu là tạo ra dữ liệu đủ tin cậy, có thể kiểm tra và đưa vào đúng quy trình.

Kiến trúc từ file đầu vào đến dữ liệu đã duyệt

Một pipeline thực tế bắt đầu bằng kênh nhận file có kiểm soát: upload, email, thư mục đồng bộ hoặc API. Hệ thống kiểm tra định dạng, kích thước, mã độc, trùng lặp và chất lượng scan trước khi phân loại tài liệu. OCR hoặc mô hình layout sau đó tạo text, bảng và vị trí; lớp extraction ánh xạ kết quả vào schema thống nhất như supplier_name, invoice_number, total_amount hoặc contract_expiry_date.

Sau extraction là lớp validation: kiểu dữ liệu, trường bắt buộc, tổng dòng hàng so với tổng hóa đơn, mã nhà cung cấp trong master data và quy tắc nghiệp vụ. Trường thiếu, mâu thuẫn hoặc dưới ngưỡng tin cậy được đưa vào hàng đợi human review cùng ảnh cắt vùng nguồn. Chỉ bản ghi đã duyệt mới đi qua lớp tích hợp tới ERP, CRM, DMS hoặc workflow automation; mọi lần sửa, duyệt và gửi lại cần có log để đối soát.

• ✓01. Ingestion, kiểm tra file, bảo mật và chống xử lý trùng.
• ✓02. Phân loại, OCR, layout và trích xuất theo schema.
• ✓03. Chuẩn hóa, validation, confidence và đối chiếu dữ liệu nguồn.
• ✓04. Human review cho ngoại lệ và trường có hậu quả cao.
• ✓05. Tích hợp có idempotency, audit log, monitoring và cơ chế xử lý lại.

Chọn mô hình theo loại tài liệu và mức biến thiên

Hóa đơn phổ biến có thể bắt đầu bằng prebuilt invoice processor. Microsoft Azure Document Intelligence mô tả invoice model dùng OCR để lấy trường và dòng hàng từ hóa đơn, hóa đơn tiện ích, đơn mua hàng và trả kết quả có cấu trúc. AWS Textract AnalyzeExpense cũng chuẩn hóa những nhãn khác nhau về cùng taxonomy, đồng thời trả confidence và geometry. Các khả năng này giúp rút ngắn pilot nhưng không thay thế việc kiểm tra trên mẫu thật của doanh nghiệp.

Hợp đồng và tài liệu nội bộ thường biến thiên hơn, có bảng dài, phụ lục, điều khoản trải nhiều trang và ngôn ngữ khác nhau. Khi prebuilt model không khớp schema, có thể kết hợp layout parser, quy tắc, mô hình trích xuất tùy chỉnh hoặc LLM với structured output. Quyết định cần dựa trên test set, chi phí trên tài liệu, độ trễ, yêu cầu lưu trú dữ liệu và khả năng giải thích vị trí nguồn; không nên dùng một model cho mọi loại file chỉ để đơn giản hóa sơ đồ.

• ✓Độ ổn định của template và số loại tài liệu.
• ✓Ngôn ngữ, chữ viết tay, ảnh nghiêng, mờ hoặc nhiều trang.
• ✓Số trường, bảng, quan hệ giữa trường và quy tắc đối chiếu.
• ✓Yêu cầu riêng tư, lưu trú dữ liệu, độ trễ và ngân sách mỗi tài liệu.

Đo chất lượng theo trường và thiết kế human review

Một tỷ lệ chính xác chung có thể che giấu lỗi quan trọng. Sai một ký tự trong mã số thuế, tài khoản, số tiền hoặc ngày hết hạn có hậu quả khác với sai dấu câu trong ghi chú. Bộ đánh giá nên chia theo loại tài liệu, nhà cung cấp, chất lượng scan và từng trường; theo dõi precision, recall hoặc exact match phù hợp, tỷ lệ tài liệu đi thẳng, tỷ lệ ngoại lệ và thời gian người duyệt.

Ngưỡng tự động không nên chỉ dựa vào confidence do nhà cung cấp trả về. Confidence cần được hiệu chỉnh với dữ liệu thực và kết hợp quy tắc nghiệp vụ. Màn hình review phải đưa người dùng thẳng tới vùng nguồn, làm nổi bật giá trị nghi vấn, cho phép sửa nhanh và lưu lý do. Những chỉnh sửa này tạo dữ liệu đánh giá cho phiên bản sau, nhưng chỉ nên dùng để huấn luyện khi đã có chính sách đồng ý, làm sạch và kiểm soát truy cập phù hợp.

• ✓Field accuracy cho từng trường quan trọng và từng nhóm tài liệu.
• ✓Straight-through processing: tỷ lệ tài liệu không cần người chạm vào.
• ✓Exception rate, thời gian xử lý và số lần phải làm lại.
• ✓Chi phí trên bản ghi đã được chấp nhận, không chỉ trên trang OCR.

Thiết kế pilot Document AI trong 3–6 tuần

Một pilot nên giới hạn ở một loại tài liệu, một hệ thống đích và nhóm trường tạo giá trị rõ. Tuần đầu chốt schema, lấy mẫu đại diện, ẩn dữ liệu không cần thiết và đo baseline nhập liệu hiện tại. Các tuần tiếp theo xây pipeline, màn hình review và bộ đánh giá; giai đoạn cuối chạy song song với quy trình cũ để đo chất lượng, thời gian, ngoại lệ và chi phí mà chưa tự động ghi dữ liệu nhạy cảm vào production.

Friday Works chỉ đề xuất mở rộng khi pilot đạt ngưỡng đã thống nhất và có người sở hữu vận hành. Bàn giao tùy phạm vi gồm data map, schema, mã nguồn, cấu hình processor, test set, báo cáo field-level, API contract, dashboard và runbook. Nếu mẫu quá biến thiên hoặc tỷ lệ review khiến lợi ích không đủ, kết luận đúng có thể là thu hẹp loại tài liệu, đổi quy trình hoặc dừng thay vì tự động hóa bằng mọi giá.

• ✓Tuần 1: mẫu đại diện, schema, baseline, quyền và tiêu chí chấp nhận.
• ✓Tuần 2–4: ingestion, extraction, validation, review và tích hợp thử nghiệm.
• ✓Tuần 5–6: chạy song song, đo lường, xử lý ngoại lệ và quyết định mở rộng.
• ✓Không tự động post dữ liệu độ chắc chắn thấp hoặc hành động khó đảo ngược.