1. 为什么从零手搓AI工程比调包更值得投入第一次看到ai-engineering-from-scratch这个项目名的时候我脑子里蹦出来的不是又一个教程仓库而是三年前自己踩过的一个坑。当时团队要做一个文本分类服务我图省事直接上了某个高层封装库三行代码跑通Demo演示效果炸裂。结果上线第二周推理延迟从80ms飙到1.2s日志里全是内存告警我盯着那三行代码完全不知道从哪下手——因为中间发生了什么我根本不清楚。这就是调包侠的典型困境你能让模型跑起来但你不知道它为什么能跑更不知道它什么时候会跑不动。ai-engineering-from-scratch这类项目的核心价值恰恰在于把那些被封装库藏起来的中间层全部摊开让你亲手摸一遍从原始数据到可用服务的每一环。需要先说清楚这个项目名里的from scratch不是让你从晶体管开始造芯片也不是让你手写CUDA内核。它的合理边界是不依赖高层训练框架的自动魔法用尽可能基础的组件把AI工程链路搭起来。具体来说它覆盖的是这样一条链路——数据进来怎么清洗和切分、张量怎么表示和运算、模型的前向和反向怎么手动推导、训练循环怎么控制、推理服务怎么部署和压测。这条链路上的每一环都是真实工作中出问题时你最需要定位的地方。适合读这篇内容的人有三类。第一类是刚学完机器学习理论、但一写工程代码就懵的学生你懂梯度下降的公式但不知道一个batch的数据在内存里到底长什么样。第二类是用惯了高层框架、想补底层认知的工程师你能训模型但遇到OOM、梯度爆炸、推理慢这些问题只能靠搜索引擎碰运气。第三类是想做技术深度沉淀的从业者你意识到只会调API的竞争力在快速贬值需要建立一套从原理到落地的完整认知。我个人的判断是AI工程能力的分水岭不在于你会不会用某个框架而在于框架出问题时你能不能自己造一个替代方案。这个项目就是训练这种能力的。下面我会把这条链路拆成几个关键环节每个环节都讲清楚为什么这么做和实际怎么做中间穿插我自己踩过的坑。2. 数据管道从原始文本到模型能吃的张量2.1 为什么数据管道是AI工程最容易被低估的部分很多人以为AI工程的核心是模型结构实际上在真实项目里数据管道占据的工程量和出问题的概率远超模型本身。我做过一个统计在一个中等规模的NLP项目里数据相关的代码行数通常是模型代码的3到5倍而线上事故里超过一半能追溯到数据处理环节。ai-engineering-from-scratch这类项目如果只教你搭模型那是不完整的。真正的从零开始第一步是把一堆乱七八糟的原始数据变成模型能消费的规整张量。这个过程包含几个必须手动处理的步骤读取、清洗、分词、构建词表、数值化、填充对齐、批处理。每一步都有坑。2.2 分词与词表构建那些封装库帮你藏起来的决策用高层库的时候你调一个tokenizer.fit_on_texts()就完事了。但手动实现时你必须回答几个问题按词切还是按字符切词表大小设多少低频词怎么处理未知词用什么符号表示按词切分适合英文这类有天然空格分隔的语言但会遇到词形变化问题——run、running、ran被当成三个不同的词。按字符切分词表小、不会遇到未知词但序列会变得很长模型学起来更吃力。实际工程里更常见的是子词切分subword但子词算法本身实现起来有复杂度从零项目里通常会先用词级切分把流程跑通再考虑升级。词表大小的选择是个权衡。词表太小大量词被映射成未知符号信息损失严重词表太大嵌入矩阵膨胀参数量暴涨而且低频词学不好。我的经验值是中小规模任务词表控制在1万到3万之间比较稳具体要看语料规模和任务复杂度。构建词表时通常保留频率最高的N个词其余归入未知符号。from collections import Counter def build_vocab(texts, max_size20000, min_freq2): counter Counter() for text in texts: counter.update(text.split()) # 特殊符号占位 vocab {pad: 0, unk: 1} for word, freq in counter.most_common(max_size - 2): if freq min_freq: vocab[word] len(vocab) return vocab这段代码看着简单但min_freq这个参数很关键。设成1的话只出现一次的词也会进词表词表被噪声撑大设太高又会把一些有意义的低频词丢掉。我一般先用2试看未知词比例如果超过5%就降到1。2.3 填充对齐与批处理padding的隐藏成本变长序列要组成batch必须填充到同一长度。这里有个反直觉的点填充到整个数据集的最大长度是极其浪费的。如果大部分句子长度在20左右但有一句话长200那你每个batch都在为那一个异常样本付出10倍的计算代价。正确做法是按batch内最大长度填充而不是全局最大长度。更进一步可以按长度分桶bucketing把长度相近的样本放一个batch这样填充浪费最小。这个优化在从零实现时值得做因为它直接决定训练速度。def pad_batch(sequences, pad_id0): max_len max(len(s) for s in sequences) padded [s [pad_id] * (max_len - len(s)) for s in sequences] return padded注意填充符号的ID一定要和真实词的ID区分开而且计算损失时要通过mask把填充位置排除掉否则模型会去学预测填充符号白白浪费容量。2.4 数据管道实操中我踩过的坑第一个坑是词表在训练集上构建但推理时遇到训练集没见过的词。这个必须靠未知符号兜底同时推理时的分词逻辑必须和训练时完全一致否则会出现同一个词在两边被切成不同形式的情况。我见过有人训练时用小写化、推理时忘了导致效果断崖式下跌。第二个坑是数据泄露。构建词表、计算归一化参数这些操作只能用训练集的数据不能用验证集和测试集。我早期做项目时图省事在全量数据上建词表结果验证集指标虚高上线后打回原形。这个坑很隐蔽因为代码能跑通指标也好看问题要到线上才暴露。第三个坑是批处理的随机性控制。训练时打乱顺序是必要的但验证和测试时不要打乱否则你没法复现结果。而且打乱的随机种子要固定不然每次跑出来的曲线都对不上。3. 张量运算与自动求导把黑盒拆成可验证的零件3.1 为什么必须理解张量运算的底层逻辑高层框架里a b就是矩阵乘法你不需要知道它怎么算的。但当你的模型出现维度不匹配、梯度为NaN、显存爆炸这些问题时理解张量的形状语义和运算规则就是救命稻草。从零实现AI工程张量这一层是绕不开的。你至少要手动实现张量的创建和形状管理、基础运算加减乘除、矩阵乘、广播机制、以及最关键的自动求导。自动求导是深度学习的发动机理解它你才能理解为什么有些操作会断开梯度、为什么有些层需要特殊初始化。3.2 计算图与反向传播的手动实现思路自动求导的核心是计算图每个张量运算都是一个节点节点记录自己的输入和如何计算梯度。前向传播时构建图反向传播时沿图反向应用链式法则。手动实现时通常给每个张量加两个属性requires_grad标记是否需要梯度grad存梯度值。每个运算函数除了返回结果还要注册一个反向函数。class Tensor: def __init__(self, data, requires_gradFalse): self.data data self.requires_grad requires_grad self.grad None self._backward lambda: None self._prev set() def __matmul__(self, other): out Tensor(self.data other.data, self.requires_grad or other.requires_grad) def _backward(): if self.requires_grad: self.grad out.grad other.data.T if other.requires_grad: other.grad self.data.T out.grad out._backward _backward out._prev {self, other} return out这段代码是简化版真实实现要考虑广播、累积梯度、拓扑排序等问题。但核心思想就在这里每个运算都知道自己的局部梯度怎么算反向传播就是把它们串起来。3.3 梯度消失与爆炸从零实现才能看清的真相用高层框架时梯度消失和爆炸是个抽象概念。手动实现后你会发现它就是连乘效应反向传播时梯度要一层层乘过去如果每层的局部梯度都小于1乘几十次就趋近于0都大于1乘几十次就爆炸成无穷。理解了这一点你就能理解为什么需要这些技巧权重初始化用Xavier或He是为了让每层输出的方差保持稳定残差连接是为了给梯度提供一条高速公路绕过连乘梯度裁剪是在爆炸发生时强行把梯度拉回合理范围层归一化是让每层的输入分布稳定。def clip_gradients(tensors, max_norm1.0): total_norm sum((t.grad ** 2).sum() for t in tensors if t.grad is not None) ** 0.5 if total_norm max_norm: scale max_norm / (total_norm 1e-6) for t in tensors: if t.grad is not None: t.grad * scale提示梯度裁剪的阈值不是越大越好。设太大等于没裁设太小会拖慢收敛。我一般从1.0开始试观察梯度范数的实际分布再调整。3.4 数值稳定性那些让loss变NaN的隐形杀手从零实现时NaN是最常见的报错。来源通常有几个除零、log(0)、exp溢出。比如交叉熵损失里有个log如果预测概率是0log就炸了。解决方案是在log里加一个极小值或者用log-sum-exp技巧把计算重排。softmax是另一个重灾区。直接算exp(x) / sum(exp(x))当x很大时exp会溢出。标准做法是先减去最大值exp(x - max(x)) / sum(exp(x - max(x)))数学上等价但数值上稳定得多。这些技巧在高层框架里被自动处理了从零实现时你必须自己想到。4. 训练循环控制收敛的每一个旋钮4.1 训练循环的骨架与每个组件的职责一个完整的训练循环包含前向传播、计算损失、反向传播、更新参数、清零梯度。这五步的顺序不能乱尤其是清零梯度必须在更新之后、下一次前向之前。我见过新手把清零放在反向之前导致梯度累积出错训练完全不收敛。for epoch in range(num_epochs): for batch in dataloader: inputs, targets batch outputs model(inputs) loss criterion(outputs, targets) loss.backward() optimizer.step() optimizer.zero_grad()这个骨架简单但每个环节都有讲究。损失函数的选择要和任务匹配优化器的学习率要调batch size影响梯度估计的方差。从零实现的好处是这些旋钮全部暴露在你面前你必须理解每个旋钮的作用。4.2 学习率调度为什么固定学习率往往不是最优固定学习率的问题是训练初期需要大学习率快速下降训练后期需要小学习率精细收敛。一个折中方案是学习率衰减常见的有阶梯衰减、余弦退火、指数衰减。余弦退火是我用得比较多的它让学习率按余弦曲线从初始值平滑降到接近0训练后期收敛很稳。还有warmup在训练最开始用很小的学习率逐步升上去避免初期梯度方向不准导致震荡。这两个组合起来warmup cosine decay是很多现代模型的标配。def cosine_schedule(step, warmup_steps, total_steps, base_lr): if step warmup_steps: return base_lr * step / warmup_steps progress (step - warmup_steps) / (total_steps - warmup_steps) return base_lr * 0.5 * (1 math.cos(math.pi * progress))4.3 过拟合与欠拟合的现场诊断训练过程中你要盯着训练损失和验证损失两条曲线。训练损失降但验证损失升是过拟合两条都降不下去是欠拟合。这两种情况的处理方向完全相反。过拟合了加正则化L2、dropout、减模型容量、加数据。欠拟合了加模型容量、减正则化、检查数据质量。从零实现时你可以精确控制每个正则化项加在哪、强度多少而不是像调包那样只能改一个参数。我踩过的一个坑是dropout在训练和推理时的行为不一致。训练时按概率丢弃神经元推理时要用全部神经元但输出要按保留概率缩放。如果忘了缩放推理结果会系统性偏大。这个细节在高层框架里是自动的从零实现时特别容易漏。4.4 检查点与实验管理别让一次崩溃毁掉三天训练从零实现训练循环时一定要加检查点保存。我吃过亏一个模型训了三天机器突然重启全没了。后来我养成习惯每个epoch结束存一次同时保留验证指标最好的那个版本。检查点要存的不只是模型参数还有优化器状态动量、二阶矩这些、当前epoch、学习率调度器的状态。只存模型参数的话恢复训练时优化器状态丢失收敛曲线会跳变。def save_checkpoint(path, model, optimizer, epoch, best_metric): torch.save({ model: model.state_dict(), optimizer: optimizer.state_dict(), epoch: epoch, best_metric: best_metric, }, path)注意实验管理不是大公司的专利。哪怕你一个人做项目也应该记录每次实验的配置和结果。我用一个简单的CSV文件记录超参数和对应指标回头对比时能省大量时间。5. 推理部署从训练脚本到能扛住请求的服务5.1 训练和推理的本质差异训练时你关心的是梯度能不能算、损失降不降。推理时你关心的是延迟、吞吐、内存占用。这两个场景的优化目标完全不同所以训练代码不能直接拿来当服务用。最典型的差异是训练时用dropout和batch norm的训练模式推理时要切到评估模式。训练时batch size可以很大推理时请求是逐个来的batch size可能是1。训练时不需要考虑并发推理时要处理多个请求同时进来。5.2 模型导出与推理优化从零实现的项目里模型导出通常就是把参数存下来推理时重新构建结构再加载。但真实部署时你可能需要把模型转成更高效的格式或者做量化压缩。量化的核心思想是用更低的精度表示参数比如从32位浮点降到8位整数。这样模型体积缩小4倍推理速度提升代价是精度略有下降。对于很多任务这个精度损失是可以接受的。从零理解量化你要知道它是怎么把浮点范围映射到整数范围的以及反量化时怎么还原。def quantize(tensor, num_bits8): qmin, qmax 0, 2 ** num_bits - 1 min_val, max_val tensor.min(), tensor.max() scale (max_val - min_val) / (qmax - qmin) zero_point qmin - min_val / scale q_tensor ((tensor / scale) zero_point).round().clamp(qmin, qmax) return q_tensor, scale, zero_point5.3 服务化把模型包成一个能用的接口一个最小可用的推理服务至少要有加载模型、接收请求、预处理输入、前向推理、后处理输出、返回结果。用Python的话Flask或FastAPI都能快速搭起来。from fastapi import FastAPI app FastAPI() model load_model(checkpoint.pt) app.post(/predict) def predict(text: str): tokens tokenize(text) tensor to_tensor(tokens) with torch.no_grad(): logits model(tensor) return {label: decode(logits)}这里torch.no_grad()很关键它告诉框架不要构建计算图能省大量内存和时间。推理时不需要梯度忘了加这个上下文管理器是新手常见错误。5.4 压测与性能瓶颈定位服务搭起来不算完你得知道它能扛多少请求。压测就是模拟并发请求观察延迟和吞吐的变化。我一般用locust或wrk这类工具从低并发逐步加压找到延迟开始飙升的拐点。瓶颈通常出现在几个地方预处理分词、数值化如果是纯Python实现往往比模型推理还慢模型前向如果是单条处理GPU利用率极低后处理如果涉及复杂逻辑也会拖后腿。定位方法是分段计时看时间花在哪。提示推理服务的预处理逻辑要和训练时严格一致但实现上可以针对性能优化。比如训练时用通用分词器推理时可以用更快的实现只要输出结果一致就行。6. 从零项目到真实工作的能力迁移6.1 什么时候该从零造什么时候该用现成的这是最实际的问题。我的判断标准是核心业务逻辑和性能瓶颈相关的部分值得从零理解甚至自己实现边缘的、成熟的、非差异化的部分直接用现成的。比如数据加载你不需要自己写多进程读取用框架自带的DataLoader就行。但损失函数如果和业务强相关你就得自己实现并理解每个细节。模型结构如果是标准Transformer用现成实现没问题但你要能读懂它的每一行出问题时能改。从零项目的训练价值不在于让你以后什么都自己写而在于让你具备随时可以自己写的能力和判断力。当现成方案不满足需求时你知道从哪下手当现成方案出问题时你知道去哪找原因。6.2 面试与晋升中的底层能力体现我参与过不少技术面试一个明显的感受是能讲清楚底层原理的候选人和只会讲框架用法的候选人评价差距很大。前者遇到没见过的场景能推理出方案后者只能套用已知的模式。比如问模型推理慢怎么优化只会调包的人会说换更快的框架理解底层的人会先问瓶颈在哪然后从预处理、批处理、量化、算子融合等角度给出有层次的方案。这种差异在晋升答辩时更明显因为高级别要求你能做技术决策而决策的前提是理解每个选项的代价。6.3 持续迭代从零项目之后该往哪走把一条完整的链路从零跑通之后下一步有几个方向。一是深入性能优化学CUDA编程、算子融合、分布式训练把单机单卡的效率榨干。二是扩展规模学多机多卡、数据并行、模型并行处理更大的模型和数据。三是深入特定领域比如计算机视觉、自然语言处理、推荐系统把通用能力落到具体场景。我个人的路径是先跑通全链路建立全局观再选一个方向深挖。全局观很重要因为它让你知道自己的优化在整个系统里处于什么位置值不值得投入。很多人一上来就钻某个细节结果优化了半天发现这个环节根本不是瓶颈。6.4 我在这条路上踩过的几个典型坑第一个坑是过早优化。刚跑通流程就想着上分布式、上混合精度结果基础逻辑还有bug调优调了个寂寞。正确顺序是先保证正确性再优化性能。第二个坑是忽视可复现性。随机种子没固定、依赖版本没锁、数据版本没记录导致实验结果对不上。后来我强制自己每次实验都记录完整配置这个习惯救了我很多次。第三个坑是只关注模型不关注数据。花大量时间调模型结构结果发现数据里有大量标注错误清洗数据后效果直接提升一大截。数据和模型哪个重要取决于哪个更烂而大多数时候数据更烂。第四个坑是把训练指标当终点。离线指标好不代表线上效果好分布偏移、延迟要求、成本约束这些工程因素往往比模型本身更能决定项目成败。从零项目教的是技术但真实工作里技术只是拼图的一块。把ai-engineering-from-scratch这条链路走一遍最大的收获不是某个具体技能而是一种**我知道这东西是怎么转起来的的底气**。这种底气让你在面对新框架、新问题时能快速定位到它属于链路的哪一环以及那一环的常见陷阱是什么。这比会用一个具体工具值钱得多。