5 篇博文 含有标签「structured-output」

一个团队发布了一个文档提取流水线。它使用了 JSON 模式。QA 通过了。监控显示解析错误接近于零。六周后，一个隐蔽的失败浮出水面：语料库中的每一份风险评估都被标记为 “低” —— JSON 格式有效，字段名称正确，但答案是错的。该流水线已经在以符合架构（Schema）的格式自信地撒谎了好几周。

这是将 JSON 模式视为可靠性保证的核心问题。结构一致性（Structural conformance）和语义正确性（Semantic correctness）是系统的不同属性，混淆两者是生产级 AI 工程中最代价高昂的错误之一。

每个集成工程师都曾面对过两个拒绝相互通信的系统。一个说的是 2008 年的 SOAP XML，另一个期望的是上季度刚设计的 REST JSON 负载。传统的解决方案——编写自定义解析器、维护映射层、祈祷没人改动模式——在第三或第四个系统加入之前都还能用。之后你就要维护一个没人愿意接手的组合爆炸式翻译代码了。

现在团队正在将 LLM 放入这个缺口中。不是作为聊天机器人，不是作为代码生成器，而是作为运行时协议翻译器——读取一种格式并输出另一种格式。对于某些用例，它的效果出奇地好——而对于其他用例，它的失败方式则真正令人担忧。理解这两个区域之间的边界就是整个博弈的关键。

当开发者第一次接入 JSON 模式时，响应结果感觉就像解决了一个大问题。LLM 不再返回 Markdown 围栏、文字道歉或靠近花括号的乱码。输出可以解析了，测试通过了，生产环境上线了。

然而，三周后，一个后台作业悄无声息地失败了，因为模型在 Schema 要求 {"status": "completed"} 时返回了 {"status": "complete"}。由于一个必填字段返回了 null 而不是被省略，数据流水线崩溃了。智能体工具调用循环（agent tool-call loop）提前终止，因为模型在字符串值中嵌入了一个异常换行符，导致下游解析器卡死。

JSON 模式保证了语法上有效的 JSON。它并不保证该 JSON 的含义与你的预期一致，不保证它包含你的应用程序所期望的字段，也不保证在多次请求之间保持语义一致性。这些是不同的问题，需要不同的解决方案。

大多数基于 LLM 的应用中都潜伏着一个隐形 Bug。它不会出现在单元测试中。在前一千次请求中也不会触发。它会一直潜伏，直到用户输入了带有引号的内容，或者模型出于某种莫名其妙的原因决定将其 JSON 响应包裹在 Markdown 代码块中，再或者将 "count" 字段作为字符串 "three" 而非整数 3 返回。这时，你的生产流水线就会崩溃。

“LLM 是文本生成器”与“我的应用需要结构化数据”之间的鸿沟，是大多数可靠性问题产生的原因。弥补这一鸿沟并非 Prompt 工程问题，而是一个基础设施问题。在 2026 年，我们终于拥有了能够正确解决这一问题的工具。

在生产环境中的某个阶段，每个由 LLM 驱动的应用都需要停止将模型输出视为散文，而开始将其视为数据。当你尝试从语言模型中可靠地提取 JSON 对象——并将其输入到下游的数据库、API 调用或 UI 中时——你会发现这有多少种出错的方式。模型会将 JSON 包裹在 Markdown 栅栏中。它会生成一个有效的对象，但遗漏了必填字段。它在多次调用中格式化日期的格式不一致。它会幻觉出枚举值。这些失败中的任何一个都会静默地破坏下游状态。

结构化输出已经从一个事后才考虑的问题演变成生产级 LLM 系统的一等公民。这篇文章介绍了强制执行结构化输出的三种主要机制、各自失效的场景，以及如何在约束下设计高质模式（Schema）。