Java 工程师 LLM 工程化

Appearance

L01-08 结构化输出 ​

全局中心内容：temperature 不设 0，是结构化抽取失败的第一原因。 全局讲解主线：只靠 prompt 会怎样 → 约束的两种强度 → 写出带兜底的抽取器 → 连跑 5 次验证。

P1 · 产出页 ​

中心内容：一段描述进去，一个 Java 对象出来，失败也不崩。

  • 页面内容

    • Ticket 对象含枚举、列表、布尔
    • 自带校验与兜底
    • 解析失败不让异常穿透到用户

  • 讲解技巧

    • 说清价值：这是 AI 接入业务系统的关键一跳——只有变成对象，才能写进数据库、才能触发流程。
    • 预告本节会故意让模型返回脏数据。

  • 时长：20s

P2 · 痛点页：五种脏输出 ​

中心内容：你在 prompt 里写「请返回 JSON」，模型可以选择不听。

  • 页面内容

    • 加 ```json 代码块标记（极高）
    • 加「好的，这是结果：」前缀（高）
    • 字段名/驼峰不一致（中）
    • 枚举值跑偏（中）
    • 少字段多字段（中）

  • 讲解技巧

    • 现场展示一段真实脏输出，最好是自己项目里截的。真实的比构造的有说服力。
    • 给频率标注（极高/高/中）：让学员知道哪些是必然会遇到，不是小概率。

  • 时长：2min

P3 · 原理图：两种约束强度 ​

中心内容：prompt 约束是请求，原生结构化是强制。

  • 页面内容

    • Prompt 约束：写 Schema 进 prompt，兼容性好，靠模型遵循
    • 原生结构化：厂商采样层强制，稳定性高，支持度参差
    • 叠加使用最稳

  • 讲解技巧

    • 用「请求 vs 强制」这组对比词，一句话讲清本质差异。
    • 诚实说明：兼容端点上 responseFormat 未必生效，要实测。

  • 时长：2min 30s

P4 · Converter 家族 ​

中心内容：90% 用 BeanOutputConverter。

  • 页面内容

    • BeanOutputConverter<T> → 类型安全，推荐
    • MapOutputConverter → 结构动态时用
    • ListOutputConverter → 抽取标签列表

  • 讲解技巧

    • 重点讲 Converter 的清洗能力：能剥代码块、剥前后缀。这就是该用它而不是自己 readValue 的原因。
    • 画一张清洗流程图：脏输出 → 剥壳 → 干净 JSON → Jackson → 对象。

  • 时长：2min

P5 · 影响因素排序 ​

中心内容：先调 temperature，再谈换模型。

  • 页面内容

    • ① temperature（0~0.2）
    • ② Bean 字段设计（含 @JsonPropertyDescription）
    • ③ 模型能力

  • 讲解技巧

    • 这个排序本身是本节观点输出：很多人一失败就换更贵的模型，其实调 temperature 能解决大半。
    • 用一句反常识的话收尾：「省钱的方法往往是调参数，不是换模型」。

  • 时长：2min

P6 · 编码：Bean 与描述 ​

中心内容：@JsonPropertyDescription 不是装饰，它决定填得对不对。

  • 页面内容

    • 每个字段写取值范围与约束
    • 枚举写「只能取 LOW / MEDIUM / HIGH 之一」
    • 列表写「最多 3 条，没有则为空列表」

  • 讲解技巧

    • 对比演示：去掉描述后模型开始自由发挥，字段值五花八门。
    • 强调这些描述会被写进 Schema 给模型看——不是给 IDE 看的注释。

  • 时长：4min

P7 · 编码：Converter 与 prompt 注入 ​

中心内容：用 tpl.create(Map) 做变量替换，别拼字符串。

  • 页面内容

    • new BeanOutputConverter<>(Ticket.class)
    • converter.getFormat() 生成 Schema 说明
    • .param("format", format) 注入
    • options.temperature(0.0)

  • 讲解技巧

    • 可视化反差：展示 getFormat() 实际生成的那段 Schema 文本。学员第一次看到会觉得「原来框架帮我写了这么多」。
    • 强调 temperature 必须显式写 0.0，不要依赖默认值。

  • 时长：4min

P8 · 编码：校验与兜底 ​

中心内容：永远不要让解析异常穿透到用户面前。

  • 页面内容

    • 重试 2 次
    • validate() 业务校验
    • Ticket.fallback(description) 兜底

  • 讲解技巧

    • 这段兜底比转换本身更重要，要放慢讲。理由：抽取失败是必然的，问题是失败后系统怎么办。
    • 给出设计原则：返回 fallback 让流程继续（进人工队列），好过抛异常中断工单流程。

  • 时长：4min

P9 · 验证与小结 ​

中心内容：连跑 5 次，单次成功不算成功。

  • 页面内容

    • 字段完整、枚举合法、列表不超限
    • 同一输入连跑 5 次结果稳定
    • 脏输入返回 fallback 不报错

  • 讲解技巧

    • 强调「连跑 5 次」这一步不能省：单次成功说明不了任何问题。
    • 结尾悬念：「JSON 语法完全正确，但内容全是编的——你的校验能发现吗？」引出 02-11 引用溯源。

  • 时长：2min

讲师备忘 ​

项内容
课前必做准备 temperature 0 与 0.7 各跑 5 次的结果对比；准备一段真实脏输出样本
最容易超时处P8 的兜底设计，容易展开讲业务补偿——收住，说「这是架构话题」
学员最常问「嵌套多深会失败？」答：经验值字段 8 个以内、嵌套 2 层以内，超了拆成多次调用
现场备用模型不稳定 → 用假模型返回固定的脏输出继续讲清洗逻辑，主线不受影响