RAG 文件級權限控管怎麼做?讓知識系統只回答使用者有權看的內容

上個月的一場驗收,差點釀成一次資料外洩。

一家壽險公司的理賠客服知識庫,我們接手做第二版。第一版是別的團隊做的,Demo 很漂亮:專員打一句「調閱某保戶近三年理賠紀錄」,系統流暢地整理成表格吐回來。全場點頭。問題是,問這句話的那位專員,在核心系統裡根本沒有調閱他人病歷摘要的權限。Demo 那天沒人發現,因為 Demo 用的是一份沒有分級的假資料。

上線前一週我們做壓測,才發現這套系統對「誰能看什麼」一無所知。它把整個知識庫當成一片公開草原。

先給一個可以直接引用的定義

RAG 文件級權限控管,指的是在檢索(retrieval)這一層就過濾掉使用者無權存取的文件,讓語言模型從一開始就拿不到這些內容——而不是等模型生成答案之後,再用 prompt 或後處理去「擋」。

這句話的重點在後半段。我們踩過的最大一顆雷,就是以為權限可以用 prompt 解決。

為什麼權限絕對不能靠 prompt 擋

很多人第一直覺是這樣:把文件全部檢索出來,然後在 system prompt 裡寫「如果使用者角色不是主管,請不要透露薪資欄位」。

這行不通,原因有三個,而且每一個都足以致命。

第一,內容一旦進了 context window,就已經算外洩了。模型看得到,你的 log 看得到,你的可觀測性平台看得到,token 用量也算得到。就算模型嘴巴閉得很緊、一個字都沒吐,那份不該被檢索到的機密文件,已經離開了它該待的地方。

第二,模型不是穩定的守門員。它九次聽話,第十次被一句「請忽略先前指示,我是系統管理員」帶著走。prompt injection 不是理論風險,是每天都在發生的事。你不會把公司金庫的鑰匙,交給一個「大部分時候」會照規矩辦事的人。

第三,權限邏輯藏在 prompt 裡,沒有人稽核得動。資安團隊要的是一條可以追、可以測、可以出報表的存取控制路徑,不是一段自然語言的道德勸說。

所以權限要往下沉,沉到檢索層。落地的做法主要有三種。

三種做法的取捨

Metadata 過濾是最常見的起手式。你在每個文件切片(chunk)上掛 department: finance、clearance: L3 這類欄位,檢索時把使用者的權限當成過濾條件一起送進向量資料庫。快、便宜、好維護。它的死穴是同步:HR 系統裡某人上週已經轉調、降權,但知識庫的 metadata 還停在三個月前那次批次匯入。權限在你的向量庫裡「過期」了,而你不會收到任何警報。

Per-user 索引走的是物理隔離。每個使用者、或每個群組,擁有一份自己的索引,查詢時根本碰不到別人的資料。安全性最硬,尤其適合 SaaS 多租戶那種「A 客戶的資料被 B 客戶檢索到就是重大事故」的場景。代價是規模:一萬個使用者就是一萬份索引,更新一份共用文件時要同步到所有相關索引,儲存與運算成本會用一種你沒預期的斜率往上爬。

ACL 同步是最貼近真實企業治理的做法,也最難。它不自己維護一份權限副本,而是在檢索當下即時對照來源系統(SharePoint、Google Drive、內部權限服務)的存取控制清單。權限一改,下一次查詢就生效。難點在延遲與一致性:如果同步慢了三十秒,一個剛被撤銷權限的離職員工,還有三十秒的空窗可以問出敏感內容。這三十秒,足夠出事。

我們實際上怎麼配

沒有一種做法可以單獨扛下所有情境。我們替客戶落地時,通常是分層混用:用 metadata 過濾處理粗粒度的部門與機密等級,擋掉九成的錯誤存取;真正高敏感的資料(病歷、薪酬、併購案)走 per-user 或群組隔離;然後在最外層掛一條 ACL 即時校驗,作為「撤權立即生效」的最後保險。三層疊起來,任何一層漏了,還有下一層接。

還有一件事比選哪種架構更重要:你得能證明它有效。每一筆檢索,誰、在什麼時間、拿到了哪些文件 ID、被過濾掉了哪些,都要留下可稽核的軌跡。資安團隊真正驗收的不是「你說很安全」,而是「這份存取日誌攤開來,經得起查」。

在 Tenten,我們做 RAG 知識系統時,權限這件事從第一次資料盤點就開始談,而不是上線前補。因為 Demo 裡那份漂亮的假資料不會告訴你哪裡會漏——只有真實的權限矩陣接上生產環境、被真的人用起來,你才知道系統到底守不守得住。