零結果與低信心的處理：RAG 的失敗體驗設計

RAG 一定會遇到查不到的情況。多數系統這時的行為是：模型硬答一個看似合理的答案。這比明確說「查不到」傷害更大，因為使用者無法分辨。

好的失敗體驗要做到三件事：明確承認、解釋為什麼、給出下一步。

區分三種失敗

零結果：檢索完全沒有命中。通常是內容缺口或用詞差太多。
低信心：有結果但相似度都很低。可能是問題太模糊。
有結果但不足：片段相關但不含答案所需的具體資訊。

def diagnose(hits, threshold_low=0.35, threshold_ok=0.55):
    if not hits:
        return 'no_result'
    if hits[0].score < threshold_low:
        return 'low_confidence'
    if hits[0].score < threshold_ok:
        return 'weak'
    return 'ok'

各自的回應策略

零結果 → 說明查無資料，列出系統涵蓋的文件範圍，並提供聯絡管道。
低信心 → 請使用者補充資訊，並主動提出兩三個可能的澄清問題。
有結果但不足 → 呈現找到的相關段落，明說「以下段落可能相關，但未直接回答你的問題」。

主動提出澄清問題

CLARIFY = '''使用者的問題檢索結果不佳。根據以下**部分相關**的片段，
提出 2-3 個能幫助縮小範圍的澄清問題。

規則：
- 問題必須具體、可用是非或選項回答。
- 不要問使用者「你想知道什麼」這種空泛問題。

使用者問題：{q}
部分相關片段：{chunks}'''

把失敗轉成內容改善

每一次零結果都是一個內容需求訊號。把它們自動彙整成清單，依出現頻率排序，交給知識管理者。這條回饋迴路是 RAG 系統能持續變好的關鍵，而多數團隊都沒有建立。

# 每週產出
SELECT normalized_query, COUNT(*) AS n
FROM qa_logs
WHERE status IN ('no_result', 'low_confidence')
  AND ts > NOW() - INTERVAL '7 days'
GROUP BY normalized_query
HAVING COUNT(*) >= 3
ORDER BY n DESC;

失敗回應裡放一個「這題應該有答案」的回報按鈕。使用者按下去的那些查詢，就是最高優先的內容缺口。