AI chấm bài AI — cái bẫy xác suất

Dùng LLM thứ hai kiểm tra LLM thứ nhất nghe hợp lý, nhưng trong compliance thì đó là canh bạc. Có cách khác — dùng toán.

"LLM-as-a-judge" — đúng mà vẫn sai

Tuần trước, một anh tech lead ở startup insurtech hỏi mình: "Team tao cho Claude kiểm output của GPT — vậy là đủ compliance chưa?"

Câu trả lời ngắn: đủ để demo cho sếp. Không đủ để auditor gật đầu.

Pattern LLM-as-a-judge đang được rất nhiều team áp dụng: dùng model thứ hai đánh giá output model thứ nhất. Thêm một lớp kiểm tra, yên tâm hơn — nghe hợp lý. Nhưng có một vấn đề nền tảng mà ít ai dừng lại suy nghĩ: bạn đang dùng một hệ thống xác suất để validate một hệ thống xác suất khác.

Nói thẳng ra thì giống nhờ một người đoán mò kiểm tra kết quả của một người đoán mò khác. Cả hai đều "nghĩ" câu trả lời đúng, nhưng không ai chứng minh được.

Khoan — chuyện phức tạp hơn bạn tưởng

Trong ngành không có compliance nghiêm ngặt — chatbot nội bộ, tool tóm tắt meeting — thì LLM-as-a-judge hoạt động ổn. Sai một chút cũng không ai bị phạt.

Nhưng bước sang fintech, bảo hiểm, y tế — câu chuyện khác hẳn. Giả sử team bạn xây một AI assistant trả lời câu hỏi bảo hiểm cho khách hàng. Khách hỏi: "Tai nạn giao thông có được bồi thường không?" AI trả lời có. Model judge kiểm tra, cũng gật: "đúng rồi." Nhưng hợp đồng gốc có điều khoản loại trừ mà cả hai model đều bỏ qua — vì chúng suy luận theo xác suất, không đọc hợp đồng theo logic hình thức.

Đây chính là lúc Automated Reasoning checks trong Amazon Bedrock Guardrails bước vào.

Sợi dọc giữ nguyên tấm vải

AWS đưa formal verification — phương pháp chứng minh toán học — vào Bedrock Guardrails. Thay vì để một AI "cảm thấy" output đúng, hệ thống dùng logic hình thức để chứng minh output có nhất quán với bộ quy tắc bạn định nghĩa hay không.

Nghĩ về nó như dệt vải: output của LLM là sợi ngang — chạy nhanh, phủ rộng. Nhưng sợi ngang không thôi thì rời rạc, kéo nhẹ là tuột. Formal verification là sợi dọc — giữ cấu trúc, đảm bảo mỗi sợi ngang nằm đúng chỗ. Thiếu sợi dọc, bạn không có vải — chỉ có đống chỉ.

Kết quả trả về không còn là "có vẻ đúng" mà là "đúng, vì thoả mãn điều kiện X, Y, Z" hoặc "sai, vi phạm quy tắc W" — kèm bằng chứng logic cụ thể, trace được, audit được.

Ở team Việt Nam thì áp dụng ra sao?

Kịch bản 1 — Fintech, phân loại rủi ro theo EU AI Act.

Giả sử team bạn 5 người đang build hệ thống credit scoring có AI. EU AI Act yêu cầu phân loại risk level và document lý do. Dùng LLM-as-a-judge, bạn có một câu "phân loại này hợp lý" — auditor hỏi "hợp lý dựa trên gì?" thì… im lặng. Dùng formal verification, bạn có log: rule R1 (thu nhập trên ngưỡng quy định) = TRUE, rule R2 (không có nợ xấu) = TRUE, kết luận: rủi ro thấp — provably correct, đính kèm proof.

Kịch bản 2 — Insurtech, trả lời quyền lợi bảo hiểm.

Khách hỏi chatbot: "Tôi nằm viện 5 ngày, được bồi thường bao nhiêu?" Thay vì model tự suy luận từ training data, hệ thống map câu hỏi vào bộ policy rules đã encode sẵn, chạy formal check, trả về kết quả có chứng minh. Auditor kiểm tra? Có trace logic từ đầu đến cuối. Không còn cảnh "model nói vậy nhưng em không biết tại sao."

Plot twist: không phải lúc nào cũng cần toán

Trước khi bạn hào hứng đi refactor toàn bộ pipeline — hãy dừng lại. Formal verification chỉ mạnh khi bạn có bộ rules rõ ràng, encode được thành logic. Những task mở, sáng tạo, không có đúng/sai tuyệt đối thì không cần.

LLM-as-a-judge vẫn ổn cho:

Cần formal verification khi:

Thử ngay chiều nay

Nếu team bạn đang dùng Bedrock:

  1. Vào Amazon Bedrock console, mở mục Guardrails
  2. Tạo guardrail mới, bật Automated Reasoning checks
  3. Định nghĩa policy rules — bắt đầu với 5-10 rules đơn giản nhất trong domain của bạn
  4. Test với 20-30 câu hỏi thật từ khách hàng, so sánh output có formal proof và không có

Nếu chưa dùng Bedrock, vẫn áp dụng được tư duy tương tự: tách phần cần compliance ra khỏi phần creative. Phần compliance, thay vì dùng LLM judge, hãy kết hợp rule engine truyền thống với LLM. Open-source đáng xem: OPA (Open Policy Agent) cho policy-as-code, Z3 theorem prover nếu bạn muốn tự build formal verification layer, hoặc Guardrails AI — framework mã nguồn mở để thêm validation layer cho LLM output.

Bẫy kinh điển: encode rules nửa vời

Một team mình biết hào hứng setup formal verification, nhưng chỉ encode được khoảng một phần ba policy rules. Kết quả? Phần lớn câu hỏi của khách rơi vào vùng trắng — không có rule nào cover — hệ thống lặng lẽ fallback về LLM-as-a-judge. Như dệt vải mà chỉ mắc sợi dọc nửa khung: chỗ có sợi thì chắc, chỗ không thì rách toạc.

Bài học: formal verification không phải thứ bật lên rồi quên. Nó đòi hỏi đầu tư nghiêm túc vào việc encode rules đầy đủ, và cập nhật liên tục khi policy thay đổi. Nếu bạn không sẵn sàng maintain bộ rules, thì thà dùng LLM-as-a-judge cho đàng hoàng còn hơn formal verification nửa mùa.

Xác suất hay toán học — cuối cùng thì cũng phải do con người quyết định đặt sợi dọc ở đâu. AI không thay bạn chọn được đâu, yên tâm.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo