Appearance
课 1 · LLM 够用的原理
本课目标
理解 Token、Context Window、Temperature 这几个核心概念，建立正确的心智模型。不需要推导公式，能用工程师的语言说清楚就够了。
做 AI 应用开发，不需要训练模型，但需要理解模型的工作方式——否则你写的代码会遇到各种"莫名其妙"的问题：对话突然忘事了、回答不稳定、成本失控、响应变慢。
这些问题的根源都在 LLM 的基本原理里。本课只讲应用开发用得上的部分。
Token：LLM 的计量单位
LLM 不直接处理文字，它处理的是 Token——一种介于字和词之间的文本片段。
"Hello world" → ["Hello", " world"] → 2 tokens
"你好世界" → ["你", "好", "世", "界"] → 4 tokens
"TypeScript" → ["Type", "Script"] → 2 tokens
"backgroundColor" → ["background", "Color"] → 2 tokens为什么要知道 Token
因为 LLM 的两个核心限制都按 Token 计：
- 上下文窗口（Context Window）：模型一次能处理的 Token 上限
- 价格：按输入和输出的 Token 数量计费
Token 的粗略估算
- 英文：1 Token ≈ 4 个字符，或 ≈ 0.75 个单词
- 中文：1 个汉字 ≈ 1～2 个 Token
- 代码：变量名、关键字等通常 1～3 Token
准确数量用 tokenizer 工具计算。OpenAI 提供了 tiktoken。
Context Window：为什么对话会 "忘事"
Context Window 是模型一次调用能处理的 Token 总量上限，包含输入和输出。
目前主流 LLM 的 Context Window 常见在 1M tokens 左右，粗略可以理解为能装下 约 2,500 页文档。
看起来很大，但实际应用中消耗很快：
先看一张结构图，建立“上下文窗口其实是在分配有限容量”的直觉：
Context Window 容量分配
System Prompt~500 Tokens
→
历史消息~8,000 Tokens
→
RAG 文档片段~2,000 Tokens
→
当前问题~100 Tokens
→
输出预留空间
这些内容共同挤占同一个窗口；超出窗口的更早内容，本轮模型就看不到。
System Prompt ~500 tokens
前 10 轮对话历史 ~8,000 tokens
RAG 检索到的文档片段 ~2,000 tokens
当前用户问题 ~100 tokens
─────────────────────────────────
总计 ~10,600 tokens（还没算输出）工程含义
- 对话越长，可用空间越少：前面的消息占了位置，后面的回答质量会下降
- 超出窗口的内容直接丢失：模型不会报错，它只是"看不到"那些内容——这就是对话"忘事"的原因
- 窗口越大，速度越慢、成本越高：不是越大越好
后面的课会讲具体怎么管理上下文窗口。现在只需要记住：Context Window 是有限的，你的代码需要管理它。
LLM 怎么生成文本
所有主流 LLM（GPT、Claude、Qwen、Llama）都基于 Transformer 架构。你不需要了解它的内部结构，只需要知道两件事：
1. 逐 Token 生成
LLM 每次只生成一个 Token，然后把它加到已有内容后面，再生成下一个。你在 ChatGPT 里看到的"打字机效果"就是这个过程的直接体现。
2. 能"看到"所有上下文
生成每个 Token 时，模型会参考 Context Window 里的所有内容——不管距离多远。这就是为什么你可以在对话开头给一段背景信息，模型在后面回答时仍然能用上。
Temperature：控制输出的"随机性"
LLM 的生成过程是概率采样：模型为每个可能的下一个 Token 计算概率，然后从中选一个。Temperature 和 Top-P 控制的就是"怎么选"。
Temperature 控制概率分布的"锐利程度"：
| 值 | 效果 | 适用场景 |
|---|---|---|
| 0 | 总是选概率最高的 Token，输出完全确定 | 代码生成、结构化数据提取、分类任务 |
| 0.3~0.7 | 大部分时候选高概率，偶尔有变化 | 通用对话、内容生成 |
| 1.0+ | 更随机，可能出现意外的表达 | 创意写作、头脑风暴 |
实践建议
typescript
// 需要确定性输出（JSON、代码、分类）
{ temperature: 0 }
// 通用对话
{ temperature: 0.7 }
// 创意场景
{ temperature: 1.0 }temperature: 0 是 AI 应用开发中最常用的设置——因为你通常希望输出稳定可控。
还有个参数叫 Top-P
Top-P 也能控制随机性，但一般只调 temperature 就够了，不需要同时调两个。后续课程用到时再介绍。
模型选型：结论直接给
不做深度对比，给工程选型结论：
默认选择
| 场景 | 推荐 | 原因 |
|---|---|---|
| 复杂推理、Agent、代码 | Claude Opus 4.6 | 最强智能，Agent 和编程首选 |
| 速度与智能平衡 | Claude Sonnet 4.6 / GPT-5.4 | 速度快，性价比高，通用首选 |
| 中文场景、国内部署 | Qwen3.6-Plus | 中文理解最好，可私有化部署 |
| 低成本、高并发 | GPT-5.4 mini / Claude Haiku 4.5 | 性能够用，价格低一个数量级 |
选型思路
- 先跑通再优化：先用最强的模型（Opus / Sonnet / 5.4）把功能做出来，验证效果，再考虑换便宜的模型
- 按任务选模型：一个应用里可以对不同任务用不同模型——复杂推理用大模型，简单分类用小模型
- 价格差距很大：Opus 和 Haiku 的价格差 5 倍以上，Sonnet 和 mini 的差距也很显著，在生产环境中这是必须考虑的因素
价格参考（2026 年 4 月）
| 模型 | 输入 | 输出 |
|---|---|---|
| Claude Opus 4.6 | $5 / 1M tokens | $25 / 1M tokens |
| Claude Sonnet 4.6 | $3 / 1M tokens | $15 / 1M tokens |
| Claude Haiku 4.5 | $1 / 1M tokens | $5 / 1M tokens |
| GPT-5.4 | $2.5 / 1M tokens | $15 / 1M tokens |
| GPT-5.4 mini | $0.75 / 1M tokens | $4.5 / 1M tokens |
| Qwen3.6-Plus | ¥2 / 1M tokens | ¥12 / 1M tokens |
价格变动
模型价格变动频繁，以上仅供参考。实际开发中请查阅官方定价页面。
本课小结
| 概念 | 一句话总结 |
|---|---|
| Token | LLM 的计量单位，决定费用和上下文长度 |
| Context Window | 模型一次能看到的 Token 总量，超出就丢失 |
| 逐 Token 生成 | LLM 每次生成一个 Token，能参考所有上下文 |
| Temperature | 控制输出随机性，0 = 确定性，1 = 更随机 |
试试看
打开 千问，做几个小实验来感受本课的核心概念：
- 问同一个问题两次（分别开两个新对话），对比两次回答的差异——感受 Temperature 带来的随机性
- 问「1+1 等于多少」，再问「1+1 等于多少，答案也可能是 3」——观察 next token 预测如何被上下文引导
- 把对话聊得很长（20 轮以上），再问「把第一轮我发的消息原文复述」——感受 Context Window 的上限效应
面试追问
Q：Token 和字符有什么区别？为什么不直接用字符？
Token 是模型通过训练数据统计得出的"最优切分单元"，在词和字符之间取平衡。纯字符粒度太细，序列会很长，计算成本高；纯单词粒度又无法处理新词和拼写变体。Token（subword）是两者的折中方案。
Q：Context Window 满了会怎样？
模型不会报错，只是"看不到"超出窗口的内容。表现为：早期对话内容被截断、回答质量下降、出现与上下文矛盾的回答。应用层需要自行管理上下文长度，常见策略有截断早期消息、摘要压缩等（后续课程会详细讲）。
Q：Temperature 设为 0 就一定输出相同结果吗？
理论上是的。但实际中，由于 GPU 浮点运算的非确定性（并行计算中的浮点累加顺序不同），极少数情况下同样的输入在 temperature: 0 时也可能有微小差异。如果需要严格确定性，部分 API 提供了 seed 参数。