toB 场景的两条硬约束——权限隔离与人机协同

一栋楼把门禁装在大门口，和装在每个人离开时的出口处，安全性完全不同。装在出口，意味着人已经进去过、看过、记住了；你只能拦住他把东西带出去，拦不住他知道。

模型就是那个「已经看过」的人。只要受限内容进了上下文，你就已经失去了控制——因为项目的第一条冻结口径就是：模型无法可靠区分「指令」与「数据」，真正的防线在执行层与权限层，不在提示词里。

• 前置过滤（pre-filtering）——在检索发生之前，把候选集限定在当前身份可见的范围内。代价是召回候选变少、检索参数要重调。
• 后置过滤（post-filtering）——先全量检索，再从结果里剔除无权限的。代价是受限内容已经进过上下文，且 top-k 会被高相关但无权限的文档占满，导致「有权限的内容反而召不回」。
• 分级自治（graduated autonomy）——按操作的不可逆程度决定自动执行、先确认、还是只给建议。这是人机协同的骨架，不是「不确定就问人」这么随意的东西。
• 转人工（escalation）——把会话连同上下文移交给人。注意它有两个独立的问题：什么时候转（触发条件）和转得干不干净（交接质量）。

四个落点里，检索时的前置过滤是主防线，其余三个是纵深。只做主防线会漏并发和缓存场景，只做纵深等于没做。

多数企业场景的正确答案是混合，但答题时必须说清「哪一部分走物理、判据是什么」，否则等于没选。

这是分水岭最深的一层。权限不是静态的：人会调岗，文档会改密级，项目组会解散。三个必须处理的点：

1. 索引里的权限标签是快照。文档改密级后，索引里的标签、已经切好的分块、以及缓存里的检索结果都要失效。很多系统栽在缓存上。
2. 前缀缓存与语义缓存要按身份分桶。同一个问题，不同权限的人应该拿到不同答案；如果缓存键里没有身份维度，缓存本身就是泄露通道。这是语义缓存「正确性责任转移到你」这条口径在权限场景的具体形态。
3. 权限变更要能追溯。审计要问的是「他在那个时间点有没有权限」，所以日志要记当时的判定依据，不能只记结果。

常见的错误设计是「模型不确定就转人工」。置信度只是一个输入，真正的主轴是操作的不可逆程度：

在这条主轴之上，再叠三个转人工的触发信号：置信度低（检索没命中、答案与证据不一致）、用户情绪或表述升级（重复提问、明确表达不满）、命中黑名单主题（法律、投诉、医疗、资金）。

转人工的交接质量比触发时机更容易被忽略。合格的交接要带三样东西过去：用户的原始诉求（不是模型的复述）、已经尝试过什么、以及模型判断的不确定点。缺了这三样，用户要从头再说一遍，转人工反而变成负体验。

它不需要标注、不需要 judge，实时可得，而且方向明确：

• 转人工率突然升高 → 通常是检索侧或上游数据出了问题；
• 转人工率长期偏高且稳定 → 说明覆盖面不够，该扩知识库或扩流程，不是该换模型；
• 转人工率过低 → 反而是危险信号，说明兜底门槛设得太高，模型在硬答。

最后一条最容易被漏。评估一个 toB 助手，只看「答对率」不看「该转没转的比例」，是在奖励它硬答。

1. 绝不用 prompt 做权限。「不要透露受限内容」这类写法在第一条冻结口径下就是无效的。
2. 过滤必须前置，并且要重调召回参数——很多团队做对了前置、忘了调参，结果是「安全了但不好用」，然后被业务压回后置。
3. 别忘了缓存。权限做得再好，一个不分桶的语义缓存就能全漏。
4. 引用要回查。答案里给出用户看不到的文档链接，是最容易被安全评审抓到的低级错误。
5. 分级自治按不可逆程度设计，置信度只是触发信号之一。
6. 转人工要带上下文，否则用户体验比没有 AI 更差。
7. 监控「该转没转」，不要只监控答对率。

toB 场景题里，权限和转人工是必然会被追到的两点，而且往往以「陷阱式」提问出现：「你在 prompt 里怎么写才能保证它不泄露？」——正确反应不是回答怎么写，而是指出这个问题的前提就是错的。

权限部分按「四个落点 + 三种隔离级别 + 一致性」三段讲，其中一致性那段是拉开差距的地方——大多数人只讲到「元数据过滤」。人机协同部分按「不可逆程度主轴 + 三个触发信号 + 交接三要素 + 转人工率的三种读法」讲。