RAG管道架構：將索引與檢索作為獨立關注點

典型的RAG教學在同一個腳本中開始和結束：載入文件，分塊，嵌入，儲存到向量資料庫，然後在推論時查詢該資料庫。整個過程在一個程序中執行。這對展示來說可以。但對生產環境不行。

生產RAG系統面向真實使用者，處理不斷變化的真實資料。文件被新增、更新和刪除。嵌入模型被升級。分塊策略被最佳化。與此同時，檢索路徑需要保持快速、穩定和可觀測——即使在重建索引的過程中。當索引和檢索糾纏在一起時，改變一個就會破壞另一個。

最佳的生產RAG架構將索引和檢索視為兩條獨立的管道，它們只共享一樣東西：向量儲存。

為什麼單體RAG腳本會崩潰

在單腳本RAG實作中，同一個程式碼庫處理文件攝取、分塊、嵌入、儲存、查詢處理、向量搜尋、上下文組裝和回應生成。這創建了幾種只在規模化時才顯現的故障模式。

重新索引會阻塞檢索。 當您需要重新處理文件語料庫——因為您更改了分塊策略、升級了嵌入模型或收到了一批新文件——檢索路徑要麼被阻塞，要麼在部分更新的索引上運行。使用者體驗到降級的結果或完全的停機。

無法獨立擴展。 索引是批次處理工作負載。在解析和清理期間是CPU密集型的，在嵌入期間是GPU密集型的，在向量寫入期間是I/O密集型的。檢索是延遲敏感的線上工作負載。它需要快速嵌入短查詢和快速的近似最近鄰搜尋。這些工作負載具有根本不同的資源配置。在同一程序中執行它們意味著兩者都沒有被最佳化。

除錯變成考古學。 當檢索品質下降時，您需要確定問題是出在文件的解析方式、分塊方式、嵌入方式還是檢索查詢的建構方式上。在單體管道中，這些關注點交織在同一個程式碼庫中。將品質問題追溯到其根本原因需要閱讀整個系統。

版本管理幾乎不可能。 您想對新的分塊策略與當前策略進行A/B測試。或者您想回滾一個導致結果降級的嵌入模型更改。在單體系統中，這些操作需要重新處理整個語料庫並重新部署整個應用程式。

雙管道架構

將RAG分離為索引管道和檢索管道，在它們之間創建了清晰的邊界和定義明確的契約。

索引管道（批次處理）

索引管道將文件處理為向量表示。它按排程執行或回應觸發器——新文件到達、模型升級或手動重新索引請求。其階段為：

1. 檔案匯入 — 從來源系統（檔案系統、S3、SharePoint、資料庫匯出）攝取文件。處理格式偵測和去重。
2. 解析器 — 從結構化和非結構化格式（PDF、DOCX、HTML、Markdown、CSV）中擷取文字。保留文件中繼資料和結構資訊。
3. 清理 — 規範化文字，移除重複的頁首和頁尾，處理編碼問題，去除無關標記。此階段對檢索品質有著巨大的影響，但往往投入不足。
4. RAG分塊器 — 將清理後的文字分割為檢索單元。這是分塊策略所在——固定大小加重疊、語義分塊或文件結構感知分塊。分塊器是成熟RAG系統中迭代最頻繁的元件。
5. 嵌入 — 使用嵌入模型將塊轉換為向量表示。這是運算最密集的階段，受益於批次處理和GPU加速。
6. 向量儲存寫入器 — 將嵌入及其關聯的中繼資料寫入向量資料庫。處理更新插入、刪除和索引管理。

每個階段都可以獨立測試。您可以驗證解析器輸出而無需執行嵌入器。您可以交換分塊策略並在提交完整重新索引之前比較其輸出。您可以升級嵌入模型並寫入新集合而不觸及現有集合。

檢索管道（即時）

檢索管道處理即時查詢。它是延遲敏感的線上服務。其階段為：

1. API端點 — 接受帶有身份驗證、速率限制和請求驗證的傳入查詢。
2. 查詢嵌入器 — 使用與索引期間相同的嵌入模型將使用者查詢轉換為向量。這必須使用相同的模型和設定——此處的不匹配會靜默地降低結果品質。
3. 向量搜尋 — 對向量儲存執行近似最近鄰搜尋。套用中繼資料篩選器，如果執行多個索引版本則處理多集合查詢。
4. 上下文組裝器 — 取得檢索到的塊，如有需要進行重新排序，將它們組裝成連貫的上下文視窗，並為下游LLM格式化。此階段管理token預算和去重。
5. API回應 — 傳回組裝好的上下文（或如果整合了LLM則傳回產生的回應）以及來源歸屬中繼資料。

檢索管道與索引管道具有完全不同的運行特性。它需要始終可用、在毫秒內回應並處理並行請求。它不需要解析文件、管理分塊策略或處理批次嵌入作業。

管道之間的契約

向量儲存是兩條管道之間的介面。契約很簡單：索引管道以已知的維度、已知的中繼資料綱要和已知的集合命名慣例寫入向量。檢索管道使用相同的嵌入模型從這些集合中讀取。

此契約支援獨立部署。您可以部署索引管道的新版本——使用不同的分塊策略或新的嵌入模型——而無需重新部署檢索管道。寫入新集合，驗證結果，然後將檢索管道指向新集合。回滾就是將其指回舊集合。

在實務中是什麼樣子

在Ertas Data Suite中，兩條管道都作為視覺化節點圖建構在同一畫布上。索引管道是一系列節點：檔案匯入、解析器、清理、RAG分塊器、嵌入、向量儲存寫入器。檢索管道是另一條獨立的鏈：API端點、查詢嵌入器、向量搜尋、上下文組裝器、API回應。它們並排放置在畫布上，視覺上不同但共享向量儲存連接。

這種視覺分離使架構變得具體。您可以看到兩條管道是獨立的。您可以修改索引管道中的分塊節點而不觸及檢索管道。您可以向檢索管道新增重新排序節點而不觸發重新索引。每條管道按自己的時間表執行——索引管道作為批次處理作業，檢索管道作為持久化服務。

由於Ertas作為桌面應用程式在本地執行，整個架構都保留在您的基礎設施內。向量儲存是本地的。嵌入模型在本地執行。沒有文件內容或查詢資料離開機器。對於有資料主權要求的企業，這消除了評估雲端RAG服務的合規開銷。

分離的營運優勢

獨立的可觀測性。 每條管道獲得自己的指標。索引：每小時處理的文件數、塊分佈統計、嵌入吞吐量、寫入延遲。檢索：p50/p95/p99查詢延遲、相關性評分、快取命中率、並行查詢數。當檢索品質下降時，首先檢查檢索指標。如果檢索正常，問題在索引中——檢查索引指標以找到根本原因。

獨立的迭代。 分塊策略是生產RAG系統中最常更改的元件。使用分離的管道，您可以透過索引管道執行新的分塊設定，將結果寫入測試集合，並針對該集合評估檢索品質——所有這些都不影響生產檢索路徑。

獨立的故障域。 如果索引管道在批次處理作業期間當機，檢索繼續從現有索引提供服務。如果檢索管道出現延遲峰值，索引繼續處理文件。兩者的故障不會相互傳播。

清晰的團隊邊界。 在較大的組織中，負責資料攝取和品質的團隊（通常是資料工程團隊）可以擁有索引管道，而負責面向使用者應用程式的團隊可以擁有檢索管道。向量儲存契約是兩個團隊之間的API。

何時開始分離

如果您的RAG系統是一個具有小型靜態語料庫和單一使用者的原型或內部工具，單體方法就可以了。分離增加了在該規模下不合理的架構開銷。

當出現以下任何條件時進行分離：您的語料庫定期更新，您需要在不停機的情況下迭代分塊或嵌入，多人或多個團隊在系統上工作，或者檢索可靠性是業務需求而非便利。

對於大多數企業RAG部署，這些條件從第一天起就存在。從分離的管道開始可以避免以後從單體系統進行痛苦的遷移——這種遷移通常需要在生產壓力下重新處理整個語料庫並重新設計應用程式架構。

最佳的RAG管道架構不是擁有最複雜檢索演算法的架構。而是您可以更改任何元件——解析器、分塊器、嵌入器、檢索策略——而不破壞其他一切的架構。