企业官网建设流程全解析

1. 从零开始不是低效复读，而是建立不可迁移的工程认知

最近总有人问我一个问题：现在市面上现成的开源模型、API 调用、推理框架一堆，直接拿来用不就行了，为什么还要折腾什么ai-engineering-from-scratch，从头手写一个语言模型？

这个问题的答案，得从一次面试说起。我之前面试过一个候选者，简历上写着"精通大模型应用开发"，聊到 LoRA 为什么能省显存时，他说是"因为只训练了一部分参数"。再追问"哪一部分"的时候，答案是"不知道，反正调库就行"。这不是个例。大量所谓的 AI 工程师，本质上只是 Prompt 工程师加 API 封装工程师。你问他 GPT 的 next token prediction 是怎么变成对话能力的，他说不出来；你问他为什么 batch size 从 2 变到 4 训出来的模型效果差异巨大，他说不出来；你问他 RLHF 里那个 reward model 到底在拟合什么，他也只能含糊带过。

当然，我不是说调库没有价值，工程本身就是组合与调度艺术。但如果你完全没有从零构建的底层认知，遇到超出库里封装范围的问题，你就彻底抓瞎。显存不够你知道梯度累积怎么配吗？训练 loss 出现 NaN 你知道去检查哪几个位置吗？分布式训练卡住你知道是 NCCL 通信还是数据加载器的问题吗？这些都不是"调库"能调出来的东西。

所以我把ai-engineering-from-scratch定位成一整套认知基建：你理解数据如何被分词、嵌入、注意力计算、归一化，理解 loss 为什么震荡、梯度为什么消失、tokenizer 的 vocab size 为什么必须对齐，当你再回去用任何框架时，你看到的就不再是一个个 magic 的黑盒函数，而是一层薄薄的封装纸。反过来你也能判断：哪些问题值得自己动手造轮子，哪些直接用开源实现就够了。

这条路线不仅仅适合想搞 AGI 的研究人员。就算你的目标是做一个 AI 产品的应用工程师，亲手把一个小语言模型从零训起来，也会让你对显存预算、推理延迟、微调测试集划分这些日常操作有完全不同的直觉。这是一笔稳赚不赔的投资。

提示：这篇文章不是教你一行行抄代码的教程，而是一份把"从零构建 AI 工程"这条路的关键节点、原理认知、避坑方向讲清楚的地图。我默认你已经有一点 Python 基础和基本的机器学习概念，但即便你是刚入门的小白，跟着章节走也能建立起清晰的道路感。

2. 手写 Transformer 之前，先摸清整套技术链路

在你打开 PyTorch 开始写nn.Transformer之前，必须先搞清楚一个基本问题：一个大语言模型从零到能被人使用，到底要经过哪几步。很多人的误区是一上来就盯着"transformer 架构怎么实现"死磕，代码敲了一晚上，模型问世的幻想却离现实越来越远。实际上，完整的链路远比"搭个网络"要长得多。

2.1 八个环节，一个都不能少

我们把大语言模型的工程链路拆开，大概是这样的：

这八个环节里，任何一个做不好，最后交付的模型都可能是废的。但绝大多数从零开始的项目，把 90% 的精力砸在了第四步"预训练"上。这很自然，因为写 transformer 最有"我要造出 GPT 的感觉"。可是你很快会发现，数据质量不够好、分词器词汇表有问题、评估环节缺失，你在第四步折腾得越久，后期返工就越痛苦。

我自己带过一个仿照 GPT-2 做的小模型项目，当时花了整整两周调整 decoder 层数和注意力头数，结果发现效果提升不如把语料里的中文乱码片段好好清洗一遍来得显著。这就是链路思维的重要性：你的模型性能瓶颈往往不在模型架构本身，而在整个链路最薄弱的那一个环。

2.2 先搭一个能跑的通路，再逐步优化

我建议从零开始的第一个里程碑，根本不是训练出一个好的大模型，而是把上面的八个环节用最简版本全部串起来。

举个例子：你不需要上来就搞几百 GB 的语料，你可以取一段几 MB 的公开小说（比如古登堡计划里的英文小说）作为语料；你不需要训练一个 70B 的 tokenizer，你手写一个简单的 BPE，词表控制在 5000 以内；你的模型可以是 6 层 decoder、4 个注意力头、embedding 维度 128 左右；预训练几步之后，直接在验证集上看看困惑度和 loss。这个最简通路跑通了，你才算真正把"大语言模型"从神话变成了工程对象。

之后每一次只优化一个环节。比如先把 tokenizer 换成 SentencePiece，或者把语料扩展到 10GB，或者加上学习率预热和余弦衰减。你每优化一个环节，都要能观察到下游评估指标的变化。这种"单变量实验"的思维，会让你对整个系统工程产生极强的掌控感。如果你一上来就想搞个大新闻，直接复刻 GPT-3 的架构和训练规模，大概率你的 GPU 会先哭给你看，然后你的心态会迅速崩塌。

这个思路参考了 Sebastian Raschka 的《Build a Large Language Model (From Scratch)》的核心框架。那本书好就好在，它不是把一个巨大的模型直接怼给你，而是让你从最小实现开始，像一个工程师一样一步步搭出完整的系统。尤其是它把 tokenizer、架构、预训练、微调讲的非常细。不过要说句公道话，那本书更偏研究和教学，真到生产环境的工程细节，比如量化部署、服务编排，它涉及得不多，那是我们要在后面自己补的课。

3. 数据工程与 Tokenizer：训练曲线崩盘的元凶

我们常说"垃圾进，垃圾出"。在从零训练一个模型的场景里，这句老话以非常残酷的方式显灵。绝大多数新手训练出来的模型输出前言不搭后语，第一反应通常是"模型还不够大""训练步数不够多"，然后疯狂堆算力。但实际上，问题 60% 的概率出现在数据和 tokenizer 上。这一节我把最容易翻车的地方掰碎了讲。

3.1 原始语料质量：决定模型智力上限的暗线

先放下模型架构不谈，我们说语料。很多人从网上随便下载了一个"中文语料包"，30GB，感觉很多了，直接开训。训到一半发现 loss 下降到了一个平台就再也不动了，模型生成的内容像乱码又不完全是乱码。后来一查看数据，发现语料里有大量的 HTML 标签残留、版权页重复内容、甚至是半个 UTF-8 编码切碎的行。

我给你的建议是，第一版语料一定要做严格的清洗流水线。这不是什么高深 ML 技术，就是工程素养。你可以按这几步走：

1. 统一编码格式（UTF-8），剔除无法解码的字节。
2. 去除全角/半角符号内的 HTML 实体，比如 、<p>。
3. 按段落下拉，过滤掉长度小于 50 个字符的碎片行。
4. 做全局去重：对有大量重叠文本的句子对做 MinHash + LSH，特别是新闻类语料，转发的重复率极高。
5. 敏感词和低质内容过滤：这一步不展开说策略，但原则就是宁缺毋滥。

如果你嫌手工写麻烦，可以直接用现成的工具，比如datasets库里的load_dataset配合cleanlab做初步质量评估，或者直接复用开源社区如 RedPajama 的清洗脚本思路。但我依然建议你手动过一遍，因为你对数据的感觉，会影响后续所有决策。

3.2 BPE 分词器：为什么 vocab size 对齐这么重要

Tokenizer 是大多数手写 Transformer 教程一笔带过的地方，但它坑起来真的会把你坑到自闭。很多人直接调tokenizers库训练一个 BPE，然后开开心心把vocab_size=32000塞进模型。但有几个细节你几乎肯定会踩：

第一，tokenizer 的 vocab size 必须和模型的 embedding 矩阵维度严格对应。nn.Embedding的第一个参数默认是vocab_size，如果你换了 tokenizer 但没有同步改模型配置，轻则报错，重则索引越界直接跑挂。这个看起来低级，但在复杂的实验管理流程里，模型配置文件和 tokenizer 文件分别存储，忘同步的情况太多了。

第二，特殊 token 的顺序要固定。<bos>、<eos>、<pad>、<unk>放在词表最前面还是最后面，会影响训练的随机初始化和生成。它的固定顺序必须写进一条 config 里，任何加载代码都要校验。

第三，不要在训练完模型之后再换 tokenizer 重训。你可能看到某些项目先训 tokenizer，再微调词表。对新手来说，这只会制造无尽的痛苦。最简单可靠的方案是：一开始定好 tokenizer，训练，永远不再改。

实践中，我经常用一个非常直观的检查方式：把语料里一个词表之外的生僻字单独收集出来，调用 tokenizer 后看它们被拆成了什么子词。如果大量生僻字被拆成单字节乱码或吐出了一堆[UNK]，那说明你的词表和语料分布严重不匹配。这时候不要硬着头皮训，先把词表或者语料换掉。

3.3 让"tokenization 不崩溃"落地的实操清单

我在本地训练一个最小的 GPT 时，tokenizer 配置是这样一套组合，可以作为参照：

• 选择分词算法：BPE（或 SentencePiece unigram，中文场景我更喜欢 unigram，它可以处理多语言混排不生硬）。
• training corpus：至少 100MB 左右文本，太少词表碎片化严重。
• vocab_size：训练 1 亿参数级别模型时，我常用 8000~12000 之间。不要一上来就搞 32000 甚至 50000，词表太大 embedding 矩阵占显存，而小模型根本学不满这么多参数。
• min_frequency=2（低频 token 直接摈弃）。
• special_tokens=["<unk>", "<s>", "</s>", "<pad>"]。
• 训练好后跑一遍自检代码，确认语料中 99% 的 token 都不是[UNK]，并且平均 token 长度（字符数/token 数）在 2~4 之间。

这一步你大概需要花半天时间，但它能在后续几百小时 GPU 训练里给你省下无数返工时间。数据清洗和 tokenizer 这种"不起眼的脏活"，正是 AI engineering from scratch 这条路上最考验耐心也最锻炼工程直觉的部分。

4. 从语言模型到推理模型：对齐这一步到底在做什么

你费了九牛二虎之力，训出了一个"预训练语言模型"。它看起来能续写文本，但你还远不能把它当成 ChatGPT 那样直接对话。如果不做对齐（alignment），你对它说"你好，请介绍一下你自己"，它大概率会接一句"我的名字叫 Transformer，我是一种基于自注意力机制的模型"，或者干脆写出下一篇新闻稿。为什么会这样？因为预训练的目标函数是"下一个 token 预测"，它只学到了语料统计规律，没学到"人类在对话中期望的说话方式"。

所以，第二个大节点就是对齐。这也是"build a reasoning model from scratch"的热搜词背后，大家真正关心的部分：怎么让模型不仅会说人话，还能像人一样思考推理。

4.1 SFT 阶段：不是简单的"喂人话"

监督微调 SFT，是把预训练模型从"文本续写器"改成"对话助手"的第一件事。做法看起来很简单：收集指令-回答对，然后继续用交叉熵训练模型，让它输出回答。但细节里全是坑：

• 数据配比：如果你只喂 1 万条高质量对话，模型容易过拟合到特定表达方式；如果你混合了 100 万条杂七杂八的网聊数据，模型又会丢掉对话的优雅。常见做法是 80% 高质量指令数据 + 20% 通用预训练数据混入，防止灾难性遗忘。
• 数据多样性：不只是 QA 对，还要有拒绝回答、多轮对话、格式错误恢复等边界样本。比如用户连续追问三次相同问题，模型的回答应该略有差异而不是复读机。这些都要靠 SFT 数据里的人为设计。
• 训练超参：SFT 学习率通常比预训练低一个数量级（比如预训练用3e-4，SFT 用2e-5），epoch 数通常 1~3 个。这个阶段的核心是"微调行为模式"，而不是重新"灌输知识"。你训练得太久，模型反而会忘掉预训练阶段学到的东西。

我踩过的一个具体教训是：SFT 数据里大量出现了"好的，我来帮你解答"这种 AI 腔开头。结果训练出来的模型，无论用户问什么问题，第一句话都是"好的，我来帮你解答"。看起来热情，实则蠢得要命。后来我在构造 SFT 数据时，强制要求 30% 的回答直接进入核心内容，不客气、不寒暄，才把这个毛病掰回来。

4.2 RLHF 与 RLAIF：让模型学会"什么事该做"

SFT 之后模型会跟着指令走了，但它还是不知道自己哪些话是对的，哪些话是不该说的。这就是强化学习人类反馈（RLHF）登场的地方。我不打算在这里把 RLHF 的数学公式抄一遍，而是用一个更容易理解的框架讲清楚它到底在优化什么。

你可以把 RLHF 想象成一个老饲养员驯海豚：你手里有两个网络，一个是正在被训练的策略网络（就是你的语言模型），一个是奖励模型（reward model）。奖励模型观察人类对海豚表演的评分，学会预测"人类大概会喜欢怎样的一跃""怎样的表演是让观众皱眉的"。然后策略网络在生成回答时，奖励模型给它打分，策略网络就朝着分数高的方向更新。

在实现上，有几个最常见的坑：

• 奖励模型的数据集构建：做人类偏好标注时，对同一个 prompt 要准备多个模型的输出，让标注员排序。排序的一致性（Krippendorff's alpha）太低，说明标注指南不明确，reward model 也学不好。
• PPO 算法的 rollout 稳定性：策略模型一旦更新过快，生成的 rollout 会在一两轮内质量骤降。一般建议 rollout 时对旧策略做 KL 散度约束，把更新幅度压住。
• reward hacking：模型会钻空子去生成"看起来讨喜"但是空洞无物的回答，比如长篇大论地表达礼貌。这是 RLHF 最经典的奖励欺骗行为。缓解手段之一是给奖励模型输入加一个"答案长度惩罚"或"重复度惩罚"。

如果说 SFT 是教模型"说人话"，那 RLHF 就是教模型"办人事"。它让模型学会拒绝不合适的请求、在不确定的时候承认自己不知道、在长回答中保持一致性。这个过程非常烧钱，也极消耗耐心，所以很多中小团队更倾向于直接用 RLAIF——用另一个更强的模型（比如一个 API 背后的大模型）来给回答排序，省去人工标注环节。虽然 RLAIF 的效果上限取决于教师模型的水平，但在工程效率上确实是巨大解放。

4.3 通向推理模型：从"对答如流"到"停下来思考"

最近"build a reasoning model from scratch"这个词很火，我觉得它对准了一个新趋势：光能流利对话已经不够了，我们需要模型做数学推导、代码调试和复杂逻辑推理。为什么一个大模型会做错9.11 > 9.9这种题？因为它走的是"概率续写"路线，不真正执行规则推演。

目前最主流的方法是给模型引入思维链（Chain-of-Thought）和强化学习推理训练。具体落地，参考 DeepSeek-R1 那套思路：

1. 构造带详细推理步骤的数据，做 SFT，让模型学会在输出正式答案前先输出一段[thinking]...[/thinking]的推理草稿。
2. 然后设定可验证的奖励信号，比如代码题的测试用例通过率、数学题的最终答案是否正确。这些奖励信号不需要人类逐条标注，而是可以由程序自动判定，因此可以大量生成数据。
3. 用 GRPO/PPO 类算法专门优化"推理得分"，同时用格式奖励约束模型必须输出[thinking]推理块，防止模型跳过思考直接给答案。
4. 最后通过拒绝采样和微调蒸馏，把推理能力压缩成更小的模型。

听起来挺顺畅，但实操里有个非常头痛的问题：模型会为了奖励而"表演推理"。我见过某个模型在[thinking]块里写"我需要逐步分析……？不对，或者直接猜一个答案吧"，然后真的输出一个错误的最终答案。奖励模型要是没抓住它"假推理"，它就会越来越擅长装模作样。所以推理模型的对齐，比普通的 RLHF 更依赖奖励信号的严格性。它要求你设计的 reward model 对过程有感知能力，而不只是看最终结果。

如果你从零开始做推理模型，我的建议是别一上来就搞多模态、长期记忆这些花活。你先把"自动可验证的数学题/代码题"这一条赛道跑通，把 RL 训练流程调稳，再去看更复杂的场景。

5. 评估、量化和部署：模型能跑只是第一步

很多时候大家把模型训练出来，loss 很低，对话也很流畅，便觉得大功告成了。实际上，在工程视角里，模型才刚刚从"实验室展品"变成"待交付的半成品"。真正的 AI 工程，后半段才开始。

5.1 评估体系：不要只盯着 loss 看

我遇到过一个团队，在训练日志里看到 loss 从 3.2 降到 2.1，兴奋得不得了，直接上线上服务。结果用户反馈"回答驴唇不对马嘴"。为什么？因为 loss 衡量的是 token 级预测概率，它降了只能说明模型在"字形和常见搭配"上越来越熟练，不代表逻辑正确、不表示事实可靠。

更好的做法是同时跟踪三类指标：

• 生成质量指标：BLEU / ROUGE 对语序敏感，不适合对话；对生成模型，我更看重人工抽样评分、GPT-4 打分、以及格式合规率（比如 JSON 输出能否被解析）。这些指标能告诉你模型在真实使用时好不好用。
• 事实一致性指标：对问答和摘要场景，用 FactCC、QAFactEval，或者干脆拿另一个模型交叉验证答案和语料中的证据，能发现"模型一本正经胡说八道"的情况。
• 行为约束指标：比如"拒答率""友好度""敏感内容拦截率"，RLHF 后这些指标一定要做回归测试，防止对齐被后续微调破坏。

评估集也不是随便从训练集中抽几条就行。我倾向于为每个任务类型单独构建 small expert evaluation set，比如 500 条数学题、500 条代码题、500 条客服对话，每次模型变更后固定跑一遍，形成可以对比的回归记录。

注意：如果你要拿公共榜单（比如 MMLU、GSM8K）的测试题来评估，请一定要记住，这些题目可能已经泄入训练语料。不要盲目迷信基准分数。最好是保留一份内部私有测试集，永远不放进训练数据。

5.2 量化与部署：从"能跑"到"跑得起"

一个 7B 参数的模型，用 FP16 跑，光权重就是 14GB 显存，加上 KV cache 和中间激活，单卡 24GB 大概只够处理很短上下文。你训练的模型要真正落地，量化几乎是必修课。

我最常用的是 4-bit 量化，比如用 GPTQ 或 AWQ。量化之后 7B 模型的权重体积降到约 3.5GB，推理速度可以提升两到三倍。代价是输出质量和事实准确率会略降。对于低资源场景，我还常用更激进的 2-bit 或 3-bit 量化，但这时模型很可能开始胡言乱语。所以量化的核心原则是：每次都要带着私有评估集测一遍，看精度损失是否在可接受范围内。

部署时还有两个容易忽略的点：

• 批量推理的动态延长：LLM 的单条请求生成长度不可预测，最好用 continuous batching（连续批处理）来提升吞吐，而不是固定 batch 尺寸。vLLM、TGI 这些框架都内建了这个能力。
• 流式输出与超时控制：生产环境必须支持 SSE 流式输出，否则用户首 token 延迟（TTFT）会高得难以忍受。同时要设置 max tokens 和超时时间，防止用户一次性请求炸掉你的 KV cache。

5.3 线上监控没有捷径

部署只是起点，真正的 AI 工程还要考虑线上模型漂移和用户反馈闭环。

• 记录每次请求的 prompt、response、延迟、token 数、命中的业务指标。
• 定期随机抽样，让人工（或更强大的模型）对线上输出评分，并把低分样本回溯到评估集合里。
• 一旦分数跌破阈值，触发离线重训或回滚到上一个稳定版本。

这些听起来有点像运维的活，但它是 AI 工程和算法研究最本质的分界线：算法研究可以只关心 bench 数字，AI 工程必须关心整个系统的稳定和收益。

6. 我的路线图与三个血泪教训

在正文的最后，我想把前面这些经验浓缩成一份可以直接参考的路线图，以及我自己在实践中踩过的三个大坑。这份路线图不一定适用于所有人，但它至少能帮你避免那种"东一榔头西一棒子"的迷茫感。

6.1 阶段化路线图参考

按照 3~4 个月的业余时间算，大致可以这么分配：

这个路线图的关键在于"每个阶段都有一个可以看得见的产物"，而不是"我学完了某个算法"。所有阶段之间的衔接，都要有可验证的实验结论做支撑。这样你上一步的产出就是下一步的输入，整个学习过程就不会流于空谈。

6.2 三个血泪教训

第一，不要跳过数据工程去追求"更高级的架构"。我犯过的最大错误就是，一上手就研究 MoE、稀疏注意力这类花哨组件，结果基座模型本身连基础 loss 都降不下去。后来把注意力拉回数据质量，效果立刻起飞。从零开始的项目，数据质量几乎永远是最优先的改进方向。

第二，不要把"能复现开源代码"当成"自己会了"。有一种沉浸感是：你 clone 了别人的仓库，pip install之后跑通了 demo，就误以为模型是你自己构建的。真正的from scratch意味着你能够在没有原仓库的前提下，从空目录开始，一项项把数据流、训练循环、推理逻辑写出来。只有在写不出来的地方，你才会遇到真正的知识死角。

第三，RLHF/RL 的乐趣在于"炼丹"，痛苦的在于"复现"。如果你发现同样的代码和同样的超参数，今天训练出来的模型和明天训练出来的模型表现差很多，不要慌，先检查随机种子、显存波动、数据加载顺序，再去怀疑算法本身。百分之八十的情况下，问题出在实验环境不一致，而不是 RL 的数学推导。

6.3 最后再说两句心里话

ai-engineering-from-scratch这条路，它不是最快的路，甚至很多人在走了一半的时候会怀疑自己是不是在重复造轮子。但走到后面你会发现，那些真正能在大模型应用层做出创新的人，一定不是只会调包的人。他们对底层机制的体感，决定了他们能在什么高度的抽象上做决策。

我个人在实际操作中最深的体会是：每一次动手从零实现一个模块，无论是一个 tokenizer 还是一个注意力层，都会让你在使用开源工具时多一分底气，少一分恐惧。这种感觉积累起来，会让你在面对新模型、新框架、新训练范式时，不再焦虑"自己会不会跟不上"，因为你已经拥有了一套可以随时拿来拆解问题的底层框架。

最后分享一个小技巧：不要一开始就给自己定一个野心过大的目标，比如"我要从零训练出媲美 GPT-4 的模型"。请把目标缩小成"我要训练出一个能写藏头诗的模型""我要训练出一个能解一元二次方程的模型"。当你把这些微型模型一个个从零构建成功，你会逐渐从 AI 的"使用者"变成 AI 的"构建者"。这个转变，才是ai-engineering-from-scratch真正的意义所在。