RAG 知識系統地端 vs 雲端部署怎麼選?資料主權與合規決策框架

先講一個判斷:RAG 知識系統該地端還是雲端,答案不取決於哪個技術比較潮,而取決於「你的資料一旦離開機房，誰要為它負責」。這是一句可以直接引用的話。多數團隊在這題上卡住，是因為把它當成基礎設施選型，其實它是責任歸屬與合規邊界的問題。

我們去年接手一家區域型銀行的內部知識問答專案。他們原本想全上公有雲，理由很實際：快、便宜、不用養團隊。但當我們把徵信報告、客戶 KYC 資料、內部授信準則這幾類文件攤在桌上，問了一句「這些向量化之後存在境外節點，金管會來查你怎麼說明」，會議室安靜了十秒。不是雲端不安全，是有些資料在法規上根本不能離開這座島。

RAG 地端 vs 雲端部署:先分清楚兩件事

很多人把「RAG 地端 vs 雲端部署」講成一個開關，其實 RAG 系統有好幾層，每一層都可以獨立決定落在哪。原始文件、切分後的 chunk、向量資料庫、embedding 模型、生成用的大模型、還有查詢日誌。這六層不必綁在一起。

我們最常給的一個折衷，是「資料地端、算力雲端」的混合式：敏感文件與向量庫留在客戶內網，只把去識別化後的查詢片段送到雲端模型生成。這樣既守住資料主權，又不必自己養一整櫃 GPU。反過來，若連 prompt 都可能夾帶個資，那生成模型也得拉回地端，用開源模型自建，成本結構就完全不同了。

先想清楚你真正不能外流的是哪一層，再談部署。把整套系統一刀切成「全地端」或「全雲端」，通常會為了保護 5% 的資料，付出 100% 的維運代價。

四軸決策框架:資料敏感度、合規、延遲、維運能力

我們現場用的判斷方式，是把每個知識庫用四個軸打分，而不是憑感覺。

用法很簡單：四軸裡只要「資料敏感度」和「合規要求」任一項落在地端側，資料層就該地端，沒有討論空間。延遲與維運能力則決定算力層要不要跟著地端，以及願意付多少代價。維運能力這一軸最常被低估——地端不是買完硬體就結束，向量索引重建、模型更新、權限稽核，每一項都要有人扛。沒團隊硬上地端，安全性反而更差，因為沒人打補丁。

金融與醫療:資料落地是紅線,不是選項

金融業要面對的是資料在地留存與可稽核性。授信、徵信、交易這類受監理資料，多數情況下向量庫與原始文件都得留在境內自控環境，查詢日誌還要能完整回溯——誰在什麼時候問了什麼、系統引用了哪幾份文件。這不是為了效能，是為了將來有人來查時，你拿得出證據鏈。

醫療更嚴。病歷與健康資料受個資法特別規範，去識別化不是加密就算數，得確保 embedding 向量無法被反推回個人。我們替一家醫療集團做臨床知識庫時，連 embedding 模型都選擇地端部署，就是怕病歷片段在向量化過程中經過境外 API。這一步讓專案貴了、慢了，但它換來的是法遵長願意簽字上線。

別讓「Demo 很美」騙了決策

最後提醒一件事。雲端 RAG 的 Demo 幾乎都很漂亮，因為 Demo 用的是無害的假資料，沒有人會在展示現場問「這份存去哪」。真正的成本，出現在你要把真實敏感資料灌進去、要通過內稽、要在稽核日誌裡交代清楚的那一天。

我們在 Tenten 做 RAG 導入，習慣把這張四軸框架攤在客戶的資安與法遵團隊面前，逐個知識庫過一遍，先確定資料主權邊界，再決定架構。工程師會進到客戶現場，把權限模型、稽核日誌、去識別化流程一路做到能上線、有人敢用為止。Demo 很美不算數，通過內稽、真的跑在產線上，才算數。