Java 工程师 LLM 工程化

Appearance

L01-01 LLM 基础概念与模型选型 ​

全局中心内容：模型不会「查」，只会「续写」——所有工程问题都从这句推导出来。 全局讲解主线：先纠正心智模型 → 再讲清三个参数 → 最后把成本换算成「一个月多少钱」。

P1 · 产出页 ​

中心内容：这节结束，你能自己算清一次调用花多少钱。

  • 页面内容

    • 三个能脱口而出的问题：发的是什么 / 花多少 / 选哪个
    • 一个 20 行的 Token 估算器

  • 讲解技巧

    • 用钱开场：直接说「这节课不写代码，但它决定你的账单是一千还是三万」。对比：同期学员里有人上线第一周烧掉两个月预算。
    • 不做任何铺垫，第二页立刻进痛点。

  • 时长：20s

P2 · 痛点页：三个真实的翻车 ​

中心内容：概念错了，代码写得越好跑得越快。

  • 页面内容

    • 把 3 万 Token 表结构塞进 system → 成本翻 30 倍且早期对话被挤掉
    • 抽取任务设 temperature 0.9 → 每次结果不同，加一堆正则兜底
    • 全流量打旗舰模型 → 账单超预算 8 倍

  • 讲解技巧

    • 这三条要用「有个同学」的口吻讲，不要用「你应该注意」。具体的人和具体的数字才可信。
    • 讲完停 2 秒，问：「这三件事，哪件你觉得不会发生在自己身上？」——通常没人举手，这就是钩子。

  • 时长：2min 30s

P3 · 原理图：模型看到的是什么 ​

中心内容：模型没有理解，只有续写。

  • 页面内容

    • 左：你以为发的（一句话）
    • 右：实际发的（system + 历史 + 输入，Token 序列）
    • 底部一行：模型在预测「下一个最可能的 Token」

  • 讲解技巧

    • 黑板留这张图：整节课只留这一张，后面每次解释现象都回来指它。
    • 用「成语接龙」类比：「我说『守株待』，你接什么？你不是在理解农业，你是在预测下一个字」。这个类比对 Java 工程师特别有效。

  • 时长：3min

P4 · 推论表：四个现象一个根因 ​

中心内容：幻觉、中段遗忘、否定失效、结果不同——全是续写的副产品。

  • 页面内容

    • 编造不存在的 API → 在续写「看起来合理的下一个 Token」
    • 长文档中间被忽略 → 注意力对中间位置权重低
    • 「不要做 X」反而做 X → 否定词把 X 的 Token 放进了上下文
    • 两次答案不同 → 采样是概率性的

  • 讲解技巧

    • 逐条提问：先问「为什么让它别做某事，它反而更爱做？」沉默 3 秒再答。这个反直觉的点讲透，后面讲 Prompt 工程学员会自己推导出结论。
    • 强调第二条的工程含义：重要信息放开头或结尾，别放中间——这是 RAG 排序的伏笔。

  • 时长：3min

P5 · 参数页：只记三个 ​

中心内容：temperature 决定稳不稳，maxTokens 决定贵不贵。

  • 页面内容

    • temperature：抽取/分类 0~0.2 · 对话 0.5~0.7 · 创意 0.8~1.0
    • maxTokens：必须显式设置
    • topP：一般不动

  • 讲解技巧

    • 可视化反差：同一句 prompt，temperature 0.1 和 0.9 各跑三次，屏幕并排展示输出差异。什么都不用解释，差异自己会说话。
    • 顺带纠正一个常见误解：「temperature 不是随机度，是采样分布的尖锐程度」。

  • 时长：3min

P6 · 上下文账本 ​

中心内容：上下文窗口是按 Token 算的总量，不是按轮数算的。

  • 页面内容

    • 公式：system + 历史 + 检索片段 + 输入 + 预留生成 ≤ 窗口
    • 中文经验值：1 汉字 ≈ 0.6~1 Token（保守按 1）
    • 一个 32K 窗口的实际配比示例

  • 讲解技巧

    • 现场算一遍：拿一个真实数字当场减，让学员跟着算。算完问「如果前端允许聊 50 轮会怎样？」——引出必须做裁剪，埋 01-06 的伏笔。
    • 提示：这是 02 篇 RAG 里「塞几个片段」的决策依据，现在讲清后面省很多事。

  • 时长：3min

P7 · 选型表：按任务分档 ​

中心内容：先证明能做，再逐级降本。

  • 页面内容

    • 分类/打标 → 轻量 · 摘要抽取 → 中档 · 代码/推理/Agent → 旗舰
    • 三步法：旗舰跑通 → 中档跑评测集 → 掉得少就降级

  • 讲解技巧

    • 给一个具体数字：「我们项目做完这三步，成本降了 60%」。真实数字比方法论有说服力。
    • 强调顺序不可颠倒：先用旗舰确认「这件事模型能做好」，再谈省钱。反过来做会陷入「便宜的模型不行，是不是我 prompt 写得不好」的自我怀疑。

  • 时长：2min 30s

P8 · 编码与验证：估算 vs 真实 usage ​

中心内容：估算用于预算，usage 用于对账，两者不能混。

  • 页面内容

    • TokenEstimator.estimate()：中文 0.7 / 英文 1/4
    • resp.getMetadata().getUsage()：厂商返回的才是计费依据
    • 偏差超过 30% 就要重新校准

  • 讲解技巧

    • 两次真实调用：一次纯中文、一次中英混合（比如贴一段日志），展示估算与 usage 的偏差。让学员看到「估算模型会被文本分布影响」。
    • 强调生产纪律：不要拿估算值给用户计费。

  • 时长：4min

P9 · 避坑与小结 ​

中心内容：三条记牢 + 当场算月成本。

  • 页面内容

    • 估算只用于预算，对账看 usage
    • maxTokens 必须显式设置（分类 50 / 摘要 500 / 生成 2000）
    • 超限不报错，表现为答非所问
    • 当场换算：日活 1000 × 20 次 × 0.003 元 ≈ 60 元/天

  • 讲解技巧

    • 最后这个换算是本节的收尾重击，一定要带着学员一起算。他们对「几分钱」没概念，对「一个月 1800」立刻有感。
    • 结尾悬念：「下节课我们让这个估算器真的接上模型」。

  • 时长：2min

讲师备忘 ​

项内容
课前必做准备 temperature 0.1 / 0.9 的对比输出截图；准备一次真实 usage 数值
最容易超时处P4 的现象解释，学员会追问「那 Prompt 工程还有用吗」——答「有用，就是在操纵这个前文」，然后收住
学员最常问「国产模型的 Token 换算一样吗？」答：各家分词器不同，这就是必须实测 usage 的原因
现场备用网络不通时，用预先存好的 usage 截图讲解，不影响主线