1. 项目概述AI工程从零开始意味着什么这几年“AI engineering”几乎成了最热的职业方向但真要说清楚“从零开始”这四个字敢接的人其实不多。我身边不少朋友看到网上到处是“三天上手大模型”“一键部署AI应用”的标题党结果真到自己动手时连一个最简单的文本分类模型都跑不顺。这个项目标题ai-engineering-from-scratch其实戳中了一个很本质的问题与其拿着一堆现成工具拼拼凑凑不如老老实实把AI工程的核心链路自己搭一遍。这就像学做饭你跟着菜谱能做出菜但只有从选菜、切菜、调味、控制火候一步步都试过你才真正会做饭而不是只会照着教程按步骤操作。所谓“from scratch”在AI工程里通常指两件事一是从零开始实现关键算法或模型结构不依赖现成的黑盒API二是从零开始搭建完整的工程链路包括数据清洗、特征工程、模型训练、评估、上线和监控。这两条线缺一不可。只懂调库调参的人遇到一个没有现成方案的任务就束手无策只懂算法原理但不会工程化的人做出的模型永远停留在Jupyter Notebook里。这篇内容适合三类人第一类是刚入门AI、想建立系统认知的学习者第二类是有基础但想补齐工程能力、把自己从“调参侠”进化成“AI工程师”的开发者第三类是团队负责人或技术选型者需要判断一个AI项目从0到1落地的成本和路径。我会尽量用我实战中踩过的坑和验证过的方案把这个过程讲透。别急着碰大模型。现在很多人的学习路径有问题一上来就研究几十B参数的模型结果显卡不够、数据不会处理、效果还一团糟。真正高效的路径是先用小模型把整个工程链路跑顺再考虑规模放大。这也是为什么我现在看一个人有没有AI工程能力先看他能不能从零训练一个几百万参数的模型而不是看他会不会调用现成大模型API。2. 内容整体设计与思路拆解2.1 先搞清楚“AI工程”和“算法”的区别很多人把AI工程等同于写模型代码这是个致命误区。AI工程是整个系统性的工作流包含业务问题定义、数据获取与清洗、模型设计、训练调优、评估验证、部署上线、运营监控七个环节。算法只覆盖“模型设计”和“训练调优”的一小部分。我见过太多算法工程师模型做得极好但一到部署就卡住因为没考虑过推理延迟、显存占用、并发请求这些工程指标。在规划ai-engineering-from-scratch这个学习项目时我把它拆成了五个层基础层Python、数学基础线性代数、概率论、微积分、PyTorch/NumPy操作数据层爬取/收集数据、清洗、标注、构建DataLoader、特征工程模型层从手动实现线性回归、多层感知机开始逐步过渡到Transformer结构、小规模语言模型训练层损失函数设计、反向传播、优化器选择、分布式训练单机多卡、日志与追踪部署层模型导出、ONNX/TensorRT优化、推理服务搭建、性能监控、A/B测试每一层都必须亲手完成至少一个闭环项目。比如基础层不要只刷文档去手写一次mini-batch梯度下降用纯NumPy实现一次Transformer的前向传播和反向传播。这些练习很枯燥但正是“from scratch”的价值所在。2.2 为什么“手搓模型”仍然是最高效的学习路径我经常被人问“现在框架这么发达自己实现一遍有意义吗”我的回答是框架只是工业化的工具它不是认知的替代品。用PyTorch的nn.Linear和nn.MultiheadAttention只是告诉机器怎么做自己一行行写出来才能理解为什么这么做。这和你用计算器能算出平方根但只有自己写过牛顿迭代法才真正理解数值计算是一个道理。那本《Build a Large Language Model From Scratch》为什么火也是心理上的同感大模型本身并不神秘它就是一堆张量操作、注意力机制和训练策略的组合。作者带读者从零构建一个小型GPT目的不是挑战HuggingFace而是帮人建立“我不是只会用库”的底气。同理“build a reasoning model from scratch”这个热词反应的也是同一个需求——与其只读论文不如亲手训练一个能推理、能决策的模型顺着这条路理解数据配比、奖励建模、强化学习微调这些大模型中最核心的操作。我在自己的实践里也验证了这个路径。手写模型再加上端到端的训练流程虽然代码量多了几百行但对整个系统的敏锐度提高了好几个级别。模型loss涨了知道去查哪个环节部署慢了知道瓶颈在哪儿这些能力只有亲身趟过一遍才能获得。2.3 理性看待大模型热潮热门概念和实际能力的关系最近“推理模型”reasoning model这个概念特别火很多人想自己从零构建一个推理模型。但先泼一盆冷水论文里那些效果惊艳的推理模型动辄都是几十亿甚至上千亿参数还要配合海量的强化学习训练数据个人开发者根本复现不了。但这不代表这条路不值得走关键是要在可控规模内复现原理。我的思路是分三步走第一阶段做一个极小的语言模型比如300万参数训练一个OpenWebText或数学题数据集让它学会基本的字符或单词预测第二阶段在基础模型上做指令微调让模型学会遵循“问题—答案”的格式第三阶段尝试简单的过程监督或奖励模型通过强化学习让模型学会在数学题上多步推理逐步逼近论文中“推理模型”的核心机制。这个过程跑下来你对推理模型背后的数据、算法和工程问题就有了切肤的理解拿起大模型论文来也会觉得亲切很多。千万不要一上来就奔着几百亿参数去那是只有顶级实验室才有的资源条件。这里必须多说一句网络上《Build a Large Language Model From Scratch》的百度云网盘盗版资源很常见我的建议是不要图省事下载盗版。支持正版是对作者劳动的尊重也能确保你拿到的是完整、最新的版本。书本身并不贵和它带来的认知价值相比这点投入值得。3. 核心细节解析与实操要点3.1 数据工程决定模型上限的隐形战场我在实战里最深刻的体会是模型的bottleneck经常不是模型结构而是数据质量。做过一次数据清洗你就会明白为什么业界流行“垃圾进垃圾出”这句话。以训练一个小型语言模型为例数据链路通常包括采集、过滤、去重、分词、分桶等环节。我自己在做一个中文领域模型时直接去网上爬了约500万条新闻文本结果发现里面的问题比想象中多得多大量HTML标签和URL被当成正文成片的广告、免责声明、重复内容编码混乱繁体简体混杂还有乱码字符有些文本太短不到20个字对语言模型的学习几乎没有帮助这些脏数据如果直接进入训练流程轻则拉低训练效率重则让模型学到一堆噪声。我的处理流程大致是这样的用BeautifulSoup或正则表达式去除HTML标签、脚本代码、多余空白按URL去重、按文本哈希去重过滤掉长度异常过长或过短和明显不是自然语言的文本比如全是符号或者重复字词统一编码格式做繁简转换。数据这一块越早建立“数据质量远胜数据数量”的意识越好。我在第一版训练时就因为偷懒跳过了去重结果模型在生成时频繁复读某些新闻标题后来排查了整整一天才发现是数据里同一篇新闻被爬了几百遍。3.2 从零实现一个轻量级Tokenizer“从零构建大语言模型”绕不开的一个坎就是Tokenizer。很多人直接用现成库比如transformers里的GPT2Tokenizer或tiktoken这没什么问题但若想真正理解语言模型是怎么吃饭的手写一个BPE或WordPiece分词器是必做功课。以BPE为例核心思想是反复合并高频字节对直到达到预设词表大小。我会用Python的collections.Counter实现一个简化版from collections import Counter def get_stats(ids): counts Counter() for pair in zip(ids, ids[1:]): counts[pair] 1 return counts def merge(ids, pair, idx): newids [] i 0 while i len(ids): if i len(ids) - 1 and ids[i] pair[0] and ids[i1] pair[1]: newids.append(idx) i 2 else: newids.append(ids[i]) i 1 return newids # 词汇表、合并逻辑、编码器、解码器……后面都是一层层往上搭别看这几段代码简单它背后代表的是语言模型“文本—ID”映射的核心原理。自己写一遍之后再去看GPT-4级别的分词策略理解深度完全不一样。实际训练时我不会自己现写因为tiktoken这种库已经优化得很好了但“手写一次”“正式用库”搭配效率和认知双赢。3.3 模型结构从MLP到Transformer的升级如果你真想从零构建一个推理模型我的建议是别急着直接写Transformer先把基础打牢。先手写多层感知机MLP理解激活函数、权重初始化、反向传播再手写RNN/LSTM理解序列建模的困难最后才上Transformer。Transformer的核心组件有几个Embedding层将token ID映射为稠密向量本质是一个查表操作多头自注意力让每个位置关注序列中其他位置动态加权聚合信息位置编码给模型注入位置信息否则一句“我爱你”和“你爱我”在模型看来完全一样前馈网络FFN对注意力输出做非线性变换LayerNorm和残差连接稳定训练并提升效果我自己用PyTorch写了一个微型Transformer核心就是多头注意力这部分占了不少代码量import torch import torch.nn as nn import torch.nn.functional as F class MultiHeadSelfAttention(nn.Module): def __init__(self, embed_dim, num_heads): super().__init__() self.embed_dim embed_dim self.num_heads num_heads self.head_dim embed_dim // num_heads assert self.head_dim * num_heads embed_dim self.qkv nn.Linear(embed_dim, 3 * embed_dim) self.proj nn.Linear(embed_dim, embed_dim) def forward(self, x, maskNone): B, T, C x.shape qkv self.qkv(x) # (B, T, 3*C) q, k, v qkv.chunk(3, dim-1) q q.view(B, T, self.num_heads, self.head_dim).transpose(1, 2) k k.view(B, T, self.num_heads, self.head_dim).transpose(1, 2) v v.view(B, T, self.num_heads, self.head_dim).transpose(1, 2) attn (q k.transpose(-2, -1)) * (self.head_dim ** -0.5) if mask is not None: attn attn.masked_fill(mask 0, float(-inf)) attn F.softmax(attn, dim-1) out attn v # (B, num_heads, T, head_dim) out out.transpose(1, 2).reshape(B, T, C) return self.proj(out)这段代码看起来很短但梯度、维度、掩码任何一处出错都够你排一个晚上的bug。正因如此我强烈建议大家把注意力矩阵的手工计算过程写一遍甚至用一个很小的序列比如3个词手动推导一次前向的结果再和代码输出对齐这样你才能真正理解什么是“缩放点积注意力”。3.4 训练策略损失函数、优化器、学习率调度训练一个模型代码里最关键的其实就是训练循环。很多人恨不得一次就跑出好效果事实上先定基准、再调优才是正路。小型语言模型的损失函数通常是交叉熵损失。在实际PyTorch里nn.CrossEntropyLoss会自动把模型输出和标签做softmax和交叉熵计算。需要注意模型输出形状一般是(batch_size, seq_len, vocab_size)而标签是(batch_size, seq_len)需要把输出reshape成(batch_size * seq_len, vocab_size)来匹配。优化器方面大模型训练通常用Adam/AdamW。关于学习率经验法则是一个batch_size下的初始学习率从3e-4到1e-3之间开始配合Cosine退火或者线性warmup。Warmup的作用是防止模型在训练早期因梯度太大而不稳定这在大模型上尤其重要。我有一个小工具习惯在每次训练迭代里打印“loss / lr / tokens_per_sec / grad_norm”。梯度范数超过10我就要警惕梯度爆炸loss长时间不降就查数据或模型实现是否有bugtoken速度很低就调整batch size和混合精度。optimizer torch.optim.AdamW(model.parameters(), lr3e-4, weight_decay0.01) scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_maxepochs) for epoch in range(epochs): for batch in train_loader: inputs, targets batch logits model(inputs) loss F.cross_entropy(logits.view(-1, logits.size(-1)), targets.view(-1)) optimizer.zero_grad() loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() scheduler.step() # 记录日志、保存checkpoint……3.5 从“基础语言模型”到“推理模型”的进阶思路热词“build a reasoning model from scratch”之所以让人感兴趣是因为它指向的是大模型领域最前沿的能力推理。但别急着用强化学习先理解推理模型的基本构成。推理模型reasoning model与普通指令模型的核心区别在于它希望在生成最终答案之前产出一长串“思考过程”以此来提升答对复杂问题的概率。怎么让模型学会产出这种思考过程最简单的两个路径是监督微调SFT用大量带有思考链Chain-of-Thought的数据微调模型。这是门槛最低的做法你只需要准备“问题-思考过程-答案”格式的数据集让模型模仿这种输出形式。强化学习RL用奖励信号来引导模型提升正确率比如在数学数据上答案对了给正奖励错了给负奖励。模型在试错中逐步学会“多想想再回答”。我自己在一个小模型上试过第一种路径准备了一万条数学推理数据每条都带详细步骤。效果非常明显模型从只会直接给答案变成会先写“根据题意设x为……”这样一步步推。虽然它的推理能力很初级但机制已经完全跑通。至于第二种路径实现复杂度和训练成本都大很多至少要涉及奖励模型和策略梯度我建议放到第三进阶阶段而且最好在已有基础模型上做。千万不要从随机初始化直接RL那是实验室才有的资源。3.6 模型评估不要只看loss要看真实任务表现训练过程中的loss只是参考指标绝不能作为模型好坏的最终评判标准。以我的经验必须建立一套与业务目标对齐的评估集。一个典型的小语言模型评估维度包括困惑度Perplexity衡量模型对数据的拟合程度越低越好生成质量人工评估或利用GPT-4等给生成结果打分看语义连贯性、主题相关性分类/推理准确率在测试集上跑出可量化的指标陷阱在于Loss降到很低可能只是过拟合了训练数据一遇到新数据就露馅。我在训练一个文本生成模型时训练集perplexity降到15看似漂亮但拿到真实对话场景测试生成的内容空洞、前后矛盾。后来发现是训练数据里重复的套话太多于是扩展了数据多样性效果才真正改善。4. 实操过程与核心环节实现4.1 搭建最小可用的环境工欲善其事必先利其器。我推荐的基础环境是Linux操作系统Ubuntu 22.04 LTSWindows下用WSL2也可以但坑更多Python 3.10PyTorch 2.x自带CUDA支持装的时候注意版本和显卡驱动匹配依赖库transformers、datasets、tiktoken、numpy、pandas、matplotlib、tqdm、wandb可选用于实验追踪至少一块8GB显存的NVIDIA GPU实在没有就用云服务器按小时租跑训练环境搭建就踩过不少坑。最典型的CUDA版本和PyTorch版本不匹配装完PyTorch后发现torch.cuda.is_available()返回False。检查方法很简单python -c import torch; print(torch.__version__, torch.cuda.is_available())如果返回False多半是nvidia-smi里的CUDA Driver和torch要求的CUDA runtime不一致。解决办法是重装对应版本的PyTorch通常pip install torch --index-url https://download.pytorch.org/whl/cu118这种指定CUDA版本的方式最不容易错。风险提示一下很多人为了图省事去搜索引擎找“一键安装包”或者二手教程里的命令最后装了一堆依赖冲突得不偿失尽量用官方文档。4.2 数据准备训练一个“小黄鸡”语言模型为了让大家有更直观的感受我拿一个具体例子说明我的操作过程。目标是训练一个像“小黄鸡”那样风格鲜明的对话模型参数规模控制在1500万以内训练集大约100万条短对话。完整流程如下收集公开的QA语料比如开源的中文对话数据集清洗数据过滤掉非UTF-8字符、表情符号、无意义短句做关键词/内容去重防止同一对话反复出现将数据按8:1:1划分为训练集、验证集、测试集用之前写过的BPE tokenizer训练词表词表大小定为8000到16000之间将文本编码成token序列按固定长度比如128或256切块构建TensorDataset写入DataLoader设置batch_size32num_workers4根据机器配置调整以一个批次为例假设序列长度为128token数量就是32*1284096。如果目标是训练一个1500万参数的模型这批次大小还是可接受的。4.3 训练一个推理模型基础版的完整配置当你已经拥有一个基础语言模型比如上一步训练的“小黄鸡”模型后可以开始尝试向推理模型方向微调。这里是我调试成功的一套配置供参考基础模型参数量约3000万比之前的纯对话模型大一些为推理留足容量监督微调数据集两万条数学题和逻辑推理题每条数据格式固定为“问题... 思考... 答案...”训练策略冻结底层部分参数freeze bottom layers只训练顶层和注意力层这样能节省大量显存并加速训练批次大小batch_size16梯度累积4步等效batch_size64学习率1e-4warmup200步线性衰减训练轮数3到5轮观察验证集loss防过拟合训练核心代码里有一点需要特别提醒mask掉损失函数中的padding部分不要让模型学习“预测padding token”这种无意义任务。做法是这样def compute_loss(logits, targets, ignore_index-100): # targets里padding部分设为-100 return F.cross_entropy(logits.view(-1, logits.size(-1)), targets.view(-1), ignore_indexignore_index)然后构造数据时把padding token的target设为-100。这个小细节如果不注意训练loss会被padding token拉低但模型实际生成效果并不好。4.4 部署和推理优化模型训练完才是开始模型训练完并不代表项目结束。真正工程化的考验在部署阶段。最常见的部署方案方案一用Flask/FastAPI包一个HTTP服务接收输入文本返回模型输出方案二使用vLLM这类推理引擎配合PagedAttention技术吞吐量比原生PyTorch推理提高数倍方案三导出为ONNX格式配合ONNX Runtime提供跨平台推理能力我自己在部署时踩过的一个深坑是tokenizer和模型不匹配。训练时用的tokenizer词表和推理时加载的不一致导致输入文本编码完全错乱生成结果一团糟。解决方式是在保存模型时连同tokenizer文件一并保存上线前做一次“输入-编码-解码-还原”的往返测试。性能方面先量化模型是一个低成本而且效果明显的优化方式。把fp32的权重转成fp16或者int8可以显著降低显存占用和推理延迟。使用PyTorch自带的能力就能操作model model.half() # 转为fp16 model model.eval() with torch.no_grad(): out model(input_ids)不过注意int8量化可能需要torch.quantization的额外配置而且某些层比如LayerNorm不适合量化。盲目量化有时反而让延迟变高实际部署前一定要做基准测试。4.5 性能监控与日志系统一个AI工程如果上线后没有监控等同于开飞机没有仪表盘。我一般会在推理服务里加入以下指标推理延迟p50/p95/p99QPS每秒请求数显存占用和GPU利用率输入输出token数模型生成内容的长度分布开始时用Python写一个简单装饰器加计时器就够了项目变大后再接PrometheusGrafana。千万别小看这一步很多模型刚上线效果还行跑了一周之后因为数据分布漂移或者缓存bug效果骤降没有监控你根本不知道问题出在哪个时间点。5. 常见问题与排查技巧实录5.1 显存不足OOM这是我在训练时遇到最多的问题。一报显存不足很多人第一反应就是把batch_size调小但这是治标不治本。先按这个顺序排查确认是否真的需要那么大的batch梯度累积可以等效增大batch但显存不变检查是否开启混合精度torch.cuda.amp的autocast和GradScaler能把显存占用砍掉近一半检查是否有张量泄漏例如在训练循环里不停保存中间变量如果模型实在太大考虑冻结部分层freeze或使用LoRA这类参数高效微调另外有个实用技巧用torch.cuda.empty_cache()不是必须的但如果你在调试过程中频繁重跑部分代码它会帮你释放碎片显存。注意不要在训练循环里调用它那会显著拖慢速度。5.2 Loss不降或反升遇到loss像心电图一样上蹿下跳或者干脆不降的时候我的排查顺序是先检查数据把一批数据打印出来确认输入标签对齐。最常见的错误是标签整体偏移了一个位置模型永远学不对检查模型初始化用一个小批量数据先跑一次前向和反向确认没有维度错误检查学习率学习率太高会导致loss震荡太低会让人误以为“没有在学”。我先用1e-3快测50步看loss有没有下降趋势再降学习率跑正式训练核对损失公式尤其是多分类任务有没有做softmax、标签的class index是否在词表范围内还有一次模型loss一直不降最后发现我在训练循环里忘了调用optimizer.zero_grad()梯度一直在累加模型直接废了。这种bug特别隐蔽所以必须要有log和定期checkpoint的习惯。5.3 模型生成质量差重复、答非所问训练了很久loss也降得不错但实际生成内容重复率高、质量差这种情况多半出在解码策略。常用的缓解办法温度temperature采样时将temperature设为0.7到1.0之间的值太低会过于保守太高会乱说Top-k采样只从概率最高的k个token里采样k一般取50Top-p采样累积概率超过p的token集合里采样p一般取0.9惩罚重复n-gramno_repeat_ngram_size3可以有效抑制连续重复这些参数没有绝对的标准答案需要根据业务场景调。我在做对话模型时常用的组合是temperature0.85、top_p0.92做摘要时就更保守temperature0.3、top_p0.8。5.4 训练时间过长优化无从下手如果你不是Google不能用“加机器”解决一切问题那就需要从工程角度做优化。我的思路是“先瓶颈后优化”。先用nvidia-smi看GPU利用率如果GPU利用率不到70%说明数据处理是瓶颈要加num_workers、用pin_memoryTrue或者做数据预处理缓存如果GPU利用率很高但训练速度仍然慢就要考虑模型结构优化比如减少注意力层数、减小词表、使用混合精度。另外一个容易忽略的地方小模型不需要用那么多层。我发现有些朋友习惯照搬大模型的结构比如12层Transformer、768维hidden size参数量一下子几千万。但在小数据上训练这只会让模型过拟合。正确的做法是先让模型容量小到能快速迭代等数据增多了再加大模型。5.5 合规提醒关于正版资源和数据集最后我想提一个和“from scratch”相关但容易被忽略的问题资源和数据的合法性。热词里出现“百度云网盘”这类字眼时我强烈建议大家不要碰盗版电子书或数据包。理由很简单盗版资源可能被植入恶意代码这在你的训练环境里运行后果不堪设想使用来源不明的数据集可能存在隐私、版权和伦理风险支持正版才能让优质内容持续产出想深入学习完全可以用合法渠道购买正版书、阅读开源论文和代码库、使用公开的benchmark数据集比如HuggingFace的datasets库里有海量开放数据。做AI工程安全合规的意识和模型精度同样重要切记。6. 实操心得与后续扩展说句掏心窝的话做AI工程久了你会发现“从零开始”不是一种低效率的重复劳动而是一种思维铠甲。我有一次接到一个任务要用一个冷门领域的小数据训练一个效果尚可的模型很多人上来就想用现成大模型API做微调结果发现API不支持这个领域的数据格式还限流。我反而是从数据清洗到小模型训练到部署全部从零撸了一遍最后两周内交付效果比预期还好。这件事给我最大的启发是工程能力不是靠囤积工具得来的而是靠一次次亲手搭链路练出来的。如果你想进一步扩展这个“ai-engineering-from-scratch”项目我有三个推荐方向方向一在已有小模型基础上做多轮对话的RLHF流程感受强化学习对齐的全过程方向二用RAG检索增强生成把外部知识库接入模型解决时效性问题这是当前应用落地的热点方向三研究高效微调技术LoRA、QLoRA这是在单人开发预算下追平实验室效果的最优解。练到这里你已经不是那种“只会调用OpenAI API”的普通开发者了而是真正理解AI系统底层逻辑的工程师。这个项目带来的核心资产不是你跑出来的那个模型而是你脑子里的那套完整方法论。以后不管技术框架怎么变方法论都会跟着你走。