託管 RAG 還是自建 RAG：應該用哪一種？

託管 RAG 服務替你做甚麼？

託管 RAG 服務替你運行由文件到檢索的流程：匯入檔案、切成分塊、轉成嵌入向量、儲存向量，並在查詢時檢索最相符的內容。Amazon Bedrock Knowledge Bases、Google 的 Vertex AI RAG Engine 和 OpenAI 的 file search 工具都是這個模式。

Amazon 的文件指出，知識庫把建立流程的繁重工作抽象化，提供現成的 RAG 方案以縮短開發時間。OpenAI 則把 file search 描述為由 OpenAI 託管的工具，所以你毋須自己編寫檢索的執行程式。下圖顯示三種建置方式在每個階段通常由誰負責。

甚麼時候託管服務是正確選擇？

文件整齊，而且第一個版本要盡快推出時，託管服務是正確選擇。單一語言的幫助中心頁面、政策文字和 FAQ 內容都很適合，目的只是測試 RAG 對用戶有沒有幫助的原型也一樣。

沒有檢索工程師的團隊也適合，因為流程由供應商承擔。判斷準則是答案要不要經得起審計：如果錯誤或沒有引用的答案只是沒有幫助，託管服務通常已經足夠；如果會變成負債，請閱讀下一節。

甚麼時候會超出託管服務的能力？

當你需要服務沒有開放的控制權時，便會超出它的能力：表格和掃描件怎樣解析、答案怎樣引用來源、數據在哪裏處理，或者怎樣按你自己的問題調校檢索。

位置是最清楚的例子。Google 的 RAG Engine 頁面指出支援 VPC-SC 控制和 CMEK，但不支援數據駐留控制，而且部分地區要加入許可名單才可使用。解析是另一個例子。Super Cat Technology 為四大會計師行建置的本地部署系統，會把每一頁分成文字、表格和圖表區域，並為每個答案附上來源段落。這些流程是我們按該行的文件設計的。

開源框架適合放在哪裏？

開源框架介乎兩者之間：你得到組件，然後自己運行成品。LlamaIndex 的文件把它的框架描述為 RAG 和 Agent 的開源工具包。解析器、向量儲存、檢索邏輯和託管方式，仍然由你選擇和營運。

所以框架適合想要控制權、而且有工程師可以營運的團隊；不適合希望由別人承擔流程的團隊。如果你的問題橫跨多份文件，請參閱向量 RAG、GraphRAG 與 LightRAG，了解何時值得加入圖譜。

選擇之前應先決定甚麼？

先解答這五個問題，它們通常已經決定了路線：

1. 數據必須存放在哪裏？服務支援哪些地區和控制？
2. 文件是甚麼樣子：整齊的文字，還是表格、掃描件和兩種語言？
3. 每個答案都必須引用來源段落嗎？
4. 上線之後由誰維護流程？
5. 怎樣量度答案質素，用哪些已標註的問題？

如涉及香港數據、雙語文件和監管機構的期望，請參閱香港企業 RAG 方案：自建還是購買平台？。

有哪些風險？

每條路線都有自己的故障方式。以下是需要預先考慮的：

• 服務在你腳下改變。Microsoft 的 Azure AI Search 指引現時指出，新的 RAG 實作應從 agentic retrieval 開始，既有方案則可考慮遷移。綁定某個服務特定模式的流程，也要承受這些變動。
• 沒有計算在內的成本。Google 的 RAG Engine 頁面指出，如果由服務管理 Spanner 實例作為你的向量資料庫，Google Cloud 會就該實例收費。
• 可用範圍有限。同一頁面指出，新專案要在數個地區使用 RAG Engine，需要加入許可名單。
• 沒有評估集。沒有已標註的問題，你就無法判斷新的分塊設定或新的服務令答案變好還是變差，而且沒有任何警報。