从来没想过一个“from scratch”的项目标题会在接下来的半年里把我按在地上反复摩擦又让我像拼乐高一样把AI的世界从头到尾搭了个遍。这个仓库叫ai-engineering-from-scratch说白了就是从零开始搞AI工程。不是让你调个库、跑个demo就完事儿而是把AI应用从想法到落地过程中涉及的每一个环节——数据、模型、训练、评估、部署、监控——全都亲手过一遍。它的核心价值在于不依赖现成的AI平台黑盒而是自己动手理解每一层的工作原理最终能独立设计并交付一套AI解决方案。这篇文章就是来复盘这个过程中我踩过的坑、悟出的理以及一条可以复现的实操路径。不管是刚入门想建立完整AI工程认知的开发者还是被各种AI框架搞得一头雾水的学习者都能从中找到你想要的东西。老实说刚开始我差点被“from scratch”劝退但走完一遍才发现知道系统怎么从头长出来的人和只知道用现成组件拼装的人面对同一个需求时的底气和思路是完全不一样的。1. 内容整体设计与思路拆解1.1 为什么非要“从零”开始市面上有太多AI速成课教你两小时跑通一个图像分类或者一天部署一个ChatBot。这当然很爽但有个致命问题一旦环境变量变了模型报错了或者需求稍微偏离了教程路线你就卡住了因为你只学会了操作没理解原理。“from scratch”的思路恰恰相反。它不追求“最快出结果”而是追求“每一步都透”。就像学做饭别人教你用预制菜包五分钟端上一盘鱼香肉丝而这个项目教你从杀鱼、切配、调汁开始一步步来。虽然慢但做完这道菜之后任何川菜你都能上手因为底层逻辑通了。具体到AI工程所谓“from scratch”包含几个层面不依赖AutoML手动完成特征工程、模型选择、超参数调优。不依赖现成框架的高级封装尽量理解并亲手实现训练循环、评估逻辑、数据流水线。不依赖云平台锁定本地也能跑通部署方案也有通用的替代路径。这种做法的直接好处是你建立的是“可迁移的能力”而不是“特定平台的操作记忆”。比如TensorFlow和PyTorch再怎么更新底层反向传播和梯度下降的逻辑是永恒的你从底层理解了换什么框架都是语法层面的适应。1.2 项目整体架构与学习路径设计整个项目我分成了八个阶段各个阶段之间的依赖关系很清晰一定要按顺序来跳步必吃亏。Python工程化基础不只是语法而是模块化设计、类型注解、单元测试、虚拟环境管理。这是所有上层建筑的底座。数据工程核心从数据采集、清洗、标注到特征工程和数据版本管理。要建立“数据是AI项目的地基”这个意识。机器学习基础算法实现不直接调sklearn而是用NumPy纯手写线性回归、逻辑回归、决策树。理解损失函数、梯度下降、过拟合的本质。深度学习原理拆解动手实现一个两层的MLP多层感知机理解反向传播的每一个矩阵运算。这是理解一切复杂模型的关键。模型评估与调优体系学习交叉验证、学习曲线、混淆矩阵、PR曲线、ROC曲线建立一套科学的模型迭代方法论。模型部署实战把训练好的模型封装成RESTful API用Docker打包并部署到服务器。理解线上环境和训练环境的差异。模型监控与持续迭代设计数据漂移检测、模型性能监控、日志记录体系形成AI系统的闭环。端到端项目实战将前面所有能力串联起来从业务问题抽象、数据采集到模型上线完成一个完整体量的项目。这套路径设计的精妙之处在于它把“AI”从一个模糊的概念拆解成了一个个可以被验证的技能点。每个阶段都有明确的产出物卡在哪一步就能精准定位你的弱点在哪。2. 核心细节解析与实操要点2.1 环境与工具链的真正含义网上很多教程把环境配置一笔带过但实际工程中环境问题占到了排障时间的30%以上。一开始我直接用全局Python环境结果装PyTorch和CUDA的时候依赖冲突直接把系统搞崩了。后来才老老实实用以下组合Python版本管理用pyenv多版本共存项目各自独立。虚拟环境每个项目用venv或者poetry精确锁死依赖版本。Docker容器所有代码最终跑在容器里环境彻底固化在服务器和本机之间无缝切换。这一套组合拳打下来我的“环境恐惧症”基本消失了。很多初学者觉得这是浪费时间实际上这是在为未来的无数小时节省时间。工程化的第一步就是让你的环境可复制、可重现。2.2 数据策略比模型策略更重要我花了大半个月在这个阶段是真真正正的大半个月。因为在这个项目里90%的数据都是我来编的模拟的各种场景数据。这逼着我去思考一个根本问题什么样的数据才能训练出一个能泛化的模型关键认知有三条数据质量大于数据数量五千条干净、分布合理的数据胜过于五万条噪声大、分布偏斜的数据。特征工程是人与业务的对齐你不是在造特征你是在把你对这个行业的理解编码成模型能懂的数学语言。数据版本必须管理我吃过一次大亏改了一版数据清洗逻辑之后模型效果“变好”了。后来才发现是数据发生了泄漏。没有版本管理你根本不知道模型究竟学的是模式还是bug。我强烈建议所有人在做算法之前先花时间把数据分布可视化出来。看直方图、散点图、相关性矩阵。这个习惯能让你规避掉非常多“捏着鼻子训练”的场景。2.3 从零手写算法的顿悟时刻用NumPy实现线性回归和逻辑回归是我整个项目里“啊哈”时刻最密集的阶段。当你自己写出y sigmoid(X w b)然后手动写出交叉熵损失再手动推导出梯度突然之间构建模型的神秘感就消失了。之前调sklearn就像开一辆自动挡的车虽然能走但你对发动机内部的工作原理毫无概念。手写模型就像手动挡。刚开始手忙脚乱但一旦熟练你能精确感知到每一个数据点对参数更新的影响。这个阶段一个非常重要的操作是梯度检查。通过数值方法近似计算梯度与解析求导的结果对比一旦误差小于某个阈值就能确认你手写的反向传播是正确的。这一步能防止你在疯狂Debug中迷失自我。我踩过的坑是忽略矩阵的维度匹配。反向传播里的(n, m)和(m, k)一旦对不上报错还是轻的更怕的是能运行但结果是错的。2.4 逐步摆脱黑盒的深度学习从纯手写MLP到使用PyTorch框架中间的过渡要自然。我见到太多人直接跳进PyTorch结果连backward()里发生了什么都不知道。所以在用PyTorch之前我坚持只用手动实现梯度的方式训练了一个两层神经网络。当时死死地盯着损失曲线从0.9往下降第一次真切感受到了“学习”的过程。这一刻你才能真正理解什么是梯度下降什么是权重更新。之后接触PyTorch看到loss.backward()时就知道它背后究竟做了哪些事逐层计算偏导数、链式法则、缓存中间激活值。这个认知特别重要因为当你未来设计自定义损失函数、自定义层的时候你需要对这部分有极强的掌控感否则会在自定义网络的调试中彻底迷失。3. 实操过程与核心环节实现3.1 基础算法训练营NumPy实现线性回归这部分是整条链路的基石我以一个非常经典的“房价预测”为例展示一下核心步骤。第一步生成模拟数据import numpy as np np.random.seed(42) X np.random.rand(100, 1) * 10 # 面积平方米0-10 true_w 2.5 true_b 1.2 y true_w * X.squeeze() true_b np.random.randn(100) * 0.5 # 划分训练集和验证集 train_idx np.random.choice(100, 80, replaceFalse) val_idx np.array([i for i in range(100) if i not in train_idx]) X_train, y_train X[train_idx], y[train_idx] X_val, y_val X[val_idx], y[val_idx]这里关键在于模拟数据时要加入噪声否则模型会过拟合到完全线性的分布上。真实世界的数据永远带噪声。这也是对后续模型泛化能力的最初检验。第二步初始化参数并实现前向/反向传播w np.random.randn(1) b np.zeros(1) learning_rate 0.01 def forward(x, w, b): return x * w b def loss(y_pred, y_true): return np.mean((y_pred - y_true) ** 2) def backward(x, y_pred, y_true): grad_y_pred 2.0 * (y_pred - y_true) / len(y_true) grad_w np.dot(x.squeeze(), grad_y_pred) grad_b np.sum(grad_y_pred) return grad_w, grad_b epochs 1000 for epoch in range(epochs): y_pred forward(X_train, w, b) l loss(y_pred, y_train) grad_w, grad_b backward(X_train, y_pred, y_train) w - learning_rate * grad_w b - learning_rate * grad_b if epoch % 100 0: print(fEpoch {epoch}, Loss: {l:.4f}, w: {w[0]:.4f}, b: {b[0]:.4f})提示学习率的选择是关键。设置成0.1试试你会发现损失直接变成NaN。原因是步长太大参数在最优解附近来回震荡甚至发散。这就是“深度学习训练不收敛”的原始版本。第三步验证模型并绘制学习曲线在验证集上计算RMSE均方根误差并画出真实值与预测值的散点图。观察拟合效果同时绘制损失曲线查看收敛情况。一个健壮的训练过程是损失平滑下降并趋于平稳如果损失曲线出现剧烈震荡第一时间检查学习率。3.2 深度学习进阶手动实现两层神经网络线性回归是热身实现一个带隐藏层的MLP多层感知机才是分水岭。网络结构定义输入层2个神经元隐藏层4个神经元ReLU激活输出层1个神经元Sigmoid激活二分类任务。前向传播def relu(z): return np.maximum(0, z) def sigmoid(z): return 1 / (1 np.exp(-z)) def forward(x, W1, b1, W2, b2): z1 np.dot(x, W1) b1 # (batch, 2) (2, 4) - (batch, 4) a1 relu(z1) z2 np.dot(a1, W2) b2 # (batch, 4) (4, 1) - (batch, 1) a2 sigmoid(z2) return z1, a1, z2, a2反向传播这段代码是整个项目的重头戏def backward(x, y, z1, a1, z2, a2, W2): m x.shape[0] grad_a2 a2 - y.reshape(-1, 1) # 输出层梯度 grad_W2 np.dot(a1.T, grad_a2) / m grad_b2 np.sum(grad_a2, axis0, keepdimsTrue) / m grad_a1 np.dot(grad_a2, W2.T) * (z1 0) # ReLU反向传播 grad_W1 np.dot(x.T, grad_a1) / m grad_b1 np.sum(grad_a1, axis0, keepdimsTrue) / m return grad_W1, grad_b1, grad_W2, grad_b2这里最关键也最容易出错的地方就是(z1 0)这个ReLU的掩码。它保证了只有被激活的神经元才能接收梯度。如果在反向传播时忘了这一层梯度信号就会穿过死亡的神经元导致训练极不稳定。我在这里卡了很久最后是通过梯度检查定位到的。梯度检查的代码实现def gradient_check(x, y, W1, b1, W2, b2): eps 1e-7 # 以W1[0,0]为例 W1_copy W1.copy() W1_copy[0, 0] eps _, _, _, a2_plus forward(x, W1_copy, b1, W2, b2) loss_plus binary_cross_entropy(a2_plus, y) W1_copy[0, 0] - 2 * eps _, _, _, a2_minus forward(x, W1_copy, b1, W2, b2) loss_minus binary_cross_entropy(a2_minus, y) numeric_grad (loss_plus - loss_minus) / (2 * eps) analytic_grad backward(x, y, None, None, None, None, W2)[0][0, 0] print(fNumerical: {numeric_grad:.6f}, Analytical: {analytic_grad:.6f})实时保证解析梯度和数值梯度误差在1e-5量级以内。一旦偏差过大不要继续训练先把反向传播的Bug找出来再说。没有这步检查你极有可能训练出一个看似收敛、实则只是碰巧的模型。3.3 部署模型从笔记本走向生产模型训练只是第一步工程化的核心环节在部署。在这个项目里我产出了一个轻量化但完整的部署方案。保存模型参数如果你用纯NumPy实现的模型推荐使用np.savez保存权重或者直接保存为JSON如果模型很小。对于PyTorch模型使用torch.save(model.state_dict(), model.pth)。用Flask/RESTful封装from flask import Flask, request, jsonify import numpy as np app Flask(__name__) # 加载模型参数假设是NumPy版本 params np.load(model.npz) w params[w] b params[b] app.route(/predict, methods[POST]) def predict(): data request.get_json() x_input np.array(data[features]).reshape(-1, 1) y_pred x_input * w b return jsonify({prediction: y_pred.tolist()}) if __name__ __main__: app.run(host0.0.0.0, port5000)Docker化FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . EXPOSE 5000 CMD [python, app.py]部署验证本地启动容器用curl发送POST请求验证返回结果是否符合预期。然后利用部署平台对外提供服务并配置一个后端负载均衡。注意部署时最大的坑是Python版本和本地包版本的锁死问题。即使在同一个Python版本下不同的NumPy版本也可能导致二进制不兼容直接报numpy.dtype size changed。你在本地怎么跑怎么好一上服务器环境一重新装Skill全套就位但报错第一行。所以Docker镜像里的requirements.txt必须精确锁死到次版本号。3.4 监控闭环的设计与实践模型上线的那一刻AI工程其实才完成了一半。这个项目里非常重要的一环是对模型进行监测因为数据分布是流动的今天训练的模型明天可能就不适应了。监控两个核心维度数据漂移检测监控线上输入特征的分布是否和训练集一致。最简单的做法是定期对线上数据进行统计与训练集的均值和标准差进行对比。如果差异超过阈值就需要告警。模型性能监控虽然在线上环境很难实时获得真实标签但可以监控预测值的分布、置信度分数等间接指标。如果某类别的预测频率发生剧烈变化大概率有异常情况。闭环迭代将漂移数据和预测结果记录到日志中定期把增量数据拉回来重新做标注用来作为微调训练集。这样才能让模型持续运转。目前这套系统在线上稳定跑了一个多月比较关键的一点是设计和部署了异常告警机制到目前已经触发了两次。每一次触发都成功定位到了线上数据分布与训练集分布不一致的问题。4. 常见问题与排查技巧实录4.1 损失函数不降反升但代码看起来没问题这是前期最让人崩溃的问题了。明明反向传播的实现看起来完全没问题逻辑上也没有明显Bug就是损失不降。排查步骤检查学习率学习率过大导致的模型发散是最高频的原因通常表现为损失在震动中放大。将学习率降低一个数量级如0.01 - 0.001后再试。检查梯度值打印每一层梯度的均值和标准差观察梯度是否消失或爆炸。如果梯度小到1e-10级别说明被ReLU的死亡区域拦截了。如果梯度大到1e10就要考虑梯度裁剪。检查数据归一化如果特征是房屋面积500平米和房间数3间量纲差异会让参数更新失衡。最有效的解决方式是对所有特征做标准化使其落在均值为0、方差为1的分布内。4.2 训练损失很低验证损失却很高这是典型的过拟合。在实现完整数据流水线时我通过对比训练和验证表现很就发现了这个现象。常见的三种解决路径加入正则化L1减少冗余特征L2约束参数幅度。在损失函数后加一项lambda * np.sum(W ** 2)你会看到验证集损失开始跟随训练损失变化而不是分道扬镳。早停法当验证损失在patience个epoch内不再降低时保存之前最佳模型并停止训练。这是最实用、成本最低的方法。数据增强针对图像和文本数据非常有效。即使是表格数据轻微的噪声扰动也是一种形式的数据增强。我个人体会最深的一点是正则化强度不是越大越好。过大的lambda会让模型欠拟合训练损失和验证损失同时飙高。合理的做法是使用一组从小到大排列的lambda值做粗筛然后在小范围内微调。4.3 训练速度太慢怎么加速在纯NumPy实现阶段训练速度确实感人。验证集加上数据量大训练轮数的时候训练时间令人焦虑。三个立竿见影的方案向量化计算尽量避免使用Python的for循环。我的经验是用np.dot和np.matmul能实现的操作一定要优先使用。一次循环到向量化的改写能让训练速度快出超过一个数量级。优化数据流水线在数据加载时使用tf.data或者PyTorch的DataLoader设置为并行预读取这样GPU/CPU在计算的时候数据已经在IO中准备就绪。使用GPU/混合精度如果你的模型在GPU上训练混合精度混合精度可以通过FP16计算FP32存储的配合把显存负载和计算速度都优化一个台阶。不过在纯NumPy实现阶段这一步走不了只能说明这个阶段的意义在于理解而效率交给框架完成。4.4 代码能跑但结果总是不稳定这个问题的隐蔽性非常强。即使是同样的训练数据和同样的模型结构多次训练结果差异也很大。这多半由两个因素造成随机种子未设置权重的随机初始化会导致模型陷入不同的局部极小值。必须在代码开头设置全局随机种子让实验可以被复现。数据shuffle机制如果不打乱数据顺序模型的参数更新极易被数据排列方式影响。每次epoch前要对训练集重新洗牌。我之前非常不重视随机种子这个问题。经过这个项目之后我在所有训练实验里都固定随机种子从此对比实验结果时观察到的差异就更加真实反映模型或数据的改变了。5. 真正拉开差距的工程化细节5.1 项目结构规范化随着代码量越来越大项目结构成了关键。我早期写的代码一股脑堆在几个.py文件里结果到后面连自己都不知道哪些函数是干什么的。后来我参考开源项目的模式做了标准化拆分├── data/ # 原始数据和预处理脚本 ├── models/ # 模型定义和训练脚本 ├── features/ # 特征工程代码 ├── evaluation/ # 评估和验证代码 ├── deployment/ # Dockerfile 和 API服务 ├── tests/ # 单元测试 ├── configs/ # 配置文件 └── requirements.txt # 依赖管理这种结构的关键优势在于它把“训练实验”和“模型服务”清晰分离——训练管线是离线的、迭代的部署服务是在线的、稳定的。两者混在一起的话后期维护会非常痛苦。5.2 实验记录与版本管理在AI工程里最糟糕的感觉是这个模型昨天还能跑出85%的准确率今天改动了一个无关紧要的模块准确率直接掉到70%。如果不记录实验参数你根本无从排查。目前我能坚持的基本操作每个实验都有一个独立的config文件包含学习率、批次大小、层数、正则化强度、数据路径、特征列表。模型的每个版本保存时都包括对应配置和评估指标。我养成了记录实验笔记的习惯用Markdown记录当天的实验目的、修改内容、结果和感悟。一个月后的自己翻笔记时也能很快重建当时的上下文。这套流程极其朴素效果却极其显著。它让你的AI项目从“炼丹”走向了“科学”。5.3 写测试不是为了形式而是为了保命大部分人写模型代码是不写测试的因为实验代码是探索性质的结构时刻在变。但这个项目里我坚持为以下三类代码写单元测试数据预处理函数因为一旦数据清洗逻辑出错错误方向上的正确性毫无意义你甚至都不会发现。损失函数和评价指标用非常简单的例子如全零预测、完美预测手算期望值验证函数是否正确。反向传播的梯度这就回到之前的梯度检查。用数值梯度验证解析梯度这是对是错一测便知。我后来排查过多次数据逻辑bug都是因为有测试才避免了一次次上线事故。没有测试你的每一步“改进”都像是在下坡路上开车却只用了空挡。6. 最后一个扩展从项目到作品的蜕变走完整个项目说实话那种“我懂AI了”的虚火已经退去了。取而代之的是一种更踏实的“我能把AI做好”的手感。最后再分享一个可以继续扩展的方向。整个项目学完之后你可以选一个贴近真实业务的小课题比如做豆瓣电影评分预测、或者一个客服工单自动分类把它完成一次从数据到部署到监控的全程闭环。这个过程和照着教程跑最大的区别是你开始直面不确定性陌生的数据格式、错误的内存限制、模糊的业务指标都会逼着你不断调用学过的底层知识来解决问题。我在做扩展项目的时候踩过的很多坑都回到了这个基础项目的知识点上。如果没有当时“从零开始”的积累我恐怕连问题出在哪几个模块都说不清。所以这个“from scratch”项目走到最后真正留给你的不是几段代码而是对AI系统整体脉络的掌控感。这种掌控感会让你在快速变化的技术浪潮里始终保持一种难得的稳定。