幻覺與應對

RAG 的代價與優化策略

每次 RAG 查詢都要額外花錢。不優化，成本會隨用量快速失控。

額外成本來源
文檔向量化
低（一次性）
Embedding 入庫時跑一次，之後複用
問題向量化
低
每次查詢約 0.1 元/百萬 Token
向量檢索
中
大規模知識庫時延遲顯著
Prompt 增大
高
每次多注入 500–2000 Token，LLM 費用倍增 ⚠
最關鍵的優化：先做意圖識別，判斷是否需要 RAG。70% 的對話其實不需要檢索文檔，直接用 LLM 回答更快更便宜。
PM 應對策略
建立檢索命中率評測：知道有多少問題被成功檢索到正確文檔
引用來源強制顯示：讓用戶可核查，也倒逼知識庫質素
定期清洗知識庫：RAG 質素上限 = 知識庫質素
四種優化策略（點擊展開）
關鍵詞觸發（過濾）
節省成本：跳過 30–70% 查詢
先判斷問題是否需要檢索。「今日幾號？」不需要查文檔，直接回答；「我們的退款政策」才觸發 RAG。
實現：用意圖分類器或簡單規則預判斷，跳過不必要的檢索鏈路。
模型路由（分級處理）
整體 LLM 費用降低 60–80%
簡單問題用小模型（便宜），複雜問題才上旗艦模型。避免用 GPT-4 回答「你好」。
實現：問題複雜度分級 + 模型梯隊配置（小模型兜底，大模型按需調用）。
語義緩存
高頻查詢降低 50% 延遲和費用
相似的問題複用同一檢索結果。「退款政策」和「點樣退款」結果幾乎一樣，無需重複查詢。
實現：問題向量相似度 ≥ 0.95 時直接返回緩存，跳過整條 RAG 鏈路。
精準切塊（Chunking 策略）
準確率提高 20–40%
文檔切割粒度影響檢索質素。太大注入冗餘 Token；太小丟失上下文。
最佳實踐：約 512–800 Token/塊，以標題/段落為邊界，保留語義完整性。
還有一條路：讓模型自己去翻
RAG：先切好、先算好向量
檢索是「找相似」，答案在片段裏
  • 適合：語料海量且相對穩定——產品手冊、法規、客服知識庫、歷年工單
  • 適合：問題是「呢件事點規定」，答案散在幾百份文檔的某幾段裏
  • 代價：切塊、入庫、更新一整條流水綫，文檔一改就得重跑
  • 軟肋：只按語義相似度撈，要「精確匹配某個編號」時經常撈不準
工具讀取：grep / glob / read
模型自己決定翻邊個檔案、翻幾遍
  • 適合：語料本來就帶結構又天天變——程式碼倉庫、日誌、當前這台機器上的檔案
  • 適合：要精確匹配（函式名、錯誤碼、訂單號），grep 一把命中，向量檢索反而繞
  • 代價：多輪工具調用，延遲和 Token 都比一次檢索高，且要給模型開讀取權限
  • 軟肋：檔案規模超過模型能翻的範圍就會漏，得靠目錄結構和命名幫它收斂
怎麼選：先問一句「呢份資料有冇天然嘅索引」。 程式碼有檔案路徑和函式名，日誌有時間戳，這類直接給工具讓模型自己翻； 一堆沒結構的 PDF 和網頁，才輪到 RAG 先切塊建索引。兩者也常常混着用—— 先 RAG 找到大致位置，再用工具把那個檔案完整讀一遍。
RAG ≠ 全量檢索。生產級 RAG 系統的核心是「什麼情況下不用 RAG」，做好過濾和路由才是關鍵。知識庫質素 → 檢索質素 → 回答質素，三層缺一不可。