有一种特定类型的事件，任何警报都不会触发，而这也是我最不信任的一种情况。系统没有崩溃。没有异常，没有 500 错误，也没有失败的健康检查。智能体每天运行，每次都返回答案，并且在你拥有的每个仪表板上都保持绿色正常状态。然而，在六周的时间里，它的表现明显变差——而你是从客户那里得知这一情况的，而不是通过监控系统。
这就是漂移，我认为这是行业最缺乏准备的故障模式。我们已经擅长捕捉悬崖式故障：智能体抛出异常，工具返回 500 错误，JSON 无法解析，持续集成流程变红。但我们仍然极不擅长捕捉斜坡式衰退：回答质量每周流失百分之二，而所有系统都报告完美健康。崩溃是喧闹且自我宣告的。漂移在构造上就是静默的，而这种静默正是它得以胜出的原因。
以下是我将捍卫的观点：漂移不是一个离群值问题，而是一个基线问题。你无法通过查看任何单次运行来检测衰退，因为单次运行看起来完全正常。漂移仅作为随时间变化的分布改变而存在——因此，如果你没有持续对生产环境进行评分并追踪分数趋势，你在结构上就无法看到它。这不是运气不好，而是能力缺失。
为什么你的代码未变，但行为却变了
漂移之所以如此令人困惑，是因为它违背了我们最深层的直觉：如果代码没有改变，行为就不会改变。对于智能体而言，这完全是错误的。即使你的 Git 历史记录完全静止，你的智能体也在衰退：
-
模型在你脚下变动。你锁定了
gpt-4o，但锁定的模型名称并不等于锁定的模型——提供商会在稳定的字符串背后滚动检查点并悄悄重新调整。你的提示词在字节层面上完全相同，但输出结果却发生了偏移。 - 世界在你的提示词下变动。你的少样本示例是基于三月的现实编写的。现在是九月。用户询问的是在你冻结提示词时不存在的产品和边缘案例，智能体进行了即兴发挥——效果更差，但表达流畅。
- 你的依赖项和输入在变动。检索索引被重新嵌入；某个工具重命名了一个字段；你的用户群扩展到了新的语言区域。智能体在你测试过的输入上从未出错——问题在于，它实际服务的数据和流量已经偏离了那些测试用例，而它仍在继续运行，并自信地引用略微错误的结果。
这些情况都不会出现在代码差异对比中。没有任何情况会抛出异常。每一种情况都在降低用户的实际体验。这就是为什么“如果出问题了我们会注意到”是一种幻想——代价最高的智能体回归测试根本不会破坏任何东西。
基线是衡量漂移的唯一参照
要检测漂移，你需要两样东西：一个基线——即在可信的时间窗口内“正常”得分的情况——以及一个连续信号，即以相同方式对实时流量计算的相同分数。漂移是两者之间的差距，通过统计方法而非肉眼观察来衡量。
naive（朴素）的版本是单一阈值：“如果质量降至 0.8 以下则发出警报。”这能捕捉到悬崖式故障，但会错过斜坡式衰退。一个在五周内从 0.91 缓慢降至 0.82 的分数永远不会触发绝对下限警报，但它已经损失了近十分之一的质量。你寻找的不是低分，而是变动——这是一个不同的统计学问题，因此需要基线。
这正是评估与可观测性不再成为独立关注点，而合并为一个工作流的地方——因为你既需要一个评分的工具，也需要一个记住路径的工具。我运行 agent-eval 来对智能体的输出进行评分和门禁控制：确定性检查
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
