长推理不是越多越好

智能体要在多步任务里推进,并依据反馈修正动作;而总推理预算往往有限,还得留给后面的步骤。于是每做一个动作前,它都得在「短推理」和「长推理」之间选:长推理或许能靠提前想清楚少犯后面的错,但也吃掉了本该留给后续决策的预算。这里有两道难题——怎么估长推理的下游价值,又怎么判断这一份价值值不值得用掉剩余预算。PORA(arXiv 2610.27119,10 月 19 日提交,配对结果引导推理分配)就是来学这个决定的。

同一状态,跑两遍比长短选中状态从它完整跑两遍短推理一遍长推理一遍比质量与耗时学何时长推理值得用应用 / 记忆 / 代码 / 零售 / 数学 多任务验证推理时不真跑两遍,靠学得的估价来选来源:arXiv 2610.27119(10/19)
图|PORA 在训练时从同一状态把任务跑两遍(短推理与长推理各一),比较质量与耗时,从而学会在每一步判断长推理到底值不值。

它的训练方式是:从每个被选中的状态,把任务完整跑两遍,一遍给短推理额度、一遍给长推理额度,再比较两者最终的质量和总耗时,从而估出「什么时候长推理才值」。到了推理阶段,一个控制器把这份估计,和从剩余预算压力上学到的「价格」放在一起权衡,直接选短或选长——而不需要真的把两种都跑一遍。它在应用、记忆、代码、零售和数学等任务上做了评估,各档设置都拿到了稳的结果。

省下的预算,留给了后面的步

在 BFCL 记忆任务上,它超出表现最好的现有方法 17.4 到 32.9 个百分点。在同一个智能体内部,它在代码和数学上匹配或超过了「始终长推理」的做法,却少用了 50.6% 的 actor token、少了 31.2% 的模型请求。换句话说,它把省下来的推理预算,腾给了任务后面更需要的决策,而不是在每一步都无差别地烧。

省下的预算,留给后面的步BFCL 记忆:超现有最好 +17.4~32.9代码/数学匹配始终长推理actor token 少 50.6%模型请求少 31.2%推理预算不被静态策略定死,跟着状态动态分配
图|PORA 在 BFCL 记忆上超出表现最好的现有方法 17.4 到 32.9 个百分点,并在代码与数学上以少 50.6% 的 actor token、少 31.2% 的请求匹配始终长推理。

PORA 点出的是智能体效率里一个被长期低估的旋钮:推理预算不该被「始终长」或「始终短」这种静态策略定死,而该跟着状态和剩余预算动态分配。对要把智能体铺到长流程、多步骤业务里的团队,这种「按需分配推理」的思路,比单纯换更大的模型更直接地压成本。