RAG作為模組化服務：為什麼檢索應該是基礎設施，而非嵌入式程式碼

沒有人會把資料庫驅動邏輯嵌入HTTP處理程式中然後稱其為架構。資料庫在幾十年前就成為了基礎設施——被抽象在連線字串、查詢介面和託管服務之後。但出於某種原因，大多數使用檢索增強生成建構系統的團隊正在做等同於將SQL直接硬編碼到路由處理程式中的事情，只不過這裡的「SQL」是分塊邏輯、嵌入呼叫、向量搜尋配置和重新排序啟發式方法，全部糾纏在不應該了解這些內容的應用程式碼中。

這就是當今大多數RAG實作核心的耦合問題，它正在悄然製造與產業花了多年學會用資料庫、快取和訊息佇列來避免的同類技術債務。

耦合問題

典型的RAG實作看起來大致如此：應用程式接收使用者查詢，應用程式碼呼叫嵌入模型將查詢向量化，應用程式碼使用特定搜尋參數查詢向量資料庫，應用程式碼套用重新排序或過濾邏輯，應用程式碼用檢索到的上下文建構提示詞，然後應用程式將該提示詞傳送給LLM。

每一個步驟都在應用程式內部。分塊策略、嵌入模型選擇、相似度閾值、檢索文件數量、重新排序演算法——所有這些都嵌入在應用程式碼中，通常分散在多個檔案和函式中。

現在考慮當你需要變更這些決策中的任何一個時會發生什麼。

你從一個嵌入模型切換到效能更好的新模型。這是一次應用程式部署。你調整分塊策略，因為帶表格的文件被錯誤地分割了。應用程式部署。你新增中繼資料過濾器以限制檢索最近90天的文件。應用程式部署。你新增重新排序步驟以提高精確度。應用程式部署。

每一次檢索改進都需要完整的應用程式發布週期。檢索管線和應用程式共享相同的部署邊界、相同的CI/CD管線、相同的回滾程序。重新排序邏輯中的錯誤可能導致整個應用程式當機。分塊策略中的退化需要回滾在同一版本中發布的應用程式功能。

這不是理論上的擔憂。建構生產RAG系統的團隊報告說，檢索調校——調整區塊大小、嘗試不同嵌入模型、微調搜尋參數——佔了持續維護工作的相當大比例。當這些工作與應用程式部署耦合時，它同時拖慢了檢索團隊和應用程式團隊。

資料庫類比

考慮你的應用程式如何與PostgreSQL資料庫互動。你的應用程式不包含查詢計畫器。它不管理索引建立。它不處理儲存引擎決策。它連接到一個端點，透過定義良好的介面傳送查詢，並接收結果。資料庫團隊可以重建索引、升級引擎、變更複寫拓撲和最佳化查詢計畫——所有這些都不需要應用程式團隊部署任何東西。

這種分離存在是因為產業透過痛苦的經驗了解到，將儲存基礎設施與應用程式邏輯耦合會建立脆弱、迭代緩慢且難以理解的系統。

檢索屬於同一類關注點。它是基礎設施。它有自己的效能特性、自己的調校參數、自己的故障模式、自己的版本控制需求。將其視為應用程式碼是一種架構類別錯誤。

RAG作為服務的樣子

RAG檢索API端點將檢索管線與應用程式清晰地分離。應用程式傳送查詢。它接收排序的、相關的上下文。它不知道也不關心上下文是如何檢索的。

在端點背後，檢索服務擁有自己的部署生命週期。檢索團隊可以：

• 替換嵌入模型而無需觸及應用程式。從通用模型轉移到領域特定模型，或完全升級到更新的架構。API契約保持不變。
• 按文件類型變更分塊策略。 法律合約用一種分塊方法，技術文件用另一種，客戶支援記錄用第三種。應用程式永遠不會知道。
• 新增或移除重新排序階段。 從僅使用向量相似性開始，然後加入交叉編碼器重新排序，再新增中繼資料提升。每次變更都是獨立部署。
• 版本化檢索管線。 平行執行v1和v2。將10%的流量路由到新管線。比較檢索品質指標。升級或回滾不需要任何應用程式變更。
• 獨立檢測。 將檢索延遲、相關性評分、快取命中率和嵌入吞吐量作為一等營運指標進行追蹤，與應用程式層級的可觀測性分開。

這就是具有工具呼叫規格整合的RAG管線為AI代理所帶來的能力。代理不包含檢索邏輯。它透過標準化介面呼叫檢索工具。該工具背後的檢索服務可以獨立演進。

為什麼企業需要這種分離

對於評估本地部署RAG服務的企業團隊，檢索基礎設施與應用程式碼之間的分離不是可選的——它是治理要求。

可稽核性。 當檢索是一個獨立服務時，你可以準確稽核任何給定查詢檢索了什麼。你可以記錄檢索管線版本、考慮的文件、排序評分以及傳遞給模型的最終上下文。這個稽核記錄存在於檢索服務中，而不是分散在應用程式日誌中。

存取控制。 不同的文件集合可能有不同的存取策略。檢索服務可以集中執行文件層級權限，而不是要求每個應用程式圍繞檢索內容實作自己的存取控制邏輯。

資料駐留。 當檢索管線是可部署的服務時，你精確控制它在哪裡執行。本地部署檢索層意味著嵌入、向量和文件內容永遠不會離開你的基礎設施，即使應用程式層使用雲端託管的LLM進行生成。

獨立擴展。 檢索工作負載和生成工作負載有不同的資源特性。嵌入和向量搜尋是運算密集但速度快的。LLM生成更慢且記憶體密集。當這些是獨立服務時，你可以根據各自的實際資源需求獨立擴展。

Ertas如何將檢索視為基礎設施

Ertas將檢索視為一個可部署的管線，在架構上與消費它的應用程式分離。檢索管線——文件擷取、分塊、嵌入、索引和搜尋——是一個託管服務，有自己的配置、版本控制和部署生命週期。

當Ertas驅動的應用程式或代理需要上下文時，它透過定義的介面呼叫檢索管線。應用程式指定它需要什麼：一個查詢、可選過濾器、期望的結果數量。管線處理如何滿足該請求，包括使用哪個嵌入模型、如何搜尋、是否重新排序以及查詢哪些文件集合。

這意味著管理文件擷取和檢索品質的團隊可以獨立於建構面向使用者應用程式的團隊進行迭代。分塊策略可以改進。嵌入模型可以升級。新的文件集合可以被索引。這些變更都不需要重新部署應用程式。

對於本地部署的團隊，檢索管線完全在其基礎設施內執行。文件內容、嵌入和向量索引留在現場。管線可以配置為與組織現有的文件儲存協同工作，從檔案共享、內容管理系統或內部資料庫中提取，無需將資料遷移到外部服務。

架構原則

這裡的模式並不新穎。它與推動資料庫、快取、訊息佇列和認證服務從應用程式碼中分離出來的原則相同。基礎設施關注點值得基礎設施層級的處理：具有定義介面的專用服務、獨立的部署生命週期和專門的營運工具。

檢索就是基礎設施。它一直偽裝成應用程式碼，因為RAG模式相對較新，團隊預設選擇了通往可工作原型的最快路徑。但原型會變成生產系統，生產系統需要架構邊界。

那些早早劃定這條邊界的團隊——將其RAG管線視為模組化的、可獨立部署的服務，而非嵌入應用程式中的程式碼——將更快地迭代檢索品質，以更低的風險部署應用程式變更，並保持對兩個系統更清晰的營運可見性。

那些不劃定這條邊界的團隊最終會得出產業三十年前關於資料庫得出的同樣結論：基礎設施屬於基礎設施，而非應用程式碼。唯一的問題是在做出改變之前累積了多少耦合。