数学推理大模型的训练、评估与应用实践

一、问题背景

数学推理是检验语言模型逻辑能力的典型任务。与开放域问答不同，数学题的答案通常可以验证：结果是否正确、推导步骤是否严谨、中间变换是否合法。这一特点让数学场景成为衡量模型推理能力、并推动训练方法改进的常用试验场。

在工程实践中，开发者通常会遇到三类问题：

• 通用模型在多步推导中容易出现计算错误或跳步；
• 公开评测分数与真实业务题目的表现存在差距；
• 教学、科研、金融计算等场景对可解释性和格式稳定性要求高。

本文不围绕某一具体产品展开，而是讨论这类系统的通用技术路线：数据、训练、评估、推理部署四个环节各自的关键决策。

二、数据构建：数量与质量同样关键

数学推理数据可分为三类：题目与标准答案、带有完整推导过程的解答、形式化或半形式化的证明。训练语料通常要同时覆盖三类，否则模型容易只学会“给出答案”，而不会“说明过程”。

2.1 语料来源与筛选

常见来源包括：

• 教材、习题册和竞赛题库（需确认版权与授权）；
• 网页中的数学论坛、问答社区与百科条目；
• 可程序化生成的合成题目，例如按模板生成的代数变换题。

筛选时可以采用多级过滤：

1. 去重：对题目文本做规范化后计算哈希或近似相似度，去除重复样本。
2. 语言与格式过滤：删除乱码、公式缺失或截断的文本。
3. 答案一致性校验：若题目能由程序计算出答案，则比对标注答案与计算结果。
4. 难度分层：按解题步数或正确率划分难度，保证训练分布覆盖从基础到竞赛级别的题目。

2.2 公式与符号的表示

数学文本含有大量上下标、分式和特殊符号。若直接按普通文本切分，公式会被拆散，模型难以学到结构关系。推荐做法如下：

• 保留公式的原始标记，不做全角半角转换；
• 对公式块使用独立分隔符，避免与自然语言混淆；
• 在分词词表中加入常用数学符号，减少符号被切碎的情况。

预处理流程示意：

for sample in corpus:
    text = normalize_unicode(sample.text)
    text = protect_formula_blocks(text)   # 保护公式块不被切分
    if not passes_quality_filter(text):
        continue
    if sample.has_answer and not verify_answer(sample):
        continue
    write(text)

三、训练策略：从语言能力到推理能力

3.1 继续预训练

在通用基座模型上，用大规模数学相关语料做继续预训练，是提升数学能力最直接的方法。关键在于控制数学语料的比例。比例过低，效果不明显；比例过高，通用语言能力可能下降。实践中通常会混入一定比例的通用语料，并在验证集上同时监控数学指标和通用指标。

3.2 有监督微调

模型需要输出可读的解题过程，才能服务教学和审核场景。有监督微调样本应满足以下要求：

• 步骤清晰，每一步可以被单独检查；
• 最终答案位于固定位置，便于程序抽取；
• 同一题目可保留多种解法，帮助模型泛化到不同思路。

3.3 基于结果反馈的强化学习

对于答案可验证的题目，可以把“最终答案是否正确”作为奖励信号，用强化学习优化模型的解题策略。常见做法是对同一题目采样多条解答，根据组内相对得分更新策略，从而省去单独训练价值模型的开销。该方法的前提是奖励函数足够可靠。否则模型可能学会猜测答案，或利用输出格式的漏洞拿分。

训练时应注意以下几点：

• 对格式错误给予明确惩罚，避免模型为了得分而省略推导；
• 定期抽样人工检查，确认过程与结论一致；
• 使用 KL 约束或等效的正则项，限制策略偏离初始模型过远。

四、评估体系：分数背后的含义

4.1 指标选择

数学推理评估通常包含以下指标：

• 准确率：最终答案与标准答案一致的比例；
• 过程正确率：由人工或更强的评审模型对步骤逐条判定；
• 稳定性：同一题目多次采样的结果一致程度；
• 鲁棒性：题目更换数字或改写表述后，表现的变化幅度。

只看准确率容易掩盖问题。例如，模型可能依靠记忆公开题目取得高分，而换一组数字就失效。

4.2 防止数据污染

评测题目若与训练语料重叠，分数会虚高。建议在训练前对评测题目做精确匹配与近似匹配检查，并保留一份不对外公开的私有评测集，仅用于最终验证。

4.3 答案抽取示例

def extract_answer(output: str) -> str | None:
    # 约定模型在输出末尾使用固定格式给出答案
    marker = "最终答案："
    if marker not in output:
        return None
    return output.split(marker)[-1].strip()
def is_correct(pred, gold):
    return normalize_math(pred) == normalize_math(gold)

normalize_math 需要处理分数化简、等价表达式和单位差异。简单的字符串比较会低估模型的真实能力，也会误判正确答案。

五、推理与部署

5.1 输出模式

根据场景，可以设计两种输出模式：

• 简洁模式：只输出答案和关键步骤，适合批量判题；
• 详细模式：逐步展开推导，适合教学辅导。

两种模式可以通过系统指令或输入参数切换，不必为每种场景部署一套模型。

5.2 与计算模块协作

纯语言推理在大数运算和符号化简上容易出错。一种通用做法是让模型生成可执行的计算步骤，由独立的计算模块完成数值验证。执行模型生成的代码时，必须放在隔离环境中运行，并限制执行时间、内存和网络权限。

5.3 工程落地要点

• 延迟：多步推理的输出较长，可采用流式返回，让用户尽早看到中间步骤；
• 成本：简单题目路由到较小的模型，难题再升级到大模型；
• 日志：记录题目、输出与校验结果，并对个人信息脱敏；
• 容错：为答案抽取失败、超时和格式错误设置明确的降级策略。

六、典型应用场景

1. 作业辅导：生成分步讲解，并标注易错步骤。
2. 试题生成：按难度和知识点批量产出练习题，并自动校验答案。
3. 科研计算辅助：检查推导中的代数变换，对可疑步骤给出提示。
4. 金融与工程计算：对公式代入结果做复核，最终结论仍需人工确认。

在高风险场景中，模型输出只能作为辅助参考，关键结论必须经过独立验证。