如果你让一个大模型做一道需要多步计算的数学题或者顺着一段报错日志排查 bug你大概率见过这种场面模型给出的推理过程步骤完整、逻辑自洽语气还很笃定但最终结论是错的。更让人头疼的是它并不会因为错误而收敛换个问法再来一次它可能又自信地给出另一个错误答案。这种“一本正经地胡说八道”本质上是单次推理single-pass inference的固有瓶颈。模型从输入到输出只完整生成了一遍中间没有检查、没有验证、没有回退推理链条一旦在某一步跑偏后面的所有步骤都会跟着错而且错误会被包装得越来越像正确答案。解决这个问题的思路之一就是本文要讲的 Chained Recursive Language Models for Multi-Iteration Reasoning即链式递归语言模型与多轮迭代推理。从标题就能看出它关注的不再是“让模型生成一个答案”而是“让模型像人一样对着草稿纸反复检查、修正最后给出一个更可靠的答案”。这个方向真正改变的是 LLM 应用的方式从一次性生成变成带验证闭环的迭代系统。这篇文章会先解释这个概念背后的动机和核心原理再给出完整的 Python 实现最小递归循环、Self-Refine、Self-Consistency 投票最后聊一聊工程落地时的成本控制、停止条件和常见坑。如果你想在项目里给 LLM 加一层“验算能力”这篇文章可以直接作为起点。1. 单次推理的瓶颈为什么模型会“自信地犯错”先回到根本问题大模型本质上是一个根据前文预测下一个 token 的生成器。你给它一个问题它在一次前向传播里把答案“写完”。这个过程很像一个人在没有任何草稿纸、只能心算的情况下一口气把一道多步题的答案写出来。题目简单还好一旦涉及多个步骤、多个条件中间某一步算错后面就全盘皆输。多步推理中的错误积累是最典型的问题。一个推理链越长越靠前的子步骤一旦出错后续步骤哪怕每一步都正确最终答案也是错的。更麻烦的是模型没有“发现自己错了”的机制。它在生成时并不会回头检查前一步是否合理token 一经生成就成了“事实”后面的推理只能在这个错误基础上继续。另一个问题是置信度错位。模型给出答案时并不附带真实的正确率信号。它对一个正确答案和错误答案在语气和格式上往往没有区别。这就导致开发者很难通过模型自己的“信心”来判断结果是否可用。你拿到一个答案要么人工复核要么全盘接受这两种方式在规模化场景下都不可持续。这也是人脑与现有 LLM 最明显的差异之一。人做复杂计算或写长代码时默认流程是先写一版再回头验算发现不对就改改完再检查。这里的“检查-修正-再检查”是一个闭环而不是一次生成。Chained Recursive Language Models 想做的就是把这种闭环补到 LLM 的推理过程中。所以我的核心判断是多轮迭代推理不是一个“多加几个 Prompt 再问一遍”的技巧而是一套可靠性机制。它把“生成答案”升级为“生产可靠答案”代价是更多的计算和延迟收益是错误可以被发现、被修正而不是被自信地输出。2. Chained Recursive Language Models 核心概念理解这个方向建议直接从名字拆解Chained链式、Recursive递归、Multi-Iteration Reasoning多轮迭代推理。三个词其实对应三个层次的结构设计。2.1 链式把模型当作流水线里的工位“链式”指的是多个处理单元按顺序协作前一个单元的输出成为后一个单元的输入。在最简单的形式里可以是一个模型同时承担多个角色先生成答案再批判答案再根据批判结果重写。在更复杂的工程形式里可以用不同模型或不同提示词来承担不同角色比如生成器Generator负责给出候选答案。验证器Verifier负责检查答案中的错误。修复器Fixer根据验证结果重新生成。这就像工厂里的流水线每个节点只负责一道工序。把任务拆给多个单元比让一个单元“既当运动员又当裁判”更容易控制质量。实际项目中常见的做法是用一个大模型负责生成用一个更便宜的小模型或专用验证器负责检查这样能在成本和效果之间取得平衡。2.2 递归让模型反复处理自己的输出“递归”是比“链式”更深一层的关系。链式是线性管道数据只流过一次递归则要求模型把自身输出再次作为输入形成 f(x)、f(f(x))、f(f(f(x))) 的循环。在 LLM 场景里递归的具体形态是模型读入“问题 上一轮答案 上一轮的批判意见”重新生成一轮答案。与链式最大的区别在于递归存在反馈回路上一轮的结果会直接影响下一轮的输入。这个设计背后的意图很清晰每一轮不是简单地再生成一遍而是站在前一轮的基础上继续收敛。需要注意的是递归并不等于无限循环。工程上递归必须搭配终止条件否则就是成本和延迟的失控。这也是后面代码实现里最重要的部分之一。2.3 多轮迭代推理测试时计算的工程化落地近两年大模型领域有一个明显的趋势把更多的计算资源放到“推理时”而不是“预训练时”。大家熟悉的思维链Chain-of-Thought、自一致性Self-Consistency、以及强调长时间思考的模型路线本质上都属于“测试时计算”test-time compute的范畴。Chained Recursive Language Models 的多轮迭代推理是这条路线中非常工程化的一个分支。它没有把希望寄托在“模型一次生成更长的思维链”而是用系统结构来保证可靠性生成、验证、修正、再验证直到满足停止条件。这种思路和搜索类方法比如 Tree of Thoughts也有相通之处只是搜索类方法通常需要显式建模分支和回溯而链式递归方法更接近一种受控的迭代精化过程。为了看清它和常见方法的区别我整理了一张对比表方法核心机制迭代方式主要开销定位标准 CoT先写推理过程再给答案无迭代一次较长生成提升多步推理能力Self-Consistency多次采样后投票并行采样N 倍生成成本提升确定性任务准确性Self-Refine生成-批判-修正串行迭代每轮额外的批判与生成开销提升文本与推理质量Tree of Thoughts按分支探索推理路径搜索式迭代高需建模状态和回溯解决规划、探索类问题Chained Recursive LM链式 递归 迭代验证串行 / 混合由迭代轮数和验证器决定多轮验证后给出可靠答案从表中可以看出一条主线所有多轮方法都在用“计算量”换“准确率”。区别只在于迭代的结构、验证的方式以及停止的策略。3. 多轮推理系统的核心模块与设计要点一个能落地的多轮推理系统通常由四个模块组成。不要一上来就堆代码先把模块想清楚后面实现才不会散。3.1 生成器Generator生成器的任务是产出候选答案。它可以是任意 LLM通过 system prompt 控制角色比如“请一步步推理并给出最终结论”。生成器不一定必须很强因为后续还有验证和修正环节。但生成质量会影响迭代收敛的速度生成得太离谱后面的修正成本会很高。3.2 验证器Verifier / Critic验证器是整个系统里最关键的模块也是最容易被低估的模块。它的任务是判断当前答案“对不对”“哪里不对”。验证器可以是模型自身可以是独立的小模型也可以是外部工具比如编译器、计算器、规则引擎。这里要特别强调一个坑近两年已经有多项研究指出纯靠模型自我批判并不总能提升准确性有些情况下甚至会把正确结果改成错误结果。原因很简单如果模型本身不具备识别错误的能力让它批判自己的答案也不会凭空获得这种能力。所以工程上验证信号的质量决定了整个迭代框架的上限。最可靠的做法是分层验证先让模型自评再用规则或工具做硬校验必要时引入更强的模型做最终仲裁。3.3 控制器与终止条件Controller控制器决定每一轮之后的动作继续迭代、停止输出或者重启到某个中间状态。终止条件是控制器里最重要的设计一般包括达到最大迭代次数硬性停止验证分数达到阈值提前停止相邻两轮答案不再变化说明已收敛Token 预算耗尽成本控制优先。缺少终止条件的多轮推理系统本质上是一个会持续消耗费用的循环必须从一开始就设好上限。3.4 记忆Memory第三个模块是记忆。多轮迭代中模型需要知道前几轮发生了什么上一版答案是什么、验证器指出了哪些错误、修改过哪些内容。最简单的方式是把所有历史拼进 Prompt但 Prompt 有长度限制轮数多了会截断或造成注意力分散。更规范的做法是维护一个结构化的迭代记录只保留“问题、当前答案、上轮批判”这三段关键信息历史详情单独存日志。这四个模块合在一起就构成了一个完整的迭代闭环生成器给出候选验证器打分找错控制器决定是否继续记忆保证每一轮修改有据可依。理解了这些模块后面的代码看起来就会非常直观。4. 环境准备与接口约定4.1 安装依赖本文代码只需要 Python 3.9 以上以及一个 OpenAI 兼容的 SDK。安装命令如下pip install openai如果你使用的是国内模型服务或本地部署的模型服务只要对方提供 OpenAI 兼容的 Chat Completions 接口代码几乎不用改换一下 base_url 和模型名即可。版本号请以你实际环境的依赖为准本文不绑定特定版本。4.2 统一模型调用入口为了让后面的递归、Self-Refine、投票代码不重复写 API 调用