Điều kiện chốt giá trị cho AI đọc tài liệu: Đừng giao quyết định cuối cùng cho AI

Hãy hình dung trường hợp dùng AI tạo sinh để đọc báo giá từ nhà cung cấp rồi đăng ký vào hệ thống nội bộ. Số tiền và ngày tháng đều được điền vào đúng ô, nhìn trên màn hình có vẻ hoàn tất. Nhưng nếu số tiền tính theo nghìn yên, còn ngày tháng là hạn hiệu lực chứ không phải ngày báo giá thì phát hiện ở bước nào?

Bài viết khuyến nghị không xác nhận ngay kết quả đọc của AI như giá trị cuối cùng, mà tách riêng “giá trị lấy từ bản gốc”, “giá trị đã chuyển đổi cho nghiệp vụ” và “giá trị đã qua kiểm chứng”. Việc cần quyết định trước không phải hình thức đầu ra, mà là căn cứ để chấp nhận từng trường dữ liệu.

Tách việc đọc khỏi chuyển đổi sang giá trị nghiệp vụ

RICOH cho biết đã triển khai “AI-OCR thích ứng”, có thể chuyển đổi kết quả đọc theo quy tắc xử lý của doanh nghiệp hoặc nhân viên phụ trách, trong dịch vụ xử lý hóa đơn và phiếu giao hàng nhận vào. [1] OCR (nhận dạng ký tự quang học) là công nghệ đọc ký tự trong hình ảnh và các dữ liệu tương tự. [4] Mô tả của công ty nêu các xử lý như trích xuất một phần mã số và đổi niên hiệu Nhật sang năm dương lịch. [1]

Phần giải thích dịch vụ hiện tại cũng cho biết lịch sử chỉnh sửa của người dùng được đưa vào AI tạo sinh để xuất kết quả theo quy tắc xử lý. [4] Đây đều là mô tả từ phía nhà cung cấp, không nên xem là tài liệu xác minh độc lập về hiệu quả tiết kiệm của doanh nghiệp sử dụng.

Điều cần suy nghĩ từ đây là ranh giới giữa chép lại chính xác và chuyển thành giá trị dùng cho nghiệp vụ. Ví dụ, khi bỏ các chữ số đầu của một mã, giá trị có thể chính xác theo mã quản lý của đối tác nhưng không phù hợp với quy tắc đăng ký của công ty mình. Nếu chỉ kiểm thử giá trị cuối cùng, sẽ không thể xác định sai khác đến từ khâu đọc hay khâu chuyển đổi.

Khi thiết kế, hãy lưu riêng chuỗi ký tự trong bản gốc, giá trị sau chuyển đổi, quy tắc đã áp dụng và trang hoặc vị trí làm căn cứ. Nếu không đọc được bản gốc nhưng giá trị sau chuyển đổi lại được điền, hãy đặt chính sách chuyển sang xác nhận thay vì chốt. Nếu yêu cầu AI cung cấp cả vị trí căn cứ, hãy đưa việc xác minh vị trí đó có thực sự chứa nội dung tương ứng vào phạm vi kiểm thử.

Định dạng đầu ra đúng không đồng nghĩa giá trị có ý nghĩa đúng

Đầu ra có cấu trúc là cách nhận câu trả lời theo định dạng đã xác định tên trường, kiểu dữ liệu và các mục tương tự. [2] Tài liệu chính thức về Gemini API của Google giải thích đầu ra tuân theo JSON Schema, đồng thời yêu cầu phía ứng dụng xác minh giá trị ngay cả khi JSON đúng cú pháp. [2] Tài liệu cũng nêu rõ cần xử lý đầu ra đúng định dạng nhưng sai ý nghĩa. [2]

Hãy đưa sự khác biệt này vào điều kiện nghiệm thu nghiệp vụ. Với trường số tiền, ngoài việc xác nhận đó là số, còn phải kiểm tra tiền tệ, đơn vị và giá đã gồm hay chưa gồm thuế. Với trường ngày tháng, đừng chỉ kiểm tra có đọc được như ngày tháng hay không; hãy định nghĩa đó là ngày phát hành, hạn hiệu lực hay ngày giao hàng.

Ví dụ giả định: nếu đầu vào ghi “số tiền 12, đơn vị nghìn yên” và chuyển sang đơn vị yên, giá trị đăng ký dự kiến là 12.000 yên. Giá trị 12 khi bị mất đơn vị vẫn là một con số hợp lệ. Trong thử nghiệm, đừng chỉ dựa vào so khớp chuỗi; hãy so sánh kết quả chuyển đổi có bao gồm đơn vị.

Cách xử lý ô trống cũng là một phần của đặc tả. Không nên gộp “không ghi”, “không đọc rõ ký tự”, “có nhiều ứng viên” và “không áp dụng” thành một ô trống duy nhất. Nếu điền số 0 vào khoản tiền không được ghi, sẽ không phân biệt được trường hợp chưa xác minh với số tiền bằng 0. Hãy thiết kế cả định dạng cho phép giá trị rỗng lẫn lý do vì sao rỗng.

Phần nào giao cho AI và phần nào xác minh bằng quy tắc cố định

Có ba lựa chọn: giao cho AI từ trích xuất đến chỉnh sửa; chỉ xử lý bằng quy tắc cố định; hoặc kết hợp cả hai. Bài viết ưu tiên cấu trúc dùng AI để đọc cách diễn đạt trên tài liệu, còn các quy tắc chuyển đổi đã xác định và điều kiện đối chiếu được thực thi bằng chương trình thông thường.

Chẳng hạn, có thể xác minh mã bộ phận đã được đăng ký hay chưa, ngày bắt đầu của một giai đoạn có trước ngày kết thúc không và cùng một chi tiết có bị lặp hay không. Nếu đối chiếu tổng tiền, hãy thống nhất với bộ phận nghiệp vụ quy tắc tính có bao gồm chiết khấu và làm tròn trước khi triển khai. Nếu kết luận chênh lệch là lỗi khi quy tắc chưa được xác định, thiết kế sẽ yêu cầu nhân viên xác nhận sửa đổi mà không có căn cứ.

Nếu giao tất cả cho AI, bài toán là đánh giá cả kết quả trích xuất lẫn kết quả xác minh ra sao. Không nên xem lời giải thích do AI tạo ra là bằng chứng giá trị đúng. Ngược lại, nếu thêm quy tắc mỗi khi biểu mẫu hoặc cách diễn đạt thay đổi, cũng cần so sánh cả việc ai sẽ tiếp tục duy trì phần bổ sung đó.

Nếu ngay từ đầu có thể nhận các trường cần thiết dưới dạng dữ liệu có cấu trúc, hãy cân nhắc tích hợp trực tiếp trước khi biến dữ liệu thành hình ảnh tài liệu rồi dùng AI đọc lại. Đừng coi việc ứng dụng AI là mục tiêu; hãy ưu tiên con đường giúp hai bên thống nhất giá trị được chuyển giao và ý nghĩa của nó.

Không lấy ngưỡng độ tin cậy làm điều kiện duy nhất để chốt

Tài liệu chính thức của Microsoft Document Intelligence giải thích rằng hệ thống trả về độ tin cậy ước tính cho các trường trích xuất, nhưng không phải trường nào cũng có độ tin cậy. [3] Tài liệu cũng cho biết độ tin cậy của ô và của hàng có thể khác nhau: ô trong bảng có thể đúng, nhưng cả hàng vẫn có khả năng bị bỏ sót. [3]

Vì vậy, trước khi đặt một ngưỡng chung cho cả tài liệu, hãy quyết định đánh giá trường nào ở cấp độ nào. Đừng mặc định cho qua các trường không có độ tin cậy. Hãy xem định dạng giá trị, vị trí căn cứ, tính nhất quán nghiệp vụ và mức độ tin cậy nếu có như những điều kiện riêng biệt.

Đừng chỉ quyết định điều kiện chấp nhận từ các tài liệu dễ đọc. Bộ tài liệu thử nghiệm nên gồm trường hợp đơn vị ở ngoài ô, chi tiết kéo dài qua nhiều trang, nhà cung cấp có tên gần giống nhau, giá trị trước và sau chỉnh sửa cùng xuất hiện, và mục bắt buộc bị thiếu. Ngoài tài liệu dùng để tinh chỉnh, hãy để riêng một tập tài liệu kiểm thử sau khi chốt điều kiện.

Trong thử nghiệm, nên báo cáo song song không chỉ tỷ lệ trường đọc được mà cả số giá trị sai đã lọt vào danh sách chờ chốt và số trường hợp phải đưa đi xác nhận. Tăng số lần xác nhận cũng làm tăng gánh nặng tại hiện trường. Ngược lại, nếu nới điều kiện để giảm xác nhận, phải nêu rõ đang chấp nhận loại sai sót nào.

Biến điều kiện chốt thành sản phẩm mà nghiệp vụ có thể cập nhật

Trên màn hình xác nhận, hãy hiển thị cạnh nhau giá trị trích xuất, đoạn liên quan trong bản gốc, nội dung chuyển đổi và lý do không đạt điều kiện. Khi nhân viên sửa giá trị, hãy ghi riêng lỗi đọc, thiếu sót trong quy tắc chuyển đổi và mâu thuẫn ngay trên tài liệu. Trước khi đưa mọi kết quả sửa trở lại quá trình học, cần phân biệt người dùng đã sửa điều gì.

Với cách làm Forward Deployed Engineering (FDE) — đồng hành cùng khách hàng từ khâu lập kế hoạch và thử nghiệm đến triển khai rồi đưa vào nề nếp — nên dùng bảng định nghĩa từng trường làm sản phẩm chung giữa bộ phận nghiệp vụ và phát triển. Bảng ghi ý nghĩa trường, căn cứ, quy tắc chuyển đổi, cách xử lý thiếu dữ liệu, điều kiện chốt và người chịu trách nhiệm thay đổi điều kiện. Khi thay mô hình hoặc chỉ dẫn, hãy kiểm tra lại bằng tập tài liệu đã lưu riêng.

Cách tiếp cận này không phù hợp nếu không thể xem bản gốc, hoặc chính bộ phận nghiệp vụ cũng không thể định nghĩa ý nghĩa và đáp án đúng của trường dữ liệu. Khi đó không thể thiết kế điều kiện để xác nhận đầu ra AI thành giá trị nghiệp vụ. Trước tiên hãy xem lại cách nhận tài liệu hoặc định nghĩa các trường nhập liệu.

Gợi ý cho thực tiễn

Đề xuất 1: Quyết định ý nghĩa của từng trường và cách xử lý thiếu dữ liệu trước khi thử nghiệm. Với số tiền, định nghĩa đơn vị và tiền tệ; với ngày tháng, xác định đó là ngày nào, kèm ví dụ đầu ra mong đợi.

Đề xuất 2: Tách riêng bản gốc, giá trị chuyển đổi và kết quả xác minh trong luồng chuyển giao. Không biến giá trị thành dữ liệu đã chốt trong hệ thống nghiệp vụ chỉ vì nó được trả về đúng định dạng.

Đề xuất 3: Đánh giá song song số giá trị sai lọt qua và số trường hợp chuyển đi xác nhận. Phạm vi tự động hóa phải được quyết định dựa trên cả điều kiện mà nhân viên xác nhận có thể xử lý, chứ không phải đầu ra trông đẹp mắt.

Tài liệu tham khảo

1. RICOH “Phát triển ‘AI-OCR thích ứng’ tối ưu hóa kết quả OCR theo quy tắc xử lý biểu mẫu của từng doanh nghiệp và nhân viên phụ trách” (2025-05-08, thông cáo báo chí tại thời điểm công bố, ngày kiểm tra: 2026-09-23)
2. Google, Structured outputs (2026-09-17, HTML hiện hành, không có số phiên bản, ngày kiểm tra: 2026-09-23)
3. Microsoft, Interpret and improve accuracy and confidence scores (2026-04-08, Document Intelligence v4.0, API 2024-11-30 GA, ngày kiểm tra: 2026-09-23)
4. RICOH “Tiếp tục phát triển AI-OCR nhờ ứng dụng AI tạo sinh” (ngày đăng/cập nhật không rõ, HTML hiện hành, không có số phiên bản, ngày kiểm tra: 2026-09-23)

Bài viết này được thực hiện với sự hỗ trợ của AI và đã được rà soát tự động trước khi xuất bản. Ngày kiểm tra thông tin: 2026-09-23.