到底是什麼使得流利的錯誤答案變得有用呢？是模型本身，還是其背後的證據路徑？當兩個團隊使用相同的模型卻獲得截然不同的結果時，最先改變的是提示還是決定模型所能看到的檢索結果的決策呢？

如果一個支援機器人能夠輕鬆解答錯誤代碼的問題，但卻錯過了只隔著一個文檔的政策例外，那麼首先失敗的是模型，還是它被提供的證據片段？如果那個片段是錯的，那麼更好的模型又怎麼能挽救這個答案呢？

模型無法自主提升的上限

當你詢問大型語言模型（LLM）上週的事件、新政策或在知識截止日期之後創建的客戶關係管理（CRM）記錄時，除非檢索能將證據帶入提示中，否則它只能即興發揮。這正是檢索增強生成（RAG）在知識密集型NLP任務中的基本步驟：將生成根植於當前的外部證據中。

更困難的教訓在後面。更好的模型並不能修正缺失或過時的證據，也不能修正錯誤的上下文。如果檢索器給模型提供了錯誤的簡報，結果就是一個更乾淨的錯誤答案。

這就是上限。AI的使用體驗質量在模型選擇之前，受到檢索質量的強烈限制。如果答案脆弱，那就要問檢索層被允許顯示什麼。

將檢索策略與查詢類型相匹配

最清晰的檢索思維方式不是「什麼是最佳搜索？」而是「這位用戶實際上在問什麼問題？」精確的識別符號需要精確查找；改述的意圖則需要相似度搜索。比較和跟進問題需要周圍的證據，這樣體驗才不會回到搜索框中。

Okapi BM25或關鍵字搜索仍然是正確的選擇，當用戶提到錯誤代碼、庫存單位（SKU）或條款號碼時。當用戶記得概念但不記得文字時，語義搜索更具優勢。混合搜索使用互惠排序融合（RRF）介於它們之間，當企業用戶通過同一界面發送兩種查詢時，將關鍵字和語義排名融合在一起。

考慮一下這些不同之處。對於支援機器人來說，「在密碼輪換後的錯誤18456」應該路由至精確匹配。法律文件和平台工作流則不同：修訂的條款需要語義上下文的支持，而將票據與CRM備註進行比較時，需要足夠的周圍證據以避免幸運地得到頂部結果。

這個選擇會影響體驗。精確檢索感覺像是搜索。更廣泛的上下文感覺像是對話。混合檢索則處於中間，多數企業助手其實正好位於此。

多跳檢索以應對分散的企業知識

一份CRM備註顯示誰擁有帳戶。而一張打開的票據顯示了什麼出錯。任何一次搜索可能能夠顯示出那個故事的片段，但無法顯示整個故事。

這就是多跳檢索的價值所在。系統檢索一個證據片段，並用它來形成下一個查詢，直到從相連的事實中組裝出答案。最近的研究顯示，如HopRAG：多跳推理於邏輯感知檢索增強生成展示了為什麼這種循環在關係相較於詞彙相似性更重要時能夠幫助。

對於企業內容而言，檢索還必須在攝取階段就保留關係。圖形提取通過在用戶發問之前提取實體和關係來豐富知識層。這樣在隨後的跳躍中，對於哪些人、帳戶、票據、產品和文件屬於一起都有更好的地圖。

這種區別在答案依賴於多於一個文檔時是有意義的：

• 支援體驗可以從錯誤代碼開始，然後根據帳戶關係跟進打開的票據。
• 法律助手可以檢索條款及其周圍的段落，同時保留文檔的標題作為上下文。
• 內部助手可以在全篇文檔重要時，傳遞整個短資源。
• 銷售助手可以結合帳戶備註和產品文件，而不假裝這些系統是一個來源。

這一模式並不是「檢索更多」。而是檢索體驗所需的內容：一個標題、一個相鄰的段落、一個完整的資源或附有授權標記的圖形跳躍。

配置和測量檢索層

一旦選擇了策略，你的下一步工作就是操作性：決定什麼樣的搜索模式啟用、什麼證據進入以及當答案開始偏移時你會觀察哪些信號。

Progress Agentic RAG通過為不同任務而建立的應用程式介面（API）介面揭示了這一區別。當調用者需要合併的證據時，使用/find；當調用者需要基於該證據生成的答案時，使用/ask。相同的知識層，不同的體驗。

範圍控制同樣重要。filter_expression可以在答案生成之前依據資源、標籤、日期、文件類型、起源路徑和其他元數據來縮小檢索範圍。這樣就可以保持一個體驗在批准的政策文件內，而另一個則搜索更廣泛的內容。

搜索策略設置處理上下文權衡。文本層次和相鄰段落策略在檢索的片段太過稀薄時添加標題或相鄰的段落。完整資源上下文可以傳遞整個匹配的資源，但Progress的標記消耗指導對這一權衡十分明確：更大的上下文會增加輸入大小，而硬性標記限制可能會降低答案質量。

測量閉合了這一循環。REMi，Agentic RAG的評估層，讓團隊通常在一次雜亂的會議中辯論的問題變得清晰可見。

每個診斷有不同的任務。使用上下文相關性作為檢索信號，固定性作為生成檢查，答案相關性作為問題符合度檢查，並且監控標記消耗作為成本參考。如果模式是漂移，請在責怪模型之前查看這些信號。

這會使下一步動作具體化：先修正上下文再處理提示，當支援不佳時檢查生成，檢查比較或多跳請求的路由，並在標記成本上升時調整上下文大小。

下一步該審計什麼

從一個體驗開始。選擇一個支援機器人或內部助手，並追蹤四個因素：查詢類型、檢索策略、上下文範圍和你將用來觀察質量漂移的指標。

這項審計能給你一個比「模型有問題」更清晰的決策。它告訴你是否應該改變精確匹配、圖形增強跳躍、來源過濾器、上下文大小或測量。模型仍然很重要。它是完成檢索者開始的任務。

常見問題

在企業AI計劃中，誰應該負責檢索質量？

你希望有共同的責任，但不是共同的模糊性。應該指定一名負責檢索層的領導者，通常是平台或數據AI。應用團隊負責基於它構建的體驗，而安全或合規則應當批准過濾器和訪問規則。如果沒有人負責檢索路徑，模型就會成為路由問題的替罪羊。

如何判斷故障是檢索還是生成？

首先查看證據。如果檢索的上下文不正確、薄弱或缺失，那麼問題出現在檢索。如果上下文穩固，但答案仍然漂移，那麼問題就出在生成上。REMi類風格的評分使得這種區別變得可見。

如果以後更改模型，哪些部分應該保持可攜帶？

你的檢索策略、來源過濾器和評估邏輯應該保持可攜。模型可以更改；檢索決策則不應每次都需要重建。保持這些層分開，你就可以在不重新進行堆疊的情況下調整體驗。