被忽略的 finish_reason：LLM 截断如何悄悄污染你的数据管线

一个每周运行的任务，把客服工单汇总成一份报告，每个产品一个章节。报告读起来流畅、自信，每周一准时送达。没有人注意到，最后两个产品的内容已经整整一个月没有出现过。

工单在增长，报告也随之变长。而调用模型时设置的最大输出长度，是在报告还只有现在一半大小时定下的——然后再没人动过它。这个真实场景揭示了一个被普遍忽视的工程陷阱：当大语言模型输出被截断时，它不会告诉你，至少不会在文本里告诉你。

模型撞到上限时会发生什么

当模型触及 max_tokens 限制时，它不会收尾，不会道歉，也不会补一句"以上就是全部内容"。它就那么停了——可能停在列表中间，甚至停在一个单词中间——然后把已经生成的部分原样交回。

关键在于：响应本身其实说明了这一点。 每一个正经的 API 都会返回一次生成结束的原因。它可能是自然结束（stop）、撞到长度上限（length）、命中停止序列，或者被内容过滤器拦截。这个字段通常叫 finish_reason 或类似名称，就摆在那里。

问题出在代码只读了文本，从来没读过这个原因。

finish_reason 字段在主流 API 中的具体表现略有差异，但逻辑一致。OpenAI API 返回的 finish_reason 常见取值包括：stop（模型自然生成了结束符）、length（触达 max_tokens 限制）、content_filter（内容被安全策略拦截）、tool_calls（模型请求调用工具）。Anthropic Claude 的对应字段叫 stop_reason，取值为 end_turn、max_tokens、stop_sequence 等。Google Gemini 则使用 finishReason，包含 STOP、MAX_TOKENS、SAFETY 等。无论命名如何，含义是统一的：length 或 MAX_TOKENS 类的值意味着模型被强制打断，而非主动收尾。这个字段通常位于响应体的 choices[0].finish_reason（OpenAI 风格）或顶层 stop_reason 字段中，一行代码即可读取，但绝大多数集成代码从未碰过它。

散文最擅长隐藏截断

截断之所以危险，是因为它在不同输出格式下的表现截然不同。

自然语言散文把问题藏得最深。一份本应有八个章节的报告，在第六节后戛然而止，看起来就像一份本来只有六节的报告。没有语法错误，没有解析失败，没有任何异常信号——它只是"少了两个产品"，而少掉的部分不会主动举手。

结构化输出的隐藏方式则不同。被截断的 JSON 无法解析，于是会直接报错。听起来这是好事——至少失败是显式的。但危险往往从这里开始。

不要把"修复"当成解决方案

当截断的 JSON 解析失败，总有人会加一个"修复"步骤：自动补上缺失的括号，闭合未完成的结构。于是一个只完成了一半的答案，现在能通过校验了。

这正是最糟糕的处理方式。原文的警告非常直接：不要把残缺的输出修复成合法的输出。 如果它无法解析，那说明它不完整，而不完整这件事应该是"吵闹"的——应该大声报错、阻断流程，而不是被悄悄抹平后继续向下游传递。

一个能通过校验的半截答案，比一个明确失败的请求危险得多，因为前者会伪装成正确结果，一路流进后续系统。

把 finish_reason 当作 HTTP 状态码来读

作者 Serguey Asael Shinder 给出的核心建议值得每个做 LLM 集成的工程师记住：在每一次调用后读取停止原因，就像你读取 HTTP 状态码一样。

• 自然结束（finished naturally） 才算成功。
• 撞到上限（hit the limit）不是一个答案。 它是一个错误，或是一个"需要继续生成"的信号，但绝不该作为结果传给下游。

这个类比很到位。没有人会在收到 HTTP 500 时假装请求成功了，但在 LLM 调用中，无数系统正是在对等价的"失败状态"视而不见。

几条可落地的防御措施

结合原文观点，可以把防护拆成几个具体动作：

1. 给上限留足余量，并在接近时告警

设置 max_tokens 时要留出真实的 headroom，并在调用逼近上限时触发告警。因为缓慢增长正是让你撞墙的典型路径——就像那份一周一周悄悄变长的报告，没有哪一天是"突变"的，直到某天内容开始被截断。

2. 已知结构就校验结构

当输出的形状是已知的，就去检查形状。八个产品进去，就该数出八个章节出来。这种基于业务语义的"数量断言"，往往比单纯的 JSON 格式校验更能抓住截断问题——因为残缺输出可能格式合法，但数量对不上。

3. 把停止原因和成本一起记录

把 finish_reason 和调用成本记录在一起、画在同一张监控图上。这样一来，当摘要开始提前截断的那一周，它会显示在图表上，而不是等到某场会议里被人当面提出来。

可观测性的意义正在于此：让问题在数据里暴露，而不是在事故里暴露。

在需要生成较长内容的场景下，还有一种架构层面的应对策略：流式输出（streaming）配合增量校验。启用流式模式后，客户端可以在生成过程中实时接收 token，一旦检测到 finish_reason: length 便立即触发告警或重试逻辑，而不必等到整个响应返回后才发现截断。对于超长任务，也可以采用分段生成的方式：将大任务拆成若干独立的小请求，每段单独校验完整性，再在应用层拼接结果。这样既降低了单次调用撞上限的概率，也让每一段的截断问题更容易被隔离发现。分段的边界最好沿业务语义切割（例如每个产品单独一次调用），而不是按字符数硬切，否则拼接后的结构一致性难以保证。

一个容易被低估的工程盲区

这篇短文虽然篇幅不长，却点出了 LLM 工程化中一个极具代表性的盲区。随着模型能力越来越强、输出越来越流畅，开发者很容易默认"模型说完了就是说完了"。但实际上，输出的完整性和输出的质量是两个独立的问题。

一个运行流畅、每周准时、读起来毫无破绽的管线，可能已经静默丢失了四分之一的数据——而唯一能告诉你真相的，是那个你一直没去读的字段。

"一个撞到输出上限的模型不会在文本里告诉你。它会在那个你没在读的字段里告诉你。"

对于任何将 LLM 接入生产流程的团队，这都是一条应当写进代码规范的铁律。