大模型中 reasoning_steps 完整深度解释
大模型中 reasoning_steps 完整深度解释
一、基础定义
reasoning_steps 直译:推理步骤 是大模型思维链(CoT, Chain-of-Thought)体系下的核心概念,指模型解决复杂问题时,拆解出来的有序、分步逻辑推导过程,每一步包含前提、推导、中间结论,最后汇总得到最终答案。
在 API、LangChain、Agent、OpenAI 兼容接口里,reasoning_steps 常作为返回字段、配置参数出现:
- 作为输出字段:模型返回的分步思考文本数组;
- 作为控制参数(如
reasoning_steps=5):强制模型做多轮深度推理; - Agent 场景:规划、工具调用、反思的每一轮动作都算一条 reasoning step。
二、两类核心场景:提示词层面 / API 返回结构化字段
1. 提示工程层面:人工引导生成 reasoning steps
通过 Prompt 强制模型先分步推理,再给答案,典型模板:
Solve the problem, output your reasoning steps one by one, then give final answer.
示例数学题: Question:A store bought 100 goods at $5 each, sold 60 at $8 each, the rest sold at $4 each. Calculate total profit.
plaintext
reasoning_steps = [
"Step1: Calculate total cost = 100 * 5 = 500 dollars",
"Step2: Income from first batch = 60 * 8 = 480 dollars",
"Step3: Remaining goods = 100 - 60 = 40 units",
"Step4: Income of remaining = 40 * 4 = 160 dollars",
"Step5: Total revenue = 480 + 160 = 640 dollars",
"Step6: Profit = total revenue - total cost = 640 - 500 = 140"
]
final_answer = "140 dollars profit"
优势:解决多步计算、逻辑推理、规划类问题,大幅降低模型幻觉、计算错误。
2. 结构化 API 返回字段(主流推理模型 DeepSeek-R1、Qwen-R1、OpenAI o1)
新一代思考型模型会原生输出结构化 JSON,内置 reasoning_steps 数组,区分思考内容和最终回答:
json
{
"reasoning_steps": [
"首先判断用户需求是对比Ollama和LM Studio在Mac的性能差异",
"第一步梳理底层推理引擎:LM Studio默认MLX,Ollama仅llama.cpp Metal",
"第二步对比内存占用、token生成速度差异",
"第三步区分适用开发场景与纯聊天场景",
"总结给出两种软件搭配使用方案"
],
"answer": "日常聊天测试用LM Studio,开发API服务用Ollama,两者可共存"
}
- 分离推理文本与正式回答,便于程序单独解析思考过程做校验、日志、反思;
- Agent 框架(LangGraph、CrewAI)会把工具调用、反思、纠错每一轮存入
reasoning_steps。
三、参数化控制 reasoning_steps(深度推理配置)
很多推理大模型支持传入参数 reasoning_steps=N,N 为正整数,含义:
强制模型至少执行 N 轮独立推理思考,再输出答案。
举例:
reasoning_steps=1:简单直答,几乎无拆解;reasoning_steps=3~5:日常逻辑题、阅读理解标准档位;reasoning_steps=8~12:复杂数学、代码推导、商业方案、多工具 Agent 规划。
参数影响
- 数值越大:推理越细致,幻觉越少、复杂题正确率提升;
- 代价:token 消耗翻倍、推理耗时变长、费用更高。
四、和相关核心术语区分(极易混淆)
-
reasoning_steps vs CoT(Chain-of-Thought)
- CoT:是一套提示方法 / 技术范式(思维链技术);
- reasoning_steps:是 CoT 落地后产出的分步内容载体,是结果。 关系:使用 CoT 提示 → 模型生成 reasoning_steps。
-
reasoning_steps vs thinking_process
- thinking_process:通用统称 “全部思考过程”,不分段;
- reasoning_steps:有序拆分、编号、逐条独立的分段思考,结构化。
-
reasoning_steps vs tool_call_steps(Agent 专用)
- reasoning_steps:纯文本逻辑推演;
- tool_call_steps:调用检索器、计算器、代码解释器等工具的执行步骤,属于特殊子类 reasoning step。
五、技术价值(为什么需要 reasoning_steps)
- 可解释性 不再黑盒输出答案,能逐条校验模型哪一步逻辑出错,定位幻觉来源;
- 迭代纠错(Self-Reflection 自反思) 程序读取
reasoning_steps,发现计算 / 逻辑漏洞后,送入模型重新修正推理步骤; - 复杂任务拆解 多步骤数学、多文档 RAG、多工具 Agent 必须依靠分步推理,一步直达极易出错;
- 流程标准化解析 代码、LangChain 可遍历
reasoning_steps数组,做日志存储、打分、合规审查。
六、两种工业级应用场景
场景 1:本地大模型 / 推理 API 开发
后端配置 return_reasoning_steps: true,接口返回分步推理,用于业务日志审计、错题复盘。
场景 2:AI Agent 智能体
Agent 完整流程全部记录进 reasoning_steps:
- 分析用户需求
- 判断是否需要调用工具
- 调用搜索 / 计算器
- 整合工具结果二次推理
- 整理最终回复 每一条动作单独作为一条 step,完整记录智能体全部决策链路。
七、限制与缺点
- 增加 token 消耗,推理成本、延迟上升;
- 简单问答(翻译、短句摘要)不需要,多余推理浪费资源;
- 小参数量模型(7B 及以下)容易出现冗余、无意义的虚假推理步骤(伪 CoT);
- 部分闭源模型(旧版 GPT-3.5)不支持结构化
reasoning_steps字段,只能纯文本输出。
八、极简总结
reasoning_steps 是大模型解决复杂问题时拆分后的有序分步逻辑数组:
- 人工提示词可引导生成;
- 深度推理模型原生结构化输出;
- 可通过参数控制推理步数;
- 用于提升正确率、提供可解释性、支撑 Agent 自反思与工具调用。
更多推荐



所有评论(0)