Độ chính xác AI-OCR: PoC và nghiệm thu chứng từ đa ngôn ngữ

Không thể so sánh độ chính xác AI-OCR một cách đáng tin cậy chỉ bằng một “tỷ lệ nhận dạng” do nhà cung cấp công bố. Kết quả trên bộ dữ liệu của nhà cung cấp không cho biết hệ thống sẽ xử lý thế nào với chứng từ tiếng Nhật, tiếng Anh, tiếng Thái và tiếng Việt của doanh nghiệp, đặc biệt khi có ngày tháng, tiền tệ, mã số thuế, dòng chi tiết, ghi chú viết tay hoặc bản quét chất lượng thấp. Bài viết này trình bày cách triển khai AI-OCR từ PoC đến nghiệm thu bằng precision, recall và F1 ở cấp trường; exact match cho trường trọng yếu; document exact match; tỷ lệ xử lý thẳng STP; lỗi trọng yếu lọt khỏi khâu kiểm tra; tỷ lệ xử lý thất bại; tính lặp lại; và sai khác khi đổi phiên bản.

Mục tiêu thực tế không phải là tìm sản phẩm có con số quảng cáo cao nhất. Mục tiêu là lập một hợp đồng đo lường, trong đó xác định chứng từ nào được tự động đi tiếp, chứng từ nào phải do con người kiểm tra, và cần bằng chứng gì trước khi chấp nhận đưa vào vận hành.

Vì sao một tỷ lệ nhận dạng không đủ để so sánh độ chính xác OCR

“OCR nhận dạng 99%” nghe có vẻ chính xác, nhưng chưa thể so sánh nếu không biết mẫu số, quy tắc khớp, tập dữ liệu, bước tiền xử lý và điều kiện loại trừ. Tỷ lệ được tính theo ký tự, từ, trường hay cả chứng từ? Trường tùy chọn để trống có được tính là đúng không? Dòng chi tiết lặp lại được căn chỉnh như thế nào? Ảnh không đọc được và lỗi API có bị loại khỏi mẫu số không? Những định nghĩa khác nhau có thể tạo ra kết quả rất khác từ cùng một đầu ra.

Tác động nghiệp vụ cũng khác nhau theo từng trường. Thiếu một dấu câu trong ghi chú không có mức rủi ro giống với sai tài khoản thụ hưởng, mã số thuế, loại tiền, tổng tiền hoặc dấu thập phân. Mục tiêu của OCR chứng từ không chỉ là tạo văn bản, mà là rút ngắn đăng ký, đối soát, phê duyệt, thanh toán và kiểm toán mà không làm suy yếu kiểm soát. Vì vậy thiết kế đánh giá phải xuất phát từ chi phí lỗi và rủi ro của quy trình.

Tài liệu đánh giá chính thức của Google Document AI giải thích precision, recall, F1 và confidence threshold, đồng thời cho thấy precision và recall hữu ích với trường tùy chọn và dòng chi tiết lặp lại. Tài liệu minh bạch của Microsoft Document Intelligence nhấn mạnh đánh giá theo mục đích sử dụng, xử lý dựa trên confidence và vai trò kiểm tra của con người. Amazon Textract thể hiện confidence trong khoảng 0–100, trong khi một số dịch vụ khác dùng 0–1. Không được xem điểm thô là xác suất chuẩn dùng chung giữa các nhà cung cấp, vì calibration thay đổi theo mô hình, processor, phiên bản và tập dữ liệu.

8 chỉ số để đo độ chính xác OCR chứng từ

Nghiệm thu nên tính ít nhất các chỉ số dưới đây trên cùng một bộ kiểm thử đã được đóng băng. Chỉ dùng một chỉ số có thể che giấu lỗi nghiêm trọng ở phần khác của quy trình.

Precision được tính bằng TP ÷ (TP + FP), recall bằng TP ÷ (TP + FN). TP là trường được trích xuất đúng. FP là giá trị không tồn tại hoặc giá trị sai nhưng được hệ thống xuất như một kết quả hợp lệ. FN là giá trị có trong ground truth nhưng bị bỏ sót. F1 bằng 2 × precision × recall ÷ (precision + recall).

Cần đóng băng quy tắc đếm trước khi chạy. Nếu một trường tùy chọn không tồn tại trong ground truth và hệ thống cũng không xuất ra, đó là true negative. Bài toán trích xuất có thể có rất nhiều true negative, nên đưa chúng vào accuracy đơn giản sẽ làm tỷ lệ cao một cách giả tạo. Precision và recall cho thấy cả trường được tạo sai lẫn dòng chi tiết bị bỏ sót mà không để số lượng ô trống chi phối kết quả.

Xây dựng bộ kiểm thử phân tầng cho PoC AI-OCR

Bộ PoC phải đại diện điều kiện vận hành thật, không chỉ gồm chứng từ dễ thu thập. Kết quả trên PDF số sạch có thể giảm mạnh khi triển khai gặp ảnh từ máy photocopy, điện thoại, quy trình fax hoặc tệp đính kèm đã nén.

Phân tầng theo ngôn ngữ, loại chứng từ và chất lượng ảnh

Lập bản đồ đầu vào theo ngôn ngữ, loại chứng từ, nhà cung cấp, biểu mẫu, kênh tiếp nhận, chất lượng ảnh, chữ viết tay, con dấu và số trang. Số lượng hóa đơn tiếng Nhật lớn không được che khuất lỗi ở chứng từ thuế tiếng Thái hoặc chứng từ nhà cung cấp Việt Nam ít hơn nhưng rủi ro cao. Nên duy trì một tập theo đúng tỷ trọng sản xuất và một challenge set chủ động tăng các trường hợp hiếm hoặc có tác động lớn.

Chia chất lượng thành ít nhất good, medium và poor; gắn nhãn lệch, mờ, bóng, nếp gấp, thấu chữ, nhiễu nén, chữ nhạt, nền hoa văn, cắt mất mép và xoay trang. Hướng dẫn của AWS coi chất lượng ảnh là yếu tố ảnh hưởng đáng kể và khuyến nghị xử lý confidence theo độ nhạy của use case. Nhãn chất lượng biến ảnh hưởng này thành số liệu có thể kiểm chứng.

Tách dữ liệu tinh chỉnh khỏi acceptance holdout

Nhóm triển khai có thể xem development set khi điều chỉnh preprocessing, schema, template hoặc prompt. Acceptance holdout phải được giữ kín cho đến khi cấu hình đã đóng băng. Dùng cùng chứng từ để tinh chỉnh và nghiệm thu sẽ biến việc nhớ biểu mẫu thành một cải thiện có vẻ tổng quát. Tệp trùng, ảnh quét lại từ cùng bản gốc và chứng từ số liên tiếp từ một mẫu phải ở cùng một phía của phép chia dữ liệu.

Kiểm toán ground truth

Ground truth cũng có thể sai. Dấu thanh tiếng Thái, dấu tiếng Việt, dạng ký tự toàn chiều rộng và nửa chiều rộng của tiếng Nhật, dấu phân cách mã số thuế, cũng như 0/O và 1/I dễ gây bất đồng giữa người gắn nhãn. Trường trọng yếu nên được hai người nhập độc lập và xử lý bất đồng; trường thông thường được kiểm tra theo mẫu; đồng thời lưu người nhập, người duyệt và lịch sử sửa.

Không loại chứng từ thất bại khỏi mẫu số

Timeout, phản hồi rỗng, PDF mã hóa, vượt giới hạn trang, tệp bị coi là hỏng và lỗi API phải được giữ trong báo cáo. “Đúng 96% trên số đã xử lý” chưa đầy đủ nếu 5% khối lượng không thể mở. Hãy tách lỗi lần đầu, trường hợp phục hồi sau retry, lỗi vĩnh viễn và chuyển sang xử lý thủ công.

Quy tắc chuẩn hóa cho tiếng Nhật, Anh, Thái và Việt

Độ chính xác OCR phụ thuộc vào việc so sánh văn bản thô hay giá trị nghiệp vụ đã chuẩn hóa. Chuẩn hóa là hợp lệ khi ánh xạ các cách biểu diễn tương đương về một dạng đã công bố. Nó trở nên sai lệch nếu âm thầm sửa lỗi của mô hình hoặc xóa khác biệt có ý nghĩa.

Unicode Standard Annex #15 định nghĩa canonical equivalence và các normalization form. NFC có thể là nền tảng thực tế, nhưng không nên áp dụng NFKC cho mọi trường khi chưa phê duyệt riêng, vì compatibility normalization có thể thay đổi một số phân biệt. Hãy lưu ảnh nguồn, đầu ra OCR thô và giá trị sau chuẩn hóa để mọi phép biến đổi đều truy vết được.

Với trang trộn nhiều ngôn ngữ, hãy lưu ngôn ngữ của từng trường cùng với ngôn ngữ chính của chứng từ. Địa chỉ tiếng Thái trên biểu mẫu tiếng Anh không nên bị chìm trong trung bình của chứng từ tiếng Anh. Thông tin công khai của Microsoft bao gồm tiếng Thái và tiếng Việt trong các ngôn ngữ OCR được hỗ trợ, nhưng mô hình, tính năng, khu vực, phiên bản API và trạng thái preview hoặc general availability có thể thay đổi. Các nguồn trong bài được tham chiếu ngày 26 tháng 8 năm 2026; cần kiểm tra thông số chính thức hiện hành bằng đầu vào thực tế trước khi mua.

Dùng exact match và quy tắc nghiệp vụ cho trường trọng yếu

Độ giống ký tự không đủ cho tiền hoặc định danh. 1,000.00 và 10,000.00 gần nhau về chuỗi nhưng khác biệt rất lớn trong thanh toán. Trường critical nên dùng exact match sau chuẩn hóa được phê duyệt, kết hợp các kiểm soát như:

• tổng dòng cộng thuế bằng tổng chứng từ;
• ký hiệu tiền tệ nhất quán với mã tiền;
• mã số thuế và số đăng ký thỏa độ dài hoặc checksum đã quy định;
• ngày hóa đơn và ngày đến hạn có quan hệ hợp lý;
• số đơn mua tồn tại trong tập ứng viên ERP;
• danh tính nhà cung cấp và tài khoản đăng ký khớp master data.

Khả năng phát hiện của quy tắc phải báo cáo riêng với độ đúng của OCR. Nếu đối chiếu master data chặn được tài khoản sai, kiểm soát đã có hiệu quả nhưng kết quả OCR vẫn sai. Tách “OCR đúng”, “quy tắc phát hiện” và “con người sửa” để biết nên đầu tư vào đâu.

Chọn confidence threshold bằng đo lường theo mức trọng yếu

Confidence không đảm bảo xác suất câu trả lời đúng. Cần đo quan hệ giữa điểm và độ đúng quan sát được trên chính chứng từ dự kiến sử dụng. Lập bảng calibration theo dải điểm, rồi phân tích theo ngôn ngữ, loại chứng từ, chất lượng ảnh và criticality. Một điểm đáng tin cậy trên biểu mẫu tiếng Anh sạch có thể hoạt động khác trên bản quét tiếng Thái kém chất lượng.

Không nên tìm một “threshold chuẩn ngành” duy nhất. Hãy chọn từ chi phí lỗi và năng lực của nhóm review. Tài khoản thụ hưởng hoặc tổng tiền có thể cần threshold cao, quy tắc nghiệp vụ và người kiểm tra; trường ghi chú không được dùng tiếp có thể dùng threshold thấp hơn hoặc không cần trích xuất. Theo hướng dẫn đánh giá của Google, thay đổi confidence threshold làm thay đổi trade-off giữa precision và recall. Tăng threshold thường giảm số tự động đi tiếp và có thể tăng precision, nhưng recall và STP có thể giảm.

Quy trình thiết lập threshold

1. Phân trường thành critical, controlled và informational.
2. Quét các threshold ứng viên theo bước 0.01 hoặc khoảng phù hợp.
3. Tính lại precision, recall, F1, STP, leakage và khối lượng review tại mỗi mức.
4. Kiểm tra phân tầng kém nhất theo ngôn ngữ, loại chứng từ và chất lượng ảnh.
5. Đặt cạnh năng lực xử lý mỗi ngày và SLA.
6. Ghi threshold đã chọn, lý do, người phê duyệt và phiên bản mô hình.

Nếu chỉ kiểm toán trường hợp confidence thấp đã vào hàng review, đánh giá sẽ bị selection bias. Cần lấy mẫu ngẫu nhiên từ nhóm confidence cao đã tự động đi tiếp và lấy mẫu mục tiêu ở phân tầng rủi ro cao. Đây là cách để ước lượng critical-error leakage nằm ngoài hàng kiểm tra.

Ví dụ tính độ chính xác AI-OCR

Toàn bộ số liệu trong phần này là giả định minh họa cho cách tính. Đây không phải hiệu năng đo được của nhà cung cấp, không phải cam kết của TOMAS TECH và không phải dự báo lợi ích kinh doanh.

Giả sử bộ kiểm thử gồm bốn nhóm ngôn ngữ là Nhật, Anh, Thái và Việt; ba tầng chất lượng là good, medium và poor; mỗi ô có 100 chứng từ. Tổng là 4 × 3 × 100 = 1.200 chứng từ. Ground truth có 9.600 trường mục tiêu. Giả sử kết quả là TP 9.024, FP 216 và FN 576:

• Precision = 9.024 ÷ (9.024 + 216) = 97,66%
• Recall = 9.024 ÷ (9.024 + 576) = 94,00%
• F1 = 2 × 97,66% × 94,00% ÷ (97,66% + 94,00%) = 95,80% sau làm tròn

Nếu 3.480 trong 3.600 trường trọng yếu khớp hoàn toàn sau chuẩn hóa, critical-field exact match là 3.480 ÷ 3.600 = 96,67%. Nếu 684 chứng từ có tất cả trường bắt buộc đúng, document exact match là 684 ÷ 1.200 = 57,00%. Điều này cho thấy chỉ số cấp trường cao không đồng nghĩa phần lớn chứng từ hoàn toàn không cần sửa.

Nếu 870 chứng từ đi hết quy trình không cần người, STP là 870 ÷ 1.200 = 72,50%. Nếu 9 trong 870 chứng từ được tự động thông qua có ít nhất một lỗi trọng yếu, critical-error leakage là 9 ÷ 870 = 1,03%. Nếu 18 đầu vào không xử lý được, failure rate là 18 ÷ 1.200 = 1,50%. Nếu chạy lặp và 1.188 chứng từ cho đầu ra giống nhau, repeatability là 1.188 ÷ 1.200 = 99,00%.

Giả sử khi so phiên bản có 44 trong 9.600 trường thay đổi, version delta là 44 ÷ 9.600 = 0,46%; 31 thay đổi tốt hơn và 13 xấu đi, tổng đúng bằng 44. Số cải thiện nhiều hơn không tự động cho phép phát hành. Nếu 13 trường xấu đi tập trung ở tổng tiền hoặc mã số thuế, phiên bản mới vẫn có thể không được chấp nhận.

Biến tiêu chí nghiệm thu thành các gate độc lập

Với cùng giả định minh họa, đặt F1 tối thiểu 95,00%; critical exact match tối thiểu 99,50%; STP tối thiểu 70,00%; leakage không quá 0,20%; failure không quá 1,00%; và repeatability tối thiểu 99,00%.

Kết luận đúng không phải là “trung bình cao nên phê duyệt”, mà là tạm hoãn nghiệm thu, khắc phục rồi kiểm thử lại. Lỗi trường trọng yếu, leakage và failure vượt gate. Có thể chia việc khắc phục thành tiền xử lý ảnh xấu, threshold cho trường critical, đối chiếu master data, định tuyến review và retry khi lỗi. Sau đó chạy lại holdout đã đóng băng và bổ sung challenge case từ root cause.

Đưa tính lặp lại và regression giữa phiên bản vào nghiệm thu

Dịch vụ AI đám mây có thể cập nhật processor, mô hình, API và mặc định trong khi tên sản phẩm vẫn giữ nguyên. Cần xem nguồn chính thức như processor list của Google và trang What’s new của Microsoft, đồng thời ghi model ID, API version, region, cấu hình và mã preprocessing dùng trong mỗi phép thử. Không dựa vào trí nhớ về ngôn ngữ hỗ trợ hoặc trạng thái preview/general availability; hãy kiểm tra ngay trước quyết định mua hoặc phát hành.

Kiểm thử repeatability xử lý cùng tệp nhiều lần với cùng thiết lập rồi so giá trị thô, giá trị chuẩn hóa, confidence, hình học và căn chỉnh dòng. Tách khác biệt định dạng vô hại khỏi thay đổi giá trị nghiệp vụ critical. Khi đổi phiên bản, chạy cũ và mới song song trên cùng regression set và xem mọi changed case, không chỉ chỉ số tổng.

Gói bằng chứng tối thiểu nên có:

• mô hình, processor, phiên bản mô hình, phiên bản API và region;
• hash tệp, phiên bản test set và phiên bản ground truth;
• phiên bản preprocessing, normalization, schema, threshold và business rule;
• thời điểm chạy, retry, error response và thời lượng xử lý;
• số liệu tổng, số liệu phân tầng, danh sách thay đổi và hồ sơ phê duyệt.

NIST AI Risk Management Framework xem đo lường, giám sát, phản ứng rủi ro và phân vai người–AI là hoạt động quản trị liên tục. Điểm PoC không nên trở thành đảm bảo vĩnh viễn. Lấy mẫu sau triển khai, theo dõi drift, xem xét sự cố và regression gate trước khi đổi phiên bản phải nằm trong thiết kế vận hành.

6 giai đoạn triển khai PoC AI-OCR

Giai đoạn 1: Xác định mục tiêu quy trình và chi phí lỗi

Kiểm kê loại chứng từ, sản lượng tháng và cao điểm, ngôn ngữ, kênh tiếp nhận, hệ thống sau và yêu cầu lưu trữ. Đánh giá tác động, khả năng phát hiện và thời gian sửa của từng trường. Đặt mục tiêu như “rút ngắn thời gian đăng ký hóa đơn mà vẫn ngăn thanh toán sai” thay vì chỉ “tăng độ chính xác OCR”.

Giai đoạn 2: Viết hợp đồng đánh giá

Quy định matching, normalization, TP/FP/FN, căn dòng chi tiết, xử lý failure, phân tầng, quét threshold và acceptance gate. Hỏi nhà cung cấp có xuất field value, raw text, confidence, bounding region, model/version và error information cho cùng một evaluation script không.

Giai đoạn 3: Xây đường end-to-end hẹp

Không nên bắt đầu bằng tự động ghi mọi chứng từ vào ERP. Xây một đường hẹp từ extraction, normalization, rule validation đến giao diện review và audit log. Người kiểm tra nên thấy ảnh gốc, giá trị trích xuất, confidence, chênh lệch và ứng viên master data trên cùng màn hình; nếu không thời gian review có thể xóa lợi ích tự động hóa.

Giai đoạn 4: Đo trên holdout

Đóng băng cấu hình và chạy holdout chưa từng dùng. Báo cáo tổng và theo ngôn ngữ, loại chứng từ, chất lượng, nhà cung cấp, criticality. Nếu trung bình đạt nhưng một phân tầng quan trọng không đạt, cần giới hạn phạm vi hoặc hoãn nghiệm thu.

Giai đoạn 5: Chạy shadow operation

Dùng đầu vào sản xuất nhưng vẫn lấy quy trình hiện tại làm nguồn chính thức. Theo dõi sản lượng ngày, ứng viên STP, tải review, leakage, failure, latency và phí API. Đồng thời xác nhận cách xử lý dữ liệu nhạy cảm, nơi lưu, quyền truy cập, thời hạn log và xóa dữ liệu.

Giai đoạn 6: Nghiệm thu, mở rộng và giám sát

Phê duyệt gate, ngoại lệ, rủi ro còn lại, manual fallback, SLA, liên hệ sự cố và thông báo cập nhật mô hình. Sau khi vận hành vẫn phải lấy mẫu nhóm tự động đi tiếp, phân tích root cause của lỗi critical, xem số liệu phân tầng hàng tháng và regression test trước đổi phiên bản.

Câu hỏi cho RFP và so sánh độ chính xác OCR

1. Có thể kiểm thử cùng điều kiện trên chứng từ tiếng Nhật, Anh, Thái và Việt được chỉ định không?
2. Có thể xuất field value, raw text, confidence, bounding region, page, processor và version không?
3. Optional field và repeating line item được căn chỉnh, đánh giá thế nào?
4. Confidence có ý nghĩa gì, được calibration ra sao, và khách hàng đặt threshold đo được thế nào?
5. Có giới hạn gì với ảnh xấu, xoay, nhiều trang, trộn ngôn ngữ, chữ viết tay và con dấu?
6. API error, partial extraction, timeout, retry và xử lý trùng được quản lý ra sao?
7. Điều kiện về lưu trữ, dùng để huấn luyện, mã hóa, region, access log và xóa là gì?
8. Có thông báo cập nhật mô hình, ghim phiên bản, rollback và regression test không?
9. Đo thời gian và chi phí end-to-end, gồm review và audit log, như thế nào?
10. Bàn giao PoC có định nghĩa test set, evaluation code, danh mục lỗi và thiết kế vận hành không?

Để lập ngân sách, xem hướng dẫn chi phí và giá AI-OCR tại Thái Lan. Nếu phạm vi có chữ viết tay hoặc biểu mẫu biến động mạnh, nên tách thành phân tầng riêng theo hướng dẫn OCR chữ viết tay và số hóa biểu mẫu.

Sai lầm thường gặp và biện pháp kiểm soát

So demo trên mười trang sạch

Demo giúp hiểu giao diện nhưng không phải bằng chứng nghiệm thu thống kê. Cần dữ liệu phân tầng, holdout được bảo vệ và đo cả processing failure.

Xem confidence của các nhà cung cấp là cùng một thang

Đổi 0–1 sang 0–100 không làm calibration giống nhau. Phải đo độ đúng theo dải điểm cho từng ứng viên và đặt threshold riêng.

Chỉ kiểm toán chứng từ vào hàng review

Cách này che lỗi trong nhóm tự động đi tiếp. Duy trì lấy mẫu ngẫu nhiên nhóm confidence cao và lấy mẫu trọng điểm ở phân tầng rủi ro cao để đo leakage.

Chỉ lưu giá trị sau chuẩn hóa

Sẽ khó truy lỗi Unicode và biến đổi. Hãy giữ nguồn, raw output, giá trị normalized và phiên bản quy tắc.

Chấp nhận đa ngôn ngữ từ một số trung bình

Ngôn ngữ có sản lượng lớn sẽ chi phối trung bình. Đặt minimum gate theo ngôn ngữ, chất lượng ảnh, loại chứng từ và trường critical.

FAQ về độ chính xác AI-OCR

Độ chính xác AI-OCR bao nhiêu thì đủ triển khai?

Không có một tỷ lệ chung. Kết quả phụ thuộc chi phí lỗi, criticality, năng lực review và kiểm soát phía sau. Hãy dùng F1, critical exact match, leakage, failure và STP như các gate độc lập trên chứng từ của doanh nghiệp.

Khi so sánh độ chính xác OCR nên ưu tiên precision hay recall?

Ưu tiên precision nếu đưa giá trị sai sang bước sau gây tổn thất lớn, và recall nếu bỏ sót giá trị gây tổn thất lớn. Thực tế nên dùng F1 cùng chi phí lỗi, đồng thời kiểm soát trường critical bằng exact match.

Trường tùy chọn để trống được tính thế nào?

Không nên làm accuracy cao bằng số lượng lớn trường không tồn tại. Hãy định nghĩa TP, FP, FN rõ ràng và tính giá trị được tạo ra cho trường không có thật là FP.

Có thể đánh giá tiếng Nhật, Anh, Thái và Việt trong cùng PoC không?

Có, nhưng phải báo cáo riêng theo ngôn ngữ, ngôn ngữ của trường và chất lượng ảnh. Hỗ trợ thay đổi theo mô hình, tính năng, API, region và release status, nên kiểm tra tài liệu hiện hành khi đánh giá.

Confidence threshold chuẩn là bao nhiêu?

Không có threshold trung lập giữa nhà cung cấp. Cần quét giá trị theo criticality và đo precision, recall, STP, leakage cùng tải review trên dữ liệu thật.

PoC AI-OCR có cần tích hợp production không?

Không cần đưa toàn bộ vào production, nhưng chỉ kiểm extraction sẽ không đo được STP và công sức review. Một đường end-to-end hẹp qua normalization, rule, review và audit log tạo quyết định thực tế hơn.

Kết luận: Đo độ chính xác AI-OCR như hợp đồng nghiệm thu

Không lựa chọn AI-OCR bằng cách so tỷ lệ nhận dạng quảng cáo. Hãy xây holdout phân tầng theo bốn ngôn ngữ, loại chứng từ và chất lượng ảnh; đo precision, recall, F1, critical exact match, document exact match, STP, critical-error leakage, failure, repeatability và version delta. Đóng băng quy tắc ngày, tiền tệ, mã số thuế, Unicode và căn dòng chi tiết. Đặt confidence threshold từ criticality và năng lực review đã đo. Nếu gate trọng yếu không đạt, hãy hoãn nghiệm thu dù số trung bình đẹp, xử lý root cause rồi kiểm thử lại theo cùng hợp đồng.

TOMAS TECH có thể hỗ trợ ngay từ giai đoạn xác định dữ liệu đa ngôn ngữ, ground truth, bảng điểm PoC và acceptance gate mà chưa cần chọn sản phẩm trước. Nếu doanh nghiệp muốn so sánh trên chính chứng từ của mình, hãy liên hệ TOMAS TECH để trao đổi.

Tài liệu tham khảo

• Google Cloud: Evaluate a processor
• Google Cloud: Shared.Types.Metrics
• Google Cloud: Processor list
• Microsoft: Transparency note for Document Intelligence
• Microsoft: OCR language support
• Microsoft: What’s new in Document Intelligence
• AWS: Amazon Textract best practices
• AWS: Responsible AI Service Card—Textract AnalyzeID
• Unicode Consortium: UAX #15 Unicode Normalization Forms
• NIST: Artificial Intelligence Risk Management Framework 1.0

Phạm vi hỗ trợ dịch vụ, processor, mô hình, phiên bản API, khu vực và trạng thái preview hoặc general availability có thể thay đổi. Các nguồn trên được tham chiếu ngày 26 tháng 8 năm 2026; cần kiểm tra thông tin chính thức mới nhất trước khi lựa chọn hoặc ký hợp đồng.