Đánh giá & độ tin cậy

Câu hỏi khó nhất khi đưa LLM vào sản phẩm không phải “làm sao cho nó chạy?” mà “làm sao biết nó đúng?”. Trang này nói về hai mặt của câu hỏi đó: eval (đo chất lượng một cách hệ thống) và hallucination (chế độ lỗi đặc trưng của LLM).

Hallucination (ảo giác)

Hallucination là khi model sinh ra thông tin nghe hợp lý nhưng không đúng - một hàm không tồn tại, một tham số CLI sai, một trích dẫn không có thật, một API version bịa ra.

Nguyên nhân gốc: model được huấn luyện để sinh ra văn bản có xác suất cao, không phải văn bản đúng. Trong phần lớn trường hợp hai thứ trùng nhau, nên ta không thấy vấn đề. Khi chúng lệch nhau, ta thấy ảo giác.

Điểm quan trọng: model không “biết” là nó đang bịa. Không có tín hiệu nội tại nào phân biệt “tôi nhớ điều này” với “tôi đang suy ra điều nghe có lý”. Vì vậy hỏi “bạn có chắc không?” không phải phép kiểm chứng đáng tin.

Nơi ảo giác hay xuất hiện nhất

Tên API, tham số, phiên bản thư viện - đặc biệt với thư viện phát hành sau thời điểm huấn luyện.
Chi tiết cụ thể được yêu cầu chính xác - số dòng, hash commit, ngày tháng, con số thống kê.
Khoảng trống trong dữ liệu được cấp - nếu tài liệu bạn cấp không trả lời được câu hỏi, model có xu hướng “lấp” bằng suy diễn thay vì nói không biết.
Chuỗi dài nhiều bước - một suy luận sai ở bước 3 được coi là sự thật ở các bước sau.

Grounding: cách giảm ảo giác

Grounding là buộc câu trả lời phải dựa trên nguồn có thể kiểm chứng, chứ không dựa trên ký ức của model.

Kỹ thuật	Cách làm
Cấp nguồn thật	`@file`, dán log, đưa URL - thay vì hỏi từ ký ức
Cho phép tự kiểm chứng	Cấp một phép kiểm tra model tự chạy được: test, build, lệnh shell
Yêu cầu trưng bằng chứng	“cho tôi xem lệnh bạn đã chạy và output” thay vì tin lời tuyên bố “đã xong”
Cho phép nói không biết	Nêu rõ trong prompt: “nếu tài liệu không trả lời được, hãy nói vậy”
Citation	Với tài liệu, bật citations để mỗi câu trả lời trỏ về đoạn nguồn cụ thể

Với agent chạy lâu không có người giám sát, một chỉ dẫn cụ thể giúp nhiều:

Trước khi báo cáo tiến độ, hãy đối chiếu từng tuyên bố với một kết quả tool
trong phiên này. Chỉ báo cáo việc bạn chỉ ra được bằng chứng; nếu có thứ
chưa kiểm chứng được, hãy nói rõ điều đó.

Eval: đo chất lượng một cách hệ thống

Eval là một bộ test cho hệ thống LLM: tập input, kỳ vọng đầu ra, và cách chấm. Không có eval, mọi thay đổi prompt là mò trong tối - bạn không biết prompt mới tốt hơn hay chỉ khác đi.

Bốn cách chấm

Cách chấm	Cách làm	Phù hợp cho
Chính xác tuyệt đối (exact match)	So chuỗi hoặc so JSON	Phân loại, trích xuất, output có schema
Chương trình kiểm tra (programmatic)	Chạy test, kiểm exit code, validate schema, so với fixture	Code, output có cấu trúc - đáng tin cậy nhất
LLM-as-judge	Một model chấm output theo rubric bạn viết	Việc mở: văn bản, giải thích, thiết kế
Người chấm	Người đọc và cho điểm	Chuẩn vàng, đắt, chậm - dùng để hiệu chỉnh 3 cách trên

Thứ tự ưu tiên rõ ràng: dùng cách chấm bằng chương trình bất cứ khi nào có thể. Nó rẻ, tất định, và không tự nó cần eval. Chỉ dùng LLM-as-judge cho những gì không lập trình được cách chấm.

LLM-as-judge: các bẫy

Rubric mơ hồ cho điểm nhiễu. “dữ liệu trông ổn” → vô nghĩa. “CSV có cột price kiểu số” → chấm được.
Judge thiên vị output dài. Đặt ràng buộc độ dài trong rubric, hoặc chấm từng tiêu chí riêng.
Judge được yêu cầu tìm lỗi thì sẽ tìm ra lỗi - kể cả khi không có. Nêu rõ ngưỡng: “chỉ nêu thiếu sót ảnh hưởng đến tính đúng đắn hoặc các yêu cầu đã nêu”.
Judge cùng model, cùng ngữ cảnh với writer thì không độc lập. Dùng ngữ cảnh sạch - xem Multi-agent.

Adversarial verification

Với các phát hiện quan trọng (bug, lỗ hổng bảo mật), cách đáng tin hơn LLM-as-judge thông thường: yêu cầu N agent độc lập cố gắng phản biện phát hiện đó, mỗi agent một góc nhìn khác (tính đúng đắn, bảo mật, có tái hiện được không). Chỉ giữ lại nếu đa số không phản biện nổi.

Điểm cốt lõi: prompt của người xác minh phải là “hãy chứng minh điều này sai”, không phải “điều này đúng không?” - hỏi theo cách thứ hai thường nhận được câu “đúng”.

Xây eval cho công việc của bạn

Không cần framework phức tạp. Bắt đầu tối giản:

Thu 10–20 ca thật từ công việc bạn đang làm - gồm cả các ca đã từng sai.
Ghi lại kết quả kỳ vọng cho mỗi ca, cụ thể đủ để chấm.
Chạy lại sau mỗi thay đổi prompt/model/cấu hình. Chỉ giữ thay đổi khi eval không tệ đi.
Mỗi lỗi mới gặp trong thực tế → thêm một ca vào eval. Bộ eval lớn dần theo đúng những chỗ hệ thống của bạn yếu.

Với Claude Code, “eval” của bạn thường chính là bộ test của dự án cộng một vài tác vụ mẫu bạn hay giao. Nếu một thay đổi trong CLAUDE.md không làm các tác vụ đó tốt lên rõ rệt, nó chỉ đang chiếm ngữ cảnh.

Đọc thêm

Best practices - cấp phép kiểm chứng cho agent.
Multi-agent - dùng agent ngữ cảnh sạch để kiểm chứng.
Hooks - biến phép kiểm chứng thành cổng chặn tất định.