评测不是“看榜单”，而是回答三个问题

当团队准备换模型、改 Prompt、升级 RAG 或引入 Agent 时，最容易犯的错误是打开排行榜，挑一个分数最高的模型，然后直接上线。排行榜能告诉你模型大概处于什么能力区间，却不能回答：它是否理解你的业务规则、在真实用户请求上是否稳定、上线后是否真的提升任务完成率。

一、为什么大模型比传统软件更难评测

传统软件通常有明确输入和唯一输出，测试用例只要验证“结果对不对”。大模型面对的是开放式语言任务，同一个问题可能有多种合格答案，输出还会受 Prompt、上下文、采样参数、模型版本和工具状态影响。

因此，评测不能只看一个数字。一个客服机器人可能事实正确，却语气生硬；一个 RAG 系统可能回答流畅，却引用了无关材料；一个 Agent 可能最后一句话说“已完成”，但数据库状态根本没有改变。

图：大模型应用常见的八类评测维度

二、学术 Benchmark：先看它到底考什么

学术 Benchmark 的价值在于标准化：同一套题、同一评分方式，可以横向比较不同模型。但不同 Benchmark 测的能力完全不同，不能把所有分数混成一个“智商值”。

图：常见大模型 Benchmark 的任务定位

知识与综合推理

MMLU 覆盖 57 个学科，题型以选择题为主，适合观察知识广度和基础推理。MMLU-Pro 提升了难度和选项数量，但它们仍然偏“考试题”，不能代表真实业务中的长文本理解、工具调用和多轮协作。

HELM 的意义不在于再造一套题，而在于强调多维评测：除了准确率，还要同时看校准、鲁棒性、公平性、偏见、有害性和效率。

数学与科学推理

GSM8K 是小学数学应用题，适合测试基础多步推理；MATH 更接近竞赛数学；GPQA 由生物、物理和化学领域专家编写，难度更高。选择这类 Benchmark 时，要特别关注评分是否只看最终答案，还是也验证推理过程和单位、格式。

代码与软件工程

HumanEval 给出函数签名和说明，通过隐藏单元测试验证代码能否运行，常用 Pass@k 表示“生成 k 个候选，至少一个通过测试”的概率。SWE-bench Verified 更接近真实开发：模型需要理解完整仓库、定位 GitHub Issue、修改代码并通过项目测试。

对话、偏好与 Agent

MT-Bench 和 Chatbot Arena 更关注开放式对话与人类偏好。τ-bench 则让 Agent 在业务规则、API 工具和模拟用户之间完成多轮任务，并通过最终数据库状态和 pass^k 衡量可靠性。

动态与高难评测

公开题库一旦长期存在，就容易进入训练数据。LiveBench 通过持续更新题目、使用客观答案降低污染风险；Humanity’s Last Exam 通过高难度、跨学科和保留私有题目，试图继续拉开前沿模型差距。

三、指标怎么选：先看任务是否可验证

指标不是越高级越好。能用程序确定对错的任务，优先使用确定性评分；只有开放式文本质量无法用规则描述时，才需要 LLM 或人工评审。

图：根据任务类型选择评分方式

常见确定性指标

Accuracy：分类或选择题中，预测正确的比例。

Exact Match：输出与标准答案完全一致，适合短答案、字段抽取和格式严格的任务。

Precision：模型判为正例的结果中，真正正确的比例。

Recall：所有真实正例中，被模型找到的比例。

F1：Precision 与 Recall 的调和平均，适合类别不均衡的任务。

Pass@k：代码生成多个候选时，至少一个通过全部测试的概率。

Task Success：Agent 是否真正完成业务目标，而不是只生成“完成了”的文字。

图：类别不均衡时，准确率可能极具误导性

开放式文本指标

摘要、问答、写作和客服回复往往没有唯一答案。BLEU、ROUGE 等词面相似度可快速自动化，但对改写、创意和长答案的语义质量有限。更常见的做法是给出明确 Rubric，让 LLM 或人工分别评估事实性、完整性、相关性、风格和安全性。

四、四种评分方法，应该按什么顺序使用

图：规则、代码、LLM 裁判与人工评审的取舍

OpenAI 的评测流程可以概括为：定义任务与标准，使用代表性测试输入运行评测，分析结果并继续迭代。Anthropic 的建议同样强调：成功标准必须具体、可测量、与真实任务相关，并优先使用最快、最可靠、可扩展的评分方式。

五、Benchmark 的系统性局限：数据污染与饱和

大模型训练数据规模巨大，而公开 Benchmark 的题目、答案、解析和讨论经常出现在网页、论文、代码仓库中。模型在预训练时可能已经见过这些内容，测试成绩因此被抬高。

图：公开 Benchmark 从发布到失真的典型路径

数据污染不一定是故意作弊，但结果一样：排行榜分数可能不再代表真实泛化。应对方向包括动态更新题库、按时间切分数据、保留私有测试集、使用真实业务样本，以及避免将评测题直接用于训练或 Prompt 优化。

六、真正决定项目效果的是业务黄金测试集

业务测试集应该来自真实用户请求，而不是由开发者凭空想象。一个实用的起点可以是 100-300 条高代表性样本：数量不必巨大，但要覆盖高频主路径、关键长尾、边界条件和高风险场景。

图：业务黄金测试集的构建流程

一条测试样本应该包含什么

输入：用户问题、上下文、历史对话和可用工具。

期望结果：标准答案，或必须包含的关键事实和动作。

禁止项：不能编造、不能越权、不能泄露的内容。

评分规则：通过条件、部分得分和错误标签。

切片标签：场景、难度、语言、用户类型、风险等级。

版本信息：数据来源时间、标注人、修改原因和适用模型。

七、LLM-as-Judge：可扩展，但必须校准

LLM-as-Judge 的优势是便宜、快速、可以理解语义，适合摘要、客服、问答和写作等开放式任务。研究表明，强模型裁判与人类偏好可以达到较高一致度，但同样存在位置偏差、冗长偏差、自偏好和“把流畅当正确”等问题。

图：LLM 裁判的常见偏差与校准方法

一个可执行的评分 Rubric

你是质量评审员。请只根据给定资料评分，不允许补充外部常识。
评分维度：
- 事实正确性：0-4 分
- 信息完整性：0-3 分
- 是否直接回答问题：0-2 分
- 格式是否满足要求：0-1 分
严重错误：出现资料无法支持的关键事实，总分不得超过 4 分。
输出 JSON：{"score": 0-10, "errors": ["错误标签"], "reason": "简短理由"}

评审 Prompt 要尽量把“好不好”拆成可观察标准。对于成对比较，交换答案顺序再评一次；对于高风险任务，使用多个裁判投票并抽样人工复核。

八、RAG 评测：不要只给最终答案打一个总分

RAG 是“检索 + 生成”的组合系统。检索没找到正确资料、召回了大量噪声、模型忽略上下文、引用位置错误，都会导致最终答案失败。只有拆分指标，才能知道该优化向量检索、重排、Prompt 还是生成模型。

图：RAG 的检索、生成和引用指标

Context Recall：参考答案需要的证据是否被检索到。

Context Precision：检索结果里真正有用的内容比例。

Faithfulness：回答中的陈述是否都能被上下文支持。

Answer Relevance：回答是否围绕用户问题，而不是复述材料。

Citation Accuracy：引用是否准确指向支持该结论的证据。

九、Agent 评测：看最终状态，也看执行轨迹

Agent 的输出不只是文本，而是一系列动作。一个机票 Agent 可能语言礼貌，却选错航班；一个客服 Agent 可能正确调用退款工具，却违反了“必须二次确认”的业务规则。因此，Agent 评测要同时覆盖目标完成、工具选择、参数、规则合规、状态更新和多次运行稳定性。

图：Agent 的轨迹评测和核心指标

τ-bench 使用最终数据库状态判断任务是否完成，并用 pass^k 衡量多次重复执行的可靠性。这比只看单次成功率更接近真实生产：用户需要的是每次都能完成，而不是偶尔成功。

十、离线评测与线上指标如何闭环

离线评测适合快速对比模型、Prompt 和检索策略，能够稳定复现问题；线上指标则反映真实用户、真实流量和真实成本。只做离线，容易优化到测试集；只看线上，定位问题又太慢。

图：离线回归、灰度发布和线上样本回流

常见线上指标

任务完成率：用户是否真正达到目标，是最重要的业务指标。

满意度：点赞、点踩、评分或客服转人工原因。

追问率：用户是否因为回答不完整而反复追问。

会话放弃率：用户是否中途退出或改用其他渠道。

延迟：TTFT、P50、P95、P99，以及工具链整体耗时。

成本：输入/输出 Token、检索、工具、重试和人工兜底成本。

安全事件：越权、隐私泄露、错误操作和高风险回答。

十一、模型选型要做多目标权衡

“最强模型”不一定是最适合的模型。生产环境通常需要先设置硬门槛，例如安全违规为零、关键场景通过率不低于某值、P95 延迟不超过预算；通过门槛后，再比较质量、成本和稳定性的综合得分。

图：模型选型的多维 Scorecard

十二、把评测变成发布门禁，而不是临时报告

评测的最终价值不是做一份 PPT，而是阻止质量回归。任何模型版本、Prompt、知识库、重排器、工具 Schema 或业务规则变化，都应该触发同一套回归测试。

图：从提交变更到灰度发布的评测门禁

回归报告至少要展示：总体分数、关键业务切片、与基线的差值、失败样本、延迟和成本。平均分上涨但高风险切片下降，依然不能发布。

十三、面试和项目中怎么简洁回答

上线前检查清单

是否明确了业务成功标准，而不是只有“回答看起来不错”？

测试集是否来自真实流量，并覆盖边界和高风险场景？

评分方式是否优先选择确定性规则或执行结果？

LLM 裁判是否做过顺序交换、一致率和人工抽查？

是否按业务切片查看结果，而不是只看平均分？

RAG 和 Agent 是否拆分了各环节指标？

是否同时监控质量、延迟、成本、稳定性和安全？

是否设置发布门槛、灰度策略和一键回滚？

线上失败样本是否定期回流到私有测试集？