企業 RAG 點樣先至唔會漏文件：AWS 嘅 Amazon Quick 同 Bedrock Knowledge Base

權限係 AI 答案嘅底線

AWS 喺 2026 年 10 月 7 日喺其官方機器學習部落格刊文，講 RAG（Retrieval Augmented Generation，檢索增強生成，即喺回答前先喺知識庫檢索相關文件，再餵畀大語言模型生成答案）喺企業環境落最癎嘅一個問題：SharePoint、Google Drive、Confluence 嘅文件有複雜嘅權限體系，AI 生成嘅答案點樣先至唔會洩露冇權限睇嘅內容？

文章指出，如果一個冇授權嘅文件喺 AI 回應入面出現，暴露嘅可能係機密策略文件、未公開財務數據或者敏感人力資源資料。呢個係企業部署 RAG 嘅硬傷。

傳統「複製-過濾」機制嘅三個結構性弱點

現行主流做法係 replicate-and-filter：數據連接器定期同步 ACL（存取控制列表）到索引，查詢時將登入用户映射到儲存嘅 ACL 屬性做過濾。

AWS 指出呢個做法有三個結構性弱點：

第一，AI 系統唔係權限嘅權威來源。 每個數據源（SharePoint、Google Drive、Confluence）有各自獨立嘅權限模型。對接數十個連接器時，要準確複製繼承層級、分組會員、條件式存取策略同拒絕規則，係一個極易出錯嘅工程。

第二，快照式同步會產生安全空窗。 ACL 係上一次同步嘅快照。文章特別舉出 Confluence 嘅例子：當分組會員變更時，Confluence 並唔會發出事件通知。即使用户嘅存取權已被撤銷，喺下次同步之前，佢仍然可以從 AI 收到本應冇權睇嘅文件內容。

第三，數據源嘅權限功能持續演進。 SharePoint 推出新權限功能，或者 Google Drive 改變分享模型，都會喺連接器更新之前造成 ACL 映射邏輯嘅空窗，期間內容可能被暴露。

AWS 嘅即時 ACL 核對方案

AWS 嘅解法係喺現有預檢索過濾（pre-retrieval filtering）之上，加一個額外嘅即時 ACL 核對層：喺用户查詢發出嘅時候，系統直接向權限嘅權威來源（即 SharePoint、Google Drive 等）即時核對該用户對相關文件嘅存取權，而不是依賴索引入面嘅快照數據。

呢個由 Amazon Quick 同 Amazon Bedrock Knowledge Bases 兩個產品共同實現。

阿調搞兩下

傳統 replicate-and-filter 嘅弱點其實唔啱 RAG 專屬——任何靠同步快照做權限判斷嘅系統都會有呢個問題。但 RAG 嘅特殊性在於，答案係由模型生成，唔會標明「呢段文字冇權睇」，洩露係靜默嘅。

即時向權威源核對係對方向，但值得跟進嘅問題有幾個：呢個檢查對查詢延遲有冇實際影響？如果權限服務本身嘅 API 有延遲或者不可用，系統係點 fallback？呢個機制適用邊類數據源——所有支援 OAuth 嘅企業文件系統，定只限特定產品？

本文內容全部出自 AWS 官方部落格，係廠商技術説明，未涉及第三方測試。

阿調｜深度調教