LLM 应用的结构化输出方案:从 JSON Mode 到 Function Calling 的四种实现

为什么需要结构化输出

LLM 的原生输出是自由文本,但实际应用中我们往往需要机器可解析的结构化数据——比如从简历中提取姓名、技能、工作经历,或者让 AI 助手返回可直接调用的函数参数。直接用正则或 JSON 解析自由文本容易遇到格式不稳定、字段缺失等问题,结构化输出方案就是为了解决这个痛点。

四种主流方案的技术实现

Prompt 工程 + 后处理

最基础的方案:在提示词中明确要求模型输出 JSON 格式,然后用代码解析。例如在 prompt 末尾加上"请以 JSON 格式返回,包含 {name, skills, experience} 字段"。

适用场景:原型验证、对格式要求不严格的场景。主要问题是模型可能返回带 Markdown 代码块包裹的 JSON、字段顺序不一致、或者在 JSON 前后加解释文字,需要写容错逻辑处理(如正则提取、trim 操作)。

JSON Mode

部分厂商(OpenAI、Google 等)提供的 API 参数,强制模型输出合法 JSON。调用时设置 response_format: {"type": "json_object"},模型会保证返回可解析的 JSON 字符串。

关键限制:你仍需在 prompt 中描述 schema,模型不会自动校验字段类型或必填项。假设你要求返回用户信息,模型可能返回 {"user_name": "张三"} 而不是你期望的 {"name": "张三", "age": 30},需要应用层二次校验。

适用场景:需要保证输出可解析,但 schema 简单或可以容忍字段差异的场景。

Structured Output(严格 schema 校验)

OpenAI 的 Structured Outputs 和 Anthropic 的类似能力允许你传入 JSON Schema,模型输出会严格符合定义的结构。你可以指定字段类型、枚举值、必填项,模型输出保证通过 schema 验证。

const schema = {
  type: "object",
  properties: {
    name: { type: "string" },
    age: { type: "number" },
    skills: { type: "array", items: { type: "string" } }
  },
  required: ["name", "age"]
};

工程优势:省去应用层的 schema 校验逻辑,减少解析错误导致的重试。权衡点:schema 定义需要前置设计,对于动态场景(比如用户自定义字段)灵活性较低。

Function Calling

让模型决定是否调用函数、选择哪个函数、以及传入什么参数。你定义函数签名(名称、参数 schema、描述),模型根据对话上下文返回结构化的函数调用请求。

const tools = [{
  type: "function",
  function: {
    name: "search_jobs",
    parameters: {
      type: "object",
      properties: {
        location: { type: "string" },
        keywords: { type: "array", items: { type: "string" } }
      }
    }
  }
}];

适用场景:多步骤任务、需要调用外部 API 或工具的 Agent 应用。模型不仅返回结构化数据,还做了「何时调用」的决策,适合构建复杂交互流程。

选型决策树

只需要可解析的 JSON,schema 灵活:JSON Mode
schema 固定且复杂,需要类型保证:Structured Output
需要模型主动决策工具调用:Function Calling
预算受限或使用不支持上述功能的模型:Prompt 工程 + 容错解析

工程实践建议

优先使用平台原生能力:Structured Output 和 Function Calling 的可靠性通常高于自己写解析逻辑。
设计降级策略:即使用了严格 schema,也要处理模型拒绝回答或超时的情况。
监控解析成功率:记录格式错误、字段缺失等指标,帮助优化 prompt 或切换方案。

如果你的团队正在构建 LLM 应用并需要在多个模型间灵活切换结构化输出方案,欢迎联系 Taylent Labs 了解我们的 AI 应用开发与 API 网关服务。