RAG 文档权限同步权限变了向量结果也要变一、RAG 权限不是检索后再过滤那么简单企业知识库里文档权限经常变化人员转岗、项目关闭、客户隔离、合同过期。如果 RAG 系统只在文档入库时记录一次权限后续权限变更就会让旧向量继续被召回。检索结果再准也不能越权。RAG 权限同步要和文档内容同步一样重要。二、权限要进入索引元数据flowchart TD A[文档系统] -- B[内容同步] A -- C[权限同步] B -- D[Chunk] C -- D D -- E[向量索引] E -- F[查询过滤]每个 chunk 都应该带权限元数据比如租户、部门、角色、项目 ID 或 ACL 版本。查询时必须基于当前用户权限过滤。chunk_metadata: doc_id: contract-001 acl_version: 42 tenant_id: tenant-a project_id: p100ACL 版本能帮助发现索引里的权限是否过期。三、权限变更要触发更新record PermissionChangedEvent( String docId, long aclVersion, Instant changedAt ) {}权限变更不一定需要重新 embedding但需要更新向量库里的元数据。如果向量库不支持高效更新元数据就要设计 tombstone 或重写 chunk。不要等每天全量同步。高敏感文档权限变更应该尽快生效否则窗口期内就可能越权。四、查询时要二次校验索引过滤是第一道返回答案前还要检查引用文档是否仍对用户可见。因为索引可能延迟权限服务也可能刚更新。rag_permission_guard: filter_in_vector_query: true verify_citation_acl_before_answer: true block_when_acl_unknown: true权限未知时应该拒绝或降级而不是默认放行。安全系统里默认允许通常会埋雷。还要监控权限过滤命中情况。大量候选被过滤可能说明检索范围太宽过滤后没有结果系统应返回“无可访问证据”而不是让模型编答案。最后权限同步要有对账任务。定期抽样比较文档系统和向量索引里的 ACL 版本发现不一致要自动修复。权限模型还要支持继承。企业文档常有空间、目录、文档三级权限用户又可能来自角色、部门和项目组。入库时要把最终可见范围计算清楚查询时也要能解释为什么可见。acl_resolution: include_space_acl: true include_folder_acl: true include_document_acl: true record_resolved_version: true如果权限表达太复杂可以在索引侧存 resolved permission hash查询时用用户权限 hash 匹配。这样查询快但要保证权限变更后能及时更新 hash。还要处理权限收缩和权限扩大。权限扩大时用户可能希望立刻检索到新文档权限收缩时安全要求更高必须尽快阻止访问。两者优先级不同权限收缩应该走更快链路。最后RAG 回答里不能暴露有一篇你无权访问的文档。过滤后如果没有证据就说没有可访问证据不要暗示隐藏内容存在。权限同步频率也是需要权衡的问题。实时同步权限变更最安全但会对文档系统和向量库造成持续压力尤其在权限变更频繁的大规模组织里。一种折衷方案是近实时 定期全量对账监听权限变更事件在秒级内更新向量索引元数据同时每天凌晨执行一次全量对账修复漏掉的变更。这样既能把越权窗口控制在秒级又避免了实时同步的复杂度和性能开销。对账时发现的大规模不一致往往暴露了事件丢失或处理失败的根本问题值得深入排查。RAG 权限模型还需要考虑间接授权场景。比如一个用户可能没有直接访问某文档的权限但因为参与了相关项目、成为了合同签署方或被分配了工单从而应该看到该文档。这种基于上下文的权限在企业里很常见但很难在向量检索时高效表达。一种做法是把间接授权关系预计算成扩展权限列表写入 chunk 元数据另一种做法是在检索后、生成前调用业务系统做一次实时鉴权。前者查询快但更新复杂后者灵活但增加了延迟和耦合需要按场景选择。五、总结RAG 文档权限同步要把 ACL 元数据写入 chunk监听权限变更查询时过滤并在答案引用前二次校验。权限变了向量结果也要变。企业 RAG 的可信度首先来自不越权。