推理能力：多步推理评测

可视化演示

演示模型在数学证明、逻辑链条与规划类任务中逐层推进推理步骤，并穿插中间步骤评估与失败模式诊断的多步推理评测流程。

任务设计要求

一条合格的登山路线，绝不会让你一步跨上山顶。筑路师会把高差切成几个可验证的台阶：先过一线天，再到半山亭，最后冲顶云梯。每一段都有明确的路标，又都保留着真实的挑战。你要是问登山俱乐部“怎么评估一个人的登山水平”，他们会先反问：你设计的是什么路线？路线太陡，所有人都摔在半路；路线太缓，又测不出真本事。

多步推理评测的第一步，同样是“造山”。评测者要设计一系列需要多个推理步骤才能完成的题目，比如数学证明题、逻辑链条题、多阶段规划题。每道题必须满足三条铁律：目标清晰（有唯一可验证的结论）、步骤必要（每一步都是后续推理的基石）、防捷径（无法通过表面线索一步猜出答案）。换句话说，不能让模型像坐缆车一样跳过中间环节。

在任务设计里，步骤之间的依赖关系决定了难度。假设模型完成第 i 步的成功率为 p_i，那么完成整条 n 步推理链的整体成功率，遵循链式法则：

基于这个链条，评测者会刻意控制任务步数（通常 3~5 步最有效）并设置难度梯度，避免出现“全军覆没”的悬崖。回到登山比喻：好路线设计决定了评测含金量。要是每条路线都有缆车直通山顶，你测出来的根本不是登山能力，而是购票能力；只有当每一段路都不可跳过、不可作弊时，山顶的印章才有说服力。

评测数据集构建

有了路线图，接下来要修训练场。登山俱乐部不会只靠一条路发家，而是会在不同山脉收集、开辟大量风格各异的路线：有的考验耐力，有的考验攀岩技巧，有的云雾天容易迷路。评测数据集就是这座“多步推理训练场”，它的质量高低直接决定评测报告是否可信。

构建评测数据集，第一要义是来源多样。题目可来自真实数学考试、逻辑谜题、竞赛题库，也可以由人类专家按模板改写。来源单一的数据集容易被模型“背题”，就像总走同一条路的登山者能靠肌肉记忆蒙混过关。第二，每道题都要有人工标注的参考推理链——即一条标准答案式的思考路径，相当于老登山员画下的手绘路线图，供后续逐站比对。第三，规模要适度。多步推理的标注成本高，几百条高质量样本往往就足以区分模型能力；盲目堆数量反而会引入噪声。最后是难度配比，一般按简单：中等：困难 ≈ 3:5:2 搭配，让不同水平的模型都有可比较的发挥空间。

如果数据集全是“一步到位”的送分题，或者全是无人能解的绝壁，评测都会失去区分度——这正是训练场选址的学问。好的数据集应该像一张等高线清晰的登山地图：不同海拔、不同地形都被覆盖，评测者才能看清模型究竟擅长爬缓坡还是攀岩。

中间步骤评估

只看山顶合影，你分不清谁是徒步登顶、谁坐了直升机。登山俱乐部的做法，是在沿线设检查站逐站盖章。多步推理评测的关键设计之一，就是对模型的推理过程做“逐站盖章”——这被称为中间步骤评估。

为了让中间步骤可评估，评测者通常会要求模型以链式思考（Chain-of-Thought, CoT）的方式把推理过程显式写出来：先列条件，再算中间量，最后给出结论。评测者再把这条“思考链”切分成若干检查点，每个检查点对应一个必须得出的中间结论。对每个中间步骤单独打分，最后汇总。汇总方式常用加权过程得分：

更进一步，中间步骤的信号还能变成训练信号——过程奖励模型（Process Reward Model, PRM）会用检查点打分来强化模型的每一步推理，而不仅仅奖励最后落在山顶的那一下。回到登山比喻：真正专业的领队不只看你是否到达山顶，还会检查你在半山亭有没有喝水、在云梯上有没有挂好安全绳。正是这些沿途盖章，把“运气好”和“能力强”区分开来。

评分自动化

检查站有了，总不能每站都靠人工盖章。登山俱乐部会引入电子打卡器：登山者戴上手环，经过检查点时自动记录时间与位置。多步推理评测同样需要评分自动化，否则几百道题、每道四五步的人工评分会让人崩溃。

自动评分有三层方案，由快到慢、由规则到智能。第一层是规则匹配：评测者事先为每个检查点写好等价表达式或答案集合，把模型输出与参考链做精确匹配或符号计算比对。这就像电子打卡器对准某个固定位置，简单可靠但不够灵活。第二层是语义近似匹配：用文本嵌入相似度或文本蕴含模型，判断模型的一步推理与参考答案“意思是否一致”，能容忍换一种说法的合法推理。第三层是 LLM 裁判：让大模型根据评分标准给出分档与理由，处理那些模糊、开放式的推理步骤；但 LLM 裁判并非绝对公正，需要一致性校验——比如同题多次打分，统计一致率，并定期与人工评分抽检对齐。

用一个登山场景来理解：规则匹配是固定打卡桩，只认手环；语义匹配是巡山员认脸，说明你走这条路也算数；LLM 裁判则是经验老到的裁判长，能判断“你虽然没走官方路线，但选择的路径同样合理”。三层结合，既守住了效率底线，又避免了单一智能体评分带来的偏见。

失败模式分析

登山队保存着一摞沉甸甸的事故档案：有人在三岔口抄近路摔伤，有人雨天没看清路标走错方向，有人体力不支半途失足。多步推理评测的失败模式分析，就是为模型建立这样一摞“推理事故档案”。

常见的失败模式可归纳为四类。第一类，逻辑跳跃：模型直接跳过某个必要步骤，从条件跳到结论，推理链出现断点，就像登山者为了省力绕过半山亭。第二类，计算失误：推理框架是对的，但数值算错了，例如把 3×4 算成 10，相当于在平路上莫名其妙崴了脚。第三类，条件遗忘：题干中给出的关键信息没有被使用或记错，比如题目说“买 3 千克苹果”却按 5 千克计价，像登山者忘了看路标。第四类，幻觉编造：模型引用了不存在的数据、定理或中间结果，仿佛凭空捏造出一条根本不存在的“捷径”。

评测时，团队会把每条模型的错误回答按这四类打标签，形成错误分布表。对登山俱乐部来说，只有把“失足”“迷路”“漏标”分开统计，才知道该加装护栏、增设路标还是重新测绘地图；对模型评测而言，失败模式同样把抽象的分数翻译成具体可行动的改进项。

诊断策略

登山者半路失踪，救援队不会满山乱找，而是先看打卡记录：最后出现在哪个检查站？那里有什么地形风险？然后沿轨迹回溯，判断是路标不清还是登山者体力不足。多步推理评测里的诊断策略，做的正是这件事——不满足于“这题错了”，而是回答“到底哪一步错了、为什么错”。

常用的诊断手段有四件。一是回溯定位：从最终错误出发，沿推理链逐站回查，找到第一个偏离参考链的检查点。二是分步对比：把模型每一步输出与参考链对齐，计算逐字的语义相似度，量化偏差从哪一步开始扩大。三是归因评分：用统计方法衡量每个步骤与最终成败的关联强度，识别“关键步骤”。关键步骤的归因分可以写成：

第四件诊断工具是错误注入：故意篡改模型某一步的输入值，观察最终答案是否跟着改变。如果答案纹丝不动，说明模型根本没真正使用这一步——像登山者没在检查站打卡，路线图却显示他通过了。诊断的终点不是写一份事故报告，而是为下一轮训练和评测迭代提供明确靶点。

报告与迭代

登山季结束，俱乐部会发布一份年度报告：哪条路线完登率最高，哪段路事故最多，各年龄段队员的表现如何。多步推理评测也要产出类似的评测报告，并把结论反哺到新一轮迭代中。

一份完整的评测报告通常包含四块。能力画像：用雷达图或分项表呈现模型在数学证明、逻辑推理、规划任务等不同推理类型上的强弱项，相当于给登山者的体能、技巧、方向感分别打分。横向对比：与基线模型、前一天版本、竞品模型并列比较，让进步和差距一目了然。失败模式分布：统计各失败类型的占比，指出最值得优先解决的短板。迭代建议：基于诊断策略定位出的关键步骤，给出数据补充、提示词调整或训练策略的建议。

评测报告不是终点。登山路线每年都会因为地质变化而重修；评测基准同样需要版本化更新——新增路线、淘汰被模型背下的旧题、修正标注错误。持续迭代的基准，才能防止模型在固定路线上“刷成绩”。这正是多步推理评测最有魅力的一点：它不是一次性的期末考试，而是一条不断延伸、不断修正的登山闭环。

方法论借鉴

这套登山检查制度，不只在某一座山有效。任何徒步俱乐部都可以借鉴：设检查站、记打卡、事故分类、年度复盘。多步推理评测的方法论，同样可以抽象为可复用的原则，渗透到更多 AI 评测场景中去。

第一条原则是可复现性。评测要公开任务模板、提示词、评分标准与随机种子，让其他团队能在同一座“山”上重复验证，否则分数只是一句无法对证的承诺。第二条是公平性。防止数据泄漏（训练集混入评测题）、防止题干线索泄漏答案，确保所有模型面对同样的起跑线。第三条是成本控制。多步推理评测比普通问答贵得多——模型要多写推理链、评测要多步打分，所以要设计采样策略和分级评测，把 token 预算花在最能区分能力的题目上。第四条是动态更新。像山路会风化一样，模型的“背题”能力会随时间上升，基准必须定期换题、加题，保持挑战性。

把这四条原则回放到登山比喻里，它们就是登山界的“公约”：路线图公开、成绩可复核、经费不浪费、路况勤更新。当越来越多团队遵守这些原则时，整个行业对“模型推理能力”的判断才会真正可信——那山顶的照片，也才不再只是一张照片。

AI 应用场景

Python 演示

import re  class StepCheck:    def __init__(self, desc, expr, value, weight):        self.desc = desc        self.expr = expr        self.value = value        self.weight = weight  class Task:    def __init__(self, title, checks, final_answer):        self.title = title        self.checks = checks        self.final_answer = final_answer  class MiniEvaluator:    def __init__(self, task):        self.task = task     def grade(self, model_answer):        ans_map = {}        for line in model_answer.splitlines():            m = re.search(r"第(\d+)步.*?=\s*([\d.]+)", line)            if m:                ans_map[int(m.group(1))] = float(m.group(2))        total = 0.0        scores = []        for i, check in enumerate(self.task.checks):            got = ans_map.get(i + 1)            ok = got is not None and abs(got - check.value) < 1e-6            total += check.weight if ok else 0.0            scores.append((i + 1, check.weight if ok else 0.0, ok))        final_ok = False        if "最终答案" in model_answer:            tail = model_answer.split("最终答案")[-1]            fm = re.search(r"=\s*([\d.]+)", tail)            final_ok = fm and abs(float(fm.group(1)) - self.task.final_answer) < 1e-6        return {"总分": round(total, 2), "步骤得分": scores, "最终答案正确": bool(final_ok)}     def classify_failure(self, model_answer):        ans_map = {}        for line in model_answer.splitlines():            m = re.search(r"第(\d+)步.*?=\s*([\d.]+)", line)            if m:                ans_map[int(m.group(1))] = float(m.group(2))        failure = []        for i, check in enumerate(self.task.checks):            got = ans_map.get(i + 1)            if got is None:                failure.append((i + 1, "逻辑跳跃/步骤缺失"))            elif abs(got - check.value) >= 1e-6:                ratio = abs(got - check.value) / abs(check.value)                failure.append((i + 1, "条件误读" if ratio > 0.5 else "计算失误"))        return failure  def demo():    task = Task("买菜总价", [        StepCheck("苹果总价=斤数*单价", "3*4", 12.0, 0.3),        StepCheck("牛奶总价=瓶数*单价", "2*5", 10.0, 0.3),        StepCheck("总花费=苹果+牛奶", "12+10", 22.0, 0.4),    ], 22.0)     good = "第1步: 3*4=12\n第2步: 2*5=10\n第3步: 12+10=22\n最终答案=22"    bad = "第1步: 3*4=12\n第2步: 2*5=9\n第3步: 12+9=21\n最终答案=21"    for tag, ans in [("成功样例", good), ("失败样例", bad)]:        report = MiniEvaluator(task).grade(ans)        fails = MiniEvaluator(task).classify_failure(ans)        print(tag, report)        print(tag, "失败模式:", fails)  if __name__ == "__main__":    demo()

1. m = re.search(r"第(\d+)步.*?=\s*([\d.]+)", line)从模型回答的每一行里，用正则“抠”出第几步和算出的数值，就像从打卡记录里识别登山者经过了哪个检查站。
2. ok = got is not None and abs(got - check.value) < 1e-6判断模型这一步的数值与参考答案是否基本一致，容忍浮点误差。
3. total += check.weight if ok else 0.0按步骤权重累加过程得分，这就是加权过程得分公式的落地。
4. failure.append((i + 1, "条件误读" if ratio > 0.5 else "计算失误"))根据偏差比例粗判失败模式：差一半以上更像用错条件，小偏差更像计算失误。
5. report = MiniEvaluator(task).grade(ans)对一条模型回答执行逐步评分，得到总分、各步得分与最终答案正确性。
6. fails = MiniEvaluator(task).classify_failure(ans)对同一条回答做失败模式归类，输出具体的“事故档案”。

常见误区

面试题