这次我们不聊某个一键包而是一个在推理链路里很容易被忽略的方向Chained Recursive Language Models for Multi-Iteration Reasoning。简单说就是让语言模型把自己上一轮的输出作为下一轮输入反复迭代直到答案稳定。它能解决的核心问题是单次生成时模型容易在长逻辑链上“一步错步步错”而递归迭代可以给模型一次“回头改错”的机会。这个方法听起来不像一个开箱即用的 WebUI但实际上非常适合工程化。你不需要改模型权重不需要重新训练只需要在调用层写一个循环调度器就能把普通大模型的单次推理变成多轮自省式推理。更关键的是它天然适合接入现有本地部署环境任意 OpenAI 兼容接口、任意支持对话补全的模型都可以套用这套逻辑。这篇文章会把“链式递归语言模型”拆成一个可落地的实现方案。我会先讲清楚它的适用场景和边界再给出一套基于本地 LLM 的最小 Python 实现然后演示数学推理、代码修正、批量任务和 API 封装流程。整个链路都围绕“多迭代推理”展开你读完可以直接复制代码到自己的环境里跑。1. 核心能力速览能力项说明项目类型推理范式 / 提示词工程策略核心机制链式递归模型输出回流到输入多轮迭代主要应用数学推理、逻辑问答、代码调试、长文本结构化硬件要求取决于底座 LLM本地部署用量化小模型即可先行验证显存占用与模型参数量、上下文长度和量化方式有关需实测确认启动方式脚本方式运行或封装为 API 服务是否支持 CPU取决于底层模型和推理框架小模型可 CPU 推理速度较慢是否支持 API支持可封装 OpenAI 兼容接口是否支持批量任务支持脚本循环或并发队列均可依赖外部服务可选全部用本地推理框架可实现内网部署从这张表可以看出这个方法不挑模型不挑框架核心资产是一套“递归调用 停止条件 结果聚合”的调度逻辑。对于想快速验证大模型能力的团队来说这个方案的门槛比微调低得多。2. 适用场景与使用边界链式递归不是银弹。它适合解决需要“多步推导”和“自我修正”的任务典型场景包括数学应用题和逻辑推理题模型第一轮可能列错方程第二轮看到上一步结果后能主动修正。代码调试与代码审查让模型反复检查同一段代码每次只指出问题并给出修改版本。长文本信息抽取先抽取粗粒度信息再结合上一轮结果补全细节。复杂指令拆解把一个大任务拆成多个子步骤每个子步骤都由递归调度器校验。但递归也会放大模型本身的毛病使用边界必须明确不适合单轮对话延迟要求极高的场景。多迭代必然带来多次模型调用响应时间成倍增加。不适合模型事实性知识很弱的领域。如果底座模型本身不知道某类知识递归只会让错误越来越“自洽”。不适合包含个人隐私、未授权人脸信息、版权素材的任务除非你使用完全本地化的部署并确认数据使用边界。我建议所有使用该方法的人都把“模型输出会被再次送入模型”这一点当成一种数据处理行为。如果数据需要脱敏或授权必须在进入递归链路之前完成处理。3. 方法设计链式递归推理的完整流程链式递归推理的核心不是“多问几次”而是“有结构的循环”。一个最小可用的递归推理链路包含四个部分初始问题、历史轨迹、生成器、停止条件。初始问题输入 ↓ 第 1 轮LLM 生成答案 A1 ↓ 把问题 A1 拼接成新的 prompt ↓ 第 2 轮LLM 生成答案 A2 ↓ 把问题 A1 A2 拼接成新的 prompt ↓ 第 3 轮LLM 生成答案 A3 ↓ 判断 A3 与 A2 是否稳定 ↓ 是 输出最终结果与完整推理轨迹 ↓ 否 继续下一轮直到达到最大轮数这里的“历史轨迹”很关键。如果不把之前所有轮次的答案都放回上下文模型就看不到自己说过什么递归就退化成多次独立采样。多迭代推理的价值恰恰在于“基于先前假设继续推理”。3.1 停止条件设计停止条件决定了系统是快速收敛还是无限发散。推荐优先使用三种停止条件内容收敛连续两轮的最终结论一致或相似度超过阈值。显式终止标记要求模型每轮输出都以FINAL_ANSWER:开头一旦出现该标记就停止。最大轮数设置一个安全上限比如 5 轮防止死循环和 Token 爆炸。最稳的方案是“最大轮数兜底 内容收敛提前退出”。实际项目中我会把最大轮数设成 3 到 5 轮既保留修正空间又不会让成本和延迟失控。3.2 Prompt 模板设计每一轮的 Prompt 都包含三部分系统指令、原始问题、历史轨迹。系统指令可以写成这样你是一个严谨的推理助手。你会看到原始问题和此前多轮推理过程。 请基于前几轮的结果继续推理 1. 如果之前的推导有错误明确指出并给出修正。 2. 如果之前的推导正确补充更完整的理由。 3. 如果你确定最终答案请以 FINAL_ANSWER: 开头给出结论。这段 Prompt 不绑定具体模型。换模型时不需要改逻辑只需要微调语气和输出格式。4. 环境准备与前置条件在动手写代码之前需要先准备一个可用的 LLM 推理环境。这里给出一套通用检查清单操作系统Windows 10/11、Ubuntu 20.04、macOS 均可脚本使用 Python 3.9。GPU 环境NVIDIA 显卡建议安装 CUDA 和对应驱动没有 GPU 可以先用 CPU 跑小模型验证。推理框架推荐 Ollama、llama.cpp server、vLLM 等支持 OpenAI 兼容接口的方案。模型文件选择 7B 或更小的量化模型例如 Qwen2.5 7B Instruct 的 GGUF 版本。Python 依赖requests、pandas可选、fastapi可选、uvicorn可选。磁盘空间模型文件一般 4GB 到 8GB具体以实际下载文件为准。端口规划如果使用 Ollama 默认端口11434确保该端口未被占用。不需要把所有依赖一次性装齐。第一版先用requests或urllib调通接口再决定是否引入 FastAPI。这样排查问题时更简单。4.1 本地推理框架的启动方式以 Ollama 为例启动服务后默认监听127.0.0.1:11434。命令行启动方式如下ollama serve如果模型还没有下载先拉取一个开源模型ollama pull qwen2.5:7b如果你使用的是 llama.cpp 的 server 模式也可以启动 OpenAI 兼容接口./llama-server -m ./models/qwen2.5-7b-instruct-q4_k_m.gguf --host 127.0.0.1 --port 8080这里只给模板实际路径和模型名需要按你本地的文件调整。启动后用下面的命令验证接口是否可用curl http://127.0.0.1:11434/v1/models如果返回模型列表说明本地推理服务已经就绪。5. 最小实现基于 OpenAI 兼容接口部署递归推理下面这套代码是完整的递归推理调度器。它不依赖特定框架只调用 OpenAI 兼容的/v1/chat/completions接口。你只需要把base_url改成你本地推理服务的地址。5.1 定义单次对话函数import json import urllib.request import time def chat_once(messages, base_urlhttp://127.0.0.1:11434/v1/chat/completions, modelqwen2.5:7b, temperature0.3, max_tokens512): payload { model: model, messages: messages, temperature: temperature, max_tokens: max_tokens, stream: False } req urllib.request.Request( base_url, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json} ) with urllib.request.urlopen(req, timeout120) as resp: data json.load(resp) return data[choices][0][message][content]这个函数只做一件事发送 messages 列表返回模型的文本输出。把超时时间设成 120 秒是为了避免模型思考时间过长导致请求中断。5.2 构造递归推理主循环def recursive_reason(question, max_rounds4, stability_rounds2, base_urlNone, modelNone): history [] system_prompt ( 你是一个严谨的推理助手。你会看到原始问题和此前多轮推理过程。\n 请基于前几轮的结果继续推理\n 1. 如果之前的推导有错误明确指出并给出修正。\n 2. 如果之前的推导正确补充更完整的理由。\n 3. 如果你确定最终答案请以 FINAL_ANSWER: 开头给出结论。 ) for turn in range(1, max_rounds 1): messages [{role: system, content: system_prompt}] messages.append({role: user, content: f原始问题{question}}) for idx, previous_answer in enumerate(history): messages.append({role: assistant, content: previous_answer}) messages.append({ role: user, content: f请针对第 {idx 2} 轮继续推理或修正。 }) print(f第 {turn} 轮推理中...) answer chat_once(messages, base_urlbase_url, modelmodel) history.append(answer) if len(history) stability_rounds: last_two history[-stability_rounds:] if all(last_two[i] last_two[i 1] for i in range(len(last_two) - 1)): break return history这段代码把每一轮的历史答案都拼回 messages让模型看到自己的推理轨迹。当连续两轮输出完全一样时默认已经收敛提前退出循环。5.3 运行一个简单问题if __name__ __main__: question 一个农场里有鸡和兔子一共有 35 个头和 94 只脚。请问鸡和兔子各有多少只 trace recursive_reason( question, max_rounds4, stability_rounds2, base_urlhttp://127.0.0.1:11434/v1/chat/completions, modelqwen2.5:7b ) print(\n 完整推理轨迹 ) for i, step in enumerate(trace, 1): print(f\n--- 第 {i} 轮 ---\n{step})这个例子不需要改模型参数第一轮如果给出了正确方程第二轮大概率会直接确认最终答案。如果第一轮算错第二轮模型看到自己的过程后有很大概率会修正。6. 功能测试与效果验证递归推理不能“看起来有用”必须用可量化的测试验证。我把测试分成四类每一类都给出输入示例、预期结果和判断标准。6.1 数学推理测试测试输入小明有一些苹果他给了小红一半多一个还剩 5 个。请问小明原来有多少个苹果预期结果答案是 12。判断标准最终答案是否正确推理过程中是否出现“上一步错误”的自我修正。失败现象如果每一轮都给出不同答案说明模型本身对这类题不稳定应该降低 temperature 或换一个更大的模型。6.2 逻辑一致性测试测试输入三个人中只有一个人是凶手。A 说凶手是 BB 说凶手是 CC 说凶手不是我。已知只有一个人说真话。请问凶手是谁预期结果凶手是 C。判断标准输出的推理链是否覆盖三个人各自真假判断。注意点这类题容易因为模型“过度自洽”而一条路走到黑所以停止条件里的内容收敛反而可能是负作用。建议把这个测试单独跑一遍观察历史轨迹里是否出现“重新审视假设”的表述。6.3 代码调试测试测试输入一段有 bug 的 Python 函数。def max_value(nums): result 0 for n in nums: if n result: result n return result预期结果模型指出当 nums 全为负数时初始值0会导致结果错误并修正为result nums[0]或result float(-inf)。判断标准修正后的代码能否通过边界用例。建议代码调试是递归推理最实用的场景。模型单次审查可能漏掉边界条件但多轮迭代往往会逐步聚焦到关键问题。6.4 长文本结构化抽取测试测试输入一段包含公司名、产品名、时间、负责人姓名的会议纪要。预期结果模型先抽取粗粒度摘要再在后续轮次补全缺失字段最终输出结构化 JSON。判断标准JSON 字段是否完整是否出现重复字段或幻觉信息。失败风险长文本 多轮迭代会导致上下文迅速膨胀。如果超长建议只保留“上一轮抽取结果”而不是把所有轮次都塞回去。每一类测试跑完后把输出保存成文件。后续换模型或调整 Prompt 时用同一组测试用例做回归对比。7. 将递归推理封装为 API 服务与批量任务在真实工程里递归推理通常不是单独跑脚本而是封装成 API 服务让其他工具调用。下面用 FastAPI 给一个最小封装示例。7.1 安装依赖pip install fastapi uvicorn7.2 定义请求与响应模型from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ReasonRequest(BaseModel): question: str max_rounds: int 4 stability_rounds: int 2 base_url: str http://127.0.0.1:11434/v1/chat/completions model: str qwen2.5:7b class ReasonResponse(BaseModel): question: str trace: list用 Pydantic 做参数校验可以避免非法请求进入主循环。7.3 创建推理接口app.post(/reason, response_modelReasonResponse) def reason_api(req: ReasonRequest): trace recursive_reason( req.question, max_roundsreq.max_rounds, stability_roundsreq.stability_rounds, base_urlreq.base_url, modelreq.model ) return ReasonResponse(questionreq.question, tracetrace)启动服务uvicorn app:app --host 127.0.0.1 --port 8000然后用 curl 测试curl -X POST http://127.0.0.1:8000/reason \ -H Content-Type: application/json \ -d {question: 一个三角形的三个角分别是 2x, 3x 和 5x求 x 的值。, max_rounds: 3}如果返回 JSON 中包含完整的trace列表说明服务已经跑通。7.4 批量任务调度批量任务的实现比单次调用多一个队列维度。最简单的写法是顺序遍历questions [ 鸡兔同笼问题35 个头94 只脚。, 一段代码存在空指针风险请修复。, 从会议纪要中抽取行动项。 ] results [] for q in questions: trace recursive_reason(q, max_rounds3) results.append({ question: q, final_answer: trace[-1], rounds: len(trace) })如果问题数量大可以用线程池控制并发from concurrent.futures import ThreadPoolExecutor, as_completed def process(q): return {question: q, trace: recursive_reason(q, max_rounds3)} with ThreadPoolExecutor(max_workers4) as executor: futures [executor.submit(process, q) for q in questions] for future in as_completed(futures): result future.result() print(result[question], -, result[trace][-1])并发数量不要盲目拉高。如果所有请求都打到同一个本地推理服务显存和请求队列都会成为瓶颈。建议从 1 到 2 个并发开始测试逐步调大。7.5 失败重试与日志批量任务必须考虑失败重试。我给每个请求加一个简单包装def process_with_retry(question, max_retries3): for attempt in range(1, max_retries 1): try: return process(question) except Exception as e: print(fattempt {attempt} failed: {e}) time.sleep(2 ** attempt) return {question: question, trace: [], error: failed after retries}建议把每一轮推理的时间、Token 数、是否收敛都写到日志里。这样能快速定位“卡住”的任务到底是模型问题还是接口问题。8. 资源占用与性能观察递归推理的资源占用比单次推理高得多这是必须提前接受的事实。性能观察要关注三个维度显存、上下文长度、单请求耗时。8.1 显存占用观察方法在推理过程中用以下命令实时观察显存nvidia-smi -l 2如果显存不足优先检查两个因素模型的量化级别和上下文长度。同一个模型Q4 量化通常比 FP16 占用更低上下文越长KV Cache 占用越大。对于 7B 级别的模型4-bit 量化通常能放在小显存环境但具体数值请用nvidia-smi实测不要根据网上的“某某模型占用多少 G”直接做容量规划。8.2 上下文长度对性能的影响每多一轮递归历史文本就会增加一轮。假设每轮输出 500 个 Token5 轮就是 2500 个 Token 的历史再加上原始问题和系统提示词总上下文可能冲到 3000 Token 以上。如果问题本身是长文本上下文长度会增长得更快。上下文变长的直接后果是推理延迟增加。KV Cache 占用增加。模型注意力变散反而可能出现“尾段偏置”模型只关注最后几轮。应对方法是限制历史长度。只保留最近两三轮的推理内容而不是全部轮次。例如只把history[-2:]拼入 messages牺牲一部分完整度换取速度和稳定性。8.3 单请求耗时估算多迭代推理的单请求耗时约等于“单轮生成耗时 × 实际轮数”。如果单轮生成需要 5 秒4 轮就是 20 秒。优化方向有三个减少max_tokens让每一轮输出更短。使用更高吞吐推理框架比如 vLLM。使用“先收敛再停止”的策略避免无意义轮次。不要盲目调低 temperature 到 0。虽然低温度会让输出更稳定但也更容易陷入同一个错误答案。建议在 0.2 到 0.5 之间做小范围测试。9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后接口无法访问推理服务未启动或端口错误检查服务日志执行 curl 测试启动推理服务确认 base_url 端口请求一直超时模型单轮生成时间过长查看推理服务日志和 GPU 利用率增加 timeout或减少 max_tokens多轮迭代答案不收敛模型推理能力不足或问题本身过难用单轮回答做对比换更大模型或增加最大轮数上下文超长报错每轮历史答案全部拼入上下文查看报错中的 context length只保留最近两三轮历史或换长上下文模型显存不足模型过大或并发过多运行 nvidia-smi 查看显存占用降低并发数切换量化模型或减少上下文长度批量任务卡在某个问题单个请求阻塞在推理服务查看进程日志和任务重试次数给每个任务增加超时和重试机制输出格式越来越乱模型在长历史中失去指令跟踪能力检查每一轮输出格式在每轮 user 消息中重复格式要求或使用最终答案标记置信度高的错误答案反复出现模型陷入自洽错误对比不同 temperature 的输出用外部验证器检查答案不要只看模型自评排查时最忌讳一上来就改 Prompt。先看请求日志确认是模型问题、接口问题还是调度逻辑问题。如果是模型问题调整 Prompt 和 temperature如果是接口问题检查超时和并发配置。10. 最佳实践与使用建议以下是我个人在落地这类系统时会遵守的几条原则你可以直接抄到自己的项目里。10.1 先小参数验证再上大模型第一次测试不要直接上 70B 模型先用 7B 量化模型把调度逻辑跑通。问题集控制在 5 个以内max_rounds 设为 3。确认接口稳定、轨迹正确后再替换更大模型。10.2 保留一套最小可运行配置把以下内容固定为一个模板推理框架启动命令、模型名称、base_url、递归循环代码、测试用例。每次改动只动一个变量这样能快速定位是模型问题还是代码问题。10.3 用外部校验器替代“模型自评”递归推理最大的风险是模型对自己的错误答案“越看越顺眼”。如果任务有可计算的验证方式比如数学题、代码执行结果一定要把验证器放在系统外面。只有当验证器通过时才认为推理收敛。10.4 数据和权限管理如果系统会被多个业务方调用必须给 API 加上访问鉴权。本地推理服务默认绑定127.0.0.1不要直接绑定0.0.0.0暴露到公网。涉及他人肖像、声音、版权文本、未公开数据时必须确认授权和脱敏需求。10.5 输出复核机制递归推理不适合全自动化发布到生产环境。建议先输出到人工审核队列抽样检查最终答案和推理轨迹。尤其是代码生成、医疗、法律等高风险领域人工复核是不可省略的环节。11. 总结与下一步Chained Recursive Language Models for Multi-Iteration Reasoning 的核心价值不是让模型“多想几次”而是用结构化的递归调用把单次推理变成可回溯、可修正、可验证的多轮推理链路。它不需要重训模型不需要复杂基础设施只要有一个带有对话接口的语言模型就能用十几行 Python 完成第一版。建议你先跑通数学应用题和代码调试两个测试场景这是最容易看到效果的方向。最容易踩的坑是“上下文无限膨胀”和“模型自洽性错误”前者用历史裁剪解决后者用外部验证器解决。后续可以继续扩展的方向包括把多轮轨迹压缩成摘要喂给下一轮、结合代码执行器做“推理-执行-反馈”闭环、以及把该调度器接入业务系统作为统一的推理前置服务。如果你正在做本地部署或 API 集成这套递归调度逻辑可以直接作为中间层。建议收藏备用下次遇到模型“单次推理不够稳”的问题时再回来照着落地。