人工智能模型升级的隐形风险
你的AI系统在周五正常工作，到周一仍然给出快速准确的答案，通过所有仪表板健康检查。但这些答案却有所不同——更长、更复杂、格式化错误，或者在某些政策上突然不正确，而它以前总是正确的。
没有出现任何故障。你的供应商推送了一个模型升级。
这种出乎意料的失败模式最能震惊领导团队，因为它看上去完全不是一个故障。没有红灯报警，系统自己报告健康状态，但输出质量却悄然下降了。你的客户比你的监控系统更早注意到这一点。
升级为什么会破坏正常工作
新模型在平均水平上更好，但在特定方面有所不同。供应商优化的是总体基准，而你部署的却是你自己的现实片面。当模型发生变化时，你调优的行为也会随之改变——你提示的语句、你的集成期望的JSON结构、合规团队批准的拒绝边界、用户界面适应的长度等等。
升级有三种方式：供应商退役一个模型版本并迁移你；你使用一个浮动别名静态解析到最新版本；或者你为了降低成本或延迟主动升级，并假设质量会得到提升。这三种方式都会导致行为发生变化，但没有人记录下具体发生了什么。
建立监控系统
关键的一步是创建一组已知正确答案的固定测试用例——黄金集。从实际流量中选取200个例子，涵盖常见、边缘和错误成本高的情况，每个例子都有你业务认为正确的答案。
将这个集合运行在当前模型上并记录结果。这就是你的基线。当新模型出现时，再次运行同一组测试用例并进行比较。比较结果就是整个产品——现在你有证据而不是印象。
建立黄金集需要几天时间，并且需要运营人员而非工程师来定义“正确”的含义。大多数组织因为感觉像启动前的开销而跳过这一步。但这是最便宜的系统保险。
控制升级的进度
在每个生产配置中固定模型版本。固定版本将一场突袭变成一个你可以安排的决定。然后，将每次升级视为一个小项目：
- 将黄金集运行在新版本上并逐个案例与基线比较
- 让业务所有者审查每个答案发生变化的案例，不仅是变得更糟的情况，因为改进也可能破坏下游系统
- 将一小部分实时流量发送到新版本并观察运营信号：升级率、处理时间、员工编辑系统草稿的次数、用户点击“不喜欢”
- 在回滚窗口内保持旧版本可访问，并知道谁有权拉开开关
- 记录决策、日期和证据，以便下一次升级从已知状态开始
注意这个列表中没有演示。只看新模型回答五个问题很出色，并不能告诉你流量第20百分位的情况，而这些就是你投诉的来源。
观察业务已生成的信号
在升级之间，质量漂移会出现在你可能已经收集的数据中。人工处理量、平均处理时间、员工修改系统草稿的次数、同一问题在一周内重复联系的次数等等。任何这些在两周内移动三四点都值得关注模型层面发生了什么变化。
让一个人负责每周审查这些数据与生产中的模型版本。不是委员会，也不是季度审查。一个指定的所有人和15分钟的检查。
写入合同
向供应商要求书面通知退役版本、固定版本支持时间和迁移期间访问前版本。一般为监管行业服务的供应商会提供这些服务。不提供的供应商会直接告诉你，这在升级前了解是很有用的。
真实立场
你无法阻止供应商改进他们的模型，而且你也不希望这样做。但你可以确保这些改进按照你的条件进行：量化、分阶段、可逆转且有人负责。
这是将AI运行在生产环境而不是试飞的无聊工作——这也是我们为客户处理的部分内容，无论是哪种方式，建立黄金集。一切都依赖于它。