Vì sao không nên để LLM tự chấm điểm độ tin cậy cho chính nó

Các agent dựa trên LLM ngày càng được giao nhiều việc: viết mã, tóm tắt tài liệu, lập kế hoạch, điền biểu mẫu. Và khi bạn hỏi chúng "bạn tự tin bao nhiêu phần trăm?", chúng cũng sẽ đưa ra một con số. Vấn đề là không có lý do chính đáng nào để tin vào con số đó.

Bài viết dưới đây giải thích vì sao điểm tin cậy do LLM tự sinh ra không đáng tin, và cách thay thế bằng một quy trình có thể kiểm chứng.

Điểm tin cậy thực sự có nghĩa là gì?

Hãy hình dung một người dự báo thời tiết nói: "Tôi tin 70% rằng ngày mai trời sẽ mưa." Con số 70% ở đây là mức độ chắc chắn của họ về dự đoán, dựa trên thông tin họ có: áp suất khí quyển, độ ẩm, hướng gió, ảnh radar, cộng với dữ liệu thời tiết nhiều năm.

Về lý thuyết, việc chuyển thông tin thành con số tin cậy là một phép tính, không phải ý kiến. Nếu hai người dự báo có cùng dữ liệu và cùng áp dụng đúng quy tắc, họ phải ra cùng một con số. Khi họ khác nhau, đó là do khác dữ liệu hoặc một người áp dụng quy tắc sai.

Nếu được hỏi về một ngày cách đây hai tuần, người dự báo chỉ có dữ liệu lịch sử: vào thời điểm này năm nào cũng mưa khoảng 30% số ngày, nên câu trả lời tốt nhất là "30%". Càng gần ngày dự báo, thông tin càng nhiều, con số càng có thể tiến về 0% hoặc 100%.

Làm sao biết một điểm tin cậy có chính xác?

Một ngày mưa hay không không đủ để đánh giá. Phải nhìn trên nhiều ngày: gom tất cả những lần người dự báo nói "70%" lại, nếu trời mưa đúng khoảng 70% số lần đó thì con số của họ đã được hiệu chỉnh (calibrated) đúng.

Ví dụ bảng tổng kết một năm:

• Nói 10% → thực tế mưa 11% số ngày
• Nói 30% → thực tế mưa 29%
• Nói 70% → thực tế mưa 71%
• Nói 90% → thực tế mưa 89%

Đây là một người dự báo tốt. Nhưng hiệu chỉnh đúng thôi chưa đủ: một người luôn nói "30%" theo tỉ lệ trung bình của mùa cũng đạt hiệu chỉnh, nhưng không hề dùng thông tin mới nên con số không có giá trị. Điều kiện thứ hai là điểm tin cậy phải phản ánh lượng thông tin thực sự có — do đó người dự báo tốt phải đưa ra nhiều mức khác nhau, gần 10% hoặc gần 90%, chứ không dồn vào một con số an toàn.

Một điểm tin cậy đáng tin cần hai điều: nó phản ánh lượng thông tin có được, và nó đã được đối chiếu với những gì thực sự xảy ra trên cùng loại câu hỏi.

Vì sao LLM không thể cho điểm tin cậy đáng tin?

LLM sinh văn bản từng token một, mỗi token dựa trên các token phía trước (autoregressive). Khi bạn hỏi "Bạn tự tin bao nhiêu?", câu trả lời "0.85" không được đọc ra từ một chiếc đồng hồ đo bên trong mô hình — nó chỉ là phần tiếp nối hợp lý của đoạn hội thoại.

Điều này kéo theo nhiều hệ quả ai cũng có thể tự kiểm chứng:

• Hỏi lại thì con số đổi. Cùng một câu hỏi có thể ra 0.85 lần này, 0.7 lần sau. Thông tin không đổi thì lẽ ra con số cũng không đổi.
• Đổi cách diễn đạt thì con số đổi. Hỏi "Bạn có chắc không?" thường làm điểm số thay đổi, dù bài toán chẳng khác gì.
• Văn bản phía trước quyết định con số. Nếu mô hình vừa viết "Đây rõ ràng là câu trả lời đúng", thì một điểm cao là phần tiếp nối tự nhiên — con số đi theo câu chữ chứ không theo bằng chứng.
• Lúc nào cũng có con số. Nó luôn trả lời, luôn trông chính xác, và một con số sai trông y hệt một con số đúng.

Đúng là quá trình tiền huấn luyện có chấm điểm mô hình, nhưng kết quả được chấm là token tiếp theo, không phải "điểm tin cậy mô hình viết ra có khớp với tỉ lệ đúng thực tế hay không". Mô hình học được điểm tin cậy trông như thế nào trong văn bản, chứ chưa từng học cách làm cho nó khớp với độ chính xác của mình.

Muốn biết những con số này có đáng tin, cách duy nhất là chấm hàng loạt chúng với đáp án chuẩn. Phần lớn người hỏi LLM điểm tin cậy đều không làm việc đó.

Cách xây dựng điểm tin cậy mà không cần LLM

Giải pháp là làm như người dự báo thời tiết: xây một quy tắc biến thông tin quan sát được thành điểm tin cậy, và liên tục kiểm tra với thực tế. LLM vẫn làm phần việc chính (soạn câu trả lời), nhưng điểm tin cậy đến từ quy tắc.

Ví dụ với một agent trả lời câu hỏi chăm sóc khách hàng bằng cách tra cứu trung tâm trợ giúp, ta muốn câu trả lời nào không chắc chắn thì chuyển cho người thật xử lý:

1. Chọn thông tin quan sát được. Ví dụ: có tìm thấy bài viết phù hợp không, tìm được bao nhiêu bài, loại câu hỏi này agent từng trả lời tốt chưa, hỏi cùng câu hai lần thì hai câu trả lời có khớp nhau không. Đây là "áp suất, độ ẩm, hướng gió" của agent.
2. Bắt đầu từ quá khứ. Nếu 200 câu trả lời trước đã được người kiểm tra và 150 câu đúng, thì mọi câu mới khởi điểm ở mức 75%.
3. Ghi lại mọi câu trả lời và kết quả. Lưu thông tin ở bước 1, điểm tin cậy do quy tắc đưa ra và câu trả lời đó có đúng không. Đây là cuốn sổ mà không có nó thì mọi con số đều vô nghĩa.
4. Cập nhật quy tắc từ sổ ghi chép. Nhóm các câu trả lời cũ theo thông tin quan sát, xem tỉ lệ đúng của từng nhóm. Nhóm "có bài khớp và hai câu trả lời đồng ý" mà đúng 95% thì lần sau gán 95%; nhóm "không tìm thấy bài nào" chỉ đúng 40% thì gán 40%. Ban đầu nhóm còn nhỏ và quy tắc còn thô, càng nhiều dữ liệu càng chính xác.
5. Kiểm tra định kỳ. Mỗi tuần, lập lại bảng như bảng của người dự báo: mỗi mức tin cậy thì thực tế đúng bao nhiêu phần trăm. Nếu nhóm 90% chỉ đúng 70%, quy tắc đang quá tự tin và dữ liệu mới sẽ chỉ ra cách chỉnh.

Khác với con số của LLM, quy tắc này cho cùng thông tin thì cùng kết quả, không phụ thuộc cách diễn đạt, được hiệu chỉnh đúng trên chính loại câu hỏi của bạn, và càng dùng càng tốt lên.

Kết luận

Điểm yếu duy nhất của cách làm này là nó phụ thuộc vào chất lượng sổ ghi chép. Nếu không ai kiểm tra câu trả lời có đúng hay không, thì chẳng có gì để học, và ta lại quay về một con số chưa ai từng đo.

Với các đội ngũ đang xây agent ở Việt Nam, đặc biệt trong chatbot hỗ trợ khách hàng, trợ lý nội bộ hay công cụ xử lý chứng từ, bài học rất thực tế: đừng hỏi mô hình "bạn chắc không?" rồi tin câu trả lời. Hãy định nghĩa rõ tín hiệu quan sát được, ghi log kết quả thực tế, và cập nhật quy tắc định kỳ. Đó là cách duy nhất để "độ tin cậy" thực sự có nghĩa.