掌握 LLM 结构化输出：JSON 模式、函数调用与语法约束解码深度解析

假设你部署了一个复杂的聊天机器人，旨在将自然语言请求转换为精确的 API 调用。用户说：“帮我预订明天晚上 7 点四个人的位置。” 你的提示词要求 LLM 发送如下 JSON：{"restaurant": string, "party_size": int, "time": string, "date": string}。第一次，它返回了 {"restaurant": "海底捞", "party_size": 4, "time": "19:00", "date": "2026-06-15"} —— 完美运行。然而，下一次请求“周六中午点心”时，它在生成有效的 JSON 后跟了一句闲聊：“-- 顺便问一下，那里有带娃设施吗？”。

此时，你的 JSON 解析器会抛出异常，下游流水线崩溃，你的 Slack 报警频道在凌晨 2 点疯狂闪烁。问题的根源在于：像 n1n.ai 上提供的这些大语言模型（LLM）生成的是 Token（令牌），而不是数据结构。你要求的任何 Schema（模式）都只是建议，而非强制约束。对于依赖结构化输出的生产系统，必须在 Token 级别强制执行模式。

结构化输出的三个必用场景

在企业级应用中，结构化输出在以下场景中是不可或缺的：

1. API 封装与函数调用 (Function Calling)：代表用户调用工具的 LLM 必须生成符合工具 JSON Schema 的参数。哪怕只有 2% 的格式错误，也会导致持续的运行错误、重试或静默失败。
2. 数据提取与 ETL 流水线：如果你让 LLM 处理 10,000 张支持工单并提取 {customer_id, sentiment, category}，任何多余的字段、缺失的括号或非 JSON 文本都会导致数据清洗脚本失效。
3. 多步智能体循环 (Agent Loops)：在 LangChain 等框架中，Agent 的每一步输出都是下一步的输入。如果第 2 步输出了自由文本而不是函数调用，整个循环就会停滞，浪费 Token、增加延迟并产生额外费用。

实现结构化输出的三种途径

目前开发者主要有三种方式来强制 LLM（如 DeepSeek-V3 或 Claude 3.5 Sonnet）生成结构化数据。它们在可靠性、延迟和集成深度上各不相同。

1. 仅靠 Prompt 的 JSON 模式：原型开发阶段

这是最简单的方法：在提示词里告诉模型只输出 JSON。通过 n1n.ai 调用各种模型时，你可能会写出如下提示词：

你是一个数据提取助手。
请提取请求的字段并仅输出有效的 JSON。
不要包含任何解释、Markdown 格式或额外文本。

对于像 OpenAI o3 这样强大的模型，成功率可能达到 95%，但失败模式令人抓狂：多余的逗号、缺失的反括号、或者在 JSON 前后加上 json 这样的代码块。其根本缺陷在于，Prompt 无法干预 Token 的生成概率分布。如果模型生成到一半突然想“道歉”，它就会直接输出文本，而不管 Prompt 里的约束。

2. API 级别的结构化输出与函数调用

为了解决上述问题，OpenAI 在 2024 年推出了 JSON Schema 模式，随后行业纷纷效仿。通过在 API 请求中传递 response_format，服务商会在后台使用验证器，在 Token 生成过程中实时屏蔽掉会导致无效 JSON 的 Token。

Python 实现示例：

from openai import OpenAI

# 通过 https://n1n.ai 获取高性能模型访问权限
client = OpenAI(api_key="YOUR_N1N_API_KEY", base_url="https://api.n1n.ai/v1")

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "提取信息：张三，28岁，[email protected]"}],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "user_info",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "name": {"type": "string"},
                    "age": {"type": "integer"},
                    "email": {"type": "string"}
                },
                "required": ["name", "age", "email"],
                "additionalProperties": False
            }
        }
    }
)
print(response.choices[0].message.content)

开启 strict: True 后，输出结果被保证 100% 符合 Schema。对于在 n1n.ai 上构建生产级应用的开发者来说，这是最推荐的方式。

3. 语法约束解码 (Grammar-Constrained Decoding)：终极方案

如果你运行的是本地模型（如使用 vLLM 或 llama.cpp 部署的 DeepSeek-R1），你可以使用语法约束解码。这种技术通过修改采样循环，在生成每个 Token 时，直接将不符合语法规则的 Token 概率降为零。

Outlines 和 Guidance 是这类技术的代表。它们将 JSON Schema 转换为上下文无关语法 (CFG) 状态机。例如，如果当前位置应该出现数字，状态机会告诉模型：除了 0-9 这几个 Token，其他所有 Token（如逗号、字母、空格）的生成概率全部设为 0。

为什么它比重试更好？

• 确定性：它不是在生成后检查，而是在生成时引导。它永远不会生成无效的 JSON。
• 效率：虽然每步计算会有微小的延迟开销，但由于避免了重试，整体吞吐量往往更高。

# 使用 Outlines 强制执行 Pydantic 模式
from pydantic import BaseModel
from outlines import models, generate

class Product(BaseModel):
    name: str
    price: float

model = models.transformers("Qwen/Qwen2.5-7B-Instruct")
generator = generate.json(model, Product)

# 输出绝对符合 Product 类的定义
result = generator("这款手机卖 4999 元")

专家建议与避坑指南

1. Schema 编译开销：Outlines 等工具在开始生成前需要编译 Schema。对于极其复杂的嵌套 Schema，编译可能耗时 2-10 秒。请务必缓存编译后的语法对象。
2. 严格模式的局限性：OpenAI 的 Strict Mode 不支持某些复杂的 JSON Schema 特性（如 additionalProperties: true）。如果你的需求非常灵活，可能需要退而求其次使用普通 JSON 模式并配合代码校验。
3. 模型性能差异：在处理复杂的结构化输出时，DeepSeek-V3 的表现非常出色，甚至在某些逻辑严密性上超过了 GPT-4o。建议通过 n1n.ai 同时测试不同模型，选择性价比最高的方案。
4. Token 屏蔽 vs. 重采样：早期的某些实现采用“如果不合法就重新生成”的策略，这非常浪费资源。请优先选择像 llama.cpp GBNF 这样直接在采样层屏蔽非法 Token 的框架。

什么时候不应该使用结构化输出？

• 开放式创作：如果你在写小说或进行头脑风暴，强制的语法约束会严重限制模型的发散思维，导致内容枯燥乏味。
• Schema 频繁变动：如果你的数据结构每小时都在变，语法编译和测试的成本将远超其带来的收益。此时，建议先使用 Prompt 引导，待结构稳定后再加固。
• 极致低延迟：语法屏蔽会带来微小的每 Token 延迟。对于要求在 100ms 内返回响应的高吞吐场景，使用简单的 Prompt 配合一个宽容的解析器可能是更务实的权衡。

总结

结构化输出是 LLM 从“玩具”走向“工具”的关键一步。对于大多数开发者，通过 n1n.ai 调用支持 JSON Mode 或函数调用的 API 是平衡开发效率与运行稳定性的最佳选择。而对于追求极致控制的本地化部署，语法约束解码则是不可或缺的技术利器。

在 n1n.ai 获取免费 API Key。