AI 评测 (AI Evaluations)：比模型更大的护城河

开始构建你的评测体系，最好的时机是昨天，其次是现在

我是在 6 月末了解到 AI 评测的，慢慢地开始感受它的魔力。虽然我可能还没有真正深入去对一个复杂的 Agent 进行评测，但 AI 评测驱动开发的理念已经让我深深着迷。让我们先看看硅谷的大牛们是怎么说的。

硅谷大牛眼中的 AI 评测

OpenAI 联合创始人 Greg Brockman 早在 2023 年 12 月就指出：“Evals 出人意料地往往就是你所需要的全部。”

Y Combinator 总裁 Gary Tan 年初在 X 上发帖：“AI Evals 正在成为 AI 初创公司真正的护城河。”

知名 AI 投资者 Anjney Midha 也表示：“我认识的最好的 AI 产品领导者习惯于公开说‘品味（taste）’是他的差异化因素，但在幕后，一切都是无情的 evals。”

Open AI 研究员姚顺雨也在 4 月份发布的 Th Second Half 中明确指出 “在这个新时代，评测变得比训练更加重要。我们不再仅仅问“我们能训练一个模型来解决 X 问题吗？”，而是开始问“我们应该训练 AI 去做什么，以及我们如何衡量真正的进展？”

这些不仅仅是随口的评论，而是标志着在 AI 时代，我们构建软件的方式必须发生根本性改变，传统的确定性开发范式正在瓦解。

从传统开发到 LLM 开发

我们首先需要认识到 AI 开发与传统软件工程的巨大差异，我们用一个小例子来说明下。

在传统开发里，开发者的操作是精确且可预测的。比如构建一个网站的登录功能：

• 目标明确：正确的密码可以登录，错误的密码则被拒绝。

• 过程是确定性的：你编写代码来处理逻辑，然后编写一个单元测试，断言（assert）正确的密码会“成功”，错误的密码会“失败”。

• 影响是局部的：修复一个 bug 的影响是精确的。你知道哪一行代码出了问题，并且可以预测你所做修改的确切结果。 这就是工程 (Engineering)。它建立在可验证的因果关系之上。

AI 开发，尤其是涉及大型语言模型 (LLM) 和智能体 (Agent) 的开发，则完全不同。

想象一下，你的任务是让一个客服 Agent 的回答“更简洁”。

• 目标是模糊的：“更简洁”到底意味着什么？怎么表达简洁？

• 过程是实验性的：你可能会在系统提示词里简单地加上一句话：“你的回答必须简洁，直接给出结果”。

• 影响是全局且不可预测的：这个看似简单的改动可能会引发连锁的、无法预料的后果。Agent 的回答可能确实变简洁了，但也可能变得“生硬”和“不友好”。更糟糕的是，为了追求简洁，它可能不再输出思考过程，导致其使用工具或遵循复杂逻辑的能力下降。最糟糕的是，你还不知道，以为你测试通过了。

这更像是 猜测(Guesswork) 。因果之间的直接联系消失了，取而代之的是一个复杂的、概率性的系统，其中每一个微小的改动都可能波及整个产品。你的提示词、工具和业务逻辑，现在都成了一种行为不确定的代码。

最近很多人都开始了 vibe coding，开发得很爽。尤其是 cc，一句话前后端全部做出来。我自己是用 cursor，也是一个功能描述清楚之后就能实现。不过回到自己最近在做的项目，可以快速开发完前后端后，我沉默了：

• 我要怎么测我的 AI 功能？

• 我的测试集哪里来？

• 我怎么评判我的 AI 功能比别人好？

• 甚至我怎么知道我的效果在持续变好？

• 我为了调试我的 prompt，是不是会改变我存储的数据结构，甚至要引入新的数据到 context 里面来。

  
  

因此，我停了下来，重新思考 LLM 开发流程到底应该是怎么样的【这部分可以之后再讲】。

那到底什么是 AI 评测

传统开发的测试同样会准备很多测试用例，有明确的输入，操作步骤，以及预期输出，更像是一个“判断题”。那 AI 评测就像是有一套详细评分标准的开放式问答考试。

它不是简单地判断“对/错”，而是对 AI 系统在特定任务上的表现进行系统性、多维度衡量和打分的过程。一个评测活动通常由几个核心部分组成，而一个完整的评测体系则是一个持续迭代的闭环，它包含分析、量化和优化三大环节。

评测的核心组成

1.评测数据集 (The Test Cases)：这是一系列精心设计的、用来“考验”AI 的输入或场景，通常被称为“黄金测试集” (Golden Set)。

2.成功标准 (The Success Criteria / Rubrics)：这是你用来定义“好”与“坏”的多维度标尺。

3.评分机制 (The Scoring Mechanism / Evaluator)：这是将 AI 的实际输出与“成功标准”进行比较并打分的方法，可以是人工、代码规则或“AI 裁判”。

一个完整的评测循环

拥有了以上组件后，一个科学的评测体系会按照以下循环流程来运作：

第一步：构建数据集 (Construct Dataset)

评测的起点是构建一个高质量的数据集。这包括从真实场景中收集数据样例，以及通过 AI 合成新的样例来丰富测试的广度和深度。

第二步：人工分析 (Manual Analysis)

在数据集上运行模型后，团队需要仔细查看结果，并对其中出错的案例（case）进行归纳分类。例如，是事实性错误、逻辑不通，还是未能正确使用工具？

第三步：系统量化 (System Quantization)

这是关键的一步。团队需要基于对出错案例的主观分析，将其转化为系统可以追踪的量化指标。例如，将“经常无法回答数学问题”这个主观感受，转化为“数学问题场景下的回答准确率”这个客观指标。

第四步：针对优化 (Targeted Optimization)

有了清晰的量化指标后，团队就可以进行有针对性的优化。优化的手段包括：

• 优化 Prompt 和上下文 (context)

• 优化模型本身（例如微调）

• 优化整个工作流 (workflow)

总而言之，一次 AI 评测就是将“评测数据集”作为输入，让你的 AI 系统运行，然后通过“评分机制”对照“成功标准”给输出打分的过程。

AI 评测应该成为基础设施

在开启评测时，通常是通过编写简单的脚本开始的。但要真正使开发过程专业化，你必须将评测视为核心的基础设施 (Infrastructure)，而不仅仅是一个一次性的工具，或者框架。

一个 AI 评测框架（AI Evaluations framework）可能会给你定义测试的工具，但 AI 评测基础设施（AI Evaluations Infrastructure）则是一个支撑你在生产环境中运行、管理和扩展这些测试的平台。我们不用深究，只需要知道这个概念就好。现在的很多评测工具，开源项目其实也都要包含这些内容，但是只有将这里面的每个模块都揉进整个 AI 开发生命周期里面，才会成为真正的 AI 评测基础设施。

该基础设施的关键组成部分包括：

• 可观测性(Instrumentation)：能够追踪 AI 系统所走的每一步——每一次 LLM 调用、每一个被使用的工具、每一个中间的思考过程。这为成本、延迟和错误的精细化诊断提供了可能。

• 生产数据集成 (Production Data Integration)：最有价值的测试用例来自于真实的用户交互。基础设施必须提供从生产环境中捕获这些交互、将其提取为版本化的数据集，并反馈到评测流程中的能力。

• 可复现性与版本管理 (Reproducibility and Versioning)：要成为一门可靠的工程学科，评测必须是可重复的。这意味着在每次运行时，都需要捕获系统的确切状态——包括模型版本、提示词、数据集和评测代码。这是 AI 回归测试的基石。

相较于能够熟练掌握 AI 评测体系以及使用 AI 评测工具，更为重要的，我相信是团队的 AI 评测文化。

AI 评测文化是终极战略

即使有再好的基础设施，如果没有合适的团队文化，也无法发挥作用。最成功的 AI 团队把评测当作核心流程和集体习惯，而不是 QA 部门的单纯技术任务，用它来推动学习和产品迭代。

Hex 在这方面提供了一个典范，他们开创了一种名为“评测派对(evals parties)”的实践。这是一种定期的仪式，整个团队聚集在一起，复盘他们的 AI Agent 在真实场景中的成功案例，以及——更重要的——失败案例。

这种文化体现了一种关键的心态转变：评测的目的不是为了获得高分，而是为了发现有价值的失败模式。一个你的模型能得 99 分的测试集，其价值远不如一个模型只能得 70 分的、由少量困难边缘案例组成的测试集。那 30% 的失败率，正是最重要学习和改进机会所在。

立刻行动的四步起手式

别犹豫，不要问“要不要...”，不要说“怎么...”，问就是“干”。以下是轻量可行的四步：

1. 举办一次“评测派对”：不需要任何工具，先召集产品、研发和测试人员，花一个小时，一起审查 50 个来自生产环境的真实失败案例，并且定义成功的标准。这个文化仪式是建立共识和发现问题的最佳起点。

2. 定义黄金案例集：从上述案例中，挑选出 20-50 个最重要、最典型的场景，手动编写出理想的输出结果，构成第一份评测集。

3. 启用自动化评分：用更强大的模型（如 GPT-4）或规则来评判主模型的输出，立刻跑起来。

4. 持续回归 + 动态扩展：每次版本更新自动跑这些案例，发现新 bug 就补充新样例。

AI 评测不应再是发布的最后一个环节，而应是驱动整个 AI 开发生命周期的引擎。投资于高质量的、私有的评测数据集，是构建长期 AI 竞争力的最高杠杆活动。开始构建你的评测体系，最好的时机是昨天，其次是现在。从一个最小的、基于规则的回归测试集开始，然后逐步迭代。

真正的护城河，不是更大的模型，而是评测驱动开发 (Eval-Driven Development, EDD) 所带来的高效反馈循环和数据沉淀。它让团队从“猜测”走向真正的“工程”。

文章每一小节都可以展开非常多来阐述与讨论，碍于篇幅，只能先抛砖引玉。欢迎大家可以把问题抛出来，一起来讨论开发 AI 项目过程中碰到的评测的问题，碰撞出更多非共识认知。

接下去我也会总结一些其他公司在 AI 评测上的认知跟大家分享，以及我现在怎么用 langfuse 先跑起来一个小的评测。