Khi nào LLM nên nói “không chắc”: tự chấm điểm, đo độ tin cậy và đặt ngưỡng chuyển cho người

Đến buổi demo thứ ba tại khách hàng, trưởng bộ phận chăm sóc khách hàng hỏi một câu mà FDE nào triển khai LLM rồi cũng sẽ gặp: “Khi nào con bot này biết là nó không biết, để chuyển cho nhân viên của tôi?” Trả lời “model sẽ tự nói khi nó không chắc” thì nghe xuôi tai trong phòng họp.

Nhưng câu trả lời đó sẽ không trụ nổi qua tuần đầu chạy thật.

Lý do là không thể tin mức tự tin mà model tự nói ra. Năm 2023, Xiong và cộng sự thử nhiều cách prompt để LLM nói ra mức tự tin của mình, và kết quả là model thường quá tự tin. Model nói “Tôi chắc chắn 95%” không có nghĩa là cứ 100 câu như vậy thì 95 câu đúng.

Với FDE, kỹ năng này quyết định một bản demo có trở thành hệ thống mà khách hàng dám đưa vào chạy thật hay không. Ngưỡng chuyển cho người quyết định bao nhiêu việc được tự động hoá và bao nhiêu câu trả lời sai lọt ra ngoài. Bạn cần đo được ngưỡng này, không phải đoán.

Hỏi lại model theo dạng đúng/sai sẽ đáng tin hơn

Có cách tốt hơn là hỏi “bạn chắc bao nhiêu”. LearnPrompting gọi cách này là self-evaluation: dùng LLM để kiểm tra kết quả của chính nó hoặc của một LLM khác. Cách đơn giản nhất là hỏi model một câu, rồi yêu cầu nó kiểm tra câu trả lời vừa đưa ra. Bạn có thể lặp lại vòng này nhiều lần.

Từ năm 2022, Kadavath và cộng sự ở Anthropic đã nghiên cứu một dạng tự chấm có thể đo được, gọi là P(True). Model đưa ra một câu trả lời, rồi ước lượng xác suất câu trả lời đó đúng.

Mấu chốt nằm ở định dạng câu hỏi. Nghiên cứu cho thấy các model lớn có độ tin cậy khá sát với độ chính xác thật trên nhiều loại câu hỏi trắc nghiệm và đúng/sai, với điều kiện định dạng phù hợp.

Vì thế, thay vì đọc con số model tự viết ra, bạn biến bước tự chấm thành một câu hỏi đúng/sai và đọc xác suất của token “Đúng” từ logprobs. Bài nghiên cứu này còn đề xuất P(IK): huấn luyện model dự đoán xem nó có biết đáp án hay không, trước khi có bất kỳ câu trả lời cụ thể nào.

Trong phần lớn dự án FDE, P(True) qua prompt là điểm khởi đầu thực tế hơn.

Một ví dụ đi trọn từ prompt đến ngưỡng

Thử hình dung bạn triển khai một trợ lý trả lời câu hỏi về chính sách hoàn tiền cho một công ty thương mại điện tử. Luồng xử lý gọi model hai lần: lần đầu để trả lời, lần sau để tự chấm.

JUDGE_PROMPT = """Câu hỏi: {q}
Tài liệu: {ctx}
Câu trả lời đề xuất: {a}
Câu trả lời đề xuất có đúng và được tài liệu hỗ trợ không?
(A) Đúng
(B) Sai
Chỉ trả lời A hoặc B."""

def p_true(q, ctx, a):
    out = llm.complete(JUDGE_PROMPT.format(q=q, ctx=ctx, a=a),
                       max_tokens=1, logprobs=True)
    pa, pb = out.prob("A"), out.prob("B")
    return pa / (pa + pb)

def route(q, ctx, threshold):
    a = llm.answer(q, ctx)
    score = p_true(q, ctx, a)
    return ("auto", a) if score >= threshold else ("human", a)

Hàm p_true chỉ chạy được khi API trả về xác suất của từng token. Nhiều API không làm vậy. Khi đó, đừng quay về cách bắt model viết ra con số phần trăm.

Có hai cách thay thế: gọi bộ chấm nhiều lần với temperature lớn hơn 0 và lấy tỷ lệ số lần trả lời “A” làm điểm, hoặc dùng một model mã nguồn mở tự host có trả logprobs cho riêng bước chấm.

Trước khi tin hàm p_true, hãy kiểm tra xem bản thân bộ chấm có bị lệch không. LearnPrompting mô tả kỹ thuật contextual calibration: với một input không có nội dung, model phải cho xác suất khoảng 0.5 cho cả hai nhãn.

Nếu kết quả lệch xa mức đó, model đang thiên về một nhãn. Lưu ý đây là chỉnh độ lệch giữa các nhãn, không giống với việc model tự nói ra mức tự tin.

Áp vào ví dụ trên: đưa “N/A” vào cả ba ô câu hỏi, tài liệu và câu trả lời. Nếu bộ chấm vẫn cho “A” khoảng 0.7, nó đang thiên về “Đúng”, và mọi điểm số bạn đọc sau đó đều bị đẩy lên cao. Khi đó, hãy sửa prompt, đổi thứ tự hai nhãn, hoặc trừ phần lệch này khi chọn ngưỡng.

Ngưỡng là con số đo trên dữ liệu của khách hàng

Một bài khảo sát năm 2024 về abstention (việc model từ chối trả lời) mô tả cách làm phổ biến: ước lượng điểm tin cậy, và cho model từ chối trả lời khi điểm thấp hơn một ngưỡng. Phần khó là chọn ngưỡng, và việc này không thể quyết trong phòng họp.

Tiếp tục ví dụ giả định: bạn lấy 200 câu hỏi thật từ lịch sử ticket và nhờ nhân viên gán nhãn đúng/sai cho từng câu trả lời của bot.

Giả sử ở ngưỡng 0.8, bot tự trả lời 150 câu, đúng 140 câu (khoảng 93%), và chuyển 50 câu cho người. Nâng ngưỡng lên 0.9, bot chỉ còn tự trả lời 110 câu nhưng đúng 107 câu (khoảng 97%), và chuyển 90 câu cho người.

Không có ngưỡng nào “đúng” về mặt kỹ thuật. Câu hỏi bạn cần đặt cho trưởng bộ phận là: 10 câu sai trên 150 câu có chấp nhận được không, hay họ sẵn sàng để nhân viên xử lý thêm 40 câu để chỉ còn 3 câu sai?

Có những câu hỏi điểm tin cậy không bao giờ bắt được

Ngay cả một bộ chấm đã được hiệu chỉnh tốt cũng có giới hạn. Bài khảo sát về abstention xem xét việc từ chối trả lời từ ba góc: câu hỏi, model, và giá trị con người. Nhóm tác giả chỉ ra rằng các vấn đề về giá trị, cũng như việc câu hỏi có lời đáp hay không, rất khó thể hiện qua độ tin cậy của model.

Trong ví dụ hoàn tiền, khi khách viết “tôi sẽ kiện các anh”, vấn đề không nằm ở chỗ model thiếu kiến thức. Model có thể trả lời rất tự tin mà vẫn xử lý sai tình huống.

Tương tự, câu hỏi về một đơn hàng không có trong tài liệu là câu hỏi không có lời đáp, dù model vẫn có thể bịa ra một câu trả lời nghe rất chắc chắn.

Vì thế, hệ thống cần một lớp luật chạy trước model. Các câu có từ khoá pháp lý, khiếu nại, dữ liệu cá nhân nhạy cảm, hoặc các câu mà bước truy xuất không tìm được tài liệu nào, đều được chuyển thẳng cho người. Ngưỡng tin cậy chỉ xử lý những câu còn lại.

Các bước làm tại khách hàng, và những lỗi hay gặp

Trình tự nên làm như sau. Trước hết, ngồi với khách hàng để liệt kê các loại câu hỏi luôn phải chuyển cho người, rồi viết chúng thành luật. Tiếp theo, dựng bộ tự chấm dạng đúng/sai và kiểm tra độ lệch bằng input rỗng.

Sau đó, gom một bộ câu hỏi thật có nhãn, lập bảng tỷ lệ đúng và tỷ lệ tự động hoá ở từng mức ngưỡng, rồi để khách hàng tự chọn mức họ chấp nhận được. Với 200 câu giả định ở trên, thêm một mức 0.7 để khách hàng thấy cả chiều nới lỏng, bảng mang đến buổi họp có thể trông như sau:

Ngưỡng	Bot tự trả lời	Số câu đúng	Độ chính xác	Câu sai lọt ra	Chuyển cho người
0.7	175	158	khoảng 90%	17	25
0.8	150	140	khoảng 93%	10	50
0.9	110	107	khoảng 97%	3	90

Cột “câu sai lọt ra” và cột “chuyển cho người” là hai thứ khách hàng thực sự trả giá: một bên là rủi ro với khách, một bên là giờ làm của nhân viên. Đọc theo hàng ngang, mỗi lần nâng ngưỡng là đổi vài câu sai lấy vài chục ticket cho người xử lý.

Lỗi phổ biến nhất là tin con số model tự khai, đúng điều mà nghiên cứu của Xiong đã cảnh báo. Lỗi thứ hai là chọn ngưỡng theo cảm giác thay vì dựa trên dữ liệu có nhãn.

Lỗi thứ ba là dùng một ngưỡng chung cho mọi loại câu hỏi. Thực tế, câu hỏi về số tiền hoàn có thể cần ngưỡng cao hơn câu hỏi về thời gian giao hàng. Ngoài ra, nhiều đội quên đo lại sau khi đổi model hoặc sửa prompt, trong khi đó chính là lúc phân bố điểm số thay đổi.

Nếu bạn đang chuẩn bị ứng tuyển FDE, hãy đưa đúng phép tính này vào CV hoặc portfolio, chẳng hạn: “thiết kế cơ chế chuyển cho người dựa trên self-evaluation, chọn ngưỡng trên N câu có nhãn, đạt X% tự động hoá với Y% độ chính xác”.

Chủ đề này cũng đáng chuẩn bị trước khi phỏng vấn: hãy luyện cách giải thích bảng ngưỡng của chính bạn trong vài phút, từ cách gán nhãn đến lý do chọn một hàng cụ thể.

Lần tới khi khách hàng hỏi bot có biết lúc nào nó không biết không, đừng trả lời bằng một lời hứa. Hãy mang theo bảng ngưỡng và để họ chọn dòng phù hợp.