企业 RAG 权限怎么做：从文档分块到缓存都要隔离

搜索服务的 API 访问权限决定应用能否访问搜索系统；文档权限决定当前用户能看哪些内容。应用有搜索凭证，不代表每位用户都拥有库内全部资料。

Microsoft 的 RAG 文档建议在检索时实施访问控制，使用文档级安全过滤，并将检索内容视为不可信输入。下面的分块、缓存和测试方案为本站实施建议，具体平台能力仍需按当前文档确认。

身份来自服务端验证的会话或访问 token。租户、用户、组成员和业务范围通过授权服务确认，不能让模型声称“我是财务负责人”就获得财务资料，也不能直接信任请求中的 tenant_id。

对文档标记所属租户、可访问组或对象范围，以及权限版本。权限模型可以采用企业已有机制，关键是检索请求带入经过确认的范围，并对无效或未知范围采取明确的拒绝处理。

MCP 官方安全文档也强调 token 的目标服务与最小权限，状态标识不能替代身份。连接工具完成鉴权以后，仍要执行文档和业务对象层面的授权。

表中字段名是示例，不是通用标准。分块、摘要和向量都是原文的派生资料，应按同等敏感范围管理。把原文移入受限目录，却留下公开摘要，不能算完成权限调整。

相同问题的答案可能来自不同权限范围。缓存键或缓存读取条件需要包含租户、授权范围和资料版本等必要约束；更稳妥的实现会在命中后再次验证当前用户能否使用缓存中的证据。不同系统具体策略不同。

答案中的引用链接要再次检查权限。用户有权看一段摘要，不一定有权下载整份合同；工具也不能把内部存储地址或长效访问链接直接放到公开回复。

权限撤销后，要按企业允许的传播时限清理或阻止使用旧索引、缓存和派生内容。已经展示给用户的资料无法通过清缓存自动收回，但新请求与历史会话再次加载时应受到当前权限约束。

缓存答案、会话摘要和生成消息保留来源 document_id、source_version 与适用权限范围。重载历史内容或再次送入模型前，按当前身份复核这些依赖；无法判断敏感来源时，隔离对应历史内容，或用当前获授权证据重新生成摘要。不能只过滤新的检索结果，却继续把旧合同摘要送入上下文。

检查的不只是最终回答。能看到检索候选、调试信息、引用标题或缓存内容的人，都可能接触敏感资料。负向测试应覆盖这些路径，并记录实际权限版本和环境。

在隔离环境中建立一份仅项目组可读的测试合同，分成几块并生成摘要。项目成员提问能够引用合同，其他成员只能收到不含合同内容的说明。接着移除一位成员，分别测试新对话、旧对话、缓存和文件下载。

如果新检索正确拒绝，但旧会话继续输出合同摘要，检查历史消息是否未经当前权限验证进入上下文。如果引用下载仍可用，检查链接是否绕过了授权服务。定位具体路径后修复，不只给模型增加“保密”提醒。

对大规模资料库，还要抽查授权信息是否完整继承。缺 ACL 的分块应按明确策略隔离或阻止发布，不能默认开放。

这套方法适合包含内部制度、客户资料或跨部门内容的知识库。纯公开资料库可以简化用户级授权，但仍应管理内容撤回、版本和来源入口。权限设计不等于完成合规判断，实际资料使用遵循企业已有要求。

开始前整理一份角色与资料范围表，选几份不同权限的脱敏资料，确认授权数据由谁维护、多久生效。没有这份基础信息，搜索组件再丰富也难以实现正确隔离。