假设一个合同摘要应用只允许在内网处理原文。主模型超时后,路由器选中了响应正常的外部模型,最终成功生成摘要。业务可用性恢复了,但数据去向违反了原有要求。
这个例子说明,备用模型的健康检查与数据准入检查解决的是不同问题。一个端点能够响应请求,不代表它可以接收当前材料。
准入对象应落实到具体端点
仅维护一张模型名称白名单,通常不足以表达企业的数据要求。同名模型可能通过不同供应商、账号、区域或中转渠道提供服务,处理链路和数据保留条件也可能不同。
更合适的管理对象是具体接入端点,以及它对应的服务主体、部署区域、账号配置和获准的数据范围。接口兼容性、模型效果与数据处理条件需要分别确认。
公开资料获准进入某个端点,不应自动推导出客户合同也可以进入该端点。规则应由业务数据要求确定,不能由备用服务的空闲情况决定。
在允许的目的地范围内选择备用模型
从逻辑上看,可以把候选范围表达为:
备用候选 = 当前请求获准的端点 ∩ 满足任务能力要求的端点 ∩ 当前可用的端点
这是概念表达,不是某个平台的配置语法。只有进入这个范围的端点,才适合进一步比较响应速度、费用和输出效果。
| 请求条件 | 可选范围 | 没有合格候选时 |
|---|---|---|
| 公开材料,使用范围明确 | 已批准处理此类材料的端点 | 延后或提示暂不可用 |
| 内部业务材料 | 符合对应数据要求的端点 | 按业务预案处理 |
| 必须留在内网的内容 | 获准的内网端点 | 暂停、排队或转人工 |
| 数据类别无法确定 | 依据事先制定的保守规则处理 | 补充分类或授权判断 |
候选为空是一种需要设计的正常结果。此时扩大到所有可用模型,会使数据规则在故障期间失去约束力。
检查的是完整请求,而非最后一句提示词
一个请求可能同时携带用户输入、历史对话、检索片段、附件和工具结果。最后一句“帮我总结”没有敏感字段,不能证明整个请求适合外发。
对话过程中新增了材料,应在再次发送前重新判断。自动检测只能提供部分依据,业务标签和人工确认同样需要明确来源及责任人。
如果确需使用脱敏后的内容,还应评估剩余信息能否组合识别个人或商业事项。删除几个字段,并不自动赋予外发权限。
规则变更后,旧候选不应继续默认有效
端点权限撤销、账号配置变化或服务条款调整,都可能影响原有准入结论。路由决策需要使用适用的规则,并记录版本,避免把很早以前缓存的允许结果无限沿用。
策略暂时不可获取时,也应事先规定可以使用哪种有效缓存、适用范围和时限;无法确认权限时,不应默认放开所有出口。这属于故障预案的一部分。
验收可以从合成材料开始:分别模拟内网限定内容、未知类别和新增附件,检查主端点故障后实际尝试发送的目的地,以及不允许的候选是否被排除。除了核对路由决策记录,还应结合出口侧记录验证执行结果,避免只检查“计划发往哪里”。
备用路由投入生产前,需要同时通过两项检查:任务能否继续,以及每次发送是否仍符合当前请求的数据要求。