用于衡量AI模型性能的方法。这远不止于基准测试——它包括人工评估（由人类对输出结果进行评分）、A/B测试（在真实流量中对比模型）、红队测试（对抗性测试）、领域特定测试（医疗准确性、代码正确性）以及社区排行榜（Chatbot Arena、LMSYS）。优秀的评估比构建模型本身更具挑战性。
如果你无法衡量它，就无法改进它。但AI评估尤为困难，因为任务是开放式的，质量具有主观性。基准测试容易被操控，人工评估成本高昂，而纸面上得分最高的模型往往在实际应用中并非最佳。构建优秀的评估体系是一种超能力。
人工智能的评估看似简单实则困难，因为你要衡量的事物——“这个输出是否优秀？”——通常是主观的、依赖于上下文的，并且是多维的。一个模型对“解释量子纠缠”的回应可能在技术上是准确的，但对受众来说过于专业；或者通俗易懂但略有错误；或者完全正确但枯燥乏味。传统的软件测试有明确的通过/失败标准，而人工智能评估很少能做到这一点。这就是为什么该领域发展出了多种互补的方法：用于广泛能力测量的自动化基准测试、用于质量判断的人工评估、用于可扩展的人类判断近似值的LLM作为评判者，以及用于特定领域的任务特定指标。没有任何一种方法是足够的。评估效果良好的团队会将所有方法分层使用。
像MMLU、HumanEval、MATH和GPQA这样的公开基准测试为模型在明确定义的任务上的比较提供了标准化方式。它们有助于大致了解模型的能力，并跟踪随时间推移的进步。但在依赖它们之前，你需要了解它们的严重局限性。基准测试污染现象十分普遍——训练数据通常包含基准问题，因此高分可能反映的是记忆能力而非实际能力。基准测试饱和意味着一旦大多数前沿模型在测试中得分超过90%，它就不再具有信息价值。而最根本的问题是，基准测试评估的是狭窄且明确的技能，而实际应用需要广泛、混乱且依赖于上下文的推理能力。一个在MMLU中得分92%、在HumanEval中得分87%的模型，可能在你的特定使用案例中仍然表现糟糕——比如编写Symfony控制器、总结法语法律文件，或为你的特定模式生成SQL。基准测试告诉你模型通常能做什么，而你自己的评估则告诉你模型能为你做什么。
你能做的最有价值的评估工作是构建一个特定于你应用的测试套件。首先，收集50到100个你系统将看到的实际输入示例，以及良好输出应该是什么样子。这些可以是实际用户查询、合成的边缘情况，或探测已知失败模式的对抗性输入。对于每个示例，尽可能具体地定义“正确”是什么意思——预期的关键词、必需的结构、必须存在或不存在的事实声明、语气标准。然后自动化评估：将你的提示运行在每个示例上，对输出进行评分（使用精确匹配、正则表达式或LLM作为评判者），并随时间跟踪结果。像Braintrust、Langfuse和Promptfoo这样的工具可以简化这一过程，但你也可以用电子表格和脚本自行构建。关键是拥有一个可重复的过程，这样当你更改提示、更换模型或更新检索管道时，你可以立即看到情况是变好还是变差。
使用一个LLM来评估另一个LLM的输出——“LLM作为评判者”模式——已成为可扩展评估的默认方法。你给一个强大的模型（通常是GPT-4或Claude）原始问题、模型的响应和评分标准，然后要求它根据准确性、有用性和安全性等标准对响应进行评分。这种方法在许多任务中出人意料地有效，尤其是在你提供详细评分标准和校准示例时。但它也有盲点：LLM评判者倾向于偏好更长的响应，可能忽略细微的事实错误，并且在成对比较中表现出位置偏见（偏向于首先出现的响应）。对于质量敏感的应用，人工评估仍然是黄金标准。像Scale AI和Surge这样的服务提供受过训练的标注人员，但即使是非正式的人工审查——让三个团队成员独立评分50个输出——也能发现自动化评估遗漏的失败模式。最稳健的评估流程使用自动化指标作为快速过滤器，LLM作为评判者用于中等置信度的决策，而人工审查用于高风险或模糊的案例。
评估中最困难的部分不是技术性的——而是文化性的。那些推出优秀AI产品的团队将评估视为一流的工程学科，而不是事后考虑。他们像优秀的开发人员在编写代码前编写测试一样，在编写提示前编写评估。他们维护一个不断发展的评估套件，随着在生产中发现新的失败模式而不断扩展。他们抵制为了基准分数而牺牲实际性能的诱惑。如果你的模型在你的评估套件中表现优异，但用户却在抱怨，那说明你的评估是错误的，而不是用户的问题。最好的评估框架是那些能让你诚实地面对系统实际表现的框架，尤其是在系统失败的情况下。