Confidence Medium: Vùng nguy hiểm nhất của AI
Tại sao mức độ tự tin trung bình của AI lại là cái bẫy lớn nhất cho các kỹ sư phần mềm và cách xử lý hiệu quả.
Sự thật mất lòng là khi một mô hình AI trả lời bạn với sự tự tin tuyệt đối, nó thường đang nói dối. Nhưng điều làm mình đau đầu nhất trong các hệ thống tự động hóa không phải là sự dối trá đó, mà là trạng thái lấp lửng: Confidence Medium.
Confidence Medium thực sự là gì?
Trong machine learning truyền thống và cả các mô hình ngôn ngữ lớn (LLM) hiện nay, confidence score là xác suất mà hệ thống tin rằng kết quả nó đưa ra là chính xác. Nó được tính toán dựa trên trọng số toán học của các token.
Khi hệ thống trả về Low Confidence, quyết định rất dễ dàng - bạn vứt luôn kết quả đó đi. Khi nó trả về High Confidence, bạn tự tin cho luồng dữ liệu chạy thẳng vào production.
Nhưng Medium Confidence lại là một vùng xám tồi tệ. Nó là trạng thái mà mô hình có đủ dữ kiện để đưa ra một câu trả lời có vẻ hợp lý, nhưng lại không đủ chắc chắn về độ chính xác của các chi tiết bên trong. Đây là nơi các luồng tự động hóa bị gãy và con người buộc phải can thiệp.
Tại sao vùng xám lại tốn kém nhất
Hầu hết mọi người sẽ không đồng ý với điều này, nhưng mình cho rằng output với độ tự tin trung bình tốn kém hơn cả output sai hoàn toàn.
Một kết quả sai hoàn toàn (Low Confidence) bị bộ lọc loại bỏ ngay lập tức ở bước đầu tiên. Nhưng một kết quả ở mức Medium lại đủ tốt để vượt qua các bài test tự động cơ bản. Nó đi sâu vào hệ thống của bạn, yêu cầu một kỹ sư senior phải ngồi đọc lại từng dòng code hoặc từng đoạn văn bản để xác minh.
Nếu bạn đang xây dựng một sản phẩm AI và liên tục gặp phải những kết quả hên xui như vậy từ mô hình, có lẽ bạn nên dừng lại. Bạn có thể đọc bài Mom Test cho AI: Tại sao idea của bạn sẽ fail để thấy rằng đôi khi vấn đề nằm ở việc chọn sai use case ngay từ đầu, chứ không phải do model chưa đủ thông minh.
Lấy dữ liệu từ đâu để biết độ tự tin?
Để đo lường sự tự tin của LLM, các kỹ sư thường dùng tham số logprobs (log probabilities). Theo tài liệu từ https://platform.openai.com/docs, logprobs cho phép bạn xem xác suất của từng token được sinh ra. Bạn cũng có thể tìm hiểu thêm về khái niệm này trên trang https://en.wikipedia.org/wiki/Softmax_function để hiểu cách các mô hình phân phối xác suất.
Phần đo lường và phân tích logprobs này mình hoàn toàn dựa trên tài liệu kỹ thuật chính thức từ các nhà cung cấp API, chưa có điều kiện tự build một hệ thống đo lường độc lập trên quy mô hàng triệu request. Tuy nhiên, nguyên lý chung là khi nhiều token khác nhau có xác suất được chọn gần bằng nhau, mô hình đang ở trạng thái mập mờ.
Góc nhìn từ các model mới nhất
Các mô hình hiện tại xử lý sự lấp lửng này theo những cách rất khác nhau.
Với GPT-5.2, mô hình này có xu hướng “làm mịn” sự không chắc chắn. Nó thường đưa ra câu trả lời với giọng điệu cực kỳ thuyết phục ngay cả khi xác suất logprobs nội bộ ở mức trung bình. Điều này rất nguy hiểm cho các tác vụ lập trình cần độ chính xác tuyệt đối.
Ngược lại, Claude Opus 4.6 của Anthropic lại được tinh chỉnh để minh bạch hơn về giới hạn của nó. Khi ở trạng thái Medium Confidence, Claude thường chủ động chèn thêm các cụm từ rào trước đón sau hoặc yêu cầu người dùng cung cấp thêm ngữ cảnh. Nếu bạn đang phân vân không biết nên dùng nền tảng nào cho dự án, bài so sánh GPT-5.2 vs Claude Opus 4.6: Chọn ai? có phân tích rất chi tiết về hành vi của hai mô hình này.
| Trạng thái | Hành động kỹ thuật | Rủi ro | Ví dụ thực tế |
|---|---|---|---|
| Low Confidence | Drop/Retry tự động | Rất thấp | Rác ký tự, sai định dạng JSON |
| Medium Confidence | Human-in-the-loop | Cao (tốn thời gian) | Code chạy được nhưng sai logic edge case |
| High Confidence | Pass qua CI/CD | Trung bình | Code chuẩn xác (hoặc hallucination hoàn hảo) |
Cách xử lý khi hệ thống lấp lửng
Thay vì cố gắng ép mô hình phải luôn tự tin, bạn nên thiết kế hệ thống để xử lý vùng xám này một cách mượt mà.
- Thiết lập ngưỡng Fallback rõ ràng: Đừng để hệ thống tự động đoán. Nếu điểm logprobs trung bình của một câu trả lời rơi vào vùng xám, hãy tự động chuyển task đó thành bản nháp (draft) và ping qua Slack cho người duyệt.
- Sử dụng Prompt Chaining: Khi nhận được kết quả không chắc chắn, hãy dùng một prompt thứ hai để yêu cầu chính mô hình đó (hoặc một mô hình khác) phản biện lại kết quả vừa tạo. Để hiểu rõ hơn về kỹ thuật này, bạn có thể xem qua Prompt engineering chuẩn kỹ thuật: Trải nghiệm thực tế.
- Điều chỉnh tham số Temperature: Giảm temperature xuống gần 0 có thể giúp mô hình bớt sáng tạo và tập trung vào các token có xác suất cao nhất. Nó không làm model thông minh hơn, nhưng giúp kết quả ổn định và dễ dự đoán hơn.
Câu hỏi thường gặp
Logprobs có phản ánh đúng 100% độ tự tin của mô hình không?
Không. LLM có thể rất tự tin vào một thông tin hoàn toàn sai (hallucination). Logprobs chỉ đo độ tự tin về mặt toán học của việc dự đoán từ tiếp theo, không phải độ chính xác của sự thật ở thế giới thực.
Khi nào nên chấp nhận giữ lại kết quả ở mức Medium?
Khi chi phí cho một lỗi sai là rất thấp. Ví dụ như tính năng gợi ý tag cho bài viết blog hoặc tạo biến thể tiêu đề email marketing. Sai một chút cũng không làm sập hệ thống.
Làm sao để giảm thiểu các kết quả ở mức trung bình này?
Cung cấp nhiều few-shot examples trong prompt của bạn. Ngữ cảnh càng hẹp và ví dụ càng rõ ràng, mô hình càng dễ đẩy xác suất dự đoán lên mức cao.
Kết luận
Chúng ta làm kỹ thuật thường quen với tư duy nhị phân: đúng hoặc sai, chạy được hoặc bug. Nhưng làm việc với AI sinh tạo yêu cầu một tư duy hoàn toàn khác: quản trị xác suất. Vùng lấp lửng không phải là lỗi của mô hình, nó là bản chất của ngôn ngữ. Việc chấp nhận và xây dựng các luồng xử lý riêng cho những kết quả “không chắc chắn lắm” mới chính là ranh giới giữa một ứng dụng AI demo và một sản phẩm thực tế chạy được trên production.