拿到“ai-engineering-from-scratch”这个标题的时候我心里其实挺有共鸣的。现在一提到AI工程很多人的第一反应是“训练个模型有什么难的”可真把一个模型从Notebook搬到线上、在真实流量里稳定跑上几个月完全是另一件事。我见过太多demo视频里飞起、一碰真实数据就拉胯的项目也见过不少调参一把好手、却说不清模型上线后怎么监控、怎么回滚的团队。而“from scratch”这个表述恰好把这个问题的答案指了出来不依赖平台黑盒把AI工程从数据管理到模型训练、再到部署监控每一步都亲手搭一遍。这篇文章就按这个思路来拆适合已经会用PyTorch训练模型、但还没真正端到端做过生产系统的同学也适合想系统补一遍AI工程基础的人。1. 先搞清楚“from scratch”到底要从哪里开始1.1 三种常见的“从零”理解你是哪一种技术圈里叫“XX-from-scratch”的仓库太多了但含义并不相同直接决定你接下来的学习路径。第一种是算法层复现比如用NumPy从零手写CNN、手写Transformer重点是把反向传播、自注意力这些数学细节磕明白练的是“看得懂公式也写得出代码”。第二种是流水线搭建不用现成的ML平台而是自己从数据版本管理、训练脚本、实验记录、模型部署、线上监控一路搭过来练的是工程能力。第三种是业务闭环从一个具体的业务问题出发定义指标、采集数据、训练模型、上线验证、迭代优化走通一个完整的AI项目生命周期。在GitHub上搜索“ai-engineering-from-scratch”时我看到更多项目倾向于第二类路线但真正高性价比的路线其实是三者的组合核心算法用第一类的方式亲手实现一遍整体系统按第二类的方式自己搭建目标用第三类的方式对齐真实业务。只做第一种你只是个算法复读机复现得再像也不代表能上线只做第二种你不知道模型内部发生了什么出了问题只能靠猜只做第三种容易变成调包侠换一个场景就抓瞎。三者各占一部分才配叫“AI工程”。1.2 为什么现在做“从零搭建”依然值得有人会问现在有现成的MLflow、Kubeflow甚至有各种AutoML平台为什么还要自己从零搭我的回答是从零是快速建立判断力的方式而不是目的。我团队里有个实习生刚来时习惯用某平台一键训练、一键部署一切都很顺利直到某天平台改版、旧版本模型无法下载他整个人都懵了——因为他不清楚模型文件存在哪、依赖哪些环境变量、怎么离线恢复。那次之后他花了一周时间把一个最简模型服务从FastAPI到Docker全部手写了一遍从此对“部署”这件事的认知完全不一样了。只有亲手搭过一遍你才知道一个实验追踪系统真正要解决的是什么——不是记录几个参数而是让每一次实验都可以复现、对比、回溯你也才知道为什么需要数据版本管理——因为模型训练用的数据变了指标对比就毫无意义。说白了踩过一次坑之后你再回头看那些重平台能一眼看出它哪里设计得好、哪里是过度设计。2. 技术栈选型我推荐的组合不是最流行但最练手2.1 数据层文件即数据库版本管理尽早做很多入门项目的问题不是数据不够多而是数据文件一团乱。今天用train_v2.csv明天用train_final_0715.csv后天又改了特征但文件名叫train_final_0715_v3.csv等你想复现结果时根本不知道当时用的哪一版。所以我的习惯是小项目直接用Parquet或CSV统一存放用DVC做版本管理。DVC的核心理念是数据不入Git而是把数据文件的元信息和哈希记录在Git里推到远端后数据文件本身存在云存储或NAS上。这个设计很聪明。代码和配置跟着Git走数据跟着DVC走两者版本一一对应。某个commit对应的模型代码和数据版次永远是可回溯的。有人觉得数据量小没必要用DVC我也同意——但前提是你得有一套自己的版本规则比如目录按日期加语义命名并且保证同一个命名只能由一个脚本生成。否则迟早有一天你会对着三个不同名字的CSV文件发呆。2.2 算法层NumPy手写一遍 PyTorch正式落地在算法层我的建议始终是同一份代码写两遍先用NumPy手写一个极简的网络完全靠矩阵运算和前向/反向传播跑通训练再切到PyTorch做正式实现。第一遍的目的是让你对梯度流动有肌肉记忆——你知道每一个参数更新的数字到底从哪里来第二遍的目的是让你在真实工程项目里获得生产力——你用自动求导、GPU加速、以及Python生态里各种成熟工具而不必重新发明轮子。PyTorch唯一的问题是它帮你省掉了太多步骤容易让你误以为训练就是这么简单。我见过一些同学用PyTorch几十行代码就训练了模型但被问到“backward到底在计算什么”“学习率为什么是0.001不是0.1”完全答不上来。这就像你会开车但不懂刹车原理平时没问题一旦山路陡坡你就不知道怎么做。所以从零手写不是炫技是建立对工具判断力的基础。2.3 工程层FastAPI Docker 轻量监控能跑就先用工程层的选型我有明确偏好服务化用FastAPI不用Flask原因是FastAPI自带自动请求校验、自动生成OpenAPI文档性能也好很多环境打包用Docker保证训练和生产环境一致实验追踪用MLflow或Neptune小项目用MLflow就够了它支持记录超参数、指标和模型文件启动一条命令就能在本地看到所有历史实验的对比。监控方案我建议别一上来就上Prometheus Grafana全家桶虽然它们很标准但对小项目来说太重了。我早期项目就是用Python写个定时脚本每十分钟统计一下接口延迟、预测结果分布、特征缺失率异常了就发告警到群。这些指标确实非常重要这一点在第5节里我会详细展开。轻量监控能跑通逻辑之后再决定要不要升级成完整的可观测性体系工程决策从来都是“先跑通再优化”。下表是我推荐的组合以及选它的原因层次推荐方案选择原因数据管理Parquet/CSV DVC版本可回溯结构简单小项目够用算法实现NumPy手写 PyTorch落地既理解原理又不牺牲效率实验追踪MLflow一次实验的超参、指标、产物都在一处模型服务FastAPI Uvicorn轻量、高性能、自动校验输入环境隔离Docker训练与推理环境保持一致消灭“在我电脑上是好的”监控告警Python定时脚本 Webhook低成本先把核心指标跑起来3. 从零手写一个最小训练闭环矩阵乘、反向传播和梯度更新3.1 前向传播矩阵乘法的直观意义我们先做一个最简单的两层网络。输入的特征维度是4隐藏层维度是8输出维度是3比如三分类激活函数用Sigmoid。很多人看到“矩阵乘法”就害怕其实它的意义很朴素把一批样本一起往前推进。假设输入X的形状是(样本数, 特征数)那么一行就是一个样本矩阵乘法相当于对每个样本做一次“特征乘以权重再求和”只是用广播方式同时处理了所有样本。前向传播就是反复做这两步hidden sigmoid(X W1 b1)output sigmoid(hidden W2 b2)。这里的W1和W2是网络要学习的参数b1和b2是偏置。整个前向过程可以理解成把原始特征压成中间表示再把中间表示压成最终预测。其中每一步矩阵乘法都在改变数据所在的向量空间让数据慢慢地变得“可分类”。3.2 反向传播与梯度更新网络到底怎么学前向传播给了我们预测值预测值和真实值之间的差距就是误差。模型学习的过程就是不断调整参数让误差变小。这个调整方向由反向传播计算得到——本质是链式法则输出层的误差逐层往回传每经过一层就乘以该层激活函数的局部导数最终得到每个参数应该往哪个方向调、调多大幅度。下面是完整的两层网络训练代码我用NumPy实现没有用任何深度学习框架目标是让你看清参数更新的全部细节import numpy as np def sigmoid(x): return 1 / (1 np.exp(-x)) def sigmoid_derivative(a): # a 是 sigmoid 的输出导数可以写成 a * (1 - a) return a * (1 - a) np.random.seed(0) input_size, hidden_size, output_size 4, 8, 3 W1 np.random.randn(input_size, hidden_size) * 0.1 b1 np.zeros((1, hidden_size)) W2 np.random.randn(hidden_size, output_size) * 0.1 b2 np.zeros((1, output_size)) learning_rate 0.1 X np.random.randn(8, 4) # 8个样本4个特征 y np.eye(output_size)[np.random.randint(0, output_size, size8)] for epoch in range(200): # 前向传播 hidden sigmoid(X W1 b1) output sigmoid(hidden W2 b2) # 损失对输出的梯度均方误差的平均值 error (output - y) / X.shape[0] # 更新输出层参数 dW2 hidden.T error db2 error.sum(axis0, keepdimsTrue) # 误差继续回传到隐藏层 delta_hidden error W2.T * sigmoid_derivative(hidden) dW1 X.T delta_hidden db1 delta_hidden.sum(axis0, keepdimsTrue) # 梯度下降更新 W2 - learning_rate * dW2 b2 - learning_rate * db2 W1 - learning_rate * dW1 b1 - learning_rate * db1 loss np.mean((output - y) ** 2) if epoch % 40 0: print(fepoch {epoch}, loss {loss:.4f})把这段代码跑起来你能看到loss在随着epoch下降。但这里面有个非常经典的坑Sigmoid函数两端饱和导数值最大也只有0.25叠加多层之后梯度会指数级缩小层数一深基本就传不动了。这就是为什么现代网络更多用ReLU等非饱和激活函数。当你从零手写时会亲身体会到梯度消失导致loss几乎不下降的痛苦这比看任何教科书都有效。3.3 训练循环里的工程细节从“跑出数字”到“可复现”上面代码只是让模型跑起来了还不算工程实现。真正要放到项目里还要补几件事固定随机种子、保留最佳权重、记录训练曲线、保存模型产物。我的习惯是在训练脚本开头设置全局随机种子保证同一份数据每次训练结果一致训练过程中保存loss曲线到本地每个epoch后验证一次只在验证指标提升时覆盖保存模型文件。这些步骤看起来琐碎却是工程化的起点。固定随机种子和保存最佳权重本质上是在做“可复现性”记录训练曲线是“可观测性”。从零手写一遍训练循环后你再看那些框架内置的Trainer就能明白它们在背后帮你干了多少活也更能理解什么场景下需要自己写训练循环——比如要做梯度累积、自定义学习率调度、多任务联合训练时框架的默认行为未必够用。4. 数据工程与训练循环模型练得好一半靠数据管得稳4.1 数据划分与信息泄漏线下99%、线上60%的元凶我见过一个非常经典的案例某团队训练XGBoost模型在验证集上AUC达到0.99所有人信心满满地上线结果线上效果只有0.6。排查了一周最后发现问题出在预处理他们在划分训练集和验证集之前先用全量数据对缺失值做了均值填充。这一步看着不起眼却让验证集在不知不觉间偷看了训练集的统计信息。拿到生产环境后线上数据没有经过同样的全局统计表现自然暴跌。正确的做法是先把数据集切出独立的验证集和测试集之后所有的统计信息均值、方差、分位数都只用训练集计算再把这些统计值应用到其他数据集上。一句话切分在先统计在后。类似的泄漏源还有很多比如用全量数据做标准化、用验证集调超参后还把验证集混进训练集重新训练等。数据泄漏的可怕之处是它会让离线指标虚高给你营造一种“模型很牛”的错觉等上线后才发现一切都要重来。4.2 DataLoader设计思路批大小、随机打乱和工作进程数据加载看起来只是读取数据但设计得好不好直接影响训练效果和硬件利用效率。第一个决策是批大小。批大小越大梯度越稳定但占显存也越多且容易收敛到较差的局部最优点批大小太小则梯度噪声大训练不稳。通常从32或64开始调实践中大部分小项目在这个区间能找到不错的平衡点。第二个决策是随机打乱。训练集每个epoch都要重新shuffle目的是避免模型学到样本顺序带来的假规律验证集和测试集不需要shuffle保证评估结果与模型无关且可复现。第三个决策是num_workers。num_workers不是越大越好一方面它受限于CPU核数另一方面在Windows上多进程启停本身有开销有时设成0反而更快在Linux服务器上一般设成4到8就能把数据读取和GPU计算的流水线跑满。这些参数需要实际压测不能靠直觉。4.3 训练循环的稳定性设计早停、学习率衰减与检查点训练一个模型不是让它无休止地跑就行。我在工程代码里一定会加三个机制早停、学习率衰减、检查点保存。早停是监控验证指标连续若干轮不提升就提前终止避免无效训练和过拟合学习率衰减是训练后期用更小的步长做精细化调整比如每10轮衰减为原来的0.9检查点保存则是只保留验证集上表现最好的模型参数而不是最后一步的参数因为深度学习最后几步模型可能已经开始过拟合。这三个机制有一个共同目标让训练过程对噪声更鲁棒。真实项目里你不会盯着Loss曲线不放而是让脚本自行决定何时停止、保存哪份参数。这也是工程化模型和实验室跑分模型的区别——工程化模型要交付的是一个经过验证的、可复现的、可解释其训练历史的产物而不是一个“最后一轮”的状态。5. 部署、服务化与监控从Notebook走向生产环境的关键一步5.1 用FastAPI封装模型接口预处理一致性是最大的坑模型训练完成后部署工作通常是写一个HTTP服务。我常用FastAPI因为它基于Pydantic做请求校验自动返回400错误而不是等模型内部崩溃。下面是一个典型的mini服务示例from fastapi import FastAPI from pydantic import BaseModel import numpy as np import joblib app FastAPI(titletitanic-survival-model) model joblib.load(model/titanic_model.joblib) class Passenger(BaseModel): pclass: int age: float fare: float sex: str app.post(/predict) def predict(passenger: Passenger): age passenger.age if passenger.age 0 else 0.0 sex_code 1 if passenger.sex female else 0 features np.array([[passenger.pclass, age, passenger.fare, sex_code]]) prob model.predict_proba(features)[0][1] return {survival_prob: round(float(prob), 4)}但如果你只是把模型load进来就上线十有八九要踩一个经典大坑训练时的预处理和推理时的预处理不一致。比如训练前你做了缺失值填充、归一化保存的是归一化之后的特征文件但推理接口里没有做同样的处理模型上线后接收到的输入分布和训练时完全不同效果退化几乎是一定的。我的建议是把完整的预处理管线单独封装成一个函数训练脚本和推理接口共用同一个函数并且用一条测试样本同时跑训练预处理和推理预处理断言输出必须一致。这步对比虽然简单却能避免线上最严重的隐性错误。5.2 容器化与模型版本管理环境不可复现等于白部署部署环节最常听的“在我电脑上是好的”根因是环境不一致。Docker的做法是把Python版本、依赖库版本、模型文件全部打进同一个镜像让别人无论在哪台机器上跑行为都一致。下面是一个比较典型的Dockerfile供参考FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY ./app ./app COPY ./model ./model CMD [uvicorn, app.main:app, --host, 0.0.0.0, --port, 8000]要注意的是真正精细的环境管理还要固定基础镜像的版本最好制定明确的Python版本和依赖版本列表而不是每次拉最新的tag。模型文件也不建议塞进Git而是放到模型仓库比如MLflow的Model Registry或者简单的OSS存储并且给每个模型包打上版本号和哈希值。生产服务记录当前使用哪个版本的模型一旦要回滚直接把服务的模型版本指到上一个即可。5.3 监控与告警模型上线只是开始不是结束模型上了线真正的工程考验才开始。我做的第一版监控方案比较简单但足够有效定时任务每一分钟调用一次接口健康检查统计响应延迟和成功率每十分钟对线上请求的预测结果做一次分布统计对比训练集的预测分布记录特征缺失率和取值范围异常的次数。一旦指标出现显著变化就触发告警通知。其中比较值得一讲的是数据漂移监控。假设模型是在某个地区的数据上训练的后来业务扩展到另一个地区新用户的特征分布就会发生变化。这时候模型可能已经不再适应新数据但准确率不会瞬间崩掉而是慢慢退化。实践中常用PSIPopulation Stability Index群体稳定指数来衡量分布漂移程度计算公式等于对每个分箱计算(实际占比 - 预期占比) * ln(实际占比 / 预期占比)再求和。通常阈值是PSI小于0.1认为分布稳定0.1到0.25之间需要关注大于0.25则必须告警并考虑重新训练或回滚。监控指标可以用一个简单表格整理指标说明告警阈值示例接口成功率服务是否正常响应连续1分钟低于99%响应延迟P95用户体验核心指标超过500ms预测分布线上预测类别占比是否偏移与训练分布差异超过20%特征缺失率输入数据质量缺失率超过5%数据漂移PSI特征分布偏移程度超过0.25触发重训流程6. 常见问题与排查技巧实录我踩过的那几个坑6.1 问题速查表先定位再动手做AI工程项目报错是常态关键是有系统性的排查思路。我整理了一份高频问题速查表遇到问题可以先对照一下症状可能原因第一步排查Loss不下降学习率过大导致震荡或过小导致收敛极慢数据没归一化打印梯度范数观察是否消失或爆炸Loss变成NaN除零错误、log(0)、学习率爆炸检查输入数据是否含有NaN调低学习率训练精度高、线上效果差数据泄漏、评估口径不一致、特征构造不同重查数据切分顺序和预处理复用逻辑推理延迟高每条请求都重新加载模型、未做批处理模型预热、使用批推理或换更小模型显存OOM评估时未关闭梯度计算累积了计算图在验证阶段加上with torch.no_grad():换机器后模型加载报错Python或依赖库版本不一致、模型序列化兼容性差用固定版本的Docker镜像重新导出模型排查问题切忌“东改一下西试一下”。我调试训练问题的固定顺序是先看数据有没有NaN、分布是否正常、再看梯度范数是太大还是太小、最后才看模型结构。按这个顺序能解决大部分训练疑难杂症。6.2 我亲历的三个真实事故每个都值得写进你的检查清单第一个事故是模型换环境后加载失败。早前我在一台机器上训练好模型放到另一台新机器上加载结果直接报错原因是本地的sklearn版本和训练时不一致。从那以后我强制要求模型产物必须写明训练环境的Python版本和关键依赖版本而部署一律用固定依赖列表的Docker镜像绝不在裸机上跑模型服务。两个环境版本差一个patch都可能让pickle反序列化失败这个坑特别隐蔽。第二个事故是上线第二天预测分布就严重偏移。排查后才发现生产服务里拼特征时把几个特征的顺序写反了模型接口收到了特征值错位的数据却照样输出一个看似正常的结果。那次之后我在服务启动时加了一个特征Schema校验每次请求都检查特征数量、类型、取值范围是否在训练时预设的范围内超范围直接拒绝并告警。这类错位问题在纯数值特征里非常难用肉眼看出来只有靠程序化校验。第三个事故是日志过大把磁盘写满。某次监控脚本每秒钟记录一条完整请求日志包含全部入参出参运行两天后磁盘直接爆了。教训是生产日志必须分级请求入参只保留采样和固定比例预测结果和特征数据另存而关于告警要用“重试次数时间窗口”来抬高通知的灵敏度避免半夜三点被一条可忽略的告警吵醒。7. 关于“从零构建”这件事我最后再啰嗦几句我现在带新人做项目会先让他们用两周时间从零搭一个端到端的AI小系统模型不用先进但数据、训练、部署、监控四条线必须全部打通。这个过程很磨人第一周基本都和路径、版本、配置较劲但熬过去之后再看任何人的工程方案你都能一眼判断它哪里好、哪里脆。AI工程不是一个靠看视频就能学会的技术它必须靠真的把手弄脏踩过一遍错误才长得出判断力。如果你也想走这条路我的建议是找一个很小但真实的业务问题把每一层都亲自敲一遍然后让那个模型在线上活过一个月再回来看当初的架构你会感谢自己做出的这个决定。