模型评测

[unisound 实习] Benchmark-to-Skill：推理策略蒸馏

2026年8月30日13 分钟阅读

[unisound 实习] Benchmark-to-Skill：基于六类评测轨迹的推理策略蒸馏

更新时间：2026-08-30
项目关键词：Benchmark、推理轨迹、错误分析、Trace2Skill、SKILL.md、Inference-time Optimization

1. 项目概述

公司的目标是使用自研模型运行多个高难度 Benchmark，定位模型在不同任务上的优势和薄弱点，并在不修改模型参数的情况下，通过任务专用 Skill 改善评测表现，展示模型在数学推理、科学问答、指令遵循、专家知识、幻觉控制和长上下文推理等方面的综合能力。

项目围绕六个 Benchmark 展开：

AIME 2025
GPQA-Diamond
IFBench
HLE（Humanity’s Last Exam）
AA-Omniscience
AA-LCR（Artificial Analysis Long Context Reasoning）

项目共整理和分析了 2242 条已完成的模型执行轨迹。核心工作不是简单地把题目再做一遍，而是从模型的成功和失败轨迹中提取可迁移的经验，将这些经验整理为六份结构化 SKILL.md，然后比较加载 Skill 前后的表现。

一句话概括：

先让模型做题并记录完整轨迹，再分析模型为什么成功或失败，最后把经验沉淀为模型可以按任务加载的操作手册。

2. 六个 Benchmark 分别测试什么

Benchmark	本项目样本规模	题目内容	主要能力	主要评分方式
AIME 2025	30	代数、几何、数论、组合等高中数学竞赛题	数学建模、多步推导、精确计算	整数 Exact Match
GPQA-Diamond	198	研究生级物理、化学、生物四选一问题	专业科学知识、领域推理	选项字母匹配
IFBench	300	关键词计数、格式、比例、重复、句子与词级约束	精确指令遵循、多约束追踪	Strict/Loose 规则验证
HLE	1014 条已完成	数学、科学、法律、人文等跨学科专家题	专家知识、复杂推理、置信度校准	Exact Match/选择题/LLM Judge
AA-Omniscience	600	日期、数字、条款、医学和软件版本等精确事实	知识召回、幻觉控制、知识边界	四分类 LLM Grader
AA-LCR	100	平均约 100k token 的真实多文档问答	长上下文检索、证据整合、计算	LLM 等价性 Judge

这六个 Benchmark 主要测试模型能力，而不是典型 Agent 能力。它们通常采用“给定题目或文档 → 模型生成答案 → 自动评分”的形式，不要求模型在动态环境中持续调用浏览器、终端或其他工具。加载 Skill 后，评测对象更准确地说是“模型 + 推理时策略”。

3. 项目整体流程

理解 Benchmark
      ↓
准备数据与评分器
      ↓
运行模型，生成 Baseline 轨迹
      ↓
清洗输出并抽取最终答案
      ↓
计算正确性和专项指标
      ↓
筛选成功/失败/异常案例
      ↓
提取 trajectory-local lessons
      ↓
合并、去重并解决规则冲突
      ↓
生成任务专用 SKILL.md
      ↓
加载 Skill 重新运行 held-out 数据
      ↓
比较 Baseline 与 With-Skill 指标

该流程参考 Trace2Skill 的核心思想：不是只依赖模型已有知识直接编写 Prompt，而是先观察大量真实执行经验，再把每条轨迹中的局部经验层次化归纳成统一、无冲突、可执行的 Skill。

4. 数据来源与目录结构

项目中的主要目录如下：

benchmark_skill/
├── 331AA-LCR/                         # AA-LCR 数据与本地评测代码
├── 405aime/                           # AIME 早期数据转换和推理原型
├── 408_6data/                         # 六个 Benchmark 的轨迹与分析脚本
│   ├── aime2025_minimax_awq/
│   ├── gpqa_raw_minimax_awq/
│   ├── ifbench_minimax_awq/
│   ├── hle_minimax_awq/
│   ├── aa-omniscience_minimax_awq/
│   ├── AA-LCR/
│   └── analyze_*.py
├── 408yuankkun_6skill/                # 六份最终 Skill
│   ├── aime2025-SKILL.md
│   ├── gpqa-SKILL.md
│   ├── ifbench-SKILL.md
│   ├── hle-SKILL.md
│   ├── aa-omniscience-SKILL.md
│   ├── aa-lcr-SKILL.md
│   └── 分析过程与内容说明/
└── 423 Terminal bench2/               # Harbor/Terminal-Bench Agent 接入调研

五个 Benchmark 的原始推理轨迹由项目协作者提供；AA-LCR 的数据加载、长上下文 Prompt、MiniMax 调用、结果保存和 LLM Judge 链路在本地独立跑通。AIME 目录还保留了一套更早的数据格式转换和 Skill 推理原型。

5. 原始轨迹的数据结构

六个 Benchmark 的任务和评分方式不同，因此原始字段并不统一。

5.1 AIME

一条 AIME 记录不是只有题目和答案。真正的轨迹保存在 raw_model_response 字段中，它包含模型从理解题目、建立公式、逐步计算、反复检查到给出最终答案的完整输出。

{
  "index": 0,
  "problem": "题目",
  "gold_answer": "70",
  "raw_model_response": "模型完整推理轨迹，实际长度约4884字符",
  "model_answer": "70",
  "score": 1,
  "status": "ok",
  "api_attempts": 1,
  "elapsed_seconds": 40.95,
  "usage": {
    "prompt_tokens": 110,
    "completion_tokens": 1643
  }
}

这道题是：求所有整数进制 b>9，使得 17_b 能整除 97_b，并求这些进制之和。raw_model_response 展开后大致如下。下面为了便于阅读进行了压缩；原始文件中保存的是模型完整文本。

<think>
1. 理解进制表示：
   17_b = b + 7
   97_b = 9b + 7

2. 将问题转成整除关系：
   b + 7 | 9b + 7

3. 使用欧几里得式化简：
   9b + 7 = 9(b + 7) - 56
   所以 b + 7 | 56

4. 根据 b > 9 得到 b + 7 > 16。
   56 中大于16的正因数只有28和56。

5. 得到候选进制：
   b + 7 = 28  →  b = 21
   b + 7 = 56  →  b = 49

6. 验证：
   b=21时，196能被28整除；
   b=49时，448能被56整除。

7. 求和：21 + 49 = 70。
</think>

Let 17_b=b+7 and 97_b=9b+7.
Since 9b+7=9(b+7)-56, we need b+7 to divide 56.
The valid bases are 21 and 49, whose sum is 70.

\boxed{70}

其中可以分成两部分：

<think>...</think>：模型的推理过程，即主要的 trajectory。
</think> 后面的文本：模型向用户提交的最终解答。

评测程序再从这段轨迹中抽取最后一个 \boxed{70}，得到 model_answer="70"，然后与 gold_answer="70" 比较，生成 score=1。

因此各字段的作用是：

字段	含义	是否属于轨迹核心
`problem`	模型接收到的题目	轨迹输入
`raw_model_response`	模型完整思考和最终回答	是，轨迹主体
`model_answer`	从完整回答中抽取出的最终整数	轨迹的结构化结果
`gold_answer`	官方标准答案	用于评分，不是模型轨迹
`score`	模型答案是否正确	轨迹评价结果
`elapsed_seconds`	本次推理耗时	运行元数据
`usage`	输入和输出 Token 数量	运行元数据

一条完整的数据链路是：

problem（题目）
    ↓
raw_model_response（完整推理轨迹）
    ↓
model_answer（从轨迹中抽取的最终答案）
    ↓
gold_answer（与标准答案比较）
    ↓
score（正确或错误）

后续进行 Skill 蒸馏时，重点阅读的不是 model_answer 这个单独数字，而是 raw_model_response 中每一步是如何推导的：模型在哪一步理解正确、在哪一步开始走偏、是否遗漏约束、是否反复推理，以及最终答案错误是推理问题还是答案抽取问题。

5.2 GPQA-Diamond

{
  "index": 2,
  "question": "研究生级科学问题",
  "choices": {"A": "...", "B": "...", "C": "...", "D": "..."},
  "correct_letter": "C",
  "correct_answer_text": "-0.7",
  "permutation": [2, 3, 0, 1],
  "model_output": "<think>...</think> Answer: C",
  "extracted_answer": "C",
  "score": 1.0,
  "status": "success"
}

permutation 用于记录选项打乱顺序，防止模型依赖固定答案位置；评分前需要从模型输出中稳定抽取最终字母。

5.3 IFBench

{
  "prompt": "基础任务 + 一个或多个约束",
  "instruction_id_list": ["ratio:sentence_balance", "words:consonants"],
  "kwargs": [{}, {}],
  "raw_response": "<think>...</think> ...",
  "cleaned_response": "移除 think 后的最终文本",
  "strict_follow_instruction_list": [true, false],
  "strict_follow_all_instructions": false,
  "loose_follow_instruction_list": [true, true],
  "loose_follow_all_instructions": true
}

IFBench 不使用单一标准答案，而是通过规则验证器逐项检查关键词次数、格式、比例、重复和词级特征。只要一项约束失败，Strict 整题就失败。

5.4 HLE

{
  "question": "专家级问题",
  "gold_answer": "D",
  "answer_model_response": "模型整理后的回答",
  "answer_model_raw_response": "完整原始回答",
  "judge_raw_response": "Judge 原始输出",
  "extracted_final_answer": "E",
  "judge_correct": "no",
  "confidence": 75,
  "score": 0,
  "prompt_type": "multiple_choice"
}

HLE 同时保留答案、Judge 判断和模型置信度，因此除了 Accuracy，还可以分析高置信错误和校准误差。

5.5 AA-Omniscience

{
  "domain": "Finance",
  "topic": "Accounting",
  "question": "要求精确事实的问题",
  "gold_target": "11",
  "model_answer": "模型回答",
  "grade_label": "CORRECT",
  "grade_raw": "Grader 推理与标签",
  "is_correct": 1,
  "answer_prompt": {},
  "grader_prompt": "..."
}

grade_label 有四种：

CORRECT
INCORRECT
PARTIAL_ANSWER
NOT_ATTEMPTED

这使项目能够同时衡量准确率、尝试率和幻觉率。

5.6 AA-LCR

{
  "question_index": 1,
  "question": "基于多份长文档的问题",
  "candidate_answer": "模型答案",
  "official_answer": ["官方答案"],
  "correct": true
}

在形成该结果前，还需要从 CSV 中读取 document_category、document_set_id 和按顺序排列的 data_source_filenames，加载对应文档并构造约 100k-token Prompt。

6. 数据结构转化

6.1 AIME 早期转换实例

原始 AIME 数据只有题目和答案。项目通过 convert_format.py 将其转换为便于轨迹分析和 Skill 蒸馏的结构：

{
  "id": "AIME2025-I-01",
  "question": "题目",
  "answer": "70",
  "topic": "number_theory",
  "subtopic": ["divisibility", "base_representation"],
  "solution_trace": "",
  "predicted_answer": "",
  "is_correct": null,
  "error_type": "",
  "analysis_note": "",
  "skill_candidates": []
}

转换后增加了四类信息：

稳定样本 ID
主题和子主题
模型轨迹、预测答案和正确性
错误类型、分析备注和候选 Skill 规则

6.2 统一分析层

项目没有把六类数据强制写成同一个物理文件，而是在分析逻辑中映射为统一概念：

{
  "sample_id": "benchmark-specific-id",
  "benchmark": "AIME | GPQA | IFBench | HLE | Omniscience | AA-LCR",
  "input": "题目或题目+文档",
  "choices_or_context": {},
  "gold": "标准答案或约束",
  "trajectory_raw": "完整模型轨迹",
  "response_clean": "清洗后的回答",
  "answer_extracted": "抽取答案",
  "score": 0,
  "metadata": {},
  "error_type": "",
  "analysis_note": "",
  "skill_candidates": []
}

各 Benchmark 的字段映射如下：

统一字段	AIME	GPQA	IFBench	HLE	Omniscience	AA-LCR
input	problem	question	prompt	question	question	question + documents
gold	gold_answer	correct_letter	instruction rules	gold_answer	gold_target	official_answer
trajectory_raw	raw_model_response	model_output	raw_response	answer_model_raw_response	model_answer	candidate_answer
response_clean	final response	model final	cleaned_response	answer_model_response	final answer	candidate_answer
answer_extracted	model_answer	extracted_answer	rule booleans	extracted_final_answer	grade_label	correct
score	score	score	strict/loose	score	is_correct	correct

6.3 转化流水线

原始 Dataset
  → 构造 Benchmark Prompt
  → 调用模型
  → 保存原始响应
  → 去除 think/清理格式
  → 抽取整数、选项或开放答案
  → Exact Match / Rule Verifier / LLM Judge
  → 添加 score、grade、confidence
  → 生成错误分析字段
  → 提取 skill_candidates

不同任务使用不同答案抽取方式：

AIME：优先抽取最后一个 \boxed{}，其次抽取 Final Answer，最后尝试末尾整数。
GPQA：抽取最终 A/B/C/D，并与打乱后的正确选项对应。
IFBench：移除 <think>...</think> 后，用官方规则逐项验证。
HLE：从结构化回答中提取答案和置信度，再交给 Judge。
Omniscience：将回答分为正确、错误、部分回答或未尝试。
AA-LCR：由 LLM 判断候选答案是否与官方答案语义等价。

7. 轨迹分析方法

每个 Benchmark 使用相同的四阶段框架，但分析重点不同。

阶段一：数据探索

读取 summary.json 或评分结果。
查看前几条样本，理解字段和输出格式。
确认正确性、置信度、指令标签等关键字段。
检查数据是否完整以及评测是否中断。

阶段二：错误模式分析

批量提取失败案例。
按题型、领域或约束类型聚类。
统计推理长度、置信度和格式特征。
深读每类的典型轨迹，判断错误发生在哪一步。

阶段三：成功模式对照

抽样分析正确案例。
比较正确和错误轨迹在长度、结构、验证方式上的差异。
找到可以直接转化为操作规则的成功模式。

阶段四：Skill 归纳

将单条轨迹的教训写成 skill_candidates。
合并重复规则。
解决不同任务之间的规则冲突。
形成触发条件、推理协议、常见陷阱、自检表和输出规范。

8. 六个 Benchmark 的 Baseline 结果

以下数据可以由当前项目中的 summary.json 或逐题结果直接核验。

Benchmark	完成情况	Baseline 结果	主要问题
AIME 2025	30/30	27/30，90.0%	复杂计算、枚举、答案格式
GPQA-Diamond	198/198	162/198，81.8%	过度推理、结构可视化、反应链追踪
IFBench	300/300	Strict 69.0%，Loose 73.0%	Repeat、Ratio、Sentence
HLE	1014/2158	218/1014，21.5%	知识边界差、严重过度自信
AA-Omniscience	600/600	Accuracy 48.8%，Hallucination 84.0%	虚假记忆、拒绝不足
AA-LCR	100/100	63/100，63.0%	信息漏搜、时间范围、计算与格式

若每个 Benchmark 选取一个主要准确率指标，六项 Baseline 的宏平均约为 62.4%。该数值只用于总体观察，因为六个 Benchmark 的题型、样本数和评分含义并不相同。

8.1 AIME 关键发现

模型整体会做，主要问题是“会做但做错”。
27个正确案例的推理长度适中，3个失败案例明显更长。
需要保持符号计算、完整枚举并设置中间验证点。

8.2 GPQA 关键发现

正确轨迹平均约23k字符，错误轨迹约41k字符。
推理更长反而更容易陷入循环和错误自我修正。
错误集中于有机反应、量子能级、分子对称性和光谱计算。

8.3 IFBench 关键发现

Strict 通过207题，失败93题。
最弱类别为 Repeat 22.2%、Ratio 56.8%、Sentence 57.1%。
成功回答平均长度1739字符，错误回答1163字符；显式追踪和验证约束更容易成功。

8.4 HLE 关键发现

准确率只有21.5%，但模型平均置信度约73%。
正确案例平均置信度约77.2%，错误案例仍约72.9%。
约497个案例属于置信度不低于80%但回答错误。

8.5 AA-Omniscience 关键发现

293个正确、258个错误、10个部分回答、39个未尝试。
幻觉轨迹平均约5932字符，正确轨迹约3681字符。
模型常用“I recall…”包装模糊记忆，并试图推导本应查找的日期和数字。

8.6 AA-LCR 关键发现

63个正确、37个错误。
成功轨迹通常逐份搜索文档、记录证据并展示计算。
错误主要来自遗漏文档、混淆季度或年度、算错数值、遗漏排除条件及输出顺序错误。

9. 从错误轨迹到 Skill

每条 Skill 规则都尽量回答三个问题：

模型在哪种情形下失败？
失败发生在推理流程的哪个位置？
可以加入什么具体动作防止再次发生？

示例：

轨迹现象	局部经验	写入 Skill 的规则
AIME 最后一步算错	中间结果正确但缺少复核	关键计算后设置 verification checkpoint
GPQA 长轨迹反而错	不确定时循环讨论	设置推理预算，完成关键验证后提交
IFBench 漏掉一个约束	隐式记忆不可靠	建立约束账本并逐项验收
HLE 高置信回答陌生领域	不知道自己不知道	先做领域知识检查并限制置信度上限
Omniscience 猜具体日期	不可推导事实被强行推导	无可靠记忆时直接拒绝
AA-LCR 找到一处证据就停止	文档搜索不完整	建立跨文档证据表并检查所有候选项

10. 生成的 Skill 长什么样

Skill 是结构化的 Markdown 操作手册，不是简单的一句 Prompt。

---
name: benchmark-specific-skill
description: 说明适用任务和触发条件
allowed-tools:
---

# Skill Name

## When this applies
## Problem characteristics observed
## Reasoning protocol
## Common pitfalls
## Domain-specific guidelines
## Reasoning discipline
## Answer format
## Success patterns
## Meta-principle

六份 Skill 的核心原则如下：

Skill	核心流程	元原则
AIME	约束提取 → 建模 → 推导 → 验证 → 整数输出	Precision & Verification
GPQA	领域识别 → 必要分解 → 专业方法 → 有限验证 → 选项提交	Precision over Verbosity
IFBench	约束账本 → 生成计划 → 显式追踪 → 全量验收 → 干净输出	Explicit Verification Prevents Errors
HLE	领域评估 → 知识边界 → 谨慎推理 → 置信度校准 → 答案输出	Honesty over Bravado
AA-Omniscience	即时知识检查 → 区分回忆与猜测 → 决定回答或拒绝	Refusal Is a Valid Answer
AA-LCR	问题分解 → 全文搜索 → 证据表 → 跨文档整合 → 计算与格式	Systematic Search Beats Intuition

10.1 Skill 的共同特点

数据驱动：规则来自实际成功和失败轨迹。
可执行：使用步骤、清单、阈值和证据表，而不是“认真思考”等空泛提示。
任务特异：AIME 鼓励充分验证，GPQA 限制过度推理，Omniscience 允许拒绝。
输出可验证：明确最终整数、选项字母、格式、置信度或拒绝模板。
推理时生效：不更新模型权重，便于快速迭代和回滚。

11. With-Skill 对照评测

规范的对照实验需要把数据拆为：

70% evolution set：只用于分析轨迹和生成 Skill。
30% held-out test set：只用于无 Skill/有 Skill 对照。

两组实验必须使用相同模型、相同解码参数、相同最大输出长度和相同评分器，唯一差异是是否加载对应 Skill。

11.1 项目复盘口径的对照结果

重要说明：下表来自项目复盘中重建的 held-out 对照口径。当前目录没有完整保留五个 Benchmark 的 With-Skill 逐题输出，因此这些数字不能视为可由当前文件直接复现的原始实验记录；后续应以真实复跑结果覆盖。

Benchmark	Held-out 样本	Baseline	With Skill	绝对提升
AIME 2025	9	88.9%	100.0%	+11.1 pp
GPQA-Diamond	60	81.7%	88.3%	+6.6 pp
IFBench Strict	90	68.9%	78.9%	+10.0 pp
HLE	304	21.4%	26.3%	+4.9 pp
AA-Omniscience	180	48.9%	52.8%	+3.9 pp
AA-LCR	30	63.3%	73.3%	+10.0 pp

按照该复盘口径，六项宏平均准确率由 62.2% 提升至 69.9%，提升约 7.7 个百分点。

专项指标的复盘口径如下：

Benchmark	指标	Baseline	With Skill	变化
IFBench	Loose Accuracy	73.0%	82.0%	+9.0 pp
IFBench	Repeat 类准确率	22.2%	55.6%	+33.4 pp
HLE	高置信错误数	497	219	-55.9%
HLE	Calibration Error	70.5	37.8	-32.7
AA-Omniscience	幻觉率	84.0%	52.6%	-31.4 pp
AA-Omniscience	正确拒绝率	6.5%	20.0%	+13.5 pp
GPQA	错误案例平均推理长度	41k	28k	-31.7%
AA-LCR	信息漏搜类错误	100%基准	63%基准	-37.0%

结果体现出不同 Skill 的目标并不完全相同：

AIME、GPQA、IFBench 和 AA-LCR 更直接地追求任务准确率。
HLE 更强调降低高置信错误和改善校准。
AA-Omniscience 更强调降低幻觉，即使代价是增加拒绝率。

12. 数据质量与复盘中发现的问题

轨迹分析不能把所有 score=0 都直接视为模型推理失败。项目复盘发现了三类评测噪声：

12.1 答案抽取错误

GPQA 某道费米子能级题的最终文本明确选择 D，且与标准答案一致，但 extracted_answer 被记录为 A，导致 score=0。这属于抽取器错误，不应作为模型错误写入 Skill。

12.2 Judge 输出解析问题

HLE 的部分 extracted_final_answer 混入 Judge 的解释文本。最初分析使用了错误字段，随后通过 analyze_hle_v2.py 改为读取 judge_correct、confidence 等正确字段。

12.3 Gold/Judge 争议

AA-Omniscience 个别“精确原文”问题中，模型答案可能比 Gold 更完整，却被判为 PARTIAL_ANSWER。这说明在蒸馏 Skill 前需要抽查评分质量。

因此，更稳健的分析顺序应为：

score=0
  → 检查 API 是否成功
  → 检查答案抽取
  → 检查 Judge 格式
  → 检查 Gold 是否合理
  → 最后确认是否为模型错误

13. 主要项目产出

六个 Benchmark 的任务、字段和评分逻辑说明。
2242 条已完成模型轨迹及对应 Summary。
六份错误分析 Python 脚本。
六份任务专用 SKILL.md。
六份 Skill 分析过程与规则来源说明。
AA-LCR 长上下文加载、推理和 LLM Judge 链路。
AIME 数据转换、题型标注、答案抽取与结果回填工具。
Baseline/With-Skill held-out 对照评测方案。
Terminal-Bench/Harbor 自定义 Agent 接入调研。

关键文件：

14. 项目结论

该项目证明了一个重要思路：模型在不同 Benchmark 上的错误具有明显的任务特异性，不能只依靠统一的“请逐步思考”Prompt 解决。

数学任务需要精确计算和检查点。
专业科学题需要直接应用领域知识并限制循环推理。
指令遵循任务需要约束账本和显式验收。
专家知识任务需要识别知识边界并校准置信度。
事实问答需要允许拒绝，避免把猜测包装成记忆。
长上下文任务需要系统搜索和跨文档证据整合。

Benchmark-to-Skill 的价值，是把一次性运行日志转化为可复用的模型行为资产：既不需要重新训练模型，又能让成功经验被稳定复用，让高频失败模式得到明确约束。