LLM 输出格式不规范怎么修?
意图识别中 JSON 格式错误、字段缺失的修复策略与优缺点
原题：在基于大语言模型的意图识别任务中，针对模型输出格式不规范（如JSON格式错误、字段缺失、类型不符等）的问题，请系统阐述可采取的技术策略以提升输出的结构化程度、一致性与稳定性，并结合实际应用场景说明各方法的优缺点。
Agent · 小红书真题
回答与解析
核心解决思路：三层防御体系
一、提示工程层（软约束）
- Few-shot示例：在Prompt中嵌入3-5个标准输入输出样例，引导模型模仿格式
- 思维链+格式模板：要求模型先分析再输出，用
json代码块包裹，降低自由生成 - 负面示例警示：明确告知"禁止输出markdown以外的内容"
局限：依赖模型指令遵循能力，强模型（GPT-4）效果好，弱模型仍可能漂移
二、模型能力层（硬约束）
| 技术 | 原理 | 适用场景 |
|---|---|---|
| JSON Mode | 约束输出token为合法JSON | OpenAI/Claude等支持，最稳定 |
| JSON Schema | 预定义字段类型/必填/枚举值 | 复杂结构化需求，可校验 |
| Function Calling | 强制输出匹配函数参数结构 | Agent工具调用场景 |
| Constrained Decoding | 解码时限制token生成空间 | 自研模型/开源方案（如outlines库） |
小红书场景：笔记标签抽取用JSON Schema强制tags: array<string>，避免模型输出字符串拼接
三、后处理层（容错兜底）
- 解析容错：用
json5/demjson容忍尾随逗号、单引号等 - LLM自修复：解析失败时，将错误信息+原输出喂给模型要求修正（1-2轮重试）
- 规则兜底：关键字段缺失时，用规则补全或返回默认值
- 输出验证：Pydantic模型校验，类型不符触发重试或降级
方案选型建议
| 场景 | 推荐组合 |
|---|---|
| 高稳定性要求（交易/审核） | JSON Schema + 重试机制 + 规则兜底 |
| 成本敏感（海量内容） | 小模型+Few-shot + 轻量规则修复 |
| 复杂Agent多步推理 | Function Calling + 级联错误传播控制 |
关键认知：没有100%可靠的方案，需根据错误率容忍度设计"解析成功率→重试→人工兜底"的降级链路。
学习建议
建议从提示工程、输出约束库（如Pydantic）、后处理校验和重试机制入手学习，结合LangChain等框架实践结构化输出控制。
口语版讲法(约4分钟)
- 本质是平衡软约束、硬约束和容错
- 提示工程层：Few-shot和模板，模型能力强时管用
- 模型能力层：JSON Schema和Function Calling，但有限制
- 后处理层：容错解析和重试，兜底保障
- 落地选型：根据场景组合，没有银弹
这道题其实问的是，怎么让大模型输出稳定的结构化数据，比如JSON。核心思路我把它分成三层：提示工程、模型能力、后处理容错。这三层不是互斥的，真正落地往往是组合拳。
先说提示工程这层，就是软约束。我会在Prompt里放几个Few-shot示例，让模型模仿格式，再给一个JSON模板，要求它先分析再输出，用代码块包起来。甚至加个负面例子，说不要输出多余文字。这个方法好处是零成本，但前提是模型指令遵循能力要强，像GPT-4效果就很好，换成小模型就经常飘，输出格式不对。所以它适合对成本敏感、错误容忍度高的场景，比如海量内容打标签，错了影响不大。
再一个，模型能力层，这是硬约束。比如Function Calling，强制模型输出匹配函数参数结构，这在Agent工具调用里很常见，比如客服系统里判断退款意图，直接返回结构化参数。还有JSON Schema，可以预定义字段类型和必填项，比如电商的订单异常检测，要求输出order id和reason字段，类型不对就报错。但这里有个坑：这些功能不是所有模型都支持，而且会限制模型的自由度，复杂场景下可能漏掉信息。所以我会在关键业务上用，比如交易审核，输出格式必须严格，但代价是模型可能拒绝回答。
最后是后处理层，容错兜底。毕竟没有模型100%可靠。我会用json5库容忍尾随逗号、单引号这种小错误；如果解析失败，就把错误信息喂回给模型，让它自修复，一般重试一两次就能好。如果字段缺失，就用规则补全或返回默认值。比如商家满减政策解析，如果discount字段缺失，我宁愿返回默认值0，也不让系统崩溃。但重试会增加延迟和成本，所以得设置最大次数。
那怎么选呢？高稳定性场景，比如金融风控，我会用JSON Schema加重试机制再加规则兜底，宁可慢也要准。成本敏感场景，比如内容审核，用小模型加Few-shot加轻量修复就够了。复杂Agent多步推理，用Function Calling控制每一步输出，同时做好错误传播，比如一步失败就回滚。
这里有个延伸点：如果模型本身不支持结构化输出约束，比如开源小模型，光靠提示工程和后处理可能不够，那就要考虑微调了。比如用LoRA在训练数据里加入格式正确的样本，让模型从底层学会输出JSON。但这又涉及数据成本和模型更新频率的问题。
所以我的判断是，没有银弹，关键是根据错误容忍度设计降级链路：先解析，失败就重试，再失败就规则兜底，最后人工介入。我更倾向把提示工程和后处理作为标配，硬约束按场景按需引入，这样既灵活又可控。
关键一句:如果模型不支持结构化约束，比如开源小模型，可以考虑微调，比如用LoRA在训练数据里加入格式正确的样本。
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做电商客服的订单查询意图识别，模型需要输出JSON格式，比如{'意图':'查询物流','订单号':'123'}。但有时候模型会输出格式错误或者字段名不对，你遇到过吧？怎么保证它每次都输出规范的JSON？
- 问法 2 · 层层追问
你通常怎么让模型按固定格式输出？……如果加了few-shot还是偶尔会输出乱格式呢？……那要是模型输出JSON但字段类型不对，比如字符串写成了数字，你怎么处理？
- 问法 3 · 直球架构
针对大模型意图识别输出格式不规范的问题，比如JSON格式错误、字段缺失、类型不符，你系统性地讲讲有哪些技术策略可以提升输出的结构化程度和稳定性？包括优缺点和适用场景。