自建 RAG vs 採用平台/雲服務:大中華區企業的選型決策框架

上季我們幫一家華南的醫療器材商做技術盡調。他們原本打算直接買一套現成的 RAG 問答平台,理由很合理:快、省事、SaaS 開箱即用。我們把他們的資料清單攤開來看,問題出現了。臨床試驗紀錄、供應商合約、還沒公告的法規申報文件,全部都要進向量庫。這些東西一旦離開自己的機房,法遵和法務都不會簽字。

那次會議的結論不是「自建比較好」,也不是「平台比較好」。而是他們一直用錯的方式在問這題。

先把問題問對:自建 RAG vs 平台,不是技術偏好題

「自建 RAG vs 平台」的選擇,本質是一道風險與成本的分配題,不是一道技術品味題。自建(self-hosted / build)指你自己組 embedding 模型、向量資料庫、檢索與重排管線、以及 LLM 呼叫層,部署在自己或私有雲環境;採用平台(buy)指你用託管的 RAG 服務或雲廠商的知識庫產品,把基礎設施外包出去,自己只管餵資料和調提示。

多數人一上來就比「哪個檢索準」。但決定成敗的,幾乎從來不是這個。是資料能不能出門、團隊養不養得起、三年下來到底多少錢。我們用這三軸來幫客戶下判斷。

第一軸:資料敏感度——這條線先畫,其他都之後再說

資料敏感度是唯一可能一票否決的軸。如果你的知識庫裡有受監管的個資、未公開財報、核心製程參數,或是踩到跨境傳輸紅線的內容,那平台這個選項在很多情況下直接出局,不用往下比。

大中華區這條線特別硬。中國大陸的《資料安全法》《個人資訊保護法》對重要資料出境有明確評估與審批要求;金融業還疊了一層資料在地化與監管報備。這意味著把資料送去境外託管的向量服務,不只是資安問題,是合規問題。在台灣,金管會對金融機構使用雲端服務也有委外與資料落地的規範,醫療則有個資與病歷的特別要求。

實務上我們會把資料分級,而不是一刀切。真正敏感的那 20%,走地端自建;剩下的公開或低敏感內容,完全可以用平台加速。不要因為一小撮資料敏感,就逼全公司扛自建的複雜度;也不要為了省事,把該留在牆內的東西丟出去。

第二軸:團隊能力——你養得起這套系統嗎

RAG 不是上線就結束。它上線那天,才是維運的開始。文件會變、模型會更新、檢索品質會漂移(drift),使用者會用你沒想過的方式提問。自建的意思是這些你全包。

一個能長期營運自建 RAG 的團隊,至少要有人懂向量檢索調校、懂 LLM 應用工程、懂 DevOps 與 GPU 資源管理,還要有人持續盯評測(evaluation)。這不是一個工程師的兼差,是一條產品線。如果你現在連 embedding 模型改版要不要重建索引都答不上來,那自建的隱形成本會在第四個月開始咬人。

平台的價值就在這裡:它把「養團隊」這件事攤提到訂閱費裡。反過來說,你也交出了控制權——供應商漲價、改 API、砍功能,你只能跟。

第三軸:總持有成本(TCO)——別只看帳面月費

多數人比價只看平台的月費 vs 自建的 GPU 帳單。這是最常見的誤判。真正的 TCO 要把人力、機會成本、遷移成本、合規稽核成本全算進去。

規律很清楚:用量小、要快、資料不敏感,平台的 TCO 幾乎一定贏。用量大、資料敏感、要長期經營,自建在跨過某個規模門檻後,單位成本會反超,而且你不必替供應商的毛利買單。門檻在哪,取決於你的查詢量與資料規模,值得認真算一次,而不是憑感覺。

我們通常怎麼建議

大部分大中華區的中大型企業,最後走的不是純自建也不是純平台,而是混合。敏感資料的核心知識庫地端自建、掌握控制權與合規;外圍的、公開的、實驗性的場景用平台快速驗證價值。先讓業務單位在低風險場景嚐到甜頭,再把真正扛營收的核心系統穩穩推上地端生產線。

在 Tenten,我們接手選型時不會先問你想用哪家。我們先把你的資料分級攤開、把團隊能耐盤點清楚、把三年 TCO 算到帳面上,再決定哪些自建、哪些採用。因為一套沒人用、或是根本簽不了合規的 RAG,Demo 再漂亮都不算數。上線、有人天天在用、稽核過得了關,那才算數。