做AI工程的时间越久我越觉得“from scratch”是最被低估的学习路径。你可能写了一年模型但从来没亲手写过“模型”——框架替你包办了前向、反向、优化器、数据采样你要做的只是把层叠起来。听起来很爽可一旦训练的loss变成NaN、梯度死活不更新、换个推理环境就报错很多人就只剩“重启大法”和“上网搜报错”两条路。去年我把一个文本分类项目划成“特批区”PyTorch这类框架保留着但只用于对照实验从数据清洗到词表构建、从自动微分到训练循环、从模型序列化到推理服务核心链路全部自己实现。很多人觉得这是闲得慌可正是这次 ai-engineering-from-scratch 的折腾让我对AI工程里每个环节的“为什么”第一次有了能落地的答案。这篇文章不是教你重新发明TensorFlow也不是让你以后都别用框架。它讲的是一个典型的机器学习项目如果脱掉框架的外壳底层到底长什么样哪些环节最容易失控以及我从零趟完之后回过头来再写框架代码时那种“终于看得懂报错”的感觉。适合已经在用框架但总觉得心里没底的人也适合刚入门、想知道AI工程真实地图的新手。1. 别急着上框架凭什么“从零”是值得的1.1 框架帮你藏起来的全是工程里要命的东西先讲一个真实片段。团队里有个刚来的同学用PyTorch写ResNet很熟练训练验证集划分、Early Stopping都懂。直到有一天他问我为什么把Embedding的维度从64改成128第一个epoch的loss直接从5.2变成了3.8e-7我一看他改维度时顺手把下一层Linear的in_features忘改了结果Embedding的输出被某种广播机制静默“对齐”模型内部根本没有形成一条完整的计算路径——但框架不报错因为矩阵乘法的维度恰好兼容。这种错误框架永远救不了你它只会给你一个看似合理的loss曲线然后让模型学不到任何东西。框架把所有底层操作封装成黑盒高效但代价是你对形状、内存、数据布局的敏感度会直线下降。AI工程不是搭积木更像修水管表面上看是各段接口对接漏水时你得知道水压方向和水流路径。手写一遍底层就是为了把那些“理当如此”的假设全部打掉。1.2 from-scratch的合理边界不是重造轮子这里必须澄清“from scratch”的范围。我并不会建议你从二进制指令开始写那纯属自虐。我划的边界是张量运算用NumPy实现不调用框架的Tensor自动微分自己实现反向传播的计算图模型结构自己写Linear、ReLU、Softmax、交叉熵训练循环自己控制参数更新、梯度清零、Batch采样部署自定义权重格式 自己写推理接口这个边界刚好覆盖“数据→模型→训练→部署”的完整链路。框架只用来做对照实验用PyTorch跑同样结构验证我手写实现的数值是否一致。这等于把官方题的答案放在旁边自己把题目刷一遍最后对答案——效率远高于空想收获大于纯抄。算一笔时间账我用大约三个周末完成了这套从零实现代码总量约两千行。相比直接调框架多花了大概十天但这十天换来的是后续一年里排查各类训练和部署问题的能力。尤其当你遇到“模型在训练集上不收敛”“上线后预测分布漂移”这类问题你脑子里会多一张整条管线地图而不是在黑盒外面瞎猜。从工程思维看这更是值得的。真正的工程能力不是“会调包”而是当系统出问题时你能在多短的时间内把它拆到可分析的边界内。线上延迟高到底是数据预处理慢、模型计算慢还是网络问题手写一遍系统的人会先看每一环节的耗时框架用户则常常只盯着模型推理时间查了半天才发现问题在数据侧每次请求都重复构建词表。这种全局视角正是“AI工程”里“工程”二字的含义。2. 数据管线是自己写的第一段“AI工程”2.1 清洗规则脏数据是项目的头号风险我做的项目是中文文本分类数据来自人工录入和网页抓取。第一件事不是建模而是把数据清洗成一个可靠可复现的流程。我建议任何从零开始的项目都提前写好这几类规则HTML标签、URL、控制字符先删掉全角/半角统一中文标点转英文标点或直接移除去重按“文本哈希标签”双键做避免同一文本同时出现在训练和验证集先看长度分布再决定截断和padding策略写一个极简版本import re def clean_text(raw): text raw.lower() text re.sub(r[^], , text) text re.sub(rhttps?://\S|www\.\S, , text) text re.sub(r[^\w\u4e00-\u9fff\s], , text) text re.sub(r\s, , text) return text.strip()清洗规则看起来是体力活其实藏着一半的工程价值。真实项目的坑往往不是模型选型而是训练集里混入了重复样本、验证集和训练集同源导致指标虚高、线上文本带了清洗规则没处理的HTML实体。这些东西如果不从一开始就建立“清洗→抽样质检→统计分布”的闭环到后面就是一连串改不完的线上问题。2.2 词表与张量化形状错误比算法错误更早爆文本变向量的过程是新手最早接触“形状”这件事的地方。词表构建用Counter统计频次保留出现次数≥2的词汇固定词表上限然后让每个词映射到一个整数ID。这里有个小设计pad放第0位unk放第1位padding天然是0编码函数里用vocab.get(w, vocab[unk])处理未登录词。from collections import Counter def build_vocab(texts, min_freq2, max_size20000): counter Counter() for t in texts: counter.update(t.split()) vocab {pad: 0, unk: 1} for w, c in counter.most_common(max_size - 2): if c min_freq: vocab[w] len(vocab) return vocab def encode(text, vocab, max_len64): ids [vocab.get(w, vocab[unk]) for w in text.split()] ids ids[:max_len] ids [0] * (max_len - len(ids)) return np.array(ids, dtypenp.int64)很多人觉得Padding只是为了让Batch整齐其实它决定了后续所有矩阵乘法的形状边界。你有没有遇到过RuntimeError: size mismatch大部分是padding后的序列长度和Linear层第一维没对齐。手写一遍这步你才会真正理解为什么叫“输入形状”——它不是抽象概念是矩阵的第一维。再提一句广播机制Broadcasting。NumPy里shape为(3,1)的数组和(4,)的数组相加结果是(3,4)从尾部维度开始逐个比较两个维度要么相等、要么其中一个是1为1的那个维度会扩展到对方大小。这个规则能帮你省掉大量显式repeat操作但也容易悄悄改变计算图语义。我在实现Embedding查表后加偏置时就吃过shape是(1,64)还是(64,)的亏结果梯度形状全对但数值全错。从那以后我养成一个习惯每步张量操作后打印data.shape校验期再痛也比训练三天后崩溃强。3. 五百行自动微分治好了我的“框架迷信”3.1 计算图把前向计算变成一张可以回溯的图自动微分是整个手写链路的灵魂。说白了反向传播就是链式法则的工程化实现但工程化的关键是你得记住“每个操作从谁而来”。我实现的Tensor类非常朴素class Tensor: def __init__(self, data, requires_gradFalse): self.data np.asarray(data, dtypenp.float64) self.grad None self.requires_grad requires_grad self._backward lambda: None self._prev () def backward(self): if self.grad is None: self.grad np.ones_like(self.data) topo [] visited set() def build(v): if v not in visited: visited.add(v) for p in v._prev: build(p) topo.append(v) build(self) for v in reversed(topo): v._backward()凡是从两个Tensor计算出来的新Tensor都会把父节点记在_prev里。backward通过深度优先遍历做拓扑排序确保每个节点的_backward执行时它的上游梯度out.grad已经被后续节点算好了。这个思路是工程上的关键图必须无环执行顺序必须是逆拓扑序。3.2 手写反向传播算子add很简单matmul值得想清楚接着实现算子。加法最简单因为d(ab)/da 1直接把上游梯度复制给两个输入。矩阵乘法则要按链式法则展开若out A B记grad_out为上游梯度则grad_A grad_out B.Tgrad_B A.T grad_out。def __add__(self, other): other other if isinstance(other, Tensor) else Tensor(other) out Tensor(self.data other.data) out._prev (self, other) def _backward(): self.grad out.grad other.grad out.grad out._backward _backward return out def __matmul__(self, other): out Tensor(self.data other.data) out._prev (self, other) def _backward(): self.grad out.grad other.data.T other.grad self.data.T out.grad out._backward _backward return out注意grad为什么要而不是当一个节点被多条路径同时依赖时比如同一个输入被用了两次它的梯度是各路径梯度的累加。这个细节如果不手写一遍你很难真正理解为什么框架里的zero_grad()那么重要——因为累积梯度是有意的不清零就会把多个Batch的梯度混在一起。3.3 数值梯度校验手写Backward的“对答案”方法手写了Backward怎么证明它是对的用数值梯度。导数的定义是极限工程上用中心差分近似def numerical_grad(fn, x, eps1e-6): g np.zeros_like(x, dtypenp.float64) it np.nditer(x, flags[multi_index]) while not it.finished: idx it.multi_index old x[idx] x[idx] old eps fp fn(x) x[idx] old - eps fm fn(x) x[idx] old g[idx] (fp - fm) / (2 * eps) it.iternext() return g用(f(xeps)-f(x-eps))/(2*eps)比单侧差分误差小一个数量级。我每次实现完一个新算子都跑一遍np.allclose(my_grad, numerical_grad, atol1e-5)。这能筛掉绝大多数维度写反、转置漏写、符号搞反的错误。而且这个过程本身就在训练你的“调试直觉”梯度不对先怀疑形状、再怀疑矩阵方向、最后才怀疑数学公式。我用这套自动微分实现了一个两层的MLP跑通二分类后再用PyTorch跑同一个模型结构做对比loss曲线几乎重合。那一刻你心里会有一种“值了”的感觉——框架不再神秘它就是你手中这套逻辑的工程完善版。4. 训练循环里的隐形战场损失、学习和正则化4.1 参数初始化一步错步步错很多人直接w np.random.randn(...)就开训然后发现深层网络loss根本不降。原因很简单标准正态初始化在层数一多时连乘会带来方差指数爆炸梯度要么消失要么爆炸。工程上需要按层输入输出维度做缩放也就是Xavier/He初始化。以线性层W为例输入维度fan_in、输出维度fan_outXavier均匀分布的边界是sqrt(6 / (fan_in fan_out))He初始化常用np.random.randn(fan_in, fan_out) * np.sqrt(2 / fan_in)。前者适合tanh、sigmoid这类饱和激活后者更适合ReLU。我在一个很小的MLP上就能明显感觉到差异用错初始化验证准确率永远卡在65%换成He初始化同样的超参数很快就上到97%。这不是玄学是方差传递的数学约束。4.2 学习率和Batch Size的三角矛盾学习率、Batch Size和初始化其实是联动的。梯度下降的更新量是lr * grad而grad的噪声水平随Batch Size变化Batch越大梯度方差越小更新方向越稳定但显存占用越高Batch太小梯度噪声大需要配合更小的学习率或动量。我推荐的起步组合lr1e-3batch_size32或64用Adam优化器。先从这些值开始观察loss曲线的下降速度。loss不降先降低学习率一个数量级再试loss骤降到NaN那大概率是学习率太大、梯度爆炸或数据里有NaN。记住诊断顺序永远是“数据→初始化→学习率→模型结构”别一上来就怀疑模型写错了。还有一件事训练循环里最常写的几行就是model.zero_grad()、loss.backward()、更新参数。这三行很多新手会漏掉zero_grad然后发现loss反复横跳、梯度像滚雪球。手写一遍之后你会形成肌肉记忆之后再也不会犯这种低级错误。for epoch in range(30): epoch_loss 0.0 for x_batch, y_batch in batches: logits model(x_batch) loss softmax_cross_entropy(logits, y_batch) model.zero_grad() loss.backward() for p in model.params(): p.data - lr * p.grad epoch_loss loss.data print(fepoch {epoch}: loss {epoch_loss / len(batches):.4f})4.3 损失曲线怎么读不降、突降、假降背后各是什么训练不收敛先看曲线长什么样loss缓慢下降后进入平台期可能是学习率太小或模型容量不够试着调高学习率或加深网络。前几步就跌到接近0警惕数据泄漏或标注错误更可能是样本顺序本身有规律比如所有正类排在前面。loss变成NaN数值不稳定。softmax里做了log(0)或者梯度爆炸。一个基础但关键的修复是softmax先减掉每行最大值再做exp和归一化交叉熵里给log加上1e-9的epsilon。再说一个很隐蔽的坑模型在训练和推理模式下行为不同。我实现dropout时如果不把这两者区分开验证集指标会极其诡异——推理时把神经元按概率丢弃等于随机让网络“失忆”。这个问题只有在手写dropout的实现后才会真正被刻进脑子里。4.4 过拟合的工程侧判断不要只看训练loss。我习惯每两个epoch算一次验证集loss和准确率如果训练loss一直降、验证loss从某个点开始回升那就是过拟合的明确信号。手写L2正则很简单就是在loss上加上lambda * sum((p ** 2).sum() for p in params)dropout也不复杂前向时以概率keep_prob保留神经元推理时乘以keep_prob保持输出期望不变。这两种手段配合能解决很大一部分过拟合问题。不过比正则化更优先的永远是数据先确认验证集和训练集分布一致再做模型侧的调整。我在这个项目里有一次验证准确率低得出奇排查半天发现是清洗去重时官方给的测试集和训练集在URL层面有重叠。换句话说模型“作弊”都找不到方向。这种数据问题靠调模型是永远调不出来的。5. 最后十公里把模型从Notebook搬到服务里5.1 序列化陷阱Pickle是线上事故的第一来源到了部署环节很多人直接pickle.dump(model, f)一了百了。但Pickle有几个很头疼的问题它绑定Python类定义训练环境里类路径一变线上就加载失败它还能被恶意构造造成反序列化漏洞更常见的是NumPy版本升级后老Pickle文件打不开。既然整条链路都在“from scratch”我干脆自定义了一个权重格式把每个参数的tolist()存成JSON附带一份model_version。加载时重建模型结构再np.array填充参数。这个做法最土但也最稳——跨环境迁移时几乎不踩坑。def save_model(model, path, version): payload { model_version: version, W1: model.W1.tolist(), b1: model.b1.tolist(), W2: model.W2.tolist(), b2: model.b2.tolist(), } with open(path, w, encodingutf-8) as f: json.dump(payload, f)加载时反着来注意把list转回np.array并确认dtype。版本号一定要带上模型文件不带版本号线上出问题你都不知道该回滚到哪一份。这个教训是我用三次线上事故换来的。5.2 一个能扛请求的最小推理服务推理阶段手写的模型已经变成纯NumPy运算部署反而简单。我用FastAPI包了一层HTTP接口三个设计要点请求体用Pydantic做校验字段缺失时自动返回400而不是让异常打到调用方。请求处理和预测分离先解析文本、再编码、再批量预测方便后续加缓存。记录请求延迟和预测分布这是之后做监控的数据基础。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class PredictRequest(BaseModel): text: str class PredictResponse(BaseModel): label: str prob: float app.post(/predict, response_modelPredictResponse) async def predict(req: PredictRequest): ids encode(req.text, vocab, max_len) logits model.predict_batch(np.array([ids])) prob softmax(logits[0]) label label_names[prob.argmax()] return PredictResponse(labellabel, probfloat(prob.max()))上线之前我对着接口打了一轮压测发现NumPy的argmax和softmax在单样本时有个隐藏的reshape开销。优化方式很简单推理时logits[0]直接拿到的是一维向量不要在中间层反复np.expand_dims。每多一次数组复制延迟就多一截。别小看这些细节在线服务对延迟的容忍度往往只有几十毫秒。5.3 日志、指标和回滚的落地配置Notebook里可以没有监控线上不能没有。我最简单的配置是每个请求记一条结构化日志包含时间戳、模型版本、延迟、预测类别、概率。然后用一个后台任务聚合出三个核心指标P95延迟超过阈值就告警说明服务可能被打满或模型变慢。预测分布如果某天某个类别占比突然从30%跳到60%大概率是线上输入分布变了需要重训或回滚。错误率请求超时、反序列化失败、文本编码异常都要单独计数。日志格式建议用keyvalue或JSON后面接监控系统时不用再解析一遍。回滚策略是我个人最强调的一点每次发布新模型权重文件带上版本号接口层的model_version字段同步更新线上做灰度时按比例切流量观察半小时再全量。手写系统最大的优势就在这里——你完全清楚哪里能切、哪里要小心因为每个模块都是自己搭的。6. 从零路线图以及我最想避开的三个坑6.1 五步路线适合工程师的AI底层学习路径如果你看完也想试一把我给一条实测可行的路线NumPy热身花一周熟悉广播、切片、np.sum的axis语义用纯NumPy实现一个线性回归。手写自动微分实现上面的Tensor类和add、matmul、relu、softmax算子用数值梯度校验。手写常用网络MLP→CNN→RNN/注意力每实现一个就用框架跑同结构做数值对照。训练工程化把初始化、学习率调度、正则化、训练/推理模式切换全部纳入自己的训练循环。部署闭环自定义权重格式、写HTTP推理服务、加日志和监控。每步尽量卡两周内完成不要贪多。我自己的经验是前两步带给人的“通透感”最大后面几步则主要回报在工程排错能力上。6.2 我最想避开的三个坑第一个坑是数值稳定性。Softmax里不减max交叉熵里不补epsilon小数据集上可能毫无问题数据一多直接NaN。这不是偶发bug是数学表达不稳定的必然结果。所有概率计算都要写成数值稳定的形式这是习惯问题。第二个坑是模式切换。手写BatchNorm或Dropout时训练与推理的统计量和行为必须分开。我自己实现BatchNorm时一开始在推理时也用了训练集的均值和方差结果验证指标虚高上线就崩——线上的单条样本不该用训练集统计量做归一化。现在我会在代码里明确区分is_training分支并在测试用例里覆盖两种情况。第三个坑是盲目自信评估指标。手写项目没有框架自带的DataLoader封装自己切分数据时很容易让验证集和训练集产生重叠。我最后悔的一次是把同一来源的数条相似文本同时切进两边导致验证准确率长期虚高发现不了。现在所有数据集都做ID级别的去重并且固定随机种子保证切分可复现。6.3 最后的体会写完这两千行之后我再次用回框架最大的变化不是速度变快而是“敢看报错了”。以前一个size mismatch我要搜半天现在能自己推出来是哪一层、哪个维度、为什么。AI工程这条路没有捷径但“从零写一遍”可能是最省时间的捷径——它把黑盒变白盒把“会调库”变成“懂系统”。如果你也在用框架的过程中感到心里没底我给的建议就一句话挑个小项目动手把底层写一遍你会回来感谢自己的。