很多人问过我一个很有意思但容易让对话冷场的问题你天天折腾 AI 工程是不是就是“从零开始把模型训起来”说实话模型训练只是最后 20% 的显性工作。我更愿意把“ai-engineering-from-scratch”理解成一种完整的工作方式数据怎么进、特征怎么算、模型怎么验证、服务怎么扛流量、效果怎么持续追踪所有这些环节都要经得起“为什么这么设计”的追问。最近我把这套流程从头又走了一遍踩了不少印象深刻的坑也总结出一套真正适合个人或小团队落地的路线。这篇文章就从工程视角把“从零开始做 AI 工程”这件事拆开讲从任务定义、数据切分、手写训练循环到数据流水线和推理监控最后给一份可以直接照着做的两周路线图。如果你是第一次想正经做一个 AI 项目或者已经用框架跑过一些 Demo 但总觉得缺了底层那口气这篇应该能帮你补上关键一环。1. 为什么我劝你定期把自己拉回“从零开始”状态1.1 框架拿走的东西恰恰是最值钱的底层直觉现在用现成框架训练一个模型门槛低到让人误以为 AI 工程就是“写三行代码调参”。加载数据集、调用model.fit()、看下准确率完事。但问题恰恰出在这里框架把数据流动、梯度计算、损失函数、优化器更新这些关键机制都包装成了黑盒。你在黑盒外面调参就像只根据仪表盘开车却从没打开过引擎盖一旦遇到损失值不降、验证集指标震荡、推理速度慢得离谱这类真实问题你根本不知道从哪里下手排查。我自己带过几个新人发现一个很普遍的现象他们在训练脚本里改了学习率但说不清学习率到底作用在哪个数学步骤上;他们用过交叉熵损失但被问到“为什么分类问题最后要接 softmax训练时又常常把它和交叉熵合在一起算”时会愣住。这其实不是他们笨而是“从零开始”这条必经之路被框架抹掉了。所以我一直认为不管工作里用多高级的框架每隔一段时间都应该亲手实现一次最小训练流程不是为了炫技而是为了重新校准自己对“模型到底在做什么”的判断。1.2 “从零开始”不是重复造轮子而是一种刻意的技能训练当然我并不是号召大家回到 2012 年手写卷积神经网络推理层的时代。所谓“从零开始”更像是一种刻意练习把项目里最容易出问题、也最容易被忽略的环节亲手从原始逻辑实现一遍直到你能清晰地解释每一步的输入、输出和代价。举个例子很多人会用训练集准确率来评估模型却分不清“训练集上表现好”和“未知数据上表现好”是两回事。这个偏差不是因为缺乏统计学知识而是因为大多数人从来没有亲手做过一次严格的数据切分和一个从零搭建的验证流程。当这些步骤真正由你自己一个字一个字写出来时你会突然明白原来验证集是这么用的原来随机切分会把时间序列信息打乱原来类别不平衡会导致准确率这个指标变得毫无意义。这种从“听说过”到“亲手撞上”的转变才是“from scratch”真正的价值。所以我这篇文章里所有的建议核心都指向一个目标让你在依赖框架之前先用最笨重但最透明的方式把一个 AI 项目每个环节跑通把直觉建立起来然后再回头用框架提升效率。磨刀不误砍柴工真的不空。2. 从零开始的第一步根本不是模型把任务、数据和可评估结果钉死2.1 一个问题只有浓缩成指标才能说清“行还是不行”我见过太多项目死在第一步不是缺算力而是问题本身没有定义清楚。比如“我要做一个故障预测系统”这句话听着像目标但完全没法落地。你要预测什么时间窗口内的故障预测到故障之后希望系统干什么多早报警才算及时误报一次和漏报一次哪个代价更高这些不明确后面整个建模过程都会变成无头苍蝇。推荐的做法是选一个具体到不能再具体的场景。我最近在练手时用的是设备故障预测基于传感器的时间序列预测未来 12 小时某台设备会不会发生故障。这个场景的好处是目标单一、数据可以模拟、评价指标边界清晰。它足够小小到一个人两周能做完又足够完整完整到能覆盖数据、模型、部署、监控全部环节。把这个目标翻译成可评估的东西我建议先想清楚“用什么数字代表成功”。二分类问题的指标有很多但故障预测这种场景通常正负样本严重不平衡机器大部分时间正常运行故障窗口很少。如果只看准确率模型只需全部预测“正常”就能拿到 95% 以上的分数但这个模型没有任何实际价值。这时候要用精确率、召回率或 F1 值再配合召回率-精确率曲线来判断阈值到底切在哪里。我的习惯是先定指标再开跑实验指标没定清楚之前不写一行训练代码。2.2 切数据时别犯那些“一看就懂、一做就错”的错误数据切分是新手最容易踩的重灾区。很多人直接拿train_test_split(random_state42)随机切分如果是普通表格数据问题不大但碰到时间序列这就是灾难。传感器数据具有时间连续性今天的样本和昨天的样本高度相关。如果随机切分训练集和验证集里会出现大量“来自同一时间段”的数据模型等于提前看到了未来片段验证分数会虚高到让你产生幻觉。等上了真实环境模型立刻原形毕露。正确做法是按时间顺序切分前 70% 的数据做训练后 30% 做验证并且在构造特征时严禁使用未来信息。还有一个更隐蔽但很常见的泄漏点对连续型特征做标准化时如果用全量数据的均值方差去缩放训练集和验证集验证集的信息已经进入了训练预处理流程。正确的做法是只用训练集拟合标准化器的参数再用同一套参数去转换验证集和测试集。这些细节不是理论洁癖而是从零实验里真正会让你得到“看起来完美、上线就崩”的结果的元凶。2.3 动手建模前先做一个“无脑基线”来校准预期第一次跑模型之前我强烈建议先做一个不需要任何机器学习的基线。比如故障预测问题你可以写一条简单规则只要近期传感器读数超过某个固定阈值就报警。或者更笨一点全部预测为“正常”。把这条基线的召回率、精确率算出来记在纸上。为什么这么干因为基线是判断模型有没有用的标尺。如果你后来训练出来的模型连一个简单的阈值规则都打不过说明特征构造或模型选择很可能有问题而不是“再加一个隐藏层就能解决”。同时基线还能帮你建立对任务难度的直觉。有时候你会惊讶地发现一个简单规则就已经达到 85% 的召回率而模型即使调得再好上限也只是 88%那你就该思考这个项目还值不值得继续投入。这个决策成本远比先花两周训练模型再发现没价值要低。3. 手写一个最小网络接受梯度的教育3.1 坚持手写一个小模型到底是为了学会什么我始终认为一个对 AI 工程有基本追求的人至少应该从头实现过一次最小网络哪怕它只有一两个隐藏层。这个练习的重点不是要做得多复杂而是让你亲手经历一次“前向传播算出损失反向传播更新参数”的完整过程。你会在实现中被迫面对很多平时被框架藏起来的问题矩阵维度对不上怎么办数值下溢怎么处理ReLU 在反向传播时对负输入的梯度是多少为什么损失函数里经常把 softmax 和交叉熵合并计算这些问题看起来琐碎但就是它们构成了理解和排查深度学习项目的基本功。我在实践中发现一个规律那些能把框架代码写得又快又稳的人不一定懂底层原理;但反过来能徒手写出小网络并能跑通的人用起框架来几乎不会出什么难排查的错。因为他们的心智模型是“我能看见梯度流经每一层”而不是“梯度这种东西好像会自动算好”。3.2 一份极简 NumPy 训练循环长什么样下面这份代码是纯 NumPy 实现的两层全连接网络没有用任何自动微分库。代码本身很简单但值得一行一行读懂。import numpy as np def init_network(n_in, n_hidden, n_out, seed42): rng np.random.default_rng(seed) W1 rng.normal(0, 0.1, (n_in, n_hidden)) b1 np.zeros(n_hidden) W2 rng.normal(0, 0.1, (n_hidden, n_out)) b2 np.zeros(n_out) return [W1, b1, W2, b2] def forward(x, params): W1, b1, W2, b2 params z1 x W1 b1 a1 np.maximum(0, z1) # ReLU 激活 logits a1 W2 b2 return a1, logits def softmax_crossentropy(logits, y): # 减去最大值防止 exp 溢出这是数值稳定的关键 shifted logits - logits.max(axis1, keepdimsTrue) exp_logits np.exp(shifted) probs exp_logits / exp_logits.sum(axis1, keepdimsTrue) n y.shape[0] loss -np.log(probs[np.arange(n), y] 1e-12).mean() return loss, probs def predict(x, params): _, logits forward(x, params) return logits.argmax(axis1)然后把前向传播得到的损失对每个参数求梯度再用梯度下降更新十几行就能跑完一个能学习的模型。很多人在这一步会突然明白“训练”的微观过程每一轮不过是计算损失、算出梯度、沿着负梯度方向挪一小步。所谓学习率就是那一小步的步长。理解到这个粒度之后再去看框架文档里的各种优化器你会觉得它们全都变得好懂多了。3.3 梯度检查能同时治好“盲写网络”和“瞎调框架”手写网络最怕的一件事就是反向传播写错了但损失却在下降让你误以为一切正常。有一类 bug 很阴险梯度算得不对但方向和真实梯度大致相同前几百步损失照样下降模型却在一个低质量解附近徘徊。这时候如果你只会看训练曲线根本发现不了问题。解决办法是数值梯度检查。原理非常简单对某个参数theta用(f(theta eps) - f(theta - eps)) / (2 * eps)近似求导然后和你的解析梯度对比。如果两者误差在可接受范围比如相对误差小于 1e-4那反向传播基本可信。我在练手时保留了下面这个小函数它帮我在一天之内揪出过三次维度匹配错误和一次 ReLU 反向传播漏乘掩码的错误。def numerical_grad(f, theta, eps1e-5): grad np.zeros_like(theta) for i in range(theta.size): theta_plus theta.copy() theta_minus theta.copy() theta_plus.flat[i] eps theta_minus.flat[i] - eps grad.flat[i] (f(theta_plus) - f(theta_minus)) / (2 * eps) return grad这个技巧还有一个副作用当你以后用高级框架训练大模型遇到 loss 出现 NaN 或梯度爆炸时你会本能地想到用数值方法或梯度裁剪去验证梯度的合理性而不是瞎改学习率。这种“拥有基础诊断工具”的感觉正是从零训练给你的底气。4. 从笔记本到流水线数据管线与实验记录怎么设计才不拖后腿4.1 数据管线的“从零”原则每个步骤可重启、可追溯模型偶尔在笔记本里跑一跑没问题但只要开始认真做项目我强烈建议你尽早把数据处理从“一堆临时变量”改成“一串可重放的步骤”。我当时给自己定的原则很简单原始数据永远不变每一步处理都落成独立脚本脚本输入和输出都形成新文件或确定性的中间结果。比如原始传感器数据是一张 CSV我第一步统一格式化时间戳第二步做缺失值和异常值处理第三步构造滚动窗口特征第四步切分训练验证集。每一步都写成类似python step2_clean.py --input data/raw.csv --output data/clean.parquet这样可独立执行的命令。这样做的好处是当你发现模型因为特征算错而效果差你不需要重新处理整个流程;你只需要修复出错那一步然后重放它和它之后的所有步骤。这听起来像是工程洁癖但实际操作中特别能救命。有一次我改了一个特征窗口长度结果验证集分数突然暴涨让我兴奋了大半天。后来重新跑了一遍清洗脚本才发现前一次实验的验证集切分点被意外覆盖了。如果没有可重放的分步管道这种错误几乎无法追踪只能推倒重来。4.2 实验记录哪怕是一个人干活也要有“血缘”一个人做项目的时候最容易犯的错误就是“记不住上一次实验到底改了什么”。你可能只是把隐藏层从 64 改成 128几个小时跑完发现指标掉了两个点然后你想回退却想不起来当时的代码是哪个文件、数据版本是哪一版、随机种子是多少。这种混乱会极大消耗你的意志力也是很多项目做到一半搁浅的原因。我给自己做了一套极简的记录表每次实验跑完都填一行比如时间数据版本模型设置随机种子验证 F1备注2025-01-06 14:22data_v3两层 MLP隐藏层 64lr0.01420.782基线实验2025-01-06 16:03data_v3两层 MLP隐藏层 128lr0.0170.791加深隐藏层2025-01-07 09:41data_v3两层 MLP隐藏层 128lr0.00570.788降学习率反而变差不要小看这张表的价值。当你继续迭代到第 30 次实验你会发现真正能让你快速前进的不是更好的显卡而是一套能精确回答“上次有效的那版配置到底是什么”的记录体系。配合前文的分步管道每一次实验结果都可以复现每个涨点都能归因。这就是“实验血缘”工程上一般叫 lineage自己一个人做也必须建立起来。5. 模型训练完只是开始用服务化视角逼自己补上推理与监控5.1 推理边界要回答的三个问题同步还是异步、单体还是批处理、怎么算可用性很多从零开始做 AI 的人做到“模型在验证集上效果不错”就认为项目结束了。但在真实工程里模型训练完只是“模型产物”完成离“项目可用”还差着部署、推理、监控三大步。我建议你在训练阶段就逼自己用服务化的视角思考至少回答三个问题第一推理是同步还是异步。如果你的应用是用户点一下页面立刻得到结果那通常需要同步在线 API如果是离线定期扫描一批设备批处理任务更合适。第二是单体实时推理还是批量预测。故障预测如果每小时对全部设备做一轮判断批处理的成本远低于在线 API而且更容易追踪和回溯。第三怎么定义可用性。比如目标是“每天 95% 的预测任务在 5 分钟内完成”你就要为这个目标设计监控而不仅仅是“模型没崩就行”。这种视角转变最大的好处是它会逼着你把很多模糊的问题具体化。你会发现数据格式、字段缺失、单位不统一、请求频率、输出后处理这些工程细节每一项都比想象中更花时间。提前意识到这些就不会把“训练完模型”误当作“项目完成”。5.2 一个朴素的批处理推理框架可能比在线 API 更适合起点对大多数从零开始的中小型项目我其实更推荐从批处理推理开始而不是一上来就写一个在线 API。批处理逻辑简单出错容易排查也便于离线评估。你可以写一个非常朴素的定时任务读取新一批数据调用训练好的模型把预测结果写入结果表。整个过程不涉及并发、服务降级和复杂运维但已经足够让你走通“数据新进来-模型做出决策-结果回到业务方”的完整链路。当你把批处理链路跑稳了再做在线 API 就只是换一个入口的问题。因为底层的特征构造、模型加载、预测输出都被封装成了相同函数。我的经验是先用最朴素的方式跑通闭环再根据实际需要增加复杂度比一上来就搭微服务要稳妥得多。5.3 监控什么预测分布、特征漂移比监控准确率更应急模型上线后很多人只会监控“准确率今天是多少”。但问题是真实场景里你很难及时拿到准确的标签等你知道准确率下降了往往已经过去一两周损失已经造成。所以我的建议是监控你能立刻拿到的东西而不是监控需要滞后标签才能计算的指标。三个值得优先关注的点一是预测分布。比如模型预测故障发生的比例从平时的 10% 突然涨到 35%这通常意味着输入数据分布变了模型很可能在做不靠谱的判断。二是特征漂移。对每个关键特征监控均值、方差、分位数某个特征开始出现训练集里从没见过的值域就要立刻告警。三是数据返回量和处理延迟。如果数据进不来或者任务堆积再好的模型也白搭。我在个人项目里用的是非常朴素的办法每次批处理跑完把预测分布、特征均值、耗时统计写进同一张日志表。每周扫一眼所有异常都能早期发现。做 AI 工程最怕的就是“模型静悄悄地在生产环境变坏”而这种简单的统计监控就能把“静悄悄”变成“有信号”。6. 两周“从零开工”路线图一份可照抄的任务清单6.1 第 1~3 天把任务、数据和成功标准写到一页纸上前两天不要碰模型。选择一个小而具体的任务写下你要预测什么预测结果如何被使用用什么指标衡量好坏以及数据从哪里获取。接着做探索性数据分析画出数据分布、缺失值、时间范围把质量最差的数据清理逻辑确定下来。第三天结束前你必须跑出一个无脑基线并用基线指标和手动检查的样例输出写摘要。记住这份摘要不是写给别人看的是写给第七天的自己看的防止你后来在模型效果上自我欺骗。6.2 第 4~7 天搭出数据管道和第一个最小模型能跑就行第四到五天把分步数据处理脚本写好保证从原始数据到训练特征可以一键重放。第六天用手写最小网络或最朴素的框架模型跑通训练循环不要追求效果只要保证 loss 在下降、验证指标能算出来。第七天进行一次完整的梯度检查或对标准库模型的结果做 sanity check确保数据流和标签没有对错位。这四天的目标只有一个让整个体系先“转起来”。哪怕 F1 只有 0.6哪怕代码写得很丑只要链路通了后面所有优化都有抓手。最怕的是一直造部件永远不组装。6.3 第 8~11 天误差分析优先换模型靠后这是整个项目最出成果的阶段也是最容易走偏的阶段。很多人第 8 天开始换大模型第 9 天开始调超参数第 11 天宣布“两周项目结束了”。但我建议从第 8 天起把时间花在误差分析上把所有预测错误的样本拉出来逐一查看它们到底是特征缺失、标签错误、阈值不合理还是模型本身判断不了。误差分析之后你再去决定是调整阈值、增加特征、还是换模型结构。我的经验是大部分从 0.6 到 0.8 的提升来自数据和特征层面的修正而不是模型结构的改变。这个阶段一定要保持实验记录细分到每次改动一行就重跑一次。6.4 第 12~14 天封装、演示、留一手回退方案最后三天做两件事。第一把模型和预处理逻辑封装成可重复调用的函数写一个批处理推理脚本确保新数据进来能跑通预测结果能落库。第二做一个极简的演示页面或报告把“输入什么、输出什么、效果如何”展示出来。哪怕只是几张图和一段录屏也比只交一个 ipynb 文件更有说服力。同时一定要保留旧模型文件和旧管道的重放入口。上线新模型时旧版本必须随时可以回退。两周项目虽小但如果你从这个小项目里养成了“可回退”的习惯以后做大系统会少踩很多线上的坑。7. 哪些地方必须造轮子哪些地方可以偷懒一点务实取舍7.1 必须亲手走一遍的领域别跳过从零开始的练习中有几样东西我坚决建议亲手实现一是训练循环本身哪怕只写一个最简单的梯度下降二是数据切分和预处理逻辑因为这里藏着最多的业务逻辑和泄漏风险三是评估流程包括混淆矩阵、精确率召回率曲线这些指标的代码;四是误差分析的流程你要亲手把预测错的样本一条条调出来看。这四样东西构成了你对 AI 项目的核心直觉做不好它们后面很容易被各种框架和平台牵着鼻子走。7.2 可以有底气偷懒的领域别死磕同时我也要诚实地说从零开始不等于所有代码都自己造。像高性能矩阵运算、分布式训练、GPU 内核优化这些领域重复实现对你理解 AI 工程并没有加成性价比极低。你不需要自己写一个 cuDNN 级别的卷积实现也不需要为用 Transformer 而硬手写注意力机制的反向传播。重点在于理解和验证不在于重新发明基础设施。我的原则是核心逻辑必须理解到能徒手实现基础设施则大胆借用成熟工具。这两者不矛盾。前者保证你的判断力后者保证你的效率。一个聪明的“从零开始”项目应该是在关键路径上亲手把轮子转一遍然后转身去借用已经被验证过千万次的引擎。说到底从零开始做一次 AI 工程真正的收获不是那个准确率或者 F1而是你在每一步都能回答“为什么这么做”的能力。我第一次全程走完这套流程时最大的感触是原来之前用框架跑 Demo 时觉得理所当然的很多事情背后都有非常具体的工程选择。理解了这些选择之后不管是选型、调优、还是排查线上问题你都会比以前笃定得多。如果你正打算开始自己的项目别急着堆模型先把第一条数据管道跑起来哪怕它很简陋。
