Claude 的新自动评估工具
Anthropic 为 Claude Code 发布了一套新的评估工具。他们的 claude-api 插件现在包含新的 build_eval 和 hill-climb 命令，可以帮你构建评估集、检查评分器，并据此改进应用。我一般不太写评估工具的评测，因为软件更新太快，评测文章很快就过时了。但 Anthropic 官方出品的东西，很可能会影响大家做评估的方式，所以我想亲自试一试，把发现分享出来。我和 Isaac Flath 一起做了场直播，用一套公寓租赁助手的对话记录来实测。结果如下：
体验不佳的地方
1. 它催着你在看数据之前就先建评估
Claude 一上来就列出了几个可能的失败点，然后马上让我们挑一个做成评估。它给了下面这组选项，并推荐了“呼叫转接规则”这一项。可我们自己还没看过对话，根本判断不了这到底是不是真的失败，值不值得优先处理。尽管如此，我们还是照推荐选项走了，因为估计普通用户也会这么做。
我认为应该先看数据，建立自己的理解，再决定优先写哪些评估。智能体可以帮你发现问题，但在动手之前，你仍然需要做错误分析，判断哪些失败才值得关注。
2. 它让你在上下文不足的情况下验证判断
接下来，Claude 生成了一些 Markdown 文件，用来查看与“呼叫转接失败”相关的数据。在下面的截图里，Claude 让我们浏览 inputs.md，然后“告诉它”哪些标签是错的。这意味着你得在编辑器里读长长的对话，再另外在聊天里报告修正结果。我们觉得这很蠢——既然用的是编程智能体，它本该搭一个标注应用，让对话容易阅读，还能就地留下反馈。最后我们干脆让 Claude 给我们做了个网页应用，改用那个了。
到了工作流的后面，Claude 初步尝试为“呼叫转接失败”创建一个评估器。
它只给出汇总的标签数量，然后问我们“有没有哪个案例你会给出不同评分？”，却没提供足够信息让我们判断标签是否正确。整个工作流反复出现的一个问题是：太急着创建产物或请求我们批准，却没帮我们理解数据。
3. 评估器范围太宽
接下来，工具创建了一个呼叫转移评估器，一次性检查四种不同的失败情况：
-
多次请求确认，或未经确认就转接。（LLM 作为评判者）
-
在来电者同意与转接之间说了多余的话。（基于代码的评估）
-
在转接过程中或之后说了话。（基于代码的评估）
-
大声说出工具机制，比如“触发”转接。（基于代码的评估）
这个评估器捆绑了太多东西。我更希望把评估范围缩小，一次只关注一个错误，或者至少把需要基于代码评估和 LLM 作为评判者的评估分开。
Claude 对评估器的描述也让人困惑：protocol_ok 是核心指标。只有四项检查全部通过，案例才算通过。对于“不应转接”的呼叫，如果没有发生转接，protocol_ok 为 1。这种 AI 废话很难读。我更愿意看到代码或评判提示，这样我能理解正在创建什么。我发现读提示总是值得的，尤其是对评估这样重要的东西。
下面是这部分工作流的截图：
优点
这个插件开箱即用的能力让我印象深刻——它能发现其他自动评估方法找不到的问题！它发现了人工交接、格式、语音代理等方面的问题。用代理迭代查看数据仍然更好，但这是我见过的更“一次性”问题发现方法中最强的表现。
Anthropic 介绍这个工具的博客文章大致传达了我想法一致的观点，比如查看数据的重要性、智能采样、不要让自己的评估饱和等。我很高兴有更多人这样思考评估。
我会用吗？
暂时观望。
我更希望这套工作流能先帮我探索数据，然后再决定用哪个评估器（evaluator），而且一开始就提供更好的审查界面。另外，Shreya 和我一起做的那些 Eval skills 已经让我对编码智能体（coding agent）的能力挺满意了——它们不那么带主观倾向，但更灵活。后来我和 Claude eval 插件的作者聊过。他很认可这些反馈，说会据此更新插件，所以我预计它很快就会变。到时候也许值得再看看。即便这个插件变了，我也希望这篇走查能帮你评估其他 eval 工具。一定要确保工具能帮你在选评估方法之前先理解数据，并且仔细检查它给出的判断。我认为 eval 工作流的很大一部分应该放在 Web 应用里，而不是聊天里，这样才能减少数据探索和标注时的摩擦。记住：如果一个 eval 工具没有把“看数据”放在工作流的核心，那就不值得用。所有 eval 梗图都在我的梗图页面。感谢 Isaac Flath 审阅本文并和我一起做直播。
Anthropic 为 Claude Code 发布了新的评估工具。他们的 claude-api 插件新增了 build_eval 和 hill-climb 命令，可以帮助构建评估、检查评分器，并根据评估结果改进应用。我一般不怎么评测评估工具，因为软件变化太快，评测文章的保鲜期很短。但 Anthropic 官方推出的工具，很可能会影响大家做评估的方式，所以我想亲自试一下，把发现分享出来。我和 Isaac Flath 一起直播了试用过程。