韩国大学AI代码思考数学解题能力超百倍大模型

近期，一项由韩国大学与AIGEN Sciences合作完成的研究在arXiv预印本平台发布（编号：arXiv:2605.07237），为解决AI应对数学难题这一长期挑战，提出了一个颇具新意的思路。

数学问题一直是AI面临的核心难点之一。其挑战并非源于模型智能不足，而在于数学计算对精确性的严苛要求——任何微小差错都将导致后续推导全盘皆输。这类似于笔算多位数乘法时，若中间某步误写一个数字，最终结果必然谬以千里。

当前主流的AI解题方法主要分为两类。一类是纯自然语言推理，类似于学生完全依靠心算和草稿纸推导；另一类是“工具辅助推理”，即AI在文字分析过程中调用Python解释器等工具进行计算。后者看似更为合理，但韩国大学的研究团队发现，这种“文字与代码交错”的模式存在三个结构性缺陷，制约了AI性能的充分发挥。

为彻底解决此问题，他们提出了一套全新框架，命名为THINC（Thinking in Code，即“用代码思考”）。其核心理念异常简洁：与其让AI以文字推导为主、偶尔借助代码验证，不如让代码承担绝大部分推理工作——自然语言仅用于初始阶段的高层规划，后续所有计算与逻辑步骤完全交由代码执行。

实验结果令人瞩目。基于40亿参数的小型模型，在五个顶级数学竞赛评测集上取得了平均78.1%的准确率。该表现不仅超越了所有同类“工具辅助推理”系统，甚至超过了参数量级达其近60倍的巨型模型Qwen3-235B-A22B-Thinking。

现有方法的三大固有缺陷

要理解THINC为何有效，需先厘清其旨在解决的问题。

将AI“文字推理+代码执行”的混合模式类比为工程师与计算器协作的场景，便能直观看出问题所在。工程师（文字推理部分）先进行心算或纸笔推导，随后将中间结果交由计算器（代码执行部分）验证。此流程看似稳妥，实则存在三个易被忽视的漏洞。

第一是“事后验证陷阱”。工程师已完成全部推导并得出答案，随后才要求计算器“确认此结果”。计算器执行后给出相同答案，看似双重校验，实则并未进行任何新的推理——它仅仅在复现一个已存在的结论。若工程师的初始推导有误，计算器的验证亦将确认该错误，无法起到纠正作用。

第二是“错误静默传递”。工程师在思维中完成某步计算，得出一个中间值（例如将500的12%误算为50）。随后他将此错误数值直接输入代码，交由计算器继续后续运算。计算器忠实执行，却无从知晓输入的50是错误的——它不会质疑数据来源，只会基于此错误值进行计算。错误由此被悄然传递，全程无任何警报。

第三在于“角色重叠与资源浪费”。理论上，文字推理与代码执行应各司其职：前者擅长高层战略规划，后者精于精确计算与符号运算。然而在实际混合模式中，文字推理常会详细描述解题步骤，近乎用自然语言重述整个算法；紧随其后的代码块，又用编程语言将同一算法重新实现一遍。两者重复相同工作，文字推理部分未能发挥应有价值，反而浪费了宝贵的计算资源。

THINC的核心设计：让代码主导推理

THINC的解决方案可通过一个直接类比理解：将解题过程视为施工队建造楼房。

在旧模式中，项目经理（文字推理）会依据蓝图口头阐述整个施工流程，详细说明每一步操作、耗时及中间数值……然后工人（代码执行）再依照指令施工。若经理口述的某个数字有误，工人便会按错误数字作业，且无人核查该数字的正确性。

在THINC模式中，项目经理仅负责最初环节：审视蓝图后，简要声明“我们将建造一栋三层楼房，采用钢筋混凝土结构，从地基开始”。此言既毕，经理便退居幕后。后续所有工作——地基开挖、墙体砌筑、管线敷设——皆由工人依据工程标准独立完成，每一步均有实测数据支撑，不依赖于经理的口头描述。

以更技术性的语言表述，THINC的工作流程如下：问题输入后，模型首先生成一段简短的自然语言规划，阐明解题的整体策略；随后完全切换至代码模式，每个代码块执行后的输出结果直接作为下一代码块的输入依据，直至获得最终答案。代码块之间不存在任何自然语言推理段落。

此结构的精妙之处在于，其从设计层面规避了前述三个漏洞。代码块是主动的推导者，而非被动的验证者；所有中间数值均由解释器实时生成，杜绝了手动输入错误的机会；自然语言仅负责战略规划，不涉足具体推导，两者职责边界清晰明确。

从零到精通的训练三阶段

理解THINC核心理念后，随之而来的问题是：如何让一个普通AI模型掌握这种“以代码思考”的方式？研究团队设计了一个三阶段训练流程，可类比为培养厨师：先观摩名厨（轨迹蒸馏），再系统练习基本功（监督微调），最后通过真实竞赛锤炼技艺（强化学习）。

第一阶段“观摩名厨”，即从更强的教师模型中采集符合THINC格式的解题样本。团队选用Qwen3.5-27B作为教师模型，向其展示三道示例题（包含标准THINC格式解题过程），随后让其对大量竞赛数学题生成解题轨迹。每条生成的轨迹均经过严格筛选：答案必须正确、每个代码块皆可无错运行、至少包含三个独立代码块，且开头的规划部分不得超过总篇幅的一半。后两个条件旨在确保样本真正“以代码为核心”，而非文字推理占主导。经筛选，最终保留12,200条高质量的代码中心型轨迹，构成THINC-SFT数据集。

第二阶段“练习基本功”，即利用这12,200条轨迹对学生模型进行监督微调。团队选用两个基础模型：Qwen3-1.7B和Qwen3-4B-Thinking-2507，分别训练出THINC-1.7B-SFT和THINC-4B-SFT版本。训练参数方面，采用32K上下文长度、学习率7×10，以及3个训练轮次。此阶段目标并非使模型立即表现卓越，而是让其熟悉THINC格式——如同新厨师先掌握基本刀工与火候控制。

事实上，刚完成监督微调的模型表现并不突出：THINC-4B-SFT的平均准确率仅为48.1%，甚至略低于基础模型。这完全在预期之内——模型此时刚掌握新的“工作方式”，尚未达到熟练程度。

第三阶段“真实竞赛锤炼”，即通过强化学习进一步提升模型的解题能力。强化学习的逻辑直观：模型尝试解答题目，若最终答案正确则获得奖励，错误则无奖励。通过大量此类“尝试-反馈”循环，模型逐渐学会哪些解题策略真正有效。

团队采用的具体算法是GRPO（Group Relative Policy Optimization），一种无需额外“裁判模型”的强化学习方法。训练分为三个阶段，核心区别在于可用的计算资源：第一阶段允许最多20次工具调用、上下文长度16K；第二阶段过滤掉已完全解决的简单题目，专注于挑战性题目；第三阶段大幅扩展资源，允许最多40次工具调用、上下文长度32K，使模型能够处理需要更长推理链的超难题目。

经过完整的强化学习训练，THINC-4B的平均准确率从48.1%跃升至78.1%，提升幅度达29.9个百分点。此阶段方为真正的“能力飞跃时刻”。

竞赛表现：超越同级，以小博大

研究团队在五个顶级数学竞赛评测集上测试了THINC，分别为AIME 2024、AIME 2025、AIME 2026、HMMT 2025 February及BeyondAIME。这些评测集题目难度极高，相当于数学竞赛中的顶尖赛事水平。

评测方式是为每道题目生成16次解答，随后计算平均答对率（avg@16）。此方式较单次生成更能反映模型的真实能力，减少了运气因素的干扰。

在这五个评测集上，THINC-4B的平均成绩为78.1%，在四个评测集上位列第一。最直接的对比对象是ASTER-4B——该模型与THINC-4B使用完全相同的基础模型、相似的教师模型容量及强化学习流程，唯一区别在于ASTER采用传统的“文字与代码交错”格式，而THINC采用纯代码推理格式。在此最公平的对比条件下，THINC-4B在所有五个评测集上均超越ASTER-4B，平均领先4.1个百分点。更值得注意的是，THINC-4B实现此成绩所用的工具调用次数（平均6.1次）较ASTER-4B（11.1次）减少近半，生成的响应长度（平均13.5K个token）也短于ASTER-4B（15.4K）。换言之，THINC不仅更准确，且更高效。

更具戏剧性的对比来自不同量级模型间的较量。Qwen3-235B-A22B-Thinking是目前开源社区中最强的纯文字推理模型之一，参数量高达2350亿（其中220亿为激活参数）。THINC-4B的参数量仅为40亿，体量差距近60倍。然而，在五个评测集中的四个上，THINC-4B的得分均超越此巨型模型，平均领先2.9个百分点。

THINC-4B亦超越了其自身的教师模型Qwen3.5-27B（在相同的3-shot提示条件下），平均领先幅度达13.4个百分点——学生全面超越教师，这在机器学习领域虽不常见，但通过监督微调与强化学习的组合确可实现。

在更小的1.7B规模上，THINC同样展现出稳定的提升。THINC-1.7B的平均准确率达到42.8%，超越了Qwen3-1.7B基础模型（32.2%）、被提示使用Python解释器的Qwen3-1.7B（29.8%），以及同量级竞争者CoRT-1.5B（25.7%）。

THINC是否真正“用代码思考”？

一个合理的疑问是：THINC仅是形式上遵循“先规划、后代码”的格式，还是真正在用代码进行推理？研究团队通过两个指标回应此问题。

第一个指标是“每条轨迹的代码行数”。THINC-4B平均每条轨迹编写349行代码，远超排名第二的ReTool（261行）、ASTER（102行）和CoRT（40行）。仅从数量观之，THINC确实在大量使用代码。

第二个指标更能说明问题，称为“代码接地率”——即最终答案有多大比例实际出现在某个代码块的执行输出中，而非由模型直接在文字中生成。此指标衡量最终答案究竟是“代码计算得出”还是“文字直接写出”。THINC-4B的代码接地率高达99.2%，几乎所有答案均源自解释器的执行输出。相比之下，ReTool为88.4%，rStar2-Agent为74.3%，CoRT与ASTER约为50%，DemyAgent最低，仅为34.9%。这意味着超过半数情况下，这些对比模型的最终答案实际上是直接由文字推理“生成”的，完全绕过了代码解释器——而绕过解释器，便意味着丧失了精确计算的保障。

THINC-4B的这一特性，从其轨迹结构来看是“被迫”形成的——因为格式规定两个代码块之间无文字推理空间，答案必须从代码执行结果中产生，否则无处生成。这种“被迫”实则构成了其优势。

代码执行出错如何处理？

一个自然的担忧是：若代码是唯一的推理工具，一旦执行出错，模型是否完全无路可退？在传统的“文字与代码交错”模式中，代码出错后，模型尚可在后续文字段落中分析原因、重新规划，如同登山时遇阻可言“此路不通，另寻他径”。THINC无此选项——代码块之间无文字间隔，面对执行错误，模型只能在下一个代码块中直接应对。

研究团队采用名为“Recovery@k”的指标测量此情境下的表现：即在前k个代码块全部执行出错的情况下，模型最终仍能正确答题的比例。k值从1测试至5，覆盖从一次失败到五次连续失败的场景。

结果出人意料：所有传统交错推理系统均随k值增加而表现大幅下滑。ASTER在k=1时恢复率为52.1%，至k=5时跌至18.5%；rStar2-Agent在k=1时为39.1%，至k=5时直接降至0%；ReTool、DemyAgent及CoRT亦呈现类似下降趋势。

THINC-4B的表现则截然不同：在k=1、2、3时，恢复率稳定在64%至69%之间，几无下滑；至k=4时降至54.5%，k=5时降至33.3%。即使在k=5的极端场景下，THINC-4B的恢复率仍是所有交错推理基线中最高值的近两倍。

研究团队进一步分析了此鲁棒性的来源。刚完成监督微调、尚未进行强化学习的THINC-4B-SFT，在k=1时的恢复率已达42.9%，超越了大多数交错推理基线。这表明“代码中心型”格式本身即带来了一定的鲁棒性——不依赖文字推理来消化错误，反而迫使模型在代码层面解决问题。经过强化学习后，此鲁棒性进一步大幅提升，在k=1、2、3时分别提升超过20个百分点。

实例解析：一道真实题目的完整解题过程

为使上述描述更为具体，研究团队在论文中展示了THINC-4B解答AIME 2026第3题的完整轨迹。题目为：找出不超过100的整数中，有多少个可表示为a+b+ab的形式，其中a与b为不同的正整数？（参考答案为70。）

模型的规划段仅完成一项任务：将表达式a+b+ab改写为(a+1)(b+1)-1，随后声明“如此可直接枚举，我将编写代码”。之后无任何多余文字，直接进入代码执行。

第一个代码块：编写双重循环，枚举所有满足条件的(a,b)对，将结果存入集合并去重。输出：70。但模型在代码注释中指出，循环内的`break`语句可能存在逻辑问题——即其在代码执行完毕后，通过阅读自身代码发现了一个潜在漏洞，此反思过程完全在代码注释中完成，无任何文字推理段落。

第二个代码块：针对已发现的问题重写循环逻辑，修正break条件，并顺带输出所有满足条件的数字的完整列表。结果仍为70。

第三个代码块：将此70个数字按奇偶性分类，验证是否存在遗漏或重复计数。奇数48个，偶数22个，合计70个，验证通过。

第四个代码块：采用完全不同的数学等价形式（令u=a+1，v=b+1，通过枚举乘积u×v进行计数）独立重新推导，并明确检验两种方法的结果是否一致。结果仍为70，两种方法完全吻合。

第五个代码块：反向验证——找出1至100中所有无法被表示的数字，确认恰好有30个，从而反证可被表示的为70个。

最终答案：70。全程无任何文字推理介入，所有自我纠错、结构验证及独立重推均在代码块内部完成。

超越数学：在科学题目上的适用性

研究团队还进行了一项额外测试，将THINC-4B置于GPQA-Diamond评测集上运行。此评测集并非数学题，而是研究生级别的物理、化学及生物选择题，对AI而言属于完全陌生的领域。

结果显示，THINC-4B在avg@16指标上获得66.48%，略高于基础模型Qwen3-4B-Thinking的66.32%；在best@16（16次尝试中的最佳成绩）指标上达到91.41%，超越ASTER-4B的90.40%，并较基础模型高出7.57个百分点。此结果表明，代码中心型推理方式并不局限于数学领域，在需要系统性分析与精确计算的科学问题上同样有效。

归根结底，THINC研究回答了一个简单问题：当要求AI在解决数学问题时“少言多行”，会发生什么？答案是：其表现更优、速度更快，且容错性更强。

这并非否定文字推理的价值——战略规划仍需语言完成。但具体计算、逻辑推导及验证等任务，代码本就较文字更为擅长，强行令二者共存反而可能制造麻烦。研究团队找到了一种让两者各司其职的方式，效果显著。

当然，此项研究亦存在局限。目前实验仅在1.7B和4B这两个较小模型规模上进行，在更大规模模型上是否同样有效尚不明确。评测范围也局限于竞赛数学，代码中心型推理是否适用于其他类型问题（如开放式问答或创意写作）仍需进一步探索。

常见问题解答

问：THINC框架与普通的“AI使用代码解数学题”有何区别？

答：普通的工具辅助推理是文字推理与代码执行交替进行——AI先用文字分析一段，再调用代码计算一段，随后继续文字推理。THINC的核心区别在于：开头仅用文字进行一次战略规划，之后所有推理步骤完全由代码完成，代码块之间无任何文字推理。这使得所有中间结果均由解释器生成，避免了文字推理中的计算错误被悄无声息地传递至代码中。

问：THINC-4B如何以40亿参数击败2350亿参数的大模型？

答：参数量大并不意味着解题方式更合理。Qwen3-235B-A22B-Thinking采用纯文字推理解题，文字计算本身易出错；而THINC-4B将所有数值计算交由Python解释器完成，从源头上消除了文字计算的不可靠性。加之强化学习训练使模型反复尝试难题、积累有效解题策略，最终在竞赛数学这类对精确计算要求极高的领域，THINC-4B的解题方式较大模型的纯文字推理更具优势。

问：THINC在代码执行出错时如何应对？

答：THINC没有文字推理段落来“解释”执行错误，模型只能在下一个代码块中直接重写逻辑以应对。实验测试显示，此方式的鲁棒性反而强于传统交错推理——在前五个代码块全部出错的极端情况下，THINC-4B仍有33.3%的恢复率，而最强的对比模型（ASTER）已跌至18.5%，rStar2-Agent直接降至0%。强化学习阶段使模型大量练习了“遇到错误直接在代码层面修复”的能力。