多租户与权限隔离：RAG 的合规底线
本文基于模型知识整理（生成时未联网核对），关键结论建议对照经典文献复核。
一句话定义
多租户与权限隔离要求检索在"语义匹配之前"就按租户与用户权限裁剪候选集——过滤必须发生在向量检索层（pre-filter）或物理分区层，任何"检索后再筛"或"靠 prompt 约束"的方案都存在越权泄露。
为什么重要
企业 RAG 的一号合规红线：A 部门的薪酬文档绝不能因语义相似而出现在 B 部门的答案里。与 kp-003 的幻觉不同，越权不是质量问题而是安全事故——它不需要"模型出错"就会发生（内容进了上下文即已泄露）。权限架构必须在索引设计期确定（kp-006 元数据契约），后补的代价极高。
前置知识
kp-006（权限元数据与 pre-filtering）。
核心概念
- 租户隔离层级：物理隔离（每租户独立库/独立 collection，最贵最严）→ 逻辑分区（同库多 collection / partition key）→ 行级过滤（同 collection + 必带 tenant 过滤条件）。选择取决于合规要求与规模。
- 权限模型（ACL）：用户 → 组 → 资源的多对多授权；RAG 检索时要把"当前用户可见的资源集合"转化为过滤条件。
- 强制过滤（mandatory filter）：租户/权限条件由服务端强制注入，不由 LLM 或前端决定——防 prompt 操纵绕过。
- 缓存与日志的连带隔离：语义缓存键要含权限维度，检索日志要防越权内容落日志。
- 图的权限：节点/边带权限属性，查询时同样强制过滤；跨租户共享的实体（如公开公司信息）需明确共享层。
原理与机制
为什么必须 pre-filter：post-filter（检索后再删）的问题在 kp-006 已述（滤空与浪费）；对权限场景还多一条——越权内容已参与检索排序、可能已进日志与缓存，"最后没展示"不等于没泄露。安全铁律：不可见内容不进入检索过程。
ACL 到过滤条件的翻译：用户请求 → 鉴权服务返回其可见资源集（部门、密级、文档 ID 列表）→ 转为检索过滤（若集合过大，用"排除不可见"反向表达或分组过滤）。性能要点：权限过滤字段要建索引；大集合过滤用分区键而非长 ID 列表。
测试即证明：权限隔离必须有自动化越权测试（以 A 用户身份检索 B 租户敏感内容，断言零命中），并纳入回归——权限回归测试是合规审计的常见要求。
图示
用户B(部门B) 查询 → 鉴权服务: 可见={dept:B, level≤3}
→ 强制注入 filter: tenant=acme AND dept='B' AND level<=3
→ 向量检索在过滤后子集执行 (pre-filter)
→ 越权内容从未参与排序/缓存/日志 ✓
反例: 无过滤检索 → post 删 → 已泄露(日志/缓存/排序痕迹)实例或案例
- SaaS 知识助手：partition key = tenant_id，库级强制；再叠加租户内部门 ACL。
- 医疗系统：按科室 + 密级两级过滤，越权测试纳入发版门禁。
- 图权限案例：销售图谱中"客户联系方式"边仅管理层可见，查询层按角色裁边。
常见误区
- 误区一："prompt 里写'只答本部门内容'就行"。prompt 约束可被注入攻击绕过（kp-032），且内容已进入上下文；过滤必须发生在检索层。
- 误区二："共享向量库 + 元数据过滤就够了"。合规等级高的数据需要物理隔离；等级决定隔离层级，不是技术便利决定。
- 误区三："语义缓存与日志不涉及权限"。缓存命中可能跨用户返回越权答案，日志可能存储越权片段——两者都是泄露面，必须随权限维度隔离。
与其他知识点的关系
自测题
- 为什么权限过滤必须在检索前（pre-filter）？
答：post-filter 时越权内容已参与排序、可能进日志与缓存，泄露已经发生；pre-filter 保证不可见内容不进入检索过程。
- 租户隔离的三级方案与选择依据？
答：物理隔离（合规最严/成本最高）、逻辑分区（平衡）、行级过滤（成本最低/依赖过滤正确性）；依据合规等级与规模选择。
- 权限隔离如何"被证明"？
答：自动化越权回归测试（跨租户敏感查询断言零命中）纳入发版门禁，配合审计日志，把隔离从设计声明变成可验证事实。
延伸阅读
- Qdrant/Milvus/Pinecone 多租户文档（partition key 与过滤索引）。
- AWS Builders' Library：enterprise search 的权限修剪。
- OWASP LLM Top 10 中数据泄露相关条目。