评分了每一轮对话却错过了整个交流：聊聊多轮评估的陷阱

你的评估仪表盘是一片绿色。单轮准确率（turn-level accuracy）保持在 95%，LLM 裁判（LLM judge）与你的标注人员意见一致，每一项回归测试在上线前都顺利通过。然后，一名用户提交了一个 bug：在第九轮对话中，智能体推荐了一个 Postgres 索引，但这直接违反了用户在第一轮中设定的“我们使用的是 DynamoDB”这一约束。你调出对话记录。每一轮对话如果拆开来看，都是合理的回复。但如果把整个对话作为一个整体来看，那就是一场灾难。

这是单轮评估（turn-level evaluation）的核心谎言。它对“请求-响应”对进行评分，因为这是标注成本最低的单位，并且它默认假设一段对话仅仅是你可以取平均值的独立轮次的组合。事实并非如此。第九轮的响应是以之前发生的一切为条件的，而那些真正触达用户的失败几乎从未存在于单轮对话内部——它们存在于轮次之间的缝隙中，在那里状态丢失、假设变得僵化，微小的错误复合成一个完全错误的最终答案。

如果你只记住一件事：一个单轮准确率为 95% 的系统，其每个会话（session）的准确率并不是 95%。它要糟糕得多，而且随着交流的增加，差距会不断扩大。大多数评估框架在结构上对定义多轮智能体是否可用的故障模式是完全盲目的。

将 95% 变为 77% 的算术题

从累积效应开始。如果每一轮独立成功的概率是 0.95，那么一个五轮的会话成功的概率是 0.95⁵ ≈ 0.77。将单轮准确率提高到 99%，五轮成功的概率会回升到 0.95 左右。一旦你将足够多的轮次串联在一起，那 1% 的单轮可靠性差距，就是“通常可用”与“通常失败”之间的天壤之别。

而且，独立性还是一个乐观的假设。实际对话的情况比乘法计算的还要糟糕，因为错误不仅会累加，还会传播。在第二轮引入的 2% 的偏差不会仅仅停留在 2%。如果模型在错误的假设上继续构建而不是重新审视它，那么这个种子到第十轮时可能会演变成 40% 的失败率。审计生产环境对话记录的从业者一致发现，70–90% 的多轮错误都可以直接追溯到 之前 的某次回复，而不是当前的这一轮。模型会死磕早期提到的某些信息——比如在第一轮中提到过一次“我正在做一个 Python 项目”——并在用户早已切换到另一个文件、另一个服务、甚至完全不同的问题之后，仍然在沿用那个信息。

单轮评估无法察觉到这些。每一轮都根据其直接的提示词进行评分，错误的第九轮在继承了中毒的上下文后，局部看起来并无大碍，评分依然稳步通过。你衡量了局部正确性，并将其称之为质量。但两者并非一回事。

为什么平均单轮得分在统计学上是行不通的

还有一个更微妙的问题，这不仅仅是覆盖范围的缺失，而是一个数学错误。主流范式是计算每一轮的得分，然后在整个对话中取平均值。这种平均处理默认假设每一轮都是独立样本。但事实恰恰相反：第 t 轮是以到 t 为止的全部历史为条件的，而用户的下一条消息又是由模型刚刚说了什么而决定的。

当你像对待独立观察样本一样，对单轮得分进行标准的统计分析时，自相关性（autocorrelation）会破坏你的结论。最近的一项分析估计，对话分析中 42% 的单轮发现可能是伪造的——这是将相关轮次视为独立抽取样本的结果。你不仅错失了失败案例，还在产生关于哪些提示词更改有效、哪些无效的错误结论，并基于此发布产品。

聚合也会在结构上掩盖灾难。一个前九轮表现完美、但在第十轮犯下致命错误的会话，在平均分下会得到 90 分。但那次对话是彻底失败的——用户得到了错误答案并离开了。平均分奖励了局部的流畅性，却埋没了那个真正决定结果的轮次。看起来最令人安心的指标，往往是最具欺骗性的。

轨迹级评估究竟在衡量什么

加载中…