Transformer与大模型原理
核对日期:2026-05-13。
不稳定项:模型 API 参数、上下文窗口长度、推理服务能力、开源模型版本、对齐训练最佳实践会持续变化;学习时以官方模型文档和具体服务商 API 为准。
1. 阶段目标
本阶段目标不是把 Transformer 论文每个公式都推一遍,而是建立工程人员使用 LLM 时必须具备的机制理解:模型为什么能生成文本,为什么会出错,哪些问题可以靠 Prompt、RAG、评测和系统设计缓解,哪些问题不能指望模型自己解决。
学完本阶段,你应该能做到:
- 用自己的话解释 tokenization、embedding、self-attention、Transformer block 和 decoder-only LLM。
- 理解 LLM 的基本训练路径:预训练、指令微调、偏好对齐和安全调优。
- 能解释 temperature、top_p、max output tokens、stop、seed、reasoning effort 等推理参数的工程影响。
- 知道上下文窗口、KV cache、长上下文衰减和“上下文不是长期记忆”的边界。
- 能把幻觉拆成知识缺失、检索缺失、指令不清、采样不稳定、任务不可验证等不同原因。
- 能基于任务、成本、延迟、稳定性和安全要求选择模型,而不是只看榜单。
本阶段的核心产出是:
- 一份《LLM 机制与边界说明书》。
- 一个推理参数对比实验。
- 一个长上下文失败样例分析。
- 一个模型选型决策表。
2. 学习前置条件
建议已完成:
04-深度学习基础,理解 tensor、embedding、loss、训练循环和 attention 直觉。- 基础线性代数,知道矩阵乘法和向量相似度。
- 有至少一次调用模型 API 或本地 LLM 的经验。
不要求:
- 手写完整 Transformer 训练框架。
- 掌握分布式训练、MoE、FlashAttention、量化推理等底层优化细节。
- 能复现 RLHF 或大规模预训练。
3. 核心知识地图
4. 详细讲义
4.1 Transformer 解决了什么问题
Transformer 之前,序列建模常用 RNN、LSTM、GRU 等结构。它们按时间步处理序列,适合表达顺序,但并行效率差,长距离依赖难学。
Transformer 的关键变化是:让序列中每个位置通过 attention 直接读取其他位置的信息。这样做带来三个工程结果:
- 训练更容易并行,能吃下更大数据和更大模型。
- 长距离依赖更容易表达,但计算和显存成本随上下文长度增长。
- 模型不再只是“按顺序读”,而是在每一层动态重组上下文信息。
一句话理解:Transformer 是一种用 attention 做上下文信息路由的深层神经网络。
4.2 Tokenization:模型看到的不是字,而是 token
LLM 处理文本前会先把文本切成 token。token 可能是一个英文单词、一部分单词、一个汉字、一个标点、一个空格组合,也可能是代码中的符号片段。
Tokenization 直接影响:
| 影响项 | 说明 |
|---|---|
| 成本 | API 通常按输入 token 和输出 token 计费 |
| 延迟 | token 越多,推理时间越长 |
| 截断 | 超过上下文窗口会丢信息 |
| 多语言效果 | 不同语言的 token 密度不同 |
| 结构化输出 | JSON、代码、表格会产生额外 token |
工程判断:任何严肃 AI 应用都应该记录 token 用量。只记录请求次数无法解释成本和延迟。
4.3 Embedding 和位置表示
token 本身只是 ID。模型会把 token ID 映射成向量,这就是 token embedding。
但仅有 token embedding 不够,因为句子中同一个词出现在不同位置含义可能不同。因此 Transformer 还需要位置表示,让模型知道 token 的相对或绝对位置。
常见位置表示包括:
- 原始 Transformer 的 sinusoidal positional encoding。
- learned positional embedding。
- RoPE 等相对位置方法。
工程上不需要纠结每种位置编码细节,但要理解:位置表示决定模型如何感知顺序和距离,也会影响长上下文扩展能力。
4.4 Self-Attention 的机制
Self-attention 可以理解为:每个 token 都提出一个查询,然后去上下文里找和自己相关的信息。
在标准注意力里,每个位置会生成三类向量:
- Query:我想找什么信息。
- Key:我能被什么查询匹配到。
- Value:如果匹配到我,我提供什么内容。
简化公式:
Attention(Q, K, V) = softmax(QK^T / sqrt(d_k))V
这不是“模型在思考”,而是一个可微分的信息加权机制。它让模型在每一层决定哪些上下文位置更相关。
4.5 Masked Self-Attention 和下一个 token 预测
现代文本生成 LLM 多数是 decoder-only 架构。训练时的核心任务是根据前文预测下一个 token。
为了避免模型偷看答案,训练和生成时会使用 causal mask:
位置 1 只能看位置 1
位置 2 能看位置 1-2
位置 3 能看位置 1-3
因此生成过程本质上是循环:
已有 token -> 模型输出下一个 token 概率 -> 选择一个 token -> 拼回上下文 -> 再预测
这也解释了为什么 LLM 输出是逐 token 生成的,为什么 streaming 能逐步返回内容。
4.6 Transformer Block 的组成
一个典型 Transformer block 包含:
- Attention:做上下文信息路由。
- MLP / Feed Forward:对每个位置做非线性变换。
- Residual connection:缓解深层网络训练困难。
- LayerNorm:稳定训练。
简化结构:
x -> LayerNorm -> Attention -> Residual Add
-> LayerNorm -> MLP -> Residual Add
模型能力来自很多 block 的堆叠。底层可能偏词法和局部模式,中间层学习结构和语义,高层更接近任务和输出策略。但不要把层解释得过度拟人化,具体表示仍需要实验验证。
4.7 预训练:能力的主要来源
预训练通常使用大规模文本、代码、多模态数据,通过“预测下一个 token”等目标学习世界知识、语言模式、代码模式和推理片段。
预训练带来的能力:
- 语言生成和理解。
- 常识和领域知识的参数化记忆。
- 代码、数学、工具说明等模式学习。
- 少样本泛化能力。
预训练也带来风险:
- 数据过时。
- 数据污染,评测集可能进入训练数据。
- 学到偏见、错误和不安全模式。
- 参数知识不可追溯,无法天然给出可靠引用。
工程判断:LLM 的“知道”不是数据库查询,而是参数中压缩出的概率模式。
4.8 指令微调和偏好对齐
Base model 会续写文本,但不一定按用户指令工作。为了让模型更像产品中的助手,通常会经过:
| 阶段 | 目标 | 工程含义 |
|---|---|---|
| SFT | 用指令-回答样本训练模型服从任务格式 | 提升可用性和任务遵循 |
| RLHF | 用人类偏好训练奖励模型,再优化模型输出 | 让输出更符合偏好 |
| DPO | 直接用偏好样本优化模型 | 流程更简单,常用于对齐 |
| Safety tuning | 降低危险、违法、隐私泄露输出 | 提升安全边界但不完美 |
对齐不是“让模型永远正确”。它主要改变输出倾向、拒答策略和交互风格。权限控制、数据隔离、审计和安全策略仍必须由系统实现。
4.9 推理参数:控制输出分布
模型每一步都会给出候选 token 的概率分布。解码参数决定如何从分布中选择下一个 token。
| 参数 | 作用 | 调大时的常见效果 | 调小时的常见效果 |
|---|---|---|---|
| temperature | 控制随机性 | 更发散、更多变化 | 更稳定、更保守 |
| top_p | 从累计概率集合采样 | 候选范围更大 | 候选范围更小 |
| max_output_tokens | 限制输出长度 | 能输出更完整 | 易被截断 |
| stop | 遇到指定片段停止 | 控制格式边界 | 配错会提前停止 |
| seed | 尝试提升可复现性 | 便于对比实验 | 不保证跨模型/版本稳定 |
| reasoning effort | 控制推理预算 | 更慢、更贵、可能更强 | 更快、更便宜 |
经验规则:
- 抽取、分类、格式化:低 temperature。
- 头脑风暴、创意写作:适度提高 temperature。
- 代码、财务、法律、医疗等高风险任务:低随机性,加校验和评测。
- 不要同时随意调 temperature 和 top_p,先固定一个变量做实验。
4.10 上下文窗口、KV cache 和长上下文边界
上下文窗口是单次请求中模型可读取的 token 范围。它不是长期记忆,也不是保证全量信息都被同等使用。
长上下文常见问题:
- 重要信息被淹没。
- 中间位置内容更容易被忽略。
- 重复、冲突、低质量上下文会污染输出。
- 输入 token 成本和首 token 延迟上升。
- 超长上下文仍需要检索、摘要、排序和引用策略。
KV cache 是推理优化:生成时缓存历史 token 的 key/value,避免每一步重复计算全部历史。它降低生成成本,但不改变模型是否“理解”上下文。
工程判断:长上下文是能力,不是架构设计的免死金牌。真实系统仍需要上下文工程。
4.11 幻觉机制:不要只归因于“模型不聪明”
幻觉是指模型生成看似合理但事实错误、无法证实或与证据不一致的内容。
常见来源:
| 来源 | 解释 | 缓解方式 |
|---|---|---|
| 参数知识缺失 | 模型没学过或知识过时 | RAG、工具查询、拒答 |
| 上下文缺失 | 请求没有给足证据 | 补上下文、追问 |
| 检索失败 | RAG 没召回正确证据 | 改 chunk、hybrid search、rerank |
| 指令不清 | 任务目标或输出标准模糊 | Prompt 模板和验收标准 |
| 采样随机 | 高 temperature 下更发散 | 降低随机性 |
| 任务不可验证 | 让模型编事实或猜数据 | 强制引用、工具验证 |
高质量 AI 系统不承诺“消除幻觉”,而是让错误更可检测、可追溯、可回滚。
4.12 模型选型:从任务约束出发
模型选型至少看 7 个维度:
| 维度 | 问题 |
|---|---|
| 能力 | 是否完成任务,错误类型能否接受 |
| 成本 | 输入、输出、缓存、工具调用总成本是多少 |
| 延迟 | 首 token、完整响应、长任务耗时是否可接受 |
| 上下文 | 是否需要长上下文、图像、音频或工具调用 |
| 稳定性 | 格式、拒答、边界条件是否稳定 |
| 数据合规 | 数据是否能发给该服务或部署方式 |
| 可观测性 | 是否能记录 token、trace、错误和反馈 |
不要用“最强模型”替代选型。很多任务适合小模型、分类器、规则、检索或传统 ML。
5. 关键概念表
| 概念 | 含义 | 工程意义 | 常见误解 |
|---|---|---|---|
| Token | 模型处理文本的基本单位 | 决定成本、延迟、截断 | 以为 token 等于字或词 |
| Embedding | token 的向量表示 | 承载可学习语义 | 以为 embedding 天然可解释 |
| Self-Attention | 上下文信息加权机制 | 让 token 读取相关位置 | 以为等于人类注意力 |
| Causal Mask | 防止生成模型看未来 token | 支撑下一个 token 预测 | 以为训练时能看到完整答案 |
| Transformer Block | Attention、MLP、Norm、Residual 组合 | 大模型基础结构 | 只记结构不懂数据流 |
| Pretraining | 大规模自监督训练 | 通用能力来源 | 以为等于事实数据库 |
| SFT | 指令样本微调 | 让模型听懂任务 | 以为能补全部知识 |
| RLHF / DPO | 偏好对齐方法 | 改变输出倾向 | 以为能保证安全正确 |
| Context Window | 单次可读 token 范围 | 影响上下文设计 | 以为越长越好 |
| KV Cache | 推理缓存机制 | 降低生成计算成本 | 以为是长期记忆 |
| Hallucination | 无证据或错误生成 | 需要评测和治理 | 以为靠一句 prompt 可解决 |
6. 工程案例
6.1 Token 成本账本
目标:解释为什么一个“看起来很短”的功能成本突然上涨。
做法:
- 记录
input_tokens、output_tokens、cached_tokens、模型名和请求类型。 - 按用户、功能、租户和日期聚合。
- 找出高成本请求:长上下文、重复系统提示、无意义历史消息、过长输出。
结论:AI 成本优化经常不是换便宜模型,而是减少无效 token。
6.2 长上下文遗漏实验
目标:验证“把全文塞进去”是否可靠。
实验:
- 构造一篇 20,000 token 的长文档。
- 在开头、中间、结尾分别放置关键事实。
- 提问要求模型只根据文档回答。
- 记录不同位置的命中率、引用质量和错误类型。
常见发现:模型可能能读长上下文,但关键事实位置、上下文噪声和问题措辞会显著影响结果。
6.3 推理参数对比
同一个任务分别设置:
temperature = 0temperature = 0.7temperature = 1.2
观察:
- 输出稳定性。
- 事实错误率。
- 格式违规率。
- 创意多样性。
结论:参数不是“风格旋钮”这么简单,它会改变可重复性和错误分布。
6.4 LLM 分类任务选型
场景:判断一条用户反馈属于“投诉、建议、咨询、无效输入”。
可选方案:
| 方案 | 优点 | 缺点 | 适用 |
|---|---|---|---|
| 规则 | 便宜、可解释 | 覆盖差 | 明确关键词 |
| 传统 ML | 快、成本低 | 需要标注数据 | 类别稳定 |
| 小 LLM | 泛化较好 | 仍有成本 | 中低风险文本分类 |
| 强 LLM | 表现更强 | 贵、慢 | 复杂语义和少样本 |
工程结论:不要把 LLM 当唯一方案。先做 baseline,再决定是否升级。
6.5 幻觉事故复盘
场景:模型为企业制度问答编造了一个不存在的报销上限。
复盘步骤:
- 是否有正确制度文档。
- 检索是否命中正确 chunk。
- Prompt 是否要求“无证据则拒答”。
- 输出引用是否真的支持结论。
- 评测集是否覆盖该问题。
结论:幻觉常是系统链路问题,不只是模型问题。
7. 常见误区与反模式
| 反模式 | 表现 | 后果 | 修正 |
|---|---|---|---|
| 把 LLM 当数据库 | 直接问事实,不给来源 | 编造、过时、不可追溯 | 接入检索和工具 |
| 只看模型榜单 | 选榜单第一名 | 成本高且未必适配业务 | 建业务 eval |
| 迷信长上下文 | 把所有历史都塞进去 | 成本高、遗漏、污染 | 排序、摘要、检索 |
| 参数随手调 | 每次出问题改 temperature | 无法复现 | 固定实验矩阵 |
| 对齐当权限 | 让模型“不要泄漏” | 越权和注入风险 | 系统层权限控制 |
| 无 token 观测 | 只记录请求成功失败 | 成本无法定位 | 建成本账本 |
| 忽略输出截断 | max tokens 太小 | JSON 破损、答案不完整 | 设置长度和校验 |
| 将模型拟人化 | 用“它理解了”解释结果 | 无法定位失败 | 回到数据、上下文、概率和评测 |
8. 阶段练习
8.1 Tokenization 练习
选择 5 段文本:
- 中文产品说明。
- 英文技术文档。
- TypeScript 代码。
- JSON 数据。
- Markdown 表格。
记录每段 token 数、字符数、token/字符比例,并解释哪类输入更消耗上下文。
8.2 Attention 讲解练习
用 300 字以内解释:
- Query、Key、Value 分别是什么。
- 为什么要除以
sqrt(d_k)。 - causal mask 解决什么问题。
- multi-head attention 为什么不是简单重复。
要求:不能只抄公式,必须结合“信息路由”说明。
8.3 推理参数实验
选 3 个任务:
- 结构化抽取。
- 创意标题生成。
- 政策问答。
分别测试不同 temperature / top_p / max tokens,记录:
- 格式通过率。
- 事实正确率。
- 输出多样性。
- 平均延迟。
8.4 长上下文失败样例
构造一个长文档问答任务,要求:
- 文档内包含冲突信息。
- 正确答案只出现在中间位置。
- 问题要求引用原文证据。
分析模型失败原因,并提出 Prompt、RAG、排序或拒答策略。
8.5 模型选型练习
为 3 个业务场景填写模型选型表:
- 客服草稿生成。
- 合同条款风险提示。
- 内容标签分类。
每个场景至少比较两个模型或两类方案,并写出成本、延迟、风险和评测标准。
9. 项目任务
9.1 项目要求
完成《LLM 机制与边界说明书》,面向一个准备接入 AI 能力的工程团队。
必须包含:
- Transformer 和 decoder-only LLM 的机制图。
- token 成本与上下文窗口说明。
- 预训练、SFT、偏好对齐的区别。
- 推理参数实验结果。
- 长上下文失败样例。
- 至少 5 类幻觉来源和缓解方案。
- 一个模型选型矩阵。
9.2 输出结构
# LLM 机制与边界说明书
## 1. 一句话结论
## 2. Transformer 如何生成文本
## 3. 模型能力来自哪里
## 4. 推理参数如何影响输出
## 5. 长上下文和记忆边界
## 6. 幻觉来源和缓解策略
## 7. 模型选型矩阵
## 8. 对应用工程的要求
9.3 评分标准
| 维度 | 分值 | 标准 |
|---|---|---|
| 机制理解 | 25 | 能准确解释 token、attention、decoder-only 生成 |
| 工程边界 | 20 | 能说明上下文、幻觉、对齐和权限边界 |
| 实验设计 | 20 | 有推理参数和长上下文对比实验 |
| 选型判断 | 20 | 能从成本、延迟、稳定性、合规做权衡 |
| 表达质量 | 15 | 文档可给团队直接阅读,图表清晰 |
10. 验收题
- Tokenization 为什么会影响成本、延迟和截断?
- Self-attention 中 Query、Key、Value 分别承担什么作用?
- decoder-only LLM 为什么需要 causal mask?
- 预训练、SFT、RLHF、DPO 的目标分别是什么?
- 为什么对齐不能替代权限控制和安全治理?
- temperature 和 top_p 分别如何影响输出?
- 为什么长上下文不等于长期记忆?
- KV cache 优化了什么,不能解决什么?
- LLM 幻觉至少有哪些来源?
- 模型选型时为什么不能只看排行榜?
11. 延伸阅读
论文与机制
- Attention Is All You Need: https://arxiv.org/abs/1706.03762
- The Illustrated Transformer: https://jalammar.github.io/illustrated-transformer/
- The Illustrated GPT-2: https://jalammar.github.io/illustrated-gpt2/
官方与工程文档
- Hugging Face Transformers 文档: https://huggingface.co/docs/transformers/index
- Hugging Face LLM Course: https://huggingface.co/learn/llm-course/chapter1/1
- OpenAI Text generation guide: https://platform.openai.com/docs/guides/text
- OpenAI Models docs: https://platform.openai.com/docs/models
建议阅读方式
- 第一次读只抓主线:token -> attention -> block -> next token。
- 第二次读再看训练与推理参数。
- 做应用前重点复习上下文、幻觉和模型选型边界。
12. 本阶段总结
Transformer 与 LLM 的关键不是“模型很智能”,而是大规模数据、可并行架构、下一个 token 预测、指令微调和偏好对齐共同形成了一套强大的概率生成系统。
你需要把它理解为一个能力很强但边界清晰的组件:它能生成、归纳、转换、推理和调用工具,但它不会天然拥有最新事实、权限意识、业务目标、长期记忆和自我验证能力。
下一阶段进入 Prompt 与上下文工程。你会学习如何把任务目标、上下文、约束、输出格式和验收标准组织成模型可执行、系统可验证的输入。