面经策

大模型的结构化输出指的是什么？ ​

  • 标签：AI、大模型

🏛 业务架构师 ​

结构化输出指让大模型严格按预定义的 Schema（JSON Schema、Pydantic 模型等）生成结果——字段名、类型、枚举值都受约束，输出可以直接被程序解析入库，而不是给人看的自由文本。

为什么它是企业落地的分水岭：大模型要进入业务流程，产出就必须能和下游系统对接——工单要写进数据库、标签要进推荐系统、抽取的字段要过规则引擎。自由文本没法编程消费，"模型输出 JSON 但多了一句解释"就能让程序崩掉。结构化输出把模型从"聊天玩具"变成"流程中可编排的组件"，这是从 Demo 到生产的必经一步。

实现方式：一是靠提示词+重试（脆弱，老模型经常翻车）；二是 Function Calling/Tool Calling 天然返回 JSON；三是 2024 年后主流模型支持的约束解码（如 OpenAI Structured Outputs），在解码层面保证 100% 合法。

业务建议：任何要对接系统的场景都强制结构化输出，并在 Schema 里设计兜底字段（如 confidence、needs_human_review），让低置信结果进人工队列而不是污染业务数据。成本上它几乎免费，属于"不做才有成本"的那类工程决策。

🏗 系统架构师 ​

结构化输出 = 让 LLM 的输出严格符合预定义的数据 Schema（JSON、枚举、嵌套结构），从"自然文本"变成"可被程序消费的数据"。这是 LLM 从聊天玩具变成系统组件的分水岭——下游代码、工具调用、流水线编排都依赖确定性接口。

实现手段三层：

  • Prompt 约束：给 Schema + few-shot，声明"只输出 JSON"。最弱，模型仍可能输出多余文字或字段缺失，必须配重试与修复逻辑；
  • 受限解码（Constrained Decoding）：在推理时按语法（JSON Schema 编译成的文法/FSM）约束采样，每个 token 只允许合法转移，物理上保证输出合法 JSON——OpenAI Structured Outputs、outlines、vLLM guided decoding 都是这个路线，这是生产级方案；
  • 校验 + 修复：Pydantic/JSONSchema 校验，失败走"错误信息回喂模型重试"的 auto-fix 循环（最多 2~3 次，然后降级）。

架构要点：结构化输出是 Agent 工具链的地基（Tool Calling 的参数、多步编排的状态传递都靠它）；我会在系统边界统一做 Schema 校验（never trust model output），字段设计上避免深嵌套和过强约束——约束越死，模型表达越扭曲，质量越差。

💻 全栈开发专家 ​

结构化输出就是让模型的回答严格符合预定义的数据结构（JSON Schema、Java Bean、枚举），从「一段自然语言」变成「程序可直接消费的数据」。它对工程太重要了：下游解析、入库、前端渲染、Agent 工具链都依赖确定性结构。

实现手段按可靠度排序：

  1. 受约束解码（最可靠）：OpenAI Structured Outputs、outlines/xgrammar，在解码层面只允许合法 token，100% 合法 JSON；
  2. 框架封装：LangChain withStructuredOutput、Spring AI BeanOutputConverter 自动生成 schema + 解析校验 + 重试；
java
record Order(String orderId, BigDecimal amount, OrderStatus status) {}
Order o = ChatClient.create(chatModel).prompt()
    .user("提取订单信息：" + text)
    .call().entity(Order.class);   // 直接拿 Java 对象
  1. Prompt 约定（兜底）：在 prompt 里贴 schema + few-shot，配合 JSON mode 和解析失败重试。

坑：模型偶尔加 markdown 围栏或前后缀废话，解析前先抽取首个 {...} 块；嵌套复杂 schema（深层 oneOf）小模型容易崩，要么拆成两次调用要么换强模型；日期、BigDecimal 格式要在 schema 里用描述钉死。