RAG 的成敗關鍵：為何你的檢索品質決定了 AI 回答的天花板

許多人在建構檢索增強生成（RAG）系統時，若遇到回答品質不佳的問題，直覺反應是更換或微調大型語言模型（LLM）。然而，這往往是治標不治本。根據我的觀察與實作經驗，RAG 的真正瓶頸，十之八九出在檢索（retrieval）階段。如果從源頭送進來的上下文就是錯誤或不相關的，再強大的生成模型，也只是把垃圾資訊說得更流利而已。我們必須將焦點從生成端轉向檢索端，系統性地提升資訊命中的準確度，這才是提高 RAG 系統天花板的關鍵。

《三國志》RAG 實驗：檢索失準，如何揭示殘酷真相？

為了驗證 RAG 的核心流程，我最近用吉川英治的日文版《三國志》作為知識庫，建立了一個最小化的 RAG 系統。這個專案來自一篇公開的實作紀錄，流程非常典型：

1. 文件載入與切分：讀取《三國志》全文，並將其分割成數百字元的小區塊（chunks）。
2. 嵌入與索引：使用 Embedding 模型將每個 chunk 轉換為向量，並存入 FAISS 這樣的向量資料庫中。
3. 檢索：當使用者提出問題時，將問題同樣轉換為向量，在資料庫中進行相似度搜尋，找出最相關的幾個 chunks。
4. 生成：將原始問題與檢索到的 chunks 一併交給 LLM，由 LLM 綜合這些上下文後生成最終回答。

這個流程看似簡單直觀，但在實際測試中，問題很快就浮現了。例如，當使用者提出一個較為模糊的查詢，或是使用了書中人物的不同稱謂（例如「孔明」與「諸葛亮」），檢索階段就很容易「失手」，找不到最關鍵的資訊。最終，LLM 因為拿到的上下文不對，只能給出含糊其辭甚至錯誤的答案。這個實驗清楚地表明，回答的品質瓶頸，並不在於 GPT-4 或 Claude 3 Opus 不夠聰明，而在於我們餵給它的材料從一開始就錯了。

為什麼檢索會失敗？從查詢理解到表記對齊的挑戰

檢索端的失敗，本質上是機器在「理解」與「對齊」上的失敗。多數基礎的 RAG 系統，僅僅依賴向量的餘弦相似度（cosine similarity）來判斷關聯性，這在處理複雜的真實世界資訊時顯得過於脆弱。常見的挑戰包括：

• 語義模糊與抽象查詢：使用者可能問「劉備最令人感佩的特質是什麼？」。這個問題本身非常抽象，在原文中可能沒有任何一個 chunk 直接描述「令人感佩的特質」。系統需要有能力將這個抽象概念，對應到描述劉備「仁德」、「堅毅」或「三顧茅廬」的具體段落。
• 實體名稱的表記不一（Entity Ambiguity）：《三國志》中的人物常有多種稱呼，如「劉備」也稱「玄德」、「劉皇叔」。如果索引時只記錄了「劉備」，那麼用「玄德」查詢時，最直接的向量比對就可能錯失目標。這在法律文件、醫療紀錄或內部技術文件中更為常見，縮寫、代號與正式名稱混用，是檢索的巨大障礙。
• 不理想的 Chunking 策略：如何切分文件，直接影響了檢索上下文的完整性。一個常見的錯誤是固定長度切分，這很可能將一個完整的因果關係、一段關鍵對話或一個完整的定義從中間切斷。被切碎的資訊，即使被命中，也無法提供足夠的上下文讓 LLM 做出正確推論。根據 LlamaIndex 的一份官方文件，語義切分（semantic chunking）或基於句子邊界的切分，通常比固定大小切分效果更好。

我們必須接受一個現實：如果檢索系統回傳的是垃圾，那麼 RAG 系統產出的，只會是看起來更精緻、更流利的垃圾（eloquently phrased garbage）。

如何建立一個更高品質的檢索系統？

要突破 RAG 的品質天花板，我們需要將檢索視為一個獨立且重要的系統來設計，而不僅僅是 LLM 的一個附屬品。這意味著要引入更複雜、但更精準的檢索策略。學術界與業界已經發展出許多成熟的技術，例如在一篇 2023 年的綜述論文中提到的進階 RAG 技術。

一個更穩健的檢索流程，應該包含以下幾個階段：

1. 查詢重寫（Query Rewriting）
在將使用者的原始查詢送入檢索系統前，先用一個 LLM 對其進行優化。例如，將模糊的問題變得更具體，或將一個複雜問題拆解成多個子問題。一種被稱為 HyDE（Hypothetical Document Embeddings）的技術，會先讓 LLM 針對問題生成一個「假設性的理想答案」，再用這個答案的向量去做檢索，往往能比單用問題向量找到更相關的內容。

2. 混合式搜尋（Hybrid Search）
完全依賴向量的語義搜尋，有時會忽略關鍵字詞的精準匹配。混合式搜尋結合了傳統的關鍵字搜尋（如 BM25）與向量的語義搜尋。前者確保了專有名詞、代號等不會被錯過，後者則負責處理語義上的相似性。許多現代向量資料庫（如 Pinecone）都已內建支援混合式搜尋，讓開發者能兼顧兩者的優點。

3. 重排序（Reranking）
檢索的第一階段可以設計得「寧濫勿缺」，例如一次取回 20 到 50 個候選 chunks。接著，再用一個更輕量、但專門為排序任務訓練的模型（Reranker），對這些候選 chunks 進行第二次排序，篩選出最相關的 3 到 5 個，最後再交給 LLM。像是 Cohere 的 Rerank API 就是專門為此設計的商用服務，能顯著提升最終上下文的信噪比。

總結來說，一個成熟的 RAG 系統，其檢索端不應該只是一個簡單的向量搜尋，而是一個包含查詢理解、多路召回與精細排序的複雜流程。將心力投入到優化檢索品質上，其投資回報率遠高於不斷更換或微調後端的生成模型。

延伸閱讀

• Gao, Y., Xiong, Y., Gao, X., Jia, K., Pan, J., Bi, Y., ... & Sun, H. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997.
• Gao, L., Mazaré, L., Schwartz, A., Min, S., & Lewis, M. (2022). Precise Zero-Shot Dense Retrieval without Relevance Labels. arXiv:2212.10496.
• Pinecone Documentation. (n.d.). Hybrid Search. Retrieved from https://www.pinecone.io/learn/hybrid-search/

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。