别把“from scratch”理解歪了。它不是让你用某个流行框架三分钟训练一个模型也不是什么“零基础转码 AI 速成”的噱头。在我眼里ai-engineering-from-scratch 就是一句话作为一个工程师你究竟能不能不依赖任何封装把一个 AI 系统从上到下自己亲手拼出来。这个过程中你会写数据管线、写模型结构、写训练循环甚至自己写模型服务和监控脚本——不是因为这些轮子重新造一遍更聪明而是只有从零走一遍那些工程决策背后的“为什么这么设计”才算真正长在你身上。我带过不少想转 AI 方向的同事也面试过很多人。很有意思的一个现象是用着 sklearn、PyTorch 的时候觉得自己什么都会一追问“梯度到底怎么回传”“损失函数为什么这么设计”立刻就卡壳。反过来也有读过不少论文的同学写出来的代码连基本模块划分和异常处理都没有。从一个工程视角看AI 系统根本不是“模型文件 predict 接口”它是一个完整的数据流入、决策输出、效果反馈的软件系统。而 from scratch 这条路径恰好能把整个系统的每一块都暴露在你面前让你没法浑水摸鱼。如果你正处在“会用框架但心里没底”的状态或者你是后端工程师想认真切进 AI 领域这篇文章应该能帮你画出一条还算清晰的地图。我的经验是从零搭建一条最小可用的神经网络训练与部署链路比裸刷三个月论文对实际工程能力的提升要大得多。下面这些内容就是我一路踩坑、复盘之后整理出来的实操记录。1. AI 工程化到底在干什么1.1 它不是调参也不是纯算法研究AI 工程化这个词近几年被各种概念包装搞得有点廉价。有人把网格搜索调参叫工程化有人把调别人训练好的接口叫工程化。说句实在话两个都不算。我看见太多团队做概念验证时跑得飞快但真正上不了线的原因不是模型精度不够而是没有人能回答这几个问题模型在真实业务流程里怎么接入数据分布变了怎么办线上效果突然掉了怎么定位模型更新和回滚怎么做工程化的本质是把“一次性实验”变成“可持续运行、可监控、可演进”的软件系统。这意味着你要处理训练集和线上特征的对齐要保证训练时用的预处理逻辑和推理时用的是同一套要在模型效果变差时及时发现还要做灰度发布和无感回滚。这些事论文里不会写框架的官方教程也不会教你。只有亲手从零搭过一遍每一个环节都会在你手里出问题你才能真正理解它们的重量。打个比方用框架训练模型像在驾校开教练车刹车油门全给调好了从零写一个则像自己组装一台车你才知道每个部件失灵时车会怎么表现。1.2 从零开始学到的是“知识地图”不是零散技巧经常会有人问我“我想学 AI应该先看 PyTorch 还是先补数学”我一般回答先别急着碰框架用 numpy 手写一个简单的网络把数据处理干净训练起来再把它部署成一个接口。整个过程走完你脑海里会自然形成一张知识地图。这张地图有四个主要区域数据侧你会知道批次大小、归一化、特征对齐这些操作到底解决了什么问题模型侧你会明白参数量、激活函数、初始化方式如何共同影响收敛训练侧你会理解学习率、损失函数、反向传播的数学逻辑部署侧你会处理模型序列化、接口设计、监控指标这些生产问题。这四个区域不是孤立的。我举一个最常见的例子你从零手写训练循环的时候会发现如果输入特征的量纲差距太大损失值容易在几步之内变成 NaN。这时候你才会真正理解为什么数据标准化不是“可选的预处理”而是模型能不能收敛的前提。如果只用现成 API你永远不觉得标准化是一个值得关注的问题。知识就是这样自己踩一次比看十次文档都管用。1.3 最适合走这条路的四类人如果你对号入座了这条路对你来说性价比会很高刚转 AI 的软件工程师你有编程基础缺的是对数据、模型、训练过程的直觉。手写一遍是建立直觉最快的方式。被框架保护太久的算法工程师能熟练调包但遇到超出教程范围的报错就一头雾水。从零实现能帮你建立底层判断力。要做 AI 系统设计的架构师你需要知道每个组件的成本和边界在哪技术选型才不会拍脑袋。带 AI 团队的技术管理者你需要真正理解交付卡在哪个环节。很多项目延期不是模型效果问题而是工程链路断裂你没亲手做过就容易被汇报带偏。2. 从零搭建的最小 AI 系统全景2.1 数据环节的工程意义被严重低估很多新手做 AI 项目的第一个动作是打开 notebook 导入数据集然后直接开始写模型。这是个非常典型的错误。数据环节在工程化视角下的重要性至少占整个系统的一半。数据不仅仅是“喂给模型的样本”它还是模型的“行为契约”。你给模型看的数据长什么样模型就只能学会什么样。从工程角度数据环节包含这几件事采集、清洗、特征工程、标准化、划分训练/验证/测试集、批次生成。每一件看起来都很基础但每一件都有大坑。清洗数据不只是去空值和重复值更重要的是发现异常样本和标签噪声。划分数据集不能直接随机切要考虑时间顺序、类别分布和潜在的泄漏问题。特征工程决定了模型学习的上限而模型结构只是在逼近这个上限。批次生成看起来最简单但它直接影响训练稳定性和收敛速度。批次太小梯度震荡剧烈损失曲线像心电图的波形批次太大一个 epoch 的更新次数太少训练时间成倍增加。这就是为什么现成的 DataLoader 那么好用但你还是应该亲手实现一次。只有自己写过你才会理解为什么要有 shuffle为什么要做 padding为什么不同的采样方式会影响验证集的可信度。2.2 模型、损失函数、优化器的三角关系从一个很高的视角看深度学习训练过程就是不断在回答同一个问题怎么让损失函数的值变小模型负责把输入映射到预测值损失函数负责评价预测值和真实值的差距而优化器负责根据这个差距去调整模型参数。这三者之间的关系像是一个人在爬山模型是地形损失函数是当前位置的海拔高度优化器是迈步的方向和步长。从零手写的时候你必须把这三件东西分开考虑。模型架构决定参数空间有多大激活函数的选取影响参数空间的连续性。损失函数不仅要可导还要在数值上稳定否则反向传播的时候梯度很容易变成 NaN。优化器的核心是学习率学习率太高梯度下降会跳过最优点甚至发散学习率太低收敛速度让人怀疑人生。最理想的学习路径是先用最朴素的批量梯度下降在一个小数据集上手动算一次梯度更新的全过程。当你能用笔在白纸上把从损失到每个参数的梯度推导一遍再用代码实现你对“训练”这件事的理解会和只会调用 optimizer.step() 的人完全不同。2.3 训练循环本质上是一个状态机把训练过程拆开来看它不神秘就是一个循环循环里依次执行取一个批次的数据、前向传播计算预测值、计算损失、反向传播计算梯度、更新参数。说得更工程化一点这个循环维护一组状态包括模型权重、当前 epoch、学习率、优化器内部状态和各类评估指标的滑动值。既然是状态机就一定有状态同步和状态恢复的问题。训练到一半崩溃了怎么续跑验证集效果不再提升时怎么早停如何准确记录每次实验的超参数和结果这些都不是算法问题是工程问题。我在从零实现训练循环时会刻意让代码包含挂起和恢复的逻辑定期保存模型权重和优化器状态保存当前 epoch 数保存最优验证指标。这套机制虽然简单但它是生产级训练系统的雏形也是你以后理解分布式训练里 checkpoint 机制的基础。3. 手写一个神经网络完整代码拆解3.1 先把三个数学概念捋清楚在写代码之前有三个数学概念必须亲手推导一遍线性变换、非线性激活、链式法则。线性变换就是矩阵乘法加偏置它是神经网络的基本积木。一个神经元做的事就是拿输入向量点乘权重向量再加一个偏置得到一个标量。多个神经元堆在一起就变成一个矩阵乘。非线性激活函数是神经网络的灵魂。如果没有激活函数不管堆多少层整个网络都等价于一个线性变换那模型就不可能拟合复杂模式。常用的 ReLU 简单高效Sigmoid 适合二分类的输出层。链式法则是反向传播的基石。你要算损失对某个权重的梯度就要从损失开始一层一层往回传播每经过一层就乘上这一层的局部导数。我当年第一次亲手推导的时候发现它其实就是大学微积分里学过的复合函数求导只不过放在计算图上跑了一遍。3.2 一个最小 MLP 的 numpy 实现下面这个实现我刻意不用任何深度学习框架只依赖 numpy。它是一个两层的多层感知机隐藏层用 ReLU输出层用 Sigmoid适合二分类任务。import numpy as np class MLP: def __init__(self, input_dim, hidden_dim, seed42): self.rng np.random.default_rng(seed) # 使用 He 初始化匹配 ReLU 的激活特性 self.W1 self.rng.standard_normal((input_dim, hidden_dim)) * np.sqrt(2.0 / input_dim) self.b1 np.zeros(hidden_dim) # 输出层用较小的初始化避免一开始梯度太激荡 self.W2 self.rng.standard_normal((hidden_dim, 1)) * 0.5 self.b2 0.0 def relu(self, x): return np.maximum(0, x) def sigmoid(self, x): return 1.0 / (1.0 np.exp(-x)) def forward(self, X): self.z1 X self.W1 self.b1 self.a1 self.relu(self.z1) self.z2 self.a1 self.W2 self.b2 self.a2 self.sigmoid(self.z2) return self.a2 def backward(self, X, y, lr): m X.shape[0] # 二分类交叉熵 sigmoid 的梯度简化形式 dz2 self.a2 - y.reshape(-1, 1) dW2 self.a1.T dz2 / m db2 np.sum(dz2, axis0) / m da1 dz2 self.W2.T dz1 da1 * (self.z1 0) dW1 X.T dz1 / m db1 np.sum(dz1, axis0) / m # 参数更新 self.W2 - lr * dW2 self.b2 - lr * db2 self.W1 - lr * dW1 self.b1 - lr * db1这段代码里有几个细节值得注意。第一初始化用了 He 初始化因为 ReLU 在反向传播时会把负半轴的梯度清零如果初始化不当很容易出现神经元死亡。第二dz2 self.a2 - y这个式子看起来简单但它背后是 sigmoid 加上二分类交叉熵损失之后大量中间项刚好对消的结果。你自己完整推导一遍才能真正理解为什么框架实现里这么写。3.3 数据准备与训练循环实现手写训练循环的时候我会把整个流程分成几个清晰的阶段方便定位问题。先生成一个简单的二分类数据集看一眼特征分布再开始训练。from sklearn.datasets import make_moons from sklearn.model_selection import train_test_split # 生成一个非线性可分的数据集 X, y make_moons(n_samples2000, noise0.2, random_state42) X_train, X_val, y_train, y_val train_test_split( X, y, test_size0.2, random_state42 ) # 标准化必须在划分之后只拟合训练集防止数据泄漏 mu X_train.mean(axis0) sigma X_train.std(axis0) 1e-8 X_train (X_train - mu) / sigma X_val (X_val - mu) / sigma def make_batches(X, y, batch_size): n X.shape[0] indices np.random.permutation(n) for start in range(0, n, batch_size): idx indices[start:start batch_size] yield X[idx], y[idx]标准化这块有一个新手特别容易踩的坑均值和方法差必须只用训练集计算然后用同一个参数去转验证集和测试集。如果用全量数据算验证集的信息就已经泄漏到训练过程里了评估结果会虚高。下面是训练循环的本体。我用了比较保守的学习率配合简单的学习率衰减让模型在后期可以更精细地收敛。model MLP(input_dim2, hidden_dim16) epochs 200 batch_size 64 lr 0.5 for epoch in range(epochs): # 学习率衰减前 100 轮用原始学习率之后逐步降低 current_lr lr * max(0.1, 1.0 - epoch / epochs) for X_batch, y_batch in make_batches(X_train, y_train, batch_size): y_pred model.forward(X_batch) model.backward(X_batch, y_batch, current_lr) # 每个 epoch 结束后在验证集上评估 if (epoch 1) % 10 0 or epoch 0: val_pred model.forward(X_val) val_acc ((val_pred 0.5).astype(int).ravel() y_val).mean() train_pred model.forward(X_train) train_loss -np.mean( y_train * np.log(train_pred.ravel() 1e-8) (1 - y_train) * np.log(1 - train_pred.ravel() 1e-8) ) print(fepoch {epoch 1:3d} | val_acc {val_acc:.4f} | train_loss {train_loss:.4f})在train_loss的计算里我加了1e-8这是为了防止log(0)直接推出 NaN。这种数值稳定性的处理在工程上非常常见。模型训练完之后在验证集上通常能跑出 95% 以上的准确率。不要小看这个朴素模型它证明了一个完整的学习闭环数据变换、参数更新、评估反馈每一步你都知道在做什么。3.4 评估与一致性验证模型训完不能直接宣布完事。你要先看训练集和验证集的表现差距判断是否过拟合。然后再测试集上做一次最终评估那才是模型真实水平的估计。对于这个小例子测试集准确率大约在 93% 到 96% 之间浮动是因为数据本身有噪声。还有一件特别重要但经常被忽略的事模型部署之后推理代码必须和训练时的前向传播保持一致。我见过很多线上事故的根源就是训练时用的预处理是 A 流程部署时换成了 B 流程特征对不上模型效果直接崩了。你在 from scratch 阶段养成的习惯——把预处理函数直接绑定到模型对象上——就是应对这类问题最简单的手段。4. 从 notebook 到生产工程化的真正考验4.1 模型序列化与版本管理训练完的模型要能被别人用、别处跑必须解决序列化和版本管理。手写模型的序列化很简单本质上就是保存参数和保存预处理参数两步。import pickle model_data { W1: model.W1, b1: model.b1, W2: model.W2, b2: model.b2, mu: mu, sigma: sigma, hidden_dim: 16, version: mlp-v1 } with open(model.pkl, wb) as f: pickle.dump(model_data, f)参数之外一定要把预处理参数、模型版本和训练配置一起存进去。这样加载模型时就能自动完成特征转换不需要调用方再单独处理一遍。版本号也别省线上模型迭代时靠它做追踪。我一般会在模型文件里额外保存训练日期和验证集指标这样回滚的时候才能快速判断哪个版本是够用的。4.2 把模型包进一个可维护的服务把模型暴露成 HTTP 接口是最朴素的部署方式。工程化思维体现在细节里接口要能返回预测值和置信度遇到异常要返回结构化错误模型预热要在服务启动时完成而不是第一个请求来了现加载。from flask import Flask, request, jsonify import pickle app Flask(__name__) with open(model.pkl, rb) as f: model_data pickle.load(f) class LoadedModel: def __init__(self, data): self.W1 data[W1] self.b1 data[b1] self.W2 data[W2] self.b2 data[b2] self.mu data[mu] self.sigma data[sigma] def predict_prob(self, X): z1 X self.W1 self.b1 a1 np.maximum(0, z1) z2 a1 self.W2 self.b2 return 1.0 / (1.0 np.exp(-z2)) loaded LoadedModel(model_data) app.route(/predict, methods[POST]) def predict(): try: data request.get_json(forceTrue) features np.array(data[features], dtypefloat).reshape(1, -1) features (features - loaded.mu) / loaded.sigma prob loaded.predict_prob(features)[0][0] return jsonify({prob: round(prob, 6), label: int(prob 0.5)}) except Exception as e: return jsonify({error: str(e)}), 400 app.route(/health, methods[GET]) def health(): return jsonify({status: ok, version: model_data[version]}) if __name__ __main__: app.run(host0.0.0.0, port8000, workers1)注意这里的/health端点不是摆设。容器编排和负载均衡都要靠健康检查判断服务是否可用。如果你用的是生产级 Web 框架还需要把/metrics端点加上供监控系统采集数据。这些看起来和模型无关的代码在实际项目里反而决定了系统能不能稳定运行。4.3 监控、日志和漂移检测模型部署上线之后真正的工作才刚刚开始。模型和人一样会老化。线下表现很好的模型上线之后因为输入数据的分布和训练时不一致效果会逐渐变差。这类问题叫数据漂移data drift。监控的最基本要求是三件事记录每个请求的特征、预测值和标签如果之后可以拿到。计算实时准确率和请求量的滚动统计。当监控指标跌破阈值时能够触发告警。另一个容易被忽视的问题是预测置信度的退化。二分类模型的输出很接近 0.5说明它正在遇到自己没见过的情况。如果这类请求比例上升说明线上数据已经开始偏移了。你要把置信度的分布也纳入监控范围而不只是盯着准确率。做一个合格的后端工程师只需要关心服务不宕机但做一个合格的 AI 工程师必须同时关心模型还有没有效。5. 我踩过的坑与排查方法5.1 一套快速定位问题的排查速查表从零手写 AI 系统以来我攒了不少调试经验整理成一张速查表每次遇到问题先按这个顺序排查。现象大概率原因排查动作损失值是 NaN学习率太大、输入含无穷值、log 里出现 0先调小学习率再检查输入是否标准化训练集准确率极低网络容量不足、特征没做好看数据分布看是否有泄漏验证集准确率一直不变梯度消失了或学习率为零检查激活函数和初始化训练损失下降但验证集变差过拟合增加数据量或正则化线上效果与离线相差巨大训练/推理特征处理不一致用同一个预处理函数跑两边数据这张表并不高深但真的能省下大量时间。遇到问题先不要急着改模型结构先用排除法确定问题出在数据、模型还是训练配置上。5.2 三个典型问题的复盘第一个坑是初始化不当导致的“神经元死亡”。有一次我手写网络损失在某个值附近完全不下降。查了很久才发现隐藏层所有 ReLU 的输出全是 0梯度传不回去。原因很简单初始化权重太大大部分输入一进隐藏层就被压到负区间ReLU 直接截断梯度为 0。换成 He 初始化之后问题立刻消失。第二个坑是数据泄漏。我在做标准化的时候手滑用了整个数据集的均值和方差导致验证集准确率虚高到离谱。后来重新划分训练集、单独拟合标准化参数指标回落到正常水平。这个经历让我养成了习惯任何涉及统计量的预处理都必须只放在训练集上拟合。第三个坑更隐蔽发生在训练和推理特征不对齐的时候。我训练阶段对文本做了小写化和去停用词但部署时写接口代码太赶把这步漏了结果线上预测效果稀烂。后来我把所有预处理步骤封装成一个类训练和推理共用同一个类才彻底杜绝这类问题。5.3 五个值得长期坚持的习惯基于这些经历我总结出几个看着普通但非常管用的习惯永远固定随机种子。不只是模型的数据打乱的种子也要固定否则实验结果不可复现。每次实验都记录超参数。哪怕是简单的一句话加时间戳也能让你三个月后复盘时不至于抓瞎。训练中间定期打印损失和验证指标。不要自信到直接跑到最后你会无法定位到底哪一步出了问题。模型文件名带版本号。不带版本号的模型文件早晚会变成一场灾难你一定遇到过覆盖文件的痛。做任何改动前先跑一次基线。没有基线对比你根本判断不了修改是变好还是变坏。结尾随笔这条路的后续还能怎么走走到这里你已经亲手完成了一个最小闭环从数据到模型从训练到部署从监控到排查。这套能力看起来朴素但它其实是大多数“只会调框架”的人不具备的底气。你以后再去学 PyTorch、TensorFlow、或者某个新的推理引擎会发现上手速度快得多因为你理解每一步在底层发生了什么。如果想把这条路继续走下去我个人建议的下一步是把现在的模型扩展到多分类任务然后试着用类似的方法手写一个简单的卷积神经网络在 MNIST 或 CIFAR 上训练一遍。你会发现卷积操作的本质就是“滑动的矩阵乘”池化就是“局部的降采样”它们都没有你想象的那么神秘。之后当你遇到分布式训练、模型量化、自动调参这些进阶话题时你会因为走过基础路径而对问题有更清晰的判断而不是被新概念牵着走。这条路不长但每一步都扎实。希望这份记录能让你少走几个我走过的弯路。