知识库的权限：不该看到的内容不能被答出来

企业知识库里混着各种敏感程度的内容：公开的产品手册、内部的流程制度、限定范围的薪酬与合同。如果权限控制只做在前端的菜单上，模型照样能从库里检索到任何内容并组织成答案 —— 用户看不到那份文档，却能问出里面的内容。

权限必须在检索阶段生效

正确的实现是：检索请求带上当前用户的权限信息，过滤在向量检索的同一步完成，不符合权限的内容根本不进入候选集。常见的错误做法是先检索出十条再按权限筛掉七条 —— 这样不仅剩余材料不足导致答案质量下降，而且不同权限用户得到的召回数量差异很大，表现很不稳定。

文档级还是段落级

文档级权限实现简单，一份文档要么能看要么不能看，绝大多数场景够用。段落级权限（同一份文档里部分章节受限）灵活但复杂度高，而且容易出错 —— 切块、重建、文档更新时权限标记很容易丢失。

建议的做法是在源头上拆分文档，把受限内容单独成文，用文档级权限管理。这比在系统里实现段落级权限更可靠，也更容易向审计说明。

出处本身也会泄露

• 答案里显示「依据《某某部门薪酬调整方案》」，即使内容没给出，文档名本身已经透露了信息；
• 提示「相关内容您无权查看」也是一种泄露 —— 它确认了该内容存在。更稳妥的表述是统一回答资料中没有相关说明；
• 搜索建议、热门问题这类聚合功能，容易把受限内容的标题暴露给全体用户，需要单独处理。

审计要能回答三个问题

谁在什么时候问了什么、系统召回了哪些文档、最终答案是什么。这三项都要有记录。只记录问题和答案是不够的 —— 排查疑似泄露时，必须知道当时实际召回了什么，才能判断是权限配置错误还是内容本身的问题。

日志本身也是敏感数据，它包含了用户的提问内容和文档片段。日志的访问权限、保留期限和脱敏规则要一并设计，否则就是在权限体系旁边又开了一个口子。相关设计见企业知识库解决方案，实施安排参考合作流程。