一套 RAG 的系統架構

第一個關鍵觀念:一套 RAG 有兩條完全不同的時間線。一條是 BUILD 線 —— 切塊、算向量、灌進資料庫,這條只在文件進來或更新時跑,平常不動。另一條是 SERVE 線 —— 每次有人提問,都要走一遍檢索加生成。很多人把這兩條混在一起想,架構就亂了。先把它們分開:BUILD 做一次,SERVE 無數次。

這張圖把架構攤開。左下黃框是 BUILD 線:文件進來,切塊加 embedding,灌進中間的向量庫。右上黃框是 SERVE 線:問題進來,走檢索 API,撈出片段。中間的向量庫,存的是片段、向量、還有 metadata。左邊那個 access_grants,管的是誰能看哪些文件,它只在檢索時決定授權,跟向量完全分開。最後,撈到的片段交給消費端的 agent,由它自帶的 LLM 生成答案。

RAG 這三個字母,其實是三個可以分開的角色。R 是檢索,把相關片段撈出來;A 是組裝,把撈到的片段組成一段餵給 LLM 的 context;G 是生成,LLM 根據這段 context 寫出答案。為什麼要拆這麼細?因為平台可以只負責 R 跟 A,把 G 留給消費端 —— 也就是平台只管撈跟組,生成那顆 LLM 由用的人自己帶。這個分法在下一集會很關鍵。

選向量庫,很多人第一個問「哪個最快」,其實方向錯了。幾百本手冊、幾萬個片段這種量級,隨便一個支援向量的資料庫都是毫秒等級,效能根本不是問題。真正要看的是:授權好不好做、備份好不好做、你的維運團隊熟不熟。所以很多人乾脆用 PostgreSQL 加上 pgvector 外掛 —— 選它不是因為它向量算最快,而是因為授權、備份、權限這些企業要的東西,它現成就有。

向量庫裡真正的靈魂,是 metadata。每一個片段,都要記下它來自哪份文件、哪一章、屬於哪個單位。有了這些,你才能標出處、才能把問題路由到對的那本手冊、才能判斷這個人有沒有權限看。三件企業最在意的事,全靠 metadata。而且它必須在切塊那一刻就記進去 —— 現在偷懶不記,以後想補,就得把整個庫重切一遍。

企業一定會問權限:業務不能看到財務的文件。這裡有個重要設計:把授權跟向量徹底分開。權限單獨放一張表,記誰能看哪些文件。有人換部門、或要收回權限,你只動那張表,一個向量都不用重算。而授權是在檢索的當下,用這張表現查現決定的 —— 沒有授權的片段,從一開始就被濾掉,永遠不會進到任何人的答案裡。

再來是交付。如果你要把這套 RAG 給好幾個單位用,幾百本手冊,不可能叫他們一本一本上傳。實務做法是:你這邊做好一整包資料,對方拿去還原起來,本地就能問。而且有個附帶好處:各單位各自一包、各自一套,他們在不同機器、不同資料庫,天生就互相看不到 —— 連跨單位授權那套都省了。

上線之後,手冊會一直變,但這些都是局部操作,不用重建全庫。新增一本:只切、只嵌那一本,灌進去,其他書一動也不動。改版一本:把它舊的片段整批刪掉、重新灌新的,別去逐段修 —— 因為改版後片段邊界會變,對不上。刪一本、或改個權限,那更是小事。重點:日常維護的成本,只跟你動到的那一本有關,跟庫裡已經有幾百本無關。

整套架構裡,只有一個操作會牽一髮動全身:換 embedding 模型。為什麼?因為新模型跟舊模型的向量空間完全不同,同一句話在兩顆模型下算出來的座標,根本不能拿來比距離,混在一起算就是垃圾。所以一旦換模型,庫裡每一個片段都得用新模型重算,問題也要用新模型算。這就是為什麼「換模型」是重大決策,要慎重 —— 其他操作都是局部,只有這個是全部。

這集帶走一句話:一套能長期維護的 RAG,地基是「BUILD 一次、SERVE 無數次」。把授權跟向量解耦、把 metadata 記全,企業最在意的權限和出處才立得住。日常的新增、改版、改權限,全都是局部操作,便宜;只有換 embedding 模型才需要全庫重建。把這幾條想清楚,你的 RAG 才從一個 demo,變成一套敢給整個單位用的系統。