Khi nào AI phải từ chối trả lời? Thiết kế cơ chế abstention an toàn

AI phải từ chối trả lời khi không thể tạo câu trả lời vừa đúng, có căn cứ, đúng quyền và an toàn trong phạm vi được giao. Với AI Assistant hoặc RAG của doanh nghiệp, các trường hợp điển hình gồm: không tìm thấy bằng chứng đáng tin cậy; dữ liệu mâu thuẫn hoặc hết hiệu lực; câu hỏi ngoài phạm vi; người hỏi không có quyền xem; yêu cầu chứa dấu hiệu prompt injection; hoặc câu trả lời có thể dẫn đến hành động tài chính, pháp lý, y tế hay vận hành quan trọng mà chưa được xác minh.

Từ chối không có nghĩa là kết thúc cuộc hội thoại. Hệ thống nên chọn một trong bốn kết quả: trả lời có trích dẫn, hỏi lại để làm rõ, từ chối có lý do, hoặc chuyển cho người có trách nhiệm. Đây là một quyết định nghiệp vụ có thể kiểm thử, không nên giao hoàn toàn cho cảm giác “tự tin” của mô hình.

Mô hình ngôn ngữ tối ưu cho việc tạo câu tiếp theo hợp lý, không tự động biết dữ liệu nào là nguồn sự thật của doanh nghiệp. RAG giúp đưa tài liệu liên quan vào ngữ cảnh và giảm khả năng bịa thông tin, nhưng không bảo đảm truy xuất luôn đúng hoặc tài liệu luôn còn hiệu lực. Azure định nghĩa groundedness là mức câu trả lời bám vào nguồn được cung cấp; Google cũng nhấn mạnh grounding kết nối đầu ra với nguồn có thể kiểm chứng.

Vì vậy, “không tìm thấy” phải là một kết quả hợp lệ. Nếu hệ thống biến mọi truy vấn thành câu trả lời, nó có thể lấy một đoạn gần giống nhưng sai chi nhánh, suy diễn chính sách không tồn tại hoặc ghép hai tài liệu mâu thuẫn thành một kết luận nghe rất thuyết phục.

Pipeline production nên đánh giá theo nhiều cổng độc lập. Đầu tiên, xác định intent và scope. Tiếp theo, kiểm tra danh tính, tenant, property/branch và quyền với từng nguồn. Retrieval chỉ trả về tài liệu đã được lọc quyền. Sau đó, answerability gate kiểm tra nguồn có trả lời trực tiếp câu hỏi hay không; groundedness gate kiểm tra từng claim quan trọng có được nguồn hỗ trợ; policy gate kiểm tra an toàn và dữ liệu nhạy cảm. Với agent có tool, action gate còn phải kiểm tra tham số, quyền, idempotency và phê duyệt.

Đừng đặt ngưỡng như similarity > 0.8 rồi áp dụng cho mọi nội dung. Điểm số phụ thuộc embedding, index, loại câu hỏi và corpus. Hãy hiệu chỉnh trên bộ câu hỏi thật, gồm cả câu trả lời được, không trả lời được, sai quyền, mơ hồ, dữ liệu cũ và prompt injection. Ngưỡng cho FAQ ít rủi ro có thể khác ngưỡng cho giá, chính sách hoàn tiền hoặc hành động ghi dữ liệu.

Một phản hồi từ chối hữu ích nên có ba phần: giới hạn cụ thể, lý do ở mức an toàn và bước tiếp theo. Ví dụ, nói “chưa có nguồn còn hiệu lực” tốt hơn “tôi không biết”; nói “bạn chưa có quyền truy cập nội dung này” tốt hơn việc hé lộ tên hồ sơ; và với nội dung bị chặn vì bảo mật, chỉ cần nêu không thể hỗ trợ yêu cầu đó rồi đề xuất tác vụ hợp lệ.

Không nên hiển thị similarity score hoặc chain-of-thought cho người dùng. Hệ thống có thể lưu reason code như NO_EVIDENCE, AMBIGUOUS, UNAUTHORIZED, CONFLICTING_SOURCES, PROMPT_INJECTION, HIGH_IMPACT_APPROVAL_REQUIRED trong audit log. Reason code giúp đo lường và cải thiện mà không tiết lộ logic bảo vệ.

Bộ đánh giá cần ít nhất bốn nhóm: câu hỏi phải trả lời, câu hỏi phải hỏi lại, câu hỏi phải từ chối và câu hỏi phải chuyển người. Theo dõi answer correctness, groundedness, citation correctness, abstention precision, abstention recall, false refusal, unsafe answer rate và escalation resolution time. Với agent, thêm unauthorized tool-call rate và action confirmation coverage.

Triển khai theo shadow mode trước: hệ thống ghi quyết định từ chối nhưng chưa tác động trải nghiệm, sau đó so sánh với đánh giá của người có chuyên môn. Canary theo tenant hoặc use case, có kill switch và version cho policy/threshold. Mọi lần thay embedding, chunking, reranker, model hoặc prompt đều phải chạy lại regression set. Microsoft và Google đều cung cấp evaluator cho grounding; doanh nghiệp vẫn cần rubric riêng cho phạm vi và rủi ro nghiệp vụ.

1. AI có nên từ chối chỉ vì confidence thấp?

Không. Confidence thấp là một tín hiệu, không phải quyết định cuối cùng. Hệ thống cần xem bằng chứng truy xuất, phạm vi, quyền và mức độ rủi ro; đôi khi cách đúng là hỏi lại.

2. Không tìm thấy tài liệu có đồng nghĩa thông tin không tồn tại?

Không. Chỉ nên nói hệ thống chưa tìm thấy nguồn đủ căn cứ. Tránh khẳng định chính sách hoặc dữ liệu không tồn tại nếu corpus có thể thiếu.

3. RAG có loại bỏ hoàn toàn hallucination không?

Không. RAG giảm rủi ro bằng cách cung cấp nguồn, nhưng retrieval có thể sai, tài liệu có thể cũ và mô hình vẫn có thể suy diễn ngoài nguồn.

4. Khi nào cần chuyển cho con người?

Khi nguồn mâu thuẫn, người dùng cần ngoại lệ, câu hỏi thuộc chuyên môn có trách nhiệm cao, hoặc hành động nhạy cảm cần phê duyệt.

5. Có nên để mô hình tự quyết định việc gọi tool?

Mô hình có thể đề xuất, nhưng application phải xác thực capability, quyền, schema, policy, idempotency và approval trước khi thực thi.

6. Tỷ lệ từ chối bao nhiêu là hợp lý?

Không có con số chung. Mục tiêu phải được hiệu chỉnh theo use case và chi phí của hai loại lỗi: trả lời sai và từ chối nhầm.