這篇文章整理檢索增強生成（Retrieval-Augmented Generation，RAG）的完整工作流程：從使用者查詢開始，透過向量資料庫檢索相關文件，填入提示（prompt），最終形成回答。我也整理了 RETA-LLM 框架的模組化設計，說明它如何把外部知識整合到語言模型中，以及實作 RAG 時常見的挑戰。
什麼是 RAG 的工作流程？
RAG 的核心流程是：從使用者查詢開始，透過向量資料庫檢索相關內容，把檢索結果填入提示，最終形成回答的整個過程。
RETA-LLM 框架可以看作是實現 RAG 目標的一種具體實現方式，它提供了一套模組化的工具和方法來將外部知識整合到語言模型中，以提升其產生答案的能力。
RETA-LLM Framework 是什麼？
研究論文：<https://arxiv.org/pdf/2306.05212v1>
過去通用的 LLM 增強工具包（如 LangChain）與 RETA-LLM 有所不同，RETA-LLM 專注於檢索增強 LLMs，並提供更多的插件模組。
檢索增強 LLMs 使用兩個模組的檢索和生成策略：
- 根據用戶的請求檢索文件或段落（文件檢索模組）
- 利用這些相關文件作為參考生成答案（答案生成模組）
除了這兩個基本模組外，RETA-LLM 還提供了三個可選模組：
- 請求重寫模組，以使用戶當前的請求更完整和清晰
- 萃取模組，從檢索到的整個文件內容中提取相關段落或片段
- 事實檢查模組，以驗證生成答案中是否存在事實錯誤
這些可選模組可以使 IR 系統和 LLMs 之間的交互更加有效和順暢。RETA-LLM 中 LLMs 和 IR 系統之間的解綁更加徹底，這使得搜索引擎和 LLMs 的定制更加方便。
RETA-LLM 的工作流程是怎麼運作的？
RETA-LLM 的工作流程如下：
- 使用請求重寫模組修改目前使用者請求，使其完整且清晰。由於使用者可能向 RETA-LLM 提出一系列問題，目前使用者請求的語意可能不完整。例如，使用者可能會問「經濟學院怎麼樣？」而歷史請求是「介紹資訊學院的專業」。在這種情況下，使用者的準確意思是「介紹經濟學院的專業」。由於 LLMs 在對話式密集檢索中顯示出出色的重寫查詢能力，RETA-LLM 將當前使用者請求和先前的對話歷史提供給 LLMs 進行重寫。
- 然後，RETA-LLM 使用文件檢索模組根據修訂後的使用者請求從外部語料庫中檢索相關文件。文檔檢索模組是與 IR 系統連接的模組，它從外部知識語料庫中檢索相關文件並傳回前 K 個。
- 接下來，RETA-LLM 使用段萃取模組從檢索到的文件中提取與使用者請求相關的片段，以形成參考文獻。由於 LLMs 的輸入長度限制（通常為 2048 或 4096 個標記），因此不可能直接將所有前 K 個相關文件內容連接起來作為它們產生答案的參考文獻。透過截斷文件內容的瑣碎方法可能會遺失其中的重要資訊。因此，RETA-LLM 重複使用 LLMs 自身從修訂後的請求中提取相關片段。由於一個文件的長度也可能超出限制，RETA-LLM 採用滑動視窗策略逐步擷取片段。在預設配置中，滑動視窗大小和步長設定為 512 和 256。然後，這些片段被連接在一起作為參考文獻。
- 此外，RETA-LLM 使用答案產生模組為使用者請求產生答案。如同先前的研究所建議的，透過提供來自外部語料庫檢索到的參考文獻，LLMs 可以產生更準確的答案。
- 最後，RETA-LLM 使用事實檢查模組驗證產生的答案是否包含事實錯誤，並為使用者要求輸出最終回應。儘管提供了產生的額外證據，LLMs 也可能出現幻覺，有必要設計一個模組進行進一步的事實驗證。由於 LLMs 具有強大的自然語言理解能力，RETA-LLM 將參考文獻和生成的答案提供給它們進行判斷，因此可以決定是否輸出產生的答案，或只是說「我無法回答這個問題」。
請注意，LLMs 的所有輸入都包含在指示或提示中。如圖所示，在 RETA-LLM 中完全解開了 IR 系統和 LLMs 之間的連結。這種分離設計使用戶可以自訂自己的個人搜尋引擎和 LLMs。
知識檢索的過程包含哪些步驟？
- 內建工具增強助手功能：內建的工具可以將上傳的文件中的外部知識與助手功能結合起來，使助手能夠存取並利用這些外部知識來回答使用者的問題。
- 內容分塊、索引和嵌入儲存：上傳的檔案內容將被分成區塊，然後進行索引和嵌入儲存。這意味著文件內容將被切割成較小的片段，每個片段都會被賦予一個特定的標識，並且會轉換成向量表示，以便更有效地處理和檢索。
- 檢索嵌入以回答輸入查詢：當使用者提出查詢時，系統會將檢索嵌入的向量表示以尋找與查詢相關的內容區塊。這些內容區塊中包含的知識將被用來回答使用者的查詢，以提供更準確和全面的答案。
RAG 有哪些常見挑戰？
| 挑戰 | 說明 |
|---|---|
| 檢索模型 | 選擇合適的檢索模型是一項挑戰。不同的檢索模型可能適用於不同的場景，需要仔細選擇以確保檢索的效果和效率 |
| 稠密或稀疏表示 | 稠密表示通常具有更高的維度和更多的資訊，但可能更加計算密集；稀疏表示可能更加高效，但可能會遺失某些細節資訊 |
| 內容區塊的單位 | 區塊的大小和粒度會影響到檢索和處理的效率，需要找到合適的單位來平衡資訊的完整性和處理的複雜性 |
| 類似的參考引入噪音 | 當有多個相似的參考資料時，可能會引入噪音，使系統難以確定哪個參考最相關，影響答案的準確性和一致性 |
| 跨文件引用 | 某些問題需要引用多個文件中的資訊才能回答，增加了檢索和整合資訊的複雜性，需要系統能夠有效處理跨文件的引用和關聯資訊 |
延伸閱讀
- 檢索增強生成（RAG）如何讓 LLM 回答更準確：同樣聚焦 RAG、檢索增強生成，可接著比較不同情境的做法。
- Graph RAG：圖形式的檢索增強生成完整解析：同樣聚焦 RAG、LLM，可接著比較不同情境的做法。
- RAG Parallel Queries 是什麼？並行查詢如何提升 RAG 檢索品質：同樣聚焦 RAG、LLM，可接著比較不同情境的做法。
常見問題
什麼是檢索增強生成（RAG）？
RAG 是一種讓 LLM 在回答前先從外部知識來源（如向量資料庫）檢索相關文件的技術。檢索到的內容會被填入提示中作為參考，使模型能產生更準確、更貼近事實的答案，減少幻覺。
為什麼需要請求重寫模組？
使用者在多輪對話中的提問往往語意不完整，例如只問「經濟學院怎麼樣？」而不包含前文脈絡。請求重寫模組利用 LLM 結合對話歷史，把當前請求改寫成完整清晰的查詢，提高後續檢索的品質。
RETA-LLM 和 LangChain 有什麼不同？
LangChain 是通用的 LLM 增強工具包，而 RETA-LLM 專注於檢索增強 LLMs，提供更多插件模組（如請求重寫、片段萃取、事實檢查）。RETA-LLM 也把 IR 系統和 LLMs 完全解綁，方便使用者分別自訂搜索引擎和語言模型。
為什麼檢索到文件後還需要片段萃取？
LLM 的輸入長度有限（通常是 2048 或 4096 個標記），無法直接塞入所有檢索到的文件內容，直接截斷又可能遺失重要資訊。片段萃取利用 LLM 自身以滑動視窗策略從文件中提取與請求相關的片段，串接成精簡的參考文獻。
事實檢查模組如何減少幻覺？
即使提供了檢索證據，LLM 仍可能產生幻覺。事實檢查模組把參考文獻和生成的答案一起交給 LLM 判斷一致性，決定輸出答案或回覆「我無法回答這個問題」，避免輸出錯誤資訊。
RAG 中稠密表示和稀疏表示該怎麼選？
稠密表示（向量嵌入）維度較高、資訊較豐富，適合語意相似度檢索，但計算成本較高；稀疏表示（如 BM25）效率高，但可能遺失細節語意。實務上常依場景混合使用兩者，兼顧效果與效率。
參考資料
最後更新
2026-08-28（原文發布於 2024-05-01，本文保留原始筆記內容並補上 GEO 結構。）
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2024-05-01