Kiểm tra kết quả AI đọc tài liệu thế nào?
AI đọc tài liệu có thể giúp đưa thông tin từ hóa đơn hoặc biểu mẫu vào một bảng dữ liệu. Tuy nhiên, nhận ra ký tự và lấy đúng thông tin là hai việc khác nhau. Trên một hóa đơn có nhiều số tiền, công cụ có thể đọc đúng từng số nhưng chọn tiền trước thuế làm tổng phải thanh toán.
Bài viết dùng hóa đơn làm ví dụ giả định để giải thích cách kiểm tra. Mục tiêu không phải tìm một tỷ lệ “đúng” chung cho mọi tài liệu, mà là biết dữ liệu nào có thể dùng, lỗi nào phải được phát hiện và người dùng còn cần kiểm tra bao nhiêu.
1. Xác định cần lấy thông tin gì từ tài liệu
Hãy liệt kê các trường thực sự được dùng ở bước sau: nhà cung cấp, số hóa đơn, ngày, loại tiền, tổng thanh toán và dòng hàng nếu cần. Với mỗi trường, người nghiệp vụ xác nhận ý nghĩa và cách ghi kết quả đúng. “Ngày” có thể là ngày phát hành hoặc đến hạn; không làm rõ từ đầu sẽ khiến công cụ và người kiểm tra dùng hai đáp án khác nhau.
Cần quy định cả khi thông tin không có hoặc không đọc được. Một trường trống trên tài liệu phải được phân biệt với trường công cụ bỏ sót. Không nên điền 0 hoặc tự đoán chỉ để bảng không còn ô trống; một số 0 trông hợp lệ có thể được chuyển sang thanh toán mà người dùng không biết dữ liệu đang thiếu.
Đáp án chuẩn nên được người hiểu nghiệp vụ kiểm tra từ bản gốc, kèm cách xử lý những trường hợp khó. Nếu hai người chấm không thống nhất số tiền nào cần lấy, hãy giải quyết bất đồng trước. Lấy đầu ra AI làm đáp án rồi so AI với chính nó sẽ không cho biết công cụ có đang làm đúng nhu cầu hay không.
Chất lượng bản quét, phiên bản và quyền sử dụng tài liệu cần được chuẩn bị trước khi kiểm tra đầu ra. Bài Chuẩn bị dữ liệu thế nào trước khi dùng AI? giúp xác định nguồn nào đủ điều kiện thử, để kết quả không bị hiểu sai vì bộ tài liệu đầu vào thiếu hoặc chưa được xác nhận.
2. Đối chiếu kết quả với bản gốc
Chọn tài liệu đại diện cho nguồn nhận thực tế: PDF có chữ, ảnh chụp, bản quét nghiêng, nhiều trang hoặc bảng dài nếu thường gặp. Một bộ chỉ có mẫu đẹp sẽ không cho biết khả năng xử lý phần khó trong công việc hằng ngày. Ghi số lượng từng nhóm và giới hạn, không tuyên bố kết quả áp dụng cho loại tài liệu chưa được thử.
Giữ riêng tài liệu dùng để chỉnh công cụ và tài liệu đánh giá chưa dùng cho việc chỉnh. Khi sửa một mẫu lỗi, hãy thử cả mẫu mới tương tự và các trường hợp từng làm đúng. Nhờ vậy, nhóm biết thay đổi có giúp được ngoài ví dụ vừa sửa và có làm sai phần khác không.
Đối chiếu phải xem cả giá trị, trường và dòng. Nếu có nhiều mặt hàng, số lượng và đơn giá phải đi đúng với từng hàng. Tổng cộng khớp không chứng minh mọi dòng đều đúng. Có thể dùng quy tắc tính tổng để tìm sai lệch, nhưng quy tắc ấy không tự xác nhận nhà cung cấp hoặc tài khoản thanh toán đã được nhận diện đúng.
Khi tìm thấy lỗi, ghi đó là không đọc được chữ, gán nhầm trường, sai dòng hay tạo giá trị không có trên tài liệu. Các nguyên nhân cần cách sửa khác nhau. Gộp mọi lỗi thành “AI đọc sai” sẽ khiến nhóm khó biết phải đổi đầu vào, sửa quy tắc lấy thông tin hay giới hạn phạm vi dùng.
3. Xem tỷ lệ đúng có che mất lỗi quan trọng không
Ví dụ số học hoàn toàn giả định: 100 hóa đơn, mỗi tờ kiểm tra 5 trường, có 490 trong 500 trường đúng. Tỷ lệ theo trường là 98%. Nhưng nếu 10 trường sai nằm trên 10 hóa đơn khác nhau, chỉ 90 hóa đơn có đủ năm trường đúng. Nếu lỗi đều nằm ở số tiền phải trả, tỷ lệ chung sẽ che mất phần có ảnh hưởng lớn.
Vì vậy, báo cáo nên tách trường quan trọng, tài liệu đủ điều kiện xử lý và lỗi còn lọt qua bước kiểm tra. Ghi rõ cách tính và mẫu số. So sánh hai công cụ chỉ có ý nghĩa khi dùng bộ tài liệu và quy tắc chấm tương đương; không đặt cạnh nhau hai tỷ lệ từ hai thử nghiệm khác nhau rồi coi là so sánh chất lượng.
Điểm tin cậy do công cụ đưa ra có thể giúp chọn chỗ cần người xem lại, nhưng không phải bảo đảm cho từng kết quả. Hãy kiểm tra ngưỡng dự kiến trên tài liệu thực tế: có bỏ lọt lỗi quan trọng không và có chuyển quá nhiều tài liệu đúng sang người kiểm tra không? Không lấy ngưỡng từ một ví dụ của nhà cung cấp áp cho mọi nguồn.
4. Đưa dữ liệu vào quy trình có kiểm soát
Cần có đường tiếp nhận tài liệu không đọc được, thông tin thiếu và kết quả mâu thuẫn. Người kiểm tra phải nhìn được bản gốc, biết trường nào cần sửa và ghi được kết luận: chấp nhận, sửa hoặc yêu cầu gửi lại. Một tệp lỗi không nên biến mất khỏi danh sách để hệ thống chỉ còn những kết quả dễ xử lý.
Người được giao kiểm tra chưa chắc cần quyền xem mọi tài liệu hoặc duyệt thanh toán. Bài Phân quyền người dùng sao cho đúng việc? giúp tách quyền đọc, sửa dữ liệu và xác nhận kết quả, để một bước kiểm tra AI không vô tình mở rộng quyền nghiệp vụ.
Với thao tác có hậu quả lớn, chẳng hạn xác nhận thanh toán, mức tự động hóa phải theo rủi ro và bằng chứng thử. Dữ liệu đã được AI điền vào bảng chưa đồng nghĩa có thể chuyển thẳng sang thực hiện. Người chịu trách nhiệm cần xác định trường hợp bắt buộc kiểm tra, quyền từ chối và cách tiếp tục khi công cụ dừng.
Đo tổng công từ lúc nhận tài liệu đến lúc dùng được dữ liệu: chuẩn bị, chạy công cụ, kiểm tra, sửa và xử lý ngoại lệ. Nếu nhập liệu giảm nhưng việc đối chiếu tăng, cần thu hẹp hoặc sửa phương án. Khi đổi mẫu hóa đơn, nguồn gửi hoặc cấu hình công cụ, kiểm tra lại các trường hợp quan trọng trước khi mở rộng.
Kết quả này là một phần căn cứ đầu tư, bên cạnh chi phí và khả năng kiểm soát sau triển khai. Bài Khi nào nên đưa AI từ thử nghiệm vào sử dụng? giúp quyết định nên mở rộng, sửa rồi thử lại hay dừng một phạm vi chưa phù hợp.
Để trao đổi với Fenix, hãy chọn một loại tài liệu được phép dùng và danh sách trường cần lấy. Bắt đầu nhỏ nhưng đủ trường hợp khó sẽ hữu ích hơn một yêu cầu đọc mọi hồ sơ mà chưa có chuẩn đối chiếu.
