RAG的失敗往往源于檢索層，而非大模型。所以，決策框架、混合流程和可靠的系統護欄，或許是取代“一刀切”向量搜索的正解！

比如，一個內部AI助手在演示時看起來非常棒。向量數據庫連夜吞入數據，接入GPT-4級別的模型，向決策者展示簡潔的問答效果。團隊信心滿滿地啟動了項目。然而，當真正開始提出實際業務問題時，情況就變了。

銷售代表詢問合同續簽日期，卻從錯誤的客戶文件中得到了一段看似自信但完全錯誤的段落。合規官員詢問當前的數據保留政策，得到的卻是2021年的舊版本，且沒有任何免責聲明。開發者查詢了其角色本無權訪問的數據，而助手依然給出了回答。

這并不是模型的錯。 它生成的正是它被設計用來生成的內容：基于檢索層遞交給它的上下文，給出一個自信且流暢的答案。問題在于檢索層拿回了錯誤的文檔、過時的數據以及未經授權的信息，而模型對此一無所知。

RAG的質量不是模型的問題，而是一個檢索架構的問題。 大多數團隊往往在進入生產階段后才發現這一點。

根本原因幾乎總是一樣的：對所有問題都采用單一的檢索方法。 向量搜索通常是默認選項，不是因為它總是對的，而是因為它被視為萬 能答案。結果就是構建了一個在語義相似度上表現出色，但在精確查找、最新數據和訪問控制方面表現極差的系統。

生產級RAG需要的是檢索決策框架（RDF），而不是檢索默認值。方法必須與問題的“形狀”相匹配。 在企業系統中，這種路由還必須考慮實時數據源和受控訪問，而不僅僅是靜態索引。

檢索決策框架，先分類、后動手

不同的問題有不同的形態。詢問特定數字的問題與要求解釋概念的問題，其檢索需求截然不同。關于當前價格的問題與詢問行業情緒的問題也完全不同。

下面的準則將查詢形態映射到具體的檢索方法。即在任何檢索器被調用之前，應先在路由層應用此套路。

1. 當問題需要精確、實時、結構化數據時，請使用SQL

當答案是確定性的，且存在于結構化、關系型數據中時，SQL才是正確的檢索路徑。聚合計算、日期范圍篩選、連接查詢和精確記錄查找都屬于SQL的領域。

“第二季度按產品線劃分的總收入是多少？”

“給我看所有企業合同賬戶的未結支持工單。”

“哪些客戶在90天內未登錄？”

這些問題只有一個正確答案，且它就在某張表里。無論多少語義推理，都比不上一條寫得好SQL查詢。答案非對即錯，通往正確答案的唯一途徑是結構化的真理來源。

SQL在數據新鮮度方面也明顯勝出，因為關系型數據庫在查詢時反映的是當前狀態，而向量索引反映的往往是上一次索引運行時的狀態。對于任何需要關注時效性的問題，SQL是更安全的默認選擇。沒有陳舊風險，因為沒有索引滯后。

提示：不要將類似SQL的LIKE模糊查詢作為默認的企業搜索策略。LIKE執行全表掃描，忽略語言變體和詞界，并在大數據集負載下崩潰。如果你的團隊考慮用LIKE作為全面文本搜索的替代方案，說明需要投資專門的搜索框架，而不是把SQL逼到極限。

2. 當用戶措辭很重要時，請使用關鍵詞/全文搜索

Elasticsearch和其他全文搜索引擎常被忽視，但實際上起著重要作用。當用戶使用的確切詞匯很重要、需要在文檔集合中查找大量信息，或者想根據額外信息篩選結果同時匹配文本時，它非常有用。

“我們對國際SaaS訂單的退款政策是什么？”

“查找所有提及v2 API棄用的文檔。”

“給我看帶有‘企業客戶’標簽的入職指南。”

BM25是大多數關鍵詞搜索引擎使用的排名算法。它展示的是包含用戶輸入準確詞匯的文檔。它還支持提升某些字段權重、根據文檔新鮮度評分以及使用元數據篩選等功能。這些功能在向量存儲中要么缺失，要么做得不夠好。

Elasticsearch不僅僅是一個備用選項，也不是等待被新方法取代的舊技術。其文本分析工具、專用分詞器以及加權不同字段的能力，使團隊能比基于嵌入的系統更好地控制信息檢索。完全從關鍵詞搜索轉向向量檢索的團隊，常在發現結果準確性存在問題后，又不得不回歸關鍵詞搜索。

提示：在向語言模型提供搜索結果前，確保搜索結果是最新的、經過用戶授權的，并且來源可信，因為這些檢查應在生成前進行。

3. 當意圖比準確詞語更重要時，請使用向量檢索

當用戶意圖優先于精確措辭時，帶有文本嵌入的密集向量檢索是理想的選擇，因為它能有效處理同義詞、釋義、跨語言查詢和概念性問題。

“這個季度客戶最不滿意的是什么？”

“總結上個月支持工單升級的主要問題。”

“數據庫連接超時有已知問題嗎？”

這些問題沒有特定的關鍵詞，因為它們可以用多種方式表達；向量檢索通過嵌入模型與語義相似的內容進行匹配，從而有效地捕捉意圖。選擇合適的嵌入模型至關重要，尤其是在法律或醫療等特定領域，經過微調的嵌入模型相比通用模型能顯著提升檢索性能。

提示：向量相似度不等于正確性。僅僅因為一個文本塊的余弦相似度為0.87，并不意味著它準確、最新或與你的問題相關。高相似度表明文本在概念上相關，但這并不保證信息是真實的、最新的或經過驗證的。在與語言模型分享前，務必驗證任何檢索到的上下文。

什么時候SQL、全文搜索和向量檢索？

大多數生產查詢并不完全屬于單一檢索類別。“過去30天內影響企業賬戶的主要問題有哪些？”這個問題需要結構化過濾（企業賬戶，30天窗口）、關鍵詞檢索（工單描述、問題類別）和語義分組（聚類類似投訴）。沒有一種檢索器能同時應對這三種情況。

解決方案是一個帶有顯式路由邏輯的混合流水線，建議采用以下7步流程：

步驟1：對用戶意圖進行分類在路由到任何檢索器之前，先對查詢進行分類。輕量級分類器（無論是微調的模型還是快速大模型的結構化提示）將問題分為結構化、主題性、語義性或混合型。這種分類驅動著所有后續決策。跳過它意味著盲目路由。

步驟2：選擇正確的檢索路徑根據分類將查詢發送給其主檢索器。結構化查詢用SQL處理；關鍵詞和主題查詢發送到Elasticsearch；概念性查詢發送到向量數據庫；混合查詢則并行運行多個檢索器。路由不是性能優化，而是正確性的決策。

步驟3：排名前應用元數據過濾器在評分或合并結果之前，應用日期范圍、文檔類型、訪問權限、租戶ID和文檔分類的硬性篩選。排名前進行篩選更高效，更重要的是，可以防止未經授權或無關的文件進入候選庫。不應被看到的文件絕不能送到排名器手中。

步驟4：合并多個檢索路徑中的候選項當多個檢索器并行運行時，將所有候選項收集到一個統一的池中。你現在會看到SQL行、關鍵詞匹配的文檔和向量檢索的文本塊并排出現。下一步決定如何將它們排在一起。

步驟5：重排序（Re-ranking）當你收集了來自不同搜索路徑的結果后，你需要重新排序，看看哪些結果真正能更好地回答用戶的問題。

最實用的方法是使用倒數秩融合（RRF）。它是極好的默認選擇，因為它簡單，不需要復雜的數學來比較不同系統（如SQL和向量庫）的結果。它遵循一個簡單的原理：如果兩個不同的搜索工具一致認為某文檔是#1結果，那么該文檔的得分遠高于僅由單一工具找到的文檔。

對于高精度至關重要的高風險查詢，可以使用交叉編碼器（Cross-encoder）重排序器。這比RRF更準確，雖然會增加一些處理延遲。

步驟6：僅從批準的證據生成只把排名最高的、經過篩選和驗證的文本塊傳遞給語言模型。明確指示模型僅從所提供的上下文中回答，并在上下文不支持自信答案時予以承認。這是一個硬性的架構約束（而不是提示工程的技巧），限制模型可以生成什么。

步驟7：返回引用、來源或可追溯證據每個生成的答案都必須可追溯/可審計，指向特定的檢索來源。顯示文檔標題、最后更新日期、源系統和檢索方法。引用是用戶驗證答案并在檢索失敗演變為決策錯誤前發現問題的方法。

擋住陳舊、越權、胡說的的護欄

護欄不是事后考慮的，它們從一開始就內置在設計中。沒有這些護欄的RAG流程不過是帶有一些文件的“自信幻覺生成器”。以下列出的四類護欄對企業使用至關重要。

1. 新鮮度護欄 (Freshness)

檢索索引中的每個文本塊都必須帶有最后更新的時間戳。在將檢索到的內容傳遞給語言模型之前，確認源文檔是否處于查詢類型的可接受新鮮度窗口內。

價格數據的TTL（生存時間）可能為24小時；

法律和合規政策可能要求30天內更新；

內部知識庫條目可能容忍90天。

如果檢索到的文檔已經過時，不要靜默使用。要么返回警告，要么觸發源系統實時重新獲取，要么誠實地回復當前數據不可用。

2. 權限護欄 (Permissions)

每次檢索調用都必須強制執行請求用戶的訪問權限。在文檔進入候選池之前，按租戶、角色、團隊、文檔分類以及組織使用的其他訪問控制維度進行篩選。

權限必須在檢索層執行，而非呈現層。 檢索文檔后決定不顯示，已經是失敗了。因為該文件已被讀取、處理，并可能影響生成，最終才被壓制。

3. 正確性護欄 (Correctness)

如果頂層檢索的文本塊得分低于定義的置信閾值，流水線不得從中生成答案。返回“我找不到這個問題的可靠答案”，比從一個邊緣相關的部分生成流暢權威的答案要好得多。前者會削弱信心，而后者會破壞信任，而信任更難重建。

當從不同來源檢索到的文本塊相互矛盾時，應明確標記矛盾，而不是讓語言模型默默選擇一方。

4. 行動護欄 (Action)

在代理（Agent）工作流中，檢索往往先于操作。行動護欄確保代理無法對已檢索到的陳舊、模糊、超出范圍或未經授權的信息采取行動。

代理系統采取的每一個操作都必須可追溯到特定的檢索事件、證據和用戶授權。如果無法形成該鏈條，行動就不能繼續。

MCP：當 Agent 需要動真格的時候

在智能系統中，檢索更進一步。客服不僅僅是搜索信息，它使用工具從實時系統中提取數據，啟動業務工作流程，查詢外部API，并代表用戶行動。

模型上下文協議（MCP）正逐漸成為這些工具集成檢索的首選標準。它為代理提供了跨平臺訪問結構化工具（如數據庫、CRM和日歷API）的可靠方式，使語言模型能夠有效推理交互。每個MCP工具調用都作為讀取動作運行，遵循前面提到的四個護欄。

像OutSystems這樣的企業平臺，提供一個AI工作臺，用來從企業數據創建受控的AI應用，非常適合這個領域。這里討論的檢索架構選擇不僅僅是理論，它們決定了企業級AI功能在實際應用中是否可靠，或者僅僅在演示中看起來好看。

當檢索通過受控工具調用從實時企業系統中提取數據時，保持數據的新鮮性變得更容易。沒有過時索引的風險，因為數據在需要時直接從源頭獲取。

結論：RAG架構即檢索治理

企業級 RAG 最大的誤區，就是把檢索當成一個“已解決的問題”——以為向量數據庫往里一放，萬事大吉。事實上，真正的生產級 RAG，是一個檢索治理問題。

你需要一個架構，使工具與問題相匹配，比如：用SQL處理數字、用搜索匹配精確術語、用向量理解概念意義……你必須強制執行權限并檢查數據新鮮度，才能讓數據進入模型。

RAG部署成功與否，不是看你是否擁有最流行的模型，而是從第一天起就把檢索視為一個關鍵且受控的架構層次來設計。 如果你在關鍵時刻構建檢索系統，你的生產系統實際上會變得值得信賴。