仅靠大模型充当评估者救不了产品，关键在于优化流程

很多人对产品评估（product evals）存在误解。一些人认为，只要增加新的评估工具、指标，甚至是让大模型（LLM）充当评估者（LLM-as-judge），就能解决问题、挽救产品。但这恰恰是绕开了核心问题，逃避了真正要做的工作。

评估并非一成不变的产物或速效药；它们是一套实践方法，涵盖了科学方法、评估驱动开发（eval-driven development，简称EDD）和AI输出监控。

构建产品评估体系，本质上就是应用科学方法。 这才是其中的秘诀。它是一个循环往复的过程，包含探究、实验和分析。

这个过程首先始于观察 ，即仔细审视数据，俗称“看数据”。这意味着检查我们的输入、AI的输出以及用户与系统交互的方式。通过观察数据，我们可以了解系统哪些方面表现良好，更关键的是，哪些方面存在问题。识别这些失效模式（failure modes）是实现有意义改进的起点。

接着是标注 数据，重点是那些存在问题的模型输出。这意味着对成功的和失败的样本进行标记，以构建一个均衡且具有代表性的数据集。理想情况下，通过和未通过的样本比例应为 1:1，并涵盖输入分布的各种情况。这个数据集是进行有针对性的评估、追踪针对已识别问题的性能表现的基础。

然后，我们要假设这些失败的原因所在。也许是检索增强生成（RAG）系统未能返回相关的上下文，抑或是模型难以遵循复杂（有时甚至是相互冲突的）的指令。通过查看检索到的文档、推理轨迹和错误的输出等数据，我们可以优先确定要修复的失败类型和要验证的假设。

接下来，我们设计并运行实验 来验证假设。实验可能包括重写提示词、更新检索组件或更换不同的模型。一个好的实验会明确定义哪些结果能证实或驳斥假设。理想情况下，实验还应包含一个基线或对照组，以便进行对比。

而衡量结果，分析错误 通常是最具挑战性的一步。这不像随意的“凭感觉检查”，它要求量化实验更新是否真正改善了结果：准确率是否提高了？产生的缺陷是否减少了？新版本在成对比较中表现是否更好？如果我们无法衡量结果，就无法对其进行改进。

如果实验成功，就应用更新；如果失败，就深入进行错误分析，完善假设，然后再次尝试。通过这种迭代循环，产品评估成为了推动数据飞轮的动力，不断改进我们的产品，减少缺陷，赢得用户信任。

将科学方法应用于构建AI产品。

评估驱动开发（EDD）有助于我们构建更好的AI产品。 它类似于 测试驱动开发（test-driven development），即先编写测试，然后再编写能通过这些测试的软件。EDD遵循相同的理念：在开发一个AI功能之前，我们首先通过产品评估来定义成功的标准，确保从一开始就目标明确且可衡量。这里有个秘密：机器学习团队几十年来一直在实践这一点，他们会针对 验证集和测试集（validation and testsets） 来构建模型和系统。这些想法虽然名称不同，但本质是相通的。

在EDD中，评估指导着我们的开发。我们从评估一个基线（比如一个简单的提示词）开始，获得初步的基准。从那时起，每一个提示词的微调、每一次系统更新、每一次迭代都会被评估。简化提示词是否提高了输出的可信度？更新检索组件是否提高了相关文档的召回率？或者说，这次更新是否导致性能下降了？

由于EDD提供了即时、客观的反馈，我们可以清楚地看到哪些地方在改进，哪些没有。这种循环——编写评估、进行修改、运行评估、整合改进——确保了可衡量的进展。它不是依赖模糊的、基于直觉的认知，而是建立了一个根植于软件工程实践的反馈闭环。

首先，编写一些评估；然后，构建能通过这些评估的系统。

即使采用了自动化评估器（即大模型充当评估者），仍然需要人工监督。 自动化评估有助于大规模监控，但并不能弥补疏忽。如果我们不积极审查AI输出和客户反馈，自动化评估器并不能拯救我们的产品。

为了评估和监控AI产品，我们通常会采样输出，并对其质量和缺陷进行标注。有了足够数量的高质量标注数据，我们就可以 校准自动化评估器，使其与人类判断保持一致。这可能包括衡量二元标签的召回率或准确率（precision），或者在进行成对比较时衡量与人类选择结果的相关性。一旦经过适当校准，这些评估器就能帮助实现AI系统的持续大规模监控。

但拥有自动化评估器并不能取代人工监督的需求。 我们仍然需要定期采样和标注数据，并分析用户反馈。理想情况下，我们应该设计能够通过用户交互捕获隐含反馈的产品。尽管如此，显式反馈（虽然频率较低且偶尔带有偏见）也同样有价值。

此外，虽然自动化评估器擅长规模化，但并非完美无缺。人类标注者也是如此。尽管如此，通过收集更多和更高质量的标注数据，我们可以更好地校准这些评估器。保持定期采样数据、标注输出、改进自动化评估器这一反馈循环，需要组织上的纪律性，这一点至关重要。

自动化评估器放大了我们现有的标注和反馈流程。

虽然使用AI进行开发有时感觉像魔法，但构建AI产品仍需要实打实的努力。如果团队不应用科学方法、不实践评估驱动开发、不监控系统输出，那么仅仅购买或构建另一种评估工具并不能拯救产品。