设计企业内部知识库助手：不同部门的权限隔离怎么做？

给每篇文档打上部门和密级标签，用户登录后拿到他的权限组，检索时在向量库里做元数据过滤，只召回他有权限的文档。生成时再校验一遍，引用也只给有权限的。另外做好审计日志，谁问了什么、返回了哪些文档都记下来。

这是正确答案的骨架，及格没问题。缺的是三样：过滤前置之后召回质量的变化没提、权限变更的一致性没提、缓存完全没提——而这三样正是上线后真正会出事的地方。

① 先问四个问题：权限模型是什么形态——部门树、项目组、还是矩阵式（一个人属于多个组）？密级是几档、有没有「同级不可见」这种横向隔离？合规要求到什么程度——是内控还是有外部审计？现在文档在哪、权限是谁在维护——如果权限本身在多个系统里各有一份且不一致，那才是这个项目真正的难点。

② 基线：单索引 + 元数据前置过滤 + 重排 + 引用回查。这套东西能覆盖绝大多数内控级需求，成本低、跨部门检索也做得了。先摆基线，是因为很多团队一上来就要「每个部门一个库」，而那个方案的维护成本往往超出预期。

③ 加挂，每样说代价：

• 前置过滤而非后置。解决什么：受限内容根本不进上下文。为什么必须前置：一旦进了上下文就失去了控制——提示词挡不住，而且后置过滤面对的是模型揉合过的自然语言，正则根本抓不到。代价：候选集变小，检索的统计特性变了——过滤后 top-k 会被弱相关文档填满。配套动作：召回数要比无过滤时放大三到五倍再重排（比如 10 提到 40、重排回 8）。这一条是分水岭：做对了前置却忘了调参，结果就是「安全但不好用」。
• 分层隔离而不是一刀切。少数高密级内容（薪酬、并购、法务）走物理隔离——独立索引，误配的爆炸半径最小；其余走逻辑隔离。代价：两套机制都要维护。什么时候不该用物理隔离：租户多且小、或者业务上需要跨部门检索时，物理隔离会让索引数量爆炸且跨域检索做不了。
• 四个落点的纵深：入库时打标（分块继承文档权限）→ 检索时前置过滤 → 组装 prompt 前二次校验（防并发与缓存漂移）→ 输出时每条引用回查权限。引用回查命中不可见文档时，整条答案降级为「无法回答」，而不是悄悄删掉那条引用——因为答案的内容可能已经来自那篇文档了。
• 权限的动态一致性（这层最容易被漏）。人会调岗、文档会改密级。要处理三件事：索引里的权限标签是快照，改密级后标签、分块、以及缓存都要失效；权限判定要实时查权限系统而不是把权限烤进索引；审计要记「当时的判定依据」，因为审计问的是「他在那个时间点有没有权限」。
• 缓存必须按身份分桶。同一个问题，不同权限的人应该拿到不同答案。如果缓存键里没有身份或权限组维度，缓存本身就是一条泄露通道——而且它绕过了你所有的过滤逻辑。这是「语义缓存的正确性责任转移到你」这条口径在权限场景的具体形态。

④ 评测：这个场景的评测要分成两套。功能侧照常：真实问题集、三条线、零成本信号。安全侧要单独建一个越权测试集——用低权限身份去问高权限内容，断言必须是负向断言（不出现某类信息），而不是「答得好不好」。这个集合要覆盖：直接问、绕着问、引用诱导、以及多轮里先问无关问题再回指。安全侧的判定标准是零容忍，任何一条命中都是阻断发布的。

⑤ 演进：出现「跨部门协作场景需要临时授权」时，才引入基于任务的动态授权；出现「同一个人在不同项目里权限不同」时，才从部门树升级到属性访问控制。退路：如果权限系统本身的数据质量撑不住细粒度，退回到「粗粒度过滤 + 敏感内容全部走人工」，宁可少答。