作者 | 北大 OpenDCAI 团队
过去谈模型数学能力时，评测标准往往是解题的准确率。但随着越来越多的合成数据出现，错误有时会出现在题目上，模型必须要能判断一条数学数据题目本身能否被信任，是否存在条件冲突等，再验证答案。
比如把下面这道题目输入模型问答：一个圆的半径是 3 英寸，已知这个半径和圆周长的乘积等于圆面积，问圆的周长是多少？模型给出 3π 的答案。实际上题目中的额外条件和圆的基本几何关系冲突，所以题目无解。
这便是合成数学数据里非常棘手的问题。一条样本数据可以有完整题干、公式和参考答案，内部却已经混入条件缺失、表达歧义、逻辑矛盾、推理错误或计算错误。它进入训练集以后，模型学到的可能包括正确知识，也可能包括错误的题目结构和推理习惯。
为了提高数学领域合成数据的质量，北京大学 DCAI 团队提出数学数据质检 BenchMark——MathDebugger，它同时覆盖 Question 和 Answer 两端，包含 4,000 道题目、2,000 条带标注答案、7 类细粒度错误类型，并评测了 14 个主流 LLM 和 3 个 Process Reward Model。论文《MathDebugger: Detecting and Diagnosing Errors in Synthetic Mathematical Data》也已被接收为 EMNLP 2026 高分论文。（ OA 3.83｜Meta 4｜Top 0.45%）
MathDebugger 主要解答三个问题：
• 一条 Question 或 Answer 是否正确？
• 如果它是错的，错误到底属于哪一类？
• 给出明确错误类型以后，模型能不能把它修得更准？
论文中也出了一个重要实验结果：强推理模型在细粒度验证上仍远未达到饱和，而错误类型监督能稳定提升纠错准确率。MathDebugger 的价值既在评测，也在于同时对问题和答案进行测试与错误分类，并把错误变成后续修复可以使用的信号。
论文地址 https://arxiv.org/abs/2502.19058
开源仓库 https://github.com/haolpku/MathDebugger
1 Dataset：同时评测问题与答案
在评测数据集的设计上，MathDebugger 基于 GSM8K 和 MATH 种子，合成并整理了一批带质量标签的数学样本。
这批数据同时覆盖题目和答案。题目侧先检查一道数学题本身能不能成立，答案侧再检查给定解答是否可靠。按照真实的数据清洗流程，题目如果已经无解或条件冲突，后面的答案评测就没有意义。只有题目先通过检查，才适合继续看答案写得对不对。
对应到 benchmark 里，MathDebugger 把评测拆成四个任务。
评测任务
输入内容
模型需要输出
题目正确性检测
数学题目
题目正确或题目错误
题目错误类型分类
有错误的数学题目
表达错误、条件缺失、条件矛盾或不现实设定
答案正确性检测
数学题目和对应答案
答案正确或答案错误
答案错误类型分类
数学题目和有错误的答案
逻辑错误、计算错误或表达错误
前两个任务检查问题。它们判断题目本身是否成立，再进一步分类题目错误。后两个任务检查回答。它们判断给定答案是否可靠，再进一步分类答案错误。这样一来，MathDebugger 测的是模型能不能完成过滤、定位和修复前的诊断，单次解题分数退到了背景里。
MathDebugger 采用两个难度层级。SIMPLE 来自 GSM8K seed，CHALLENGING 来自 MATH seed。这样做的好处是，数据集既保留小学和初中风格的文字应用题，也覆盖更具挑战性的竞赛数学题。
数据分布设计方面。题目数据在正确与错误之间保持平衡，四类题目错误也保持平衡。答案数据则更接近自然分布，错误类型并不均匀。比如在 610 条错误答案中，logic error 有 314 条，computing error 有 232 条，expression error 有 64 条。
标签质量方面做了专门控制。实验使用 STEM 背景标注者和复核者进行多轮检查，并采用独立标注与专家复核。错误类型层面的 Fleiss’ κ 达到 0.69 到 0.91。这个数字说明，细粒度错误类型经过了一致性检验。
评测协议方面。官方 evaluator 尽量减少比较时的歧义。Binary 任务使用 Accuracy 和 F1，Type 任务使用 Macro F1，无法解析的输出会进入 Other 类别。这样一来，模型答错和模型无法按要求回答，会被清楚地区分。
2 七类错误：题目侧和答案侧分别怎么标
MathDebugger 针对题目和答案定义了不同的错误标签，题目侧的错误来自合成数据中常见的题干缺陷。
错误类型
含义
典型问题
Expression error
表达、术语或符号让题目难以理解
把数量、单位或对象写混
Lack of conditions
缺少求解所需信息
问剩余数量，却没有给出转移数量
Contradictions
条件互相冲突
总数、个体数量和约束不能同时成立
Unrealistic
设定违反现实约束
半个人、负边长、非整数学生数
这四类错误的共同点是，题目看起来都有数学外壳。它们通常已经是有完整外观的数学文本。很多情况下，模型必须先理解题目要表达什么，再判断它有没有足够条件，条件之间能不能同时成立，设定是否符合现实。
答案侧的问题更接近模型生成结果的质量检查。
错误类型
含义
典型问题
Logic error
方法或推理路径错误
公式选错、条件使用错误、步骤不可行
Computing error
计算过程出错
算术、代数变形或近似错误
Expression error
表述不完整或无法形成有效答案
只说会帮忙，没有真正作答
在真实训练数据里，一个答案的最终数值可能碰巧正确，中间推理却是错的。也可能推理方向正确，但某一步计算出了问题。只看最后结果，会漏掉这些训练风险。MathDebugger 把答案当作一条推理轨迹来验，这让它更适合评估 reward model、LLM judge 和数据清洗系统。
3 实验结果：会做题和会验题是两种能力
MathDebugger 的实验结果有一个直接结论：模型的解题能力很强，但它对数学数据质量的验证能力没有同步变强，会做题和会验题对模型来说是两种能力，这个差距可以称为 solving versus verifying gap。
SIMPLE split 结果显示，Question detection 的高分模型可以达到 70 多分，Answer detection 也能达到 80 左右。但到了 Answer type，最好的 Macro F1 仍然在 55 左右。也就是说，判断答案有没有错已经不容易，进一步判断错在哪里更难。
任务
观察
Question detection
Claude 3.5、GPT-o4-mini、GPT-o1、Qwen2.5-72B、DeepSeek-R1 位于前列
Question type
GPT-4o、Qwen2.5-72B、GPT-o1、LLaMA-3.3-70B 等表现较好
Answer detection
Qwen2.5-72B、Qwen2.5-7B、GPT-4o 等位于前列
Answer type
最好结果仍接近 55 Macro F1
因此，数学验证能力并没有随着解题能力自动饱和。此外实验还观察到，经过数学微调的模型、擅长长链推理的模型在验证任务上并不稳定优于通用模型。能把题做出来，不代表能判断题目和答案是否可靠。
4 从诊断到矫正：错误标签是有效监督信号
精细化检测的意义在于，精准定位错误，然后定向解决它。
实验发现，当把真实错误类型提供给模型时，GPT-4o 和 DeepSeek-R1 的纠错准确率都会稳定提升。提升最明显的是条件缺失和条件矛盾这类结构性错误。比如 Lack of Conditions 上，GPT-4o 从 49.2% 提升到 53.9%，DeepSeek-R1 从 52.1% 提升到 55.6%。Contradictions 上，两类模型也都有 2.1 个百分点左右的提升。
场景
最大增益
Missing conditions · GPT-4o
+4.7 percentage points
Missing conditions · DeepSeek-R1
+3.5 percentage points
Contradictions · GPT-4o
+2.1 percentage points
Computing errors · both
+1.8 percentage points
这也有效证明了错误标签是一种可以直接参与修复的监督信号。对于合成数学数据来说，发现错误只是第一步。更重要的是把错误描述到足够具体，让后续模型知道该修改哪个环节。
随着合成数据规模越来越大，对数据质量的把控更加不能只依赖抽样检查和事后修补。数学数据一旦进入训练流程，错误就不再只是单条样本的问题，它可能变成模型反复学习的推理习惯。MathDebugger 的价值也在于此——把题目是否成立、答案是否可靠、错误能否定位、修复是否有效，变成一组可以持续评测、可量化的任务。
只有当模型能够识别条件冲突、定位推理偏差等错误，并借助错误标签修正答案，数学领域的合成数据才真正从“数量堆砌”走向“质量可控”。
关于作者
梁昊
北京大学大数据科学研究中心博士，曾连续两年获北京大学校长奖学金，第一作者发表 10+篇 CCF-A 论文/期刊。主导 Data-Centric AI 系列开源项目设计开发，项目累计获得上万 GitHub Star，其中 DataFlow 项目荣获 ICML SeePhy 比赛冠军，智源 LIC 挑战赛冠军。同时带领团队负责 Camel，LLaMAFactory 项目的数据模块设计开发，分别获得 17k+和 74k+ stars。
北京大学 DCAI 团队
专注于大模型数据系统研究与 Data-Centric AI 基础设施建设，开源 DataFlow、DataFlex、One-Eval、3AGameFactory、OpenWorldLib 等多个项目。
开源项目：
DataFlow (7.9k+ Stars) ：一站式 LLM 训练数据准备系统 https://github.com/OpenDCAI/DataFlow
DataFlex：LLM 动态数据训练框架 https://github.com/OpenDCAI/DataFlex
DataMind：Agentic 范式的推理时数据检索框架 https://github.com/OpenDCAI/DataMind
One-Eval：基于 Agent 的自动化大型语言模型评估框架 https://github.com/OpenDCAI/One-Eval
OpenWorldLib：统一世界模型的通用推理与交互框架 https://github.com/OpenDCAI/OpenWorldLib
3AGameFactory：3A 游戏生成 skill 与资产框架 https://github.com/OpenDCAI/GameFactory-3A
更多开源项目可查看 https://github.com/OpenDCAI