尧图网站建设 
在讨论大语言模型LLM的数学能力时很多人会得到一个矛盾印象它既能解方程、写证明思路又会在三位数乘法上算错甚至同一个问题换一种问法就得到不同答案。这个矛盾并不是模型“笨”而是数学任务本身不是一个能力而是多种能力叠加的结果。LLM在公式记忆、语言理解、模式匹配和步骤生成上有优势在精确计算、长链推理、严格证明上依然有明确边界。这篇文章会围绕“LLM擅长什么样的数学”展开先拆解数学任务类型再分析原理然后提供一套最小评测脚本最后给出常见问题排查和工程实践建议。这样你可以知道什么时候可以信任模型的结果什么时候必须引入工具或人工复核。1. 先看清问题LLM的数学能力不是“行”或“不行”而是分任务类型的1.1 为什么需要单独讨论LLM的数学能力在大模型的应用落地中数学能力往往是考核模型逻辑水平的重要窗口。一个能通过代码生成测试的模型不一定能稳定处理数学应用题一个能写常见脚本的模型可能在分数化简上出现低级错误。这不是个别模型的问题而是语言模型学习和输出机制带来的普遍现象。数学任务和自然语言任务最大的区别在于自然语言允许表达模糊和冗余而数学有严格的符号、运算规则和唯一结果。LLM本质上是一个基于概率的文本生成系统它并不像计算器那样执行算术也不像符号计算系统那样构造表达式。因此把数学任务看作一个统一的“会不会”问题是不准确的应该拆成多个子能力来看。在开发实际功能时这个区别直接影响技术选型。比如你做一个智能作业批改系统如果只关心“模型能否输出正确答案”那么遇到大数乘除、单位换算、含参讨论时就会出现大量漏判。相反如果你把题目先分类为“简单计算”“复杂计算”“应用题建模”“证明题思路”再分别设计处理流程系统的稳定性和可维护性都会好很多。1.2 按任务形态拆解数学能力实际使用中可以把LLM的数学任务拆成几类基本形态数值计算包括加减乘除、乘方、开方、取模等。这类任务最依赖精确执行LLM在位数少、结构简单时表现好在位数多、进位复杂时容易出错。代数与符号操作解方程、化简表达式、展开多项式。LLM擅长处理常规形式因为训练数据里大量出现过但对符号约束严格的题目容易“手滑”。应用题与文字题把自然语言场景转成数学表达式。LLM对语言理解的强项在这里能发挥关键在于能否正确建模。几何与空间推理涉及图形想象、辅助线、空间关系。LLM没有视觉输入时只能依赖文字描述能力不稳定。概率与统计常规分布、条件概率、期望计算LLM能处理经典问题但问题一旦需要精确积分或复杂事件枚举容易出错。逻辑推理与证明数学归纳法、反证法、形式化证明。LLM能生成看起来合理的推理链但很难保证每一步严格有效。这种拆解的意义在于同一模型在不同形态上的表现差异很大。后续的评测和工程选型都应该以子任务为单位做评估而不是用一个笼统的“数学准确率”来概括。1.3 常见评测基准与能力分布研究社区和工业界通常用公开评测集来衡量LLM的数学能力。常见的基准包括GSM8K、MATH、TheoremQA等。了解这些基准有助于判断一个模型在通用数学场景中的大致水平。评测集题目来源典型考察点整体难度GSM8K小学到初中难度的数学应用题自然语言理解、多步算术中等MATH高中数学竞赛题目覆盖代数、几何、概率、数论等抽象推理、多步符号操作较高TheoremQA定理推导与科学计算形式化推理、领域知识高AIME美国数学邀请赛题目竞赛思维、复杂推理高SVAMP带干扰信息的应用题变体建模能力、抗干扰中等需要说明的是不同模型版本在这些基准上的公开成绩变化很快而且榜单分数受提示词、采样次数、后处理方式影响很大。这里不列具体分数只给一个常见结论LLM在GSM8K这类“自然语言应用题”上表现相对好在MATH、TheoremQA这类“抽象竞赛题”上稳定性明显下降。如果你的项目需要处理高难度数学必须用与你业务接近的题目做私有评测而不是只看公开榜单。1.4 擅长与不擅长的任务对比结合实践观察可以画一张更直白的能力对比表。这张表描述的是“大多数通用模型”的表现不代表所有模型也不代表某个版本的绝对结论。任务类型典型题目模型常见表现信任建议简单数值计算12 25 × 3通常正确格式稳定可直接使用大数计算123456789 × 987654321容易算出错误结果且过程看起来自信必须用工具常规代数解 2x 5 17大概率正确步骤完整可人工复核复杂代数带参数的三元方程组可能在消元或代入时出错建议用符号计算工具常规应用题商品打折、行程问题表现较好但单位或条件可能漏掉需要检查建模几何证明证明三角形全等能给出常见思路但步骤跳步或错误必须人工核验概率计算条件概率或组合计数经典题表现尚可复杂题不稳定建议结合公式计算严格证明数学归纳法或反证法结构像但逻辑间隙常见不建议直接信任这张表的目的是帮助你在接到一个数学需求时快速判断该用LLM直接生成答案还是把它当作“草稿生成器”再配合其他工具。实际项目中最稳妥的做法永远是“模型给思路工具给结果”。2. 从模型原理上理解为什么LLM在数学上“偏科”2.1 语言模型做数学的本质是下一词预测LLM的训练目标通常是最大化条件概率给定前文预测下一个Token。这个机制决定了模型在回答数学题时并不是“先计算再写答案”而是一边生成一边决定下一个输出什么。它的所有知识、规则、模式和陷阱都编码在参数和上下文里。这意味着模型对数学的“正确性”并不像人脑那样建立在逻辑闭环上而是建立在“这段序列在过去训练数据中出现的可能性”上。当一道题的解题步骤在训练数据中出现频率高时模型能稳定生成当题目需要临时计算或组合新知识时模型只能靠概率推断出错风险自然上升。一个直观的例子是你问“圆的面积公式是什么”模型能很快写出πr²。因为它见过无数遍。但你问“半径为7.3米的圆形花坛铺满草皮需要多少钱草皮每平方米15.8元”模型需要把公式、乘法、金额换算串起来这时它表现出的就不再是“记忆”能力而是“临时计算”能力后者恰恰是它的弱项。2.2 Token化对数字计算的影响LLM处理的是Token而不是字符或完整的数。当前主流分词器会把数字拆成不规则的Token典型的例子是12345可能被拆成多个Token导致模型看不到完整的十进制结构。这种影响体现在几个方面大数比较时模型可能数错位数。进位和借位需要通过Token间的模式学习而不是真正执行位运算。个位、十位的“对齐”问题容易被忽略。分数、小数的精度损失因为分数被当作文本片段处理。所以在工程上不要让LLM直接做高精度数值计算。这是最常被忽视的坑之一。很多时候模型在“1.10”和“1.1”之间犹豫或者在“1000000”的零的个数上出错都不是因为它没有数学知识而是因为它从Token序列中无法直观把握数值结构。2.3 训练数据分布决定擅长面数学能力高度依赖训练数据覆盖度。如果训练语料中大量包含K12数学题、常见竞赛题、编程题里的算法描述那么模型对这些题型的模式非常熟悉表现自然更好。反过来如果某个数学分支在语料中出现频率低比如组合数学中的冷门定理或需要特定符号体系的形式化证明模型就只能勉强拼接。实际项目里会遇到一个现象同样的模型解一元二次方程很稳定但解含参不等式时经常漏讨论端点。这很可能不是模型“逻辑不好”而是训练数据里这类带讨论的完整例题不足模型缺少可参考的分布。这也解释了为什么用“few-shot”可以改善数学表现。你在提示词里给出几个相似例题后模型实际上是在调整输出分布让生成结果更靠近已有的示例模式而不是真正学会了一套新的推导规则。2.4 多步推理与上下文长度的影响数学题往往需要多个推理步骤且后一步依赖前一步的结果。LLM虽然可以生成很长的内容但每一步生成的误差都会累积。步骤越多中途“跑偏”的概率越高。另外上下文窗口长度会影响注意力的分配。当输入中包含大量条件、表格或历史对话时模型可能忽略关键条件或者把较早的错误步骤带到后面。这就是为什么给LLM喂“又长又杂”的数学题时效果常常比短题差。在工程上可以通过“减少无关信息”来缓解。如果题目本身有冗余条件可以先用一个抽取步骤把关键信息提取出来再让LLM基于精简信息解题。这个方法比单纯增加“请仔细思考”要有效得多。2.5 LLM是记忆器还是推理器两种现象的边界如果把模型在不同数学题上的表现记录下来会发现它更接近一个“高能力记忆器弱能力推理器”。对于训练语料中高频出现的题目模型通过记忆模式就能输出正确结果对于需要组合多种概念的全新题目模型缺乏真正的符号计算和逻辑校验机制。一个明显的证据是当题目只有细微变化比如把“甲比乙快”改成“甲比乙慢”模型可能仍然沿用原来的代数式说明它没有真正“验算”。这提醒我们不能把LLM在数学上的成功泛化到所有新问题上。所以在设计系统时要特别注意“题目变体”。如果模型在某类题上得分很高不要认为它掌握了这类题的解法还要用改变条件顺序、增加干扰项、交换数值等方式做压力测试看看结果是否仍然稳定。3. 用一次最小评测验证你的模型到底擅长什么3.1 评测环境准备Python与模型接入与其听别人说LLM擅长什么不如自己跑一组最小评测。最基础的环境只需要Python和一个模型API。这里以OpenAI兼容接口为例因为很多云服务商和本地推理框架都提供这种协议。先确认Python环境然后安装依赖python -m venv .venv source .venv/bin/activate pip install openai如果你的模型是本地部署并且暴露了OpenAI兼容的/v1/chat/completions接口也可以把base_url指向本地地址。生产环境注意不要把密钥写死在代码里应通过环境变量读取。你还需要确认Python版本在3.9以上因为新版OpenAI SDK对Python版本有要求。3.2 编写最小评测脚本下面这个脚本会逐一发送测试题收集模型的输出。这里不预设具体模型名称你可以根据实际环境修改model和接口地址。import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY, your-api-key), base_urlos.getenv(LLM_API_BASE, https://api.your-provider.com/v1), ) def ask_math(prompt, modelyour-model, temperature0.0): response client.chat.completions.create( modelmodel, messages[ {role: system, content: 你是一个数学助手。请严格分步推理并在最后一行以“答案:”开头给出最终答案。}, {role: user, content: prompt}, ], temperaturetemperature, max_tokens2048, ) return response.choices[0].message.content if __name__ __main__: problems [ (简单算术, 计算 12 25 × 3。), (大数乘除, 计算 123456789 × 987654321。), (一元方程, 解方程 2x 5 17。), (应用题, 一个商店打折原价200元的商品打八折后再减20元最终价格是多少), (几何面积, 半径为5的圆的面积是多少保留两位小数。), (概率, 从1到10中随机取一个数取到偶数的概率是多少), (复杂证明, 证明不存在最大的素数。), ] for label, question in problems: print(f题目: {label}) print(f问题: {question}) result ask_math(question) print(模型输出:) print(result) print( * 50)这段脚本的关键点有三个。第一temperature0.0用于降低生成随机性让结果更可复现。第二在系统提示中要求“分步推理”和“最后一行给出答案”便于后面对结果做规则解析。第三题目要覆盖不同能力维度不能只测算术。3.3 设计一组有区分度的测试题评测题的选取直接决定结论是否可信。建议按照“简单到复杂、常规到反常”的方式设计每组题目至少包含类别测试点题目示例基础算术运算优先级8 2 × 5大数计算多位数乘除982451653 × 1234567方程含参方程解关于x的方程 a x b c应用题多余条件小明有5个苹果、3个梨小红有2个苹果、4个梨他们一共有几个苹果几何单位换算一个长方形长2米宽50厘米面积是多少平方分米概率条件概率袋中有3红2蓝球不放回取两球第二球为蓝且第一球为红的概率证明反证法证明根号2是无理数数论取模与大数计算 2^100 mod 7每组题目都尽量选择一个“容易被语言模型带偏”的版本。例如括号、单位、取模、条件概率这些都是模型常见失分点。3.4 运行结果与判断标准脚本跑完后不要只看“对还是错”要同时看四个方面最终答案解析最后一行“答案:”后的内容判断数值是否正确。推理过程检查每一步是否逻辑连贯有没有把上一步结果抄错。格式规范有没有单位、约等号、符号错误。稳定性同一道题跑3次是否得到一致结果。建议把结果整理成表格例如题目模型输出摘要最终答案是否通过8 2 × 5先算2×510再算81018答案:18通过2^100 mod 7写出幂运算过程后给出4答案:4通过几何面积使用π3.14答案:78.50需确认精度这里不给出固定答案因为模型和版本会变。关键是你要建立一套自己的“通过”标准避免被一个漂亮的解题过程蒙蔽。比如几何面积题如果题目要求保留两位小数那么78.50和78.5是否等价需要你提前定好规则。3.5 关键参数对结果的影响调用模型时几个参数会直接影响数学结果需要重点关注。参数推荐值作用设置错误的表现temperature0.0降低输出随机性同一个问题多次结果不一致top_p1.0或较低控制候选Token范围与temperature叠加导致输出不确定max_tokens1024或2048限制输出长度推理到一半被截断seed固定值部分模型支持可复现结果仍可能波动response_formatjson/text结构化输出难以解析最终答案在评测阶段尽量固定temperature和seed并把max_tokens设置得足够长。否则长题容易中途截断导致你误判模型能力。也要注意有些模型不支持传入seed参数强行传入会报错落地时要根据SDK能力调整。3.6 评测结果怎么解读评测完成后不要急着下“模型行/不行”的结论。建议按“题目类型”汇总通过率然后回答几个问题哪些类型100%通过哪些经常失败失败的原因是计算错误、步骤错误还是理解错误增加提示词后错误率是否明显下降如果加入“请用Python计算”的指令结果是否改善这样得到的结论才具有工程指导意义你可以把高通过率任务交给模型直接处理把低通过率任务设计成“模型工具”的协作流程而不是一刀切地接受或拒绝LLM输出。评测结果必须保留原始输出和版本信息方便后续复现。4. 数学任务中LLM表现不稳定的常见原因与排查路径4.1 现象同一个问题多次结果不同同一道题用相同提示词问三次三个答案都不一样。这在数学场景里非常危险因为用户可能拿到三个看似都合理的答案无法判断哪一个是正确的。可能原因包括temperature没有设置为0或top_p设置过大。模型经过多轮对话后受到历史信息污染。API接入层做了负载均衡不同后端节点或不同量化版本导致差异。提示词里没有强调“分步推理”模型在多次生成时选择不同路径。排查顺序先固定temperature0.0和seed清空会话或每次用新会话确认后端模型版本一致最后再考虑是否要更新提示词。如果多次结果仍然不一致可以增加答案投票机制让模型生成多个候选再用规则或另一个模型选出最一致的结果。4.2 现象过程正确但最终答案错误模型写出了完整的解题步骤但最后汇总答案时写错。这种情况经常出现在小数、分数或大数的写法上。常见原因中间步骤的数值被截断或四舍五入最后汇总用了错误中间值。Token生成过程中模型只“看起来”引用了前面的数实际上输出了不同的数字。输出格式里混入了多余文字导致解析器提取到错误答案。处理建议在提示词中明确要求“最后一行用答案: 数值格式”在代码中从中间步骤提取关键计算结果并单独校验如果必须接受自然语言答案则要走人工复核。还可以让模型在最终答案后追加“请用计算器重新验证”的步骤但这会消耗更多Token需要权衡。4.3 现象复杂题目直接给出错误步骤高难题目上模型常常“一本正经地胡说”。它会编造一个不存在的公式或跳过关键推理步骤。这不是偶然错误而是模型缺乏真正推理的表现。排查时不要把“步骤长”当作“逻辑好”要重点检查每一步是否由前一步推出。是否引入了题目中没有的条件。是否使用了不成立的等价变形。是否有“因为所以”之间的跳跃。如果连续出现这种问题说明当前模型不适合直接回答这类题目要么换更强模型要么把它降级为“提示生成器”让专业工具完成证明或计算。一个可操作的方案是让模型生成“思路要点”再由SymPy或Mathematica验证具体步骤最后人工复核完整证明。4.4 按输入、提示词、模型参数、上下文逐层排查当模型数学答案错误时推荐按下面的链路排查检查输入题目是否完整单位是否明确是否存在歧义。很多人忽略了“2米×50厘米”这种单位混用才是错误源头。检查提示词是否要求逐步推理是否给出输出格式约束是否要求验证答案。检查模型参数temperature、max_tokens、seed是否合适。检查上下文多轮对话中是否残留之前的条件是否被无关内容干扰。检查日志记录每次请求的完整输入输出便于复现。检查工具辅助如果正确率仍然不达标考虑引入外部计算器或代码解释器。检查模型选型同一道题在能力更强的模型上是否通过以判断是提示词问题还是模型能力边界。这条链路的核心思想是“先排除环境问题再评估能力问题”。很多看起来像模型数学能力不足的情况实际上是提示词没有约束好输出格式或是上下文里混入了旧条件。4.5 数学答案错误排查清单排查项检查内容可能结果处理建议输入完整性题目条件是否全部进入提示词漏条件导致误答对比原题和请求体单位一致性是否要求统一单位单位换算错误提示词中显式要求提示词约束是否要求分步思考和结果格式答案格式混乱补充最后一行写答案:温度参数temperature是否大于0输出不稳定固定为0.0上下文污染历史消息是否包含错误前例答案被历史带偏清空上下文或使用独立会话中间值截断生成长度不足推理被切断调大max_tokens工具调用是否允许模型调用计算器依赖模型手算接入计算工具或代码执行器模型版本是否使用一致版本结果漂移统一模型映射这张清单可以直接贴在项目文档里每次排查时逐项对照。建议把清单也做成一个Markdown文件放进仓库让团队成员提交代码时自查。5. 在真实项目中用好LLM数学能力的实践方案5.1 设计原则让LLM做擅长的事把计算交给工具工程上的最优策略不是让LLM把所有数学活都干完而是拆解任务让LLM负责自然语言理解、问题建模、规划解题步骤。把数值计算交给代码解释器、计算器或算术表达式解析器。把符号计算交给SymPy、Mathematica等专用库。把证明逻辑交给人工复核或形式化验证工具。这种“语言模型工具”的混合模式既能利用LLM的理解能力又能规避它的精确计算短板。生产环境中稳定性优先级高于“让模型一步到位”。比如在智能客服里用户问“我有一张满300减100的券商品标价268但是可以叠加8折最后多少钱”正确的流程是让LLM提取出“原价268、打8折、满300减100不满足”这几个关键点然后由代码计算最终价格而不是让LLM直接写答案。5.2 提示词里的“分步思考”该怎么写简单地在提示词里加“请一步一步思考”可能有效但更稳的写法是给出明确的过程约束。推荐示例你是数学解题助手。请按以下要求回答 1. 先用自己的话重新描述题目条件。 2. 列出需要求解的未知量和已知关系。 3. 分步骤推导每一步必须说明用到的公式或规则。 4. 每一步完成后检查上一步的结果。 5. 在最后一行写答案: 最终结果这样做的目的是把模型生成过程拆成可验证的多个点。如果中间某一步出错你可以根据输出定位而不是面对一个黑盒答案。实际项目中还可以要求模型在最后一行输出JSON方便程序解析例如{answer: 18, steps: [...]}。5.3 用外部计算器和代码解释器补足准确率实际项目中最可靠的补充方式是把计算任务交给执行器。例如让模型生成Python表达式然后服务端执行并校验import ast import math def safe_eval_math(expression: str): # 只允许白名单节点避免任意代码执行 allowed (ast.Expression, ast.BinOp, ast.UnaryOp, ast.Constant, ast.Name, ast.Load, ast.Add, ast.Sub, ast.Mult, ast.Div, ast.Pow, ast.Mod) for node in ast.walk(ast.parse(expression)): if not isinstance(node, allowed): raise ValueError(fillegal node: {type(node).__name__}) return eval(expression, {__builtins__: {}}, vars(math)) print(safe_eval_math(123456789 * 987654321))这里用ast白名单限制表达式类型避免把用户输入直接交给eval造成安全隐患。生产环境还要增加超时控制、日志记录和错误捕获不能假设模型生成的表达式总是合法的。如果项目已经有代码解释器或Python运行时可以直接让模型生成完整脚本后再执行。要注意的是模型生成的代码同样可能出错所以必须做结果校验和异常重试。可以设定重试次数比如模型第一次生成的代码执行报错就把报错信息回传给模型让它修正后再次执行。5.4 什么时候该考虑微调或专用模型如果特定数学域的需求非常固定比如公司内部的计算规则、行业公式、特定题型并且通用模型的错误率始终下不来可以考虑微调或选用专用模型。但微调不是万能的。它更适合让模型“熟悉固定格式和规则”而不是给模型“补数学逻辑”。微调前要先积累几百到几千条高质量问答数据并且每一条都要人工审核避免模型学到错误模式。如果不需要改变模型能力只是想提高数学题正确率更轻量的做法是使用更强的基座模型。在推理时增加候选答案采样再用验证器排序。接入外部符号计算工具。构建“模型生成方案代码执行结果”的流程。微调还会带来训练成本、部署成本和维护成本。如果你的问题可以通过工具调用解决优先选择工具而不是微调。5.5 生产环境下的数学能力评测与回归机制只要业务依赖LLM输出数学结果就不能只在开发期测一次。生产环境至少要建立固定评测集从历史问题、错误问题、边界条件中整理一批有代表性的数学题。回归流水线每次更换模型版本、提示词或参数时自动跑一遍评测集。答案校验规则用代码计算期望结果对比LLM输出。线上监控记录模型输出、用户反馈、错误率设置阈值告警。版本回滚如果模型升级后数学能力下降能快速切回旧版本。在CSDN这类技术博客的语境里这一步经常被省略但恰恰是它把“能用”变成“可靠”。一个没有回归机制的数学解答系统很可能在某个周末因为模型服务商更新版本而突然大面积出错而你无法快速定位。5.6 可复用的“数学能力使用决策清单”场景推荐做法简单算式结果唯一LLM直接回答但要固定temperature为0大数计算让LLM生成表达式用代码执行方程求解LLM给出步骤用数学库求解并核对应用题建模LLM负责建模数值计算交给工具概率统计要求列出公式再代入计算几何证明只作为思路生成必须人工核验竞赛级推理不建议依赖通用LLM直接给最终结论教学场景可让LLM分步讲解但答案要脚本校验生产API增加答案解析、异常捕获、日志与告警这张清单可以做成团队知识库里的文档让每个接入方都清楚边界和兜底方式。它不是一个静态表格应该随着项目积累持续更新。6. 一个端到端案例让LLM当解析器让代码当计算器6.1 场景定义与目标假设你要做一个“数学题自动解答服务”。用户输入一段自然语言数学题服务返回最终答案和简要步骤。为了避免模型计算错误我们设计一个混合流程LLM负责把题目翻译成可执行的数学表达式或Python代码然后由后端执行器计算最后把执行结果包装成答案返回。这个案例中目标不是“提高模型的数学成绩”而是“设计一个能稳定输出正确答案的系统”。即使模型本身在计算上会犯错我们也能通过分工把错误率降到可接受范围。6.2 流程设计识别数学表达式、生成可执行代码、执行与校验整体流程分为五个环节接收用户题目。让LLM提取题目中的关键变量和计算需求输出一个标准化的JSON。让LLM根据JSON生成一段Python计算代码。在沙箱中执行代码捕获异常并获取计算结果。将结果与LLM的步骤说明合并返回给用户。这里的校验点有三个JSON是否合法代码是否可执行计算结果是否符合直觉。如果代码执行失败可以把错误信息回传给LLM让它修正代码最多重试2次。6.3 提示词设计为了让LLM输出稳定格式提示词要尽量具体。第一步提示词可以这样写用户会输入一道数学题。请提取题目中的数学信息并以JSON格式输出。 输出格式 { variables: { quantity1: 数值或表达式, quantity2: 数值或表达式 }, operation: 描述需要进行的计算, raw_input: 原题文本 } 要求 - 不要计算结果只做提取。 - 如果没有明确数值用符号表示。 - 所有单位先换算为国际标准单位。第二步提示词用来生成代码根据下面的JSON信息写一段Python代码完成题目要求的计算。 最后用 print(result) 输出结果。 JSON信息 {json_data}这样拆成两步是因为一次让LLM“边提取边计算”很容易把错误带进结果。分步之后每步输出都更容易定位问题。6.4 Python实现示例下面是一个最小实现省略了日志和异常处理细节重点展示流程骨架。import json import ast from openai import OpenAI client OpenAI(api_keyyour-api-key) def extract_json(prompt: str) - dict: response client.chat.completions.create( modelyour-model, messages[{role: user, content: f提取数学信息输出JSON\n{prompt}}], temperature0.0, response_format{type: json_object}, ) return json.loads(response.choices[0].message.content) def generate_code(data: dict) - str: prompt f根据JSON写Python代码并print(result)\n{json.dumps(data, ensure_asciiFalse)} response client.chat.completions.create( modelyour-model, messages[{role: user, content: prompt}], temperature0.0, ) return response.choices[0].message.content def run_code_safely(code: LLM数学能力深度拆解：擅长领域、局限与工程实践
在讨论大语言模型LLM的数学能力时很多人会得到一个矛盾印象它既能解方程、写证明思路又会在三位数乘法上算错甚至同一个问题换一种问法就得到不同答案。这个矛盾并不是模型“笨”而是数学任务本身不是一个能力而是多种能力叠加的结果。LLM在公式记忆、语言理解、模式匹配和步骤生成上有优势在精确计算、长链推理、严格证明上依然有明确边界。这篇文章会围绕“LLM擅长什么样的数学”展开先拆解数学任务类型再分析原理然后提供一套最小评测脚本最后给出常见问题排查和工程实践建议。这样你可以知道什么时候可以信任模型的结果什么时候必须引入工具或人工复核。1. 先看清问题LLM的数学能力不是“行”或“不行”而是分任务类型的1.1 为什么需要单独讨论LLM的数学能力在大模型的应用落地中数学能力往往是考核模型逻辑水平的重要窗口。一个能通过代码生成测试的模型不一定能稳定处理数学应用题一个能写常见脚本的模型可能在分数化简上出现低级错误。这不是个别模型的问题而是语言模型学习和输出机制带来的普遍现象。数学任务和自然语言任务最大的区别在于自然语言允许表达模糊和冗余而数学有严格的符号、运算规则和唯一结果。LLM本质上是一个基于概率的文本生成系统它并不像计算器那样执行算术也不像符号计算系统那样构造表达式。因此把数学任务看作一个统一的“会不会”问题是不准确的应该拆成多个子能力来看。在开发实际功能时这个区别直接影响技术选型。比如你做一个智能作业批改系统如果只关心“模型能否输出正确答案”那么遇到大数乘除、单位换算、含参讨论时就会出现大量漏判。相反如果你把题目先分类为“简单计算”“复杂计算”“应用题建模”“证明题思路”再分别设计处理流程系统的稳定性和可维护性都会好很多。1.2 按任务形态拆解数学能力实际使用中可以把LLM的数学任务拆成几类基本形态数值计算包括加减乘除、乘方、开方、取模等。这类任务最依赖精确执行LLM在位数少、结构简单时表现好在位数多、进位复杂时容易出错。代数与符号操作解方程、化简表达式、展开多项式。LLM擅长处理常规形式因为训练数据里大量出现过但对符号约束严格的题目容易“手滑”。应用题与文字题把自然语言场景转成数学表达式。LLM对语言理解的强项在这里能发挥关键在于能否正确建模。几何与空间推理涉及图形想象、辅助线、空间关系。LLM没有视觉输入时只能依赖文字描述能力不稳定。概率与统计常规分布、条件概率、期望计算LLM能处理经典问题但问题一旦需要精确积分或复杂事件枚举容易出错。逻辑推理与证明数学归纳法、反证法、形式化证明。LLM能生成看起来合理的推理链但很难保证每一步严格有效。这种拆解的意义在于同一模型在不同形态上的表现差异很大。后续的评测和工程选型都应该以子任务为单位做评估而不是用一个笼统的“数学准确率”来概括。1.3 常见评测基准与能力分布研究社区和工业界通常用公开评测集来衡量LLM的数学能力。常见的基准包括GSM8K、MATH、TheoremQA等。了解这些基准有助于判断一个模型在通用数学场景中的大致水平。评测集题目来源典型考察点整体难度GSM8K小学到初中难度的数学应用题自然语言理解、多步算术中等MATH高中数学竞赛题目覆盖代数、几何、概率、数论等抽象推理、多步符号操作较高TheoremQA定理推导与科学计算形式化推理、领域知识高AIME美国数学邀请赛题目竞赛思维、复杂推理高SVAMP带干扰信息的应用题变体建模能力、抗干扰中等需要说明的是不同模型版本在这些基准上的公开成绩变化很快而且榜单分数受提示词、采样次数、后处理方式影响很大。这里不列具体分数只给一个常见结论LLM在GSM8K这类“自然语言应用题”上表现相对好在MATH、TheoremQA这类“抽象竞赛题”上稳定性明显下降。如果你的项目需要处理高难度数学必须用与你业务接近的题目做私有评测而不是只看公开榜单。1.4 擅长与不擅长的任务对比结合实践观察可以画一张更直白的能力对比表。这张表描述的是“大多数通用模型”的表现不代表所有模型也不代表某个版本的绝对结论。任务类型典型题目模型常见表现信任建议简单数值计算12 25 × 3通常正确格式稳定可直接使用大数计算123456789 × 987654321容易算出错误结果且过程看起来自信必须用工具常规代数解 2x 5 17大概率正确步骤完整可人工复核复杂代数带参数的三元方程组可能在消元或代入时出错建议用符号计算工具常规应用题商品打折、行程问题表现较好但单位或条件可能漏掉需要检查建模几何证明证明三角形全等能给出常见思路但步骤跳步或错误必须人工核验概率计算条件概率或组合计数经典题表现尚可复杂题不稳定建议结合公式计算严格证明数学归纳法或反证法结构像但逻辑间隙常见不建议直接信任这张表的目的是帮助你在接到一个数学需求时快速判断该用LLM直接生成答案还是把它当作“草稿生成器”再配合其他工具。实际项目中最稳妥的做法永远是“模型给思路工具给结果”。2. 从模型原理上理解为什么LLM在数学上“偏科”2.1 语言模型做数学的本质是下一词预测LLM的训练目标通常是最大化条件概率给定前文预测下一个Token。这个机制决定了模型在回答数学题时并不是“先计算再写答案”而是一边生成一边决定下一个输出什么。它的所有知识、规则、模式和陷阱都编码在参数和上下文里。这意味着模型对数学的“正确性”并不像人脑那样建立在逻辑闭环上而是建立在“这段序列在过去训练数据中出现的可能性”上。当一道题的解题步骤在训练数据中出现频率高时模型能稳定生成当题目需要临时计算或组合新知识时模型只能靠概率推断出错风险自然上升。一个直观的例子是你问“圆的面积公式是什么”模型能很快写出πr²。因为它见过无数遍。但你问“半径为7.3米的圆形花坛铺满草皮需要多少钱草皮每平方米15.8元”模型需要把公式、乘法、金额换算串起来这时它表现出的就不再是“记忆”能力而是“临时计算”能力后者恰恰是它的弱项。2.2 Token化对数字计算的影响LLM处理的是Token而不是字符或完整的数。当前主流分词器会把数字拆成不规则的Token典型的例子是12345可能被拆成多个Token导致模型看不到完整的十进制结构。这种影响体现在几个方面大数比较时模型可能数错位数。进位和借位需要通过Token间的模式学习而不是真正执行位运算。个位、十位的“对齐”问题容易被忽略。分数、小数的精度损失因为分数被当作文本片段处理。所以在工程上不要让LLM直接做高精度数值计算。这是最常被忽视的坑之一。很多时候模型在“1.10”和“1.1”之间犹豫或者在“1000000”的零的个数上出错都不是因为它没有数学知识而是因为它从Token序列中无法直观把握数值结构。2.3 训练数据分布决定擅长面数学能力高度依赖训练数据覆盖度。如果训练语料中大量包含K12数学题、常见竞赛题、编程题里的算法描述那么模型对这些题型的模式非常熟悉表现自然更好。反过来如果某个数学分支在语料中出现频率低比如组合数学中的冷门定理或需要特定符号体系的形式化证明模型就只能勉强拼接。实际项目里会遇到一个现象同样的模型解一元二次方程很稳定但解含参不等式时经常漏讨论端点。这很可能不是模型“逻辑不好”而是训练数据里这类带讨论的完整例题不足模型缺少可参考的分布。这也解释了为什么用“few-shot”可以改善数学表现。你在提示词里给出几个相似例题后模型实际上是在调整输出分布让生成结果更靠近已有的示例模式而不是真正学会了一套新的推导规则。2.4 多步推理与上下文长度的影响数学题往往需要多个推理步骤且后一步依赖前一步的结果。LLM虽然可以生成很长的内容但每一步生成的误差都会累积。步骤越多中途“跑偏”的概率越高。另外上下文窗口长度会影响注意力的分配。当输入中包含大量条件、表格或历史对话时模型可能忽略关键条件或者把较早的错误步骤带到后面。这就是为什么给LLM喂“又长又杂”的数学题时效果常常比短题差。在工程上可以通过“减少无关信息”来缓解。如果题目本身有冗余条件可以先用一个抽取步骤把关键信息提取出来再让LLM基于精简信息解题。这个方法比单纯增加“请仔细思考”要有效得多。2.5 LLM是记忆器还是推理器两种现象的边界如果把模型在不同数学题上的表现记录下来会发现它更接近一个“高能力记忆器弱能力推理器”。对于训练语料中高频出现的题目模型通过记忆模式就能输出正确结果对于需要组合多种概念的全新题目模型缺乏真正的符号计算和逻辑校验机制。一个明显的证据是当题目只有细微变化比如把“甲比乙快”改成“甲比乙慢”模型可能仍然沿用原来的代数式说明它没有真正“验算”。这提醒我们不能把LLM在数学上的成功泛化到所有新问题上。所以在设计系统时要特别注意“题目变体”。如果模型在某类题上得分很高不要认为它掌握了这类题的解法还要用改变条件顺序、增加干扰项、交换数值等方式做压力测试看看结果是否仍然稳定。3. 用一次最小评测验证你的模型到底擅长什么3.1 评测环境准备Python与模型接入与其听别人说LLM擅长什么不如自己跑一组最小评测。最基础的环境只需要Python和一个模型API。这里以OpenAI兼容接口为例因为很多云服务商和本地推理框架都提供这种协议。先确认Python环境然后安装依赖python -m venv .venv source .venv/bin/activate pip install openai如果你的模型是本地部署并且暴露了OpenAI兼容的/v1/chat/completions接口也可以把base_url指向本地地址。生产环境注意不要把密钥写死在代码里应通过环境变量读取。你还需要确认Python版本在3.9以上因为新版OpenAI SDK对Python版本有要求。3.2 编写最小评测脚本下面这个脚本会逐一发送测试题收集模型的输出。这里不预设具体模型名称你可以根据实际环境修改model和接口地址。import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY, your-api-key), base_urlos.getenv(LLM_API_BASE, https://api.your-provider.com/v1), ) def ask_math(prompt, modelyour-model, temperature0.0): response client.chat.completions.create( modelmodel, messages[ {role: system, content: 你是一个数学助手。请严格分步推理并在最后一行以“答案:”开头给出最终答案。}, {role: user, content: prompt}, ], temperaturetemperature, max_tokens2048, ) return response.choices[0].message.content if __name__ __main__: problems [ (简单算术, 计算 12 25 × 3。), (大数乘除, 计算 123456789 × 987654321。), (一元方程, 解方程 2x 5 17。), (应用题, 一个商店打折原价200元的商品打八折后再减20元最终价格是多少), (几何面积, 半径为5的圆的面积是多少保留两位小数。), (概率, 从1到10中随机取一个数取到偶数的概率是多少), (复杂证明, 证明不存在最大的素数。), ] for label, question in problems: print(f题目: {label}) print(f问题: {question}) result ask_math(question) print(模型输出:) print(result) print( * 50)这段脚本的关键点有三个。第一temperature0.0用于降低生成随机性让结果更可复现。第二在系统提示中要求“分步推理”和“最后一行给出答案”便于后面对结果做规则解析。第三题目要覆盖不同能力维度不能只测算术。3.3 设计一组有区分度的测试题评测题的选取直接决定结论是否可信。建议按照“简单到复杂、常规到反常”的方式设计每组题目至少包含类别测试点题目示例基础算术运算优先级8 2 × 5大数计算多位数乘除982451653 × 1234567方程含参方程解关于x的方程 a x b c应用题多余条件小明有5个苹果、3个梨小红有2个苹果、4个梨他们一共有几个苹果几何单位换算一个长方形长2米宽50厘米面积是多少平方分米概率条件概率袋中有3红2蓝球不放回取两球第二球为蓝且第一球为红的概率证明反证法证明根号2是无理数数论取模与大数计算 2^100 mod 7每组题目都尽量选择一个“容易被语言模型带偏”的版本。例如括号、单位、取模、条件概率这些都是模型常见失分点。3.4 运行结果与判断标准脚本跑完后不要只看“对还是错”要同时看四个方面最终答案解析最后一行“答案:”后的内容判断数值是否正确。推理过程检查每一步是否逻辑连贯有没有把上一步结果抄错。格式规范有没有单位、约等号、符号错误。稳定性同一道题跑3次是否得到一致结果。建议把结果整理成表格例如题目模型输出摘要最终答案是否通过8 2 × 5先算2×510再算81018答案:18通过2^100 mod 7写出幂运算过程后给出4答案:4通过几何面积使用π3.14答案:78.50需确认精度这里不给出固定答案因为模型和版本会变。关键是你要建立一套自己的“通过”标准避免被一个漂亮的解题过程蒙蔽。比如几何面积题如果题目要求保留两位小数那么78.50和78.5是否等价需要你提前定好规则。3.5 关键参数对结果的影响调用模型时几个参数会直接影响数学结果需要重点关注。参数推荐值作用设置错误的表现temperature0.0降低输出随机性同一个问题多次结果不一致top_p1.0或较低控制候选Token范围与temperature叠加导致输出不确定max_tokens1024或2048限制输出长度推理到一半被截断seed固定值部分模型支持可复现结果仍可能波动response_formatjson/text结构化输出难以解析最终答案在评测阶段尽量固定temperature和seed并把max_tokens设置得足够长。否则长题容易中途截断导致你误判模型能力。也要注意有些模型不支持传入seed参数强行传入会报错落地时要根据SDK能力调整。3.6 评测结果怎么解读评测完成后不要急着下“模型行/不行”的结论。建议按“题目类型”汇总通过率然后回答几个问题哪些类型100%通过哪些经常失败失败的原因是计算错误、步骤错误还是理解错误增加提示词后错误率是否明显下降如果加入“请用Python计算”的指令结果是否改善这样得到的结论才具有工程指导意义你可以把高通过率任务交给模型直接处理把低通过率任务设计成“模型工具”的协作流程而不是一刀切地接受或拒绝LLM输出。评测结果必须保留原始输出和版本信息方便后续复现。4. 数学任务中LLM表现不稳定的常见原因与排查路径4.1 现象同一个问题多次结果不同同一道题用相同提示词问三次三个答案都不一样。这在数学场景里非常危险因为用户可能拿到三个看似都合理的答案无法判断哪一个是正确的。可能原因包括temperature没有设置为0或top_p设置过大。模型经过多轮对话后受到历史信息污染。API接入层做了负载均衡不同后端节点或不同量化版本导致差异。提示词里没有强调“分步推理”模型在多次生成时选择不同路径。排查顺序先固定temperature0.0和seed清空会话或每次用新会话确认后端模型版本一致最后再考虑是否要更新提示词。如果多次结果仍然不一致可以增加答案投票机制让模型生成多个候选再用规则或另一个模型选出最一致的结果。4.2 现象过程正确但最终答案错误模型写出了完整的解题步骤但最后汇总答案时写错。这种情况经常出现在小数、分数或大数的写法上。常见原因中间步骤的数值被截断或四舍五入最后汇总用了错误中间值。Token生成过程中模型只“看起来”引用了前面的数实际上输出了不同的数字。输出格式里混入了多余文字导致解析器提取到错误答案。处理建议在提示词中明确要求“最后一行用答案: 数值格式”在代码中从中间步骤提取关键计算结果并单独校验如果必须接受自然语言答案则要走人工复核。还可以让模型在最终答案后追加“请用计算器重新验证”的步骤但这会消耗更多Token需要权衡。4.3 现象复杂题目直接给出错误步骤高难题目上模型常常“一本正经地胡说”。它会编造一个不存在的公式或跳过关键推理步骤。这不是偶然错误而是模型缺乏真正推理的表现。排查时不要把“步骤长”当作“逻辑好”要重点检查每一步是否由前一步推出。是否引入了题目中没有的条件。是否使用了不成立的等价变形。是否有“因为所以”之间的跳跃。如果连续出现这种问题说明当前模型不适合直接回答这类题目要么换更强模型要么把它降级为“提示生成器”让专业工具完成证明或计算。一个可操作的方案是让模型生成“思路要点”再由SymPy或Mathematica验证具体步骤最后人工复核完整证明。4.4 按输入、提示词、模型参数、上下文逐层排查当模型数学答案错误时推荐按下面的链路排查检查输入题目是否完整单位是否明确是否存在歧义。很多人忽略了“2米×50厘米”这种单位混用才是错误源头。检查提示词是否要求逐步推理是否给出输出格式约束是否要求验证答案。检查模型参数temperature、max_tokens、seed是否合适。检查上下文多轮对话中是否残留之前的条件是否被无关内容干扰。检查日志记录每次请求的完整输入输出便于复现。检查工具辅助如果正确率仍然不达标考虑引入外部计算器或代码解释器。检查模型选型同一道题在能力更强的模型上是否通过以判断是提示词问题还是模型能力边界。这条链路的核心思想是“先排除环境问题再评估能力问题”。很多看起来像模型数学能力不足的情况实际上是提示词没有约束好输出格式或是上下文里混入了旧条件。4.5 数学答案错误排查清单排查项检查内容可能结果处理建议输入完整性题目条件是否全部进入提示词漏条件导致误答对比原题和请求体单位一致性是否要求统一单位单位换算错误提示词中显式要求提示词约束是否要求分步思考和结果格式答案格式混乱补充最后一行写答案:温度参数temperature是否大于0输出不稳定固定为0.0上下文污染历史消息是否包含错误前例答案被历史带偏清空上下文或使用独立会话中间值截断生成长度不足推理被切断调大max_tokens工具调用是否允许模型调用计算器依赖模型手算接入计算工具或代码执行器模型版本是否使用一致版本结果漂移统一模型映射这张清单可以直接贴在项目文档里每次排查时逐项对照。建议把清单也做成一个Markdown文件放进仓库让团队成员提交代码时自查。5. 在真实项目中用好LLM数学能力的实践方案5.1 设计原则让LLM做擅长的事把计算交给工具工程上的最优策略不是让LLM把所有数学活都干完而是拆解任务让LLM负责自然语言理解、问题建模、规划解题步骤。把数值计算交给代码解释器、计算器或算术表达式解析器。把符号计算交给SymPy、Mathematica等专用库。把证明逻辑交给人工复核或形式化验证工具。这种“语言模型工具”的混合模式既能利用LLM的理解能力又能规避它的精确计算短板。生产环境中稳定性优先级高于“让模型一步到位”。比如在智能客服里用户问“我有一张满300减100的券商品标价268但是可以叠加8折最后多少钱”正确的流程是让LLM提取出“原价268、打8折、满300减100不满足”这几个关键点然后由代码计算最终价格而不是让LLM直接写答案。5.2 提示词里的“分步思考”该怎么写简单地在提示词里加“请一步一步思考”可能有效但更稳的写法是给出明确的过程约束。推荐示例你是数学解题助手。请按以下要求回答 1. 先用自己的话重新描述题目条件。 2. 列出需要求解的未知量和已知关系。 3. 分步骤推导每一步必须说明用到的公式或规则。 4. 每一步完成后检查上一步的结果。 5. 在最后一行写答案: 最终结果这样做的目的是把模型生成过程拆成可验证的多个点。如果中间某一步出错你可以根据输出定位而不是面对一个黑盒答案。实际项目中还可以要求模型在最后一行输出JSON方便程序解析例如{answer: 18, steps: [...]}。5.3 用外部计算器和代码解释器补足准确率实际项目中最可靠的补充方式是把计算任务交给执行器。例如让模型生成Python表达式然后服务端执行并校验import ast import math def safe_eval_math(expression: str): # 只允许白名单节点避免任意代码执行 allowed (ast.Expression, ast.BinOp, ast.UnaryOp, ast.Constant, ast.Name, ast.Load, ast.Add, ast.Sub, ast.Mult, ast.Div, ast.Pow, ast.Mod) for node in ast.walk(ast.parse(expression)): if not isinstance(node, allowed): raise ValueError(fillegal node: {type(node).__name__}) return eval(expression, {__builtins__: {}}, vars(math)) print(safe_eval_math(123456789 * 987654321))这里用ast白名单限制表达式类型避免把用户输入直接交给eval造成安全隐患。生产环境还要增加超时控制、日志记录和错误捕获不能假设模型生成的表达式总是合法的。如果项目已经有代码解释器或Python运行时可以直接让模型生成完整脚本后再执行。要注意的是模型生成的代码同样可能出错所以必须做结果校验和异常重试。可以设定重试次数比如模型第一次生成的代码执行报错就把报错信息回传给模型让它修正后再次执行。5.4 什么时候该考虑微调或专用模型如果特定数学域的需求非常固定比如公司内部的计算规则、行业公式、特定题型并且通用模型的错误率始终下不来可以考虑微调或选用专用模型。但微调不是万能的。它更适合让模型“熟悉固定格式和规则”而不是给模型“补数学逻辑”。微调前要先积累几百到几千条高质量问答数据并且每一条都要人工审核避免模型学到错误模式。如果不需要改变模型能力只是想提高数学题正确率更轻量的做法是使用更强的基座模型。在推理时增加候选答案采样再用验证器排序。接入外部符号计算工具。构建“模型生成方案代码执行结果”的流程。微调还会带来训练成本、部署成本和维护成本。如果你的问题可以通过工具调用解决优先选择工具而不是微调。5.5 生产环境下的数学能力评测与回归机制只要业务依赖LLM输出数学结果就不能只在开发期测一次。生产环境至少要建立固定评测集从历史问题、错误问题、边界条件中整理一批有代表性的数学题。回归流水线每次更换模型版本、提示词或参数时自动跑一遍评测集。答案校验规则用代码计算期望结果对比LLM输出。线上监控记录模型输出、用户反馈、错误率设置阈值告警。版本回滚如果模型升级后数学能力下降能快速切回旧版本。在CSDN这类技术博客的语境里这一步经常被省略但恰恰是它把“能用”变成“可靠”。一个没有回归机制的数学解答系统很可能在某个周末因为模型服务商更新版本而突然大面积出错而你无法快速定位。5.6 可复用的“数学能力使用决策清单”场景推荐做法简单算式结果唯一LLM直接回答但要固定temperature为0大数计算让LLM生成表达式用代码执行方程求解LLM给出步骤用数学库求解并核对应用题建模LLM负责建模数值计算交给工具概率统计要求列出公式再代入计算几何证明只作为思路生成必须人工核验竞赛级推理不建议依赖通用LLM直接给最终结论教学场景可让LLM分步讲解但答案要脚本校验生产API增加答案解析、异常捕获、日志与告警这张清单可以做成团队知识库里的文档让每个接入方都清楚边界和兜底方式。它不是一个静态表格应该随着项目积累持续更新。6. 一个端到端案例让LLM当解析器让代码当计算器6.1 场景定义与目标假设你要做一个“数学题自动解答服务”。用户输入一段自然语言数学题服务返回最终答案和简要步骤。为了避免模型计算错误我们设计一个混合流程LLM负责把题目翻译成可执行的数学表达式或Python代码然后由后端执行器计算最后把执行结果包装成答案返回。这个案例中目标不是“提高模型的数学成绩”而是“设计一个能稳定输出正确答案的系统”。即使模型本身在计算上会犯错我们也能通过分工把错误率降到可接受范围。6.2 流程设计识别数学表达式、生成可执行代码、执行与校验整体流程分为五个环节接收用户题目。让LLM提取题目中的关键变量和计算需求输出一个标准化的JSON。让LLM根据JSON生成一段Python计算代码。在沙箱中执行代码捕获异常并获取计算结果。将结果与LLM的步骤说明合并返回给用户。这里的校验点有三个JSON是否合法代码是否可执行计算结果是否符合直觉。如果代码执行失败可以把错误信息回传给LLM让它修正代码最多重试2次。6.3 提示词设计为了让LLM输出稳定格式提示词要尽量具体。第一步提示词可以这样写用户会输入一道数学题。请提取题目中的数学信息并以JSON格式输出。 输出格式 { variables: { quantity1: 数值或表达式, quantity2: 数值或表达式 }, operation: 描述需要进行的计算, raw_input: 原题文本 } 要求 - 不要计算结果只做提取。 - 如果没有明确数值用符号表示。 - 所有单位先换算为国际标准单位。第二步提示词用来生成代码根据下面的JSON信息写一段Python代码完成题目要求的计算。 最后用 print(result) 输出结果。 JSON信息 {json_data}这样拆成两步是因为一次让LLM“边提取边计算”很容易把错误带进结果。分步之后每步输出都更容易定位问题。6.4 Python实现示例下面是一个最小实现省略了日志和异常处理细节重点展示流程骨架。import json import ast from openai import OpenAI client OpenAI(api_keyyour-api-key) def extract_json(prompt: str) - dict: response client.chat.completions.create( modelyour-model, messages[{role: user, content: f提取数学信息输出JSON\n{prompt}}], temperature0.0, response_format{type: json_object}, ) return json.loads(response.choices[0].message.content) def generate_code(data: dict) - str: prompt f根据JSON写Python代码并print(result)\n{json.dumps(data, ensure_asciiFalse)} response client.chat.completions.create( modelyour-model, messages[{role: user, content: prompt}], temperature0.0, ) return response.choices[0].message.content def run_code_safely(code: