面试题 09：如何稳定地让大模型输出符合业务规范的 JSON 或 XML 格式数据？

Corey2026/6/16大约 4 分钟面试题面试题

来源：面试题 09：如何稳定地让大模型输出符合业务规范的 JSON 或 XML 格式数据？

一、痛点分析：为什么大模型很难直接输出 JSON？

大语言模型（LLM）的底层逻辑是“文本接龙”，它被训练成一个乐于助人的对话助手。因此，它天生具有“话痨属性”。
当你要求它输出 JSON 时，它往往会：

添加前缀/后缀：“好的，这是您需要的 JSON 数据：\njson\n{...}\n\n希望对您有帮助！”
幻觉字段：自行捏造了你没有要求的 JSON 字段。
语法错误：在复杂的嵌套结构中漏掉逗号、括号，或者转义字符错误。这些问题会导致后端业务代码在执行 JSON.parse() 时直接抛出异常，导致系统流程中断。

在工程实践中，我们通常采用以下三个层级的手段来保证结构化输出的稳定性：

明确的 Prompt 约束：
在 System Prompt 中严厉声明：“你是一个数据转换器。只允许输出合法的 JSON，不要包含任何 Markdown 格式（如 ```json），不要输出任何解释性文本。”
提供 Few-Shot（少样本）示例，给模型打个样。
大厂 API 原生支持：
JSON Mode：在调用 OpenAI 等 API 时，传入 response_format: { type: "json_object" }。这会强制模型输出 JSON 格式（但仍不能保证字段 100% 符合你的要求）。
Structured Outputs / Function Calling：OpenAI 最新的结构化输出功能，允许你传入一个 JSON Schema，模型会严格按照这个 Schema 的字段定义来输出。

即使有了 Level 1 的防护，模型偶尔还是会犯错。在业务代码层，我们需要引入容错机制。

Output Parsers（输出解析器）：
使用 LangChain 的 PydanticOutputParser 等工具。你在代码中定义好 Pydantic 数据模型，框架会自动帮你生成一段包含格式要求的 Prompt。
Retry Loop（重试循环）：
这是非常核心的工程思维。在代码中加入 try-catch 逻辑。
如果解析 JSON 失败，捕获 SyntaxError，并将这个报错信息作为新的 Prompt 发回给大模型：“你刚才生成的 JSON 存在语法错误，报错信息为：[Error Message]，请修复该错误并重新输出。”
通常经过 1-2 次重试，大模型就能自行修复语法错误。

如果你是本地私有化部署开源模型（如 Llama 3, Qwen），你可以使用最硬核的物理锁。

原理：在模型推理（生成 Token）的底层阶段进行干预。系统会根据你定义的 JSON Schema 构建一个状态机（FSM）。在模型预测下一个 Token 时，系统会实时屏蔽掉所有不符合 JSON 语法的 Token（将其概率设为 0）。
工具：开源库如 Outlines, Guidance，或者 llama.cpp 原生支持的 Grammar 参数。
优势：不需要大模型去“理解” JSON 语法，而是从数学层面上强行剥夺了它输出非法字符的权利，实现 100% 的格式准确率。

展现工程韧性（Resilience）：“在企业级应用中，我们永远不能假设大模型的输出是 100% 可靠的。面对结构化输出，防御性编程（Defensive Programming）是必须的。除了使用 JSON Mode，我们一定会在代码层套一层带有 Auto-Correction（自修复）逻辑的解析器。”
区分闭源与开源场景：“如果是调 OpenAI 的接口，我们会优先使用它最新的 Structured Outputs 功能；但如果是我们公司内部自己部署的开源模型，我会推荐使用 Outlines 这类库做底层的 Grammar Constraint，这比靠 Prompt 约束要稳定得多，而且节省 Token。”
处理 Markdown 标记的实用小技巧：“在实际开发中，如果模型顽固地输出了