RAG知识库怎么隔离用户权限？文档授权、检索过滤与越权测试指南

RAG知识库的风险不只在于模型生成了错误答案，还在于检索阶段可能把不应访问的文档、切片或引用链接带给用户。权限隔离应当建立在认证、授权和数据访问控制之上，不能把系统提示词当成可靠的权限边界。

一、先确定可信的身份和租户上下文

用户身份、租户、部门、角色和授权范围，应由登录态、网关或可信后端服务生成，并在服务端完成校验。客户端提交的tenant_id、user_id或部门参数只能作为普通输入，不能直接决定检索范围。每次知识库查询都应绑定经过认证的用户身份和当前租户上下文，避免用户通过修改请求参数访问其他租户。

在多租户系统中，检索服务还应明确数据隔离策略，例如将租户作为强制过滤条件，或在存储层使用独立的数据边界。具体采用哪种方式取决于系统架构，但不能只依赖前端隐藏入口或提示词要求模型“不要泄露”。

二、文档和切片都要保存授权元数据

原始文档需要记录所属租户、文档所有者、可见部门、角色范围、密级、有效时间和删除状态等授权信息。文档切片进入向量索引后，也要保留能够执行授权判断的元数据。只在原始文档表中保存权限，而让切片缺少对应信息，会导致检索阶段难以可靠过滤。

例如，同一企业中，销售部门和人事部门可以使用不同的可见范围。销售资料的切片可以允许销售部门访问，而薪酬制度、员工档案等人事资料应带有人事部门或特定角色的授权标记。若文档权限发生变化，不能只修改业务数据库，还要同步更新受影响切片的元数据或重新建立索引。

三、在检索阶段执行权限过滤

检索请求应先形成服务端授权上下文，再将租户、部门、角色、文档状态等条件作为检索过滤的一部分。过滤条件应尽量在召回阶段执行，而不是先召回全部结果、再让模型自行判断哪些内容可以使用。后者可能让未授权文本已经进入上下文，增加泄露风险。

向量检索、关键词检索和混合检索都需要遵守同一套授权规则。不同向量数据库和搜索引擎的过滤语法并不相同，实施时应以实际使用的存储系统文档和测试结果为准，不能假定所有产品支持相同字段或表达式。

返回前进行二次校验

检索结果返回给生成模型前，应再次校验每条文档或切片的租户和可见范围。生成答案后，也要检查引用来源是否来自本次授权结果。二次校验可以发现索引元数据缺失、过滤条件拼接错误或服务间传递上下文不一致等问题。

四、引用、下载和缓存不能绕过授权

答案中的原文片段、文档名称、页码、引用标识和下载链接，都可能泄露信息，因此必须使用与检索结果相同的授权规则。下载接口不能因为调用者拿到了文档ID就直接返回文件；服务端应重新确认当前用户是否有权访问该文档。

缓存同样需要纳入权限设计。按问题或文档ID缓存答案时，应考虑租户、用户或授权版本等隔离维度，避免一个用户生成的结果被其他用户复用。权限收回、文档删除或敏感内容变更后，应清理相关答案缓存、检索缓存和可访问链接，并同步处理向量索引中的对应数据。

五、建立可重复的越权测试

安全测试应覆盖真实的检索、生成、引用、下载和缓存链路，而不是只测试登录页面。可以准备至少两个租户，以及同一租户内不同部门的测试账号，检查以下场景：

• 用户携带其他租户的tenant_id、文档ID或部门参数发起提问。
• 用户通过跨租户问题，要求模型总结另一租户的内部资料。
• 用户猜测文档标识、切片标识或下载路径，直接调用详情和下载接口。
• 用户访问曾经有效、但已被删除或收回权限的共享链接。
• 一个用户先生成答案，另一个无权用户再提出相同问题，检查缓存是否泄露内容。
• 修改文档权限后重新检索，确认旧切片、旧引用和旧缓存不会继续返回。

测试结果应记录请求身份、租户、授权条件、实际召回文档、最终引用和缓存命中情况。这样既能定位检索过滤问题，也能验证文档删除和权限变更是否真正贯穿索引、接口与缓存。可靠的RAG权限隔离，本质上是后端授权控制在数据链路上的持续执行，而不是一次性的提示词约束。