這篇文章記錄我們在打造忠台AI智能客服（ https://chungtair.com ）時，解決 RAG 幻覺問題的實作思路。不是教科書，是踩過的坑。

問題背景
標準的 RAG 做法是：用戶問題 → 向量搜尋 → 撈出相關文件 → 丟給 LLM 生成回答。

這個流程在文件品質好、問題清晰的情況下沒問題。但現實是：

中小企業客戶的問法千奇百怪，語意模糊
知識庫裡的文件是老闆自己打的，不夠結構化
一句話裡常常塞了兩三個問題
這些情況下，標準 RAG 的向量搜尋命中率很低，LLM 會用撈到的半相關文件硬湊答案，產生幻覺。

解法一：HyDE（Hypothetical Document Embeddings）
HyDE 的做法是：先讓 LLM 根據問題生成一個「假設性回答」，再用這個假設性回答去做向量搜尋，而不是直接用原始問題去搜。

為什麼這樣有效？因為知識庫裡的文件通常是陳述句（「退貨期限為七天」），而用戶問題是疑問句（「可以退貨嗎？幾天內？」）。語意向量空間裡，假設性答案比疑問句更接近知識庫文件，命中率因此提升。

解法二：Hybrid Search + RRF
向量搜尋擅長語意理解，但對精確詞彙（型號、活動名稱、特定日期）的召回率不如關鍵字搜尋。我們的做法是兩個並行跑，再用 Reciprocal Rank Fusion（RRF）演算法把兩份排名合併：

RRF score = Σ 1 / (k + rank_i)，k 通常設 60。

這個公式讓兩邊都排名靠前的文件得到更高的綜合分數，有效避免單一搜尋方式的盲點。

解法三：複合問題自動拆解
「你們有折扣嗎？運費多少？可以刷卡嗎？」這種問題，如果當作一個查詢去搜尋，通常只能命中其中一個子主題。

我們在 Query Rewriting 這一層加入複合問題偵測：用 LLM 判斷問題裡有幾個獨立意圖，有的話拆開來分別跑 RAG，再把多個答案組合成多段回覆。這個偵測和拆解在同一個 LLM 呼叫裡完成，避免多一次 API 成本。

整體架構
FastAPI + PostgreSQL（pgvector）+ Redis + MongoDB。向量模型用 OpenAI Embeddings，LLM 推理用 GPT-4o。目前部署在 LINE、FB Messenger、IG、網站 Widget 四個通路。

如果你也在做 RAG 相關的東西，歡迎在留言交流，或到 https://chungtair.com 看看我們的實際產品。