LLMOps 5 — Đánh giá & chống ảo giác

Khi bạn đổi một dòng trong system prompt, hoặc nâng cấp từ model cũ sang model mới, câu hỏi đầu tiên phải là: "Nó tốt hơn hay tệ hơn?" — và câu trả lời không được phép là "tôi thử vài câu thấy ổn". Với một trợ lý phục vụ nghiệp vụ ngân hàng, "thấy ổn" là con đường ngắn nhất dẫn tới một câu trả lời bịa quy định gửi thẳng tới khách hàng.

Đánh giá (evaluation) ứng dụng LLM khó hơn đánh giá một model phân loại truyền thống rất nhiều, vì hai lý do cốt lõi: không có một "đáp án đúng" duy nhất, và đầu ra là văn bản tự do. Với bài toán phân loại nợ xấu, mỗi hồ sơ có nhãn 0/1 rõ ràng, tính accuracy/AUC là xong. Với câu hỏi "Điều kiện vay tín chấp là gì?", có mười cách diễn đạt đúng và cũng có mười cách diễn đạt sai một cách tinh vi. Bài này xây dựng một khung đánh giá có kỷ luật cho tình huống đó, và xử lý con quái vật đặc trưng của LLM: ảo giác (hallucination).

Bài này nối tiếp prompt & guardrails và bảo mật/injection, đồng thời làm sâu hơn phần đánh giá đã giới thiệu ở đánh giá LLM cơ bản.

Vì sao cần đánh giá có hệ thống

Cảm tính không sai vì nó "không khoa học" — nó sai vì nó không lặp lại được và không so sánh được. Ba lý do bắt buộc phải đo có hệ thống:

• Đo trước và sau mọi thay đổi. Prompt, model, tham số retrieval, temperature — mỗi thứ đều tác động tới chất lượng. Nếu không có con số baseline, bạn không biết thay đổi vừa rồi cải thiện hay phá hỏng. Đây chính là regression testing cho LLM.
• Chống ảo tưởng "vài ví dụ đẹp". Người ta có xu hướng thử đúng những câu mình biết model làm tốt. Một bộ test cố định, đa dạng, buộc bạn đối mặt với cả các câu khó.
• Ra quyết định có bằng chứng. Khi lãnh đạo hỏi "model mới đắt gấp đôi, có đáng không?", bạn cần trả lời "faithfulness tăng từ 0,82 lên 0,94, tỷ lệ escalation giảm 30%" — chứ không phải "em thấy nó trả lời mượt hơn".

Nguyên tắc vàng: coi eval như một tài sản kỹ thuật, versioned trong git như code, chạy tự động, và là điều kiện gate trước khi lên production.

Hai tầng đánh giá: offline và online

Không có một phép đo duy nhất phủ hết. Ta chia làm hai tầng bổ trợ nhau.

Offline: golden set

Golden set là một bộ ví dụ được tuyển chọn cẩn thận: mỗi ví dụ gồm câu hỏi (kèm ngữ cảnh nếu có) và đáp án hoặc tiêu chí kỳ vọng. Không phải lúc nào cũng là một đáp án chuỗi cứng — với đầu ra tự do, thường là tiêu chí ("phải nêu đúng lãi suất X%, phải trích nguồn, không được khuyên đầu tư").

Xây golden set tốt cần:

• Đa dạng có chủ đích: câu dễ, câu khó, câu mơ hồ, câu ngoài phạm vi (để test khả năng từ chối), câu có bẫy (hỏi số liệu không tồn tại).
• Bắt nguồn từ thực tế: lấy từ log câu hỏi thật, từ khiếu nại, từ các case nghiệp vụ hay gặp.
• Có nhãn của chuyên gia nghiệp vụ, không chỉ của kỹ sư. Cán bộ tín dụng biết đâu là câu trả lời đúng về điều kiện vay.
• Kích thước hợp lý: 50–200 case chất lượng cao còn tốt hơn 2000 case rác. Bắt đầu nhỏ, mở rộng dần khi phát hiện lỗi mới (mỗi lỗi production → thêm 1 case vào golden set để không tái phạm).

Online: dữ liệu thật

Golden set không bao giờ phủ hết những gì người dùng thật sẽ hỏi. Tầng online đo trải nghiệm thực:

• Feedback trực tiếp: nút thumbs up / thumbs down sau mỗi câu trả lời. Rẻ, dễ triển khai, nhưng tỷ lệ phản hồi thấp và thiên lệch (người bực mới bấm).
• Tín hiệu ngầm: tỷ lệ escalation (bao nhiêu % phiên phải chuyển sang nhân viên thật), số lượt hỏi lại/hỏi lại cùng ý (dấu hiệu trả lời không đủ), thời gian phiên.
• Chấm mẫu định kỳ: lấy ngẫu nhiên vài trăm phiên mỗi tuần cho con người hoặc LLM-as-a-judge chấm để theo dõi xu hướng chất lượng.

Các phương pháp chấm điểm

Có bốn nhóm phương pháp, dùng phối hợp tùy mức rủi ro.

1. Đối chiếu tham chiếu (reference-based)

So câu trả lời của model với đáp án chuẩn.

• Exact / rule-based: dùng được khi đầu ra có cấu trúc (một con số, một mã sản phẩm, một JSON). Ví dụ hỏi "hạn mức tối đa của thẻ Gold?" — kiểm tra đúng số là xong.
• Semantic similarity: so bằng embedding (cosine similarity) để chấp nhận diễn đạt khác nhau nhưng cùng nghĩa. Xem thêm RAG & retrieval.
• BLEU / ROUGE: các metric so trùng n-gram vay từ dịch máy và tóm tắt. Hạn chế nặng với sinh văn bản tự do — chúng thưởng cho trùng từ chứ không trùng nghĩa, nên một câu đúng ý nhưng diễn đạt khác có thể bị chấm thấp. Chỉ dùng như tín hiệu phụ, đừng lấy làm chuẩn.

2. LLM-as-a-judge

Dùng chính một LLM (thường model mạnh) để chấm câu trả lời theo tiêu chí bạn cấp. Ví dụ: "Cho câu hỏi, ngữ cảnh nguồn và câu trả lời sau, chấm 1–5 mức độ câu trả lời bám sát nguồn và không bịa; giải thích ngắn gọn."

• Ưu điểm: rẻ, nhanh, mở rộng được (chấm hàng nghìn case tự động), xử lý được đầu ra tự do mà rule-based bó tay.
• Rủi ro cần cảnh giác: LLM giám khảo có thiên lệch — thiên vị câu dài, câu trình bày đẹp, thậm chí thiên vị đầu ra của chính họ hàng model mình. Điểm số có thể trôi khi đổi model giám khảo.
• Cách dùng đúng: (1) prompt chấm phải có rubric rõ ràng và ví dụ chuẩn; (2) hiệu chỉnh bằng cách cho giám khảo chấm một tập đã có nhãn người, đo mức đồng thuận; (3) ưu tiên chấm nhị phân/thang ngắn (pass-fail) thay vì thang 1–100 mơ hồ; (4) cố định model và version của giám khảo để điểm so sánh được qua thời gian.

3. Human evaluation

Con người chuyên gia chấm — chuẩn vàng cho các case rủi ro cao. Chậm và đắt, nên không dùng cho mọi lượt, mà dùng để: gán nhãn golden set, hiệu chỉnh LLM-judge, và soi các câu trả lời trong miền nhạy cảm (tư vấn tín dụng, khiếu nại, tuân thủ). Trong ngân hàng, đây là tầng không thể bỏ với luồng có tác động tới quyết định khách hàng.

4. Rubric / tiêu chí

Dù dùng LLM hay người chấm, cần một rubric thống nhất. Với trợ lý ngân hàng, các chiều điển hình:

Đánh giá RAG với RAGAS

Hệ RAG (Retrieval-Augmented Generation) có hai chỗ có thể hỏng độc lập: retrieval kéo về sai/thiếu tài liệu, và generation trả lời sai dù tài liệu đúng. Cần đo tách hai phần. RAGAS là bộ metric phổ biến cho việc này, đo bốn chiều chính:

• Context precision: trong các đoạn được kéo về, bao nhiêu thực sự liên quan? (retrieval có "nhiễu" không)
• Context recall: thông tin cần để trả lời có nằm trong đoạn kéo về không? (retrieval có "sót" không)
• Faithfulness / groundedness: câu trả lời có hoàn toàn tựa trên context đã kéo về, không bịa thêm? Đây là metric chống ảo giác trực tiếp nhất.
• Answer relevancy: câu trả lời có đúng trọng tâm câu hỏi, không lan man?

Điểm mạnh của RAGAS là chẩn đoán: faithfulness thấp mà context recall cao → lỗi ở generation (model bịa dù có tài liệu); context recall thấp → lỗi ở retrieval/chunking. Chi tiết kiến trúc RAG xem RAG & retrieval.

Ảo giác (hallucination)

Ảo giác là khi LLM tạo ra thông tin nghe rất tự tin nhưng sai hoặc bịa hoàn toàn. Đây không phải bug ngẫu nhiên mà là hệ quả của bản chất model: LLM được huấn luyện để dự đoán từ tiếp theo có xác suất cao, tức tạo văn bản trôi chảy, chứ không phải để "nói sự thật". Khi không biết, thay vì im lặng, nó vẫn sinh ra chuỗi từ hợp lý nhất — và chuỗi hợp lý nhất không đảm bảo là chuỗi đúng.

Các loại ảo giác thường gặp

• Bịa sự kiện (fabrication): dựng ra một chính sách, một điều khoản, một sản phẩm không tồn tại.
• Sai số liệu: đưa lãi suất, hạn mức, phí sai — nguy hiểm nhất trong ngân hàng vì trông y như thật.
• Trích dẫn giả: viện dẫn "theo Thông tư số... Điều..." với số hiệu bịa, hoặc gán một câu cho một tài liệu không hề chứa câu đó.
• Suy diễn quá đà: ghép nối các mẩu đúng thành một kết luận sai (ví dụ suy ra khách đủ điều kiện vay từ vài điều kiện lẻ).

Vì sao xảy ra

Câu hỏi ngoài dữ liệu huấn luyện; ngữ cảnh cung cấp thiếu (RAG kéo về không đủ); prompt mơ hồ khiến model "đoán"; temperature cao khuyến khích sáng tạo; và áp lực nội tại "phải trả lời gì đó" thay vì thừa nhận không biết.

Giảm thiểu ảo giác

Không có "diệt sạch", chỉ có nhiều lớp phòng thủ kéo tần suất xuống mức chấp nhận được:

• Grounding bắt buộc trên nguồn + trích dẫn. Yêu cầu model chỉ trả lời dựa trên tài liệu được cấp, và kèm trích dẫn (nguồn nào, điều nào). Nếu buộc phải chỉ ra nguồn, model khó bịa hơn nhiều.
• Hạ temperature. Với truy vấn dữ kiện, đặt temperature thấp (gần 0) để giảm phần "ngẫu hứng".
• Cho phép "không biết". Ghi rõ trong prompt: "Nếu tài liệu không chứa câu trả lời, hãy nói không có thông tin và đề nghị chuyển nhân viên — TUYỆT ĐỐI không suy đoán." Đây là một trong những cải thiện rẻ và hiệu quả nhất.
• Kiểm tra bám nguồn tự động (guardrail). Sau khi model trả lời, một bước kiểm (bằng rule hoặc LLM-judge faithfulness) đối chiếu mọi khẳng định với nguồn; câu nào không tựa được vào nguồn thì chặn hoặc gắn cảnh báo. Xem guardrails.
• RAG chất lượng cao. Chunking tốt, retrieval đúng, đủ context — vì model không thể grounding trên tài liệu nó chưa nhận được.
• Con người duyệt với luồng rủi ro cao (human-in-the-loop).

Regression testing khi đổi prompt/model

Mỗi lần đổi prompt, model, hoặc tham số retrieval, bạn phải chắc không làm tệ đi những gì đang tốt. Cơ chế: một eval suite chạy tự động trên golden set, tính các metric (correctness, faithfulness, tỷ lệ từ chối đúng...), so với baseline của phiên bản trước.

Đưa nó vào CI: PR thay đổi prompt kích hoạt pipeline eval; nếu metric tụt quá ngưỡng thì fail, không merge. Đây chính là "unit test cho LLM app". Cách tích hợp CI/CD cho ML xem MLOps monitoring & drift.

Vòng lặp khép kín: lỗi phát hiện online → thêm vào golden set → lần sau bị bắt ở offline. Giám sát chất lượng online (dashboard faithfulness, tỷ lệ escalation, drift theo thời gian) là chủ đề của bài 6 — Observability & chi phí.

Ví dụ rubric & prompt chấm (minh hoạ)

Dưới đây là minh hoạ prompt LLM-as-a-judge chấm faithfulness — là text prompt, không phải SQL chạy được:

Bạn là giám khảo đánh giá. Cho:
- CÂU HỎI: {question}
- NGUỒN (tài liệu được cấp): {context}
- CÂU TRẢ LỜI của trợ lý: {answer}

Chấm theo rubric, trả JSON:
{
  "grounded": "pass" | "fail",   // mọi khẳng định trong câu trả lời đều tựa được vào NGUỒN?
  "unsupported_claims": [ ... ],  // liệt kê khẳng định KHÔNG có trong NGUỒN
  "refused_correctly": true|false, // nếu NGUỒN thiếu, trợ lý có nói 'không có thông tin' thay vì bịa?
  "reason": "giải thích ngắn"
}
Chỉ chấm "pass" nếu KHÔNG có khẳng định nào ngoài NGUỒN.

Kết quả JSON này được tổng hợp thành tỷ lệ pass toàn golden set — chính là metric bạn theo dõi qua các phiên bản.

Use case thực tế

Bối cảnh: Team NCB nâng cấp trợ lý nội bộ trả lời cán bộ về sản phẩm vay, đổi từ model cũ sang model mới rẻ hơn 40%. Câu hỏi: chất lượng có giữ được không?

Cách làm:

1. Golden set 120 câu do 3 cán bộ tín dụng gán nhãn: 70 câu nghiệp vụ thật (điều kiện vay, lãi suất, phí), 30 câu ngoài phạm vi (để test từ chối), 20 câu bẫy (hỏi số liệu/thông tư không tồn tại — đáp án đúng là "không có thông tin").
2. Chạy eval suite cả hai model, dùng RAGAS (faithfulness, context recall) + LLM-judge (correctness, refused_correctly), hiệu chỉnh judge bằng 30 câu đã có nhãn người (đồng thuận 92%).

Kết quả minh hoạ:

3. Phát hiện: model mới rẻ hơn nhưng bịa 7/20 câu bẫy — dựng ra "Thông tư số..." không tồn tại, faithfulness tụt. Đây là rủi ro tuân thủ, không chấp nhận được.
4. Hành động: không deploy thẳng. Thêm câu "không biết thì nói không biết" vào prompt + bật guardrail kiểm bám nguồn; chạy lại → từ chối đúng lên 18/20, faithfulness 0,91. Lúc này mới cho lên, tiết kiệm 40% chi phí mà giữ an toàn.
5. Khép vòng: 2 câu bẫy vẫn lọt được đưa vào golden set làm case regression cố định.

Không có eval suite, bản "rẻ hơn 40%" đã lên production và có thể trả lời khách một điều khoản bịa.

Ghi nhớ

• Đánh giá LLM khó vì không có đáp án duy nhất và đầu ra tự do — phải đo có hệ thống, không cảm tính; đo trước và sau mọi thay đổi prompt/model.
• Hai tầng: offline trên golden set (câu hỏi + tiêu chí kỳ vọng, versioned như code) và online trên traffic thật (thumbs, escalation, chấm mẫu).
• Bốn phương pháp chấm: reference-based (BLEU/ROUGE hạn chế cho sinh tự do), LLM-as-a-judge (rẻ, mở rộng nhưng cần hiệu chỉnh & cảnh giác thiên lệch), human eval (chuẩn vàng cho rủi ro cao), và rubric đa chiều (đúng/đủ/an toàn/giọng điệu/bám nguồn).
• Đánh giá RAG bằng RAGAS: context precision/recall (retrieval), faithfulness/groundedness và answer relevancy (generation) — tách được lỗi ở đâu.
• Ảo giác = model nói tự tin nhưng sai/bịa (sự kiện, số liệu, trích dẫn giả) vì nó tối ưu độ trôi chảy chứ không phải sự thật.
• Giảm thiểu bằng nhiều lớp: grounding + trích nguồn bắt buộc, hạ temperature, cho phép "không biết", guardrail kiểm bám nguồn tự động, RAG chất lượng, người duyệt.
• Đưa eval suite vào CI làm gate (regression testing) và giám sát chất lượng online liên tục; mỗi lỗi production → thêm 1 case vào golden set.
• Trong ngân hàng: trợ lý không được bịa quy định/số liệu và luôn trích nguồn — đây là điều kiện tuân thủ, không phải tính năng phụ.