从零搭建AI工程能力：别再收藏速成清单，这才是正确路径

1. 从零搭建AI工程能力为什么我劝你别再收藏那些“速成清单”了“ai-engineering-from-scratch”这个标题第一次看到的时候我愣了一下。不是因为它有多花哨恰恰相反它朴素得有点不像这个时代的标题。现在满屏都是“三个月从入门到精通”“七天掌握大模型应用开发”“零基础转型AI工程师”突然冒出来一个“from scratch”反而让我觉得踏实。我自己在这个行当里摸爬滚打了十来年从最早做传统机器学习模型部署到后来搞深度学习推理优化再到现在带着团队做AI应用工程化落地踩过的坑比写过的代码行数还多。我越来越确信一件事AI工程能力这件事真的没法速成。你可以七天学会调一个API但你没法七天学会怎么让一个AI系统在生产环境里稳定跑上一年。这个项目标题的核心其实是在说一件事——从底层开始把AI工程当作一门手艺来练而不是当作一堆工具来用。它适合谁适合那些已经会写Python、跑过几个demo、但一到真实项目就抓瞎的人适合那些被各种框架和工具搞得眼花缭乱、不知道该学什么的人也适合那些想转行做AI工程、但不想只学个皮毛的人。我写这篇东西不是要给你一个“学习路线图”——那种东西网上太多了而且大部分都是抄来抄去。我想做的是把我自己从零开始搭建AI工程能力的过程中真正觉得有用的思路、方法和踩过的坑原原本本地讲出来。你读完不一定能马上变成AI工程专家但至少能知道该往哪个方向使劲以及哪些弯路可以不用走。2. 先搞清楚“AI工程”到底在工程什么2.1 模型训练只是冰山一角很多人对AI工程的想象停留在“调参、训模型、看loss曲线”这个层面。我刚入行的时候也这么想觉得只要把模型训出来事情就结束了。后来才发现训练只是整个链条里最可控的一环——因为数据是固定的环境是隔离的跑完就完了。真正的麻烦从模型训完那一刻才开始。你得把模型打包成服务得考虑推理延迟得处理并发请求得做版本管理得监控线上表现得在模型效果下降时快速回滚。这些事情没有一件是“调参”能解决的但它们才是AI工程的主体。我习惯把AI工程分成四层来看。最底下是基础设施层包括计算资源、存储、网络这些你得知道GPU怎么调度、数据怎么高效读取。往上是模型层包括训练、微调、评估、优化这一层是大多数人最熟悉的。再往上是服务层模型怎么部署、怎么扩缩容、怎么保证可用性。最上面是应用层怎么跟业务逻辑结合、怎么设计交互、怎么收集反馈形成闭环。“from scratch”的意思不是说你要从写CUDA kernel开始而是说这四层你都得懂不能只会中间那一层。我见过太多人模型训得挺好但一让他部署就懵了这就是典型的“只会中间层”。2.2 为什么工具越学越乱现在AI领域的工具链用一个字形容就是“碎”。训练框架有PyTorch、TensorFlow、JAX部署有TorchServe、Triton、BentoML实验管理有MLflow、Weights Biases数据版本有DVC、LakeFS特征存储有Feast编排有Airflow、Kubeflow、Metaflow……这个列表还能列很长。新手最容易犯的错误就是试图把每个工具都学一遍。我当年也干过这种事结果就是每个工具都只会跑个demo真到项目里还是不知道该怎么选、怎么组合。后来我想明白了一个道理工具是解决特定问题的不是用来“学”的。你应该先有场景再去找工具而不是反过来。比如你有一个模型需要部署成HTTP服务你再去比较TorchServe和Triton哪个更适合你的场景而不是先把两个都学一遍然后等着场景来找你。“from scratch”的另一个含义就是从问题出发而不是从工具出发。你得先能定义清楚问题再去选工具。这个能力比会用什么工具重要得多。2.3 一个最小可用的AI工程能力模型如果让我给“AI工程能力”画一个最小可用模型我会画成一个三层金字塔。最底层是工程基本功。这包括熟练的Python编程能力、对Linux命令行的熟悉、基本的网络知识、会用Git做版本控制、能写单元测试、懂基本的软件设计原则。这些东西听起来跟AI没关系但它们决定了你能不能把AI代码写成可维护、可协作、可部署的样子。我面试过很多人模型原理讲得头头是道但连一个Python包都组织不好这种基本功的缺失是致命的。中间层是AI系统认知。你得理解一个AI系统从数据到模型到服务到反馈的完整生命周期知道每个环节的关键问题和常见解法。比如数据环节要考虑分布偏移和标注质量模型环节要考虑过拟合和泛化服务环节要考虑延迟和吞吐反馈环节要考虑如何收集有效信号。这一层不需要你每个环节都亲手做过但至少要知道它存在、它重要、它大概怎么搞。最上层是特定领域深度。比如你做计算机视觉那目标检测、图像分割这些你得深入你做自然语言处理那Transformer架构、预训练微调这些你得吃透。这一层是随着你做的项目逐渐积累的不需要一开始就追求广度。“from scratch”的路径就是先把最底层打扎实再建立中间层的认知最后在具体项目里往最上层深耕。跳过底层直接冲上层短期看好像走得快长期看一定会卡住。3. 从零开始的第一阶段把工程基本功练到不拖后腿3.1 Python不是会写就行要写到“工程级”我见过太多AI方向的代码写得跟科研脚本一样——一个文件几百行变量名全是a、b、c没有类型标注没有文档没有测试。这种代码在个人实验阶段没问题但一旦要协作、要部署、要维护就是灾难。“工程级”的Python代码至少要做到几件事。第一是模块化把数据加载、模型定义、训练循环、评估逻辑拆成不同的模块每个模块职责单一。第二是类型标注用Python的type hints把函数输入输出标清楚这不仅能帮你提前发现错误还能让IDE给你更好的补全。第三是配置管理不要把超参数硬编码在代码里用配置文件或者命令行参数来管理。第四是日志用logging模块而不是print这样你能控制日志级别也能把日志输出到文件。我自己的习惯是任何一个超过200行的AI项目我都会先花半天时间搭一个项目骨架。这个骨架包括一个configs目录放配置文件一个src目录放源代码src下面再分data、models、training、evaluation、utils这些子模块一个tests目录放测试一个scripts目录放训练和评估的入口脚本。这个骨架搭好之后后面写代码就是往里填内容思路会清晰很多。3.2 Linux和命令行AI工程师的日常战场不管你用Windows还是Mac做开发最终你的模型大概率是要跑在Linux服务器上的。所以Linux的基本操作你得熟练不是“会几个命令”那种熟练而是能把它当日常环境用的熟练。具体来说你得会这些用ssh连远程服务器用tmux或screen保持会话用htop或nvidia-smi看资源占用用rsync或scp传文件用grep和awk处理日志用find和xargs批量操作文件用crontab定时任务。这些命令看起来简单但组合起来能解决很多实际问题。举个例子你训练了一个模型日志输出到train.log你想看每个epoch的loss变化。你可以用grep epoch train.log | awk {print $2, $4}把epoch号和loss提取出来然后重定向到一个文件里再用Python画图。这个操作链条我几乎每周都会用到比打开日志文件一行行看效率高太多了。还有一个我强烈建议的习惯把你的常用命令写成脚本。比如启动训练的脚本、清理缓存的脚本、同步代码到服务器的脚本。这些脚本放在scripts目录里用的时候直接跑不用每次重新敲一遍。我自己的scripts目录里有几十个这样的脚本它们帮我省下来的时间累积起来非常可观。3.3 Git不只是“提交代码”是协作和实验管理的基础Git的重要性怎么强调都不为过。但很多人对Git的使用停留在git add、git commit、git push这三板斧上这远远不够。在AI项目里Git至少有三个进阶用法你必须掌握。第一是分支管理每个实验开一个分支实验成功就合并回主分支失败就删掉。这样你的主分支永远是干净的、可用的而所有实验痕迹都在分支历史里。第二是.gitignore的合理配置模型权重文件、数据集、日志文件这些大文件不要提交到Git里用.gitignore排除掉。第三是commit message的规范不要写“update”或者“fix bug”这种没信息量的message写清楚这次提交做了什么、为什么这么做。我自己的commit message格式是第一行简短描述空一行然后详细说明改了什么、为什么改、有什么影响。这个习惯在半年后回头看代码时特别有用你能快速回忆起当时为什么做了某个决定。另外如果你做实验比较多可以考虑用Git LFS来管理大文件或者用DVC来做数据版本控制。但这两个工具不要一开始就上先把基础Git用熟再说。3.4 测试AI代码也需要而且更需要“模型代码怎么写测试”这是我被问过最多的问题之一。很多人觉得AI代码有随机性测试没法写。这个想法是错的。AI代码的测试不是测“模型效果好不好”而是测“代码逻辑对不对”。比如你的数据加载函数给定一个输入文件输出的tensor形状对不对、数据类型对不对、归一化范围对不对这些都是可以测的。你的模型定义给定一个输入输出的形状对不对、参数量对不对这些也是可以测的。你的训练循环跑一个epoch之后loss有没有变化、参数有没有更新这些同样可以测。我通常会把测试分成三类。单元测试测单个函数用pytest写跑得快每次改代码都跑。集成测试测多个模块的配合比如数据加载加模型前向传播跑得慢一点但能发现模块间的问题。冒烟测试测整个训练流程能不能跑通用极小的数据集和极少的步数确保没有低级错误。写测试的初期会感觉浪费时间但一旦你的项目超过一定规模测试就是你的安全网。我自己的经验是有测试的项目改代码时心里有底没测试的项目改代码时提心吊胆。4. 第二阶段建立对AI系统的完整认知4.1 数据管道AI系统里最容易被低估的部分如果你问我AI项目里哪个环节最容易出问题我会毫不犹豫地说数据。模型可以换框架可以换但数据管道一旦出问题整个系统就是空中楼阁。一个完整的数据管道至少包括数据采集、数据清洗、数据标注、数据存储、数据加载这几个环节。每个环节都有它的坑。数据采集的坑在于来源多样、格式不一。你可能从数据库里拉数据从文件系统里读数据从API里抓数据每种来源的格式、编码、时区都可能不一样。我的做法是不管来源是什么先统一转成一种中间格式比如Parquet或者TFRecord然后再做后续处理。这样能把来源的差异性隔离在管道的最前端。数据清洗的坑在于规则难定义、效果难评估。什么算脏数据缺失值怎么处理异常值怎么判断这些问题没有标准答案得结合具体业务来定。我的经验是清洗规则要可配置、可追溯每一条被清洗掉的数据都要有记录这样出问题时能回溯。数据标注的坑在于质量和一致性。如果是人工标注不同标注员的判断标准可能不一样如果是自动标注标注模型的偏差会传递到下游。我的做法是标注规范要写得极其详细每个类别都要有正例和反例标注完成后要抽样检查计算标注员之间的一致性指标。数据加载的坑在于效率和正确性。数据量大的时候加载速度可能成为训练瓶颈数据预处理逻辑如果放在训练循环里可能拖慢训练速度。我的做法是用torch.utils.data.Dataset和DataLoader把加载逻辑封装好预处理能离线做的就离线做能缓存的就缓存。4.2 模型训练不只是调参模型训练这件事新手关注的是“用什么优化器、学习率设多少”老手关注的是“训练是否可复现、是否可监控、是否可中断恢复”。可复现意味着你设置一个随机种子同样的代码跑两遍结果应该完全一样。这要求你固定所有随机源Python的random、NumPy的random、框架的random、CUDA的随机性。我通常会在训练脚本开头写一个set_seed函数把所有随机种子都设上。可监控意味着你能实时看到训练过程中的关键指标loss、学习率、梯度范数、吞吐量、显存占用。这些指标能帮你判断训练是否正常。比如梯度范数突然变得很大可能是梯度爆炸loss突然变成NaN可能是学习率太大或者数据有问题。我习惯用TensorBoard或者Weights Biases来记录这些指标训练过程中随时能看。可中断恢复意味着训练中断后能从最近的checkpoint继续而不是从头开始。这要求你定期保存checkpoint包括模型参数、优化器状态、学习率调度器状态、当前的epoch和step。我通常每N个step保存一次同时在训练结束时保存最终模型。4.3 模型评估别只看准确率模型评估是另一个容易被简化的环节。很多人训完模型在测试集上跑一下准确率就认为评估完成了。这远远不够。评估至少要回答三个问题模型在整体数据上表现如何、模型在不同子群体上表现如何、模型的错误是什么样的。第一个问题用整体指标回答比如准确率、F1、AUC。第二个问题需要做分组评估比如按性别、年龄、地区分组看模型在不同群体上的表现是否有显著差异。第三个问题需要做错误分析把模型预测错误的样本拿出来看找规律。我自己的习惯是每次模型评估都生成一个评估报告包括整体指标、分组指标、混淆矩阵、错误样本示例。这个报告不仅帮我判断模型好坏还帮我决定下一步该往哪个方向优化。4.4 模型部署从notebook到生产环境模型部署是把训练好的模型变成可用服务的过程。这个过程涉及很多工程决策用什么框架做推理、怎么打包模型、怎么设计API、怎么处理并发、怎么监控服务。推理框架的选择取决于你的场景。如果追求极致性能可以用TensorRT或者ONNX Runtime如果追求开发效率可以用TorchServe或者Triton如果模型比较简单直接用Flask或者FastAPI包一下也行。我的建议是先用最简单的方案把服务跑起来有性能问题再优化。模型打包要考虑版本管理。每个模型版本应该有唯一的标识服务能根据请求路由到不同版本。这要求你把模型文件、配置文件、预处理逻辑打包在一起而不是散落在各处。API设计要遵循RESTful规范输入输出用JSON格式错误码要清晰。我通常会把API设计成/predict接收输入返回预测结果/health返回服务健康状态/metadata返回模型版本和配置信息。并发处理要考虑推理的并行性。如果模型推理是CPU密集型的可以用多进程如果是GPU密集型的可以用批处理。批处理能显著提高GPU利用率但会增加延迟需要根据业务需求权衡。服务监控要记录请求量、延迟、错误率、GPU利用率这些指标。这些指标能帮你发现服务异常也能帮你做容量规划。5. 第三阶段在真实项目里把能力串起来5.1 选一个“小但完整”的项目从零搭建AI工程能力最有效的方式是做一个“小但完整”的项目。什么叫小但完整就是数据量不大、模型不复杂但整个流程是完整的从数据采集到模型部署到服务监控每个环节都走一遍。我通常建议从图像分类或者文本分类入手。这两个任务的数据容易获取模型有现成的预训练权重评估指标也直观。你可以用公开数据集比如CIFAR-10或者IMDB评论先跑通一个baseline然后逐步优化。项目虽小但要求不能低。数据管道要写得规范训练代码要模块化评估要全面部署要能跑起来监控要能看到指标。这个项目做完你对AI工程的全流程就有了体感后面做更大的项目就是在这个基础上扩展。5.2 把项目拆成可验证的小步骤做项目的过程中最容易犯的错误是“一口气写完再跑”。这种做法的风险是一旦跑不通你不知道是哪个环节出了问题。我的做法是把项目拆成可验证的小步骤每一步都有明确的输入输出和验证方法。比如第一步是数据加载验证方法是打印几条样本看看格式对不对第二步是模型定义验证方法是跑一个前向传播看看输出形状对不对第三步是训练循环验证方法是跑几个step看看loss有没有下降第四步是评估验证方法是在小数据集上跑一下看看指标是否合理第五步是部署验证方法是发一个请求看看能不能返回结果。每一步验证通过再进入下一步这样出问题时能快速定位。这个习惯看起来慢实际上快因为它避免了“写完一大坨代码然后花几天debug”的情况。5.3 记录你的决策和踩坑做项目的过程中你会做很多决策为什么选这个框架、为什么用这个参数、为什么这么设计架构。这些决策如果不记录过一段时间就忘了下次遇到类似问题还得重新想一遍。我自己的习惯是维护一个项目日志每做一个重要决策就记一笔包括决策内容、决策理由、备选方案、预期影响。踩了坑也记一笔包括问题现象、排查过程、根本原因、解决方案。这个日志在项目复盘时特别有用也能帮你在面试或者分享时讲清楚你的思路。5.4 从“能跑”到“跑得好”项目能跑通之后下一步是优化。优化的方向有很多数据加载能不能更快、模型推理能不能更省显存、服务延迟能不能更低、代码结构能不能更清晰。优化的原则是先测量再优化。不要凭感觉猜哪里慢用profiler测一下找到真正的瓶颈再动手。我见过太多人花大力气优化了一个不重要的环节真正的瓶颈还在那里。优化的另一个原则是保持可回退。每次优化都应该是独立的、可回退的这样如果优化后效果变差你能快速回到之前的状态。我通常会把优化前后的指标都记录下来用数据说话。6. 常见问题与排查技巧实录6.1 训练不收敛怎么办训练不收敛是新手最常遇到的问题。排查思路可以按这个顺序来。先看数据。数据有没有问题标签对不对输入范围是否合理我遇到过一次数据加载时把图像归一化参数搞错了导致输入范围不对模型怎么训都不收敛。排查方法很简单打印几条样本看看数值范围是否在合理区间。再看模型。模型结构有没有问题输出层激活函数对不对损失函数选得对不对分类任务用交叉熵回归任务用MSE这些基本的东西不能搞错。然后看超参数。学习率是不是太大或太小batch size是不是合适优化器选得对不对学习率太大loss会震荡甚至爆炸太小loss下降很慢。我通常会用学习率扫描从1e-5到1e-1试几个值看哪个收敛最好。最后看训练过程。梯度有没有爆炸或消失可以用梯度裁剪来缓解。有没有过拟合如果训练loss下降但验证loss上升那就是过拟合需要加正则化或者更多数据。6.2 显存不够怎么办显存不够是训练大模型时的常见问题。解决方法有几个方向。减小batch size是最直接的方法但可能影响训练稳定性。梯度累积可以在小batch size下模拟大batch size的效果每N个step更新一次参数。混合精度训练用fp16代替fp32能省一半显存但要注意数值稳定性。梯度检查点用计算换显存在前向传播时不保存中间激活反向传播时重新计算。模型并行把模型拆到多张卡上适合超大模型。我自己的经验是先试混合精度不行再试梯度累积还不行再试梯度检查点。这几个方法组合起来能解决大部分显存问题。6.3 推理速度慢怎么办推理速度慢的排查要先定位瓶颈在哪。用profiler测一下是数据预处理慢、模型前向慢、还是后处理慢。如果是数据预处理慢可以把预处理逻辑移到GPU上或者用更高效的库。如果是模型前向慢可以尝试量化、剪枝、蒸馏这些模型压缩方法或者换更快的推理框架。如果是后处理慢可以优化后处理逻辑或者把后处理也放到GPU上。批处理是提高推理吞吐的有效方法。把多个请求攒成一个batch一起推理能显著提高GPU利用率。但批处理会增加延迟需要根据业务需求权衡batch size。6.4 线上效果比离线差怎么办线上效果比离线差通常有几个原因。数据分布不一致线上数据跟训练数据分布不同模型泛化能力不够。特征计算不一致线上特征计算逻辑跟离线不同导致输入有偏差。评估指标不一致离线用的指标跟线上业务指标不同离线好不代表线上好。排查方法是把线上出问题的样本拿回来在离线环境跑一遍看模型输出是否跟线上一致。如果不一致那就是特征计算或者预处理逻辑有问题。如果一致但效果不好那就是数据分布或者模型泛化的问题。6.5 常见问题速查表问题现象可能原因排查方法解决方案loss不下降学习率太小、数据有问题、模型结构有问题检查数据范围、试不同学习率、检查模型输出调整学习率、修复数据、修改模型loss变NaN学习率太大、梯度爆炸、数据有异常值检查学习率、看梯度范数、检查数据降低学习率、加梯度裁剪、清洗数据显存不够batch size太大、模型太大、中间激活太多看显存占用、试小batch、看模型参数量减小batch、混合精度、梯度检查点推理慢预处理慢、模型大、后处理慢用profiler定位瓶颈优化预处理、模型压缩、批处理线上效果差数据分布不一致、特征计算不一致对比线上线下样本重新训练、统一特征计算7. 我自己的学习路径和一些真心话7.1 我是怎么走过来的我最早是做传统机器学习的那时候还没有“AI工程”这个词。后来深度学习火起来我转过去做模型训练再后来发现光会训模型不够又开始学部署、学工程化。这个过程走了不少弯路也积累了一些经验。如果让我重新走一遍我会这样安排先用一个月把Python工程能力补上包括模块化、类型标注、测试、Git这些。再用一个月学一个深度学习框架把训练、评估、部署的流程跑通。然后用两个月做一个完整的小项目从数据到部署全走一遍。最后在具体工作中不断深化遇到什么问题学什么。这个路径的关键是不要跳步。工程基本功不扎实后面学什么都是空中楼阁。项目不完整做一遍对AI系统的认知就是碎片化的。7.2 一些反常识的经验经验一不要追求最新工具。AI领域工具更新很快但核心概念变化很慢。与其追新工具不如把核心概念吃透。工具会过时概念不会。经验二不要只学一个框架。PyTorch和TensorFlow各有优劣多了解一个框架能帮你理解哪些是框架特性、哪些是通用概念。但也不要贪多精通一个再学另一个。经验三不要忽视软技能。AI工程师不是只跟机器打交道还要跟产品经理、数据标注员、运维工程师协作。沟通能力、文档能力、项目管理能力这些软技能决定了你能走多远。经验四不要怕犯错。AI工程里没有标准答案很多决策都是在信息不完全的情况下做的。犯错不可怕可怕的是不记录、不反思、不改进。7.3 给不同阶段读者的建议如果你还在学校我的建议是把基础课学好。数学、编程、算法这些基础课当时觉得没用工作后才发现处处都用得上。另外多动手做项目哪怕是小项目完整做一遍比看十本书都有用。如果你刚工作不久我的建议是找一个完整的项目跟到底。不要只做其中一小块要争取从需求到上线全流程参与。这个过程能帮你建立全局观知道每个环节怎么衔接。如果你已经工作几年想转型我的建议是利用现有优势。你之前的工作经验不是白费的比如你做后端开发那服务部署、性能优化这些就是你的优势你做数据分析那数据管道、特征工程就是你的优势。把AI能力跟现有优势结合比从零开始更有竞争力。7.4 最后分享一个小技巧如果你觉得AI工程涉及的东西太多、不知道从哪下手我建议你用一个笨办法拿一张纸把你能想到的所有环节都写下来然后按依赖关系排序。比如数据加载依赖数据存储模型训练依赖数据加载模型部署依赖模型训练。排完序之后从最底层的环节开始一个一个攻克。这个办法看起来简单但能帮你理清思路避免东一榔头西一棒子。我每次接手新项目都会这么做效果很好。另外我强烈建议你维护一个自己的代码片段库。把常用的代码片段整理好比如数据加载模板、训练循环模板、评估指标计算、服务部署模板。下次做新项目时直接复制粘贴改一改能省很多时间。这个库会随着你的经验增长越来越丰富最终成为你最宝贵的资产。AI工程这条路没有捷径但有方法。方法对了每一步都算数。