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

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.