RAG 知識系統自建 vs 買平台:build-vs-buy 的總成本與可維運性分析

半年前一家製造業客戶找我們,手上有兩個估價單攤在桌上。一個是自建 RAG,工程團隊估三個月上線;一個是某家 RAG 平台,月費看起來很甜,標榜「兩週接完內部文件就能問」。他們要我們幫忙選。

我沒有直接回答。我先問了一個問題:這套系統上線後的第 18 個月,誰在維護它?桌上沒人答得出來。

這就是 build-vs-buy 最常被跳過的一格。大家算的是「導入要多少錢」,真正該算的是擁有這套系統整個生命週期的總成本(TCO)。RAG 自建 vs 平台的抉擇,九成的痛不在導入那一刻,在後面兩年。

RAG 自建 vs 平台,到底在買什麼

先把東西拆開。一套 RAG 知識系統不是一個黑盒,它至少有四層:文件切分與解析、向量檢索管線、生成與 prompt 編排、還有底下的向量資料庫與運算基礎設施。

「自建」和「買平台」不是二選一,而是你在這四層各自決定要不要自己扛。多數人把它想成整包全買或整包全做,這正是踩雷的起點。

把 TCO 三個維度攤開算

我們幫客戶做決策時,只看三件事:工程人力、維運、資料主權。用堆形容詞沒用,直接對照。

看出來了嗎?兩邊的成本曲線形狀不一樣。自建是前期砸人力、後期攤平;平台是前期輕鬆、後期隨用量與人數往上爬,而且你越用越難搬走。

真正致命的是最後一列。我們接手過一個案子,客戶在某平台上跑了一年,累積了三萬篇問答紀錄和一整套調好的檢索規則。想換供應商時才發現,這些資產全鎖在對方的專有格式裡,搬遷等於重做。平台省下的工程費,最後用「議價權」還了回去。

我們給多數企業的答案:混合路線

算完這三個維度,我們給大部分中大型客戶的建議是同一句話:檢索管線自建,基礎設施用平台。

意思是——底層那些沒有差異化、又燒錢燒人的東西,交給平台。向量資料庫用託管服務(Pinecone、Weaviate、pgvector 都行),運算彈性交給雲。你不需要自己養一組人去顧資料庫的擴容和備援,那不是你的核心競爭力。

但往上一層,文件怎麼切、檢索怎麼排序、哪些欄位要做 metadata 過濾、召回不準時怎麼重排(rerank),這些一定要握在自己手裡。因為這一層直接決定答案準不準,而它高度吃你自家資料的長相。金融的合約條款、醫療的病歷結構、製造的工單格式,通用平台的預設切分邏輯永遠餵不到位。這也是為什麼那家製造業客戶用平台跑出來的召回率只有六成——不是平台爛,是它不認得你的文件。

這條混合路線的好處是成本曲線被馴服了:基礎設施隨用量付費、不養冗員,而最影響品質、最構成資料主權風險的檢索邏輯留在自己家。要換底層向量庫時,因為管線是自己的,搬遷成本從「重做」降到「改設定」。

一個現實的提醒

沒有哪條路是免費的。混合路線要求你的團隊(或你找的顧問)真的懂檢索工程,不是接個 API 就好。如果公司連一個能長期顧這套系統的人都排不出來,那老實說,先買平台把價值跑出來、證明有人在用,再談自建,反而務實。

回到那家製造業客戶。我們沒讓他們全自建,也沒讓他們整包買。底層上託管向量庫,檢索管線由我們的工程師進場,照他們的工單格式重寫切分與 rerank 邏輯。八週後召回率從六成拉到九成一,更重要的是,現場工程師開始每天用它查歷史故障。

在 Tenten,我們做 RAG 導入從不從「要自建還是買平台」這個問題開始,而是從「上線 18 個月後誰在用、誰在養」倒推回來。Demo 上的答案再漂亮都不算數,能長期跑、有人天天用、資料還在自己手上,那才算數。