AI trả JSON đúng format nhưng sai dữ liệu: làm sao phát hiện?

Lớp 1 — Syntax và schema. Parse JSON, khóa kiểu dữ liệu, required fields, enum, range cơ bản và additionalProperties khi phù hợp. Payload fail ở đây không được đi tiếp.

Lớp 2 — Semantic và business rules. Kiểm tra những điều schema khó thể hiện hoặc không biết từ domain: endDate >= startDate, tổng hóa đơn khớp các dòng chi tiết theo quy tắc làm tròn, mã khách hàng tồn tại, trạng thái cho phép chuyển bước, email domain có thuộc đối tác đã đăng ký hay không.

Lớp 3 — Source verification. Với field quan trọng, phải biết giá trị đến từ đâu. Có thể lưu sourceDocumentId, trang/vùng trích xuất, message ID hoặc đoạn evidence để validator đối chiếu lại với nguồn. Nếu không tìm thấy bằng chứng tương ứng, đừng coi giá trị đó là đúng chỉ vì model trả confidence cao.

Lớp 4 — Decision gate. Tổng hợp kết quả thành accept, retry, quarantine hoặc reject. Gate nên dựa trên mức rủi ro của hành động downstream, không chỉ dựa vào một điểm confidence duy nhất.

Ưu tiên validator tất định. Nếu AI trả quantity, unitPrice, taxRate và total, hãy tính lại tổng bằng code theo rule kế toán của hệ thống. Nếu AI trả customerCode, kiểm tra trực tiếp trong master data. Nếu output chứa ngày hiệu lực, so sánh với policy và timezone chuẩn của ứng dụng.

Cross-field validation đặc biệt hữu ích vì nhiều lỗi chỉ lộ ra khi đặt các field cạnh nhau. currency = VND nhưng tổng tiền chứa cách diễn giải không tương thích; paymentStatus = paid nhưng không có transaction ID; action = close_ticket nhưng ticket chưa từng ở trạng thái có thể đóng. Những rule này nên được version hóa cùng nghiệp vụ, có test cases và error code rõ ràng để biết gate nào fail.

Nguyên tắc thực tế: càng kiểm tra được bằng hệ thống nguồn thì càng ít nên giao việc xác minh đó cho model. LLM phù hợp để hiểu nội dung mơ hồ; database và business logic phù hợp để xác nhận fact mà hệ thống đã biết.

Một thiết kế tốt nên giữ provenance đủ để trả lời: giá trị này lấy từ tài liệu nào, vị trí nào và phiên bản nào? Với email, đó có thể là message ID và sender thực tế; với PDF là document ID cùng page hoặc vùng OCR; với RAG là source ID/chunk được phép sử dụng.

Sau đó validator có thể kiểm tra field trọng yếu với evidence. Ví dụ số hợp đồng phải xuất hiện trong tài liệu được phê duyệt; vendor phải map về một vendor ID có thật; địa chỉ email phải đối chiếu header gốc thay vì tên hiển thị. Nếu nguồn không cung cấp dữ liệu, output nên biểu diễn trạng thái unknown/not_found theo contract thay vì ép model đoán một giá trị hợp lệ.

Microsoft Foundry tách các phép đánh giá như groundedness, relevance và completeness vì chất lượng câu trả lời không thể suy ra chỉ từ cấu trúc output. Với extraction workflow, cùng tư duy đó có thể được áp dụng ở cấp field: kiểm tra evidence và ground truth cho các thuộc tính quan trọng.

Đừng biến validation thành boolean duy nhất. Một pipeline production thường cần phân loại nguyên nhân: schema fail, missing evidence, business-rule conflict, source unavailable hoặc ambiguous extraction. Từ đó mới quyết định retry có ích hay không. Retry cùng input nhiều lần không sửa được một master-data conflict; nó chỉ tăng chi phí và có thể tạo ra kết quả khác khó audit.

Có thể auto-accept khi các field bắt buộc pass schema, pass deterministic checks và có evidence đạt yêu cầu. Nếu lỗi đến từ OCR hoặc parsing tạm thời, retry có giới hạn và idempotency key. Nếu nguồn mâu thuẫn hoặc field critical không có evidence, quarantine/reject và không gọi downstream action. Human review chỉ nên là một nhánh theo risk policy khi doanh nghiệp thực sự cần, không phải điều kiện bắt buộc cho mọi workflow.

NIST AI RMF nhấn mạnh validity/reliability cần được đánh giá bằng testing và monitoring trong vận hành; mức kiểm soát cũng nên phản ánh hậu quả của failure. Đây là lý do cùng một model nhưng gate cho phân loại email có thể nhẹ hơn gate cho thay đổi quyền hoặc giao dịch tài chính.

Tạo một bộ ground-truth từ các input đại diện cho dữ liệu thật: file rõ, file xấu, tiếng Việt có dấu/không dấu, nhiều template, field thiếu, giá trị gần giống nhau và các edge case đã từng gây lỗi. Với mỗi sample, lưu expected output cho những field cần đo.

Theo dõi ít nhất: schema pass rate, exact/normalized match cho critical fields, false-accept rate, false-reject rate, missing-evidence rate và tỷ lệ phải retry/quarantine. Với số tiền hoặc ngày, dùng comparator đúng domain thay vì text similarity. Tách metric theo nguồn/template để tránh trung bình tổng che khuất một nhóm dữ liệu đang lỗi.

Đưa bộ eval vào CI khi đổi prompt, model, OCR, schema hoặc business rules; sau deploy tiếp tục sampling và monitoring production. Microsoft Foundry cũng mô tả evaluation, monitoring và tracing như các phần bổ trợ nhau để phát hiện output không chính xác, không grounded hoặc suy giảm chất lượng theo thời gian.

JSON Schema có phát hiện AI đọc sai số tiền không?

Không nếu số tiền sai vẫn thỏa kiểu và range đã khai báo. Hãy tính lại từ line items khi có thể hoặc đối chiếu giá trị với evidence trong tài liệu nguồn.

Có nên tin trường confidence do AI tự trả về?

Không nên dùng nó như bằng chứng duy nhất. Confidence phù hợp làm một signal routing khi đã được hiệu chỉnh bằng eval, nhưng vẫn cần source evidence và deterministic checks cho field quan trọng.

Gọi AI lần hai để kiểm tra AI lần một có đủ không?

Không. Lần hai có thể giúp phát hiện bất đồng nhưng vẫn có thể lặp lại cùng lỗi. Nếu fact tồn tại trong database, API hoặc tài liệu nguồn, hãy xác minh trực tiếp ở đó.

Khi nào nên retry?

Retry khi lỗi có khả năng tạm thời hoặc có chiến lược khác thực sự tạo thêm thông tin, chẳng hạn OCR lại với pipeline khác. Không retry vô hạn với business-rule conflict hay source không có dữ liệu.

Có cần human review mọi output không?

Không. Low-risk output có thể auto-pass nếu vượt qua gates. Với critical action, review có thể là một control theo chính sách rủi ro; quan trọng nhất là hệ thống không tự hành động khi điều kiện chấp nhận chưa đạt.