引子

前一段时间，OpenAI 研究员姚顺雨在一篇广受关注的文章《The Second Half》中提出：

“I think we should fundamentally re-think evaluation. It means not just to create new and harder benchmarks, but to fundamentally question existing evaluation setups and create new ones, so that we are forced to invent new methods beyond the working recipe.”

指出，AI 发展的“下半场”已经到来，而其中一个核心议题，就是对 evaluation的重新思考。我们需要的不再是单纯地创造更难的 benchmark，然后在这些 benchmark 上“刷分”，而是要更加关注评测的实用性、创新性，以及其与真实世界的契合度。

过去，我们往往过于关注模型本身、训练方法以及各种fancy的技术手段，却忽略了模型与真实世界的交互和落地应用。而 evaluation，正是连接模型能力与实际需求的关键环节。

本文最初的出发点，是梳理 Hugging Face Evaluation 系列文章中的一些要点。需要说明的是，HF 的文章主要聚焦于如何评测LLM的能力，考虑到其成文的时间，其中部分内容在当前 LLM 能力飞速提升的背景下，显得有些滞后。但这也为我们提供了一个契机，从后来者的视角重新思考 evaluation 的意义，并尝试将这些理念应用到更加复杂和多样化的 AI 系统中，如RAG和AI-agent。

在机器学习和深度学习的流程中，Evaluation是衡量模型性能的核心环节。它贯穿于模型开发的始终：从训练阶段的实时监控，到上线前的最终验证，再到部署后的持续追踪。

简单来说，评估的目标是回答两个问题：

  1. 模型是否有效？（性能指标）

  2. 模型是否可靠？（鲁棒性、泛化能力）

以经典的猫狗分类任务为例，在训练前，我们可能将数据集划分为trainingset，evalset，和testset （经典的7:2:1）保证训练数据与测试数据无重叠；对于分类问题，可能选择Accuracy、Precision和Recall 作为metrics，在训练过程中监控模型在evalset上的情况（是否存在overfitting之类的问题）；训练结束后，在testset上验证模型的最终性能，判断是否达到预期目标。

那么，这套流程中，也存在一定的局限性：

训练数据与真实场景的数据可能存在显著差异，数据分布也有不同。例如，训练集中仅包含清晰的猫狗照片，而真实场景中可能包含模糊图像、多动物混合图像，甚至完全无关的干扰样本。

单一指标（如Accuracy）可能无法全面反映模型的实际能力。在一些高风险场景下，如医疗诊断中， 对于漏诊和误诊的权衡，影响着对于Recall和Precision的关注。

模型上线后，如何持续监控其性能？如何应对数据漂移（Data Drift）？传统评估通常基于固定测试集，但现实世界的数据是动态变化的。

同时，面对愈加复杂的模型和场景，传统评估方法已难以满足复杂场景的需求：面对不同于判别模型（Discriminative model），生成式模型（generative model）的评价明显更难，不存在在统一标准的metrics，同时也带来了更多维度的评价方向。当然，还有成本的提升。

Human Evaluation

人类对复杂语义的理解能力与价值判断力，这让Human Evaluation 始终占据不可替代的地位。但这意味着高昂的成本。

系统化的Human Evaluation，根据评估资源完备性，可分为：

  • 当缺乏现成数据集时，需提供完整的任务说明与结构化评分指南。例如在对话系统评估中，需明确定义"连贯性"、“相关性”、“安全性"等维度的评分标准，并要求标注员提供评分理由。

  • 已有数据集，将模型输入，输出结果，和打分指南一并提供给标注员评估

  • 既有数据集也有评分结果，由人工标注员通过错误注释的方式对结果进行审查

  • 对于已上线的服务， 采用人工 A/B test 以及人工反馈

  • 备注：错误注释（error annotation）

    Lets use error annotations to evaluate systems!

    让有领域知识的专家对生成文本中的错误进行标注（annotation），通常会给每个错误分配一个类别（如准确性、流畅性等），有时还会标注严重程度。这种方法介于任务型评估和打分/排序之间，结果比打分更有意义，但比任务型评估更便宜、更易操作。

在研发初期或资源受限场景下，可采用以下轻量级方案：

  • Vibes 检查： 大致的手动的评估，用于把握整体效果，但较为主观

  • Arenas：竞技场模式（如 Chatbot Arena），由用户进行投票评分，最终汇总得到Elo分数

一些技巧和要点：

  • 选择合适的标注员，如果可能的话提供经济激励

  • 认知负担最小化，将标注员的认知负担降低到最低有助于确保他们保持专注，避免引入不必要信息

  • 测试检查，并迭代：先确保在少量样本上测试通过，在扩大标注范围

  • 明确的标注准则和说明

标注工具：

Automatic benchmarks

基本概念

定义：Automatic Benchmarks是用来评估语言模型在不同任务和能力上的标准化工具。

其本质是构建一个可重复、可验证的实验环境，使不同模型、算法或超参数组合能够在统一维度下进行横向对比。

为什么需要Automatic benchmarks：

在研发过程中，往往需要快速确定优化方向，如如何选择模型， 如何选择和修改超参数，这一过程中需要大量的实验，使用人进行标注和评分显然非常不现实——过长的评估周期且人工评估的主观差异会成为干扰项，于此同时还不具备可复现性。

这时候我们便需要Automatic Benchmarks：自动化的、标准化、可复现、可量化的评估测试。

值得注意的是，尽管Automatic Benchmarks为模型研发提供了重要参考，但需明确其定位——它只是全面评估体系的基础。基准测试的优异表现并不能等同于实际应用效果，因为其只是尽可能模仿实际情况设计的。

对于Automatic Benchmarks，其核心有两点：数据集和评估指标。

如何构建数据集

数据集的具体形式应根据下游任务的需求进行设计。以评估大语言模型（LLM）的基础能力为例，数据集通常包含多个样本，每个样本包括模型的输入，有时还会配有参考答案（即“gold”），用于与模型输出进行对比。数据集应尽量模拟实际测试场景，样本数量不必过多，但要确保能够覆盖绝大多数常见情况以及一些极端情况。可以将数据集理解为代码的单元测试用例，重点在于覆盖面而非数量。

如果采用现成的数据集，建议通过随机抽取一定数量的样本（如50个）进行人工检查，评估其质量和任务相关性。同时，数据集的整体质量不仅与标注人员的专业水平密切相关，也与原始语料的来源有关。例如，学术论文的数据质量通常高于网络爬虫获取的数据。对于合成数据集，建议优先使用能力更强、更新的模型和数据集进行生成。

当不存在可直接使用的数据集时，需要根据具体场景自行设计数据集。常见的数据集构建方法包括：整合不同数据源的数据、人工标注以及基于LLM或规则的方法进行数据合成。

在构建数据集时，还需注意数据污染（Data contamination）等问题。此外，对于较为复杂且难以拆分为明确子任务的任务，模型的表现可能会低于预期，因此在设计数据集时应充分考虑任务的复杂性和可操作性。

如何选择指标

指标选择本质上是将业务目标转化为可量化问题的建模过程。不同任务类型需要匹配差异化的评估指标。

如分类任务中 Accuracy 之类的基础指标常见，但在医疗诊断等类别不平衡场景中易产生误导，这类场景可能对于Recall额外关注，需要根据场景选择合适指标，如F1-Score， MCC（Matthews Correlation Coefficient），或是配合ROC曲线。

如果是具体的任务执行，或者是存在标准答案的，如数学问题，推理问题，这些评估还是较为好做的， 如Pass@K指标衡量在K次采样中至少一次成功。

相比之下， LLM生成回答的评估有一定挑战。Exact Match（EM）适用于数学证明等严格答案场景，但对开放域问答存在局限性；n-gram匹配，如BLEU、ROUGE关注词汇重叠度，但忽略了语义上的关系；采用embedding方式计算相似度，如BERTScore，但额外增加了新的因素，并且语义相似度不是一个决定数值而是相对值，比较上需要注意；Perplexity能够一定程度上反应LLM对于输出的不确定性，但也不是特别好用；这一类型tasks评估一般采取LLM-as-judge进行评估。

不过随着模型能力增强，评估准确性不在是唯一的方向，也需要逐渐将安全性，可信度等纳入考虑范围。由于LLM存在一定的幻觉，Vectara 所采用的Hallucinations测量方式值得参考；

评估时需要关注的点

  • prompt选择对结果有影响：一个合理的 prompt 通常应包含以下要素：任务描述：明确告诉模型需要完成什么任务，避免歧义；足够的上下文：为模型提供必要的背景信息，帮助其更好地理解问题；具体问题：清晰、具体地提出待解决的问题，减少模型的猜测空间。

  • 多次实验以减少误差：不同的 prompt 设计可能导致模型输出质量和风格的巨大差异，可以针对同一任务，设计多种不同风格或结构的 prompt，分别进行多轮测试；或在相同 prompt 下，调整模型的 temperature多次实验；

  • Structure-output ：结构化输出有助于提高评测的可控性，减少模型生成无关内容。但可能会影响模型输出的概率分布。

Model-as-a-Judge

基本概念

Model-as-a-Judge 是指利用LLM或专门训练的评估模型，对其他模型的输出进行自动化打分和评价。与传统的人工评测或基于规则的自动指标不同，Judge Model 本质上是一个“打分模型”，能够理解复杂的语言现象，并根据预设标准对生成内容进行多维度评估。

Judge Model 被主要应用在以下几个常见场景中：

  • 生成文本打分：直接对模型生成的文本进行质量、流畅性、相关性等方面的评分

  • 成对比较：给定两段或多段文本，Judge Model 判断哪一段更符合要求

  • 文本相似度计算：评估生成文本与参考答案之间的语义相似度

  • （更多）

相比大规模人工标注，Judge Model 能够大幅降低评测成本，提升评测效率，尤其适合需要频繁迭代和大规模评测的场景。

不过需要注意的：

  • Judge Model 可能继承或放大训练数据中的偏见，且这些偏差往往难以被直接发现和纠正

  • 在特定专业领域（如医学、法律等），Judge Model 的评测能力可能不足，难以准确把握专业知识和细节

  • 不同 Judge Model 之间的评判标准可能不一致，评测结果的可复现性公信力仅供参考

随着大语言模型能力的不断提升，Judge Model 的应用范围也在持续扩展。未来，Judge Model 有望胜任更复杂的评测任务。

prompt设计

prompt设计原则

  • 任务描述清晰

  • 评估标准精细，评分细则详细 （You should evaluate property Z on a scale of 1 - 5, where 1 means ...）

  • 加入一些“推理”过程 (To judge this task, you must first make sure to read sample Y carefully to identify ..., then ...)

  • 对输出格式明确要求 (Your answer should be provided in JSON, with the following format {"Score": Your score, "Reasoning": The reasoning which led you to this score})

一些技巧：

  • 成对比较比直接输出评分，效果更好更robust

  • 输出分数建议使用整数，并解释每个分值的代表含义

  • 针对单一能力设计专用 Prompt

提升评估准确性的方法：

  • few-shot example

  • 引用参考

  • CoT

  • 多轮分析

  • 多个模型结果汇总（多个模型，或者一个模型采用不同温度进行多次实验）

补充：

社会学中的问卷设计原则

问卷设计通常遵循以下原则：

  1. 中立性原则：避免引导性问题，不预设立场或暗示"正确"答案

  2. 语言包容性：使用无歧视、包容各群体的词汇和表述方式

  3. 平衡表达：确保问题和选项呈现多元观点，不偏向某一立场

  4. 结构清晰：问题逻辑清晰，避免复杂或模糊的表述

  5. 避免刻板印象：警惕并消除可能反映社会刻板印象的措辞

  6. 考虑多样性：设计时考虑到不同文化背景、性别、年龄等群体的差异

LLM选择和注意项

可以直接使用LLM，也可以使用经过偏好数据集微调后的评估模型如：

也可根据自己的场景收集偏好数据，自行微调评估模型，数据集格式可以参考：

  • prometheus-eval/Preference-Collection

  • prometheus-eval/Feedback-Collection

Judge LLM的使用注意项

  • LLM存在幻觉， 并且很难识别幻觉（特别是部分正确少部分错误的内容），还是需要一定的人工检查

  • 缺乏一致性（相同条件下得出结果有差异）：使用self-consisitency prompt， 执行多次并保留占多数的结果

  • LLM对于输出格式存在便好：汇总多个模型的结果

  • 位置偏差，模型可能便好靠前的位置的答案：随机调整顺序

  • 模型偏好冗长的回答

  • 格式偏差：输入模型的 prompt 格式与其训练数据的格式差异过大，可能导致模型的评估结果不准确

Reward Model

Reward Model（奖励模型）是一类能够根据偏好预测输出好坏分数的模型，广泛应用于如 RLHF等场景。本质上，RM可以理解成Judge-model 的一种特殊形式，针对成对的输出，或单一的输入，直接给出评价分数；

最常见的奖励模型是 Bradley-Terry 模型，其核心思想是通过比较两个答案的得分差异，利用如下公式计算偏好概率：

$$ P(b \ is \ better \ than \ a) = \text{sigmoid}(score_b - score_a) $$

Reward Model 的训练数据通常只需要成对比较的答案，这比直接收集绝对分数更为容易和高效。在实际评估中，Reward Model 输出的往往是相对分数，因此常用 win-rate（即模型回答优于参考答案的百分比）或 win probabilities 作为评估指标。

RM 的选择可以参考：RewardBench Leaderboard

小结

本文主要讨论了LLM（或LLM应用）的离线评估；

从一个更大的角度，更overall 的framework来看，LLM评估可以从评测方式（LLM评审、代码评估、人工标注等）和实施阶段（离线、在线、护栏）两维度分类，每种方式/场景都需权衡任务目标、工程成本与准确性；

从评测方式， 目前主流方式是 LLM as a Judge，通常用于“参考文献-开放问答”类场景，让LLM判断答案是否基于参考文献，是否正确/完整，适用于缺乏人为标注数据或用户反馈时，能大规模自动化评测；关键难题：如何确保“评委LLM”的可靠性；适合主观性较强的评测如内容相关性、事实性；对于存在标准答案的场景，一般采用Code-Based Evaluations，适用于结果有“硬规则”或定量标准的任务，如代码生成、JSON结构、关键字段verify等；当然，也不可忽略其他辅助方法，如人工标注和用户实时反馈；

从实践阶段，对于一个LLM应用而言，评估可分为：

离线评测，上线/开发阶段，使用收集或合成的数据集（golden数据集）进行评测，用于prompt/模型版本/检索策略变化的回归测试和benchmark，通常嵌入CI/CD流程

在线评测，系统上线生产后，对真实用户数据实时打分、监测（但一般不拦截输出，仅报告问题），更关注模型的稳定性、性能等在现实环境下的轨迹，及时发现线上退化、幻觉、响应异常或敏感内容

Guardrails，实时、线上启用，发现风险（幻觉、违规、毒性等）即拦截或修正输出，优先级高于普通的在线评测

最后聊聊评估。

对于ML/DL算法工程师来说，评估这套流程大家都很熟。但未来最大的不同是，我们将进入一个普遍使用LLM进行评估的时代。这意味着，能被评估的东西会比过去多得多、广得多。以前必须靠人来评判的内容，会逐渐转向“LLM-judge”模式。简单说，只要你能用语言（Prompt）把评估标准描述清楚，那它就是可评估的。 当然，这也意味着写好、优化好Prompt会变得极其重要。

对于开发者，评估这事儿本质上和软件测试很像。它们的目标都是提供一套覆盖足够广的测试用例（也就是“Golden Test Set”），确保你的程序（LLM应用）能顺利通过。一句话，如果测试对你很重要，那么评估也一样重要。