第 6 课：从 Transformer 到 LLM 全景图

前五课我们把 Transformer 拆到了零件级：注意力、位置编码、归一化、Tokenization、逐层参数。现在把镜头拉远——从"一个 7B 模型"扩展到"整个 LLM 家族"，看清参数量级、训练三阶段、推理两阶段、开源与闭源的分岔，以及模型能力的硬边界。

🎯 学完这 6 步你将能够：
① 说清 7B / 70B / 405B / 671B(MoE，即把前馈网络拆成很多个专家、每个 token 只激活其中少数几个) 的参数量与激活参数差别，并估算显存门槛
② 画出 LLM 从随机权重到"能对话"的三阶段训练流程，标出每阶段的数据量与算力占比
③ 解释为什么首字要等、后续越吐越快，并判断一个模型"标称上下文"与"有效上下文"的差距
🗺 本节推理链（6 步：从"参数量级"到"能力边界与学习地图"；其中第 4 步为选型支链）
1要判断一个模型能不能跑在自己的机器上，必须先分清"总参数"与"每 token 激活参数"——dense 模型两者相等，MoE 模型可以差约 18 倍（671B ÷ 37B），因此显存看总参数、算力看激活参数。
↓
2知道了规模，下一个问题是这些权重怎么来的——这就要求把训练拆成 预训练（学语言与世界知识）、后训练（SFT，即监督微调，教会模型听指令；DPO，即直接偏好优化，让模型对齐偏好）、长上下文扩展（把 token 窗口从 8K 撑到 128K）三段，于是才能解释"同一个基座为什么能变成不同助手"。
↓
3模型训好了要跑起来，而推理不是一次前向——因此必须区分 prefill（一次并行处理整段提示，计算受限，决定首字延迟）与 decode（一次一个 token，带宽受限，决定吐字速度），否则会误以为"加显卡就能让首字更快"。
↓
4【支链 · 选型维度】前三步都在讲"模型本身"，但工程落地还要回答一个正交问题：这套推理成本由谁承担——于是出现 开源权重与 闭源 API 两条路：前者数据不出域、边际成本低但要自己运维，后者开箱即用但按 token 付费、数据要出域。这就要求按成本、延迟、合规三个维度做选型，而不是比"谁分数高"。
↓
5选完模型还要知道它会在哪里翻车——因为 幻觉、长上下文失稳、多步推理衰减、无法自校验都是结构性限制而非待修的 bug，因此必须用检索（把外部真值片段作为 token 注入上下文）、工具调用、验证层去补，而不是靠"换个更好的提示词"。
↓
6把上面五步的结论收成一张地图：于是第一部分（认知衔接）到此闭环，接下来第二部分学 预训练（在万亿级 token 上做 next-token prediction）与对齐、第三部分学推理部署、第四部分学 Agent 工程——每一步都建立在本课这张全景图上。
ScalingMoEPre-trainingPost-trainingPrefill/DecodeOpen vs Closed
1
同样是 Transformer，为什么参数量能从 1 亿跨到 2.78 万亿？
提示：先分清两个数——"总参数"和"每个 token 真正参与计算的参数"。想清楚这两个数在 dense 模型和 MoE 模型里是不是同一个数，答案就出来了。
▾
知识背景
参数量级是 LLM 的第一张名片：Llama 3.1 提供 8B / 70B / 405B 三档 dense 模型（Meta, 2024）；DeepSeek-R1 是 671B 总参数、每 token 激活 37B 的 MoE 模型；2026 年的旗舰已进入万亿级——Kimi K3 为 2.78T 总参数、每 token 激活约 104B（约 3.7%）。MoE（Mixture-of-Experts，混合专家）把 FFN 拆成很多个"专家"，每个 token 只路由到其中少数几个，于是"总参数"与"激活参数"解耦。

上一课我们逐层解剖了一个 7B 模型，把 6.74B 参数拆到了每一层。现在把镜头拉远：同样是 Transformer，为什么有的模型只有 1 亿参数，有的能到 2.78 万亿？因为决定"大小"的从来不是一个数——因此必须先分清两个口径，否则连"这个模型能不能跑在我的机器上"都答不出来。

关键在一个反直觉的事实：模型的"大小"有两个口径。可以把 MoE 模型类比成一家有 896 位专科医生的大医院——挂号时只叫其中 16 位进诊室，但医院里所有医生的编制都得占地方。这就是"总参数"（编制）与"激活参数"（进诊室的人）的区别。

为什么要费劲做这种稀疏结构？因为稠密模型每 token 都要把全部参数算一遍：同样 671B 参数的稠密模型，单 token 前向约 2 × 671e9 = 1.34 TFLOPs，而 MoE 只激活 37B（约 74 GFLOPs）——差约 18 倍。MoE 正是用「多存参数、少算参数」把大模型的推理算力压下来。

🧮 参数量级账：总参数 vs 每 token 激活参数
Step 1：四代模型的规模对照
模型架构总参数每 token 激活激活占比
Llama 2 7BDense6.74B6.74B100%
Llama 3.1 70BDense70B70B100%
Llama 3.1 405BDense405B405B100%
DeepSeek-R1MoE671B37B5.5%
Kimi K3MoE2.78T≈104B3.7%
dense 模型两个口径相等；MoE 模型每 token 只激活 3.7%~5.5% 的参数。激活占比 = 激活参数 ÷ 总参数。
Step 2：为什么 MoE 能"用 3.7% 的参数干活"
层Dense 模型MoE 模型（以 Kimi K3 为例）
Attention每层一份，全部参与每层一份，全部参与（不稀疏）
FFN每层 1 个，全部参与每层 896 个专家，路由选 16 个
每 token 计算量正比于总参数正比于激活参数（≈ 总参数的 3.7%）
MoE 只稀疏化 FFN（占参数大头），Attention 与归一化仍是稠密的——这就是为什么"激活参数"不会低到 1% 以下。
Step 3：显存门槛——总参数决定能不能装下
模型fp16 权重4-bit 量化权重消费级显卡能否单卡跑
7B≈14 GB≈4.0 GB能（8GB 显存起）
70B≈140 GB≈43 GB不能（需 2×24GB 或 A6000）
671B (MoE)≈1.3 TB≈404 GB不能（服务器级，约 8×H100-80GB）
权重显存 ≈ 参数量 × 每参数字节数（fp16 = 2 字节；4-bit 按 Q4_K_M 实测口径 ≈ 0.6 字节，含量化元数据开销，故高于理论值 0.5——如 7B 的 6.74B 参数 × 0.6 ≈ 4.0 GB，实测值见 TheBloke 的 GGUF 量化表）。注意：显存看总参数，算力看激活参数——MoE 省的是算力，不是显存。
🎯 关键认知

MoE 把"总参数"与"激活参数"解耦：总参数决定显存门槛，激活参数决定每 token 的算力成本。所以 671B 的 MoE 模型推理算力可能接近一个 37B dense 模型，但显存需求仍是 671B 级别——这就是为什么"MoE 让大模型变便宜了"这句话只对了一半。

AI 助教
👋 对参数量级有疑问？比如"MoE 的路由是怎么选的？""为什么 Attention 不做稀疏？"

我会用具体数字帮你算。
2
为什么一个只会"预测下一个词"的基座，必须再训一遍才能听懂指令？
提示：先想"会预测下一个词"和"会听指令"是不是同一件事。如果不是，那中间必然有一步把前者变成后者——那一步用什么数据、花多少算力？
▾
知识背景
Llama 3 的训练分两大阶段（Meta, 2024）：① 预训练——在约 15.6T 多语言 token 上做下一个词预测，旗舰模型用了 3.8×10²⁵ FLOPs、最多 16K 张 H100；② 后训练——用 SFT（监督微调）+ RS（拒绝采样）+ DPO（直接偏好优化）把基座变成助手，而不是用更复杂的 RLHF（靠人给模型的回答打分、再用强化学习调整模型）。此外还有一次长上下文继续预训练，把窗口从 8K 扩到 128K。

上一张卡片我们看清了模型的规模。但规模只是"容量"，一个刚预训练完的模型只会做一件事：预测下一个词。它不会听指令、不会拒绝有害请求、也不会按格式输出——因为它的训练目标里根本没有"回答用户"这一项，所以必须再训一遍。

把这三段训练类比成培养一名医生：预训练是读完整个医学院（海量知识），后训练是规培（学会按规范问诊、写病历），长上下文扩展是进修（能一次看完一整套病历）。

这一步的必要性有一个经典反例：OpenAI 的 InstructGPT 工作中，13 亿参数的 1.3B 模型经后训练后，其回答被人类标注员偏好的比例超过了 1750 亿参数的 GPT-3 基座——参数量差 100 倍以上，赢的却是「听得懂指令」这一项（Ouyang et al., 2022, arXiv:2203.02155）。

🧮 三阶段训练账：数据量、算力与产出
Step 1：三阶段对照表
阶段目标数据量算力占比（量级）产出
① 预训练学语言结构与世界知识≈15.6T token≈99%基座模型（Base）
② 后训练学会听指令、对齐偏好百万级指令样本<1%对话模型（Instruct）
③ 长上下文扩展把窗口从 8K 撑到 128K长文档语料<1%长上下文模型
算力占比是量级估计：预训练用 3.8×10²⁵ FLOPs，后训练与长上下文扩展各只占其中很小一部分——但正是这不到 1% 决定了模型"好不好用"。
Step 2：预训练的算力账——3.8×10²⁵ FLOPs 是什么概念
项目数值说明
训练 FLOPs3.8 × 10²⁵约为 Llama 2 最大版本的 50 倍
训练 token15.6T约为 Llama 2（2T token，Meta 官方口径）的 7.8 倍（Llama 3 论文曾按 1.8T 自述）
GPU 规模最多 16K 张 H100单集群，约两个月完成
经验公式C ≈ 6 × N × DN=参数量，D=token 数；系数 6 = 前向 2 + 反向 4
用经验公式粗算：6 × 405B × 15.6T ≈ 3.8×10²⁵ FLOPs，与官方公布值吻合——这说明"训练算力 ≈ 6 × 参数量 × token 数"是可以自己推的。
Step 3：后训练为什么"便宜但关键"
方法需要什么数据解决什么
SFT（监督微调）指令-回答对让模型学会"按指令回答"的格式与风格
RS（拒绝采样）模型自采样 + 筛选用"答得好的样本"再训一轮，提升质量
DPO（直接偏好优化）偏好对（好答案 / 差答案）不用单独训 Reward Model，直接优化偏好
Llama 3 选择 SFT + RS + DPO 而非 PPO 类 RLHF，理由是训练更稳定、更易复现——这是工程取舍，不是能力取舍。
🎯 关键认知

预训练决定模型的能力上限（知道多少、能推多深），后训练决定模型的可用性（听不听话、格式对不对、安全不安全）。同一个基座 + 不同后训练 = 完全不同的产品——这就是为什么开源社区能基于同一个 Llama 基座做出几百个风格迥异的助手。

AI 助教
👋 对训练三阶段有疑问？比如"为什么后训练只用不到 1% 的算力？""DPO 和 PPO 到底差在哪？"

我会用具体数字帮你算。
3
为什么同一个模型，首字要等两秒、后面却越吐越快？
提示：先想"处理 1000 个输入 token"和"生成 1 个输出 token"这两件事，哪个是算得多、哪个是搬数据多。瓶颈不同，优化手段就完全不同。
▾
知识背景
推理被拆成两个阶段（NVIDIA, 2026）：Prefill 一次并行处理整段提示、填充 KV Cache（把已算过的键和值存下来复用），是计算受限（compute-bound），决定首字延迟 TTFT；Decode 一次只生成一个 token，每步都要把全部权重和不断增长的 KV Cache 从显存读一遍，是带宽受限（memory-bound），决定每 token 延迟 TPOT。判据是算术强度（Arithmetic Intensity = FLOPs ÷ 访问字节数）与硬件的 ridge point 之比。

上一张卡片讲完训练，现在模型要上线服务了。用户按下回车后，会经历两段体感完全不同的等待：首字延迟（等第一个字出来）和吐字速度（后面每个字多快）。因为这两段落在 GPU 性能曲线的两侧，所以优化手段完全相反——先判断瓶颈在哪一侧，再决定加什么。

这两段类比成餐厅出餐：prefill 是"一次性把整桌菜备齐"（后厨火力全开，比的是灶台功率），decode 是"一道一道端上桌"（比的是传菜通道有多宽，灶台反而闲着）。

🧮 两阶段账：算术强度与瓶颈判定
Step 1：两个阶段在做什么
阶段一次处理多少 token瓶颈决定什么指标
Prefill整段提示（如 2048 个）计算（Tensor Core 打满）TTFT（首字延迟）
Decode1 个（每步）显存带宽（HBM 打满）TPOT（每 token 延迟）
两阶段用的是同一套权重，但落在 GPU roofline 的两侧——这就是"同一个模型两种瓶颈"的根源。
Step 2：算术强度——用数字判定瓶颈
阶段算术强度（FLOP/byte）与 ridge point（≈295，以 H100 SXM 为例：989 TFLOPS ÷ 3.35 TB/s ≈ 295）比较结论
Prefill≈ 提示长度 S（如 S=2048 → ≈2048）远高于 ridge计算受限
Decode≈ 批大小 B（B=1 → ≈1）远低于 ridge带宽受限
算术强度 = 总 FLOPs ÷ 总访问字节数。高于 ridge point 说明"算得比搬得快"，瓶颈在算力；低于则说明"搬得比算得慢"，瓶颈在带宽。prefill 一次处理 S 个 token，每读一次权重能算 S 次，故强度 ≈ S；decode 每步只出 B 个 token，故强度 ≈ B。两者在长提示下可差 3 个数量级。
Step 3：为什么"加显卡"救不了首字延迟
TTFT 的组成部分占比量级（二手/估算，随场景浮动、非同一时刻相加）加显卡能改善吗
排队等待常为首要项否（要靠调度与扩容策略）
KV Cache 传输（PD 分离时）PD 分离时可居首否（受互联带宽限制）
Prefill 计算本身约 2%~23%（二手，需人工核实）是（但只影响这一小块）
这是最反直觉的一条：首字延迟的大头往往不是算得慢，而是排队和搬 KV Cache。所以优化 TTFT 的第一手段是调度与架构（如 PD 分离、前缀缓存），而不是换更快的卡。
🎯 关键认知

推理优化的第一步永远是先判断瓶颈在哪一侧：decode 阶段 Tensor Core 利用率常常只有个位数百分比，显存带宽却已打满——此时加算力毫无用处，该做的是减少每步要搬的字节数（KV Cache 量化、GQA（把多个 Query 头分成几组、每组共享同一份 K/V）/MLA（把 K/V 压缩成一个更小的向量、用时再还原）、投机解码提高算术强度）。

AI 助教
👋 对推理两阶段有疑问？比如"批大小为什么能提高 decode 效率？""投机解码是怎么提高算术强度的？"

我会用具体数字帮你算。
4
开源权重和闭源 API，到底差在哪、该怎么选？
提示：别只比"谁分数高"。先列出三个约束——数据能不能出域、长期调用成本、团队有没有 GPU 运维能力。三个约束一摆，答案往往就唯一了。
▾
知识背景
两条路线各有代表：闭源 API（GPT / Claude / Gemini 系列）只提供接口，厂商负责权重迭代与集群运维，按 token 计费；开源权重（Llama / Qwen / DeepSeek 系列）可下载权重部署在内网，数据不出域、可自主微调，但需要自己承担 GPU 与运维。2026 年的现实是：开源旗舰在多数任务上已接近闭源旗舰，差距主要体现在最难的那一档推理与多模态上。

上一张卡片我们看到自托管有显存与带宽门槛。于是选型问题就来了：到底该调 API，还是自己部署？

这不是"技术先进 vs 落后"的问题，而是约束匹配问题——类比成出行：API 像打车（随叫随到、按里程付费、车不是你的），自托管像买车（前期投入大、但跑得越多越划算、且完全由你掌控）。

🧮 选型账：成本、延迟、合规三维对照
Step 1：三维对照表
维度闭源 API开源权重自托管
数据合规数据需出域到厂商数据不出内网
成本结构按 token 计费，随调用量线性增长前期 GPU 投入 + 运维人力，边际成本低
能力上限通常是最强档（尤其复杂推理、多模态）接近但一般略低，可自主微调补齐垂直场景
迭代速度厂商升级，你自动受益自己决定何时升级、升到哪版
运维门槛几乎为零需要 GPU 运维、推理优化、监控能力
Step 2：自托管的显存门槛（决定"能不能跑"）
模型规模4-bit 权重最低可用硬件典型场景
7B~8B≈4.0~4.8 GB单张 8GB 消费卡个人实验、轻量客服
32B≈20 GB单张 24GB（3090/4090）垂直领域微调、私有知识库
70B≈43 GB2×24GB 或 A6000企业级私有部署
671B (MoE)≈404 GB约 8×H100-80GB前沿能力私有化
注意：这只是权重占用，实际还要加上 KV Cache 与运行时开销，通常再留 20%~40% 余量。
Step 3：决策规则（按约束排序，而不是按分数）
你的约束优先选择理由
数据不能出域 / 强合规开源自托管API 路线直接不满足硬约束
调用量小、要快速验证闭源 API零运维、零前期投入
长期高并发、成本敏感开源自托管边际成本低，规模越大越划算
需要最强复杂推理 / 多模态闭源 API能力上限通常更高
需要深度定制（垂直微调）开源自托管能拿到权重才能改
🎯 关键认知

选型的第一原则是先看硬约束，再看性价比：如果数据不能出域，那么"闭源 API 分数更高"这个论据根本不成立。反过来，如果只是做个原型验证，自建集群的运维成本会远超 API 账单。没有绝对更优的路线，只有约束匹配与否。

AI 助教
👋 对选型有疑问？比如"混合方案怎么做？""自托管的真实成本怎么算？"

我会用具体数字帮你算。
5
模型"看起来很懂"，为什么还会一本正经地胡说？
提示：先想模型在做什么——它是在"查事实"还是在"预测下一个最像的词"。如果它没有查证能力，那"不知道"的时候它会怎么办？
▾
知识背景
幻觉不是待修的 bug，而是训练目标的结构性后果：模型被训练成"预测下一个最可能的词"，而评测又奖励"猜"而不是"承认不知道"（Kalai et al., 2025）。关于"不知道时会不会编造"，目前只有 2026 年的第三方二手数据，且各来源口径不一致（需人工核实）：Artificial Analysis 的 AA-Omniscience 基准被聚合来源引作"Gemini 3 Pro 幻觉率约 88%、准确率约 55.9%，Gemini 3 Flash 约 91%"；另有开发者论坛贴记为"Gemini 2.5 Pro 约 88%、Gemini 3 Pro 准确率约 53%"。同一指标被挂到不同代际模型上、准确率也对不上，说明这些数字尚不可靠，只能当趋势看。此外还有多步推理衰减、无法自校验、无法区分"指令"与"被读的数据"等结构性限制。

上一张卡片我们选好了模型。但上线前必须知道它会在哪里翻车——否则第一次事故就会教你。

把模型类比成一位口才极好但从不查资料的专家：他讲得头头是道，但被问到不熟的领域时，他不会说"我不确定"，而是顺着话头编一个听起来最合理的答案——因为他的训练目标就是"说出最像正确答案的话"。

要压住这类编造，工程上常见的做法是 RAG（先去外部知识库检索相关材料、再让模型照着检索结果回答）与工具调用。

🧮 边界账：八条结构性限制与对应数字
Step 1：八条硬限制一览
#限制根因工程对策
1知识截止训练数据有时间边界检索（RAG）注入最新信息
2幻觉目标是"生成最像的文本"，非"查证事实"强制引用来源 + 输出校验
3多步推理衰减误差逐步累积思维链 + 外部工具（代码执行）
4上下文窗口上限注意力成本随长度增长分块 + 摘要 + 检索
5无持久记忆推理是无状态的应用层存状态并注入
6无法作用于现实模型只能输出文本工具调用 / 函数调用
7训练数据偏见语料本身有偏领域上下文 + 人工审核
8无法自校验没有真值访问权独立验证层 / 第二模型复核
Step 2：幻觉的量化——"不知道"时会怎样
来源口径（二手，需人工核实）模型幻觉率准确率
Artificial Analysis 聚合Gemini 3 Pro≈88%≈55.9%
Artificial Analysis 聚合Gemini 3 Flash≈91%—
开发者论坛贴Gemini 2.5 Pro≈88%—
开发者论坛贴Gemini 3 Pro—≈53%
同一基准的"不知道时幻觉率"被两份二手来源挂到了不同代际模型上（88% 既被记为 2.5 Pro、也被记为 3 Pro），准确率也有 53% / 55.9% 两个口径——尚无一手来源、口径不一致，需人工核实。能确定的只是定性趋势：模型"知道很多"（准确率领先）与"不知道时几乎不承认"（幻觉率 88%~91%）并存，所以"分数高"不等于"可信"。不同代际模型不能直接横向比较。
Step 3：长上下文的"标称 vs 有效"
口径数值说明
标称上下文1,000,000 token厂商宣传的窗口上限
换算成字符≈300 万~400 万字符按 1 token ≈ 3~4 字符（英文）换算
实测失稳点≈30,000 字符开发者实测开始失去连贯性（仅见论坛贴，二手，需人工核实）
差距约 100 倍（2 个数量级）"能装下"不等于"能用好"
结论：不要把标称窗口当作可用窗口。工程上应按实测有效范围设计分块与检索策略，而不是把 100 万 token 全塞进去。（注：失稳点以字符计、标称以 token 计，此处已统一换算到字符口径再比较。）
🎯 关键认知

这八条限制没有一条能靠"换个更好的提示词"解决——它们是架构与训练目标带来的结构性后果。正确的做法是在系统层补：检索代替记忆、执行代替估算、验证代替信任、外部状态代替上下文内状态。这正是第四部分「Agent 工程」要解决的问题。

AI 助教
👋 对模型边界有疑问？比如"怎么降低幻觉率？""为什么长上下文会失稳？"

我会用具体数字帮你算。
6
有哪些事，是这一代大模型真的做不到（而不是没给它条件）？——能不能列出一张清单？
提示：先分清「没给它条件」和「它天生做不到」。从最底层想起——它在什么单位上思考、一次能真正用上多长的上下文、知识从哪来、能不能动手。每个方向逼出一条。
▾
知识背景
这些边界不是猜测，都有论文与实测支撑：字符级计数的失败被归因于 tokenizer（把文本切成 token 的组件，模型看不到字符本身）——「strawberry 里有几个 r」自 2024 年起被广泛讨论（Karpathy, 2024；arXiv:2410.14166）；中间遗忘由 Stanford 提出的 Lost in the Middle（即「迷失在中间」，Liu et al., 2023, arXiv:2307.03172）用 U 形曲线量化；知识截止来自训练数据被冻结，多步衰减来自误差的乘性累积，无法动手则来自模型只能输出文本这一事实。

上一张卡片我们看到模型会一本正经地胡说（幻觉）。但幻觉只是「看起来懂却不可信」的一种表现；把镜头再拉远一层，还有一批事是这一代大模型在原理上就做不到的——不是提示词没写好，也不是没喂数据，而是它的输入/输出形式、注意力机制、训练数据边界共同决定的。

打个比方：模型只认 token、没学过字符，也没长出手脚——读得再流利，也数不清一句话里有几个字母，更没法替你按下发送键。下面把这类事列成一张清单，并逐条标出「后面哪一课解决它」，它同时就是这一部分的学习地图。

🧮 边界账：五条「真的做不到」与它们的去处
Step 1：五条硬边界清单
#做不到的事现象（可复现）根因去向（哪一课解决）
1字符级计数与精确算术让模型数 strawberry 里有几个 r，会常常出错模型看到的是 token，不是字符《工具调用》——把计数与算术外包给代码执行
2长上下文的「中间遗忘」关键信息放中段，回答质量明显下降注意力对首尾有偏好（U 形曲线）《记忆与 RAG 工程化》
3知识停在训练截止日不知道训练之后的事，也不知道你的私域文档知识冻结在权重里，更新要重训《记忆与 RAG 工程化》
4多步推理累积误差单步 95% 对，十步之后常常做不完误差乘性累积，且不会自我纠正《推理模型与 RLVR（用可验证奖励做强化学习）》《从 Prompt 到 Agent》
5不能自己动手不会真的发邮件、查数据库、下单模型只输出文本，动作靠外部执行《工具调用》
注意第 1 条与第 4 条的区别：第 1 条是「单位不对」——看不到字符；第 4 条是「步数太多」——误差累积。两条的缓解办法是同一个：把计算与执行交给外部代码，而不是让模型心算。
Step 2：多步推理的复利衰减
步数单步 95% 正确单步 99% 正确算式
1 步0.9500.990——
5 步≈0.774≈0.9510.95⁵
10 步≈0.599≈0.9040.95¹⁰
20 步≈0.359≈0.8180.95²⁰
综合正确率 ≈ 单步正确率步数。代入 0.95¹⁰ ≈ 0.599，即十步全对的概率不到六成——这就是「每一步都差不多对，整条链却常常错」的数学原因。让模型自己检查也救不了：检查本身也是一步，也会出错。
Step 3：长上下文的 U 形曲线（中间最弱）
关键信息放的位置模型用得怎么样原因
开头（首因）好最先被注意到
中间最差被大量内容稀释，容易被跳过
结尾（近因）好离生成位置最近
Stanford 团队在 Lost in the Middle（即「迷失在中间」，Liu et al., 2023, arXiv:2307.03172）里做了受控实验：把答案所在的文档从开头挪到中间，准确率随之变化，画出一条两头高、中间低的 U 形曲线——开头与结尾附近最高，中间显著下降。原文图 1 给出的具体百分点随模型与文档数而变，此处只作定性描述，精确数值需核对原论文（人工核实）。
🎯 关键认知

这五条的共同点是：没有一条能靠「换个更好的提示词」解决。字符级问题要把计算外包给代码执行，知识截止要靠检索、记忆要靠外部存储，多步误差要靠推理模型与外部校验，动手能力要靠工具调用。所以这张卡既是「能力边界清单」，也是这一部分的学习地图——每条边界的正下方，都压着后面某一课。

AI 助教
👋 对模型的能力边界有疑问？比如「为什么数不清 strawberry 里的 r？」「中间遗忘能不能靠提示词缓解？」

我会用具体数字帮你算。

第 6 课完成 · 下一课：第 7 课「Scaling Laws 与算力预算」

进入第 7 课：Scaling Laws 与算力预算 →　·　← 上一课：逐层解剖一个模型