8.0
热点
AI SCORE
编程提效2026-08-06 01:57
AI Evals 入门：如何真正评估你的 AI 系统效果
dev.to · AI#AI评测#LLM#工程实践
Editor brief · 编辑速览
Eval 是 LLM 时代的单元测试，结构化测试 AI 系统的质量、可靠性和正确性。投资 Eval 能缩短开发周期、降低成本、提升质量和扩大团队协作范围。
如果你曾经上线过一个 AI 功能，然后心里默默祈祷它能正常工作，这篇文章就是为你写的。Eval（评估）是一种结构化的测试，用来衡量你的 AI 系统表现如何：它在各种场景下的质量、可靠性和正确性。可以把它想象成 LLM 世界的单元测试，只不过你测试的东西是概率性的、反复无常的，而且每次新模型发布都可能发生变化。
投入做 Eval 的团队会看到四大回报。首先，它们缩短了开发时间，因为你可以获得快速的迭代周期，可以在本地跨多个 LLM 测试，而不是逐个目测输出。其次，它们降低了成本，因为自动化 Eval 取代了缓慢的人工审查，让你更快地上线。第三，它们提升了质量，因为实时监控和合规检查降低了风险，改善了用户体验。最后，它们让团队得以扩展，因为一套好的 Eval 体系让非技术背景的协作者也能为打造最佳产品体验贡献力量。
Greg Brockman 用一句令人印象深刻的话概括了这个理念：
关键不在于提示词、可观测性或人工判断不再重要，而在于一旦 AI 系统能够产生看似合理的输出，往往最难的部分变成了：知道你的下一个改动是让它变好了还是变差了。
这个心智模型有三个支柱。Prompt 和上下文工程让你有一个地方来原型化行为。Eval 回答的是 AI 开发中最重要的一个问题：我刚才让情况变好了，还是变差了？根据你衡量的内容，结果可能是一个数字、通过或失败、一个类别，或者书面反馈。AI 可观测性告诉你生产环境中实际发生了什么，所以当出问题的时候，你可以把失败转化为一个可复现的测试，而不是依赖猜测。
大多数离线 Eval 可以用相同的三个部分来理解，尽管不同框架给它们起的名字不同。
Target（目标） 是你想要评估的代码、Prompt、模型或工作流。有些工具称之为 task、application、predict function 或 system under test。它可以小到一个模型调用，大到一个完整的 Agent 工作流。重要的是：相同的输入可以运行在不同版本上，这样你就可以比较它们的行为。
Dataset（数据集） 是你的测试用例集合。一个用例通常包含一个输入，也可能包含参考答案、期望属性、评分规则、元数据、标签或其他上下文。具体的 schema 取决于框架和你正在测试的行为。参考答案并不总是必要的：安全性、风格、延迟和许多其他标准可以在没有精确理想输出的情况下进行评估。
Evaluator（评估器） 是衡量目标行为的逻辑。有些框架称之为 scorer、grader、metric 或 judge。它可以是确定性代码、基于模型的评判器、人工审查，或者它们的组合；它可以返回数字、布尔值、标签、排名或结构化反馈。
两种常见的模式是离线评估和在线评估，成熟的团队通常会同时使用两者。
离线 Eval 在策划好的或历史积累的测试用例上运行，通常发生在开发期间、CI 中或发布前。其目的是在受控条件下 catching 回归、比较版本和理解权衡。你可以用本地脚本、测试框架、Jupyter notebook 或评估平台来运行它们；工作流是相同的，尽管界面可能不同。
在线 Eval 在系统运行时测量选定的生产交互。它们通常基于 traces、日志、用户反馈或采样流量，专注于不需要已知参考答案的信号，例如安全性、政策合规性、相关性、延迟或用户满意度。Tracing 和评估是相关但不同的：tracing 记录发生了什么，而评估器对其作出判断。有价值的生产用例应该先经过审查和筛选，然后再成为离线测试用例。
这里有一个值得牢记的心智框架。当你将输出与评估器结果进行比较时，有四种可能：
有趣的象限是那些不匹配的情况。好的输出配上负面结果，或者坏的输出配上正面结果，都意味着你的评估标准需要改进。
实践中的要点是：建立基线并立即开始迭代。别等着那个永远不会到来的完美黄金数据集。
最简单的 target 是单个模型调用。它的 Prompt 可能将指令与变量结合起来，例如用户的问题、检索到的上下文或对话状态。不同库中的模板语法各不相同，所以重要的是你传入的数据契约，而不是用来表示变量的括号。
System: Answer using the supplied context.
User question: {question}
Context: {context}
单调用 target 适用于隔离测试指令、示例、输出格式、检索上下文和模型选择。
对于多轮场景，评估一系列消息或整个对话。这非常适合衡量聊天体验是否记住上下文、是否遵循不断变化的指令，以及是否在多轮中保持连贯。
工具调用系统又增加了一层。评估器可能需要检查最终答案之外的内容，例如工具选择、参数、权限、中间结果、成本和延迟。工具可以用任何语言或服务实现；重要的是模型和工具之间可观测的契约。
Agent 和多步骤工作流结合了模型调用、工具、状态、路由和控制逻辑。评估它们通常意味着同时对结果和轨迹进行评分：系统是否以安全、高效和可重现的方式达到了正确结果。
数据集收集你的测试用例，这样你就可以运行可重复的评估并跟踪随时间的改进。三个技巧决定了数据集是有帮助的还是腐烂的：
从小处着手并迭代。专注于建立反馈循环，而不是打造一个完美的数据集。
永不停止迭代。使用生产日志捕获新的边缘用例，让你的 Eval 随着时间推移变得更加全面。
实施人工审查来建立真实标签（ground truth），尤其是当你依赖一个 expected-output 字段时。
有两类常见的自动化评估器。
基于代码的评估器 处理任何确定性的东西：精确匹配、数字比较、结构化检查或事实核查。像下面这样简单的东西也算：
output === expected ? 1 : 0
它们也可以在你的 CI 流水线中运行。Schema 验证、精确匹配、字符串相似度度量（如 Levenshtein 距离）、数值容差和二元检查等技术也属于这一类。
基于模型的 Judge 处理需要语义或主观理解的工作，例如相关性、语气、完整性或跨版本的改进。Judge prompt 可以很简单，例如："这个回复是否包含道歉？返回 PASS 或 FAIL，并简要解释原因。"
两种常见的 Judge 模式：
直接评估，你设计一个评分规则。
成对比较，Judge 在两个输出中选择较好的一个，排名算法对整体质量进行排序。这对于主观任务特别有用。
关于评估器的一些来之不易的技巧：
使用一个对评估标准足够能力的 Judge，并将其配置与被评估的系统分开。
像对待真正的法官一样对待评估器，评估意图、风格和整体质量，而不仅仅是正确性。
将评估分解为聚焦的标准，例如准确性、创造性、安全性和格式化，这样你就可以精确定位到底是什么坏了。
在信任基于模型的 Judge 之前，用有人工标签的代表性示例对其进行校准。
不要给 Judge 加载过多上下文。让它专注于相关的输入和输出。
这里最重要的理念之一是：评估器是项目规格说明书中可执行的部分。编写反映你的用户和失败模式的标准至关重要，因为通用指标很少能捕捉到你的产品真正需要的一切。
并非所有 AI 错误都是平等的。在医疗、金融或法律科技等高风险行业，一次失败可能意味着监管违规或真实的用户伤害。这就是为什么这些领域的团队大力投入于清晰的真实标签定义、使用人工领域专家作为标注员，并在工作流中应用 human-in-the-loop 来细化评分。
在这些场景中，人工审查不是"有就更好"，而是必不可少的。它对于 catching 幻觉、建立真实标签、确保与业务、合规和用户期望保持一致至关重要。自动化会遗漏细微差别。真实的人会识别错误、标注正确输出，并确保最终产品真正满足人类需求。
Human-in-the-loop 工作有两种形式。人工审查 使用内部专家手动标签、评分或审计输出。它对于构建高质量的真实标签数据集、审计边缘用例和校准基于模型的 Judge 很有用。一个例子是法律领域专家精确定义法律 AI 助手应该如何回应。
用户反馈 是最终用户在真实使用过程中的隐式或显式信号。点赞或点踩、标记、评论、修正和有用性评分可以触发人工审查，或将生产 trace 标记为数据集策划。
公式很简单：规模化自动化测试加上人类判断的细微差别，创造出北极星体验。
Trace 记录了你的应用程序的一次端到端执行。在其中，一个 span 代表一个工作单元，例如模型调用、检索步骤、工具调用或业务逻辑函数。Spans 可以嵌套，以显示较小的操作如何贡献到整体结果。具体的名称和边界取决于你如何为应用程序添加检测（instrumentation）。
为什么 trace 对数据集很重要？当你的 instrumentation 记录了相关字段时，trace 可以保留真实行为的输入、输出、中间步骤和上下文。当出问题的时候，例如 AI 错误地改写了用户的问题，你可以将相关输入和 trace 保存为新测试用例的基础。失败的生产输出是问题的证据，而不是期望的答案。添加一个修正后的参考答案、评分规则或明确定义成功应该是什么样子的属性，然后用那个策划好的用例作为回归测试。
这一切在一个值得内化的循环中汇聚在一起：
飞轮的每一圈都让你的 Eval 更加真实，让你的产品更加健壮。
最大的心态转变是用 Eval 打出攻势。Eval 不仅仅是 catching 回归的安全网。它们是你能够以更快的速度、更高的信心上线更好产品的东西。
一些原则由此而来。出色的 Eval 需要被刻意设计，而不是被附加上去。将数据集视为需要维护的工程资产：记录来源、对有意义的变更进行版本控制、对近似重复进行去重、保护敏感数据，并在集合增长时保持标签一致性。Prompt 工程也在演进为上下文工程。系统指令只是生产模型所看到的输入的一部分；对话历史、检索到的文档、工具定义和结果、记忆和策略上下文可能主导输入。评估整个上下文组装过程，而不仅仅是 Prompt 文本。
最后，记住当新模型发布时一切都会改变。模型无关的 Eval 是你抵御 LLM 不确定性的防线。它们让你能够高效且有意识地切换模型和发布。优化整个评估系统，而不仅仅是 Prompt。一旦你的 Eval 稳固了，你甚至可以完全闭合循环，用它们来自动改进你的 Prompt。
Eval 将 AI 开发从"凭感觉"变成工程。从一个 target、具有代表性的测试用例和表达你的用户认为"好"是什么意思的评估器开始。在构建时运行离线 Eval，上线后监控选定的质量信号。将生产失败策划成回归用例，在高风险的地方保持人类参与，并将你的评估标准视为产品规格中活的部分。这样，"我是改进了还是退步了？"就不再是猜测，而是一个你可以用证据回答的问题。