Agent 6 — Kiểm chứng & Eval: ngăn agent tự tin bịa

Vấn đề: agent tự tin nhất khi sai nhất

Một agent báo "Tôi không làm được" thì vô hại — bạn biết mà xử lý. Nguy hiểm là khi nó nói "Đã đối soát xong, khớp 100%" trong khi con số lệch. Model không có cảm giác chắc/không chắc đáng tin cậy: nó sinh văn bản trôi chảy kể cả khi bịa. Với nghiệp vụ ngân hàng — nơi một câu SQL sai có thể dẫn tới báo cáo sai cho ban lãnh đạo hay quyết định tín dụng lệch — thì kiểm chứng không phải tính năng thêm, mà là lớp phòng thủ bắt buộc.

Quy tắc sống còn: đừng bao giờ tin lời agent nói "đã xong" mà không có bằng chứng độc lập.

Hai khái niệm khác nhau: Verification vs Eval

Rất nhiều đội gộp hai thứ này làm một rồi lúng túng. Chúng phục vụ hai mục đích tách bạch:

Nói gọn: verification bảo vệ một lượt; eval bảo vệ cả hệ thống. Một agent có thể qua verification cho lượt hôm nay nhưng vẫn tụt điểm eval sau khi bạn đổi prompt — nên cần cả hai.

Phần I — Verification tại runtime

Có ba lớp, dùng từ rẻ tới đắt và phối hợp chứ không thay thế nhau.

1. Kiểm định tất định (deterministic) — mạnh nhất khi áp dụng được

Dùng thứ không phải LLM để phán xử, vì nó không cãi và không bịa:

• Chạy test / linter / type-check: code do agent viết phải qua test thật.
• Parse & validate cú pháp: câu SQL phải parse được; JSON phải đúng schema.
• Kiểm trên schema thật: mọi cột/bảng trong câu SQL phải tồn tại — tra information_schema.
• So ràng buộc nghiệp vụ: "bút toán phải cân (Nợ = Có)", "DTI ≤ ngưỡng", "tổng phân bổ = 100%".
• Đối chiếu nguồn: mọi con số trong câu trả lời phải truy được về một truy vấn/tài liệu gốc.

Đây là lớp đáng đầu tư nhất: nơi nào biến được "đúng/sai" thành phép kiểm tất định thì đừng để LLM tự chấm.

2. Self-check có kỷ luật — cần, nhưng KHÔNG đủ một mình

Yêu cầu agent tự rà lại theo một checklist rõ ràng trước khi chốt: "Kiểm lại: đã JOIN đúng khoá chưa? Có lọc trùng chưa? Đơn vị tiền tệ có nhất quán không?". Self-check bắt được lỗi cẩu thả và rẻ. Nhưng nó là tự chấm bài mình — model dễ hợp lý hoá cái sai của chính nó, nên không bao giờ dùng self-check làm lớp cuối cho việc quan trọng.

3. Adversarial verification — nhiều verifier độc lập cố phản bác

Đây là lớp mạnh cho phần "mềm" mà kiểm tất định không phủ hết (ví dụ: câu SQL chạy được nhưng có trả lời đúng ý câu hỏi không?). Ý tưởng:

• Dùng nhiều verifier độc lập, mỗi verifier được nhắc "cố PHẢN BÁC" kết luận thay vì tán thành.
• Mặc định coi là sai nếu verifier không chắc — bộ lọc nghiêng về bác bỏ.
• Perspective-diverse: mỗi verifier soi một góc khác nhau (một soi logic nghiệp vụ, một soi tính toán/đơn vị, một soi rò rỉ/bảo mật) — đa dạng góc nhìn bắt được nhiều loại lỗi hơn là chạy cùng một prompt N lần.
• Bỏ phiếu đa số: chỉ giữ kết quả nếu nó sống sót qua đa số verifier.

Cơ chế "cố phản bác + mặc định sai" quan trọng: nếu bạn hỏi model "câu này có đúng không?" nó có xu hướng gật; nhưng nếu giao nhiệm vụ "tìm cho ra lý do câu này SAI", nó chuyển sang chế độ phản biện và lôi ra lỗi mà tác giả không thấy. Đây chính là mẫu evaluator–optimizer mà Anthropic mô tả trong "Building effective agents", và khi nhiều verifier là các agent riêng thì đó là một dạng orchestration — xem Agent 7 — Multi-agent & Orchestration.

Phần II — Eval: đo chất lượng hệ thống

"Tôi thấy nó chạy tốt" không phải thước đo. Nguyên tắc nền: không đo thì không cải thiện — và eval là cổng ra prod.

Bộ eval cố định

Một bộ eval là tập case cố định, mỗi case gồm input → kết quả mong đợi (hoặc tiêu chí chấm). Quy trình:

1. Thu thập case sát thực tế: câu hỏi/hồ sơ thật đã có đáp án đúng.
2. Chạy agent trên từng case (giữ nguyên harness của prod).
3. Chấm mỗi case: tất định (khớp/không) khi có đáp án rõ, hoặc rubric khi đầu ra tự do.
4. Tính pass rate = tỉ lệ case đạt, kèm danh sách case fail để soi.

Bộ eval là tài sản của đội agent: nó biến "cải tiến mò mẫm" thành "kỹ thuật có số liệu". Bắt đầu nhỏ (20–50 case) còn hơn không có.

Offline eval + Online monitoring

• Offline (trước prod): chạy toàn bộ eval trước mỗi lần phát hành. Đây là cổng ra prod — pass rate dưới ngưỡng thì không release.
• Online (sau prod): monitoring & tracing trên lưu lượng thật. Log mọi lượt (prompt, tool gọi, input, kết quả, token, độ trễ), gắn trace_id cho cả phiên để dò từ đầu tới cuối. Dashboard theo dõi pass rate mẫu, số bước trung bình, chi phí/phiên, tool hay lỗi. Không có trace, gỡ lỗi agent như mò kim trong đêm (quan sát & chi phí sâu hơn: LLMOps 6 — Observability & Cost).

Regression eval — chống hồi quy

Mỗi khi đổi prompt / đổi model / sửa tool, chạy lại toàn bộ eval và so với baseline. Một chỉnh sửa nhỏ tưởng vô hại có thể làm tụt 5–10% ở một nhóm case. Không có regression eval, bạn "sửa chỗ này hỏng chỗ kia" mà không biết.

LLM-as-judge — mạnh nhưng nhiều bẫy

Khi đầu ra là văn bản tự do (giải thích, tóm tắt), dùng một LLM để chấm rất tiện. Nhưng phải làm đúng:

• Rubric rõ ràng: nêu tiêu chí cụ thể (đúng dữ kiện? đủ ý? có trích nguồn?), yêu cầu judge liệt kê ưu/nhược rồi mới cho điểm — đừng để nó phán "tốt/xấu" trơn.
• Chống thiên lệch: judge hay thiên vị câu dài hơn và câu đứng trước → chuẩn hoá độ dài, xáo thứ tự. Còn có tự thiên vị (model thích văn phong giống chính nó).
• Không dùng judge khi có ground truth tất định: đối soát số thì tính, đừng hỏi model có đúng không.
• Kiểm định lại chính judge: lấy một mẫu cho người chấm, so với judge để biết judge có đáng tin không.

Phát hiện ảo giác (hallucination)

Ảo giác là khi agent nêu sự kiện/con số không có trong nguồn. Cách bắt: buộc mọi khẳng định phải grounded — mỗi con số/dữ kiện gắn với một trích dẫn nguồn, rồi kiểm chéo trích dẫn đó có thật và có nói đúng điều đó không. Đây là trọng tâm của LLMOps 5 — Evaluation & Hallucination và LLM 6 — Đánh giá; trong bối cảnh agent, nó nối thẳng với lớp "đối chiếu nguồn" ở phần verification tất định.

Code minh hoạ

Hai đoạn dưới là pseudocode minh hoạ (không phải API thật), ví dụ chạy trên Anthropic SDK với model claude-opus-4-8.

Adversarial verify — N skeptic, biểu quyết đa số

def verify_adversarial(claim: str, evidence: str, angles: list[str]) -> bool:
    """Mỗi verifier soi MỘT góc, được nhắc CỐ phản bác, mặc định sai nếu không chắc.
    Giữ kết quả chỉ khi sống sót qua ĐA SỐ verifier."""
    votes = []
    for angle in angles:                       # perspective-diverse: mỗi góc một verifier
        prompt = (
            f"Kết luận: {claim}\nBằng chứng: {evidence}\n"
            f"Góc soi: {angle}\n\n"
            "Nhiệm vụ của bạn là CỐ BÁC BỎ kết luận trên theo góc soi này. "
            "Tìm lỗi tính toán, dữ kiện bỏ sót, hoặc suy luận sai. "
            "Nếu KHÔNG chắc chắn kết luận đúng, hãy đặt refuted=true.\n"
            'Trả JSON: {"refuted": bool, "reason": str}'
        )
        v = judge_llm(prompt)                  # gọi claude-opus-4-8, parse JSON
        votes.append(not v["refuted"])         # True = verifier này KHÔNG bác được

    survived = sum(votes)
    return survived >= (len(angles) // 2 + 1)  # đa số không bác được → GIỮ

Eval harness nhỏ — chạy bộ test, tính pass rate

def run_eval(agent, cases: list[dict]) -> dict:
    """cases: [{'input':..., 'expected':..., 'check':'exact'|'judge'}]"""
    passed, failures = 0, []
    for c in cases:
        out = agent(c["input"])
        if c["check"] == "exact":
            ok = deterministic_equal(out, c["expected"])   # so tất định
        else:
            ok = judge_with_rubric(out, c["expected"])      # LLM-as-judge có rubric
        if ok:
            passed += 1
        else:
            failures.append({"input": c["input"], "got": out})
    return {"pass_rate": passed / len(cases), "failures": failures}

# Cổng ra prod: chỉ release khi vượt ngưỡng và không hồi quy so với baseline
result = run_eval(sql_agent, eval_set)
assert result["pass_rate"] >= 0.90, f"Chưa đạt cổng eval: {result['pass_rate']:.0%}"

Use case thực tế

Bối cảnh — Trợ lý sinh SQL của NCB. Cán bộ nghiệp vụ gõ câu hỏi tiếng Việt ("tổng số dư theo loại tiền tệ của khách ở Hà Nội"), agent sinh SQL rồi chạy trên read-replica chỉ đọc và trả bảng kết quả. Rủi ro: SQL sai cột, JOIN nhầm khoá, hoặc câu chạy được nhưng trả sai ý → báo cáo lệch. Đội áp hai lớp: verification tại runtime + một bộ eval làm cổng.

Lớp verification runtime cho mỗi câu SQL agent sinh ra, theo đúng thứ tự (fail ở bước nào thì trả lỗi cho agent tự sửa, tối đa 3 vòng):

1. Parse tất định: câu phải parse thành công và là một câu SELECT/WITH (chặn DDL/DML, chặn nhiều câu).
2. Kiểm cột trên schema: mọi bảng/cột tham chiếu phải tồn tại trong information_schema — bắt ngay lỗi "cột customer_name ở bảng accounts" (thực tế phải JOIN customers).
3. Giới hạn dòng: tự bọc LIMIT và đặt statement_timeout để một câu quét bảng không làm nghẽn replica.
4. Chạy thử trên read-replica: EXPLAIN rồi thực thi với timeout; lỗi runtime → loại.
5. Adversarial 2/3: ba verifier độc lập (góc đúng-ý-câu-hỏi, góc logic JOIN/lọc, góc đơn vị & NULL) cố phản bác. Chỉ trả kết quả nếu ≥ 2/3 không bác được.

Một câu qua đủ 5 bước trông như thế này (đúng schema read-only của sandbox):

-- ▶ Chạy được
SELECT a.currency, COUNT(*) AS so_tk, ROUND(SUM(a.balance)::numeric, 2) AS tong_du
FROM accounts a
JOIN customers c ON c.id = a.customer_id
WHERE c.city = 'Hà Nội'
GROUP BY a.currency
ORDER BY tong_du DESC;

Bộ eval — 50 câu hỏi → kết quả kỳ vọng. Đội biên soạn 50 cặp câu hỏi tiếng Việt → tập kết quả đúng (do analyst chốt tay). Chấm tất định bằng cách so tập hàng trả về (chuẩn hoá thứ tự, làm tròn số). Chạy offline trước mỗi lần đổi prompt/model; đặt cổng pass rate ≥ 90%.

Số liệu (minh hoạ, đơn vị hoá theo trải nghiệm triển khai):

Trong đó lớp kiểm cột + chạy thử dập gần hết lỗi hỏng kỹ thuật (cột sai, JOIN gãy), còn lớp adversarial vớt thêm nhóm chạy được nhưng sai ý (JOIN đúng khoá nhưng thiếu điều kiện lọc, nhầm balance với amount). Mỗi lần đổi prompt, regression eval được chạy lại; có lần một tinh chỉnh prompt kéo pass rate từ 92% xuống 88% ở nhóm câu có ngày tháng — nhờ eval mà đội chặn được trước khi ra prod. Kết quả cuối vẫn qua human-in-the-loop: câu SQL và bảng kết quả hiển thị kèm nút "báo sai", và mọi lượt được ghi audit log (xem tinh thần kiểm soát ở Agent 8 — An toàn & Production).

Ghi nhớ

• Verification ≠ Eval. Verification kiểm một kết quả tại runtime (bộ lọc); eval đo chất lượng hệ thống trên bộ test (cổng + thước đo). Cần cả hai.
• Không tin "đã xong" mà không có bằng chứng độc lập — model tự tin cả khi bịa.
• Ưu tiên kiểm định tất định: parse, kiểm schema, chạy test, so ràng buộc, đối chiếu nguồn. Nơi nào biến được đúng/sai thành phép kiểm không-LLM thì đừng để LLM tự chấm.
• Self-check là cần nhưng không đủ — đó là tự chấm bài mình; không dùng làm lớp cuối cho việc quan trọng.
• Adversarial verification: nhiều verifier độc lập, mỗi verifier một góc, được nhắc cố phản bác, mặc định sai nếu không chắc, giữ kết quả chỉ khi sống sót qua đa số.
• Không đo thì không cải thiện. Bộ eval cố định (input → kỳ vọng), tính pass rate, bắt đầu 20–50 case còn hơn không.
• Eval là cổng ra prod; chạy regression eval mỗi khi đổi prompt/model/tool để chống hồi quy.
• LLM-as-judge chỉ cho đầu ra tự do, cần rubric rõ, chống thiên lệch vị trí/độ dài, và không dùng khi đã có ground truth tất định.
• Grounding chống ảo giác: mọi con số/dữ kiện phải truy được về nguồn thật.

Nguồn tham khảo

• Anthropic — Building Effective Agents — mẫu evaluator–optimizer và các workflow agent nền tảng cho phần adversarial verification.
• Anthropic Docs — Reduce hallucinations — kỹ thuật grounding, trích dẫn nguồn và giảm bịa dữ kiện.
• Anthropic Docs — Test and evaluate / Create strong empirical evaluations (mục "Develop your tests") — hướng dẫn xây bộ eval và tiêu chí chấm.
• OpenAI Evals — framework mã nguồn mở để xây và chạy eval cho mô hình ngôn ngữ.
• Zheng et al. (2023), "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" — arXiv:2306.05685, phân tích thiên lệch vị trí/độ dài và độ tin cậy của LLM-as-judge.

Tiếp theo — Agent 7: Multi-agent & Orchestration: khi nào nhiều agent giúp ích (và khi nào phá), các mẫu điều phối orchestrator–workers/parallel/evaluator, cùng cân nhắc chi phí token thực tế.