本文深入浅出地介绍了4种提升大模型推理能力的范式CoT让模型边写边想、ReAct让模型边想边查、ToT让模型多线程搜索、结构化输出让模型结果更规范。从零成本实验到真实应用手把手教你如何通过简单的提示词改造和工具链接入让大模型的正确率实现指数级增长。无论是编程小白还是经验丰富的开发者都能从中找到提升模型推理能力的实用方法。让一个成年人心算 37 × 48他得盯着天花板想好久递给他纸和笔一边写一边算不仅更快基本也不会出错。大模型也是个爱心算的人——一口气往下写写完也不改中间连打草稿的地方都不留。说白了推理范式就是往模型手里塞东西塞一支笔写草稿CoT、塞一部电话问事实ReAct、塞一张能擦的草稿纸想岔了能退回来ToT、最后塞一张标准表格让推理被程序读走。同一个模型、换一种想问题的方式正确率能差出十几倍。接下来就让我们一起看一看一句让我们一步步思考凭什么让正确率翻几倍推理到一半怎么顺手查一次真实数据想岔了能不能退回来那三十行 ReAct 循环又为什么非得手写一遍一、CoT先给它一支笔1.1 一个几乎零成本的实验先看两段提示词内容完全相同只差最后一句【A】商店原有 24 个苹果上午卖出 3 箱、每箱 8 个下午又进货 15 个现在还剩多少个答【B】商店原有 24 个苹果上午卖出 3 箱、每箱 8 个下午又进货 15 个现在还剩多少个 让我们一步步思考。差别只有一句话。但 Kojima 等人在 2022 年的论文《Large Language Models are Zero-Shot Reasoners》里给出的数据是这样的任务直接回答加上Let’s think step by stepGSM8K小学数学应用题10.4%40.7%MultiArith算术应用题17.7%78.7%测试模型是当时的 text-davinci-002175B。同一批题、多了一句话正确率翻了几倍。Note论文测的是英文原句中文场景用让我们一步步思考这类等效指令也能起效但增益幅度需用自己的测试集验证。这不是模型变聪明了而是你终于允许它把草稿打出来。1.2 为什么写出来就真的准了一句提示词凭什么有这么大威力三个层面① 中间结果变成了可见输入。 下一个 token 只能基于已生成的内容预测写出来的中间结果就成了下一步推理可复用的输入——心算时它只存在于隐藏状态里稍纵即逝。② 把计算摊到更多次前向传播上。 串行计算步数受层数上限约束一步到位只能硬算摊成一个个 token计算量就分散到了更多生成步里。③ 它见过海量的人类解题过程。 网上的解题过程、代码注释几乎都是一步步写的给出同样的形式它就更可能落回认真解题的状态。用 Java 类比模型默认的输出是return computeAnswer(input);——一行表达式硬算到底。CoT 相当于让它改成方法调用链先算中间变量、打印日志、再返回结果。日志不是废话日志就是它的工作内存。1.3 CoT 的三种强度按需选方式做法成本什么时候用Zero-shot CoT加一句让我们一步步思考几乎为零默认先试这个Few-shot CoT给几个带完整推导的示例原论文用 8 个提示词变长步骤有特定格式要求时Self-Consistency温度调高采样 N 条推理路径对答案投票N 倍答案可比较且错误是随机的Self-Consistency 的实现骨架Java 开发者一眼就懂// 采样 N 条推理路径取出现次数最多的答案 public String selfConsistent(String question, int n) { MapString, Integer votes new HashMap(); for (int i 0; i n; i) { // 温度调高让每次推理路径都不一样 String reasoning chat(question /n让我们一步步思考, 0.7); votes.merge(extractFinalAnswer(reasoning), 1, Integer::sum); } return votes.entrySet().stream() .max(Map.Entry.comparingByValue()) .map(Map.Entry::getKey) .orElseThrow(); }关键点只有最终答案参与投票推理路径各不相同——多条独立路径同时出错的概率远低于单条出错。WarningSelf-Consistency 只对答案可以投票的任务有效——数值、选项、分类标签。写作文、写代码没用投票投不出更好的代码。1.4 三个真实的坑Warning坑一CoT 是规模涌现的能力。 收益要等模型规模足够大才显现。小模型上输出可能只是一堆像推理的废话比直接作答还差——上生产前用自己的测试集验证。坑二不是所有任务都该思考。 分类、信息抽取、格式转换这类任务硬加推理步骤模型会在推理里编出原文根本没有的依据。正确做法是低温度 结构化输出。坑三最要命推理的时候模型接触不到任何新信息。 不知道订单的真实状态它会一本正经地写下订单 ORD-123456 已于昨日发货因此……“再基于编造的结论往下推。CoT 会让幻觉变得更有逻辑”而不是更少。这正是 ReAct 要解决的问题让推理过程能够从外部世界拿到事实。二、ReAct再把电话递给它2.1 Thought → Action → ObservationReAct 是 “Reasoning Acting” 的缩写Yao 等人2022ICLR 2023。它的核心就是一个循环CoT 的推理只依赖模型自己写下的内容ReAct 在推理之间插入了行动每一步思考都多了一次拿外部事实的机会。用户问我买的鞋子今天降价了能退差价吗纯 CoT 会编出一套看起来合理的退差价规则ReAct 则先调queryOrder查订单、再调queryPricePolicy查价格保护规则两个事实到手才生成答复。少了哪个工具这条链就断在那里而不是靠编补上。2.2 手写一遍 ReAct 循环框架把循环藏起来了。先不用框架用最朴素的方式写出来——整个实现只有四块工具定义、提示词、循环、解析。第一步定义工具。 名字和描述是写给模型看的执行函数是你的业务代码// 描述里的参数说明是给模型看的不是给人看的 public record ToolSpec(String name, String description, FunctionMapString, String, String handler) { } MapString, ToolSpec tools Map.of( queryOrder, new ToolSpec( queryOrder, 查询订单状态。参数 orderId形如 ORD-123456。仅在用户询问订单或物流时调用。, args - { String orderId args.get(orderId); if (orderId null || !orderId.matches(ORD-//d{6})) { // 错误信息要写成模型能照着改的形式 return ERROR: orderId 格式不正确应为 ORD-123456 格式; } return 订单 orderId 已发货预计明天 18:00 前送达; }) );第二步把格式约定写进系统提示词String buildSystemPrompt(CollectionToolSpec tools) { StringBuilder sb new StringBuilder( 你是一个可以调用工具的助手。每次只输出一轮格式严格如下 Thought: 现在缺什么信息、该调哪个工具 Action: 工具名 Action Input: JSON 对象如 {orderId:ORD-123456}} 收到 Observation 后继续下一轮。信息足够时改用 Final Answer: 给用户的最终回答 可用工具 ); for (ToolSpec t : tools) { sb.append(- ).append(t.name()).append().append(t.description()).append(/n); } return sb.toString(); }第三步循环本体。 这就是 ReAct 的全部——一个 while 循环public String run(CollectionToolSpec tools, String question, int maxSteps) { MapString, ToolSpec registry tools.stream() .collect(Collectors.toMap(ToolSpec::name, Function.identity())); // 模型是无状态的每一轮都要把完整上下文重新发过去 String context Question: question /n; for (int step 0; step maxSteps; step) { // ① 硬性步数上限 String output chat(buildSystemPrompt(tools), context); // temperature 0.0 if (output.contains(Final Answer:)) { return output.substring(output.indexOf(Final Answer:) 13).trim(); } String action extract(output, Action:); String input extract(output, Action Input:); if (action null || input null) { // 格式跑偏把错误提示塞回去让模型重来 context output /nObservation: 输出格式错误请严格按 Thought / Action / Action Input 格式重新输出/n; continue; } ToolSpec tool registry.get(action); String observation (tool null) ? ERROR: 不存在工具 action 可用工具 registry.keySet() : executeSafely(tool, input); // ② 解析 JSON 超时 异常兜底 context output /nObservation: observation /n; // ③ 结果回灌上下文 } return 任务超过 maxSteps 步仍未完成已终止。; }第四步也是最脏的一步——解析String extract(String text, String label) { int start text.indexOf(label); if (start 0) { return null; } String rest text.substring(start label.length()).trim(); int end rest.indexOf(/n); return (end 0 ? rest : rest.substring(0, end)).trim(); }这三十行就是 ReAct 的全部骨架。 跑通它之后你会发现一个残酷的事实真正花时间的不是循环而是那个extract()。Function Calling 不是 ReAct 的替代品现代生产里你几乎不会真的去解析Action:文本——原生 Function Calling 和 LangChain4j 的Tool只是把 Action 那一步交给了模型的训练对齐层你拿到的是现成的函数名和参数对象。但循环还是那个循环模型决定调什么 → 你的代码执行 → 结果回灌 → 模型决定下一步。手写一遍的价值是让你看得懂框架日志里那串tool_calls为什么会在某一步卡住。2.3 手写之后才看得见的四个坑坑真实现象处理方式格式漂移写成中文冒号Action、把参数写成queryOrder(orderIdORD-123456)的函数调用风格、给 JSON 套一层 markdown 代码块改解析器治标换原生 Function Calling 治本死循环反复调用同一个工具、同一个参数一轮轮烧 TokenmaxSteps硬上限 (工具名, 参数)去重检测重复即终止并转人工错误不会自愈工具返回异常后模型继续顺着编返回结构化错误原因 该怎么改而不是空串或堆栈上下文越滚越长每一轮的 Observation 都堆进上下文Token 成本指数增长只保留最近 N 条 Observation更早的用摘要替换死循环让 Agent 无限循环等于让一个不确定的程序烧你的 Token 预算。maxSteps不是优化项是安全项——给它一个和线程池设队列长度同级别的硬边界再叠一层(工具名, 参数)去重因为模型卡住时往往就是原地打转。错误自愈工具失败时返回ERROR: orderId 格式不正确应为 ORD-123456 格式模型下一轮大概率会改对参数返回空串或一段 Java 堆栈它只能瞎猜。错误信息是写给模型看的调试信息。2.4 ReAct 的死穴ReAct 是一条直线走到底的每一步都建立在上一轮的结果上。它没有回头的机制。一旦中间某步错了——选错工具、填错参数、拿到个误导性结果——后面的推理就建立在错误前提上越走越远它也没法同时考虑几个方向一次只能选一个 Action。用 Java 类比ReAct 是单线程、且没有事务回滚的代码。 想让它具备回溯能力就得把一条链变成一棵树。三、ToT允许它擦掉重写3.1 一道 CoT 注定做不对的题经典题 Game of 24用 4、9、10、13 这四个数每个数恰好用一次通过加减乘除凑出 24。答案是(10 − 4) × (13 − 9) 24。这道题的关键在于第一步必须选对。模型只能走一步定一步一旦第一步选了4 9剩下的 10 和 13 怎么组合都凑不出 24——可它不会停下来会硬着头皮往下算最后给出一个错误的等式语气还很自信。ToT 论文的误差分析印证了这一点约 60% 的 CoT 样本在第一步生成第一个等式就已经错了后面几步全是错误前提上的无用功。用 Java 类比这不是计算能力不够这是贪心算法撞上了需要回溯的问题。3.2 把链变成树ToTTree of ThoughtsYao 等人2023的思路就是把一条线改成一棵树它靠三个组件协作评估器是 ToT 的灵魂。 它不出答案只判断这个中间状态有没有希望输出sure/maybe/impossible三档。判断有没有希望比算出正确答案简单得多模型做得到的概率也高得多——这才是 ToT 能 work 的根本原因用便宜判断换昂贵搜索。它的骨架就是一个带剪枝的 BFS每层生成候选 → 评估 → 只留最有希望的 top-b。这里的breadth就是用多少 Token 换多少正确率的旋钮——b5 比 b1 多出 29 个百分点的成功率代价是每层多生成和评估 5 倍候选。| ToT每层保留 5 个候选 | 74% |这张表里有两个必须记住的细节第一CoT 在这类题上比直接回答还差4.0% vs 7.3%。 一步步思考把它推上了一条一错到底的路还让错误看起来更有逻辑。推理范式用错场景比不用更糟。第二Self-Consistency 采样 100 条也只到 9.0%。 投票生效的前提是多数路径是对的而这道题里绝大多数路径从第一步就跑偏了——民主投票救不了系统性错误。3.4 代价与选型WarningToT 贵得离谱每层生成 N 个候选、每个还要单独评估一轮Token 消耗是单次 CoT 的数倍到数十倍延迟也成倍上升。它绝不是默认选项。几种推理范式的选型一张表说清范式一句话适合的任务不适合的任务CoT把草稿写出来单步推理、答案唯一、不需要外部信息算术、逻辑、改写 | 需要外部事实、需要多步探索 || Self-Consistency | 多算几遍再投票 | 答案可比较、错误是随机的 | 系统性错误、开放生成 || ReAct | 边想边查拿事实 | 需要外部信息、步骤不固定查询、诊断、客服 | 一步错就步步错、无法中途发现 || ToT | 想多个方向能回头 | 搜索型、需要回溯任务规划、组合优化、方案设计 | 简单任务、成本敏感、延迟敏感 |Tip落地原则从最便宜的往上加。 先上 CoT加一句提示不要钱不行上 ReAct给它接工具真是搜索型、前两者都救不了才考虑 ToT。到这里推理的想这一层算是补齐了。但只要你真的落地一次就会撞上最后一堵墙——模型想得再好它的输出还是自由文本你的程序接不住。四、结构化输出让它写在标准表格里4.1 三层靠谱程度ReAct 循环里那个extract()就是证据把自由文本的推理过程硬翻译成程序能读的数据这件苦力活本来不该由你干。同样是让模型输出 JSON可靠性差着两个数量级方案保证什么不保证什么失败率量级纯文本 正则什么都保证不了格式、字段、类型15% ~ 30% 解析失败JSON 模式 json_object输出是合法 JSON字段名、类型、必填项2% ~ 8% 字段级错误严格 JSON Schema strict完全符合你给的 schema内容语义是否正确0.1%Note上表失败率来自社区评测不同模型差异很大但量级关系是稳定的。为什么严格模式能这么稳因为它换了机制约束解码Constrained Decoding。TipJSON 模式是求模型好好输出 JSON严格模式是解码器在物理上不允许它输出非法 token。 一个是请求一个是约束差距就来自这里。同一套机制自部署也能用llama.cpp 的 GBNF、vLLM 的 XGrammar、微软的 llguidance。你不用自己实现但知道它存在选型时才问得出对的问题。4.2 LangChain4j 里怎么用在 Java 这边LangChain4j 已经把这件事封装得很顺方法直接返回一个 POJO框架自动生成 JSON Schema 发给模型。import dev.langchain4j.model.output.structured.Description; import static dev.langchain4j.model.chat.Capability.RESPONSE_FORMAT_JSON_SCHEMA; // ① 用 record 描述你要的结构Description 是写给模型看的字段说明 public record OrderDecision( Description(推理过程先说明用户诉求、查到的订单状态、依据的售后规则) String reason, Description(决策结果只能是这三个值之一) Decision decision, Description(给用户的回复正文) String reply) { } public enum Decision { REFUND, EXCHANGE, REJECT } // ② 方法直接返回这个类型不再返回 String interface OrderAssistant { OrderDecision handle(String userMessage); }// ③ 关键显式开启 JSON Schema 能力它默认是关闭的 ChatModel model OpenAiChatModel.builder() .apiKey(System.getenv(OPENAI_API_KEY)) .modelName(gpt-4o-mini) .supportedCapabilities(RESPONSE_FORMAT_JSON_SCHEMA) .strictJsonSchema(true) // OpenAI / Azure / Mistral 需要这个开关 .temperature(0.0) .build(); OrderAssistant assistant AiServices.builder(OrderAssistant.class) .chatModel(model) // LangChain4j 1.x 写法0.x 请用 .chatLanguageModel(model) .tools(new OrderTools()) // 你的工具类用 Tool 注解方法即可结构化输出与工具调用可以同时使用 .build(); OrderDecision d assistant.handle(我上周买的鞋子不合脚能退吗); System.out.println(d.decision() / d.reason());静默降级是生产事故的经典温床supportedCapabilities(RESPONSE_FORMAT_JSON_SCHEMA)不写框架不会报错。 它会悄悄退化成把格式说明拼进用户消息的老办法——那种求模型好好输出 JSON的不可靠做法。另外 provider 差异要注意OpenAI / Azure / Mistral 要strictJsonSchema(true)Gemini、Ollama、Bedrock 只配supportedCapabilities。4.3 三个真实的坑字段顺序就是逻辑坑一最重要reason必须排在decision前面。 模型逐 token 顺序生成写完就定死——结论排前面它会在还没推理时就把结论吐出来reason沦为事后找补。把reason排最前等于把 CoT 固化进数据结构。Warning坑二默认所有字段都是可选的。 强制必填要显式标JsonProperty(required true)可选的基本类型字段漏填会静默变成0/false全程没有任何异常。关键字段都要写单测。坑三不是所有类型都能进 schema。 POJO、枚举、String、List / Set、数值和 boolean 没问题BigDecimal、Date、LocalDate、Map不在支持范围会自动退回 prompting 模式——而金额和日期恰恰是最常见的两类业务字段金额建议用 String 传。记住schema 校验只是第一道门业务校验金额范围、日期合理性、枚举与业务状态是否匹配一个都不能省。4.4 最终形态让推理过程本身成为 schema 的一部分public enum Confidence { HIGH, MEDIUM, LOW } public record Diagnosis( Description(排查推理过程列出你检查了哪些指标、排除了哪些假设) String reasoning, Description(判定结论) String conclusion, Description(置信度high / medium / low证据不足时给 low不要强行下结论) Confidence confidence) { }这么写一步到位reasoning先于confidence生成CoT 被固化进字段排查时reasoning直接可查不用翻散落的日志评测时confidence能批量统计什么情况下模型会给 low——这是 Agent 评测里最难拿到的一手数据。Tip给模型留一个我不确定的出口如果你把 schema 约束成只能输出确定答案模型不确定时就会编一个出来。 加一个null或UNKNOWN枚举值让它能诚实弃权比逼它胡说要好控制得多。总结你递出去的四样东西回到最开始的类比四种范式其实是四件不同的工具CoT —— 一支笔。 让它把草稿写出来中间结果就成了可见输入。ReAct —— 一部电话。 让它能在推理中途打给外部世界把事实取回来。ToT —— 一张可擦的草稿纸。 允许它同时想几个方向允许它擦掉重来。结构化输出——一张标准表格。 让它写在格子里你的程序才接得住。推理范式的升级从来不是让模型变聪明而是让它的推理过程获得默认状态下没有的东西草稿、事实、回溯和约束。落地顺序也就很清楚了先用一句让我们一步步思考试试——它一分钱不花却能让同一个模型的正确率翻好几倍。不够就按 ReAct → ToT 的顺序往上加并且在第一步就把输出结构定下来让每一步推理都落进字段里。大模型的知识又多又杂到底怎么学做这行久了被问最多的问题就一个大模型的知识又多又杂我到底先学啥翻了一堆资料看啥都像重点结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍零基础、应届生、转行的都适用。跟着走至少方向不乱、不瞎忙学完拿得出手。第一阶段10天初阶应用这一阶段就一个目标把大模型真正玩明白不是只会聊天那种而是能调教它、能用代码把大模型和业务接起来。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用这阶段正式进实战目标很实在做出两个能拿出手的东西——一个私有知识库一个 agent 对话机器人。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…走完这 30 天Python 或 JavaScript 背景的基本能独立做一套 RAG 应用简历上也敢写大模型应用开发了。第三阶段约20天动手微调学到这你已经开始 “造” 模型了 —— 通过微调搞出垂直领域的专用小模型。为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料第四阶段20天商业闭环部署落地技术学完落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…想要入坑大模型的朋友给大家准备了一份2026 年最新 AI 大模型全套学习资料1、大模型系统化学习路线2、大模型学习视频教程3、大模型学习书籍电子文档4、AI大模型最新行业报告5、大模型项目实战配套源码6、2026大模型大厂面试真题7、为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。8、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。9、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料好了就写到这。路线是死的人是活的卡住了随时来问我。觉得有用就点个收藏别让它进收藏夹吃灰——动起来比啥都强。
