Agent 速成笔记 · 第 12 章 智能体性能评估
Agent 速成笔记 · 第 12 章 智能体性能评估
源：Datawhale《Hello-Agents》第 12 章 ｜ 定位：工程实现 + 评估方法论 ｜ 一句话：给智能体装上一把可量化的尺子——用数据集、指标和评估流程回答"它到底行不行、改了之后有没有变好"。
0. 一章速览（30 秒）
- 一句话：智能体评估 = 数据集（Dataset）+ 评估器（Evaluator）+ 指标（Metrics） 三层结构；先用一条确定性的比对算法把"智能体输出"和"标准答案"变成 0/1 判定，再按样本聚合成可比较的分数。
- 本章解决什么问题：优化提示词、换模型、加工具之后，凭什么说"确实变好了"？靠人眼看几个例子不算，必须有一套可复现、可对比、与公开排行榜口径一致的评估流程。
- 必须记住的 5 个点：
- 评估的本质是"判定算法 + 聚合方式"：BFCL 用 AST 匹配判函数调用是否等价，GAIA 用准精确匹配（先归一化再精确比对）判答案是否等价，二者哲学不同。
- 指标要分清"绝对分"和"相对分"：LLM Judge 给绝对评分，Win Rate 做成对相对比较，人工验证做最终把关。
- 评估不是只算一个准确率：还要看分类准确率 / 加权准确率 / 难度递进下降率 / 平均推理步骤数，这些才暴露能力边界。
- 评估有成本：一次完整评估可能产生大量 API 调用，费用可达数百元量级，因此要分层、渐进、先小样本地评估。
- 想上公开榜单，必须用官方算法与官方格式，自研指标再漂亮也不能跨系统比较。
1. 智能体评估基础（对应原文 12.1）
1.1 为什么必须评估
- 是什么：用标准化的方法为智能体能力产出具体数字，使不同设计之间可以客观比较。
- 为什么重要（四个价值）：① 量化表现，把"感觉不错"变成"准确率 0.82"；② 客观比较不同设计方案（换提示词、换 LLM、换工具库）；③ 及时发现智能体在特定场景下的弱点；④ 向用户证明可靠性——上生产前的必要动作。
- 工程要点：评估要能回答三个问题——智能体是否具备预期能力、在不同任务上表现如何、与其他智能体相比处于什么水平。任何一次"优化"如果没有对应的评估数字，就不能称为优化。
1.2 与传统软件测试的三点不同（三大挑战）
| 挑战 | 具体表现 | 直接后果 |
|---|---|---|
| 输出不确定性 | 同一问题可能有多个正确答案，很难简单判对错 | 不能用 assertEqual 式断言 |
| 评估标准多样性 | 工具调用要查函数签名，问答要评语义相似度 | 每个任务类型都要自带一套判定算法 |
| 评估成本高昂 | 每次评估需大量 API 调用，成本可达数百元甚至更多 | 必须控制样本量、分层评估 |
工程结论：正因如此，才需要标准化基准（Benchmark）——统一数据集、统一指标、统一评分方法，让不同系统在同一把尺子下对比。
1.3 主流评估基准地图
按"考什么能力"分三类：
| 类别 | 基准 | 出品方 | 规模 / 特点 |
|---|---|---|---|
| 工具调用 | BFCL | UC Berkeley | 1120+ 样本，四类别，AST 匹配 |
| 工具调用 | ToolBench | 清华大学 | 16000+ 真实 API 调用场景 |
| 工具调用 | API-Bank | Microsoft Research | 53 个常用 API，考文档理解 |
| 通用能力 | GAIA | Meta AI + Hugging Face | 466 个真实问题，Level 1/2/3 |
| 通用能力 | AgentBench | 清华大学 | 8 个不同领域任务 |
| 通用能力 | WebArena | CMU | 真实网页环境中的任务完成 |
| 多智能体 | ChatEval / SOTOPIA | 学术团队 | 多智能体对话质量 / 社交互动 |
- 怎么记忆：BFCL 考"手"（会不会正确调函数），GAIA 考"脑 + 手 + 眼"（多步推理 + 工具 + 文件/网页），ChatEval & SOTOPIA 考"社交协作"。
- 选型线索：评估函数调用准确性选 BFCL；评估综合问题解决能力选 GAIA；评估多智能体协作选 ChatEval / SOTOPIA 或自建协作场景。
1.4 四类常用评估指标
| 指标类别 | 代表指标 | 衡量什么 |
|---|---|---|
| 准确性 | Accuracy、Exact Match、F1 Score | 答案/调用是否正确 |
| 效率 | Response Time、Token Usage | 执行得多快多贵 |
| 鲁棒性 | Error Rate、Failure Recovery | 容错与故障恢复能力 |
| 协作 | Communication Efficiency、Task Completion | 多体协作效果 |
- 任务完成类指标的本章口径：BFCL 的 Accuracy、GAIA 的 Exact Match Rate、数据生成评估的 Pass Rate（≥3.5 分占比）都属于"完成/正确比例"这一族，统一形式为正确样本数 ÷ 总样本数。
- 易混点：本章的"成功率"全部是单次采样的正确率口径；像 pass@k 这类"同一题采样 k 次取最好一次"的多次采样指标，本章并未使用，不要混进同一张表里比大小。
- 成本指标的本章口径：效率类只给了 Response Time 与 Token Usage 两个可采集量，费用是它们的间接结果，原文仅给出定性量级（百元级），没有成本公式。
1.5 本章的三层评估体系
本章用三个场景把评估能力讲全，正好覆盖"工具调用 / 通用能力 / 生成数据质量"三条主线：
- BFCL → 评估工具调用能力（函数调用准确性）。选择理由：数据集规模适中、指标清晰、社区活跃。
- GAIA → 评估通用 AI 助手能力（综合问题解决）。选择理由：任务真实、有难度分级、综合性强。
- 数据生成质量评估 → 评估 LLM 生成数据的质量，方法为 LLM Judge + Win Rate + 人工验证。
实现架构（贯穿全章的统一套路）：所有基准都拆成三个组件 + 一层封装：
- 数据层
Dataset：负责加载/管理数据（如BFCLDataset、GAIADataset、AIDataset）； - 评估层
Evaluator：负责跑流程（构造提示词 → 调用 Agent → 提取结果 → 与标准答案比对）； - 指标层
Metrics：负责算分（准确率、分类准确率、F1 等）； - 工具层
Tool：把整套流程封装成框架内可调用的工具，供 Agent 直接调用或集成进工作流。
记住这个"Dataset / Evaluator / Metrics → Tool"的四件套，后面扩展任何新基准都是换皮不换骨。
2. BFCL：工具调用能力评估（对应原文 12.2）
2.1 定位与四个类别
- 是什么：加州大学伯克利分校推出的函数调用能力评估基准，考的是智能体完成四件事的能力：理解任务需求（从自然语言提关键信息）、选择合适工具（从可用工具集里挑）、构造函数调用（正确填函数名与参数）、处理复杂场景（多函数、并行调用）。
- 四个类别（难度递增）：
| 类别 | 考察点 | 典型难点 |
|---|---|---|
| Simple | 单函数调用 | 参数抽取准确 |
| Multiple | 需要调用多个函数 | 规划调用序列 |
| Parallel | 并行调用多个函数 | 识别可并行性 |
| Irrelevance | 判断"是否需要调用函数" | 不该调时别乱调 |
易错点：irrelevance 常被忽视，但它恰恰考"过度调用"——智能体看到工具就想用，是生产环境最常见的坏习惯。
2.2 数据集结构
每个测试样本是一条 JSON，关键字段三组：
question：用户自然语言请求；function：可用函数列表，含name/description/parameters（JSON Schema 风格，含required）；ground_truth：期望的函数调用，形如[{"name": ..., "arguments": {...}}]。
工程要点：ground_truth 是判定基准，因此从官方仓库克隆获取完整 ground truth 是首选方式（位于 bfcl_eval/data/ 与 bfcl_eval/data/possible_answer/），本地找不到时才回退到 Hugging Face 加载。单个类别（如 simple_python）样本量为 400。
2.3 评估流程（六步）
加载数据集并选择类别 → 运行智能体得到预测 → 将预测解析为抽象语法树（AST） → 用 AST 匹配算法判定对错 → 遍历全部样本 → 计算准确率等指标并生成报告。
2.4 AST 匹配：BFCL 的核心判定算法
是什么：把函数调用解析成语法树，比较树的结构与节点值，而不是比较字符串。
判定函数定义：
AST_Match(P, G) = 1 若 AST(P) ≡ AST(G)
0 其他情况
其中 AST(x) 表示把函数调用 x 解析为抽象语法树，≡ 表示语法树等价。
两个语法树等价需同时满足三个条件：
- 函数名精确匹配（字符串完全一致，
get_weather与get_temperature视为不同函数）； - 参数键值对集合相等（忽略顺序）；
- 每个参数的值语义等价（例如
2+3等价于5）。
| 情形 | 预测 vs 标准 | 结果 |
|---|---|---|
| 参数顺序不同 | get_weather(city=..., unit=...) 顺序颠倒 |
匹配成功 |
| 等价表达式 | calculate(x=2+3) vs calculate(x=5) |
匹配成功 |
| 引号风格不同 | f(s="hello") vs f(s='hello') |
匹配成功 |
| 函数名错误 | get_temperature(...) vs get_weather(...) |
匹配失败 |
| 参数值错误 | city="Shanghai" vs city="Beijing" |
匹配失败 |
- 多函数调用的匹配规则：函数数量相同、每个都必须匹配、调用顺序可以不同（集合匹配）。
- 为什么不能用字符串匹配：字符串匹配会把"顺序不同""等价表达式""引号差异"全判错，造成大量假阴性。
- 易错点（假阳性/假阴性来源）：AST 只做语法树结构等价，不理解语义——
sqrt(16)与4结构不同会被判错；反之若两个不同函数被解析成相同结构，也可能被误判为等价。所以 AST 匹配是"比字符串聪明、比语义等价保守"的中间方案。
2.5 BFCL 指标公式
| 指标 | 定义 |
|---|---|
| 准确率 Accuracy | 1/N · Σ AST_Match(Pᵢ, Gᵢ)，即 AST 匹配成功的样本比例 |
| AST 匹配率 | 与 Accuracy 数值相同，强调使用 AST 匹配算法 |
| 分类准确率 | `1/ |
| 加权准确率 | Σ_c w_c · Accuracy_c，权重满足 Σ_c w_c = 1 |
| 错误率 | 1 - Accuracy |
怎么读这些数：Accuracy = 1.0 表示全对，0.8 表示 80% 正确，0.0 表示全错。分类准确率的用途是定位薄弱环节——例如 simple 0.95、multiple 0.82、parallel 0.68，说明瓶颈在"多函数/并行调用"这一档。加权准确率则用于"不同类别重要性不同"时的综合打分。
指标层还会额外算：parameter_accuracy（参数正确率）、f1_score、category_statistics（分类统计）——参数级指标能区分"函数选对了但参数填错"这类失败。
2.6 三种使用方式怎么选
| 方式 | 适用场景 | 特点 |
|---|---|---|
| 一键评估工具 | 快速了解表现 | 一行调用完成评估 + 导出 + 官方评估 + 报告 |
| 命令行脚本 | 批量评估、集成 CI/CD | 可脚本化，支持类别/样本数/模型名参数 |
| Dataset + Evaluator | 深度定制、集成进自有系统 | 灵活性最大，可自控流程与导出 |
- 一键工具的关键行为：默认自动集成 BFCL 官方评估工具（
run_official_eval=True），会依次执行"跑本地评估 → 导出 BFCL 官方 JSONL 格式 → 复制到result/{model_name}/→ 调用bfcl evaluate --model ... --test-category ... --partial-eval→ 汇总并生成 Markdown 报告"。想手动控制流程就关掉它，再自行调用官方命令。 - 为什么一定要接官方工具：官方评估使用官方 AST 匹配实现，结果与排行榜完全一致、支持 BFCL v4 全部类别，并能自动生成详细报告。自研指标分数没有横向可比性。
- 评估器三个实现要点：① 提示词构造——把问题与函数定义转成智能体能懂的提示；② 函数调用提取——需同时支持 JSON 格式、代码块格式、纯文本格式 三种响应形态，否则会被格式差异污染分数；③ AST 匹配——用语法树对比替代字符串对比。
2.7 提升分数的方向与评估策略
当前实现的局限：HelloAgents 的 SimpleAgent 使用自定义调用格式 [TOOL_CALL:tool_name:parameters]，需要 LLM 主动学会并遵守，在复杂场景下通常不如原生函数调用（Function Calling）的模型；且只覆盖了 simple_python 等基础类别。
三个提升方向：① 换用支持原生 Function Calling 的模型，或改进提示词让模型更好地守格式；② 扩展工具库，按数据集特点预置常用工具类型以提高覆盖率；③ 针对难度分级分别设计策略（multiple 考序列规划、parallel 考并行识别、irrelevance 考"该不该调"）。
三条评估实践策略（可复用）：
- 渐进式评估：先跑 5 个样本，超过阈值（如 0.8）再跑 50 个，再全量——避免在明显不合格的配置上烧钱。
- 多类别评估：固定样本数遍历
simple_python / multiple / parallel / irrelevance，得到能力剖面而非单点分数。 - 对比评估：同一类别、同样本数下跑"默认配置 vs 优化配置"两组 Agent，用数字对比说话——这就是离线版的 A/B 对照。（线上灰度发布、真实流量分流的 A/B 评估，本章未展开。）
3. GAIA：通用 AI 助手能力评估（对应原文 12.3）
3.1 定位与数据集
- 是什么：Meta AI 与 Hugging Face 联合推出的基准，考的是真实世界任务综合表现，而非单一工具调用。
- 设计理念：真实世界的问题往往需要多种能力的综合运用——多步推理（拆解子问题）、知识运用（内置知识 + 外部知识库）、多模态理解（文本/图片/文件）、网页浏览（获取最新信息）、文件操作（读取处理各种格式）。
- 规模与分级：共 466 个真实世界问题，按复杂度和所需推理步骤分 Level 1 / 2 / 3 三个难度级别。官方验证集（validation）共 165 题，级别分布为 Level 1: 53 题、Level 2: 62 题、Level 3: 50 题，附件资源合计 114 个文件；测试集（test）301 题。
- 数据集字段：
Question（问题）、Level（难度 1-3）、Final answer（标准答案，可为数字/文本/文件）、file_name/file_path（附件）、Annotator Metadata（标注者元数据）。 - 标注方法（本章最有价值的"数据集构造"知识点）：
Annotator Metadata由人工标注者填写，包含Steps（解题步骤列表，如"搜索加州人口最多的城市 → 取前三城人口 → 求和"）、Number of steps（步骤数）、How long did this take?（耗时）、Tools（所需工具，如web_search、calculator）。这套元数据既是难度定级的依据，也是"标准解法轨迹"的黄金参照——它把"答对"和"怎么答对"分开记录。 - 获取方式：GAIA 是受限数据集（Gated Dataset），需先在 Hugging Face 页面申请访问权限并配置
HF_TOKEN；首次运行会snapshot_download整仓下载并缓存到本地，之后直接读本地。
3.2 准精确匹配（Quasi Exact Match）
是什么：GAIA 官方定义的评估算法，核心思想是先对答案做归一化处理，再做精确匹配。
判定函数定义：
Quasi_Exact_Match(A_pred, A_true) = 1 若 N(A_pred) = N(A_true)
0 其他情况
其中 N(·) 是归一化函数，根据答案类型应用不同规则：
| 答案类型 | 归一化规则 | 示例 |
|---|---|---|
| 数字 | 去逗号分隔符、去单位符号 | "$1,234.56" → "1234.56"；50% → 50 |
| 字符串 | 转小写、去冠词、去多余空格、去末尾标点 | "The United States" → "united states" |
| 列表 | 按逗号拆分、逐元素归一化、按字母序排序后重连 | "Paris, London, Berlin" → "berlin,london,paris" |
- 为什么这样设计：答案形态多样（
$1,000与1000、The United States与united states、乱序列表），不归一化就会把"实际正确"判成错。归一化把表层差异抹平，只留语义骨架。 - 易错点：列表必须按字母序排序后再比对，因为这正是 GAIA 官方要求——判断逻辑是"集合相等"而不是"顺序相等"。
- 局限：归一化只能处理格式差异，处理不了真正的语义等价（如同义表述、不同数字写法），且完全依赖答案能不能被规则归类。
3.3 GAIA 指标公式
| 指标 | 定义 |
|---|---|
| 精确匹配率 | 1/N · Σ Quasi_Exact_Match(A_pred,i, A_true,i) |
| 分级准确率 | `1/ |
| 难度递进下降率 | Drop Rate_{ℓ→ℓ+1} = (Accuracy_ℓ - Accuracy_{ℓ+1}) / Accuracy_ℓ |
| 平均推理步骤数 | 1/N_correct · Σ_{i∈Correct} steps_i（只统计答对的样本） |
怎么读：
- Drop Rate = 0.3 表示难度上升一级导致准确率下降 30%；= 0.0 是理想情况（难度不影响准确率）。下降率越大，说明能力衰减越明显。
- 平均推理步骤数衡量的是过程效率——答对的前提下用了多少步，是本章中最接近"轨迹质量"的量化指标。
- 典型读数示例：总体精确匹配率 70%、Level 1/2/3 分别为 100% / 66.7% / 50%，Level 1→2 下降 33%、Level 2→3 下降 25%。这条结论串起来就是一句话：整体还行，中等难度开始明显衰减，高难度只有一半水平。
3.4 官方提示词与提交排行榜
- GAIA 要求使用官方系统提示词，因为答案格式直接决定能否被判定算法识别。核心约束：答案必须收尾于
FINAL ANSWER: [答案]模板；答案应是一个数字、尽量少的单词、或逗号分隔的列表；若是数字，不要使用逗号分隔符、不要加$或百分号等单位；若是字符串，不要用冠词、不要用缩写、数字用普通写法；若是列表，按元素类型套用上述规则。 - 答案提取：评估器优先用正则匹配
FINAL ANSWER:行并剥掉方括号；匹配不到再退化为答案：/最终答案：/Answer:等备用标记；全部失败则取最后一个非空行。这是典型的"防御式提取"设计——格式兼容性直接决定分数公平性。 - 提交格式：JSONL，每行
{"task_id": ..., "model_answer": ..., "reasoning_trace": ...}，可带推理轨迹；通过 Hugging Face Space 上的 GAIA leaderboard 提交表单上传。 - 预期管理：即使 Level 1 是"一步推理"，也仍然需要搜索引擎、计算器等工具才能真正答对。用一个只会聊天、不带工具的 Agent 去跑，分数低是正常的——这是评估流程跑通了，不是评估方法错了。
4. 数据生成质量评估（对应原文 12.4）
4.1 场景与三种互补方法
- 背景：高质量训练数据是系统性能的基础。本章以 AIME（美国数学邀请赛） 风格数学题生成作为案例——AIME 由美国数学协会（MAA）主办，难度介于 AMC 10/12 与 USAMO 之间；特点是答案均为 0～999 的整数、涵盖代数/几何/数论/组合/概率、需多步推理但不涉高深理论、难度约相当于 AIME 第 6～9 题。答案格式统一便于自动判定，难度适中适合大规模生成——这两个特性使它成为"生成质量评估"的理想基准。
- 参考数据与对照数据：用
TianHongZXY/aime-1983-2025（1983–2025 年 900+ 道真题，实际加载 963 道）作为生成时的风格参考样例；用math-ai/aime25（AIME 2025 真题 30 道，JSONL）作为评估时的对比基准。
| 方法 | 评估对象 | 输出指标 |
|---|---|---|
| LLM Judge | 生成题目质量 | 平均分、及格率、优秀率 |
| Win Rate | 生成题目 vs 真题的相对质量 | 胜率、败率、平局率 |
| 人工验证 | 答案的正确性、步骤完整性、推理严密性 | 1-5 分评分 + 状态标注 |
- 为什么这样分工：LLM Judge 与 Win Rate 负责自动化的题目质量评估，人工验证负责答案质量把关——前者解决规模问题，后者解决严谨性问题。
4.2 LLM Judge
- 是什么：用大语言模型当评委，从多个维度给生成数据打分。
- 为什么用：人工评估准确但成本高、效率低，无法应对大规模生成；LLM Judge 能自动化评估，保持评估标准一致，还能给出评分理由和改进建议，为后续优化指明方向。
- 四个评估维度（1-5 分制）：正确性 Correctness（数学逻辑是否正确、答案是否准确）、清晰度 Clarity（表述是否清晰、解答是否易懂）、难度匹配 Difficulty Match（难度是否符合 AIME 中等偏难标准）、完整性 Completeness（步骤是否完整、是否包含必要推理）。
- 三个聚合指标公式：
| 指标 | 公式 | 含义 |
|---|---|---|
| 平均分 | 1/N · Σ (Σ_{d=1..4} S_i,d / 4) |
整体质量水平 |
| 及格率 | ` | |
| 优秀率 | ` |
其中 N 为题目总数、S_i,d 为第 i 题在第 d 维度的 1-5 分得分、Score_i 为该题四维平均分。三个指标是三层筛子：平均分看整体，及格率保底线，优秀率看上限。
- LLM Judge 的偏差与局限（本章明确点名的两条）：一是对某些回答风格的偏好（评审模型可能偏爱某种表述方式）；二是对长度的敏感性（长短不同的回答可能被不成比例地打分）。此外，绝对评分本身还面临"标准漂移"风险——同一份数据在不同时间、不同评委模型下未必得到相同分数。
- 缓解手段（均为本章给出的做法）：
- 语言对齐：生成与评审都用英文，英文 vs 英文才公平，同时避免翻译引入的准确性问题；
- 改用成对相对比较：Win Rate 让评委直接判"A 还是 B 更好"，这种相对判断比绝对打分更符合人类习惯，也更容易暴露相对优劣；
- 多评委评审团：用 3～5 个不同 LLM 充当评委，再对评分做聚合、处理评委分歧、检测并过滤异常评分——这是本章习题中给出的"评审团式评估"思路；
- 人工验证兜底：自动评估无法覆盖的创新性、趣味性等主观因素，由人工最终把关。
- 另一处偏差信号：如果 Win Rate 显著高于 50%，不一定说明生成质量真的超越真题，也可能说明评估标准本身存在偏差——这是判断评估可信度的重要反向线索。
4.3 Win Rate（成对对比评估）
- 是什么：把"生成题目"和"真题"配对交给 LLM 判断哪个更好，统计三种结果的占比。
- 为什么用：LLM Judge 给的是绝对分，缺少参照物；Win Rate 提供相对分，直接回答"离真题还差多少"。
- 三个指标公式：
| 指标 | 公式 | 含义 |
|---|---|---|
| 胜率 | Wins / Total Comparisons |
生成题优于真题的比例 |
| 败率 | Losses / Total Comparisons |
真题更优的比例 |
| 平局率 | Ties / Total Comparisons |
质量相当的比例 |
三者满足 Win Rate + Loss Rate + Tie Rate = 100%。
- 判定输出的三种取值：
winner∈{"A", "B", "Tie"}，比较维度包括数学逻辑严谨性、表述清晰度、难度合理性、解答完整性。 - 理想结果：Win Rate ≈ 50%（说明生成质量接近真题）。显著低于 50% → 生成质量不如真题，需优化生成策略；显著高于 50% → 要么真超越了，要么评估标准有偏差，需人工复核。
4.4 人工验证
- 为什么必须保留：数学题需要严格逻辑推理，答案的准确性、解答步骤的完整性、数学推理的严密性只能由人类专家判定；人还能发现自动评估遗漏的创新性、趣味性等主观因素。
- 怎么做：基于 Gradio 的 Web 界面，单题操作流程为——阅读题目/答案/解答 → 从四个维度打分（1-5）→ 选择状态（
approved通过 /rejected拒绝 /needs_revision需修改）→ 添加评论 → 提交 → 下一题。 - 输出格式：验证结果落盘为
<data_path>_verifications.json，每题记录problem_id、scores（四维度）、total_score、status、comments、verified_at。这种"逐题结构化留痕"是人工标注能被复用的前提。
4.5 质量标准与迭代闭环
- 可直接使用的质量门槛（原文建议值）：LLM Judge 平均分 ≥ 4.0/5.0；Win Rate ≥ 45%（接近 50%）；通过率 ≥ 80%；人工验证通过率 ≥ 90%。
- 迭代闭环：根据评估结果调整生成提示词 → 分析低分题目的共同问题 → 参考高分题目的优点 → 持续改进生成策略。
- 完整评估流程：生成题目 → 跑 LLM Judge 评估 → 跑 Win Rate 评估 → 汇总生成综合报告（含主题分布、各维度评分、胜率统计、综合结论、改进建议、下一步行动）。两种评估各自 try 独立执行，一个失败不影响另一个出结果，最后再合并成综合报告。
4.6 生成侧的工程细节（容易被忽略但会直接影响评估结果）
- 限速与检查点：生成时设置延迟避免 API 速率限制（实践建议 2～3 秒，完整流程推荐 3～5 秒）；启用检查点保存避免中断损失；先小批量（10 题）确认没问题再大批量生成。30 题是典型案例规模。
- LaTeX 与 JSON 的坑：题目里的公式（
\frac、\sqrt）中的反斜杠在 JSON 中是非法转义，会直接抛Invalid \escape。修法是先用正则把未转义的反斜杠替换为双反斜杠再解析——否则整条样本会被当成生成失败，污染评估结果。 - 为什么用英文生成：与 AIME 真题保持一致、保证 LLM Judge 评估公平（英文 vs 英文）、便于国际化、避免翻译准确性问题。
- 生成器设计：从 900+ 道真题中随机抽取参考样例注入提示词，明确要求"生成一道完全不同的题"并输出
problem / answer / solution / topic的 JSON；难度、答案范围（0-999）、主题分类都在提示词里硬约束。
5. 选型对照：什么场景用什么指标
| 你的场景 | 首选判定算法 | 首选指标 | 理由 |
|---|---|---|---|
| 考函数调用是否调对 | AST 匹配 | Accuracy、分类准确率 | 语法等价而非字面相等 |
| 考答案对不对（短答案） | 准精确匹配 | Exact Match Rate、Drop Rate | 归一化抹平格式差异 |
| 考综合任务能力 | 准精确匹配 + 人工评轨迹 | 分级准确率、平均推理步骤数 | 暴露难度衰减与过程代价 |
| 考开放式生成质量 | LLM Judge | 平均分、及格率、优秀率 | 无唯一正确答案，需多维软打分 |
| 考"比参照物好不好" | 成对对比 | Win Rate / Loss Rate / Tie Rate | 相对分比绝对分更稳 |
| 考严谨性（数学/法律/医疗） | 人工验证 | 通过率、状态分布 | 自动评估覆盖不到严密性 |
| 考成本与效率 | —— | Token Usage、Response Time、平均步数 | 前两者是全章通用效率口径 |
| 考容错 | —— | Error Rate、Failure Recovery | 官方指标清单里的鲁棒性族 |
三条选型规则：
- 有唯一确定答案 → 用确定性判定（AST 匹配 / 准精确匹配），能用规则就不要用 LLM 当评委；没有确定答案（开放生成）→ 才上 LLM Judge。
- 要横向对比（换模型、上排行榜）→ 必须用同一套官方算法与官方数据格式，否则分数不可比。
- 成本敏感 → 分层评估：日常迭代用低成本快速评估，版本发布前用标准评估，重大更新或对外发布才用全面评估；样本量按 5 → 50 → 全量 逐级放大，每级设通过阈值再晋级。
6. 高频考点 & 易错点速查
- 评估的四层结构：数据层 Dataset / 评估层 Evaluator / 指标层 Metrics / 工具层 Tool。任何新基准照这四个组件扩。
- AST 匹配的三个等价条件：函数名精确、参数键集合相等（忽略顺序）、参数值语义等价；多函数调用要求数量相同、逐个匹配、顺序无关。
- 准精确匹配 = 归一化 + 精确比对；三类归一化规则（数字去逗号去单位、字符串小写去冠词去标点、列表排序后重连）是必背细节。
- 两种判定算法的分工：BFCL 考"调用等价"，GAIA 考"答案等价"，都不是语义相似度匹配；这也是它们选择不同算法（AST vs Quasi Exact Match）的根本原因。
- 易错点：把"准确率"当成唯一指标。真正暴露问题的往往是分类准确率、难度递进下降率、平均推理步骤数。
- 易错点：忽略 Irrelevance 类别。"不需要调用工具时却调用了"同样是错误，且在生产环境中危害更大。
- 易错点：答案格式不遵守官方要求。GAIA 必须收尾于
FINAL ANSWER:，数字不得带千分位与单位——格式一错，判定算法直接判 0，与能力无关。 - 易错点：Win Rate 越高越好。理想值是 ≈50%；显著高于 50% 反而是评估标准可能有偏差的警报。
- LLM Judge 的两类已知偏差：风格偏好、长度敏感性；缓解靠语言对齐、成对相对比较、多评委聚合、人工兜底。
- 易错点：用自研指标上公开榜单。官方评估工具用的是官方算法，结果才与排行榜一致。
- 本章的三条质量门槛（可背）：平均分 ≥ 4.0、Win Rate ≥ 45%、通过率 ≥ 80%，人工通过率 ≥ 90%。
- 习题考点映射（6 道题 5 组考点，一句话一条）：
- 基准对比与指标选型：BFCL 与 GAIA 各考什么能力、为何选不同判定算法、给智能客服的四项能力分别配指标、针对"不确定性/标准多样/成本高"三挑战提方案；
- BFCL 动手：AST 匹配为何优于字符串匹配、何时会假阳性/假阴性、四类别各设计边界样本、扩展评估器（调用顺序依赖、调用效率、错误类型分析）；
- GAIA 扩展：三级难度差异与 Level 4 设计、准精确匹配对答案多样性的处理与局限、自建领域评估集（10 题含标准答案与评分标准）；
- LLM Judge 深挖：相比规则/指标的优势与偏见、为代码/创意写作/技术文档分别设计评分标准、多评委系统的评分聚合与分歧处理；
- 评估体系实践：分层评估策略（快速/标准/全面）、持续评估与性能下降告警、面向开发者/产品经理/用户的分层报告。
7. 与前后章节的衔接
前序章节提供了被评估的对象：多种智能体范式、工具系统、记忆机制与强化学习训练成果，本章则为它们补上"没有它就无法判断优化是否生效"的一环——把 Agent 能力转成可比较的数字。本章的输入是 Agent 的运行输出（函数调用、最终答案、生成数据），输出则是一套可复用的 Dataset / Evaluator / Metrics / Tool 四件套与三类评估范式（工具调用、通用能力、生成质量）。下一章起进入实战：把 HelloAgents 框架落到真实项目中，而本章建立的评估流程正是所有项目上线前的质量闸门。
浙公网安备 33010602011771号