So sánh AI-OCR: hướng dẫn RFP và PoC cho nhà máy Thái Lan

So sánh AI-OCR không nên chỉ trả lời sản phẩm nào đọc đẹp nhất một trang demo sạch. Với nhà máy tại Thái Lan và ASEAN, câu hỏi thực sự là phương án nào chuyển đúng các trường cần thiết từ hóa đơn, đơn mua hàng, phiếu kiểm tra và phiếu giao hàng sang hệ thống nghiệp vụ; đưa ngoại lệ về cho con người một cách an toàn; và vận hành bền vững với chi phí hợp lý. Bài viết trình bày cách so sánh bốn mô hình xử lý tài liệu bằng cùng bộ hồ sơ, bộ chấm điểm, RFP, PoC và bằng chứng FAT/SAT.

Kết luận: so sánh AI-OCR bằng đầu ra nghiệp vụ, không bằng một tỷ lệ nhận dạng

Bảng so sánh chỉ có định dạng tệp, phần trăm accuracy quảng cáo và giá API sẽ che mất khác biệt quan trọng. Sai một ký tự trong số hóa đơn có thể làm hỏng việc đối soát. Sai tiền thuế hoặc loại tiền rồi tự động ghi sổ có thể ảnh hưởng kế toán. Ngược lại, khác biệt khoảng trắng trong tên công ty có thể xử lý an toàn bằng quy tắc chuẩn hóa đã thống nhất. Một điểm trung bình cấp ký tự không phản ánh được hệ quả này.

Hãy đổi đơn vị so sánh từ “OCR engine” sang toàn bộ luồng tiếp nhận, trích xuất, xác minh, review, xuất dữ liệu và lưu bằng chứng. Chia ứng viên thành bốn mô hình:

1. OCR hoặc trích xuất văn bản chỉ đọc.
2. Trích xuất tài liệu, biểu mẫu hoặc bảng dựng sẵn.
3. Trích xuất tùy chỉnh, xác định rõ theo tài liệu của khách hàng.
4. Hiểu tài liệu bằng AI tạo sinh hoặc multimodal, có grounding và human review.

Chấm độ đúng theo trường quan trọng, false auto-accept, straight-through processing, tỷ lệ review, chưa giải quyết, lỗi trùng/xuất dữ liệu, cycle time, độ phù hợp ngôn ngữ-layout, bằng chứng, khả năng chịu thay đổi và tổng chi phí vận hành. Không có mô hình thắng trong mọi trường hợp. Phương án phù hợp là phương án vượt các gate đã thống nhất trên bộ test đại diện được đóng băng của khách hàng.

Bốn mô hình cần tách khi so sánh AI-OCR

Nhãn AI-OCR có thể chỉ một dịch vụ trả về từ và tọa độ, mô hình hóa đơn dựng sẵn, custom extractor đã huấn luyện, hoặc mô hình tạo sinh diễn giải tài liệu đa dạng. Chúng có thể đứng cạnh nhau trong đề xuất nhưng khác về đầu ra, công sức triển khai, hành vi khi thay đổi và khả năng cung cấp bằng chứng.

Mô hình 1: đưa logic downstream vào báo giá OCR chỉ đọc

OCR chỉ đọc trả văn bản, dòng, từ và vị trí. Giá mỗi trang có thể thấp nhưng vẫn phải phân loại tài liệu, xác định số hóa đơn, ghép bảng, chuẩn hóa, kiểm tra và tích hợp. Mô hình này linh hoạt khi layout ổn định và doanh nghiệp có rule trưởng thành, nhưng phí gọi OCR chưa phải giá hệ thống hoàn chỉnh.

Theo trang giá công khai truy cập ngày 02/09/2026, Google Cloud liệt kê 0–1.000 trang Enterprise Document OCR đầu tiên là miễn phí; tier 1.000–5.000.000 trang tiếp theo có giá USD 1.50 cho mỗi 1.000 trang. Ví dụ chính thức AWS Textract tại US West (Oregon) dùng USD 0.0015/trang cho Detect Document Text. Đây là tham chiếu công khai theo ngày, không phải báo giá khách hàng. Khu vực, tier, tính năng, hợp đồng, thuế và tỷ giá có thể thay đổi; đồng thời chưa bao gồm một số phần như classification, field mapping, review, storage và integration.

Mô hình 2: kiểm “trường cần có”, không chỉ “trường đang có”

Mô hình hóa đơn, form hoặc table dựng sẵn trả dữ liệu có cấu trúc theo định nghĩa của nhà cung cấp, nhờ đó rút ngắn triển khai. Tuy nhiên, nó có thể không bao phủ trường thuế tại Thái Lan, supplier code nội bộ, đối soát PO, yêu cầu theo dòng, con dấu hoặc bảng đa ngôn ngữ.

Hướng dẫn chọn mô hình của Azure định vị Document Intelligence cho trích xuất xác định, khối lượng cao từ tài liệu structured/semi-structured; Content Understanding cho nội dung đa dạng hoặc multimodal hơn và trường được suy ra/tạo ra. Đây là hướng dẫn định vị của nhà cung cấp, không phải benchmark độc lập. RFP phải khóa mô hình, API version, region, ngôn ngữ và output schema được chào cụ thể.

Mô hình 3: đo chi phí bảo trì và kiểm thử lại của custom extraction

Custom extraction dựa trên record gắn nhãn, template hoặc rule có thể cho kết quả lặp lại tốt với phiếu kiểm tra, nhãn hoặc PO theo nhà cung cấp. Đổi lại, phải trả chi phí khi thêm supplier, thay layout, thay điều kiện chụp, retrain và regression test.

Điểm PoC một lần không có giá trị nếu trộn record train với acceptance. Tách dữ liệu train, tuning và final acceptance. Giữ bộ cuối ở dạng blind hoặc held-out, không dùng tinh chỉnh. Hỏi cần bao nhiêu nhãn, bao nhiêu công, ai làm, kiểm thử ra sao sau khi đổi mô hình và có thể quay về phiên bản trước hay không.

Mô hình 4: ký kết yêu cầu grounding và review cho AI tạo sinh

AI tạo sinh hoặc multimodal có thể phân loại tài liệu lạ, dùng ngữ cảnh nhiều vị trí và đề xuất trường khi nhãn không cố định. Nó cũng mang rủi ro tạo giá trị hợp lý nhưng không có nguồn, kết quả dao động, đổi model, latency và khó giải thích.

Quy định rõ khi không thấy giá trị phải trả null hay được đề xuất suy diễn. Gắn đầu ra quan trọng với trang, vùng và văn bản gốc. Đối chiếu supplier, PO, currency, tax và total với master data cùng phương trình xác định. Thiếu bằng chứng hoặc xung đột rule phải chuyển review. Năng lực ngôn ngữ không đồng nghĩa quyền tự ghi vào hệ thống kế toán.

Đóng băng bộ test tài liệu đại diện

Tính công bằng phụ thuộc test set nhiều hơn brochure. Nếu nhà cung cấp tự chọn record thuận lợi hoặc chỉ demo native PDF sạch, thứ hạng dễ bị thao túng. Hãy tạo bộ phản ánh biến thiên thực, gắn version/hash và đóng băng trong kỳ đánh giá.

Phân tầng theo:

• Loại: hóa đơn, PO, phiếu giao hàng, phiếu kiểm tra, biên nhận, nhãn.
• Bên phát hành: supplier chính, ít giao dịch, mới, khách hàng và site nội bộ.
• Ngôn ngữ: Thái, Anh, Nhật, Việt và trộn trên cùng trang.
• Kênh: native PDF, scan, ảnh điện thoại, tệp đính kèm e-mail.
• Trang: một, nhiều, nối tiếp, thiếu và sai thứ tự.
• Layout: hiện hành, cũ, lệch vị trí, dòng hàng sang trang khác.
• Ký hiệu: chữ viết tay, dấu, sửa, ghi chú, chữ viết dọc và ký hiệu đặc biệt.
• Lỗi ảnh: mờ, noise, tối, chữ nhạt/nhỏ, cắt, lóa và nghiêng.

Google Enterprise Document OCR có tùy chọn phân tích chất lượng ảnh, trả điểm từ 0 đến 1 và flag blur, noise, darkness, faint text, small text, cutoff, glare. Google cũng lưu ý có thể false positive và hạn chế với vùng lóa cục bộ. Chỉ số này không phải business accuracy nhưng có thể tách lỗi capture khỏi lỗi extraction tại cổng đầu vào.

Đưa cả trường hợp thường gặp lẫn hiếm nhưng tác động lớn: hóa đơn không phải THB, dòng âm, nhiều PO, sửa tay, thuế hỗn hợp. Có thể tách operational set phản ánh tỷ lệ production và risk set tăng mật độ biên nguy hiểm. Báo cáo cả hai để điểm trung bình không che lỗi trọng yếu.

Kiểm tra ground truth hai lớp

Nếu nhãn đúng bị sai, đầu ra đúng sẽ bị chấm sai. Một người gắn nhãn, người khác đối chiếu nguồn, process owner xử lý bất đồng. Data dictionary phải định nghĩa tên, kiểu, bắt buộc/tùy chọn, trường lặp, null và ranh giới dòng.

Đặt normalization trước khi chấm. Với identifier, quyết định giữ số 0 đầu, bỏ khoảng trắng/gạch nối và phân biệt hoa thường. Với tiền, định nghĩa số lẻ, làm tròn, dấu phân cách và số âm. Với ngày, định nghĩa thứ tự ngày/tháng, năm Phật lịch/Dương lịch và ngày mơ hồ. Đổi rule sau khi có kết quả sẽ phá tính tái lập.

Đo độ chính xác AI-OCR theo trường và quy trình

Tuyên bố “accuracy 99%” không cho biết mẫu số, tài liệu, lỗi bị loại hay số lỗi nghiêm trọng. Dùng character accuracy làm phụ, ưu tiên business-field và document-flow. Xem thêm hướng dẫn đo độ chính xác AI-OCR.

Tối thiểu báo exact match hoặc precision/recall từng field, document straight-through-processing rate, false auto-accept rate, manual-review rate, unresolved rate, duplicate/export error rate và end-to-end cycle time. Không loại thất bại xử lý khỏi mẫu số rồi quảng cáo accuracy chỉ trên trường được trả về.

Hướng dẫn accuracy/confidence chính thức của Azure mô tả confidence là estimated probability và đưa field confidence thấp sang human review; đồng thời yêu cầu variation hình ảnh/layout đại diện trong train/evaluate. Tuy vậy, 0.90 của vendor A không tự động tương đương 0.90 của vendor B. Phải calibrate dải confidence với tỷ lệ đúng thực tế trên cùng labelled customer set.

Sai nhưng confidence cao đặc biệt nguy hiểm vì có thể lọt review. Kết hợp rule xác định như subtotal + tax = total, supplier/currency khớp PO, tổng dòng khớp header. Đầu ra tự tin nhưng xung đột rule không được auto-post.

Kiểm độ phù hợp đa ngôn ngữ theo mô hình và tính năng

Danh sách processor của Google nói Enterprise Document OCR ở trạng thái GA, hỗ trợ hơn 200 ngôn ngữ, gồm chữ in tiếng Nhật, Thái và Việt. Hỗ trợ ký tự chung không chứng minh trích đúng field từ hóa đơn, biểu mẫu viết tay hoặc bảng đa ngôn ngữ của khách hàng. Phải yêu cầu bằng chứng trên hồ sơ thực.

Giới hạn chính thức Amazon Textract liệt kê ngôn ngữ text detection là English, French, German, Italian, Portuguese, Spanish và nhận dạng chữ viết tay chỉ English. Đây là fit gate sớm nếu scope có Thái, Nhật hoặc Việt. Tài liệu cũng nói synchronous PDF/TIFF là một trang với giới hạn 10 MB in-memory; asynchronous hỗ trợ tới 500 MB và 3.000 trang. Kiểm kích thước, số trang, latency và tích hợp bất đồng bộ thực tế.

Trang What’s New của Azure Document Intelligence liệt kê locale tiếng Thái và Việt cho invoice model cùng currency code Thái/Việt. Vẫn phải xác minh model/API version và region được chào. “Sản phẩm đa ngôn ngữ” là câu trả lời quá rộng; hãy lấy bằng chứng theo tính năng.

Chuyển giá AI-OCR thành TCO hàng tháng

Giá API công khai quan trọng nhưng chỉ là một phần. Dùng công thức chung:

TCO hàng tháng = phí API/processor + capture/classification + storage/network + integration/monitoring + bảo trì model/template + human review + sửa lỗi/reprocess + vận hành security/compliance.

Theo trang truy cập ngày 02/09/2026, Google liệt kê Form Parser và Custom Extractor ở USD 30/1.000 trang trong một triệu trang đầu; Layout Parser USD 10/1.000 trang. Ví dụ Oregon của AWS liệt kê Forms USD 0.05/trang và Tables USD 0.015/trang trong một triệu trang đầu; dùng cả hai thì tính cả hai tính năng. Chúng không đảm bảo phạm vi đầu ra tương đương. Ghi ngày, region, tổ hợp tính năng, tier, thuế và giả định. Không đổi sang THB nếu chưa ghi giả định tỷ giá.

Ví dụ tính nội bộ giả định

Đây là mô hình thiết kế minh họa, không phải trung bình thị trường hay báo giá.

• 50.000 trang/tháng.
• Baseline thủ công: 3 phút/trang ở 180 THB/giờ.
• Chi phí thủ công: 50.000 × 3 ÷ 60 × 180 = 450.000 THB/tháng.
• Phương án A: straight-through 60%; 40% còn lại review 1,5 phút/trang.
• Lao động review A: 50.000 × 40% × 1,5 ÷ 60 × 180 = 90.000 THB/tháng.
• Phương án B: straight-through 80%; 20% còn lại review 1,5 phút/trang.
• Lao động review B: 50.000 × 20% × 1,5 ÷ 60 × 180 = 45.000 THB/tháng.
• Chênh lệch review: 90.000 − 45.000 = 45.000 THB/tháng.

Nếu error/rework và risk bằng nhau, platform premium của B dưới 45.000 THB/tháng có thể hợp lý. Nếu B false auto-accept nhiều hơn, bảo trì đắt hơn hoặc chậm lúc peak, phải tính lại. Ví dụ không tạo ra một payback period phổ quát.

Đo review time từ lúc mở case, đối chiếu nguồn, sửa đến xử lý ERP error. Khi chỉ còn ngoại lệ khó, giảm số case vẫn có thể tăng phút/case. Tách implementation, migration, training và parallel run một lần khỏi steady-state hàng tháng.

Đính kèm scorecard tái lập vào RFP

Điểm trọng số giúp tổ chức quyết định nhưng không được dùng trung bình che lỗi nghiêm trọng. Áp mandatory gate trước, chỉ chấm ứng viên đã qua. Các giá trị dưới đây là proposed acceptance design, không phải external benchmark.

Ví dụ mandatory release gate

• Không có critical wrong auto-post trong frozen acceptance set.
• Mọi low-confidence hoặc business-rule conflict được chuyển review.
• Record xuất giữ link về source page và field evidence.
• Gửi trùng vẫn idempotent, không tạo record thứ hai.
• Truy được human correction, model/configuration version và retest.
• Đạt yêu cầu bắt buộc về ngôn ngữ, file, trang và region.

“Không có” chỉ áp dụng cho bộ acceptance hữu hạn của khách hàng, không bảo đảm thống kê rằng production không có defect. Vẫn cần rollout theo giai đoạn và monitoring.

Gắn mỗi điểm với test-case ID, log, màn hình, API output và dòng báo giá thay vì sales text. Chuẩn hóa output riêng của vendor vào một schema và giữ raw result để đổi trọng số sau. Danh sách chưa rõ và điều kiện loại hữu ích hơn một thứ hạng thập phân giả chính xác.

Nội dung RFP triển khai AI-OCR

1. Document inventory: loại, version, bên phát hành, ngôn ngữ, volume, peak, trang.
2. Kênh intake: e-mail, shared folder, scanner, điện thoại, API.
3. Output schema: field, type, bắt buộc, normalization, tolerance, line.
4. Hệ downstream: ERP, kế toán, mua hàng, chất lượng, DMS và ranh giới.
5. Exception flow: người review, bằng chứng hiển thị, sửa và đường trả lại.
6. Data: location, encryption, access, retention, deletion, training use.
7. Evidence: source, region, value, confidence, rule, correction, export ID.
8. Non-functional: throughput, peak, response, availability, monitoring, support.
9. Change control: model/API version, notice, regression, rollback.
10. Giá: đơn vị, tối thiểu, add-on, support, review, môi trường.
11. PoC: frozen data, scorer, blind/held-out, thời gian, deliverable, gate.
12. Exit: trả và xóa data, configuration, label, log.

Cấm chỉ chọn tài liệu sạch và buộc có blind/held-out record do khách hàng chọn. Chuyển mọi output về JSON/CSV schema chung rồi chạy cùng scorer. Cách này tái lập hơn việc mỗi nhóm nhìn interface riêng của từng vendor.

Về đội triển khai, rollout theo giai đoạn và vận hành sau lựa chọn, xem hướng dẫn triển khai AI-OCR. Scorecard của bài này có thể trở thành workstream selection/acceptance.

Yêu cầu PoC diễn tập thất bại, không chỉ happy path

PoC phải chứng minh hệ thống dừng an toàn, giữ bằng chứng và phục hồi. Yêu cầu trình diễn:

• Blur, cutoff, glare được trả về recapture.
• Unsupported language hoặc unknown layout không bị ép vào field.
• Bảng nối trang, thiếu trang, sai thứ tự.
• Gửi cùng file hai lần không xuất trùng.
• Timeout, partial success, rate limit rồi retry an toàn.
• Supplier, PO, currency, total xung đột được đưa review.
• Lưu giá trị sửa, lý do, người và thời gian.
• Chấm lại frozen set sau khi đổi model/API version.
• Rollback phiên bản trước hoặc manual route khi regression.

Trace input ID, dataset version, model/configuration version, thời gian, output, rule result, review và final record ID. Screenshot không đủ tái lập; cần machine-readable output và scoring result.

Tách FAT và SAT

FAT xác minh extraction, rule, API, evidence và failure trong môi trường kiểm soát. SAT xác minh identity, network, scanner/e-mail/file thực, ERP/API integration, operational review, monitoring và backup tại môi trường khách hàng.

Cùng PDF có thể qua FAT nhưng resolution scanner, tên file, latency, quyền service account, ERP master hoặc lịch reviewer làm kết quả SAT khác. Kiểm peak, partial outage, chạy ban đêm và manual fallback.

Giữ frozen set sau nghiệm thu. Rerun case liên quan khi model, template, rule, scanner hoặc ERP schema đổi. Đưa layout mới vào review-only đến khi có đủ bằng chứng mở rộng automation. Ghi version và kết quả đã cho phép mỗi lần mở rộng.

Toàn bộ vòng đời từ nhận giấy đến lưu và hủy được trình bày trong hướng dẫn số hóa vòng đời tài liệu giấy. Chỉ đổi OCR không hoàn tất quy trình nếu scan quality, quản lý bản gốc, quyền sửa và retention chưa rõ.

Chuyển kết quả đánh giá thành phê duyệt và hợp đồng

Scorecard kỹ thuật không đủ để lãnh đạo quyết định đầu tư hoặc mua hàng tạo phạm vi ràng buộc. Hãy nối mô hình chọn, tác động nghiệp vụ, residual risk, chủ sở hữu vận hành, giả định chi phí và release condition trong một decision record.

Đầu tiên, cố định ranh giới bằng một câu: “Trích header và line từ hóa đơn do supplier chỉ định e-mail tới nhà máy Thái Lan; kiểm PO, supplier, currency và amount; chỉ đưa record không xung đột vào ERP-ready queue; nhân viên kế toán giữ quyền final posting.” Định nghĩa mẫu số automation là mọi file nhận, tài liệu in-scope đã phân loại hay tài liệu đủ dữ liệu; báo file bị loại cùng lý do.

Thứ hai, phê duyệt severity trước test. Cho ví dụ minor, correctable, critical và release-stopping. Khoảng trắng có thể minor; sai pháp nhân, currency, record trùng hoặc giá trị thiếu source evidence có thể critical. Business, accounting, quality, IT và security owner phê duyệt stop condition và chỉ định người phân xử.

Thứ ba, giữ evidence register tách vendor claim, kiểm configuration, đo PoC, cam kết hợp đồng và unverified. Ngôn ngữ trong support list không phải customer-field accuracy. Nút delete không phải thời hạn xóa theo hợp đồng bao gồm backup/log.

Quản lý unverified khác điểm thấp vì “không có khả năng” và “chưa có bằng chứng” đòi hỏi action khác nhau. Gắn owner/due date cho việc đóng trước contract và việc được phép đóng ở SAT.

Thứ tư, chạy sensitivity analysis. Weight chỉ biểu thị ưu tiên. Nếu đổi field accuracy từ 25% lên 35%, hoặc TCO 3 năm từ 15% lên 25%, làm đảo thứ hạng, hãy nêu khuyến nghị có điều kiện thay vì người thắng phổ quát. Tính low/base/high cho volume, review minute, exchange rate, tăng supplier và reprocessing.

Thứ năm, lưu lý do loại cùng lý do chọn: dataset version, field/gate thất bại và điều kiện xem xét lại. Đặt giới hạn cho phương án chọn: hóa đơn Thái in có thể vào auto-post candidate; chữ viết tay luôn review; layout Việt cũ ngoài scope; supplier mới review-only trong thời gian quan sát. Lựa chọn chỉ cấp phép scope đã test, không phải toàn sản phẩm.

Cuối cùng, nối payment milestone với acceptance evidence và deliverable: data dictionary, common schema, labelling policy, test-set version, scorer, toàn bộ kết quả, exception, operating procedure, monitoring, incident procedure và regression method. Tránh khuyến khích overfit acceptance set đã lộ; xác minh cùng rule trên held-out record. Procurement, legal và information-management phải kiểm điều khoản cuối theo quy định áp dụng.

Scorecard trở thành decision record bền vững: scope nào được ai cho phép, dựa trên bằng chứng gì và còn action nào. Layout mới hoặc gia hạn được đánh giá như controlled change thay vì tranh luận lại từ đầu.

20 câu hỏi yêu cầu bằng chứng từ nhà cung cấp

1. Phạm vi chào là read-only, prebuilt, custom hay generative?
2. Model, API version, region, language và giới hạn sync/async nào áp dụng?
3. Mỗi giá trị truy về trang và source region được không?
4. Không thấy giá trị thì trả null hay đề xuất suy diễn?
5. Confidence là gì và calibrate trên bộ của chúng tôi thế nào?
6. Rule xác định có chặn đầu ra tự tin nhưng sai không?
7. Kiểm trộn tiếng Thái, Nhật, Anh, Việt như thế nào?
8. Điều kiện cho chữ viết tay, dấu, sửa và bảng nhiều trang?
9. Phân biệt capture failure với extraction failure ra sao?
10. Có chấp nhận blind/held-out record do khách hàng chọn?
11. Ai sở hữu training data, label, configuration, prompt?
12. Supplier/layout mới cần bao nhiêu thời gian và chi phí?
13. Retry sau partial success giữ idempotency thế nào?
14. Review có hiển thị source, value, evidence, rule conflict cùng lúc?
15. Correction có được giữ để regression test?
16. Điều khoản storage, location, retention, deletion, training use, subprocessor?
17. Phí classification, storage, monitoring, support nào ngoài quote?
18. Thông báo model/service change khi nào và bằng cách nào?
19. Manual fallback, recovery objective và rollback là gì?
20. Khi exit, data, log, setting, label được trả ở định dạng nào?

Không nhận câu “có hỗ trợ” thiếu model, điều kiện, kết quả test, giới hạn và giá. Tính năng có thể tồn tại nhưng không trong plan/region được chào. Quy định trước item chưa trả lời là fail, 0 điểm hay action PoC.

FAQ về so sánh, giá và độ chính xác AI-OCR

Cần chuẩn bị gì trước khi so sánh AI-OCR?

Chuẩn bị document inventory, required-field schema, frozen test set, ground truth đã kiểm, normalization, severity và exception flow trước danh sách vendor. Nếu không, mỗi bên sẽ demo mẫu và metric khác nhau.

AI-OCR phải chính xác bao nhiêu phần trăm để vào production?

Không có threshold phổ quát. Đo supplier, invoice number, currency, tax riêng và theo dõi false auto-accept. Chỉ review low confidence không bắt được lỗi confidence cao, nên phải thêm business rule.

Có thể so giá AI-OCR chỉ bằng giá API không?

Không. Phải gồm capture, classification, storage, integration, monitoring, maintenance, human review, rework và security operations. Khi đổi tiền, ghi tỷ giá/ngày và kiểm scope đầu ra có tương đương không.

Generative document AI luôn tốt hơn OCR truyền thống?

Không. Nó hữu ích với tài liệu đa dạng và ngữ cảnh; prebuilt/custom/rule có thể dễ dự đoán hơn cho schema ổn định. So grounding, inference error, review, latency và TCO trên cùng bộ.

PoC OCR cần bao nhiêu tài liệu?

Không có con số chung. Độ phủ supplier, ngôn ngữ, layout, lỗi capture và ngoại lệ rủi ro quan trọng hơn tổng số. Báo uncertainty, điều kiện chưa test và thu thêm record cho strata ít dữ liệu.

Confidence cao có đủ auto-post?

Chưa đủ đến khi calibrate trên cùng labelled set và kiểm critical error. Confidence không phải business accuracy và không so trực tiếp giữa vendor. Kết hợp master-data, arithmetic và duplicate check.

Ghi hỗ trợ tiếng Thái có chứng minh phù hợp hóa đơn Thái?

Chỉ là điểm đầu. Printed OCR, handwriting, invoice model, table và mixed language có thể khác phạm vi. Khóa model, version, region và test field thực trên hóa đơn Thái.

FAT khác SAT thế nào?

FAT kiểm extraction, rule, API, evidence trong controlled environment. SAT kiểm identity, network, kênh thật, ERP, reviewer và monitoring tại khách hàng. Cần cả hai để nối demo accuracy với production operation.

Tổng kết: cùng tài liệu, cùng scorer, cùng gate

Trọng tâm so sánh AI-OCR là tài liệu khách hàng được đóng băng và kết quả end-to-end, không phải recognition rate trên brochure hoặc phí API tối thiểu. So OCR-only, prebuilt, custom và generative theo critical field, false auto-accept, review, unresolved, evidence, integration, thay đổi và TCO hàng tháng.

Đưa common schema, blind/held-out set, mandatory gate, pricing assumption, failure demonstration, FAT/SAT và exit terms vào RFP. Ghi rõ threshold nội bộ là giả định thiết kế riêng cho quy trình, không phải benchmark phổ quát. Khi đó quyết định mua dựa trên bằng chứng tái lập thay vì ấn tượng PoC.

TOMAS TECH có thể hỗ trợ nhà máy tại Thái Lan lập document inventory, comparison scorecard, RFP và PoC acceptance package trước khi chọn sản phẩm. Nếu doanh nghiệp đang xác định required field và exception flow, hãy liên hệ với chúng tôi để trao đổi thiết kế đánh giá.

Tài liệu tham khảo

• Google Cloud Document AI pricing (truy cập 02/09/2026)
• AWS Textract pricing (truy cập 02/09/2026)
• Azure Document Intelligence: Choose a model or feature
• Azure Document Intelligence: Accuracy and confidence
• Google Document AI processor and detail list
• Google Enterprise Document OCR
• Amazon Textract quotas and limits
• Azure Document Intelligence: What’s new