工程團隊何時應採用 Dust 而非自行維護內部 RAG 管線

打造一個檢索增強生成（RAG）的原型系統相當容易：利用 LangChain 或 LlamaIndex，搭配一套嵌入模型與 pgvector 或 Pinecone 等向量資料庫，花費一個週末就能從本機 Markdown 資料夾中檢索出相關內容片段。然而，若要讓整間公司的工程與營運團隊長期穩定使用一套生產級內部知識檢索系統，面臨的架構挑戰完全不可同日而語。

技術團隊應在以下情境果斷採用 Dust：系統核心目標是內部團隊賦能與跨工具知識檢索——讓工程師、產品經理、客戶支援與營運專家能順暢查詢分散在 Notion、Slack、Google Drive、Confluence 及 GitHub 中的碎片化知識，且無需抽調資深平台工程師全職維護連線器同步、權限對齊與模型調度。

相反地，如果向量檢索是公司對外商業化產品的核心競爭力、系統必須滿足低於 100 毫秒的 p99 延遲 SLA、需要深度微調特有混合檢索演算法或專屬多模態嵌入模型，或是處於完全實體隔離且嚴格禁止存取外部公有雲端大模型的合規環境，技術團隊則應維持自研與維護內部 RAG 管線。

隱形冰山：自研 RAG 管線的「第 2 天」營運難題

多數技術管理者容易低估自研知識檢索系統的全生命週期總擁有成本（TCO）。建立原型往往只佔整體工程量的 20%，其餘 80% 均耗費在後續維運的工程摩擦中：

1. SaaS 連線器持續維護與資料攝取脆弱性

串接企業級 SaaS 工具絕非呼叫單次 API 即可解決。各大主流平台均有複雜的邊界情境：

• 速率限制與退避重試：Slack 與 Notion 在執行大規模工作區爬取時具備嚴格的 API 限流，工程團隊必須建立具備指數退避重試機制的高可用分散式佇列。
• Webhook 生命週期：第三方 Webhook 容易在服務短暫中斷時遺失事件，難以主動追蹤多層巢狀資料夾的權限異動，且 OAuth 憑證需要定期更新或重新認證。
• 多格式檔案解析與解構：解析 Google 簡報、Notion 關聯式資料庫、多分頁試算表與掃描版 PDF，需要持續維護解析套件並配合版面配置調整分塊規則。

2. 權限繼承與存取控制清單（ACL）洩漏風險

企業內部知識庫對資訊安全具備零容忍標準：基層工程師絕不能搜尋出高階主管的薪酬資訊，客服專員也不應調閱包含機密客戶個資的文件。 在自研架構中，將身分識別提供商（IdP）的群組映射至跨多個 SaaS 系統的文件級 ACL，需要自行打造一套即時同步引擎。一旦檔案在 Google Drive 或 Notion 中修改了分享設定，向量庫中的中繼資料必須即刻更新。只要查詢階段的中繼資料過濾出現絲毫漏洞，便會造成嚴重的機密外洩。

3. 重新索引延遲與孤立資料碎片清理

企業文件隨時都在更新。在純自建向量架構中，更新一份 50 頁的系統架構規格書，不僅需要刪除過期切片、寫入新切片，還必須徹底清理孤立分塊。若向量資料庫與真實檔案狀態失去同步，模型便會產生幻覺或依據過時規範給出錯誤指引。此外，每當團隊想要升級底層嵌入模型（例如從舊版遷移至 text-embedding-3-large），整個文件庫必須在不中斷服務的前提下全量重新計算向量並建置索引。

4. 前沿模型快速迭代與路由開銷

基礎大語言模型幾乎每個月都在更新。自研管線需要持續重構應用層編排程式碼，以因應 OpenAI、Anthropic Claude、Google Gemini、Mistral 與 DeepSeek 等不同模型在上下文長度、結構化輸出規範（JSON 模式）與思考推論強度上的差異。

5. 跨端使用者介面的開發與維護

工程師習慣在 Slack、終端機與 GitHub 環境中作業；業務主管與非技術人員則依賴瀏覽器、Google Workspace 與工單系統。自研 RAG 意味著工程團隊還得自行開發並持續維護 Slack 機器人、具備打字機效果的 Server-Sent Events（SSE）前端介面、引用來源彈出框以及權限認證整合。

架構拆解：Dust 託管平台的核心優勢

Dust 採用全託管的「智慧體作業系統」架構，專為解決企業全域知識檢索與智慧體協同的基礎設施負擔而設計。

全託管資料源與連線器生態

Dust 提供開箱即用的原生企業整合，支援 Slack、Notion、Google Drive、Confluence、GitHub、Zendesk、Intercom、Snowflake 及 BigQuery：

• 自動化生命週期管理：所有透過連線器攝入的文件均具備唯一文件 ID。寫入操作預設為 Upsert：更新現有文件時，底層向量庫會自動替換舊分塊，杜絕髒資料與孤兒切片。
• 預先處理與智慧分塊：自動清理冗餘空白字元，並依據 max_chunk_size 詞元上限進行語義切分。
• 向量嵌入基礎設施：預設採用 OpenAI 的 text-embedding-3-large 進行向量編碼（企業版可自訂專屬嵌入模型）。查詢時，Dust 會自動將使用者提問轉換為向量並檢索最相關分塊，以文件為單位進行聚合，並依關聯度最高分數降序輸出。

基於 Spaces 的雙層安全與權限隔離

不同於在向量資料庫中勉強拼接脆弱的單檔 ACL，Dust 採用結構化的 Spaces（空間） 治理模式：

• 開放空間（Open Spaces）：工作區內所有成員均可存取，適用於公司章程、工程通用手冊與全體公告。每個工作區皆內建唯讀且不可修改的 Company Data 預設空間。
• 受限空間（Restricted Spaces）：僅限特定成員或透過 SCIM 從企業 IdP（如 Okta、Microsoft Entra ID）同步的群組存取。
• 雙層隔離強制執行：
  1. 智慧體對資料：智慧體僅能檢索其所掛載空間內之資料來源。
  2. 使用者對智慧體：使用者僅能查看、@ 呼叫與執行自己具備空間成員權限的智慧體。敏感資料絕不會經由智慧體的回答跨權限洩漏。
• 專屬管理服務帳號：針對 Google Drive 與 Notion，Dust 建議配置專用管理身分（例如 dust-admin@company.com），讓 IT 與資訊安全團隊能精準掌控並集中授權哪些共用雲端硬碟或團隊空間可供同步。

多模型靈活路由與使用額度控管

Dust 將底層模型服務抽象化為統一介面。團隊無需修改任何基礎設施程式碼，即可在超過 20 款頂尖模型間自由切換（包含 OpenAI GPT-4o、Anthropic Claude 3.5 與 3.7 Sonnet、Google Gemini 1.5 / 2.0、Mistral Large 以及 DeepSeek 等）。管理員亦能為各群組指派模型權限等級與推論運算上限，避免 API 費用失控。

開發者生態與擴充架構（REST API 與 MCP）

Dust 具備高度彈性的開發者介面，絕非封閉式的無程式碼黑盒：

• 開發者 API 與 OpenAPI 3.0：提供完整 REST 介面，支援以程式自動化管理資料源、批次 Upsert 文字或 PDF 文件、發起對話並接收 SSE 串流事件。
• Model Context Protocol（MCP）支援：Dust 原生支援標準 MCP 伺服器（包含遠端伺服器與客戶端 MCP 預覽模式），使智慧體能安全呼叫企業內部微服務、查詢專有資料庫或觸發 CI/CD 自動化。
• 自動化觸發器與定時任務：支援以 Cron 定期排程執行，或接收外部系統 Webhook 即時觸發任務。
• 開源核心透明度：Dust 的核心系統在 GitHub 完全開源（dust-tt/dust），系統架構師可隨時查驗內部實作邏輯，避免技術黑盒與廠商綁定風險。

關鍵指標綜合比較：自研 RAG 與 Dust 託管平台

全生命週期總擁有成本（TCO）財務量化

工程團隊領導者在進行「自建或採購（Build vs. Buy）」決策時，必須將軟體訂閱費用與被挪用的工程人力成本及機會成本進行客觀對比。

試算場景：150 人的科技企業（含 50 位工程師）

自研與長期維護方案之實際成本

• 初始研發階段（約 4 個月）：配置 2 名資深工程師專職開發資料管線、向量索引、評測框架與 Slack 整合。以工程師年薪加計福利約 15 萬美元估算，初期投入成本約 10 萬美元。
• 年度常態維運（每年）：相當於 0.75 名全職工程師持續處理 Notion / Slack 介面變更、嵌入模型重新切片及向量庫擴容：每年約 11.25 萬美元。
• 雲端基礎設施與 API 費用：託管向量資料庫（如 Pinecone / Qdrant Cloud）、運算資源、解析服務與商業 LLM API 費用：每年約 1.5 萬至 2.5 萬美元。
• 首年綜合成本：約 22.75 萬至 23.75 萬美元，且後續每年產生超過 12 萬美元 的維護沉沒成本。

導入 Dust 託管平台之實際成本

• 商業自助方案（Business）：標準成員 Pro 席位採年繳制每月 24 歐元（約 26 美元），進階建置者 Max 席位每月 120 歐元，並依使用量配置運算額度（Credits）。
• 企業方案（Enterprise）：提供跨工作區共用額度池、無限連線器與 MCP 伺服器、SCIM 自動同步、專屬 SLA 與歐盟/美國資料常駐選項。
• 年度總體花費：對該規模團隊而言，Dust 的軟體訂閱費用通常僅為單一資深工程師年薪的一小部分。
• 機會成本釋放：2 名核心工程師得以專注於直接創造產品營收的主營業務，而非深陷非核心的內部工具開發。

決策評估框架：何時採用哪種方案？

應果斷採用 Dust 的情況：

1. 內部知識嚴重分散於多個 SaaS 工具：系統規格、內部 Wiki、討論紀錄與客服票證散落在 Slack、Notion、Google Drive、Confluence 及 GitHub。
2. 希望讓非工程業務專家自建專屬智慧體：產品經理、客戶成功主管與營運專員能藉由自然語言與 MCP 工具自行打造專屬 RAG 智慧體，無須等待工程團隊排程開發。
3. 平台工程研發資源極度吃緊：團隊正面臨關鍵商業產品里程碑，無法承擔將工程能量耗損在第三方 API 介面維護與重整索引上。
4. 具備即時企業級資安與合規需求：需要立即可用的 SOC 2 認證、GDPR 符合性、SAML SSO 統一認證以及完整稽核紀錄。

應維持自研內部 RAG 管線的情況：

1. RAG 本身就是對外商業產品的核心競爭力：例如您正在打造專業法律審查系統、醫療影像語義檢索或程式碼結構智慧分析工具，專屬檢索邏輯是公司的核心智慧財產。
2. 具備極端低延遲 SLA 要求（<100ms）：需要將向量索引常駐記憶體、搭配硬體快取加速，或直接內嵌於高頻交易與核心即時系統中。
3. 完全實體隔離之專有網路環境：因嚴苛的國防或金融法規，系統完全禁止對外連線至公有雲端 SaaS 或商業 LLM API，必須全面採用離線地端部署（如 vLLM + Ollama 搭配地端 Milvus 叢集）。
4. 數千萬級海量公開資料且權限極為單純：例如對 5000 萬筆公開電商目錄進行檢索，此時以席位計費的 SaaS 模式不具經濟效益，完全統一的存取權限也更適合採用自建架構。

務實的最佳實踐：混合架構模式

眾多成熟的科技團隊目前採取了務實的雙軌策略：

• 內部通用知識交由 Dust 託管：利用 Dust 統一整合跨部門知識，負責工程入職指南、產品規格搜尋、程式庫上下文解讀與跨部門日常營運協同。
• 內部專有系統透過 MCP 串接 Dust：研發團隊無須重新開發外層對話介面，僅需撰寫輕量級 MCP 伺服器或提供 REST API，將專屬業務資料庫掛載為智慧體工具。由 Dust 負責身分權限、前端介面、多模型調度與基礎文字分塊檢索，工程團隊則全神貫注於產出高價值的核心業務資料。

將沒有差異化價值的連線器修補工作交由成熟的代管平台處理，工程團隊才能將最寶貴的研發戰力留在核心產品的創新突破之上。

參考資料

• Dust Pricing: Business and Enterprise Plans for AI Agents
• Understanding Retrieval Augmented Generation (RAG) and the search method in Dust
• Chunks and Documents
• Datasources
• Access Controls and Permissions
• Spaces management
• Google Drive Connection
• Notion Connection
• The economics of multiplayer AI