【AI 质量衡量难题凸显】大多数公司面临的并非 AI 质量问题而是衡量问题。图片来源pirke / Shutterstock。Anthropic 作为一家在 AI 评估方面极为专业的公司在 Claude Code 中接连出现了三次质量倒退而其自身的评估机制却未能察觉。短短六周内就出现了三次倒退如果这种情况会发生在 Anthropic 身上那么它极有可能也会发生在你身上。【Anthropic 问题剖析】在一篇坦率的事后分析报告中Anthropic 详细剖析了问题所在。3 月 4 日团队将 Claude Code 的默认推理力度从高调整为中因为内部评估显示对于大多数任务而言这样做仅会使智能表现“略有下降”但能显著降低延迟。3 月 26 日一项旨在清除闲置一小时后陈旧思维的缓存优化功能上线但其中存在一个漏洞导致它在每次交互时都会清除缓存。4 月 16 日两条看似无害的系统提示语本意是让 Claude 回答更简洁结果却使编码质量下降了 3%而这一问题仅在更广泛的消融测试套件中被发现该套件并非标准发布流程的一部分。从公司内部来看这些问题都未触发警示信号但用户几乎立刻就开始抱怨了。这并非说明 Anthropic 工作粗心而是表明即便对于那些执着于评估的团队来说AI 质量也难以把控。而对于其他团队而言仅凭直觉行事则会带来风险。那么我们该如何解决这个问题呢【摒弃凭直觉发布的做法】Andrej Karpathy 创造了“凭直觉编码”这一术语用以描述这样一种过程描述自己的需求让模型自行运行然后尽量不去深究最终的结果。这种方法对于原型开发来说尚可但对于构建生产级软件而言却是糟糕透顶。单元测试、集成测试、回归测试套件、金丝雀部署等方法之所以成为行业标准并非是因为开发者喜欢繁琐的流程而是因为最终凭猜测的成本超过了实际测量的成本。AI 领域如今也到了这一步Anthropic 的事后分析报告清晰地表明即便那些构建底层模型的人也不能仅凭感觉来发布产品。很多关于 AI 评估的讨论都存在误区人们往往将评估视为一种花哨的新型测试套件。实际上评估确实有这方面的作用但并不完全如此。一个好的评估应该明确对于你的应用而言质量意味着什么。它能促使团队提前明确什么样的表现是良好的什么样的情况属于失败哪些权衡是可以接受的以及业务能够承受多大的差异。而大多数团队往往低估了差异这一问题的严重性。Anthropic 针对智能体的评估指南明确区分了 passk智能体在 k 次尝试中至少成功一次和 pass^k智能体在 k 次尝试中每次都成功。一个内部的分诊工具在经过几次重试后只要得到一个有效的答案即可因此可以接受 passk但面向客户的工作流程则不能如此。如果一个任务的成功率为 75%那么连续三次成功执行的概率就会降至约 42%。这可不是无足轻重的四舍五入误差而是演示与实际产品之间的巨大差距。另一个打破传统模式的因素是AI 打破了传统自动化所依赖的假设。曾在 Block 负责 AI 工具和赋能工作如今在 Agentic AI Foundation 管理开发者体验的 Angie Jones 长期以来一直认为传统的测试自动化假定“必须提前知晓确切的结果”这样才能进行断言验证。而在机器学习领域“不存在绝对的精确性结果存在一定的可能性范围”。她对于开发者方面也直言不讳“凭直觉编码虽然有趣但在构建生产级应用时却充满风险。即便我们采用了新的方法也不意味着旧方法就过时了。”她的观点完全正确。AI 并不会消除工程规范反而会让忽视它的代价变得更高。Anthropic 自己的评估指南也充分体现了这些观点。智能体比单轮对话式聊天机器人“本质上更难评估”因为它们需要进行多轮交互、调用工具、修改外部状态并根据中间结果进行调整。因此评估指南建议将结果、对话记录、工具调用、成本和延迟等方面作为独立的维度进行评估同时进行多次试验并将能力评估与回归评估清晰区分开来回归评估的通过率应接近 100%其目的是防止性能下滑。【改进循环】不同厂商的有效改进循环模式正逐渐趋于一致。LangChain 在 4 月的更新中推出了 30 多个评估模板涵盖了安全性、响应质量、轨迹和多模态输出等方面同时还提供了成本预警功能并在智能体改进循环中大力引入人工判断。Karpathy 的自动研究实验也以不同的方式阐述了相同的观点。在该实验中一个智能体在两天内针对自己的训练代码进行了 700 次实验并做出保留或回退的二元决策。大多数 AI 开发者在评估方面投入不足而评估本身就是产品的一部分。抛开工具不谈改进循环其实很简单生产环境中的用户投诉转化为问题追踪问题追踪确定失败模式失败模式催生评估评估形成回归测试回归测试成为发布的关卡。只有这样你才能更改提示语、更换模型、调整检索策略或优化成本/延迟的权衡。相比之下大多数团队要么是逆向执行这个循环要么根本没有执行。这显然是不可取的。许多团队目前的做法也无济于事。例如某个团队采用了 LangSmith这本身是个不错的选择配置了几个轨迹评估器使用大语言模型LLM作为评判者对输出进行评估然后发布了一个显示一切正常的仪表盘。乍一看似乎很不错毕竟仪表盘显示绿色就意味着智能体表现良好对吧然而你可以伪造仪表盘的数据但无法伪造用户的实际体验。因此在产品评审时可能会有人说“这个智能体感觉变笨了。”事实也的确如此。此时指着仪表盘说“评估结果都是绿色的”只能暴露你在大规模地自欺欺人。糟糕的评估会带来虚假的信心这比没有信心更糟糕。如果你的评估范围过于狭窄团队就会围绕这些评估进行优化如果评估者过于死板就会惩罚有效的解决方案奖励表面上的合规行为如果你完全依赖 LLM 作为评判者而不与人工评审进行校准那么你只是将凭直觉行事的层面降低了一级并没有真正消除这个问题如果你的评估集从不更新它就会变成一个充斥着陈旧假设的“墓地”。一个好的评估不应关注“答案听起来是否不错”。现代模型最擅长的就是给出听起来不错的答案这是概率系统在不真正理解真相的情况下模仿真相的表现但这也是你能收集到的最无用的质量信号。一个自信但选择了错误工具路径的智能体是非常危险的。Anthropic 事后分析中一个有趣的点在于这些质量倒退是由合理的改进措施导致的。降低延迟是好事减少冗长表述或者说在某些情况下是好事也是如此更好的缓存机制同样如此。没有人会在产品会议上说“让我们把编码智能体的性能变差。”他们会说“用户讨厌等待”或者“我们消耗的令牌太多了”这些观点本身是正确的但这并不能成为发布一个导致性能倒退的版本的理由。【应对之策】因此AI 团队不应将质量、延迟和成本视为单一的综合指标它们之间是需要权衡的关系而非同义词。例如简洁的回答可能更适合状态更新但对于代码审查来说可能就不太合适较低力度的推理模式可能适用于模板化的任务但对于多文件重构可能会造成损害。成本优化措施必须证明它没有损害质量提示语的更改也必须证明它没有影响智能体的行为。那么我们应该怎么做呢如果你是一位技术领导者面临着“我们有一个智能体已投入生产”但“不确定我们的评估是否有效”的情况还是有希望的并且有一些明确的指导方针可供参考。首先将用户投诉视为最有价值的评估输入。每一条诸如“Claude 变笨了”或“智能体忘记了我们刚刚告诉它的内容”的 Slack 消息都是一个等待编写的测试用例。Anthropic 的错误并非在于缺乏评估基础设施而是用户反馈信号与评估覆盖之间存在滞后长达两周。如果从生产环境中的用户投诉到回归测试套件的反馈周期需要数周时间那么这就是一个流程问题而非工具问题。其次编写更少但更优质的评估用例并仔细阅读每一条对话记录。Anthropic 建议从实际失败案例中选取 20 到 50 个任务进行评估这是非常合理的因为你并不需要上千个合成测试用例只需要从生产事故中选取几十个案例结合基于代码的检查用于确定性验证和经过人工评审校准的 LLM 评判用于无法确定性验证的情况进行评估即可。第三确保在评估中体现产品的价值观。如果你正在构建一个编码助手那么你应该关注测试通过率、代码风格的保留、安全问题的避免以及不随意修改代码库等方面如果你正在构建一个客户支持智能体那么你需要关注回答的事实准确性、语气、问题升级处理、政策合规性、问题解决率以及是否在解决旧问题的同时引发了新问题等。通用的“有用性”评估指标无法涵盖这些方面。第四将回归测试作为发布的关卡而非发布后的报告。如果某项更改导致回归测试得分下降就不应发布该更改。正如我之前所强调的企业中能够存活下来的智能体是那些能够可靠且可预测地完成少数任务的智能体而实现这一目标的唯一途径就是拒绝部署任何会破坏现有功能的更改。最后在编写提示语之前先进行评估。在开始调整系统之前你需要明确什么样的表现才是良好的。提示语只是实现目标的手段而评估则要提前明确这个目标。【超越演示阶段】在 AI 工程的征程中我们仍处于早期阶段因此将凭直觉驱动的演示误认为是进步或许是可以原谅的。但这种情况不会持续太久。正如 Jones 最近所说“很多人归咎于 AI 的问题实际上一直都存在AI 只是放大了这些问题。”评估是阻止问题放大的关键。在下一阶段取得成功的团队并非拥有最复杂评估仪表盘的团队而是拥有最真实反馈循环的团队。他们会清楚哪些失败是重要的知道模型升级何时起到了积极作用何时又悄然破坏了工作流程。简而言之他们会知道自己的智能体何时真正得到了改进。评估或许并不引人注目但它能引领我们打造出出色的、可投入生产的系统。