大模型学习笔记 00：从训练到应用，先画出大语言模型全景图

读这本书之前，我对“大模型”这个词的理解其实有点偏应用：Prompt、RAG、Agent、工具调用，哪个项目里用到哪个就去补哪个。翻到目录以后才发现，这本书讲的是另一条路线：从 Transformer 和 GPT 的底层结构开始，一路讲到数据、分布式训练、微调、强化学习，最后才落到应用和评估。

这个顺序让我重新看了一遍自己以前写过的 Agent 笔记。我们平时看到的是模型吐出来的答案，答案背后却是一整套生产和运行系统：结构决定信息怎么计算，数据决定模型见过什么，训练方法塑造它的习惯，推理服务决定一次回答要花多少资源，评估则决定我们有没有证据说“它变好了”。

先把这条链路看完整

数据准备 -> 预训练 -> 指令微调/偏好对齐 -> 推理服务 -> 应用 -> 评估与改进
    |           |                |                |         |         |
 质量/许可    能力底座          行为塑造          成本延迟   用户任务   证据闭环

这不是严格的单向流水线。应用中的失败可能暴露数据缺口；评估结果可能要求调整训练；推理成本也会反过来影响模型大小和部署策略。更像一个反复迭代的工程闭环。

我准备带着六个问题读

1. 输入数据是否可靠、合法、去重并保护隐私？
2. 模型学到的究竟是通用语言能力，还是某些训练样本的表面模式？
3. 微调数据和目标是否真的对应用户需要的行为？
4. 训练和推理的算力、显存、通信成本由什么决定？
5. 应用把错误答案放大成了什么实际风险？
6. 用什么评估证据判断改动带来的收益和退化？

有一件事不能忽略：这本书有版本

这本书的本地 PDF 是 2023 年预览版，书中会出现当时的模型、框架和代码接口。概念框架值得学习，但具体 API、模型名称、训练配方和性能数据不能直接当作今天的现状。遇到实践代码，要把它当作解释机制的材料，再对照当前官方文档和可复现环境。

所以这次我不打算把目录逐章改写成摘要。每一篇都尽量多问一步：这个设计解决了什么问题，代价是什么，放到项目里怎么验证？很多“模型不够聪明”的问题，最后可能落在数据、检索、服务或者评估上。

还有一个变化是，读这本书不能只盯着模型训练那一段。训练完成以后，模型还要经过量化、部署、路由、监控和评估，才能变成用户真正接触到的产品。一个参数更多的模型，如果延迟太高、成本太贵，或者在关键任务上没有证据支撑，实际价值未必比小模型高。

我准备把每篇笔记都写成三个层次：先解释书里的概念，再把它放回完整链路里，最后说明它在项目中会遇到什么边界。这样读完之后，留下来的不只是名词，而是一张可以用来排查问题的地图。

如果把这条链路放到一个真实项目里，可能是这样的：先收集公司文档，清理和切分后建立索引；选一个基础模型做适配；再通过推理服务提供 API；上线以后收集失败样本，回到数据、提示词或训练环节继续改。每个阶段需要不同的工具，但最终效果要由同一套任务指标来判断。

这也解释了为什么我不太赞成只用“模型大小”描述系统。参数量可以帮助估算能力和资源，却不能替代数据治理、权限控制、评估集和运行监控。成熟的系统，应该知道自己在哪些问题上可靠，在哪些问题上必须交给人。

参考：《大规模语言模型：从理论到实践》，第 1 章，PDF 第 13-24 页。本文为学习整理与独立阐释。