AI 大模型故障：JSON 输出解析失败：让模型按格式输出却夹带多余文字怎么办

一、故障现场：JSON 解析失败到底长什么样

先看一段真实工程里高频出现的失败样本。你要求模型返回一个用户信息对象，期望得到：

{"name": "张三", "age": 28, "city": "杭州"}

实际拿到的却是：

好的，根据您的要求，以下是提取的信息：

```json
{"name": "张三", "age": 28, "city": "杭州"}
```

希望对您有帮助！

此时 json.loads() 直接抛出 JSONDecodeError。这类故障在社区里被反复讨论：LangChain 的 OutputParserException、OpenAI 开发者论坛中关于 “model adds extra text around JSON” 的长帖、以及大量 GitHub Issue 都指向同一现象。笔者认为，把它简单归类为“模型不听话”是一种认知懒惰，真正有价值的是把它当作一个可测量、可分解的系统性偏差来对待。

1.1 故障的四种典型形态

把海量失败样本归纳后，可以稳定地分成四类。这个分类本身就是后续防御设计的依据。

前两类是“语法层”问题，后两类是“语义层”问题。本文评述：很多团队只盯着前两类做正则清洗，结果线上仍然偶发失败，原因正是忽略了后两类——它们不会被正则发现，却会在下游业务里造成更难排查的脏数据。

1.2 一个可量化的失败率视角

不同模型、不同任务下失败率差异极大。综合公开评测与工程经验，可以给出一个量级参考（以下为基于公开讨论与社区反馈的整合估计，非单一实验数据，仅供量级参考）：

这组数字传递的关键信息是：失败率不是常数，而是随任务复杂度与模型能力变化的变量。因此任何“一次性修好”的期待都不现实，工程上要追求的是把失败率压到可接受阈值，并让剩余失败可被自动兜底。

二、约束衰减：一条贯穿全文的分析主线

为了让全文不散，这里先立起核心概念。约束衰减（Constraint Decay）指的是：模型对输出格式约束的服从度，会随生成步数增加、上下文变长、任务复杂度上升而系统性下降。它不是某个模型的 bug，而是自回归生成范式的结构性特征。

2.1 为什么用“衰减”而不是“错误”

“错误”暗示随机、偶发、可归因于单点；“衰减”强调单调、可预测、与位置强相关。这个措辞差异直接决定工程策略：如果当作随机错误，你会去加更多提示词；如果当作衰减，你会去设计位置感知的约束机制——在衰减最严重的尾部施加最强约束。

本文评述：约束衰减与“注意力稀释”和“训练目标错位”两个机制高度相关。前者解释为什么长上下文里格式指令被淹没，后者解释为什么模型在“有用”和“守格式”之间天然偏向前者。后文第三章会展开。

2.2 衰减的三个维度

把衰减拆成三个可观测维度，后续所有防御手段都能映射到其中至少一个：

• 序列维度：生成越靠后的 token，对开头格式指令的“记忆”越弱，越容易在结尾加客套话。
• 上下文维度：输入越长，格式指令在注意力中的相对权重越低。
• 任务维度：任务越需要“解释”“推理”，模型越倾向于用自然语言补充，格式服从度越低。

这条主线将贯穿后文：第四章对抗上下文维度，第五章对抗序列维度，第六章兜底任务维度，第七章度量全部三个维度。

三、机理深挖：为什么模型“忍不住”多说一句

3.1 自回归生成与“局部最优”陷阱

大模型逐 token 生成，每一步都在给定前文下选概率最高的下一个 token。问题在于，训练语料中“用户要求 JSON”之后，极高频的续写模式是“好的，以下是……”——因为人类对话里直接甩一个裸 JSON 反而少见。于是模型在开头就进入了一个“对话式”的局部最优路径，一旦开头是“好的”，后面加代码围栏和结尾客套就顺理成章。笔者认为，这是约束衰减在序列维度上的直接体现：第一步的偏差会自我强化。

3.2 指令微调中的“有用性”偏好

RLHF 与指令微调普遍奖励“有帮助、解释清楚”的回答。模型学到的隐含偏好是：多解释一点更安全。当格式约束与“显得有帮助”冲突时，模型往往选择后者。OpenAI 在 Function Calling 与 Structured Outputs 的文档中明确建议使用其原生结构化能力，本质上就是在训练与推理两端同时压制这种偏好（OpenAI, 2024）。

3.3 采样参数放大的不确定性

温度、top-p 越高，模型越可能偏离高概率的“直接输出 JSON”路径。工程经验是：结构化输出任务应把 temperature 压到 0–0.3。这不是玄学，而是降低采样熵、减少偏离约束的概率。相关讨论可参考 Hugging Face 关于生成的官方教程（generation strategies）。

3.4 训练目标与推理目标的错位

预训练目标是“预测下一个 token”，而非“满足格式约束”。格式约束是推理期的外部要求，模型内部并没有一个专门的“格式检查器”。这正是为什么解码期约束（第五章）在原理上比提示词更可靠——它把外部约束直接注入到 token 选择过程。本文评述：理解这一点，就能明白为什么“再写详细点的提示词”存在天花板，而约束解码是更接近根因的解法。

四、第一层防御：提示词与上下文工程

提示词不是万能的，但它是零成本、零依赖的第一道防线。关键是别写“请返回 JSON”这种模糊指令。

4.1 给出 schema，而不是描述 schema

把期望结构以 JSON Schema 或 TypeScript 类型直接写进提示词，比自然语言描述精确得多。示例：

你是一个只输出 JSON 的抽取器。
输出必须严格符合以下 JSON Schema，不得包含任何解释、前后缀或 Markdown 围栏：
{
  "type": "object",
  "properties": {
    "name": {"type": "string"},
    "age": {"type": "integer"},
    "city": {"type": "string"}
  },
  "required": ["name", "age", "city"]
}
第一个字符必须是 {，最后一个字符必须是 }。

“第一个字符必须是 {”这类边界锚定指令，直接对抗 3.1 节的“开头跑偏”问题。

4.2 用 few-shot 示例锁定格式

给 1–3 个“输入→裸 JSON 输出”的示例，让模型通过上下文学习格式。注意示例里绝不能出现“好的，以下是”这类文字，否则等于教模型夹带。Anthropic 的提示工程文档建议把示例放在明确的分隔符中，并保持格式完全一致（Anthropic, 2024）。

4.3 把格式指令放在“近端”

针对上下文维度的衰减，把最关键的格式约束放在靠近生成起点的位置（如 system 末尾或 user 消息末尾），而不是埋在长文档开头。这是对注意力稀释的直接对冲。

4.4 预填充（prefill）技巧

部分 API 支持 assistant 消息预填充。直接把回复的开头设为 {，模型就只能从 JSON 内部续写，从物理上杜绝前缀。这是对付“前后缀包裹”最优雅的手段之一。本文评述：预填充本质上是把“约束”从概率层面提升到结构层面，与第五章的约束解码同源。

4.5 提示词的局限

提示词能显著降低失败率，但无法归零，尤其在长上下文、小模型、高温度场景。因此必须叠加后续几层防御。可参考 OpenAI 的提示工程指南（prompt engineering）与 Google 的提示指南（prompting strategies）。

五、第二层防御：解码期约束与结构化生成

这是最接近根因的一层。核心思想：在每一步采样时，动态屏蔽掉不符合目标语法的 token。

5.1 约束解码的基本原理

把 JSON 语法编译成一个状态机（或下推自动机），维护当前解析状态。每步只允许那些能让状态机继续合法的 token，其余 logits 置为 -inf。这样生成结果在语法上必然合法。经典实现包括 outlines、guidance、llama.cpp 的 GBNF 语法、以及 XGrammar 等。

5.2 主流方案对比

OpenAI 在 2024 年 DevDay 推出的 Structured Outputs 声称在 schema 遵循上达到 100%（OpenAI, 2024）。本文评述：这个“100%”应理解为“语法与 schema 结构层面”，语义正确性仍需业务校验，不能混淆两个层次。

5.3 约束解码的代价

约束解码并非免费午餐：

• 每步需计算合法 token 掩码，有额外开销；
• 过度约束可能损害模型推理质量（有研究指出强约束会降低复杂推理表现，如 Tam et al., 2024 关于 constrained decoding 影响的分析）；
• 复杂 schema 编译成本高。

因此工程上要权衡：对纯抽取任务用强约束，对需要推理的任务用弱约束 + 后校验。

5.4 与约束衰减主线的呼应

约束解码直接作用于序列维度：它让每一步都不可能选到非法 token，从根本上消除了“尾部夹带”。这是对衰减最硬核的对抗。

六、第三层防御：解析、校验与自动修复

再强的约束也可能因 API 不支持、模型不兼容而失效。这一层负责兜底，目标是把“解析失败”变成“可自动恢复”。

6.1 鲁棒解析：先清洗再解析

一个实用的清洗流程：

1. 剥离 Markdown 代码围栏（正则匹配 ```json ... ```）；
2. 定位第一个 { 或 [ 与最后一个匹配的 } 或 ]，截取中间部分；
3. 尝试 json.loads；
4. 失败则尝试修复（见下）。

import json, re

def extract_json(text: str):
    # 1. 去代码围栏
    fence = re.search(r"```(?:json)?\s*(.*?)```", text, re.S)
    if fence:
        text = fence.group(1)
    # 2. 截取第一个 { 到最后一个 }
    start = text.find("{")
    end = text.rfind("}")
    if start != -1 and end != -1 and end > start:
        text = text[start:end+1]
    # 3. 解析
    return json.loads(text)

6.2 常见修复策略

成熟库如 Python 的 json_repair、json5 已能处理大部分畸形 JSON。本文评述：修复是必要的兜底，但不应成为主路径——如果修复率长期偏高，说明上游约束层没做好，应回溯优化而非依赖修复。

6.3 Schema 校验与重试

解析成功后用 Pydantic / JSON Schema 校验字段与类型。失败则触发一次“带错误信息”的重试：把校验错误回填给模型，要求它修正。这是对抗任务维度衰减的有效手段。

from pydantic import BaseModel, ValidationError

class User(BaseModel):
    name: str
    age: int
    city: str

def parse_with_retry(llm, prompt, max_retry=2):
    for i in range(max_retry + 1):
        raw = llm(prompt)
        try:
            data = extract_json(raw)
            return User(**data)
        except (json.JSONDecodeError, ValidationError) as e:
            prompt = f"{prompt}\n\n上次输出有误：{e}\n请只输出合法 JSON。"
    raise RuntimeError("重试耗尽")

七、第四层防御：可观测性与回归评测

没有度量就没有改进。这一层把约束衰减变成可监控指标。

7.1 关键指标

7.2 构建回归集

收集线上失败样本，构建固定回归集，每次改动提示词/模型/参数后跑一遍。评测框架可用 promptfoo、DeepEval 等。相关教程见 promptfoo 文档。

7.3 与衰减三维度对应

按输入长度、输出长度、任务类型分桶统计成功率，就能定位衰减发生在哪个维度，从而针对性加强对应防御层。

八、工程落地：一套可复用的参考实现

把四层防御串成一条流水线：

def structured_call(llm, user_input, schema_model, max_retry=2):
    # 第一层：提示词 + schema
    prompt = build_prompt(user_input, schema_model)
    for attempt in range(max_retry + 1):
        # 第二层：若 API 支持，启用结构化输出/约束解码
        raw = llm(prompt, response_format="json_schema", temperature=0)
        # 第三层：清洗 + 解析 + 校验
        try:
            data = extract_json(raw)
            return schema_model(**data)
        except Exception as e:
            # 第四层：记录指标并重试
            metrics.record(attempt, e)
            prompt = append_error_hint(prompt, e)
    raise StructuredOutputError("超过最大重试次数")

这套结构在多数团队可直接复用。要点是：约束越靠前越好，修复越靠后越兜底，指标贯穿始终。

九、前沿预判：结构化输出的下一步

9.1 原生结构化输出成为标配

OpenAI、Anthropic、Google 均在强化原生结构化能力。未来“让模型输出 JSON”会像调用函数一样自然，提示词层面的格式纠缠将大幅减少。

9.2 约束与推理的平衡

如何在保证格式的同时不损害推理，是活跃研究方向。可能的路径是“先自由推理、后结构化收口”的两阶段生成。

9.3 格式即协议

随着 Agent 与工具调用普及，结构化输出正在从“输出格式”升级为“通信协议”。笔者认为，约束衰减问题的重要性会随之上升——协议不容许夹带。

十、结论与行动清单

回到主线：JSON 夹带多余文字不是偶发 bug，而是约束衰减的必然表现。单点方案无效，必须四层叠加。

• 立即做：加边界锚定提示词、去围栏解析、schema 校验、失败重试；
• 尽快做：接入原生结构化输出或约束解码；
• 长期做：建立回归集与指标看板，按衰减维度持续优化。

把这套体系跑通后，结构化输出的失败率可以稳定压到很低，且剩余失败可自动兜底。这才是工程上可交付的可靠性。