上周跟一个做信息抽取的兄弟喝茶他正被一件事折磨得够呛明明已经让模型只输出JSON结果某次回复里突然多了一个没定义过的字段下游审核系统直接崩了。这种问题在LLM接入生产时太常见了——模型的自由发挥能力放到程序眼里就是一颗不定时炸弹。我后来专门搭了个小测试框架花了两周时间用同一份200条测试集把约束LLM输出的几种主流手段挨个过了一遍纯Prompt规则、代码校验兜底、few-shot示范以及最后把三者叠在一起的组合方案。这篇文章就是这四轮实测的完整复盘包括每轮的具体做法、通过率数据、翻车现场以及我自己踩过的一些坑。如果你正在头疼怎么让LLM稳定输出结构化数据或者刚准备把LLM接进业务系统这篇应该能帮你省不少试错的时间。1. 先想清楚我们到底在约束什么1.1 LLM不是数据库它天生爱自由发挥很多人第一次对接LLM时下意识把它当成一个能理解自然语言的函数以为给它一个输入它就会乖乖返回你想要的输出结构。但模型本质上是概率语言生成器它的终极目标是生成一段看起来合理的文本而不是严格满足你的代码契约。打个比方你让一个新来的实习生写日报只说了一句写详细点他能给你写出三个不同风格的版本你不给他固定模板就别指望他每天交出来的东西长得一样。在生产环境里这种不稳定性是致命的。下游程序默认接收的是一段结构固定的JSON字段名、字段个数、数据类型、取值范围全都有约定。模型一旦在多输出一个字段、少写一个字段、或者把中性情感写成还行吧轻则解析报错重则数据被错误消费——有些校验不严的系统垃圾数据就这样悄悄进了数据库。所以约束LLM输出不只是让输出好看一点它解决的是三个层面的问题格式合法性能被程序解析、结构准确性字段齐全、类型正确、语义合理性枚举值合规、不编造。后面的几轮实测我每一轮都围绕这三个维度打分。1.2 四轮实测的测试方案设计为了让实验结论尽量贴近真实业务我选了三类常见任务命名实体抽取从一段文本里抽出人名、机构名、情感分类给文本打标签、结构化信息转换把非结构化信息整理成JSON。测试集一共200条从真实客服会话、商品评论、工单描述里随机抽的覆盖了各种脏输入——中英文混杂、没有实体、多个实体、情绪模棱两可等。每一条请求我都会人工标注一份标准答案然后跑一遍模型按下述标准判定通过结构层返回文本能被json.loads解析没有多余的MD代码块标记必需字段一个不少。类型层字段类型正确比如name是字符串、score是数值null和缺失必须区分对待。语义层枚举字段只允许在预设范围内取值不出现标准答案里没有的幻觉实体。四轮实验严格按逐步叠加约束的顺序来第一轮只靠Prompt规则第二轮加上代码校验与重试第三轮只加few-shot示范第四轮把三者全部叠加。每轮记录通过率、平均调用次数、额外token消耗。结论在最后统一对比。2. 第一轮实测只靠Prompt规则约束2.1 规则怎么写才能让模型听劝第一轮我参考了平时最常见的做法把Prompt规则写得极其详细生怕模型看不出我的要求。System消息里分配角色Rule段里一条条列明白只输出JSON对象、不要输出任何解释、字段名只能是给定的几个、枚举值只能取白名单里的值、无法确定的字段必须输出null而不是猜测、严禁自创字段。同时在用户输入的最后再重复一遍目标JSON模板强制模型照着这个骨架填。这样做确实有效果第一轮跑下来已经有78%的请求能一次通过这个数字比我预估的要高。规则里作用最大的是把JSON模板锚在Prompt末尾——模型对尾部内容的注意力通常比中间段更强这等于给它画了一棵结构树让它填空。2.2 实测数据78%的通过率以及常见的翻车形式那剩下的22%是怎么翻车的我统计了失败样本主要集中在四种形态超过一成样本会多输出一个解释性字段比如额外加了explanation或者reason哪怕我明确说了只允许两个字段。有部分样本把JSON里的null写成了None或者把布尔值写成了是/否。枚举值被同义改写的情况也很多比如允许neutral它给你回一个slightly positive。还有样本在输出外面包了json代码块标记导致json.loads直接报错。这些失败形态有一个共同特征不是模型不听话而是它以为自己听话了。它会觉得加上一个解释字段是合理的补充会觉得在输出外面包代码块是标准的Markdown格式。你站在人类的立场觉得这都叫违反要求但模型不这么想它在生成时只是在最大化整体语义通顺的概率。2.3 规则约束的边界与坑第一轮给我最大的教训是Prompt规则不是越写越细越好。我刚开始把规则堆到了十几条结果通过率反而下降了。后来我拆开看发现规则过多时模型容易顾此失彼——前面的规则记住了后面的规则被挤出了有效注意力范围而且规则之间还有隐性冲突比如你说输出要简洁又说给每个字段补充一句解释模型就会在两者之间随意权衡。另外负面指令的作用被普遍高估了。不要输出多余字段的效果远不如在Output Template里只列输出字段的效果好。与其告诉模型不能做什么不如给它一个具体可填的模板。因为负面指令需要模型先理解什么算多余这个判断本身就容易出错。到这儿我基本确认了一件事Prompt规则只能把模型从完全失控拉到大部分时候靠谱但永远会有尾部样本在边界上摇摆。规则这一层是必要的但绝不是充分的。3. 第二轮实测加代码校验兜底3.1 为什么Prompt挡不住的问题代码能挡住你可能会想第一轮里那些翻车形态能不能通过继续优化Prompt来彻底解决我的答案是很难。因为模型每次生成都是在做概率采样你把规则写得再死它依然存在一个极小的概率在某个词上飘一下。更关键的是模型并不是在执行程序它只是在模仿看起来正确的文本。你永远预测不到下一次它会在哪个环节冒出新花样。代码校验不一样它的哲学是我不在乎你为什么会错我只在乎结果能不能通过验收。规则说得再漂亮也只是期望而校验是合同。程序跑完模型输出后先来一道硬性检查过了才放行不过就走补救流程。这是工程上唯一不会跟你讲情面的兜底面。3.2 选型与实现从JSON Schema到Pydantic第二轮里我一开始用的是最朴素的json.loads加字段判断但很快发现手写校验逻辑在字段一多之后就变成了无尽的if-else。后来我把校验器换成了两层结构先用JSON Schema描述字段类型和必填项再用Pydantic模型做类型强转与枚举约束。为什么推荐Pydantic而不是手写if-else因为它会在反序列化失败时抛出非常具体的错误信息比如字段score应为int但收到了str这些错误信息稍加整理可以直接回传给模型作为修正提示。手写if-else当然也行但到了十几个字段的时候维护成本会让你怀疑人生。校验器具体做了三件事语法层文本能解析成JSON剥离掉等包裹符号、结构层必需字段是否齐全、类型是否匹配、null是否被允许、语义层枚举值是否在白名单里、数值是否落在合理范围内。我把语义层单独拆出来是有原因的——结构对了不代表内容能直接用枚举值越界是最容易让下游逻辑发疯的一种错误。3.3 实测数据校验拦截率与重试收益加上代码校验之后我把流程改成了解析失败或校验失败时把错误信息拼成一条你刚才的输出存在以下问题请修正后重新输出的辅助消息附加到对话历史里然后重试最多允许重试2次。200条样本跑下来最终通过率从78%提到了95%。其中重试1次就能救回来的占大多数重试2次才成功的只有个别崩溃案例——比如模型第一次把整个JSON截断了一半。最典型的单次错误是null和None混用重试时把错误信息字段author的值为None应为null喂回去模型基本秒懂。这里有个关键经验校验器返回的错误信息越具体重试成功率越高。如果你只告诉模型输出格式错误它往往不知道错在哪容易在同一个坑里再摔一次你把字段名、期望类型、实际值都写清楚模型就能按图索骥地修正。3.4 重试不是无脑多调两遍别急着重试先看看错误类型能不能过滤。我踩过一个坑有一个字段是昵称模型偶尔会把它输出成手机号校验器每次都拦截重试后模型改过来了但过几天它又开始犯。后来我加了单独的敏感信息守卫直接在输出里检测手机号格式一旦命中就不重试而是走人工兜底。因为这类错误靠重试解决不了你要么改Prompt要么在代码里强制脱敏。另外重试时要注意把temperature调低我会调到0.1左右让模型的输出分布更加集中修错的时候不容易再次发散。如果你用的是并发很高的批量任务还要考虑限流和成本一次重试意味着一次额外的API调用200条样本上多花的那点token看着不多但放大到日调百万级别每一轮重试都是真金白银。4. 第三轮实测加few-shot示范4.1 好示范的标准相似性、覆盖度、正反例第二轮结束后模型在结构合法性上已经没什么大问题但我在检查输出内容时发现模型偶尔会生成一些合法但不合理的答案。比如抽取实体时把原文里出现的品牌名当成人物名塞进name字段再比如情感分类时遇到模棱两可的文本会硬着头皮选一个极端情感。这类问题的本质是模型并不清楚这类输入应该如何处理它在结构上守规矩但在语义上依然要靠猜测。这时候轮到few-shot登场。给模型一两个高质量示范比在Prompt里写一百句请准确抽取都管用。我总结出的好示范标准是三个词相似性、覆盖度、少而精。相似性指示范的输入要尽量贴近真实场景别拿新闻稿示范去教它处理客服对话覆盖度指示范要涵盖那些容易出错的边界情况比如输入里没有目标实体时该怎么输出少而精则是指示范数量不是越多越好我试过放5个示范效果反而不如3个好因为这会占用更多上下文把真正要处理的输入往后挤。4.2 我给模型的三个few-shot样本我最终在第三轮固定了3个few-shot样本。第一个是常规输入加常规输出让模型建立起最基本的映射关系字段齐全、枚举值用标准写法。第二个是有目标实体缺失的输入输出时在对应字段写null同时保留confidence字段为0.0让模型学会不猜测。第三个是情感模糊的输入输出为neutral避免它强行往正负面靠。实测下来第三轮在不加代码校验的前提下结构通过率从第一轮的78%提到了91%。提升主要集中在枚举值改写这个老大难问题上——有了示范模型会直接复制你给的枚举写法而不是自己发挥同义词。这个收益在第一批测试里非常直观我那会儿甚至怀疑是不是校验都可以省了。但把话说回来few-shot也不是万能的。它提升的是语义合理性对JSON语法正确这种程序层面的问题帮助有限。我的测试里还是有一小撮样本在模仿示范的缩进结构时把格式搞乱了比如示范里用了带缩进的JSON模型也学着缩进但tm缩到一半突然断掉。好在后面把校验加上这个类型的错误也能拦得住。4.3 few-shot与规则的位置博弈还有一个细节值得单独说few-shot该放哪。我试过两种常见的做法把示例放在System消息里和把示例放在用户消息之前组成对话前缀。实测下来放在System消息末尾的效果更稳定因为前几轮都是规则-示例-输入的结构模型在生成时会习惯性靠近最近的格式而放在User消息里有时会被真正的用户输入混淆造成示例里出现了不该出现的字段模型也跟着学坏了。位置博弈的本质是注意力分配问题。模型对离生成位置越近的内容印象越深所以输入原文必须放在离生成最近的地方few-shot次之长串的法规式规则可以再往前放。如果你把顺序搞反了模型很可能会把一段冗长的规则当成需要回应的内容而不是约束条件。5. 第四轮实测规则加校验加few-shot的组合拳5.1 最终采用的调用流程第四轮不再纠结单一手段而是把前三轮的东西全部叠起来拼成一条完整流水线。整个流程是这样的组装Prompt的时候System消息包含角色设定、输出规则、3个few-shot示范User消息包含本次输入和目标JSON骨架。调用模型temperature设为0.1。模型返回后先做一层输出清洗把可能的json等包裹符号剥掉。接着做语法解析解析失败就把json.loads的报错信息回填给模型。解析成功后再走JSON Schema和Pydantic校验校验失败同样回填错误信息最多重试2次。如果重试后还是不达标就返回一个预设的兜底结果并打一条日志进监控系统留给人工处理。这一个流程看着繁琐但每个环节都有明确的职责Prompt负责尽量做对few-shot负责示范什么是对校验负责兜住做错的重试负责给模型第二次机会。每个环节拦截住的问题类型完全不同重叠度不高。5.2 四条路线的实测数据对比把四轮的通过率、重试率、平均耗时放在一起看会很清楚地发现组合方案并不是简单相加而是越到后面边际收益越高第一轮纯规则一次通过率78%最终通过率78%没有兜底手段。第二轮规则加校验一次通过率还是78%左右但重试后最终通过率提到95%。第三轮规则加few-shot一次通过率91%没有校验兜底最终通过率也就在91%左右。第四轮规则加校验加few-shot一次通过率约93%重试后最终通过率99.5%。第四轮的一次通过率只比第三轮高了2个百分点但最终通过率是四条路线里唯一逼近100%的。这印证了一个观点前三轮的努力主要在提高首帧质量而决定能不能上生产线的还是那层校验与重试的兜底。用99.5%这个数据说话大部分业务场景已经够了剩下的0.5%我建议不要硬追投入产出比太低交给人工兜底更划算。平均耗时上组合方案比纯规则多了约0.8秒主要是重试产生的额外调用。但考虑到它把故障率从22%压到了0.5%以内这点延迟完全值得。成本也类似每1000次调用大约多出10%-15%的token消耗主要消耗在重试以及few-shot占用的固定上下文上。你可以根据自己的业务容忍度决定把few-shot从3个砍到1个来省成本但后果是边界样本的表现会退化。5.3 组合方案的维护负担组合方案不是写完就一劳永逸的。最需要维护的是few-shot样本它们会随着业务输入形态的变化而逐渐失效。我后来养成了一个习惯每次从生产日志里捞一些新出现的失败案例定期刷新示范集把模型最新翻的车也变成正例教回去。这类维护工作量不大但一定要固定节奏不然过几个月你会发现few-shot里的场景已经跟真实流量脱节了。另外校验器里的枚举白名单也不是死的。业务上完全可能新增一种情感标签或实体类型你需要把更新流程跑在模型之前先改白名单再重新评估few-shot。我见过一个团队把白名单写死在代码里业务方改了需求之后没人更新结果模型输出新枚举时永远通不过校验重试到上限直接走降级——这类事故排查起来特别隐蔽。6. 常见问题与排查技巧实录6.1 常见问题速查表我把这轮实验期间踩过的、以及周围朋友常问的问题整理成一个速查表遇到类似现象可以直接对照着查症状可能原因解决思路JSON总是被截断max_tokens太小输出模板太长调大max_tokens把目标JSON骨架尽可能精简模型输出被json包裹模型把规则理解成要展示代码块清洗层先剥掉包裹符号同时把不输出代码块标记写成正向说明字段值合法但内容明显编造缺少失败出口模型被迫硬猜明确无法确定就输出null配一个缺失实体的few-shot同样错误反复出现重试两轮还错错误信息不够具体或者错误类型根本不该重试回填时带上字段名和期望值对特定敏感错误直接不重试枚举值被同义词改写模型在自由发挥白名单加大few-shot中枚举标准的权重单列一行合法枚举列表加了few-shot后格式反而乱了示范里有太多非必要格式模型跟着模仿示范里用最朴素的JSON缩进不展示多余注释校验器把合法输出拦截了校验规则写得太苛刻把null和缺失混淆先把允许为null与必须存在分开定义再跑测试集确认6.2 四个亲测有效的实用技巧最后分享几个不会写在官方文档里的小技巧。第一个是错误回填的措辞格式我发现把校验收到的信息整理成字段xxx的值yyy不合法合法值只能是[aaa, bbb]比单纯说格式错误有效得多。模型在交互式修复场景下对这种带具体位置的反馈几乎是条件反射式地修正。第二个技巧跟温度有关。如果你必须保留一点随机性比如做内容生成不想每次都一模一样至少把temperature控制在0.2以下。对结构化输出来说任何高于0.3的温度都是在给自己挖坑。别信什么温度高了更有创意在输出JSON这个场景里创意不是资产是负债。第三个技巧是给模型一个撤退路线。很多幻觉输出源于模型没有退路——你要求它必须给每个字段都填值它就只能硬编。我在系统提示里加了一句话如果输入信息不足允许字段输出nullconfidence设为0.0不鼓励猜测。加上这句话之后幻觉相关的失败率肉眼可见地降了一半。给模型一条合法的撤退路线比单纯禁止它乱猜要高出一截。第四个技巧比较隐蔽如果你在开发环境换过模型版本或者换过供应商一定要把整套约束方案重新回归一遍。不同模型对同样一段规则的服从度完全不同以前能通过的Prompt换一个新的开源模型可能就失效。我在实验最后顺手用另外两个模型试了同样的组合流水线通过率分别只有96%和92%。这说明约束方案和模型本身是绑定的别指望一套配置吃遍所有模型。我个人实际折腾完这四轮最深的感觉是约束LLM输出没有银弹。Prompt规则像驾驶培训教模型怎么开few-shot像是给了一张具体路线图说照着这个开代码校验是高速公路上的栏杆真出错时撞上它能保命。三者要一块儿上而且要让校验器真正接管终审权不要相信模型会凭自觉做到100%。如果你正打算在业务里接入LLM做结构化输出可以从纯规则开始把流程跑通后立刻补校验最后再根据失败样例慢慢加few-shot。按这个顺序推进投入产出比是最舒服的。