这类大模型推理优化的方向最近一个非常值得关注的研究主题叫“Knowing When to Quit”核心解决的是当 LLM 陷入无效推理时能不能及时发现并主动放弃而不是继续生成大量没有意义的中间步骤。这个问题不是论文里的边缘议题而是真正影响 token 消耗、接口响应时间和 Agent 稳定性的工程问题。我结合它给出的诊断和训练思路把适合工程落地的那部分整理出来帮你从“让模型想得更久”切换到“让模型知道什么时候该停”。这个主题适合三类人看一是接入了 LLM 做多步推理、工具调用或数学题生成的人二是想训练自己的推理数据集、不断调整 prompt 和样本的人三是做 Agent 框架、需要控制成本与超时时间的人。最值得关注的点不是“如何训练出更强的推理能力”而是“如何训练模型在推理确实走不下去时主动切换策略或终止任务”。下面按我自己实测时会关注的顺序拆开讲。1. 无效推理不等于慢思考先分清空转和深度推导很多人把模型的“慢”和“模型正在努力推理”混在一起实际这是两件事。无效推理的典型特征是生成步数很多、上下文不断膨胀但对最终答案的贡献几乎没有。它看起来像深度思考本质上是在原地空转。1.1 无效推理的几种典型现场我在实际跑 LLM 推理时最常遇到这样几种无效推理形态重复循环模型反复描述同一个假设换几种说法重述中间步骤没有新信息。自我怀疑但没有出口每走一步都补充一句“但是这可能不对”“再检查一下”却没有引入新约束或新计算。局部细节膨胀把某个边界条件掰开揉碎分析了几百个 token结果这个分支对答案毫无影响。工具调用空转调用了搜索或计算接口结果返回值没用上下一轮又调同一个参数。最终绕回原点思考到最后一步得出的结论和第一步完全一样只是表达更长了。如果只看输出长度你会以为它“思考得很仔细”。把推理轨迹展开之后才会发现大部分内容是在同一个语义区域内来回打转。1.2 无效推理的代价比想象中更大单次请求多花几百个 token在实验中可能看不出来。一旦放到批量任务或 Agent 场景问题会迅速放大接口成本上升尤其长文本模型的 token 计费按输入输出同时收费。响应时间变长用户等待时间被无意义拉长。下游任务被拖累比如一个多轮工具调用流程会因为中间步骤过长导致超时。日志难排查推理步骤一多失败原因被大量噪音包裹定位问题很困难。所以我建议判断一个模型是否适合生产环境不要只看它在标准评测集上的准确率还要看平均推理长度、最长推理时间、失败重试次数这些指标。1.3 为什么不能简单靠“减小 max_tokens”解决最常见的误操作是发现模型生成太多直接把 max_tokens 调小。这个方案确实能让输出变短但代价很致命——它不是让模型学会判断“该停了”而是把推理过程在任意位置截断。截断可能发生在两种地方如果截断点刚好处在关键推导之前模型会输出一个错误但完整的结论。如果截断点处在推理中途模型可能输出半截不完整的句子更不利于下游解析。更麻烦的是有些任务本来就适合长推导比如复杂计算、多跳检索、代码逻辑验证。用长度限制一刀切等于牺牲了深度推理能力。真正的方向应该是让模型自己判断“这一步还有没有继续的价值”而不是由外部参数强制掐断。我实测后的感受是外部限制只能兜底不能替代模型内部的停止决策。先记录推理轨迹再判断是否空转之后才谈得上传参调整。下表可以帮你快速区分“有效深度推导”和“无效空转”判断维度有效深度推导无效空转新信息每步引入新约束、新变量、新结论反复重述同一条信息步数分布关键步骤集中非关键步骤少每步长度均匀看不出重点工具调用结果返回值被继续使用返回值被忽略或重复请求最终答案与推导过程一致且可回溯结论和中间步骤不匹配停止时机满足条件后自然终止靠长度或超时被强制终止2. 诊断如何判断模型是不是在无效推理要让 LLM 学会停止第一步不是训练而是诊断。只有先把“什么时候算无效推理”定义清楚才能生成高质量的训练样本。2.1 从四个可计算维度做诊断诊断不能靠感觉要落到可统计的指标上。我一般会从四个维度去记录重复度推理步骤里的 n-gram 重复比例。如果同一个句子结构反复出现说明在空转。信息增量相邻两步之间新增的实体、数字、条件或动作数量。增量为 0 的步骤可以标记为低价值。行动-状态变化这一步调用了工具或接口下一步有没有使用返回值。如果调完没用基本可以判定为无效动作。收敛趋势新生成的文本距离最终结论有没有越来越近。这个可以通过人工判断也可以在数据标注阶段批量打标。其中“行动-状态变化”对带工具调用的 Agent 场景尤其重要。比如模型调用了一个天气查询接口返回了“晴”但后续推理仍然假设“在下雨”这就是典型的推理和执行脱节。2.2 快速搭建一个推理轨迹记录器要诊断先要有数据。不管你是准备做训练还是只想排查线上问题我建议先从记录完整推理轨迹开始。最小化方案只需要保存每一步的关键字段{ query: 小明有12个苹果分给3个朋友每人2个还剩几个, steps: [ { step_id: 1, thought: 先计算分出去的数量, action: multiply(3, 2), action_input: 3, 2, action_result: 6, raw_output: 先计算分出去的数量调用乘法接口... }, { step_id: 2, thought: 再用总数减掉分出去的数量, action: subtract(12, 6), action_input: 12, 6, action_result: 6, raw_output: 总数是12减掉6得到6 } ], final_answer: 6, aborted: false }在工程上还可以额外记录时间戳、token 消耗、API 调用次数。这样一旦某个 case 出问题你可以直接在日志里定位而不用重新跑一遍。2.3 用启发式规则做第一轮粗筛即使没有训练好的诊断模型也可以先用规则做初筛。例如某一步的输出和上一步相似度超过 0.9标记为“疑似重复”。连续 3 步没有出现新数字、新变量、新工具调用标记为“低进展”。工具调用结果在后续 2 步内没有被引用标记为“动作空转”。模型的每一步都以“我再想想”等犹豫表达开头且没有实质计算标记为“怀疑空转”。这几个规则不是给生产环境用的而是为了帮你快速挑出需要打标的样本。先挑坏样本再挑好样本用来训练诊断器或做数据筛选都够用。2.4 小心“伪放弃”和格式错乱诊断时还要注意一种特殊情况模型看起来放弃了但实际是输出格式坏了。比如返回一个空结果、一段乱码或者干脆把“我做不到”当成推理结论。这种情况下不能直接判断为“学会了放弃”。真正的放弃应该具备两个特征第一能明确说明为什么继续推理没有价值第二能给出当前可确认的结论或下一步替代方案。如果模型只是输出了“抱歉我无法回答”那不是放弃策略是能力不足或格式错误。我在实际排查时也会遇到接口返回的 reasoning 字段解析失败比如签名校验不通过、结构不完整、模型输出了非预期格式。这时候先别急着分析模型是否空转第一步永远是检查原始输出和协议字段是否符合预期。输入格式和输出格式没对齐后面所有诊断指标都会失真。排查顺序建议先看原始输出是否完整再看推理轨迹是否可解析最后才看步骤重复率和信息增量。格式都不对的情况下任何指标都没有意义。3. 训练模型学会放弃从数据打标到训练目标诊断只是第一步。要让模型真正具备“知道何时退出”的能力需要把具备放弃行为的样本注入训练流程。下面按数据、标签、训练目标三层说。3.1 构造训练数据哪些样本应该标记为“放弃”不是所有答错的题都要标记为放弃。我建议把训练样本分成几类可解决题模型推理后得到正确答案正常完成。模糊题题干信息不足推理再多也无法确定答案。这类题应该引导模型输出“信息不足需要补充”。走投无路题链路很长但某一步发现前提不成立或条件冲突继续推导没有意义。这类题应该引导模型停止并说明冲突点。优化放弃题模型已经得到答案且验证通过后面再加入的推理步骤反而增加噪音。这类题应该引导模型尽早收尾。如果想训练模型学会“放弃”重点数据在第二类和第三类。模糊题教会模型识别信息缺失走投无路题教会模型识别逻辑冲突。3.2 放弃标签不能只有 0 和 1很多人一开始会做二分类标签继续推理0放弃1。实际训练时效果一般因为“放弃”背后的原因完全不同。同样一句话“我决定停下来”在不同情境下含义不同标签类型触发条件期望模型输出信息不足题干缺少必要条件“目前信息不足需要补充XX建议先确认……”逻辑冲突推理中发现矛盾“这里发现前提A和前提B冲突继续推导无法得出可靠结论”资源耗尽步骤数达到阈值但进展很小“当前路径收益低建议切换方案”已完成收敛已经得到答案且验证通过“已得到结果不再继续扩展”我给每个放弃样本打标时不会只写“abandon1”还会写“abandon_reasoninformation_missing/logic_conflict/resource_exhausted/converged”。这样模型看到的不是“放弃命令”而是“何时、为什么、以及如何优雅结束”。3.3 训练目标最好让放弃同时给出理由训练时一般有两个选择。第一种是监督微调SFT直接用构造好的“推理轨迹放弃决策放弃理由”作为目标输出。这种方案实现简单数据足够时效果最直接。我自己的经验是放弃样本至少占总训练样本的 10%-15%模型才能稳定迁移到新问题上太少了模型只会把放弃当成偶然现象。第二种是偏好优化把“继续无效空转”作为负样本把“及时停止且给出理由”作为正样本让模型学习偏好。这种方案更适合已有一定基础能力、但总是过度推理的模型。如果资源有限我会先做 SFT把放弃行为先“学会”再观察是否出现过度放弃。过度放弃表现为简单题也迅速停止、不肯做多步计算。这时候再引入偏好优化或者调低放弃样本比例。3.4 数据生成流程一条可以复用的小流程没有现成数据集时可以用以下流程造数据准备一批分类明确的题集包括难题、模糊题、带冲突条件的题。用一个基础模型跑推理记录完整轨迹。用规则或人工判断找出轨迹中的空转段。在空转段后插入“放弃点”改写后续输出让模型输出停止理由。保留原始问题、推理轨迹、放弃点、停止理由作为训练样本。我一般会先用小样本跑通全流程比如每个类别 20 条验证标注格式和训练目标没问题再扩充到几百条甚至上千条。4. 评估放弃策略不能只看准确率加入“学会放弃”的模型最让人担心的一个问题是不是变笨了遇到难题就放弃导致准确率下降。所以评估时需要同时看效果指标和资源指标而不是单看某一项。4.1 建议关注的指标组我会同时看下面这些指标标准准确率把“放弃”当作错误答案计算模型在完整测试集上的准确率。可答准确率只看那些确定可解的题模型是否仍然能答对。放弃率模型主动放弃的比例。放弃正确率被放弃的样本里人工判定“确实该放弃”的比例。平均推理步数所有样本的平均思考步数。平均 token 消耗单条请求的输出 token 均值。超时率超过预期时间或步数阈值的请求占比。准确率和推理步数要放在一起看。如果模型缩短了一半步数准确率只下降 1 个百分点这个策略在成本敏感场景里是值得的。如果步数没降准确率掉了 5 个点说明放弃训练并没有生效只是干扰了正常推理。4.2 分组评估比整体评估更可靠整体指标很容易掩盖问题。我建议至少按三组拆开看样本类型预期行为关注指标简单题快速给出答案不做多余推理推理步数、准确率复杂可解题保持深度的长链推理准确率、放弃率不能过高模糊题或冲突题主动停止并说明原因放弃正确率、理由可读性如果模型在复杂可解题上也大量放弃说明训练数据里的放弃标签打得太宽模型学成了“碰到难题就停”。这时要回看数据把“信息不足”和“暂时算不出来”区分开。4.3 评估长文本任务时要控制长度偏置还有一个小坑多数生成式评测对短输出天然友好因为短输出不容易引入新错误。如果只把步数作为唯一奖励模型很容易滑向“直接跳过推理输出简短结论”。这样在评测里可能得分不低但真实场景会变成瞎猜。所以评估时我会额外检查一个维度在放弃样本里模型的停止理由是否准确。如果模型大量输出“我觉得这个问题没法解决”却没有点出哪里信息不足或哪里冲突说明它学会了“回避困难”而不是“识别空转”。这两种行为在生产环境里的价值完全不同。5. 工程落地时的边界与避坑清单最后说几个真正落地时容易被忽略的边界问题。5.1 放弃策略要能和现有系统配合如果你是在 Agent 框架里接入这个能力不要只改模型。至少还要处理放弃后的下游动作是需要返回一个错误码还是要转交给人工客服或是让用户补充信息后重试。推理步数上限模型主动放弃失败时外部仍要有一个兜底阈值防止死循环。日志和追踪放弃的请求必须能回溯到具体步骤否则线上没法排查。我自己遇到过一种情况模型主动输出“信息不足”但业务系统没有识别这个输出继续往下游走结果生了错误订单。这提醒我放弃能力不只是模型的事接口层需要增加对“停止意图”的解析。5.2 不要一上来就开最大并发做训练或推理无论是生成训练数据还是跑线上推理我都建议先小批量验证。先跑 20 条样本确认推理轨迹格式正确、放弃标签一致、评估指标能对齐再扩大到全量数据。并发开太大了一旦数据格式出问题浪费的是整个批次的资源。5.3 算力守恒别为“看起来聪明”付出过高代价有些模型中途停止后还需要额外输出一段解释理由。这段理由本身也要消耗 token。如果系统要求极简输出可以单独设置“放弃理由输出模式”调试模式输出完整理由线上模式只输出结构化标记。5.4 不同模型之间的迁移性要单独测在模型 A 上训练好的放弃策略迁移到模型 B 时不一定直接生效。因为不同模型的推理习惯差异很大有的模型天生啰嗦有的模型天生简短。落地时至少要在目标模型上重测一遍放弃率、准确率和平均步数再决定是否采用。我比较推荐的起步场景是数学题和工具调用任务。数学题推理轨迹清晰容易判断每步是否有效工具调用场景则能看到模型是否在重复无效动作。把这两个场景跑稳再扩展到自己业务里的长流程任务。回到主题本身这个研究最值得借鉴的不是某个具体模型结构而是一整套围绕“停止决策”的诊断和训练思路。先记录推理轨迹再定义无效推理然后构造带原因的放弃样本最后用分组指标做评估。按这个顺序做即使你暂时不训练模型也能先靠规则和指标减少生产环境的无效推理支出。如果要做模型训练也建议从最小样本集开始一步一步验证让“什么时候该退出”成为模型自己的判断能力而不是靠外部参数硬截断。