做AI工程和做AI研究表面上看都在写Python、调模型实际是两种完全不同的思维模式。如果今年你打算认真进入这个领域我劝你先别急着装PyTorch、跑别人的代码先想明白一个问题AI工程到底在解决什么问题。同样一个模型研究员关心的是它在benchmark上的分数还能不能涨0.5个点工程师关心的是它在线上跑一年不出事故、推理成本可控、数据漂移了能及时发现、模型迭代了能平滑上线。这两套逻辑经常打架而ai-engineering-from-scratch这个项目的价值恰恰在于帮你把这套工程体系从头建立起来。它不是一份API文档也不是论文复现练习册而是一条完整的、从零开始把AI系统做扎实的路线图。适合两类人一是有一定编程基础但没正经做过AI项目的开发者二是已经在调模型但总觉得自己的产出“差点工程味儿”的算法工程师。1. 内容整体设计与思路拆解1.1 为什么需要一条从零开始的工程路线先讲一个我观察到的普遍现象。很多入行AI的人成长路径是这样的先看几天Python语法然后直接上Kaggle抄notebook再然后就是调库、调参、换模型、刷分数。这条路走到一定阶段就会卡住——不是模型效果不行是系统跑不起来。数据一多就OOM训练到一半断点续不上模型上线后指标掉得一塌糊涂却不知道原因代码改了一版后旧结果复现不出来。这些问题的根源不是你不会用某个框架而是你缺少一个完整的工程框架。你学的是“怎么训练一个模型”但实际工作里你需要的是“怎么稳定地、可重复地、可控地训练和部署一个模型”。这两件事的差距就是工程化的差距。“ai-engineering-from-scratch”这个项目有意思的地方在于它没有把你直接按到某个深度学习框架里而是把AI工程拆成了几条可以独立修炼的能力线数据处理、实验管理、模型训练、评估验证、部署监控。每条线单独拎出来都有大量细节但合在一起就构成了一个AI系统从开发到上线的完整生命周期。这种结构的价值在于它让你知道每一步在整条链路里的位置而不是孤立地学某个工具。1.2 用软件工程的视角看AI项目如果你用传统软件工程的思维去套AI项目第一反应是“这玩意儿怎么这么难管理”。传统软件的代码逻辑是确定的输入输出是可预期的测试用例可以写得很完备。AI系统不一样它是数据驱动的你改的不是代码逻辑而是模型从数据里学到的统计规律。这意味着什么意味着模型的行为不是你直接写出来的你只能通过数据和训练过程去间接控制它。这就是为什么AI工程不能简单复用传统软件工程的实践。你需要一套专门的工具链和流程数据版本管理来代替代码版本管理实验记录来代替单元测试模型注册中心来代替制品库监控告警来代替日志排查。整个思路可以类比成“用管理复杂系统的方式管理模型”而不是“用写普通程序的方式写模型”。从零开始建立这套体系最忌讳的是“一步到位”。很多团队一上来就上Kubernetes、MLflow、Airflow全家桶结果两周过去了连一个最简单的模型都还没跑通。正确的做法是先手动跑通一条最小的链路清楚每一个环节在做什么然后再逐步引入工具来固化流程。这个项目崇尚的正是这种“先理解再自动化”的路径这也是我推荐它的重要原因。2. 核心路线拆解——先学什么再学什么2.1 五个能力阶段的设计逻辑任何一套好的学习路线背后都有清晰的设计逻辑。“ai-engineering-from-scratch”给我的感觉是它按照一个AI项目从无到有的自然顺序划分成五个能力阶段。第一阶段是数据工程。你首先得搞定数据采集、清洗、去重、标注、切分、版本管理。这个阶段最容易被轻视但它是整个AI工程的底座。我见过太多项目模型结构换了好几个效果始终上不去最后查来查去发现是训练集和验证集有数据泄漏。数据管道不扎实后面所有的实验都是空中楼阁。第二阶段是实验管理。当你开始跑模型时会产生大量实验不同的超参、不同的数据版本、不同的模型结构。你需要知道每个实验用了什么数据、什么参数、产出了什么指标。这不是为了写周报而是为了让你能科学地做决策——哪个改动真正有效哪个只是随机波动。第三阶段是模型训练与优化。这里的重点不是把某个模型跑到SOTA而是系统地掌握训练流程学习率怎么调、正则化怎么做、分布式训练怎么并行、显存不够怎么办。这部分的功底直接决定了你能否从“跑通别人的代码”进化到“训练自己的模型”。第四阶段是评估与验证。离线指标只是第一道门槛你要学会设计更贴近线上情况的评估方案比如A/B测试怎么设计、指标口径怎么统一、不同场景下的表现怎么衡量。这个阶段解决的是“模型到底行不行”的问题。第五阶段是部署与监控。模型训练完只是起点。你要把它封装成服务做性能优化设置监控告警建立模型版本更新机制处理数据漂移。这一步才是AI工程和AI研究的真正分水岭。这五个阶段的顺序很讲究。它大体遵循“数据先行、实验验证、评估把关、部署兜底”的工程逻辑。跳过任何一环后面都会加倍补偿。2.2 工具选型的克制原则跟这个学习路线配套的是工具选型。我见过很多人在第一步就钻进了工具选择的兔子洞整天纠结该用PyTorch还是TensorFlow、该上MLflow还是WB、调度用Airflow还是Prefect。这种纠结毫无意义。正确的做法是遵循“最小工具集”原则。每个环节先选一个生态成熟、上手门槛低的工具能手动做的事情就先手动做。比如数据版本管理一开始你可以只用文件目录加命名规则实验记录一开始可以只用一个结构清晰的Excel等流程跑顺了再逐步引入DVC、MLflow这类专门工具。先有流程意识再上工具固化最后的落地效果远好于一步到位。在框架选择上现在基本没什么悬念PyTorch已经成了事实标准。学习阶段认准PyTorch生态就够了其他框架可以等有需要时再了解。这套路线的核心思想是一致的从零开始指的是从认知上建立完整的工程体系而不是从轮子开始造轮子。3. 核心环节实操拆解——数据、训练与评估3.1 数据管道AI工程的地基工程数据管道这个概念听起来很高级其实本质就是一句话保证你的模型吃到的每一口数据都是干净、可控、可溯源的。先从数据清洗说起。原始数据永远比你想象的脏。我在实际项目里处理过一个文本分类任务数据是从各种渠道扒来的评论里面混着大量HTML标签、URL、重复内容、无意义字符。清洗的第一原则是“能不做就不做非做不可就留痕”。什么意思每一道清洗步骤都要有据可查最好写成脚本而不是手动改文件。因为你清洗规则会影响模型最终学到的分布如果过程不可追溯出问题时你根本无从排查。切分数据是另一个高危环节。常见错误是直接train_test_split(random_state42)就完事。如果你的数据里同一个用户贡献了多条样本不做分组切分的话训练集和验证集就会泄漏用户信息导致验证指标虚高。正确做法是先按用户、会话或其他业务粒度分组再在组级别上做切分。数据版本管理是很多人忽略的一块。训练集加了10万条新数据旧实验还能复现吗模型上线后效果下降你能确定线上跑的是哪一版数据训练的模型吗如果现在回答不了这两个问题说明数据版本管理还没到位。入门阶段的建议是用DVC它可以像Git管理代码一样管理数据和模型文件支持存储于本地或云端的对象存储操作逻辑也直观。关于数据泄漏多啰嗦一句。泄漏的本质是信息从验证集或测试集流入了训练过程。除了分组切分要当心还有一种隐蔽的泄漏是特征构造造成的。比如你做了特征工程用全量数据的均值去填充缺失值——这一步就把验证集的信息带进了训练集。正确姿势是在训练集上计算填充值然后应用到验证集和测试集。这类细节在文档里很难学到基本都是踩坑踩出来的。3.2 实验管理每一个实验都要能复现如果你同时跑过10组实验就会明白实验管理的意义。这时候你会面临几个现实问题哪个实验效果最好对应的代码版本是什么用了哪份数据训练了几个epoch学习率是多少如果这些信息全靠脑子记那基本等于没有。实验管理的核心我总结为三要素代码、数据、环境。三者的版本信息必须能一一对应。代码用Git管理数据用DVC管理环境用依赖锁文件锁定再加上一个实验记录工具把这些元信息自动串起来。最省事的组合是MLflow或者WB。MLflow开源自建数据在自己手里WB用起来顺滑但数据在别人服务器上。为了长期可控我建议从MLflow学起。一套标准的实验记录至少要有这些信息实验名称、Git commit ID、数据版本、模型结构、超参数、训练日志路径、模型产物路径、评估指标。把这些字段结构化记录好你就有了一个可检索、可复盘、可追溯的实验档案库。这不是为了写报告是为了让你在三个月后回头看时能快速搞清楚“当时那个87.3分的实验到底是怎么跑出来的”。3.3 模型训练的稳定性经验模型训练是看着最热闹、实际上最容易翻车的一环。这里分享几个我实测过很多次的经验。第一点是随机种子。深度学习中随机性无处不在数据打乱、初始化、dropout。想让实验可复现第一件事就是在代码入口固定所有随机源——Python的random、NumPy、PyTorch、CUDA一个都不能漏。但要有清醒的认知即使种子固定了某些框架在特定硬件上依然可能产生微小波动。可复现是工程化指标不是玄学操作。第二点是学习率最经典也最容易被乱调的参数。学习率太大loss震荡甚至发散太小收敛慢到怀疑人生。实用做法是先跑一个学习率扫描learning rate finder排掉明显发散和明显过慢的区间再从中间偏小的值开始。迭代策略方面有现成的scheduler就用现成的别自己发明轮子。第三点是显存优化。单卡放不下大模型时有几种递进方案减小batch size但要注意batch size变化会影响BN统计量训练结果可能难以对齐、梯度累积、混合精度训练、模型并行、卸载到CPU。我个人的优先级是梯度累积和混合精度优先尝试因为它们改动小、收益大而模型并行和CPU offload通常是在前两者都不够用时的选择。如果显存仍然紧巴巴就回到更根本的问题上——你是不是真的需要这么大的模型或者能不能把输入序列缩短一点。第四点也是最有价值的一点监控训练过程。不要等到训练结束才看结果。训练过程中要持续盯loss曲线、梯度范数、学习率变化、验证指标。很多问题在训练中期就能看出来。比如loss先降后升大概率学习率没配合好或者过拟合了验证曲线反复震荡多半是数据有问题或者结构参数不稳定。及早发现及早止损。最后补充一个很多人关心的问题训练到底该跑多少epoch没有标准答案取决于你的数据和模型复杂度。实操中不要死盯epoch数给训练加一个early stopping——当验证指标连续N轮不提升就停止同时保留最佳checkpoint。这样既不浪费算力也不容易过拟合。要养成习惯在评估阶段验证一下选出来的是历史最佳checkpoint还是最后一轮checkpoint两者差别可能很大。3.4 评估体系离线指标与在线验证的差距评估是AI工程里最容易被低估的环节。很多人觉得评估就是算个准确率、算个F1其实远不止这些。离线评估阶段至少要做到三点。第一点是区分不同任务类型选对指标分类任务要结合正负样本比例决定用准确率、精确率、召回率还是F1回归任务要关心MAE或RMSE排序任务要看NDCG或MRR。选错指标等于用错尺子量东西模型好坏是判断不了的。第二点是做误差分析不要只看总分。把预测错的样本拉出来人工翻一遍看错误集中在哪类数据上往往能帮助确定下一步的改进方向。第三点是做健壮性测试试着对输入加噪声、轻微扰动看看模型是否“一碰就碎”。这里要提一个非常有价值但经常被忽略的点什么时候该相信你的离线指标答案是——离线指标与线上指标趋势一致时。比如离线提升0.5个点线上确实也涨了0.5个点说明你的评估方法能反映真实场景。如果离线涨了但线上掉了那就要检查离线评估是否过于乐观典型原因包括数据泄漏、评估集和线上分布偏差过大等。在线验证阶段最常用的是A/B测试。很多团队在模型上线时A/B测试做得极其随意——流量切得不对、样本量不够、运行时间太短就急着下结论。我的经验是设定清楚的主要指标在跑之前约定好最小提升幅度和置信水平再用统计方法来判定不要靠眼睛目测。有基础统计知识打底这一套做下来评估体系就算立住了。4. 实操过程与核心环节实现——从零跑通一个最小闭环项目4.1 场景选择与项目定义我拿一个典型的入门场景来演示整套流程基于BERT的中文情感分类。为什么选这个场景因为它同时覆盖了几乎所有核心工程环节——数据清洗、切分、模型微调、评估、部署但数据集和模型体量都不大在单张消费级显卡上就能跑完适合拿来验证学习路线。项目定义阶段第一步是把目标量化比如准确率不低于88%、单条样本推理时间低于50毫秒、模型可以离线训练并打包上线。有量化目标的好处是后边每个环节你都清楚“做到什么程度算合格”而不是“感觉还行”。4.2 数据准备的完整流程数据集我建议用公开的中文评论数据类别为正向和负向两类。原始数据是TSV或CSV拿到的第一件事我建议按照前面提到的清洗、去重、切分三条线来处理。清洗阶段做一个简单的Python流程几条关键处理逻辑就够了全角转半角、移除HTML标签和URL、过滤长度小于2的无效样本、正则去重。这些规则写成一个模块化的函数每个函数加个注释说明“为什么这么做”。比如过滤短样本是因为过短的文本缺乏足够语义信息会让模型学到噪声而非规律。分组切分这一步要特别注意。我不会直接用train_test_split(stratifyy)而是先检查数据集里是否有同一用户或同一作品的多条评论。如果有按用户分组后再切分确保同一用户的所有评论只出现在一个集合里。切分比例我会控制在8:1:1训练集、验证集、测试集各司其职训练集学规律验证集调参数测试集最终把关。测试集尽量留到最后一刻再碰不要反复拿它试错。4.3 训练脚本与关键参数模型选择上我推荐用bert-base-chinese。训练框架用PyTorch加HuggingFace Transformers这套组合是目前中文NLP任务最顺手的起步配置。核心训练参数我列一组经过验证的基准值序列最大长度128批量大小32学习率2e-5BERT微调的标准稳妥值训练轮数设为10配合early stopping优化器AdamW权重衰减0.01warmup比例0.1关于学习率为什么选2e-5多说两句。BERT这类预训练模型微调时学习率有一个大致的安全区间1e-5到5e-5之间是多数任务的合理选择。太高容易破坏预训练学到的通用语义特征太低则微调效果微弱。2e-5不一定是理论最优但它是风险最低的起点。想调得更细可以在这个基础上做学习率扫描。训练脚本里我给出的实现要点包括# 关键点1固定随机种子 def set_seed(seed: int): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) # 关键点2验证集指标计算 # 分类任务更关注macro F1而非准确率 # 尤其在正负样本比例不平衡时更合理切勿忽略的是set_seed这个看似不起眼的函数。它直接决定了你能否在复跑时拿到一模一样的结果。之后每跑一个实验都把这次的seed、代码commit、数据版本、超参数完整记下来。这是你自己和自己的约定越早养成越好。4.4 显存估算与训练执行细节开始训练前需要快速估算显存。怎么估算常识层面就能做一个粗算BERT-base模型参数1.1亿加载到显存大约占440MBFP32下4字节每个参数。但训练态显存主要消耗来自四部分模型权重、优化器状态AdamW要保存动量等状态额外开销是权重的2倍、梯度、中间激活值。综合算下来一个小batch的BERT训练实际占用常常是模型本身的5到10倍。我的实操经验是序列长度128、batch size 32、单卡训练BERT显存占用大约在4GB到6GB之间。如果你的显卡只有8GB建议先按batch size 32尝试显存紧张就降到16或8或者开启梯度累积用等效batch size弥补单batch的减少。训练过程中用nvidia-smi随时盯显存占用尤其注意第一次迭代时显存分配是否正常这一步能提前暴露不少炸卡风险。训练时应该把模型用model.train()和model.eval()在不同阶段切换否则dropout和BN统计量在验证阶段会“作弊”式地工作导致验证指标失真。这个细节虽然简单但流行框架中频繁出现误用的场景并不少见手写训练循环时要格外小心。4.5 评估、打包与验证闭环模型训练完先算测试集的主指标。这里我要特别强调测试集只能碰一次。也就是说测试指标是你对模型最终能力的判断不是反复试来试去的调参玩具。如果做了多次实验每次都测一遍测试集那测试集的“纯净度”其实已经被污染了最终得到的是一个过拟合了测试集的结果。打包部署方面最省力的做法是导出为ONNX或TorchScript。我实测下来ONNX的推理速度通常比PyTorch原生态快一到两倍而且可以直接被ONNX Runtime或Triton等推理框架加载。导出时别忘了做输入输出对齐验证最常见的问题是动态轴没配置好导致线上推理报错。验证闭环只一步之遥写一个最小推流服务把模型包装成HTTP接口用测试集里随机抽几条样本走通一次完整请求观察单条延迟和显存占用。到这一步一个从数据到部署的最小AI工程闭环就真的跑通了。把这套流程的代码整理好就是一个能持续演进的工程样板。5. 常见问题与排查技巧实录5.1 高频故障速查表下面这张表是我自己在实践里踩坑频率最高的几个问题汇总列成速查表遇到同类问题可以直接照着排查。现象常见原因排查方向解决思路训练Loss不降或反弹学习率过大数据标签噪声严重打印每轮Loss看是否发散降低学习率检查数据标注质量验证Loss震荡剧烈单batch过小验证数据分布抖动比较训练/验证分布和样本量调整batch或改用更平滑的评估策略训练Loss降但验证指标不动过拟合数据泄漏检查验证集内是否存在训练集样本做误差分析检查划分数与特征构造推理速度过慢模型过大未做量化或导出优化用profiler定位瓶颈尝试半精度或ONNX导出必要时蒸馏复现不了旧实验随机种子没固定数据或代码版本没记录核查三要素对应关系补全实验记录固定所有随机源显存溢出batch过大序列过长观察OOM时输入形状降batch、梯度累积、混合精度训练线上指标与离线不一致分布漂移特征缺失逻辑不同对比线上传入特征与训练时特征检查特征工程前后逻辑建立特征版本这张表不是标准答案但它能帮你快速定位问题的大方向。很多问题表面上是模型不行实际上根源在数据或流程。5.2 排查思路比具体方案更重要分享一个我踩过很多次的大坑训练集和验证集之间的数据不一致。这个问题的隐蔽性在于代码不报错、数据能跑通、验证指标也不难看但它就是跟真实场景对不上。排查这种问题的思路是“追踪数据流”。从测试集里随意取一条错误预测的样本反推它的整个处理链路原始数据长什么样、清洗时发生了什么、分词器怎么切的、喂给模型的张量长什么样。把这条链路完整走一遍通常很快就能发现猫腻。比如线上传的是清洗前的文本而训练用的是清洗后的版本那效果一定会崩。再讲一个经验当模型行为变得不可理解时去看数据。这个顺序通常不会错。6. 从零到一之后怎么继续进阶跑通最小闭环只是入门。之后有几条可以深入的方向一是专攻工程化深度把自动化的实验流水线搭完善加入CI/CD让模型上线变成一个可重复、可回滚的流程二是向大模型方向延伸理解分布式训练、张量并行、流水线并行、模型量化、推理加速这些更底层的技术三是往MLOps平台化方向走把模型生命周期管理做成团队级别的基础设施。我个人在实际学习过程中还有一个体会比起追逐最新的模型不如先把评估体系做扎实。一个厉害的AI工程师不是比他多会几个新模型而是他能判断什么时候模型改动真的有效、什么时候只是随机波动。这种判断力来自对工程细节的长期打磨没有捷径。如果你也打算走这条路从今天开始先把自己手边的数据管干净再谈别的。