不只看准确率：在大模型时代如何把Evals真正跑起来

Adobe应用AI负责人Muktesh Mishra在这场分享中，系统拆解了为何“评估（Evals）”已成为AI应用的生命线，以及如何跳出准确率与相似度的局限，把Evals当作一套可规模化、可演进的工程体系来建设。

为什么没有Evals，就没有真正的AI应用

这场演讲一开始，Muktesh Mishra就抛出了一个很多AI工程师都有切身体会的问题：当模型输出是非确定性的，我们到底该怎么“测试”AI应用？同样的输入，每次回答都不一样；改了一句Prompt，却不知道会破坏哪条业务链路。这些并不是个别现象，而是大语言模型时代的常态。

他的核心判断非常明确：“没有Evals，我们就无法构建任何AI应用。”在他看来，Evals本质上就是AI世界里的测试用例，只不过测试对象从确定性程序，变成了需要主观判断的生成式系统。Evals存在的价值，不只是评估准确率，而是帮助团队回答三个更大的问题：系统是否在朝目标前进？是否在持续变好？以及，用户是否能信任它。

Muktesh特别强调了“信任与问责”。当AI应用直接面向客户时，输出质量不再只是技术问题，而是业务风险。评估不是锦上添花，而是企业敢不敢上线、敢不敢持续迭代的前提条件。这也是为什么他观察到，Evals正在成为AI应用开发中最重要的趋势之一。

从数据开始：Evals不是写出来的，是“养”出来的

当谈到如何真正开始做Evals时，Muktesh把重心放在一个看似朴素、却最容易被忽略的点上：数据。他反复强调，Evals的第一步不是选工具，也不是定指标，而是数据本身。

他的建议是“从小开始，用合成数据起步”。合成数据并不意味着随意编造，而是有意识地生成覆盖关键场景的测试输入，用来验证系统输出是否符合预期。更重要的是，这不是一次性工作，而是一个持续改进的过程：生成输出、观察系统、补充数据集，再回到评估本身。

另一个来自实践的经验是：“一个数据集永远不够。”不同应用流、不同用户路径、不同失败模式，都需要各自的数据集来覆盖。数据还必须被清晰标注，明确它在评估哪一类能力、哪一种风险。Muktesh的隐含观点很清楚：Evals的质量，最终取决于你对自己系统的理解深度，而这种理解，几乎全部体现在数据上。

没有通用指标：Evals必须为应用“量身定制”

在演讲中，Muktesh多次强调一个反直觉但极其重要的结论：“不存在通用的Eval。”评估方式必须紧密贴合应用类型，否则指标再漂亮也毫无意义。

以RAG（检索增强生成）或问答系统为例，准确率、相似度、回答是否有用，往往是合理的评估维度；但一旦进入代码生成场景，评估重点就彻底改变了——是否能通过现有代码库的测试、功能是否正确、生成代码是否足够健壮，才是核心。

而在AI Agent场景中，复杂度进一步上升。Agent可能通过不同路径完成同一目标，这时“轨迹评估”就变得至关重要：它走了哪条路径？是否调用了正确的工具？在多轮对话中是否保持一致性？Muktesh并没有给出统一答案，而是反复提醒：评估设计本身，就是对应用本质的一次深度建模。

把Evals跑到规模：流程比工具更重要

真正的难点不在于“有没有Evals”，而在于如何把它们跑到规模。Muktesh给出的关键词是：编排、并行、频率和迭代。

在工程层面，他建议缓存中间结果、做回归测试，通过并行化来提升评估效率；在方法论层面，他提出了一个在行业中逐渐流行的循环：“Measure， Monitor， Analyze， Repeat（测量、监控、分析、重复）”。评估不是一次性验收，而是一条伴随应用整个生命周期的反馈回路。

他也非常坦率地谈到了人类参与的问题：有些场景必须有人在环，才能保证高保真；有些场景则需要自动化来换取速度。这里没有标准答案，只有取舍。正如他所说，与其迷信工具，不如先把流程定义清楚——因为“你无法自动化一切”。

总结

Muktesh Mishra的分享传递了一个清晰信号：在大模型时代，评估不再是上线前的检查项，而是一种持续性的工程能力。从数据出发，针对应用定制指标，用流程而非工具驱动规模化运行，才能让AI系统真正变得可控、可信、可演进。对每一个正在构建AI应用的团队来说，Evals不是成本中心，而是长期竞争力的来源。

关键词： Evals， 大语言模型， AI应用， RAG， AI Agent

事实核查备注： 演讲者：Muktesh Mishra；公司背景：Adobe 应用AI负责人；核心概念：Evals、RAG、AI Agent、轨迹评估、Measure-Monitor-Analyze-Repeat；观点：不存在通用Eval、Evals类似AI时代的测试用例