大模型输出合法 JSON 却答非所问？结构化输出的深层陷阱与破解思路

在评估大语言模型（LLM）的应用效果时，我们常常陷入一个误区：只要模型能输出格式完美的 JSON，就认为它的“理解”和“回答”是可靠的。 然而，事实远非如此。一个模型可以轻松生成符合语法规范的 JSON 对象，但其中的字段值可能完全偏离事实、遗漏关键信息，甚至基于不完整的数据给出看似合理实则错误的结论。这种“形式正确，内容错误”的现象，正是结构化输出（Structured Outputs）在真实、混乱、不完整的数据场景中面临的核心挑战。

格式正确不等于语义正确

当我们要求 LLM 输出 JSON 时，模型本质上是在执行一项“格式化”任务。它学会了 JSON 的语法规则——正确的括号、引号、逗号，以及字段名与值的对应关系。但语法正确性（Syntax Validity）与语义正确性（Semantic Correctness）是两个完全不同的维度。

一个典型的失败案例是：当你向模型提供一段含有多条信息的文本，并要求它提取“所有客户姓名”时，模型可能会输出一个合法的 JSON 数组，但数组里只包含了部分姓名，或者错误地将“公司名称”识别为“客户姓名”。从 JSON 的角度看，输出是完美的；从任务的角度看，输出是失败的。

这背后的原因在于，LLM 的“注意力机制”在面对长文本、噪声数据或隐含信息时，可能会忽略关键的上下文线索。它倾向于生成“最常见”或“最可能”的答案，而不是“最准确”的答案。尤其是在数据不完整的情况下，模型会利用其内部先验知识进行“自动补全”，而这种补全往往是基于统计概率，而非对现实情况的确认。

结构化输出的固有局限

许多开发者寄希望于“结构化输出”功能（如 OpenAI 的 JSON Mode 或函数调用）来解决上述问题。诚然，这些功能在确保输出格式方面取得了巨大进步，但它们并未解决，也并未承诺解决“内容准确性”问题。

结构化输出主要约束模型输出的形式，而非内容。它通过约束解码（Constrained Decoding）或模式强制（Schema Enforcement）技术，确保模型输出的 token 序列符合预设的 JSON Schema。这意味着模型在生成过程中，每一步的候选 token 都被过滤，只保留能形成合法 JSON 的选项。然而，这种过滤机制并不理解字段的“业务含义”。

例如，你定义了一个 status 字段，其枚举值为 ["active", "inactive"]。模型可能会在上下文不明确时，基于概率选择输出 "active"，即使原文中该用户的状态是“已注销”（对应 "inactive"）。结构化输出保证了 status 的值只能是这两个之一，但无法保证它选对了。

这种局限性在以下场景中尤为突出：

• 数据缺失：原文中根本没有提及某个字段，模型需要“猜测”或“推断”，这极易出错。
• 信息冲突：原文不同部分对同一实体给出了矛盾的信息，模型需要“裁决”，这超出了结构化输出的能力范围。
• 隐含语义：字段值需要从上下文进行复杂推理才能得出，而非直接提取。

从“格式可靠”转向“内容验证”

既然结构化输出不能保证内容正确，我们在实际应用中就必须建立新的质量防线。依赖“输出 JSON 成功”作为成功标准，是一种危险的简化。我们需要将评估重心从“格式合规性”转向“内容验证”。

第一层：基于规则的验证。 这是最基础的防线。在拿到模型输出的 JSON 后，我们不应直接使用，而应先进行程序化检查。例如，检查必填字段是否存在、字段值是否在预期枚举范围内、日期格式是否正确、数值是否在合理区间。这些规则不依赖 LLM，完全由代码实现，能过滤掉一部分明显的“幻觉”和格式错误。

第二层：基于上下文的回退。 当规则验证失败时，我们不应直接给用户一个错误提示。更聪明的做法是，将验证失败的信息作为新的上下文，连同原始输入一起，再次提交给 LLM，要求其重新生成。例如，你可以提示模型：“你之前输出的 status 字段值为 active，但在原文中并未找到支持该状态的信息。请重新阅读原文，确认该用户的状态，如果原文未提及，请输出 unknown。” 这种“反馈-重试”机制能显著提升最终输出的准确性。

第三层：基于 LLM 的交叉验证。 对于高价值的应用场景，可以引入“评审者”模式。使用另一个 LLM（或同一个 LLM 的不同提示词）来审查第一个 LLM 的输出。评审者被要求“逐字核对”输出 JSON 中的每一个字段是否能在原始文本中找到依据。这种“生成-评审”的对抗性架构，虽然增加了成本，但能捕捉到许多单模型难以发现的错误。

拥抱“不确定性”与“不可知”

面对不完整的数据，我们还需要调整对模型的期望。与其强迫模型给出一个“确定”的答案，不如允许它表达“不确定性”。

在设计 JSON Schema 时，我们可以为每个字段增加一个 confidence（置信度）或 source（来源）属性。当模型无法从原文中找到确切依据时，它可以输出 null 或 "unknown"，并附上低置信度分数。这比让模型“硬猜”一个答案要可靠得多，因为它将“未知”状态显式地暴露给了下游系统，从而触发了人工介入或进一步的数据补充流程。

这种设计思路，承认了 LLM 并非全知全能，也承认了输入数据可能存在缺陷。它把“模型知道什么”和“模型不知道什么”清晰地分离，为构建健壮的 AI 应用提供了更坚实的基础。

从更广的视角看，这一原则与数据质量管理（Data Quality Management）的理念不谋而合。在传统的数据工程中，我们同样会区分“缺失值”和“错误值”，并采取不同的处理策略。LLM 时代的应用开发，应当继承这种严谨性，而不是被“AI 魔法”的光环所迷惑。

常见问题

为什么我的模型总是输出格式正确但内容错误的 JSON？

这是因为模型的语言建模目标与你的业务任务目标不一致。模型擅长生成符合语法规则的文本序列，但它并不理解字段的业务含义。当输入数据不完整或存在歧义时，模型会基于统计概率“猜测”一个最可能的答案，而不是基于事实推理。结构化输出功能只能约束格式，无法约束内容。

如何在不增加太多成本的情况下提升 JSON 输出内容的准确性？

可以尝试“反馈-重试”机制。在模型首次输出后，用代码进行规则验证（如必填项检查、枚举值检查），如果验证失败，将失败原因附加到原始提示中，要求模型重新生成。这种方法通常能显著提升准确率，且只增加了一次额外的 API 调用成本。

是否应该让模型在不确定时输出 null 或 unknown？

强烈建议。在 JSON Schema 中允许字段值为 null 或特定占位符，并提示模型在找不到依据时使用。这能有效避免模型“硬猜”导致的错误。同时，可以在字段旁增加 confidence 属性，让模型输出其判断的置信度，这为下游决策提供了更多信息。

结构化输出（Structured Outputs）和函数调用（Function Calling）有什么区别？

结构化输出通常指约束模型输出符合特定 JSON Schema 的功能，它专注于输出格式。函数调用则更进一步，它允许模型在对话过程中决定调用哪个函数，并生成对应的参数。函数调用内部也包含了结构化输出的机制，但增加了模型“决策”的环节。两者都无法保证参数值的语义正确性。

对于关键业务场景，如何设计更可靠的 LLM 数据提取流程？

建议采用“多级验证”框架。第一级，使用代码进行规则校验。第二级，将校验失败的信息反馈给模型，要求其重试。第三级，对于极高价值的场景，使用另一个 LLM 实例作为“评审者”，要求其逐字核对输出与原文的一致性。最后，确保你的 Schema 设计允许模型表达“不确定性”，将低置信度的结果导向人工审核流程。

关于 Bingdada

Bingdada 是一个专注 SEO、GEO（生成式引擎优化）与 AEO（答案引擎优化）的内容平台，由资深内容编辑、SEO 技术工程师与 AI 研究专家组成的团队持续运营。我们追踪搜索引擎与生成式 AI 的最新动态，为读者提供准确、实用、可落地的方法论与行业洞察。

编辑团队：内容策划 · 技术编辑 · AI 研究组
网站：bingdada.com

© 2026 Bingdada. 保留所有权利。