当用大语言模型处理多步推理问题时最常见的翻车方式不是完全不会而是“会一半”前面几步的逻辑完全正确越到后面越容易跑偏最终答案往往和标准答案差之毫厘。如果你在数学应用题、逻辑推理、计划生成或者代码调试场景中频繁遇到这类问题本文要讨论的 Chained Recursive Language Models链式递归语言模型以下简称 C-RLM或许能提供一条新的解决思路。这类方法的出发点很朴素既然人类解复杂问题时也会反复检查、来回修改为什么不让语言模型也具备“把自己的答案再拿回来重新审视”的能力C-RLM 正是把模型自身的输出重新作为输入通过多轮迭代逐步修正推理过程最终得到更可靠的答案。本文会从概念讲起逐步拆解它的核心机制并给出一套可以直接运行的 Python 原型代码适合正在做大模型应用开发、RAG 系统优化或者推理增强方向研究的读者。1. 背景单次推理为什么不够用1.1 大模型推理的“一步到位”问题大语言模型的生成过程本质上是自回归的模型根据已经生成的 token 预测下一个 token一遍生成到底。这种架构天然适合文本生成但也带来了一个问题——模型在生成过程中没有“回头检查”的机会。当任务只需要一两步推理时影响不大但当任务需要十步、二十步逻辑推导时前面任何一步的小错误都会在后面被不断放大而且模型自己并不知道已经错了。你可以做一个简单的实验让模型直接回答一道稍复杂的数学应用题它通常能写出漂亮的解题过程但中间某一步的加减乘除一旦出错最终答案就完全偏离。更麻烦的是如果你把它生成的错误答案原样发回去让它“再检查一遍”它有时会坚持自己的错误有时又会改出一个新的错误。这说明单轮生成、单轮校验的模式并不稳定需要一套更结构化的多迭代机制来约束和引导模型自我修正。1.2 什么是 Chained Recursive Language ModelsChained Recursive Language Models 的核心思想是把同一个语言模型或者一组同质模型组织成一条递归链模型先生成一个初始答案然后对答案进行评审再根据评审意见改写答案改写后的答案又进入下一轮评审如此循环往复。这里的“Chained”强调多轮迭代的链式结构“Recursive”强调每一轮都在使用前一轮的输出作为输入形成一种自我引用的递归关系。用一句话概括C-RLM 不是一个新的基础模型而是一种推理时inference-time的组织策略。它让模型同时扮演“解题者”和“评审者”两个角色通过多轮自我对弈来逼近正确答案。这种思路在数学推理、逻辑谜题、规划任务等场景中尤其有效因为这些任务的正确性是可以被检验的评审环节能够提供真实有效的反馈信号。1.3 典型应用场景C-RLM 适合那些“答案可以验证、过程可以逐步讨论”的任务典型的场景包括数学应用题与符号推理每一步计算都能被复核错误点容易定位。逻辑谜题与约束满足问题模型可以先给出一个尝试方案再逐条检查约束是否满足。代码生成与调试生成的代码可以编译、运行报错信息就是天然的评审信号。复杂规划与任务拆解先给一个总体计划再逐步骤检查资源、顺序和依赖关系。结构化信息抽取模型把抽取结果输出为 JSON校验规则可以自动检查字段完整性。需要注意的是C-RLM 并不适合所有任务。对于开放性写作、创意发散等没有唯一正确答案的场景多轮递归修改反而可能破坏初稿的自然性和多样性。2. 与主流推理增强方法的对比2.1 Chain-of-ThoughtChain-of-ThoughtCoT思维链是目前最广为人知的推理增强方法它通过提示模型“一步一步思考”来激发中间推理过程。CoT 的优点是简单、直接、无需训练但它本质上是单轮生成模型在 one pass 内完成推理没有反馈修正的机会。一旦中间步骤出错后续推导会沿着错误路径继续走最终答案往往错得“很有逻辑”。C-RLM 可以理解为 CoT 的迭代化扩展。它保留了解题过程的显式输出但增加了评审和改写环节让模型有机会在中间步骤出现错误时及时纠偏。二者并不冲突实际落地时通常会在 C-RLM 的每一轮调用中同时使用 CoT 提示让模型先展示推理过程再给出结论。2.2 Self-ConsistencySelf-Consistency自我一致性的思路是多次采样不同的推理路径然后对最终答案进行投票选择出现频率最高的结果。它通过统计的方式降低单次采样的随机性适合答案唯一、可比较的任务。Self-Consistency 与 C-RLM 的一个重要区别是多次采样得到的推理路径彼此独立没有一条路径会参考另一条路径的结论。而 C-RLM 的多次迭代是串行的、相互依赖的后一轮会明确看到前一轮的推理和评审意见。实际操作中二者也可以组合使用对每条递归链分别采样多次再对不同链的最终答案做投票聚合这样既保留迭代修正能力又利用统计投票提升稳定性。2.3 Self-Refine 与 ReflexionSelf-Refine 是较早提出的自我优化框架核心流程也是“生成 → 反馈 → 改写”但通常只做一到两轮没有形成严格的递归链。Reflexion 则更偏向强化学习场景模型会把失败经验以文本形式记录到“记忆”中在后续尝试时参考这些经验它强调的是跨 episode 的学习。C-RLM 和这些方法同属“自我修正”家族区别在于工程化程度C-RLM 把递归链的长度、停止条件、验证机制都作为显式参数来设计更强调在有限预算下稳定地逼近正确答案。你可以把 C-RLM 看作一种把自我修正推向极致的基础框架Self-Refine 和 Reflexion 中的经验记忆机制可以在 C-RLM 的评审环节中以“历史记录”的形式加入。2.4 对比小结下面用一个表格梳理上述方法的差异方便在选型时快速判断方法是否多轮迭代反馈来源是否参考旧答案典型成本Chain-of-Thought否无否低Self-Consistency否多次并行无否中Self-Refine是通常 1-2 轮模型自评是中Reflexion是外部信号 记忆是高Chained Recursive LM是可配置多轮模型自评/外部验证器是中高需要注意的是这里的“成本”既包括 token 消耗也包括延时。递归链越长单次请求的延迟和花费就越高因此在实际应用中必须给迭代轮数设置上限。3. 实验环境准备3.1 运行环境与依赖本文的示例代码使用 Python 编写并基于 OpenAI 兼容的 API 接口调用语言模型。选择这种方案是因为它不绑定具体的模型厂商无论是本地部署的 vLLM 服务、Ollama还是云端提供的 OpenAI 兼容接口都可以通过统一的base_url和api_key接入方便在不同的实验环境中切换。版本方面没有特别苛刻的要求建议使用 Python 3.10 及以上版本openaiPython SDK 使用 1.x 版本即可。如果你希望完全离线实验也可以把代码中的远程调用替换为本地 transformers 模型但那样需要额外准备 GPU 资源和模型权重本文不再展开。3.2 项目结构我们把整个原型项目组织成下面的目录结构便于后续扩展c_rlm_demo/ ├── requirements.txt ├── c_rlm_demo.py └── README.mdrequirements.txt里面只需要两个核心依赖openai1.30.0 python-dotenv1.0.0python-dotenv用来加载环境变量你也可以不加这个依赖直接在系统环境变量里配置LLM_API_KEY和LLM_BASE_URL。为了降低上手门槛下面的代码在实现时自动读取环境变量如果环境变量不存在则使用默认值。4. 核心机制拆解4.1 递归循环的构造C-RLM 的基本循环可以拆成三个角色解题者Generator、评审者Critic、改写者Refiner。在具体实现中这三个角色可以由同一个模型承担只是使用不同的提示词模板。循环流程如下解题者根据原始问题生成初始答案。评审者检查答案的推理过程输出问题定位和修改建议如果答案正确则输出通过标记。改写者结合原始问题、旧答案和评审意见生成新答案。新答案替代旧答案回到第 2 步直到满足停止条件。从数学角度看每一轮递归可以抽象为A_{t1} Refine(Question, A_t, Critique(Question, A_t))。也就是说下一轮的答案A_{t1}是上一轮答案A_t和评审结果共同作用的结果。这种结构让模型能够在每一轮都“看到”自己的历史而不是盲目地重新回答。4.2 停止条件设计递归循环最怕两件事一是无限循环二是提前终止导致修正不充分。因此停止条件必须同时考虑“何时继续”和“何时停止”。常见的停止条件包括达到最大迭代轮数max_iters这是最基础、最可靠的兜底条件。评审者输出明确的通过标记例如“PASS”或“答案正确”。连续两轮答案完全相同说明模型已经收敛继续迭代大概率不会改变结果。调用外部验证器如代码执行结果、规则校验结果只有验证通过才终止。实际工程中以上条件通常组合使用。尤其要强调最大轮数上限因为模型可能在同一个错误上来回横跳如果不设上限一次任务可能消耗几十次 API 调用。4.3 验证与结果抉择评审者的可靠性直接决定递归修正的质量。如果评审者只是笼统地说“请再检查一下”改写者往往不知道改哪里。反之如果评审者能明确指出“第三步计算错误37 乘 8 应该等于 296 而不是 292”改写者的修正就会非常精准。一种更稳健的做法是引入外部验证器。例如数学题可以用表达式求值器验证数值代码题可以真正执行代码看是否通过测试用例结构化抽取题可以用 JSON Schema 校验。外部验证器提供的反馈是确定性的不依赖模型的主观判断建议在条件允许时优先使用。如果只能依赖模型自评则可以通过多次评审投票来降低误判率。4.4 关键参数与调优下面几个参数对 C-RLM 的效果影响最大实际调优时需要重点关注参数作用调优建议max_iters控制递归深度数学题 2-4 轮即可过多会显著增加成本temperature控制生成随机性初始生成可设 0.7评审可设 0.2 左右max_tokens控制单次输出长度需根据题目复杂度调整避免答案被截断评审粒度决定反馈质量要求评审者指出具体步骤和行号而非泛泛而谈验证阈值决定多轮投票的通过条件视任务对准确率的要求而定需要提醒的是这些参数没有固定最优值。不同模型的能力差异很大有些模型在 2 轮迭代后就收敛有些模型则需要 4 轮甚至更多。建议在小规模样本上先做一轮参数扫描观察“准确率-成本”曲线再决定线上使用哪组参数。5. 完整实战多迭代数学推理原型5.1 Prompt 设计我们先设计三个 Prompt分别对应解题者、评审者、改写者三个角色。注意评审者的 Prompt 要求它输出“PASS”表示通过这个标记会被代码用来判断是否提前终止。SOLVE_PROMPT 请一步一步解决下面的问题最后给出一个明确的结论并把你认为的最终答案单独放在一行格式为“最终答案XXX”。\n问题{question} CRITIC_PROMPT 你是一名严谨的评审员。请检查下面问题对应答案的推理过程是否正确是否存在计算错误、逻辑跳跃或遗漏条件。 如果答案正确且推理完整请仅输出“PASS”。 如果存在问题请指出具体问题并给出修改建议。\n问题{question}\n答案{answer} REFINE_PROMPT 根据评审意见重写下面问题的答案。要求保留正确的推理部分修正错误并补充缺失步骤。 最终答案仍是单独一行格式为“最终答案XXX”。\n问题{question}\n原答案{answer}\n评审意见{critic}5.2 完整代码实现下面是完整的 Python 原型代码文件路径为c_rlm_demo/c_rlm_demo.py。代码实现了三个核心功能单次解题、递归修正、多轮投票。# c_rlm_demo.py import os from collections import Counter from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY, EMPTY), base_urlos.getenv(LLM_BASE_URL, http://localhost:8000/v1), ) MODEL os.getenv(LLM_MODEL, your-local-model) SOLVE_PROMPT 请一步一步解决下面的问题最后给出一个明确的结论并把你认为的最终答案单独放在一行格式为“最终答案XXX”。\n问题{question} CRITIC_PROMPT 你是一名严谨的评审员。请检查下面问题对应答案的推理过程是否正确是否存在计算错误、逻辑跳跃或遗漏条件。 如果答案正确且推理完整请仅输出“PASS”。 如果存在问题请指出具体问题并给出修改建议。\n问题{question}\n答案{answer} REFINE_PROMPT 根据评审意见重写下面问题的答案。要求保留正确的推理部分修正错误并补充缺失步骤。 最终答案仍是单独一行格式为“最终答案XXX”。\n问题{question}\n原答案{answer}\n评审意见{critic} def call_llm(user_prompt, temperature0.6, max_tokens1024): 调用 OpenAI 兼容接口返回模型生成的纯文本内容。 resp client.chat.completions.create( modelMODEL, messages[{role: user, content: user_prompt}], temperaturetemperature, max_tokensmax_tokens, ) return resp.choices[0].message.content.strip() def solve_once(question): 单轮解题作为递归链的初始答案。 return call_llm(SOLVE_PROMPT.format(questionquestion)) def recursive_refine(question, max_iters3, verboseFalse): 执行链式递归生成 - 评审 - 改写直到通过或达到最大轮数。 answer solve_once(question) history [(initial, answer)] if verbose: print([第 0 轮 初答]) print(answer) print(- * 50) for i in range(1, max_iters 1): critic call_llm( CRITIC_PROMPT.format(questionquestion, answeranswer), temperature0.2, ) if verbose: print(f[第 {i} 轮 评审]) print(critic) if PASS in critic: if verbose: print(评审通过提前终止。) break answer call_llm( REFINE_PROMPT.format(questionquestion, answeranswer, criticcritic), temperature0.5, ) history.append((frefine_{i}, answer)) if verbose: print(f[第 {i} 轮 改写]) print(answer) print(- * 50) return history, answer def extract_final(text): 从模型输出中提取“最终答案”那一行的内容。 for line in text.splitlines(): if line.startswith(最终答案): return line.split(, 1)[-1].strip() return text.strip().splitlines()[-1] if text else def multi_round_vote(question, n_rounds5, max_iters2, verboseFalse): 并行运行多条递归链对最终答案进行多数投票。 final_answers [] for r in range(n_rounds): _, final_answer recursive_refine(question, max_itersmax_iters, verboseverbose) final_answers.append(extract_final(final_answer)) counter Counter(final_answers) best, count counter.most_common(1)[0] return best, count, len(final_answers), dict(counter) if __name__ __main__: question 一个两位数十位数字是个位数字的 3 倍如果把十位数字与个位数字互换得到的新数比原数小 36。求原数。 best, count, total, dist multi_round_vote( question, n_rounds5, max_iters2, verboseTrue ) print( * 50) print(f候选答案分布{dist}) print(f最终多数投票结果{best}{count}/{total} 轮支持)5.3 运行与预期输出运行前先设置环境变量然后执行脚本export LLM_API_KEYyour-api-key export LLM_BASE_URLhttp://localhost:8000/v1 export LLM_MODELyour-model-name python c_rlm_demo.py如果你使用的是某些新版 OpenAI 兼容接口max_tokens参数可能被更名为max_completion_tokens遇到参数报错时按接口文档调整即可。脚本正常运行时会输出每一轮的初答、评审意见和改写结果最后打印多轮投票的分布。以这道“两位数十位是个位三倍换位后小 36”的题目为例预期最终答案应该是 62。标准解题过程是设个位为 x十位为 3x原数为 30x x 31x换位后为 10x 3x 13x差值为 18x 36所以 x 2原数为 62。5.4 结果解读与扩展通过 verbose 输出你可以直观地看到递归修正的价值初始答案可能只是“看起来合理”评审者会指出具体哪一步不对改写者随即修正。运行多条递归链后多数投票会过滤掉偶发的错误答案让系统整体更加稳定。这个原型虽然是针对数学题的但框架本身是通用的。只要替换掉三个 Prompt并调整extract_final的解析逻辑就能迁移到代码调试、逻辑推理、规划生成等场景。比如做代码调试时可以把评审者换成真实编译器让模型根据错误信息改写代码效果会比纯模型自评好得多。6. 常见问题与排查思路在实际调用 C-RLM 时开发者最容易遇到的几个问题整理如下可以对照排查问题现象常见原因解决思路多次迭代后答案不变模型已收敛或评审信号对改写没有帮助检查评审是否过于笼统尝试提高评审温度让反馈更多样评审者一直不输出 PASS“PASS”触发条件过于严格放宽为“答案正确”“通过”等关键词匹配或引入外部验证器答案越改越差模型过度修改正确部分降低改写温度限制改写轮数增加“仅修改被指出的问题”约束Token 消耗过大递归轮数过多或输出长度不受控设置max_iters上限压缩历史答案长度只传最新一轮结果解析最终答案失败模型没有按指定格式输出在 Prompt 中强调格式增加格式校验和重试逻辑不同轮次答案冲突模型随机性高递归链不稳定增加投票轮数统一评审标准使用更低温度一个值得注意的排查技巧是把每一轮的历史记录保存下来逐轮检查“评审意见是否准确”和“改写是否落实了评审意见”。很多时候递归效果不好根源不在迭代次数而在于评审阶段根本没有找到真正的错误点。这时候需要升级评审 Prompt或者换一个更强的模型来承担评审角色。7. 最佳实践与工程建议7.1 成本与 Token 控制C-RLM 的成本随迭代轮数线性增长如果每条递归链跑 5 轮、投票又跑 5 次一次任务可能消耗几十次模型调用。上线前一定要做成本估算并设置两层熔断单条链最大轮数以及单任务总预算。对于成本敏感的场景可以先跑max_iters1的轻量版本对比准确率后再决定是否加深。7.2 让模型输出结构化结果评审意见和最终答案最好使用结构化的输出格式例如 JSON。评审者可以输出包含is_correct、error_points、suggestion三个字段的 JSON改写者则按这些字段逐一修正。结构化输出不仅方便程序解析也能强迫模型把“判断”和“理由”分开减少含糊表述。critic_json_schema 请输出如下 JSON { is_correct: true/false, error_points: [错误的步骤描述], suggestion: 修改建议 }7.3 引入独立的验证器模型自评天然存在“认知盲区”模型可能既做错题又认为自己是对的。因此在条件允许的情况下尽量引入独立的确定性验证器数学题用表达式计算结果校验代码题用真实测试用例验证数据抽取题用规则校验字段合法性。外部验证器的反馈可以作为最高优先级信号直接决定递归是否继续。7.4 日志、缓存与可回放递归链条的中间状态非常有价值。建议把每一轮的 question、answer、critic、refined_answer 完整记录到结构化日志中既方便排查问题也可以作为后续训练评审模型或改写模型的数据集。同时对于相同的输入问题建议做结果缓存避免重复消耗 API 额度。7.5 安全与合规提示调用大模型 API 时要确保使用的是合法授权的接口和密钥不要在日志中记录敏感的业务数据。如果 C-RLM 应用在金融、医疗等对准确性要求极高的领域必须加入人工审核环节不能完全依赖模型自我修正的结果。此外递归迭代会放大模型的输出如果模型本身存在偏见或错误知识多轮修正反而可能让错误更加根深蒂固因此上线前需要对基座模型做充分的评估。8. 总结与后续学习方向Chained Recursive Language Models 本质上是把“生成-评审-改写”这个人类常用的解题循环显式化为模型推理流程它解决的是单轮生成无法自我纠错的核心痛点。本文从概念、方法对比、核心机制到完整代码带你把一个多迭代推理原型跑通并且给出了成本控制、停止条件、外部验证器等工程化建议。如果你准备继续深入有几个方向值得关注一是把评审者升级为独立训练的小模型用更低的成本获得更稳定的反馈二是把递归链扩展成树形搜索类似 Tree of Thoughts 那样在多个分支上并行探索三是把多轮修正的历史数据用于强化学习微调让模型学会在内部隐式地完成自我修正。对于实际项目建议先在你自己最头痛的推理任务上跑通这个最小原型记录准确率和成本再决定是否值得投入更多的工程资源。如果本文对你有帮助可以收藏备用也欢迎在实际业务中验证这套递归推理方案的收益。