外观
总体架构解剖
一句话定位：大模型不是"一个模型"，而是一条从数据到产品的完整流水线。本文把这条流水线拆成七个环节，每个环节标注"输入是什么、输出是什么、关键问题是什么、本站哪一页展开它"——它是全站的地图，也是你建立系统观的第一站。
一、生命周期全景图
把大模型的完整生命周期画成一条流水线：
text
┌─────────────────────────────────────────────┐
│ 模型训练主线 │
│ │
数据工程 ──→ 预训练 ──→ 后训练（SFT/对齐）──→ 评测 ──→ 部署推理
│ │ │ │ │
│ │ │ │ │
└───────────┴────────────┴───────────────┴── 模型权重 ─┘
│
┌───────────────────────────────────┘
│ 模型使用主线
▼
应用（提示工程 / RAG / Agent）
│
▼
反馈回流（日志 / 评测 / 安全监控）──────────────→ 回流到数据与对齐两条主线
整条流水线可分成两条主线：
- 模型训练主线（数据工程 → 预训练 → 后训练 → 评测 → 部署）：产出"模型权重"，参与者主要是算法与训练工程师；
- 模型使用主线（部署推理 → 应用 → 反馈回流）：消费"模型能力"，参与者主要是应用、平台与产品工程师。
两条主线共享评测（训练侧评估模型，应用侧评估系统）与数据（训练侧造数据，应用侧回流数据）。绝大多数从业者只身处其中一段，但看懂全貌，才知道自己的工作在哪、价值流向哪。
二、七环节逐层解剖
1. 数据工程
输入：互联网语料、书籍、代码、多语言文本的原始抓取；输出：干净、去重、配比合理的预训练语料，以及后训练的指令/偏好数据。
| 关键问题 | 说明 | 对应页面 |
|---|---|---|
| 数据从哪来、质量如何控制 | 清洗、去重（MinHash）、毒性过滤 | 预训练 |
| 多语言/代码/数学怎么配比 | "数据即模型"的实证 | 数据集与基准档案 |
| 版权与许可问题 | 语料合规风险 | 安全与风险 |
数据是被低估的瓶颈
预训练语料动辄数万亿 token，但"量"远不如"质"。业内公认的观察是：数据质量的上限，决定了模型能力的上限。大量公司卡住的不是模型训练，而是数据管线。详见预训练的"数据即模型"一节。
2. 预训练
输入：清洗后的海量文本语料；输出：一个"会说话但尚未对齐"的基座模型（base model）。这是最烧钱的环节（千卡 GPU 训练数月），也是大模型能力的来源——"预测下一个词"的训练目标在这里把知识压进参数。
| 关键问题 | 说明 | 对应页面 |
|---|---|---|
| 训练目标与损失 | next-token prediction、交叉熵 | 语言建模 |
| 文本如何变成 token | 分词与词表 | 分词与词表 |
| 用什么架构承载 | Transformer、位置编码 | Transformer 架构详解 |
| 规模怎么定 | 参数、数据、计算量的最优配比 | 规模法则 |
| 怎么省算力 | MoE 稀疏专家 | MoE 稀疏专家模型 |
| 训练怎么调度 | 学习率、batch、分布式并行 | 预训练 |
3. 后训练（SFT 与对齐）
输入：基座模型 + 指令/偏好数据；输出：一个"听指挥、说人话、守底线"的助手模型（instruct/chat 模型）。预训练教能力，后训练教使用方式。
| 关键问题 | 说明 | 对应页面 |
|---|---|---|
| 怎么教模型"按指令办事" | 监督微调 SFT | 微调 |
| 怎么教模型"符合人类偏好" | RLHF / DPO | 对齐 |
| 怎么只改一部分参数 | LoRA、QLoRA 等参数高效微调 | 微调、微调实战 |
| 微调后能力会不会退化 | 灾难性遗忘 | 微调 |
后训练是 2022 年后的"隐形功臣"
基座模型已经会"生成"，但生成不等于好用。ChatGPT 之所以比基座模型更像"助手"，靠的正是对齐。把后训练与预训练割裂来看是新手常见误区——它们一个给能力、一个给形态，缺一不可。
4. 评测
输入：基座/后训练模型 + 评测基准；输出：能力画像（哪里强、哪里弱、有没有退化）。评测贯穿两条主线：训练侧"模型做没做对"，应用侧"系统好没好用"。
| 关键问题 | 说明 | 对应页面 |
|---|---|---|
| 用什么基准测 | MMLU/GSM8K/HumanEval 等 | 评测与基准 |
| 怎么自建评测集 | golden set、LLM-as-a-judge | 评估实战 |
| 幻觉怎么量化 | 事实性评测 | 幻觉 |
| 基准有什么坑 | 数据污染、榜单刷分 | 评测与基准 |
5. 部署与推理
输入：训练好的模型权重 + 推理请求；输出：低延迟、高吞吐的在线服务。推理与训练是两种截然不同的工程：训练吃"吞吐"，推理吃"延迟 + 显存"。
| 关键问题 | 说明 | 对应页面 |
|---|---|---|
| 生成过程怎么工作 | 自回归、KV Cache、采样 | 推理基础 |
| 显存怎么估算 | 权重 + KV Cache + 激活 | 部署与服务化 |
| 怎么提速降本 | 量化、continuous batching | 部署与服务化 |
| 用什么框架 | vLLM / SGLang / TensorRT-LLM | 框架与工具选型 |
6. 应用（提示工程 / RAG / Agent）
输入：模型服务 + 用户请求 + 应用编排；输出：可用的产品功能。这是模型使用主线的核心，也是大多数工程师真正工作的环节。
| 应用形态 | 机制 | 对应页面 |
|---|---|---|
| 直接提示 | 写好 prompt，让模型答 | 提示工程、提示工程实践 |
| RAG | 检索外部知识 + 生成 | RAG、RAG 实战 |
| Agent | 模型 + 工具 + 规划循环 | 基于 LLM 的 Agent |
| 微调适配 | 为特定任务改模型 | 微调实战 |
| 多模态 | 文本 + 图像/音频 | 多模态大模型 |
7. 反馈回流
输入：线上日志、用户反馈、安全事故、评测失败样本；输出：新的数据标注需求、对齐修复、评测集扩充。闭环让流水线"越用越好"。
| 回流方向 | 用途 |
|---|---|
| 回流到数据工程 | 沉淀用户真实问题，造更高质量的 SFT/偏好数据 |
| 回流到对齐 | 发现有害输出，补对齐样本与护栏 |
| 回流到评测 | 线上失败样本进入回归测试集（golden set） |
| 回流到产品 | 错误模式反哺提示词与 RAG 策略 |
反馈闭环是"做了才是工程师，不做只是调用者"
只调 API 不做回流，等于把质量改进全部外包给模型厂商。自建评测与日志回流（哪怕很小）是区分"会用"与"会做"的分水岭，详见评估实战。
三、环节速查表
| 环节 | 输入 | 输出 | 关键页面 | 参与角色 |
|---|---|---|---|---|
| ① 数据工程 | 原始语料 | 清洗配比后的语料/指令数据 | 预训练、数据集与基准档案 | 数据工程师 |
| ② 预训练 | 海量语料 | 基座模型 | 语言建模、Transformer | 训练工程师、研究员 |
| ③ 后训练 | 基座模型 + 指令/偏好数据 | 对齐助手模型 | 微调、对齐 | 对齐工程师 |
| ④ 评测 | 模型 + 基准 | 能力画像 | 评测与基准 | 评测工程师 |
| ⑤ 部署推理 | 模型权重 + 请求 | 在线服务 | 推理基础、部署 | 推理/平台工程师 |
| ⑥ 应用 | 服务 + 用户 + 编排 | 产品功能 | RAG、Agent | 应用/算法工程师 |
| ⑦ 反馈回流 | 日志 + 失败样本 | 新数据与修复 | 评估实战 | 全链路 |
1. 各环节的典型失败模式
每个环节都有一个反复出现的"翻车点"。提前知道失败长什么样，比事后排查高效得多：
| 环节 | 典型失败 | 现象 | 对策 |
|---|---|---|---|
| ① 数据 | 数据污染 | 评测分数虚高、生产表现拉垮 | 训练/评测数据隔离，去重与血缘审计（见数据集与基准档案） |
| ② 预训练 | 配比失衡 | 中文好英文差、代码差 | 按规模法则与语料配比表复盘 |
| ③ 后训练 | 对齐税 | 微调后通用能力退化 | 混合通用数据、控制训练步数（见微调） |
| ④ 评测 | 测不对 | 榜单高但业务不涨 | 加自建 golden set，回归测试（见评估实战） |
| ⑤ 部署 | 显存/延迟失控 | 上线即 OOM 或超时 | 先估算再选型，量化与批处理兜底（见部署与服务化） |
| ⑥ 应用 | 过度承诺 | 让模型做它不擅长的事（精确计算、实时事实） | 能力分层选型 + 工具/检索补齐（见提示工程实践） |
| ⑦ 回流 | 闭环断裂 | 线上问题永远不进训练数据 | 把失败样本接入标注与评测流水线（见常见陷阱） |
四、关键问题清单
七个环节各有一个"决定成败"的问题，面试与项目管理都从这里出题：
text
① 数据工程： 语料够干净、配比够合理吗？
② 预训练： 数据、参数、算力三者的配比符合规模法则吗？
③ 后训练： 对齐之后，能力与安全的天平摆平了吗？
④ 评测： 我们测的，真的是我们要的吗？
⑤ 部署推理： 延迟、吞吐、成本，三角你选了哪两个？
⑥ 应用： 提示、RAG、Agent，当前场景该用哪个组合？
⑦ 反馈回流： 失败样本真的回到了训练数据里吗？1. 从问题到决策：两条决策链
七个问题可以压缩成两条决策链，工程中最常被问到：
训练侧决策链（要不要自己训练模型？）
text
有高质量专属数据吗？──没有──→ 直接用现有模型（API 或开源）
│有
↓
能承受训练算力吗？───不能──→ 微调（LoRA）而非预训练
│能
↓
数据/参数/算力配比符合规模法则吗？───→ 参考[规模法则](/concepts/scaling-laws)定预算
↓
训练后要不要对齐？───→ 进入[对齐](/concepts/alignment)环节应用侧决策链（当前场景用什么组合？）
text
任务能靠写好提示解决吗？──是──→ [提示工程实践](/practice/prompting-practice)
│否
↓
需要私有/实时知识吗？──是──→ [RAG 实战](/practice/rag-in-practice)
│否
↓
需要多步行动与工具吗？──是──→ [基于 LLM 的 Agent](/case-studies/agents-with-llm)
│否
↓
需要固定格式/稳定风格？──是──→ 考虑[微调](/concepts/fine-tuning)
↓
└──→ 回到[评测与基准](/concepts/evaluation)重新验证任务定义两条决策链的终点都是评测——没有评测，任何"选型"都是猜。这也是为什么评测在生命周期里处于承上启下的位置。
五、人才能力图谱
从生命周期看岗位，每个环节都是一类角色，也对应一套技能（详见求职与 JD的 JD 拆解）：
| 环节 | 岗位 | 核心技能 | 对应知识页 |
|---|---|---|---|
| ① 数据工程 | 数据工程师 / 语料工程师 | 爬取、清洗、去重、配比 | 预训练、数据集与基准档案 |
| ② 预训练 | 训练工程师 / 研究员 | 分布式训练、规模法则、调参 | 预训练、规模法则 |
| ③ 后训练 | 对齐工程师 / 微调工程师 | SFT、RLHF/DPO、LoRA | 微调、对齐、微调实战 |
| ④ 评测 | 评测工程师 | 基准、评测集设计、LLM-as-a-judge | 评测与基准、评估实战 |
| ⑤ 部署推理 | 推理优化 / 平台工程师 | KV Cache、量化、批处理 | 推理基础、部署 |
| ⑥ 应用 | 应用算法 / Agent 工程师 | 提示、RAG、工具调用、产品化 | RAG、Agent、提示工程实践 |
| ⑦ 全链路 | 技术负责人 / 算法负责人 | 系统架构、评估体系、成本控制 | 常见陷阱 |
一个岗位往往跨多个环节
一线"大模型算法工程师"通常横跨 ③④⑥（微调 + 评测 + 应用），而"训练工程师"聚焦 ②。面试时先问清对方岗位落在哪个环节，再针对性准备——这是求职与 JD里反复强调的"岗位地图"思维。
1. 能力自查清单
对照七个环节，用三档（熟练 / 了解 / 空白）给自己打一遍分，定位下一步：
| 环节 | 自查问题 | 熟练 | 了解 | 空白 |
|---|---|---|---|---|
| ① 数据 | 能说出去重（MinHash）与配比的做法吗 | ☐ | ☐ | ☐ |
| ② 预训练 | 能画出 next-token 训练循环吗 | ☐ | ☐ | ☐ |
| ③ 后训练 | 能讲清 RLHF 三步与 LoRA 原理吗 | ☐ | ☐ | ☐ |
| ④ 评测 | 能设计一个 20 条的 golden set 吗 | ☐ | ☐ | ☐ |
| ⑤ 部署 | 能估算一个 7B 模型 INT8 的显存吗 | ☐ | ☐ | ☐ |
| ⑥ 应用 | 能说清提示 / RAG / Agent 的选型边界吗 | ☐ | ☐ | ☐ |
| ⑦ 回流 | 线上失败样本进过评测集吗 | ☐ | ☐ | ☐ |
打勾方法："空白"直接看对应的概念页与实践页；"了解"用一页纸写给自己讲一遍，讲不通就重读；"熟练"尝试给他人做一次讲解或写一篇笔记。这套清单也是求职与 JD中"JD 知识点拆解"的自评版。
六、从哪开始
有了全景图，怎么落地？三种选择：
- 先读懂七环节的顺序：按学习路径的"系统精进"路线，把七环节对应页面逐个读一遍；
- 先动手做一个环节：从从零构建一个大模型起步，把 ② 的最小版跑通，再补其他环节；
- 先把自己放进地图：对照求职与 JD的岗位版图，找到自己的位置，用面试题库检验薄弱环节。
1. 48 小时最小闭环
如果只想用最少时间"完整走一遍"七个环节，可以在 48 小时内完成一个最小的闭环（用开源小模型本地部署或 API 皆可）：
| 时间段 | 动作 | 覆盖环节 |
|---|---|---|
| 第 1 小时 | 选一个窄任务（如：把用户问题分成 5 个意图），手写 20 条 golden set | ④ 评测的设计 |
| 第 2~6 小时 | 选模型、写第一版提示、跑出 baseline 分数 | ⑥ 应用 |
| 第 7~24 小时 | 按评估实战方法迭代提示与示例，记录每次改动与得分 | ④ 评测 + ⑥ 应用 |
| 第 25~40 小时 | 用 API 网关或本地 vLLM 封装服务、接请求日志 | ⑤ 部署 |
| 第 41~48 小时 | 收集失败样本，回到 golden set 补充用例，写一页复盘 | ⑦ 反馈回流 |
这个闭环刻意不碰 ①②③（数据、预训练、后训练）——那是"模型侧"，最小闭环展示的是"应用侧"全链路。跑完它，你就亲历了一次完整的模型生命周期，剩下的问题（要不要微调、要不要 RAG）会自然浮现，对应的页面也就有了上下文。
一句话总结
大模型工程 = 数据 × 模型 × 对齐 × 评测 × 部署 × 应用，六个要素缺一不可，七个环节环环相扣。地图已经画好，现在挑一个环节出发——需要术语时查术语表，需要模型信息时查主流模型档案。
延伸阅读
- 学习路径：三条路线 —— 把本页七环节翻译成 8 周阅读计划
- 什么是大语言模型 —— 生命周期的"产品"：一个 LLM 的定义三层面
- 演进简史 —— 七环节是如何被历史一步步补全的
- 语言建模 —— 环节 ② 的地基：预测下一个词范式
- 对齐 —— 环节 ③ 的完整展开：RLHF 与 DPO
- 部署与服务化 —— 环节 ⑤ 的工程细节：显存估算与量化
参考资料
- Andrej Karpathy · State of GPT（讲座视频，2023） —— Karpathy 详解 GPT 从数据到推理的完整流水线，"生命周期全景"概念的最直观普及来源
- Hugging Face · Transformers 官方文档 —— 架构实现与训练/推理工具链的权威文档
- OpenAI · Language Models are Few-Shot Learners（2020） —— 预训练范式与规模效应的原始论文
- Google · Attention Is All You Need（2017） —— 环节 ② 架构基石的原始论文
- OpenAI · Training Language Models to Follow Instructions（InstructGPT，2022） —— 环节 ③ 对齐范式的原始论文
- Anthropic · Constitutional AI（博客） —— 对齐工程与反馈回流的产业实践参考