【核心理解-5】指令遵循与结构化输出：让 AI 按你的格式来

· 分类：核心理解

这一节点回答：怎么把概率模型的输出变成"可预期、可被程序使用"的

【小目标】

这一节点回答：怎么把概率模型的输出变成"可预期、可被程序使用"的？ 也就是生成侧的第三个旋钮——指令遵循 + 结构化输出 + 工具调用。

这里最关键的一句判断：光让模型"能说"不够，还要让它"说的能被程序接住"。 纯自然语言的回答人能看，但程序用不了——要让模型和系统对接，必须有格式约束。这一层是"LLM 从玩具变成工具"的关键开关。

对做产品的人来说，这一层直接决定了你的 AI 功能能不能真正接入业务流程。如果每次回答都是自由文本，下游还得再做一次解析，既不稳又慢；如果模型直接输出结构化 JSON，下游就能直接用，整个链路就稳了。

【方法论】

一句话结论：让输出可预期有三层手段，由浅入深：系统提示 → 结构化输出 → 工具调用。 越往深，可控性越强，但实现复杂度也越高。

③ Function Calling / 工具调用 —— 输出"调哪个工具、传什么参数"，外部真实执行
   ↑ （更可控，对接外部世界）
② 结构化输出（JSON schema）—— 强制格式，引擎级保证字段完整
   ↑ （更稳，程序可直接消费）
① 系统提示（System Prompt）—— 写清角色/规则/格式，约束全局行为
   ↑ （最基础，软约束）
可预期的输出

① 系统提示（System Prompt）—— 最基础的全局约束

  • 在对话开头设置角色、目标、边界、格式要求，约束模型全局行为
  • 好指令的三要素：
    • 具体：不说"你是个好客服"，说"你是电商导购客服，只回答商品相关问题，不聊其他"
    • 单一：一个指令只干一件事，别把五个任务塞在一个 prompt 里
    • 有示例：few-shot（少样本）比空讲规则更有效——给 1–2 个"输入→输出"的例子，模型学得更快
  • 局限：软约束，模型不一定 100% 遵守。强约束要用下面的结构化输出。

② 结构化输出（Structured Output / JSON Mode）—— 格式硬约束

  • 要求模型返回符合预定义 schema 的 JSON，甚至引擎级保证必填字段一定有、格式一定对
  • 和"请用 JSON 回复"的提示词不同——那是软约束（可能还是会返回自然语言），结构化输出是引擎级硬约束
  • 价值：让下游（路由/工具/落库）稳收数据，不用再去解析自由文本
  • 常用场景：
    • 意图识别结果输出为 JSON（{"intent": "...", "confidence": 0.92}）
    • 信息抽取（从合同里抽出字段，直接入库）
    • 函数调用的参数生成
  • 注意：结构化输出能力随模型版本波动，要回归评测——换模型版本后一定要测一下遵循率有没有掉

③ Function Calling / 工具调用—— LLM 对接外部世界的开关

  • 让模型输出"调哪个工具、传什么参数"的结构化意图，由外部系统真实执行
  • 这是 Agent（智能体）的基础——模型不只是回答问题，还能调用工具完成实际动作
    • 例子：用户说"帮我查一下订单" → 模型输出 调用 get_order 工具，参数 order_id=123 → 外部系统执行 → 把结果返回给模型 → 模型组织成自然语言回答用户
  • 和结构化输出的关系：结构化输出只约束"格式"，Function Calling 还决定"调哪个工具并传参"，二者常配合
  • 落地工程见阶段③第五章 Agent 系统工程

实践要点清单：

  • 指令要具体、单一、无歧义，别写大段模糊的要求
  • few-shot 示例比空讲规则更有用——给例子，模型学得更快更准
  • 能结构化就结构化——只要下游是程序，就优先用 JSON schema，别让下游再做一次解析
  • 结构化输出 + 低温 = 最稳的组合（结构化任务尽量把温度调到 0.1–0.3）
  • 换模型版本后一定要回归测试指令遵循率和结构化输出合规率——这类能力会漂

【知识点】

  • 让输出可预期有三层：系统提示（软约束）→ 结构化输出（格式硬约束）→ 工具调用（对接外部世界）。越往深越可控。
  • 好指令三要素：具体、单一、有示例（few-shot）。别写大段模糊的要求。
  • 结构化输出 ≠ "请用 JSON 回复"：前者是引擎级硬约束（保证格式正确），后者是软约束（可能还是会瞎写）。
  • Function Calling 是 LLM 对接外部世界的开关：模型不再只说话，还能调用工具干实事。这是 Agent 的基础。
  • 结构化输出 + 低温 = 最稳组合：结构化任务（抽取、路由、参数生成）尽量低温 + 格式约束。
  • 指令遵循率会漂：换模型版本后一定要回归测试，不能想当然认为"新版本更好"。

【名词卡】

名词 一句话解释
System Prompt / 系统提示 对话开头设置角色/规则/边界/格式的指令，约束模型全局行为
Instruction Following / 指令遵循 模型服从用户/系统指令完成指定任务的能力，是"按规矩办事"的基础
Structured Output / JSON Mode / 结构化输出 强制模型按预定义 schema 输出固定格式（JSON），使结果可被程序直接消费
JSON Schema 描述 JSON 结构的规范（有哪些字段、类型、是否必填），用于约束结构化输出
Function Calling / Tool Use / 函数调用 / 工具调用 让模型输出"调哪个工具、传什么参数"的结构化意图，由外部系统真实执行；是 LLM 对接外部世界的开关
Few-shot / 少样本 给出少量示例让模型学会某任务/格式，通常比空讲规则更有效
Zero-shot / 零样本 不给示例、直接让模型完成任务——考验模型的通用能力
Prompt Engineering / 提示词工程 通过设计 prompt 让模型更好地完成任务的技巧，产品化见 F4.4

易混对比：

  • 系统提示 vs 结构化输出：前者是软约束（写规则），后者是硬约束（引擎级保证格式）
  • 结构化输出 vs Function Calling：结构化只约束"输出格式"，Function Calling 还决定"调哪个工具并传参"
  • Few-shot vs Zero-shot：给示例 vs 不给示例，有示例通常效果更好但更费 token

【练一练】

目标：亲手感受"系统提示 + 结构化输出"的威力——从自由文本抽取结构化信息，对比有/无格式约束的差异。

实验：拿下面这段"用户留言"作为输入，分别做 A/B 两组测试：

用户留言："您好，我想退一下上周买的那个红色的无线耳机，订单号是 20240315001，原因是音质不太好，有点杂音。还有，我上次一起买的充电线能不能换个黑色的？谢谢！"

A 组（自由文本）：

提示词："请分析上面这段用户留言，告诉我用户想干什么。"

  • 观察：模型的回答格式是什么？如果要把结果给程序用，方便吗？

B 组（结构化输出）：

提示词："请分析上面这段用户留言，严格按以下 JSON 格式输出：

{
  "intent": "用户的主要意图，可选值：退款/换货/咨询/其他",
  "order_id": "订单号，如果没有则为 null",
  "product": "涉及的商品名称",
  "reason": "用户提到的原因，如果没有则为 null",
  "secondary_request": "是否有次要诉求，有则简述，没有则为 null"
}

只输出 JSON，不要其他文字。"

  • 观察：模型输出的 JSON 格式正确吗？字段都填对了吗？程序能直接用吗？

对比分析：

  • A 组和 B 组哪个对程序更友好？
  • 如果把 A 组的回答给程序用，你还需要做什么额外工作？（解析自然语言？写正则？）
  • B 组如果有字段填错了（比如 intent 选错了），你会怎么改进提示词让它更准？（加示例？把选项写得更清楚？）

进阶挑战：试着在 B 组的基础上加一个 few-shot 示例（在 prompt 里先给一个"输入→正确JSON"的例子），看加了示例后准确率有没有提升。

相关文章