RAG 架構：避免檢索增強生成中的過度工程

檢索增強生成（RAG）經常被過度工程化，開發者往往直接跳到嵌入和向量資料庫，而實際上更簡單的資訊檢索方法往往更為有效。最佳架構取決於資料新鮮度、語料庫特性、查詢模式和規模，但大多數系統都可以使用全文檢索結合基於 LLM 的查詢改寫來成功實作。

RAG 架構的決策框架

選擇正確的檢索策略需要評估五個關鍵技術因素，以避免不必要的複雜性：

• 資料新鮮度： 即時更新有利於輕鬆重新索引；穩定的語料庫允許預先嵌入。
• 語料庫特性： 高變動率（每日變更超過 10%）使得全面預先嵌入變得不切實際。
• 查詢模式： 重關鍵字的查詢需要全文檢索，而對話式查詢則受益於嵌入。
• 規模與效能： 每日查詢次數少於 1,000 次的系統通常不需要全面最佳化。
• 團隊能力： 沒有 ML 專業知識的團隊應優先使用全文檢索和查詢改寫，而不是混合或進階的嵌入管線。

RAG 實作方案

檢索策略應逐步實作，只有在資料證明較簡單的方法不足時，才轉向更複雜的架構。

1. 全文檢索 (BM25)

使用 Elasticsearch 或 Postgres 等工具進行全文檢索，是關鍵字式查詢和精確比對（例如「invoice #12345」）最有效率的起點。

• 優點： 零 API 成本、低於 10ms 的延遲、易於除錯，且不需要分塊策略或複雜的評估。
• 缺點： 無法捕捉同義詞或語意意圖（例如「car」與「automobile」）。

2. 帶查詢改寫的全文檢索

使用 LLM 將對話式使用者查詢轉換為乾淨的關鍵字搜尋，透過解決查詢構成問題而非檢索問題，解決了許多「語意搜尋」的問題。

• 機制： LLM 移除停用詞、加入同義詞、翻譯特定領域的術語，並分解複雜的查詢。
• 效益： 如果結果不佳，開發者可以調整系統提示，而不是重新嵌入整個語料庫。這對於通用嵌入模型經常誤解的專有術語特別有效。

3. 混合搜尋 (BM25 + 嵌入重新排序)

此方法使用 BM25 檢索廣泛的候選集合（前 50-100 名），然後使用嵌入對前 10 名進行重新排序。

• 權衡： 這會增加 200-500ms 的延遲，但能捕捉關鍵字搜尋遺漏的語意。
• 複雜度： 需要導入分塊策略（固定大小與語意分塊）和重疊管理。

4. 即時嵌入

對於高變動率資料（每日更新超過 10%）或即時內容，文件是在查詢過程中進行嵌入，而不是預先嵌入。

• 優點： 完美的資料新鮮度和輕鬆的模型切換；更改嵌入模型只需更改一行程式碼，而無需重新索引數百萬份文件。
• 缺點： 較高的查詢延遲（200-500ms）且僅限於小型重新排序集合（K=20-50）。

5. 熱/冷分層

此架構會預先嵌入頻繁存取的文件（「熱層」），並即時嵌入極少存取的文件（「冷層」）。

• 效益： 最佳化存取模式的帕累托分佈（即 20% 的文件獲得 80% 的流量），平衡延遲與靈活性。

6. 全面預先嵌入

預先嵌入整個語料庫並將其儲存在向量資料庫中以進行近似最近鄰居（ANN）搜尋，僅在超大規模（每日超過 1 萬次查詢）且語料庫非常穩定的情況下才合理。

• 風險： 模型棄用是一項重大負擔。切換模型需要重新嵌入整個語料庫，這涉及高昂的運算成本、停機時間和廣泛的迴歸測試。

Agentic RAG 與查詢分解

包含多重意圖的複雜使用者查詢（例如「讀取 CSV、清理資料並繪製結果」）應分解為子查詢。Agentic 系統會拆解查詢，將每個子查詢路由到最佳的檢索方法（例如，部分使用簡單的關鍵字搜尋，其他使用嵌入），並合併結果。

這種分解通常比嘗試改寫單一複雜查詢並嵌入大量文件要便宜得多且更準確。

社群見解與反面觀點

業界從業人員強調，向量搜尋的營運負擔經常被低估。

「語意相似性並不如你想的那麼好……你不可避免地最終必須重新嵌入更多或不同的文字區塊，以適應越來越精確的嵌入搜尋……然後你轉過身來，建立一個包含 500 個關鍵字的搜尋查詢，這當然很痛苦，但它就是有效。」

其他專家建議，對於程式碼編寫等特定領域，如果檢索傳回模型信任而非實際原始碼的誤導性區塊，可能會適得其反。在這種情況下，結合 LLM 代理的簡單工具（如 grep 或 ripgrep）可能比基於向量的 RAG 管線更可靠。

實作路徑摘要

策略	新鮮度	複雜度	延遲	最適用於
全文檢索 + 改寫	完美	低	<50ms	60% 的使用案例
即時嵌入	完美	低	200-500ms	高變動率資料
熱/冷分層	混合	中	50-100ms	多變的存取模式
全面預先嵌入	過時	高	<50ms	超大規模，穩定資料