中文数理推理能力对比：模型换个语言做题会不会变笨
英文数学基准(GSM8K、MATH、AIME)的横评已经很成熟,具体数据可参考《LLM 数学推理能力横评》。但一个容易被忽略的问题是:同一道数学题,换成中文表述,模型的准确率是否会变化?对于服务中文用户的应用(客服机器人算价格、教育类产品批改应用题、财务类 Agent 算税费),这个问题比”模型在英文基准上排第几”更贴近实际使用场景。
本文聚焦中文语境下的数理推理表现,不重复英文基准的详细解析,而是回答三个问题:语言切换本身是否会拉低准确率、哪类中文题型最容易让模型翻车、以及工程上怎么规避。
一、为什么要单独测”中文”数理推理
多数头部模型的预训练语料里,英文数学题(尤其是结构化的 GSM8K/MATH 类)占比远高于中文数学题。这带来两个潜在问题:
- 语言层面的分布差异:模型对英文数学题的表述模式(应用题的固定句式、单位换算的表达习惯)更熟悉,中文题里常见的”鸡兔同笼""工程问题""浓度配比”这类古典应用题句式,在训练数据里的密度未必够高
- 推理链条的语言一致性:即使模型能读懂中文题干,它的内部思维链(尤其是开源模型没做强化对齐的)有时会切换成英文推理再翻译回中文作答,这个转换过程本身可能引入错误,例如单位换算或者数字表达(“万""亿”与阿拉伯数字混用)
二、测试设计:把英文基准”翻译”不能说明问题
一个常见误区是直接把 GSM8K 机器翻译成中文再测,这样测出来的其实是”翻译质量对模型的干扰”,而不是”模型本身的中文数理能力”。更合理的测试集应该包含:
| 题型来源 | 特点 | 考察重点 |
|---|---|---|
| 中文原生应用题(小学奥数、中考真题) | 母语者撰写,无翻译腔 | 真实中文表达下的理解准确率 |
| 人工翻译对照题(同一题中英各一版) | 内容完全一致,仅语言不同 | 严格控制变量,测语言本身的影响 |
| 中文特有题型(鸡兔同笼、盈亏问题、年龄问题) | 英文基准里少见的句式结构 | 模型对非西方数学传统表述的适应度 |
| 单位与数字表达混淆题(万/亿、分数与百分比互换) | 中文数字体系特有的坑 | 数字解析准确率 |
第二类”人工翻译对照题”是最能说明问题的——同一道题,中英文版本如果准确率有显著差距,基本可以确认是语言本身在起作用,而不是题目难度差异。
三、观察到的共性现象
综合多组对照测试(以下为多次测试的普遍趋势,具体数值请以自行复现的测试为准,不代表官方评测结果):
- 纯计算题(无复杂应用场景)中英文差距很小,因为最终推理主要靠数字和符号,语言外壳的影响有限
- 应用题(需要先理解场景再列式)中文版本的错误率普遍略高于英文对照版,尤其是题干较长、包含多个从句的题目,模型容易在提取变量关系这一步出错,而不是计算本身出错
- 中文特有题型(鸡兔同笼类)的表现两极分化明显:头部模型(经过充分中文语料训练+强化对齐)基本能正确识别这是”二元一次方程组”问题并正确列式;部分以英文为主训练、中文只是多语言能力附带覆盖的模型,有时会误判题目类型,用错误的解法框架去套
- 数字表达混淆是最容易被忽视的错误来源:“三千五百万”这类中文数字表达,在思维链较长、中间要做多步运算时,偶尔会被模型误算一个数量级,这类错误在最终答案校验时容易被发现,但如果只看推理过程是否”看起来合理”容易被漏检
四、工程规避:不改模型,怎么把中文数理场景做稳
如果产品必须处理中文数理场景(报价计算、应用题批改、财务估算),又不想等模型本身的中文能力进一步提升,可以从工程层面做几件事:
- 强制结构化中间步骤:要求模型先把题干里的数字和关系提取成结构化 JSON(变量名、数值、单位、关系表达式),再基于结构化数据做计算,而不是让模型直接从自然语言一步跳到最终答案。这样即使中文理解阶段有轻微偏差,也能在提取步骤做人工或规则校验
- 数字规范化前置:在喂给模型之前,用规则或简单模型把”三千五百万""3.5 千万""35000000”统一转成阿拉伯数字表示,减少模型在数字解析上的负担,这对涉及”万/亿”的财务、地产类场景尤其有效
- 关键计算走代码执行而非纯文本推理:如果模型支持工具调用(可参考《Claude Tool Use 最佳实践与陷阱》),对最终数值计算部分强制走代码解释器工具,只用模型做题意理解和公式列写,避免”看起来推理正确但最后一步算错”这类问题
- 中英文双跑对照做异常检测:对高风险场景(如金额计算),可以把中文题干和其翻译版本分别请求模型,两个答案不一致时触发人工复核——这是用推理成本换准确率的取舍,不适合所有场景,但对金融、医疗等容错率低的应用值得投入
五、和通用中文能力评测的关系
中文数理推理表现和模型的通用中文理解能力(《中文指令遵循能力评测指南》覆盖的维度)有相关性但不完全重合——一个中文指令遵循很好的模型,不代表它在中文应用题的变量提取上同样可靠,因为后者需要额外的符号化转换能力。选型时如果业务强依赖中文数理场景,建议单独针对这个维度做测试,不能用通用中文能力评测的结果直接外推。