去年年底我被一个做工业视觉检测的朋友拉去救火他们团队拼了三个月把缺陷识别模型精度提到了 98%可上了产线之后每两小时崩一次推理延迟动不动飙到 800 毫秒处理不过来流水线上的图像流。我过去一看代码里torch.load之后直接在 GPU 上跑连批处理都没做特征归一化的参数是在训练集上算的换成实时数据分布稍微漂移就直接失效。那一刻我特别想说这就是典型的会建模但不会 AI 工程。我自己的感觉是现在网上谈 ai-engineering 的内容不少但大部分要么是单点工具教程要么是某个框架的中文文档搬运很少有人真正把从零开始做 AI 工程这件事拆成一条可以走的路线。所以这篇我打算用最直白的话把我从只会写模型代码到能带着小团队把模型稳定跑上线这整个过程里最核心的东西一次讲透。适合两类人看一是已经会一点 Python 和机器学习、但总觉得项目落到工程上就四处漏风的同学二是刚入行、想走 AI 工程方向但不知道先学什么的小白。读完你至少能知道自己该往哪使劲、每个环节在解决什么问题、踩过的坑长什么样。这个标题叫 ai-engineering-from-scratch不是让你从线性代数开始啃也不是让你照着某本书的目录背概念——它指的是从手上有模型到线上有服务这中间的所有环节。我会按一条完整路线来讲环境与依赖怎么管、数据管线怎么搭、模型训练之后到底要做哪些事、推理服务怎么让它又快又稳、以及最容易被忽视的实验管理和回归测试。1. 从学AI到做AI工程先想清楚这层转变1.1 为什么多数人的入门路径注定低效我刚入门那会儿也经历过典型的模型崇拜期每天刷论文、复现模型、盯着 loss 曲线看半天觉得只要模型精度够高就万事大吉。直到有一次做完一个文本分类项目交付的时候对方问我你这个模型接口怎么部署出错了怎么排查每天自动更新一次数据要改哪些地方我当时一个都答不上来。这就是学 AI和做 AI 工程最大的区别。前者关心的是我怎么把模型训得更准后者关心的是我怎么能让模型稳定、高效、可维护地发挥作用。你可以把模型训练看成盖房子的图纸设计工程化是把房子真正盖起来并且通水通电。图纸好看不代表房子能住模型精度高也不代表系统能上线。从零开始做 ai-engineering你首先要建立一个大局观一个能跑的生产级 AI 系统从来不止是模型本身而是数据、训练、评估、部署、监控、迭代这六个环节组成的闭环。只盯着其中任何一块系统都长不大。1.2 从零开始应该先建立工程坐标系我建议你先别急着写代码花半天时间在脑子里画一张AI 工程坐标系把之后所有学的东西挂到对应坐标轴上。这张坐标系我到现在还在用画起来很简单横向是数据流转原始数据 → 清洗 → 特征 → 训练集/测试集 → 线上数据纵向是模型生命周期开发 → 训练 → 评估 → 打包 → 部署 → 监控 → 再训练垂直于这个平面的隐轴是环境与版本依赖、镜像、代码版本、数据版本、模型版本后面你学的每一项技术基本都能落到这三个维度上。比如 Docker 解决的是环境一致性问题对应纵轴的部署环节和隐轴的环境维度MLflow 解决的是实验可复现问题对应纵轴的评估环节和隐轴的版本维度。有了这个坐标系你会发现市面上的 AI 工程工具其实都是在帮你固定某几个环节。比如 Airflow 管的是数据流转的编排Ray 管的是训练和推理的分布式资源Kubeflow 管的是整条流水线在 Kubernetes 上的编排。它们没有多神秘都是因为你手动做某件事太容易出错才被造出来替代人力。2. 我的ai-engineering路线图六个阶段一次说清2.1 阶段一把 Python 写到肌肉记忆这一步听起来基础但淘汰了很多人。我说的会 Python不是能写函数、会用 pandas而是你对 Python 的执行机制有直觉GIL什么时候会成为瓶颈、__slots__怎么省内存、生成器怎么写才能处理流式数据、multiprocessing和threading在 I/O 密集和 CPU 密集场景下分别该怎么选。AI 工程里的大部分坑都是语言层面的。就拿读数据举例有人用 pandas 读 5GB 的 CSV读完内存爆了换成dtype指定、chunksize分批读或者直接用 polars效果立刻不一样。这种能力不是看教程看出来的得靠量。我一般建议新人每天写一到两个小脚本处理真实数据坚持一个月Python 手感就出来了。2.2 阶段二数据工程基本功这个阶段我被很多 AI 工程师朋友质疑过他们说我是做模型的为什么还要学数据工程等他们自己上线之后遇到特征不一致、数据延迟、训练测试分布漂移这类问题才回来补课。数据工程要掌握的核心其实就三件事怎么稳定地把数据拿进来、怎么清洗成模型要的格式、怎么保证训练时和上线时看到的数据结构完全一致。工具上至少要会 SQL会用 pandas 或 polars 做批处理了解 Kafka 之类的消息队列解决什么问题知道 dbt 这类工具怎么做数据转换的版本管理。我自己带项目的一个体会是数据工程占了 AI 项目里至少 40% 的工作量但它最不受重视。很多人宁可花两周调模型也不愿意花两天把数据管线理清楚最后线上出问题、根本原因几乎都指向数据。2.3 阶段三模型训练与调优训练这块是大家最熟的但工程视角下的训练和算法竞赛里的训练不太一样。工程上你更关心的是我的数据能不能按时喂给训练脚本、显存会不会爆、训练中断了能不能接着跑、超参有没有记录、换了一版数据之后模型效果到底是变好了还是数据变了。所以这个阶段我会先教大家用 PyTorch Lightning 或者 Hugging Face Trainer 这类框架把训练流程固定下来而不是一遍一遍手写训练循环。再用 WB 或 MLflow 记录每一次实验的超参、指标和产物。很多新人喜欢感觉型调参——改个学习率跑一晚上第二天看个 loss 数觉得差不多就往下走了。这种做法的致命伤是三个月后你根本说不清这个模型是用哪份数据、哪个代码版本、哪些参数训练出来的等出问题要回溯的时候一切都是一团黑。2.4 阶段四部署与推理优化这是从零到工程这条路上第一座真正的大山。模型在笔记本上跑得好不代表它能在生产服务器上扛住线上流量。部署阶段的核心矛盾是你要在精度、延迟、吞吐、显存四者之间找平衡。我在这个阶段会拆成两半来讲先学会把模型从开发格式导出成推理格式比如 PyTorch 的.pt导出为 ONNX 或者 TorchScript再用 ONNX Runtime 或 TensorRT 做推理加速再学会写一个标准的模型服务接口用 FastAPI 包一层 HTTP 服务处理并发请求把输入数据校验、错误处理、超时控制都做好。这里有句我一直强调的话model.eval()和torch.no_grad()只是推理的基本功工程上真正决定性能的是批处理策略、缓存设计、并发模型和你选的数据结构。2.5 阶段五评估与回归绝大多数教程讲评估只会给你一个混淆矩阵、一个准确率。但工程里的评估要复杂得多。你要回答的问题不只是模型准不准还有模型上线后会不会在某些样本上表现急剧下降新版本模型相比旧版本在核心业务指标上到底有没有变好哪些数据分布偏移会让模型失效。这个阶段我建议重点学会三件事一是构建一个覆盖核心场景的验证集而不是随机抽取的训练集子集二是做模型 A/B 测试用统计学方法判断新旧模型差异是否显著三是对模型做鲁棒性测试比如输入加噪声、缺字段、顺序打乱看模型的反应。每一步都有对应工具但核心是你得先有这个意识否则工具摆在那里你也不知道用。2.6 阶段六生产环境闭环最后一个阶段是很多人从来没接触过的监控、告警、日志、模型自动退役。模型不是部署完就结束了它是一个需要持续照看的线上服务。我在生产环境必备的三板斧是第一记录每次请求的输入和模型预测结果存成日志方便回溯第二监控推理延迟和吞吐量设置告警阈值第三定期用线上真实数据重跑一遍离线评估和基准模型对比发现退化及时告警。这个闭环搭起来之后你才算是真正从零开始把 AI 工程完整走了一遍。3. 核心技能拆解每个环节到底在学什么、为什么3.1 环境管理先把能跑和可复现分开环境问题是我见过最多的翻车现场。上周还跑得好好的训练脚本这周换了台服务器CUDA 版本不对、依赖冲突一跑就报错。很多新人解决方式是重新 conda install 装一遍装到最后能跑了但要问一句你用的哪个 Python 版本、哪个库的哪个版本回答不出来。环境管理的核心原则是能跑不等于可复现。能跑是你机器上的偶然状态可复现是别人在任何环境下都能还原你的运行结果。工程上标准做法分三层Python 解释器版本用pyenv或conda管理每层依赖用requirements.txt或poetry.lock固定精确版本不只锁大版本要锁到1.13.3这种级别整个运行环境用 Docker 镜像固化下来镜像和代码一起提交。我见过最推荐的组合是 Docker PoetryDocker 保证系统层面的库CUDA、cuDNN、系统依赖一致Poetry 保证 Python 依赖一致。很多人图省事只锁requirements.txt系统层换了照样崩。提示训练环境和推理环境要分开。训练环境可以随便装、随便试但推理环境越精简越好。我见过有人把训练环境整个搬上线多出一堆用不到的库不仅镜像大到几 GB还暴露了不必要的攻击面。3.2 数据管线特征工程不是玄学数据管线这个环节从零开始的人最容易忽略。很多人有一个误区觉得只要模型结构够强数据随便喂就行。实际上数据和特征的质量决定了模型精度的上限模型只是在逼近这个上限。数据管线工程化之后要解决的核心问题是清洗逻辑可复用、特征计算可复现、线上线下特征保持一致。比如你用 pandas 在某次脚本里顺手fillna(0)但等线上推理时你没有做同样的预处理模型直接崩。解决方式是把数据预处理和特征工程抽成独立的模块训练时和推理时调用同一个函数。我更喜欢用一个专门的特征变换库把这件事固定下来训练时fit_transform保存变换参数推理时读取参数transform。比如标准化用的均值和方差、类别编码用的映射表都必须训练时保存、推理时加载。这算是 AI 工程里最重要的细节没有之一。3.3 模型训练从跑通到收敛模型训练这块我会建议大家先把一个链路跑通再谈优化。拿 NLP 里的文本分类举例第一条链路是加载预训练模型 → 加载数据 → 训练若干 epoch → 保存 checkpoint → 评估。把这条链路跑通了你就有了一个原地能转的轮子。第二步才谈收敛。收敛不是 loss 越低越好而是验证集指标不再显著提升。很多新人训练时只盯着训练集 loss等到过拟合了才发现验证集指标早就开始掉了。我每次训练都会在显式地设置早停条件比如验证集准确率连续三轮不上升就停同时保存验证集最优的 checkpoint而不是最后一个 epoch 的 checkpoint。训练速度和显存也是这一阶段要处理的。数据加载慢导致 GPU 空转是新手最爱犯的问题解决方式是用DataLoader的num_workers开多进程预取显存不够先检查是不是 batch size 开大了再看能不能用梯度累积、混合精度训练AMP、模型并行这些手段。AMP 是最划算的优化手段训练速度常常直接提升 30% 以上显存也能省一半。3.4 推理加速量化、剪枝、蒸馏选哪个训练搞定了接下来就是让模型上线后跑得快。推理加速的常见手段有三类量化、剪枝、蒸馏很多新人一上来就问哪个效果最好这个问题本身就问错了。先看对比手段原理适合场景代价加速幅度量化PTQ/QAT降低参数精度比如 FP16、INT8CPU/GPU 推理对精度容忍度较高的场景可能有少量精度损失需要校准2-4倍剪枝删除不重要的权重或神经元模型过大、算力紧张的边缘场景需要重新微调过程繁琐视剪枝比例而定蒸馏用大模型Teacher教小模型Student场景固定、可以离线训练且算力长期受限需要训练一个额外的大模型可压缩数十倍我自己的选型思路是能量化先量化因为它是成本最小的加速度方案如果量化后精度掉得不能接受再考虑剪枝或蒸馏。比如用 ONNX Runtime 跑 INT8 量化只需要准备一小部分校准数据跑一轮工具推理速度明显上来精度损失通常控制在可接受范围内。TensorRT 在 NVIDIA GPU 上还会做层融合和内核优化比原生 PyTorch 推理快很多。但这里我要说句泼冷水的话推理加速永远是在精度和速度间做折中而且是和业务一起做的决策。不要为了炫技把一个 98% 精度的模型量化到只剩 95%然后告诉业务方这是工程优化的必要代价。你得先问清楚业务底线在哪。3.5 实验管理让90%的努力不白费实验管理是 AI 工程里最隐形但最值钱的一环。我看了太多团队做实验的原始方式训练脚本里手动改超参结果自动存到某个带日期的目录里模型文件名还是best_model_final_v2_realFinal这种。等到要复盘翻遍目录也找不到当初用的数据集版本和模型得分。工程化的实验管理要做到三件事每次运行记录超参、数据版本、代码版本自动记录指标曲线和模型产物实验之间能横向对比。目前我常用的工具是 MLflow它把每次 run 的所有信息打包记录调用mlflow.log_param()记录超参、mlflow.log_metric()记录指标、mlflow.log_artifact()存模型和图片最后生成一个可对比的列表一目了然。注意实验管理和代码版本管理是两件事。代码版本管的是代码长什么样实验管理管的是数据、超参、环境长什么样。线上出问题要回溯这两者缺一不可。4. 零基础启动的实操路线照着做就能跑出一串项目4.1 用三个项目练出完整闭环这里我推荐一个三段式项目路线做完这三样你对 ai-engineering 的感知会完全不一样。第一个项目用分类任务练全流程。不用找太偏的数据集就用经典的手写数字识别或者中文评论情感分类把环境搭建 → 数据加载 → 训练跑通 → 导出模型 → 用 FastAPI 写服务 → 调用接口 → 简单监控日志完整走一遍不用追求精度多高重点是流程闭环两头都要通。第二个项目用目标检测或序列任务练工程难点。目标检测的数据标注、训练调参、NMS 后处理、评估 mAP每一步都能让你踩不少坑而这些坑基本是工业项目里躲不掉的。我建议第一次跑通之后把模型换成更小的版本比如从 YOLOv8 换成 YOLOv8n再量化导出 ONNX体验一次完整的加速优化。第三个项目做一个带数据更新的真实小应用。比如一个邮件分类助手每周新增数据重新训练后滚动更新模型。这个项目逼你去思考数据版本、模型版本、新旧模型对比这些只有真实迭代才会遇到的问题。4.2 从1.0到1.1给玩具项目装上工程架子很多教程到跑通就结束了但 AI 工程恰恰是从跑通之后开始的。我自己有一个习惯凡是项目里第一版能跑的代码我都会做一轮工程化改造把玩具变成半成品把散落各处的超参收敛到一个 config 文件里比如 YAML禁止在代码里到处用魔法数字把数据处理抽成可以单独测试的类或函数加几个针对边界情况的单测把训练和推理入口分别封装好这样以后换数据、换模型、换环境只动对应模块不必全盘重写给模型服务加最基础的接口校验至少保证输入格式错了能返回 400 而不是直接 500这个习惯坚持下来非常有用。从我的经验看大部分团队的项目死亡其实不是模型太差而是代码烂到没人想继续碰。工程化改造的成本很低收益却是指数级的。4.3 开源代码该怎么读、怎么抄、怎么改AI 工程这条路不一定要全靠自己摸索读开源代码是非常高效的学习方式。但新手读开源项目有个通病打开一个大型 repo 就想从头到尾读一遍没读几章就放弃了。我自己推荐的方法是以任务为入口倒着读先明确你想学会什么再顺着任务的调用链去找关键文件。举个具体例子。你想学推理服务怎么写就找一个模型服务框架或者当下热门的推理框架的仓库先看它的接口定义、路由注册、预处理入口、模型加载和推理函数再往深处看它是怎么做并发、怎么做动态批处理、怎么做超时和容错的。这样每一步都是在解决一个具体问题效率比通读源码高得多。直接拿来主义也有门道。我自己通常会先跑通别人项目里有 README 的 quickstart能跑起来之后再抄一部分自己需要的模块比如那个特征预处理模块然后按自己的场景重新组装一遍。只要能保证协议合规代码本身就是要拿来用的。5. 避坑与复盘犯过的错全在这里了5.1 版本地狱conda 与 pip 混装的教训有一次我把自己 Research 用的 conda 环境和线上推理环境合并下场就是 pip 弹一堆依赖冲突。conda 和 pip 共用同一个环境的坑就在于它们各自的依赖解析器不完全兼容pip 把包装进 conda 管理的 site-packagesconda 再更新其他包时可能直接覆盖掉。我的解决方案很粗暴但有效训练用 conda推理用 Docker pip两者不共用一个环境。训练环境不要轻易升级大版本升级之前先看有没有项目依赖被破坏。推理环境每次变更都重新构建镜像禁止在线上环境里手动 pip install。5.2 数据泄漏看起来不错却上线崩盘这是我见过最隐蔽的坑。有人做时间序列预测做特征时有一步用了未来数据去填充缺失值还有人做用户画像分类在训练集里做了全局标准化把测试集的均值也算进去了。两种问题的共同点是离线评估很漂亮一上线就离谱。数据泄漏的根本原因是你在训练阶段偷看了不该看到的信息。防止方法其实不复杂所有涉及全局统计的预处理都拆成 fit/transform 两步严格按照只用训练集 fit再用同一套参数 transform 测试集的原则时间序列场景做特征时时刻问自己我在 t 时刻能不能拿到这个值拿不到就不能用。5.3 误判过拟合与欠拟合的方向很多人一看到训练 loss 和验证 loss 差距大就喊过拟合立刻上 dropout、上正则、缩小模型。但在我接触的项目里更常见的情况是数据量太少导致的方差大和数据本身噪音大导致的验证集精度上不去。这两种问题的解法完全不同前者要增加数据或做数据增强后者要清洗数据或换更鲁棒的损失函数。我每次拿到一个训练表现异常的项目都会先做一个快速归因实验在一个很小的训练子集上把模型训到完全过拟合如果连小样本都训不到位说明模型的表达能力不够或数据有问题不是病急乱投医调正则的时候。5.4 GPU 显存和采样策略的纠结最后聊一个工程细节--采样策略。做图像相关项目时输入分辨率是显存消耗的头号因素有人 512×512 能跑得好好的换成 1024×1024 直接 OOM连夜调代码。我的建议是显存有限时先降 batch size保持输入分辨率不变如果模型有 BatchNorm降低 batch size 会影响统计量可以改用 GroupNorm 或做梯度累积。数据加载慢、GPU 空转的问题也一样常见。默认的DataLoader不开num_workersGPU 每轮都在等 CPU 喂数据训练效率大打折扣。把num_workers设成 CPU 核数的四分之一到二分之一配合pin_memoryTrue是你最省力的提速手段。注意这些技巧都建立在一个前提下——你清楚瓶颈在哪。动手之前先打开nvidia-smi看一眼显存利用率再随便打点日志看 CPU 数据加载耗时。工程优化最忌讳的就是凭感觉瞎猜。写到这里回头看我刚入行时犯的那些错搞不定的环境、脏乱的数据流、没法回溯的实验、上线即崩的模型其实都指向同一个问题——当时我只把 AI 当成算法竞赛而在真实世界里AI 是要作为系统的一部分稳定运行、随时能被接管和迭代的。从零开始做 AI 工程最重要的不是多深的数学、多新的模型而是你愿不愿意在没人看见的地方把细节抠干净。我个人走到现在的最大体会是精度和漂亮的曲线只能证明你训了一个模型稳定、可复现、能止血、能迭代才叫真正做出了一个 AI 系统。