企业 RAG：权限、增量索引与删除一致性

图：数据进入索引之前需要保留来源与版本；更新和删除必须能追溯到每个派生片段。来源：Data collection workflow，作者 Aston Zhang、Zachary C. Lipton、Mu Li、Alexander J. Smola（D2L.ai），许可 CC BY-SA 4.0。

问题现场

员工已离开某项目，聊天系统仍从缓存返回该项目的方案摘要。原文访问控制已经更新，但向量索引和答案缓存未同步。这个故障说明授权必须覆盖整个读取路径，不能只保护原文下载页。

以下是一套教学设计，不声称任意向量数据库天然提供完整权限保证。不同数据库过滤、事务与一致性语义应结合部署版本核实。

已知条件

每个文档保存 tenant_id、document_id、source_version、content_hash、acl_version、更新时间和删除状态。每个 chunk 保存父文档、片段位置、解析器版本、切分版本、embedding 版本和内容 hash。在线请求从可信身份系统获得用户与租户，模型不能自行指定要切换到哪个租户。

权限事实以授权服务为准；索引上的 ACL 是加速过滤的投影，可能有传播延迟。系统需要明确可容忍的新鲜度、撤权生效策略，以及传播异常时的处理。

估算或实现

建立可重复的入库链路

以文档 ID 与版本作为处理幂等标识。下载后先解析和校验，再生成确定的 chunk 标识，随后编码与 upsert。只有当前版本的必要 chunk 全部就绪才进入可服务状态；失败重试不能产生一批重复文档。

若切分策略改变，即使原文没变也可能需要重建 chunk。若 embedding 模型改变，旧向量不能直接与新查询向量混用。把这些版本记录成一个可查询的索引发布清单。

用发布指针控制完整版本

可以先建立新版本索引或独立命名空间，完成覆盖率、权限样本和质量回归后切换读取指针。代价是短期双份存储和同步工作，但避免边重建边让用户看到不完整数据。

对持续更新的源，还要处理基线快照后的增量事件：记录事件序号或 watermark，补齐追平后再切换。仅把旧索引全量复制到新索引然后改地址，会漏掉复制期间发生的新增、更新或删除。

权限在每条外泄路径上校验

候选召回尽可能使用数据库支持的租户与权限预过滤；查询服务仍在内容离开可信边界前向权威授权信息复核。过滤缺失、授权服务不可用或版本不明时，对受保护内容拒绝返回，而不是默认放行。

向外部 reranker 或生成模型发送片段前就应完成授权，不能等最终答案出来再检查。向量查询的后过滤可能返回不足 k 个结果，需要按数据库能力选择预过滤、隔离索引或有上限的超额召回；不能为了补满 k 而放宽权限。

删除和撤权的状态变化

逻辑删除／撤权先写入权威状态，使在线授权立即阻止继续返回；随后异步清理 chunk、向量、摘要、对象存储和相关缓存，并记录完成状态与失败重试。物理清理与在线不可见是两个不同目标。

缓存键至少区分租户、授权范围或授权版本、知识版本、问题和生成配置。缓存命中仍要校验权限与有效期。把用户 ID 作为键也不够：同一用户权限会变，某些缓存还可能跨用户共享。

验证方法

创建两个租户、三种角色和同名文档，分别验证跨租户查询、角色撤销、文档删除、旧缓存命中和旧引用打开。再故意延迟索引更新，验证权威授权层能挡住泄漏。

对增量事件注入重复、乱序和中途失败。高版本覆盖低版本后，迟到的旧事件不能把新内容覆盖回去；可用版本比较和幂等记录拒绝旧写。重建验收不仅统计总 chunk 数，还应抽查文档到 chunk 的完整性和删除清单。

引用链接也应走授权，不暴露永久公开的受保护文档 URL。日志和追踪数据按相同的敏感性分级处理，否则主链路安全、调试页面仍会泄漏。

结果解释

“已从向量库删除”不代表缓存、摘要和其他派生物已经删除；“索引 ACL 已更新”也不代表所有在线实例都读到了新状态。应分别报告在线撤权生效延迟与后台清理完成延迟，并保留可追踪状态。

同步吞吐优先时可以接受受控的内容新鲜度延迟，但权限撤销通常需要更强策略。二者不能混为同一个“最终一致”承诺。没有相应设计时，不应在面试里承诺瞬时彻底删除。

迁移问题

部门权限在请求中途变化怎么办？ 在敏感内容发送前或关键操作前重新授权，必要时使用短期授权快照并定义其生效边界；不能只在登录时校验一次。

为什么数据库 namespace 不够？ 它可以隔离租户，但部门、项目和文档级 ACL 可能更细，还涉及缓存、引用、日志与工具返回。

90 秒回答： 我先用文档、chunk、模型和索引版本建立血缘；召回带租户过滤，内容外发前按权威权限复核；更新用可发布版本，删除先阻断访问，再追踪派生数据清理。用撤权、旧缓存和乱序事件测试验证一致性。