AWS 為 Amazon Quick 與 Bedrock Knowledge Bases 加入即時 ACL 查核

背景

企業導入 RAG（檢索增強生成，先找出相關文件段落，再交給語言模型產生回答的做法），從 Microsoft SharePoint、Google Drive、Atlassian Confluence 等知識來源取得資訊，但這些來源有複雜的權限結構。AWS 指出常見做法是「複製再過濾」：connector（資料來源連接器，負責把外部系統內容同步進來的元件）定期同步時拉取 ACL（存取控制清單，記錄誰能看哪份文件的權限設定），存進索引，查詢時再依登入者過濾。AWS 認為這有三個弱點：AI 系統不是權限的權威來源，卻要複製各來源的繼承、群組、條件式存取與拒絕規則，容易出錯；權限只是上次同步時的快照，例如 Confluence 在群組成員變動時不會發出事件，權限已被撤銷的人仍可能拿到相關答案；資料來源新增或調整權限機制時，映射邏輯可能出現缺口。 AWS ML Blog

發生什麼事

AWS ML Blog 在 10 月 7 日發文說明，Amazon Quick（AWS 的企業 AI 助理服務，使用者可透過 agent 查詢 Google Drive 等知識庫）與 Amazon Bedrock Knowledge Bases（Amazon Bedrock 中把企業資料建成知識庫、供 RAG 檢索的功能），在既有的檢索前 ACL 過濾之上，加了一層即時 ACL 查核，於查詢當下直接向權威來源確認權限，不依賴可能過時或映射錯誤的 ACL 資料。 AWS ML Blog

文中提到的客戶案例是 Mondelēz International，已為四個地區超過 35,000 名員工部署 Amazon Quick。該公司 Sr. Specialist – M365 Innovation 的 Jamahl Wiggins 表示，資安與法遵團隊的首要條件是同事只能看到有權存取的資訊，而 Amazon Quick 的即時存取控制「answered that question definitively」，讓內部審查委員會有信心推進。 AWS ML Blog

重點內容

第一階段是檢索前過濾。以 Google Drive 知識庫為例，使用者向 Amazon Quick agent 提問後，系統先對 vector index（向量索引，把文件轉成數值向量後建立的檢索資料庫）做 semantic search（語意搜尋，依意思而非關鍵字比對找出相關內容），並套用已存在索引中的 ACL，得出一批候選文件。原文說明這一階段不可省略，因為對索引中每份文件都即時呼叫 API（應用程式介面，讓程式向另一套系統要資料的管道），在大規模下成本太高。 AWS ML Blog

第二階段是即時驗證。Amazon Quick 呼叫 Google Drive API 檢查候選文件，使用管理員提供的 service account（服務帳號，給程式而非個人使用的帳號）憑證，透過 impersonation（模擬身分，由服務帳號代表特定使用者操作）產生該使用者專屬的 access token（存取權杖，證明有權存取資料的憑證）。權限以 Google Drive 為準，使用者無權存取的文件會被排除，只有通過驗證的段落才會交給 LLM（大型語言模型）當作脈絡來產生回答。 AWS ML Blog

除了 ACL 查核，原文也提到 Amazon Bedrock 的其他控管機制：用於內容過濾的 Amazon Bedrock Guardrails、用來減少 hallucination（幻覺，模型產生與事實不符內容）的 grounding checks（依據查核，檢查回答是否有資料支持），以及可自行設定的安全政策。 AWS ML Blog

對使用者的意義

這項設計主要與在企業內部署 RAG 的團隊有關。AWS 列出三項好處：權限隨時是最新的，員工權限被撤銷後，會在片刻內反映到 AI 回答，而不是數小時或數天；每次查詢都向權威來源驗證權限，企業可較放心擴大知識庫涵蓋範圍；不必再擔心同步頻率。要開始使用，原文建議前往 Amazon Quick 與 Amazon Bedrock Knowledge Bases 的頁面。 AWS ML Blog