背景
而家好多人會用 RAG 嚟做問答系統。常見做法係將公司內部文件、客戶資料、產品手冊等放入一個本地 Vector Database，再用一個雲端 LLM API 嚟生成答案。表面上，資料庫放喺自己環境，好似好安全，但其實只要 prompt 有機會包含敏感內容，資料就有機會外洩。
核心風險
首先，當使用者問問題時，例如「請列出客戶 A 嘅合約條款」，呢句問題本身已經可能包含客戶名稱或內部資訊。其次，RAG 系統會由本地 Vector DB 檢索出相關文件段落，再將呢啲段落放入 prompt，送去雲端 LLM。呢個步驟就係最大風險，因為內部文件內容已經離開咗你嘅環境。再者，如果你用同一個雲端服務做 Embedding，原始文字亦會經 Embedding API 傳出去。最後，雲端供應商可能會記錄 prompt、log、監控數據，你唔一定知道佢哋點用呢啲資料。
對應方案
第一個方案係全本地部署。即係用本地 LLM、本地 Embedding 模型、本地 Vector DB，所有步驟都唔經外部網絡。呢個係最安全嘅做法，但硬件要求較高。
第二個方案係資料脫敏。如果一定要用雲端 LLM，可以喺傳送之前將所有敏感資料遮蓋或取代，例如將客戶名改做「客戶A」，刪除電話、地址、身份證號碼等敏感內容。
第三個方案係最少化傳輸。只傳送最相關嘅段落，而唔係成份文件，並限制每段長度，減少暴露風險。
第四個方案係揀選企業級雲端方案。你應該選擇提供「唔用作模型訓練」、「資料唔保留」、「資料所在地限制」、「SOC 2 / ISO 27001」認證嘅供應商，並簽訂 DPA 同 NDA。
第五個方案係加入嚴謹嘅權限控制措施。權限控制係防止資料外洩嘅關鍵防線。具體措施包括：
- 文件層級權限：Vector DB 入面嘅每一份文件都應該標記所屬部門、存取級別或使用者群組。檢索時，系統必須先驗證使用者嘅身份同權限，確保佢有權限睇該文件，先至將相關段落放入 prompt。如果使用者冇權限，系統應直接返回「無法提供相關資料」或「你無權限查閱此內容」，而唔係照樣檢索同生成答案。
- 角色為基礎嘅存取控制：建立清晰嘅角色架構，例如管理員、編輯者、一般使用者，每個角色對應唔同嘅文件存取範圍。一般使用者只能查閱與自己相關或獲授權嘅文件，防止跨部門或越權查閱。
- API 層級嘅權限檢查：如果雲端 LLM API 係由後端系統呼叫，後端必須喺每一次請求之前，檢查使用者嘅 token、session 或 API key 是否有效，以及該使用者是否有權限存取該次檢索嘅內容。唔好只信前端或客戶端嘅權限設定。
- 定期審計與權限回顧：定期檢視每個使用者或角色嘅權限設定，確保冇過期或過大嘅權限。例如，離職員工或轉職員工嘅權限應該及時取消或更新。審計記錄應該保留，以便日後追溯。
- 最小權限原則：為所有使用者、系統帳號同 API 帳號分配最小必要嘅權限。唔好為咗方便而畀 AdministratorAccess 或過大嘅資料庫讀取權限。
第六個方案係技術隔離同監控。將重要系統同敏感資料放喺獨立嘅 AWS account 或網絡環境，限制 contractor 或第三方只可接觸必要部分。同時打開監控工具，記錄所有存取行為，一旦有異常活動可以即時警報。
總結
本地 Vector DB 加雲端 LLM 呢個架構，如果處理得唔好，係有資料外洩風險。最安全係全本地部署；如果一定要用雲端，就要做脫敏、最少化傳輸、揀企業級供應商，同時一定要做好權限控制同監控。每一環都要小心處理，先可以保障資料安全。
發佈留言