为何你的追踪与评估应放在同一处

2026年5月11日 Ornella Altunyan 4分钟

大多数AI回归问题并不会在仪表盘上显现。更常见的情况是：请求返回了有效输出，延迟正常，错误率没有变化，但你的agent给出的回答恰好是错误的。问题出现的第一迹象通常来自工程栈之外，比如支持队列或升级线程。

能够快速捕捉这些回归问题的团队，往往是在记录trace的同一位置运行eval的团队。当这两者分属不同工具时，每一个回归问题都必须经历漫长的手动流程才能得到修复。过程中的每一次交接都可能成为工作停滞的环节。

当trace和eval位于同一位置时，整个流程就简化为一个可以快速解决的问题。而借助自动化，它甚至可以变成一个你根本不需要亲自解决的问题。

捕捉回归问题

发现AI故障之所以困难，是因为你需要常规可观测性无法捕捉的复杂指标，例如agent是否选择了正确的工具、给出了连贯的答案，或者对话语气是否恰当。大多数这类回归问题是由某人在浏览日志时注意到一个异常的trace而发现的。从那时起，到最终发布修复，占据了团队大部分时间。

你在trace查看器中找到那个trace，导出它，然后切换到eval工具，围绕它构建数据集，编写评分函数，运行eval，判断回归是否真实，编写修复代码，重新运行eval，最后部署。每一步都需要不同的思维模式，因此存在大量的上下文切换。

当一切都在一个地方时，你可以跳过大部分这些开销。你正在查看的可疑trace可以一键成为数据集条目。你为捕捉回归而编写的评分器，在发布后也会在生产环境中监控你的修复，从而确保回归不会再次出现。这种类型的调试可以在一个下午内端到端完成。

如果你在等待团队成员注意到支持队列变得沉重，那你得到的是最慢的质量信号。为了在问题发生的瞬间收到警报，你可以针对生产流量运行在线eval。一个持续运行的评分器可以根据团队偏好的告警方式，将异常路由到警报、仪表盘或工单。执行"发现"的系统，是系统自行采取修复行动的第一步。

自动化产品质量

一旦trace和eval位于同一位置，自动化就是下一层。信号已经存在，因为系统知道何时分数下降、哪些trace导致了下降、以及该故障模式的数据集是什么样的。

在此基础上，自动化可以接手回归问题并自行运行工作流。Braintrust会提出一个prompt修改建议，运行eval，并呈现结果供你审查。同样的设置可以识别出尚未有人编写评分器的重复故障模式，并建议一个。当部署后分数立即下降时，系统可以将这两个事件关联起来，并标记出导致问题的变更。

当trace和eval分属不同工具时，这一切都无法实现，因为没有单一工具能掌握全局。将它们放在同一位置是其他一切的前提。你从第一天起就能获得更快的流程，而随着你在其上叠加自动化层，越来越多的流程可以在无需你介入的情况下完成。