大模型结构化输出怎么保证？JSON Schema、约束解码和校验重试怎么配合？
面试怎么回答
我会优先用模型或推理框架支持的结构化输出，传入 JSON Schema，有约束解码的能从机制上保证格式；也可以把输出定义成工具参数。但格式正确不等于内容正确，所以程序侧一定用 Schema 校验，再做业务校验，比如枚举范围、数值区间、字段之间的逻辑。Schema 设计上字段少而明确，用枚举，允许 unknown，不逼模型编答案。校验失败把错误带回去让模型修正，有限次数后进入人工队列，不用默认值悄悄填。批量抽取按 ETL 来做，记录模型、提示词和 Schema 版本，结果带校验状态落表，抽样评估准确率。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
数据团队用大模型做信息抽取、分类、生成 SQL，下游都是程序在读结果，最怕的是：模型偶尔多输出一句解释、少一个字段、把数字写成字符串，下游直接解析失败。面试官想看你怎么从「能用」做到「稳定可用」。
几种保证方式
- 提示词约束：在提示词里给出格式和示例。最简单，但不能保证 100% 遵守；
- JSON 模式 / 结构化输出：现在主流模型和推理框架都支持传入 JSON Schema，输出严格符合结构。有的是在服务端做约束解码，生成每个 Token 时只允许符合语法的候选，从机制上保证格式正确；
- 工具调用：把需要的输出定义成一个工具的参数，让模型「调用」这个工具，结果就是结构化的参数；
- 事后校验：不管用哪种方式，程序都要用 Schema 校验，失败时重试或修复。
格式正确不等于内容正确
约束解码保证的是结构，不保证：
- 枚举值选得对；
- 日期、金额的值合理；
- 必填字段不是瞎编的。
所以还要做业务校验：枚举范围、数值区间、字段之间的逻辑关系（比如结束时间晚于开始时间），以及在原文里能找到依据。
Schema 设计的技巧
- 字段少而明确，嵌套不要太深；
- 用枚举代替自由文本；
- 允许「不确定」：给出
unknown选项或者可空字段，而不是逼模型编一个答案； - 先推理后输出：可以加一个
reason字段放在结论字段前面，帮助模型先思考再给结论（注意顺序会影响生成）。
失败的处理
- 校验失败时，把错误信息带回去让模型修正，最多重试几次；
- 仍然失败的进入人工队列或者标记为失败，不要用默认值悄悄填上；
- 统计各类失败的比例，作为优化 Schema 和提示词的依据。
批量抽取的数据链路
大批量抽取（比如从 100 万条工单抽取问题类型）要像普通 ETL 一样：记录模型版本、提示词版本、Schema 版本；结果落表并带上校验状态；抽样人工评估准确率。