把计算器拿走让 50 个 LLM 直接做算术题再把得分排成榜。这类评测听起来不像大模型评测该有的样子但它恰恰能暴露一个很关键的事实LLM 在语言生成上像模像样可在精确数值计算上很可能连一个普通计算器都不如。这篇文章不打算复述某一次具体榜单的最终排名而是想拆清楚“LLM 算术能力评测”应该怎么做。先解释为什么这个话题值得关注再给出测试集、评分标准、失败模式和后台影响因素的完整设计思路最后落到实际应用既然原始算术不可靠在生产环境里我们应该如何处理数值。如果你正在做 LLM 应用开发或者准备在本地评估一批开源和接口模型这篇内容可以直接当一份评测方案草稿。1. 这个评测真正在测什么原始算术能力与工具辅助能力是两回事1.1 算术能力是 LLM 最容易“高估”的部分在对话里问一个模型“128×37 等于多少”它多半能给出一个看着很像答案的数字。问题在于很多人不会再去按一次计算器验证于是错误就被当作正确答案直接流入了下游。这和“写一段 Python 代码”不同。写代码时模型可以借助语法先验和代码库预测用户最终看到的是运行结果但算术是纯粹的 token 序列生成每一步进位、每一位数字都要求精确。模型没有真正的计算器引擎它只能基于训练时见过的模式去“猜测”结果。所以当评测者把计算器拿走时测的不是“模型能不能做数学”而是“在没有任何外部工具的情况下模型内部到底有没有形成可靠的数值运算表征”。换句话说这是一次能力边界的压力测试。1.2 50 个模型真正有价值的是能力分布而不是排名给 50 个模型排队最没有信息量的就是那个榜首。真正有价值的是不同系列、不同参数规模模型之间的能力分布小模型在哪一类题上完全放弃中等模型在哪一类上开始稳定大模型又是哪些题目上仍然无解。比如很多评测里10 以内加减法几乎都能过两位数乘两位数开始出现不稳定三位数乘三位数快速下降带小数的百分比又会出现一批新的错误。这样的曲线比单纯排名更能指导模型选型。如果某个 7B 模型在简单四则运算上的稳定性和一个 70B 模型差不多那在实际应用中低配部署就多了一个选择。这类细节只有多模型横向评测才看得到。1.3 评测不是为了证明“模型不能算数”把算术评测做成模型吐槽大会价值就浪费了。更值得做的事是把它当作能力基线哪些模型在算术上稳定到可以作为数值子模块哪些模型必须强制搭配工具验证。评测结果应该服务于模型选择、推理配置和系统架构而不是只为了证明“AI 不会做乘法”。我在做模型选型时通常会把算术评测和通用问答评测分开。通用问答分数高只能说明语言能力强算术分数高才能说明数值稳定性有保障。两者用途完全不同。2. 测试集怎么设计题面、难度梯度与评分标准2.1 题面设计不能只丢十个算式一次像样的算术评测至少要覆盖这些类别整数四则运算加减乘除。大数运算超过 15 位的整数。小数与百分数0.37×100、15% 的 80 等。混合表达带括号、带负号、分数转小数。应用题式文本从自然语言里抽取数字并计算。题面写成算式是基础项写成自然语言才会更接近真实使用场景。比如“一个商品原价 288 元打 75 折再减 20 元最终价格是多少”比直接写“288×0.75-20”更容易测出模型在文数字抽取和运算交互上的表现。如果把算式题和文本题混在一起需要把两者分开统计。否则你很难判断某个模型的失败是输在“计算”还是输在“读题”。2.2 难度梯度要按模型规模预判评测集如果全部是简单题结果会出现天花板绝大多数模型都是 90 分以上区分度极低。全部是超高难度题同样没有区分度全都不会。合理做法是分层层级示例题预期表现基础层一位数乘除法、两位数加减多数模型应该高分进阶层两位数乘两位数、三步混合运算只有部分模型稳定挑战层五位数以上乘法、复杂小数、百分比链式运算多数模型可能失败边界层除零、负数小数的舍入、超大数比较主要看模型遇到边界值时的反应每层 10 到 20 题最后按难度加权算总分比直接算平均分更合理。如果总分只看平均分挑战层的权重会太低边界层的风险也完全体现不出来。2.3 评分不能只看最终答案模型输出可能是一整句话也可能只在末尾给出一个数字。评分时要考虑解析从自然语言输出中提取最终数字而不是要求字符串完全相等。容差对小数是否允许近似值对百分数是否统一成小数表示。步骤分如果模型输出了中间推导是否依据中途结果给部分分。格式分如果要求 JSON 输出是否因为格式问题把正确结果判成错。比较好的做法是为每题预设一个数字答案同时定义一个“可接受答案集合”。例如“75%”和“0.75”都算对这样不同描述方式不会误伤分数。2.4 采样次数和温度决定排名的稳定性同一个模型同一个问题把 temperature 从 0 调到 1可能得到完全不同的答案。评测时要确定固定温度学习类评测通常用 0.2 或 0重复运行更接近。多次采样每个问题跑 3 到 5 次按通过率计算稳定分。设置最大 token防止模型在长推演中途被截断。如果一篇评测没有说明采样次数和温度它的排名基本只能代表一次随机结果。我一般会建议至少跑 3 次用“正确率 稳定率”两个维度一起报告。3. 算术评测里最常翻车的五类题目3.1 多位数乘法步数越多进位越容易出错两位数乘两位数模型往往还能生成正确步骤。位数一旦拉到三位数乘三位数中间过程就很容易在某一步进位时错一位。看输出时经常能发现模型把 137×258 算成 35236而实际答案是 35346只差了最后一步。这类错误不是原理性问题模型知道规则但在 token 序列生成时无法保持足够长的精度。这也是为什么“模型的解释看起来都对但结果错了”非常常见。遇到这种情况不要指望换一种提示词就能彻底解决更稳妥的是让模型把算式交给工具执行。3.2 大数的比较和读写超过 12 位的数字对模型来说已经接近极限。用“123456789012 123456789021”这样的题去测很多模型会出错因为它并不是真的在做数值比较而是在做文本序列比较尾数靠后时顺序并不稳定。如果业务里有身份证号、订单号、流水号这类长数字就不要指望模型直接判断大小。先转成整数再比较或者交给代码处理。这个坑在真实项目里特别容易爆因为长数字看起来确实像数字。3.3 十进制和小数容易在格式上翻车小数计算中模型常犯的错误有把 1.5×100 写成 150.0但被当成字符串比较时和 150 判不相等。把 0.70.3 算成 1.0但答案要求“1”时解析出错。百分数与小数转换时多乘或少乘 100。这不是模型计算能力的问题而是输出规范的问题。评测脚本里要做规范化和容差处理否则真实能力的差异会被格式噪声淹没。如果你的应用要求输出固定精度小数必须在提示词里明确写明不能只靠模型默认习惯。3.4 百分比和比例语义越复杂错得越隐蔽百分比题看起来简单但一旦加入上下文字段就成了“自然语言理解 抽取 运算”的组合题。比如“某商品原价 320 元先涨价 10%再降价 10%最终价格是多少”很多人以为最后是 320 元实际是 316.8 元。这类题模型能不能识别“先涨后降不能简单抵消”测的是对运算语义的理解而不仅是计算精度。这种错误比单纯进位出错更难排查因为它出现在模型已经正确理解题意的前提之下。3.5 除法和边界用例除零直接报错小数除法无限循环时模型自己选择保留几位小数不同模型差异很大负数除以小数又会出现符号错误。这些题目不应该被归为常规算术而是防御测试。如果模型要用在自动填单、财务汇总这类场景必须把边界用例单独写进测试集。否则生产环境里最容易出事故的恰恰是这些低频但致命的情况。评测时不要因为这类题占比低就忽略实际风险往往是它们的几倍。4. 别忽视推理后台精度、量化和推理模式如何改分4.1 FP16、FP32、BF16 与算术评测的关系经常有人讨论 fp16、fp32、bf16 精度问题。很多人在跑模型时会遇到困惑我用同一个模型为什么换了一台机器或换了一个推理后端结果就不一样了在算术任务里权重和激活值的数值精度会在极少数情况下影响输出。如果开发环境用 FP32 推理生产环境把量化压到 4bit某些原本在小数计算和边界值上就能通过的题目可能因为精度损失而失败。不过现代推理框架通常会在关键层保留更高精度所以影响更多体现在边缘样本而不是全部题目。评测模型时最好固定推理精度。不要用 A 环境跑出的分数直接和 B 环境的分数对比尤其在上榜的时候。如果你在做本地模型选型想用低精度模式跑可以选一批算术题做回归测试观察量化前后分数有没有明显下降。4.2 量化低配部署前必须验证低配环境部署模型量化几乎是必经之路。原来用 Float16 权重跑量化到 8bit 或 4bit 后内存占用下降生成速度可能更快但数值稳定性也会打折扣。我做模型选型时会把“量化前/量化后同一套算术测试”作为固定流程。只要算术分数不出现明显下滑再谈部署。否则模型参数再小也是负担。4.3 直接输出、思维链和自洽性三种模式的分数差异很大同样一道两位乘法题直接让模型“只给答案”可能给错。让模型“先逐步计算再给答案”正确率往往上升。如果再做多次采样选多数一致的结果也就是自洽性正确率还能再上一层。这是因为思维链给模型创造了“先占位再补数字”的中间空间把一次长序列预测拆成了多个短步骤。自洽性则是把随机性利用起来用投票降低单次错误。但这不代表所有模型都适合长思维链。有的小模型在长推理过程中反而更容易跑偏一步错步步错。评测时要同时测“直接回答”和“带推导回答”两种模式不能只挑对模型有利的一种。你最后选择哪种推理模式取决于你的真实使用场景。4.4 本地推理后端也会影响结果如果你是在本地用推理服务跑模型还要关注后端差异。常见的有 llama.cpp、Ollama、LM Studio 这类本地推理方案还有厂商提供的 API 服务。它们的采样参数、量化内核、运行精度都不完全一样。对于同一个开源模型用同一份测试题分别跑两种后端分数可能差一两个点。这不是模型能力变了而是推理栈变了。做横向评测时最好所有本地模型使用同一套推理后端API 模型单独分组统计避免把后端差异误写成模型差异。5. 提示设计对分数的干扰比很多人想象得大5.1 “只给答案”和“先解释再给答案”是两个不同的测试如果把多个模型放到同一份对比里提示语必须统一。比如A 组题面“37 × 86 ?只输出结果” B 组题面“请分步计算 37×86并把最终结果写在一行。”这两种提示测的已经不是同一种能力。前者测 token 序列直接生成后者测过程推演和结果收束。把它们混在同一张榜里排名就会失真。所以评测前要固定一套“题面模板 辅助说明”所有模型都用同一版。不要为了引导某个模型发挥更好而临时改题面。5.2 系统提示里的角色设定也会改变结果“你是一个严格计算的数学引擎”和“你是一个友好的助手请回答下面问题”对模型行为的影响肉眼可见。前者会让模型更克制、更倾向于精简输出后者可能会让模型多解释反而提高产生中间错误的机会。如果要复现评测需要在文档里说明系统提示的完整内容。否则分数只能在你的本地环境里复现换个人换个提示词结果完全不同。5.3 API 模型和本地模型的环境差异API 模型通常是厂商已经调好的推理服务可配置参数少性能相对稳定。本地模型则受推理框架、量化级别、上下文长度、批次大小和并行数影响。评测时要注意本地模型跑批量的并发数别开太大否则显存和内存不够会触发假错误。使用相同的上下文长度不同上下文长度会影响模型对问题格式的处理。同一模型在不同后端跑结果要记录后端版本和量化参数。这也是为什么“LLM 应用需要编排框架”会成为热门话题。在实际系统里提示模板、模型路由、工具调用和结果校验都要由框架统一管理否则同样的输入在不同环境里会有波动极大的输出。6. 如果自己复现这套 50 模型算术评测可以按这个流程6.1 第一步准备测试集和黄金答案先写一个 JSON 格式的题目集至少包含 50 到 100 题[ { id: mul-001, type: integer_multiplication, difficulty: easy, question: 37 * 86 ?, answers: [3182] }, { id: pct-002, type: percentage, difficulty: medium, question: 一件原价320元的商品先涨价10%再降价10%最终价格是多少, answers: [316.8, 316.80元] } ]这类文件要生成成固定形式再准备答案解析函数。注意不要用公式再生成一遍字符串答案否则容易和题面信息耦合。题目集要单独保存一份基线版本。后续调整题面或评分规则时都要沿用同一个版本重新跑不能在旧分数上叠加新规则。6.2 第二步统一调用脚本如果模型是 HTTP 接口就写一个统一的调用函数记录请求参数、响应耗时和输出内容。不要每换一个模型就手写一遍提示词那样很容易把参数量带偏。def run_single(api_url, payload, timeout60): resp requests.post(api_url, jsonpayload, timeouttimeout) return resp.json()核心参数写进配置模型名、温度、最大 token、采样次数、系统提示。这些参数最好都进一个配置文件不要在脚本里散落。否则跑完后想复盘很难还原当时的条件。6.3 第三步解析输出与评分模型输出可能是文本、JSON 或 Markdown。评分前要抽取出最终数字并做归一化去掉货币符号、百分号、单位。把科学计数法转成标准浮点或小数。支持百分数和分数两种写法。如果答案带容差就先用 float 比较。如果一道题 3 次采样中只有 1 次对不能叫“做对”应该记为“不稳定”。最终报告建议用“正确率”和“稳定率”两个指标。6.4 第四步日志、重试与并发控制批量评测最难受的不是跑得慢而是跑到一半某个服务超时。为了不浪费前面积累的日志需要做每道题完成后立即把原始响应写到本地 JSONL。超时重试最多 2 次。并发不要一上来就开满先用 4 个并发把小批量跑通再逐步增加。中断后能从断点继续而不是重新跑全部题目。日志和原始响应记录得越详细后续排查越省事。如果某个模型在某个题上得分异常低你能回看它的原始输出判断是模型算错还是解析脚本把正确结果当成了错误。6.5 第五步统计与可视化最后按难度分层统计输出类似表格的数据模型基础层正确率进阶层正确率挑战层正确率稳定率这样就能快速看出模型能力在哪里断裂而不是整体平均分掩盖一切。重点看两层挑战层和边界层。这两层才是真实业务里最容易出问题的区间。7. 评测结果落到应用里应该如何用7.1 算数不是模型的核心能力要配上工具评测完 50 个模型最可能得到的结论是没有一个模型能在所有题目上做到百分百可靠尤其是多位数乘法和复杂文本题。所以生产环境里正确做法不是去挑选“算数最好的模型”而是给模型配一台计算器。比如用 function calling 调用计算器工具或让模型生成 Python 表达式再由代码解释器执行。让模型承担语义抽取和步骤设计把精确计算交给确定性工具。现在很多应用会做 agent 编排本质也是这个思路模型不是所有能力的最终执行者而是调度者。它决定先调哪个工具、再校验哪个结果而不是自己硬算到底。7.2 数值校验层必须存在不管模型算得再好我都不建议让模型直接输出一个需要入库的金额或数量。更稳妥的是在模型后面加一层校验字段类型校验是否数字是否为空。范围校验数值是否在合理区间。交叉校验如果模型同时给出了“原价”“折扣”“最终价”校验最终价是否等于原价乘折扣。重算校验用代码重新计算一次模型生成的表达式。如果校验失败可以让模型重新生成也可以直接走人工兜底。这比相信模型解释要可靠得多。7.3 工具化算术从 function calling 到编排框架当你需要把算术能力注入到真实的 LLM 应用里常见的做法是走工具链路。比如模型识别出“用户需要计算最终价格”然后调一个外部计算函数或者让模型生成 Python 代码由沙箱环境执行后返回结果。Spring AI、MCP、RAG、Agent 这些命名经常一起出现本质上都是为了解决同一个问题模型本身不稳定所以要把语义理解、检索、计算、验证拆成多个可管理的模块。算术这类确定性任务要么封装成工具要么直接由代码执行不要交给模型硬猜。如果你只是做测试也可以先不引入复杂框架直接用函数调用写一个“计算器工具”。等评测跑通再把它接入应用架构。先从最小闭环开始能少踩很多框架坑。7.4 “计算器”应该一直留在工作流里回到最开始那个评测标题把计算器拿走是为了测试模型能力的边界。但在实际产品中我们不应该真的把计算器拿走。工具调用能力、代码解释器、RAG 中的结构化检索这些才是让 LLM 在真实业务里可靠的保障。评测的价值是帮助我们了解模型什么时候会失守并提醒我们在关键节点补上防线。至于“50 个模型谁算术最强”这个排名我更愿意把它理解成一张能力边界图而不是一张可以放心交付的答卷。个人建议是如果你想复现类似的评测先把题面标准、采样次数、推理精度和提示词固定住再跑出基础分数最后一定再看看失败样例会落在哪些题目类型上。单看整体分数容易得到安慰真正决定系统会不会出问题的往往就是那几道失败题。踩过几次之后就会发现多数问题不是模型能力不够而是前置环境和评测设计没有处理干净。