如何將 RAG 管道部署為你的 AI 代理可以呼叫的 API 端點

每個 RAG 教學都遵循相同的路徑：載入文件，分塊，生成嵌入，寫入向量儲存。然後就結束了。讀者手中只有一個已填充的向量資料庫，卻沒有從那裡到一個 AI 代理可以實際呼叫的生產系統的清晰路徑。

「資料庫中的向量」和「我的代理可以在執行時查詢的檢索端點」之間的差距是大多數 RAG 專案停滯的地方。本指南介紹如何將 RAG 部署為 API 端點——一個 AI 代理可以透過標準工具呼叫協定發現和呼叫的可呼叫檢索服務。

為什麼 RAG 教學偏離了重點

標準的 RAG 教學將檢索視為嵌入式程式碼。你編寫一個 Python 腳本來查詢 Pinecone 或 Chroma，組裝上下文，然後將其輸入提示詞。這在 notebook 中有效。但在以下情況下無效：

AI 代理（在 n8n、LangGraph 或你自己的編排器中執行）需要將檢索作為工具呼叫
多個代理或應用程式需要共享同一個檢索管道
非工程人員需要在不接觸程式碼的情況下更新知識庫
需要稽核追蹤來顯示哪些文件被檢索用於哪些查詢

核心問題：作為嵌入式程式碼建構的 RAG 不可定址。它沒有 URL，沒有模式，沒有工具呼叫規範。AI 代理無法呼叫埋藏在另一個服務程式碼庫中的 Python 函數。

RAG 作為嵌入式程式碼 vs. RAG 作為基礎設施

這一區別決定了你的檢索系統能否擴展到單一應用程式之外。

嵌入式 RAG 意味著檢索邏輯存在於你的應用程式碼中。向量搜尋、上下文組裝和提示詞建構是你應用中的函數。如果第二個應用程式需要相同的知識庫，你就需要複製程式碼。如果你想讓 AI 代理使用它，你需要手動編寫一個包裝端點。

RAG 作為基礎設施 意味著檢索管道是一個獨立的服務，擁有自己的端點、自己的模式和自己的生命週期。你將 RAG 作為 API 端點部署一次，任何需要檢索的代理或應用程式都可以呼叫它。這就是在本地執行 RAG 即服務的含義——檢索成為一種共享能力，而不是重複的膠水程式碼。

將 RAG 部署為 API 的最佳方式是將索引和檢索視為兩個獨立的管道，它們共享一個向量儲存但獨立執行。

架構：兩個管道，一個畫布

生產環境的 RAG 系統有兩種不同的運作模式，它們在不同的時間表上執行，有不同的要求。

索引管道（批次處理）

該管道處理你的來源文件並填充向量儲存。它按排程執行或在新文件到達時按需執行。

檔案匯入 → 解析器 → 清洗 → RAG 分塊器 → 嵌入 → 向量儲存寫入器

每個步驟都是一個離散操作：從來源目錄或物件儲存匯入檔案，將其解析為文字（處理 PDF、DOCX、HTML），透過刪除樣板內容清洗文字，使用重疊進行分塊以保證檢索品質，生成嵌入，並將向量寫入你的儲存。

當代理正在查詢時，此管道不需要執行。它在資料更改時執行。

檢索管道（即時）

該管道處理傳入的查詢並回傳相關上下文。它持續執行，監聽請求。

API 端點 → 查詢嵌入器 → 向量搜尋 → 上下文組裝器 → API 回應

API 端點節點接收傳入的查詢，查詢嵌入器使用索引期間使用的相同嵌入模型將其轉換為向量，向量搜尋在儲存中找到最近鄰，上下文組裝器對結果進行排序和格式化，API 回應節點將結構化輸出回傳給呼叫者。

在 Ertas Data Suite 中，兩個管道都在一個視覺化畫布上。你可以在一個檢視中看到完整的資料流——從原始文件到向量儲存到查詢回應。檢索管道可以獨立於索引管道的執行而部署（切換到監聽狀態）。這意味著你的 RAG 檢索 API 端點在背景重新索引文件時保持活躍和回應。

檢索管道詳解

檢索管道中的每個節點處理一個關注點。

API 端點。 這是入口點。它定義 HTTP 介面：接受的參數（查詢字串、top-k 計數、可選篩選器）、身份驗證和速率限制。關鍵的是，該節點自動生成一個工具呼叫規範，以 AI 代理可以消費的格式描述端點的輸入和輸出。

查詢嵌入器。 取得原始查詢字串並使用與索引管道嵌入步驟相同的模型和參數生成向量。這裡的一致性是不可協商的——如果你在索引期間使用了 512 維的 text-embedding-3-small，查詢嵌入器必須完全匹配。

向量搜尋。 對向量儲存執行最近鄰搜尋。可設定的參數包括 top-k（檢索多少個分塊）、相似度閾值（最低相關性分數）和中繼資料篩選器（將搜尋限制在特定文件類別或日期範圍內）。

上下文組裝器。 取得原始搜尋結果並準備供消費。這包括去重（來自同一文件的重疊分塊）、相關性重排、來源歸屬（每個分塊來自哪個文件和頁面）以及將輸出格式化為結構化資料而非原始文字區塊。

API 回應。 將組裝的上下文序列化為回應格式。回傳檢索到的分塊、其來源中繼資料、相關性分數以及呼叫者請求的任何診斷資訊。

工具呼叫整合：如何使 RAG 可被 AI 代理呼叫

Ertas 中的 API 端點節點自動生成工具呼叫規範。這是使最佳 AI 代理 RAG 部署工具區別於基本 REST 包裝器的關鍵能力。

當你部署檢索管道時，API 端點節點生成與 OpenAI 函數呼叫、Anthropic 工具使用和其他代理框架相容的工具規範。該規範描述：

端點 URL 和身份驗證方法
帶有類型和描述的輸入參數（查詢為字串，top_k 為整數，篩選器為可選物件）
描述回應結構的輸出模式
工具功能的自然語言描述，以便代理可以決定何時使用它

設定了此規範的 AI 代理可以在需要特定領域資訊時自主決定呼叫你的 RAG 檢索 API 端點。這就是 AI 代理的 RAG 工具呼叫在實踐中的運作方式——代理不需要寫死的檢索邏輯。它透過工具規範發現檢索能力並在相關時呼叫它。

這將你的 RAG 管道轉變為代理式 RAG 管道的一個元件，其中代理編排何時以及如何檢索資訊，而不是檢索作為每個請求中的固定步驟。

為什麼本地部署對已部署的檢索端點很重要

當你將 RAG 部署為即時 API 端點時，三個因素推動向本地部署。

延遲。 檢索端點位於每個需要上下文的代理互動的關鍵路徑上。如果你的代理在你的基礎設施上執行而檢索端點在第三方雲端中，你就為每個查詢增加了一次網路往返。與你的代理在同一網路上的本地檢索端點將網路跳躍的查詢延遲降低到個位數毫秒。

資料主權。 你向量儲存中的文件是你的專有資料。對雲端託管檢索服務的每次查詢都會將你使用者的問題傳送給第三方，並接收你的專有文件分塊作為回應。對於受監管行業——醫療保健、金融、法律——這通常是不可接受的。在本地執行 RAG 即服務將查詢和檢索到的內容都保留在你的網路邊界內。

成本可預測性。 雲端 RAG 服務按查詢收費。一個繁忙的 AI 代理每天進行 10,000 次檢索呼叫會產生可變的月度帳單。本地部署將其轉化為固定的基礎設施成本。最佳的本地 RAG 端點部署工具為你提供可預測的經濟效益，不受查詢量影響。

比較：部署 RAG 的三種方法

因素	自訂 Python 程式碼	託管 RAG 服務	視覺化管道（Ertas）
部署時間	數天到數週	數小時	數小時
工具呼叫規範	手動編寫	因供應商而異	自動生成
本地部署選項	是（你自己建構）	很少	是
稽核追蹤	你自己建構日誌	取決於供應商	內建
非工程師存取	否	有限	完整的視覺化畫布
索引/檢索分離	你自己設計架構	被抽象化	顯式的雙管道模型
每次查詢成本	僅基礎設施	按查詢收費	僅基礎設施

自訂 Python 檢索程式碼給你最大的控制權，但需要你自己建構端點、工具呼叫規範、日誌記錄和維運工具。託管 RAG 服務減少了設定時間，但引入了按查詢成本，並且通常缺乏本地部署選項。Ertas Data Suite 中的視覺化管道方法為你提供關注點分離和自動生成的工具呼叫規範，無需編寫檢索基礎設施程式碼。

完整圖景

你的 AI 解決方案變成兩個元件：一個推理 API（你的微調模型或託管 LLM）和一個在 Ertas 中建構的 RAG 檢索端點。推理 API 處理推理。檢索端點處理知識。AI 代理透過工具呼叫編排兩者。

沒有連接它們的膠水程式碼。沒有嵌入在應用程式中的檢索邏輯。沒有對按查詢收費並扣留你向量的託管 RAG 服務的供應商依賴。

索引管道在你的資料更改時執行。檢索管道持續執行，服務查詢。兩者都在一個畫布上可見，可稽核，並且可由不編寫 Python 的團隊成員維護。

開始使用

Ertas Data Suite 的 Serve 類別——API 端點、查詢嵌入器、向量搜尋、上下文組裝器和 API 回應——現已在設計合作夥伴計畫中提供。如果你正在建構需要可呼叫檢索層的 AI 代理，或者正在從嵌入式 RAG 程式碼遷移到代理式 RAG 管道架構，我們期待與你合作。

加入設計合作夥伴計畫，在你自己的基礎設施上部署你的第一個 RAG 檢索 API 端點。