前阵子好几个朋友都在问我同一个问题AI工程到底从哪里开始网上的资料倒是一大堆但要么是纯算法理论推导要么是某个工具的使用手册中间那条“从零到能落地”的路径反而没人系统性地讲清楚。我干脆把自己从只会调参到能把一套完整AI应用推上线再到能稳定维护这套系统的经验整理成了一个项目名字就叫 ai-engineering-from-scratch。这个项目不是又一个教程合集而是一份从零开始做AI工程的路线图加实操手册里面完整记录了我在数据准备、模型训练、部署上线、线上监控这一整条链路上踩过的坑、验证过的方案和觉得值得反复看的细节。今天这篇就是把这个项目的设计思路、核心模块、实操细节和常见问题一次性拆开聊聊。1. 项目定位与整体思路1.1 为什么叫“from scratch”“from scratch”不是说让你从高等数学第一页开始学起而是要求你亲手把一条完整的AI应用链路拉通。很多时候我们习惯拿来一个模型直接fit数据是现成的环境是配置好的代码是别人写好的运行一下就能出结果但这中间其实隔着一层纱。一旦遇到真实问题比如数据格式变化、模型版本回滚、线上推理延迟上涨很多人就卡住了因为从来没有亲手处理过这些环节。这个项目把AI工程拆成了几个大块数据、训练、评估、部署、监控、迭代。每一块都要求学习者亲手做一遍而不是只看代码。我的判断标准很简单如果换一台完全干净的机器你能否仅仅凭项目里的文档就把整个系统重新拉起来。能做到这一点才算真正跨越了“只会跑别人代码”的阶段。还有一个考虑是很多公开的教程喜欢跳过数据工程直接拿现成数据集训练模型但真实生产项目里数据问题占掉的时间往往超过70%。所以这个项目从第一版开始就把数据工程放在非常靠前的位置而不是让它作为“补充阅读”存在。1.2 这个项目解决什么问题我总结了一下身边想转AI工程的开发者最常被三件事卡住。第一是知识断层。会训练模型但不会部署会写Python但不懂机器学习生命周期懂一点算法但不知道如何设计一个可评估、可回滚、可监控的AI系统。断层导致的结果是模型训练完了就结束了根本到不了业务侧。第二是工具碎片化。很多人用过TensorBoard、MLflow、Docker、Kubernetes但不知道它们各自应该在什么阶段出现更不知道如何串成一条流水线。工具不在多关键在于它们能不能衔接起来。这个项目里我把每一个工具放在它真正发挥作用的位置去讲而不是单独罗列功能介绍。第三是复现困难。每次实验改了点参数下次想找回上次的结果却发现环境和数据都变了代码也没记录模型文件不知道存哪了。这是非常可怕的问题。项目里特意设计了一套实验记录机制哪怕是个人小项目也要把版本管理、数据追踪、指标记录当成规范动作。1.3 适合谁不适合谁适合已经懂一点机器学习基础想往工程方向深入但被“模型训练”和“系统落地”之间那道墙卡住的工程师。也适合刚入门但目标明确想直接做AI应用开发的初学者。项目里每个模块我都尽量从零讲起但希望你至少有Python基础、知道常见机器学习概念。不适合谁呢不适合想一周内学会所有算法的人也不适合想不写代码、只靠拖拽工具做AI的人。这个项目默认你会动手写代码而且愿意反复折腾。2. AI工程的核心知识模块2.1 底子不是背公式而是能推演很多人一听说AI工程就觉得数学门槛高不可攀。实际上工程实践需要的数学知识并不是那种钻研到论文级别的深度而是要能理解每一步操作背后的原理。我的建议是别从教科书第一页啃起而是从问题反推。比如做文本分类时为什么TF-IDF之后向量维度那么大还能算相似度这里用的就是线性代数里的矩阵运算和稀疏表示。再比如训练神经网络时梯度经常出现爆炸或消失这背后的核心就是链式法则和激活函数导数的性质。编程方面Python绕不开但不是会写个for循环就行了。你需要熟练使用NumPy、Pandas、Matplotlib这些库能独立完成数据清洗能通过可视化发现数据分布问题能写一个可复用的小工具类。这个项目里我把这些基础内容都压缩成“最小可运行”的示例放在前面每个示例都标注了阅读顺序和动手练习建议。我自己在实际陪跑过程中发现真正让初学者崩溃的并不是数学公式而是“看着代码能跑但不知道每一步在干什么”。所以我给每个基础示例都加了“为什么要这样写”的注释而不是只贴代码。这是这个项目一个比较核心的特点。2.2 数据工程动手改数据比调参更重要数据质量决定模型上限这句话我说一百遍都不腻。从零开始的AI工程必须把数据工程当成第一优先级。这个项目里数据这块我拆成了几层。数据获取与聚合。真实场景的数据很少会是一个完美的CSV更多是分散在数据库、日志、API甚至外部爬虫里的碎片。你需要写代码把这些数据聚合起来并且处理接口限流、字段不一致、格式混乱这些脏活累活。数据清洗。缺失值怎么处理是直接删、填充还是建模预测异常值是保留还是剔除重复记录怎么去重这些听起来很简单但每一条都需要结合业务场景去判断。例如预测用户流失时那些从来没有真正活跃过的账号算不算真实用户如果算很可能把模型带偏。标签设计。监督学习必须有标签但标签怎么定义、由谁标注、标注一致性怎么验证很多人第一次做的时候都会懵。项目里我分享了一个小技巧在正式标注前先做一次小范围的试标然后计算标注员之间的一致性如果一致性太低那一定是对标签定义理解有偏差需要先修正标准再扩大标注规模。切分策略。训练集、验证集、测试集不能简单用随机切分。时间序列类数据必须按照时间切分防止未来信息泄漏。如果正负样本不均衡还要考虑分层采样。我见过不止一个人因为切分不当导致模型在测试集上看起来效果很好一上线就崩。还有一个特别容易被忽略的点数据版本。训练样本是动态变化的如果不给数据集打版本标记那么模型版本和数据集版本之间就永远对不上。这个项目里我强制要求使用数据版本工具至少在每个数据集目录下保存一个hash值、创建时间和数据描述这是一个成本极低但收益极高的习惯。2.3 模型训练与评估一切以可验证为前提模型训练这块最容易犯的错误是一上来就想调一个SOTA模型。我的建议是先跑通再优化。先做一个最简单的baseline哪怕只是一个线性模型也要保证全流程能走通。然后再去尝试更复杂的模型、加特征、做超参数搜索。每一次改动都要有记录否则你怎么知道哪个改动真正带来了提升评估指标不能只看一个数字。分类任务要看准确率、召回率、F1但在业务场景里还要关心最差样本的表现。回归任务除了MAE、RMSE还要看误差分布是否有极端离群点被模型严重预测错误。做一个好的评估集非常重要而且评估集要尽量贴近线上真实分布否则离线结果很漂亮线上完全不是一回事。这个项目里推荐使用实验跟踪工具比如MLflow或者WB。每次实验的代码版本、参数配置、训练数据版本、评估指标、模型文件都要记录下来。原因很简单当你有上百次实验后你不可能记住所有细节实验跟踪是你唯一可信的记忆系统。它不是一个可选项而是必需品。3. 工程化落地从Notebook到生产系统3.1 部署形态与推理优化模型训练完成后被低估得最严重的就是部署环节。很多人觉得把模型保存下来写个Python脚本调用预测就算完事了。但在真实业务中这远远不够。部署的第一个选择是形态。最轻量的是把模型包成一个REST API服务适合内部工具、离线分析或者实时性要求不高的场景。如果要求低延迟例如互联网产品里的实时推荐那么就要考虑用模型量化、剪枝或者用更高效的语言重写推理路径又或者直接上推理服务框架。这个项目里不会一上来就让你上K8s而是先把单机的部署和性能调明白。我自己常用的做法是先用FastAPI把一个模型包成最小服务把输入输出格式用Pydantic定义清楚然后做一轮压测。压测一般会暴露很多问题比如GPU显存占用过高、并发请求时排队延迟剧增、模型加载时间太长导致超时。这个时候再针对性地做优化而不是盲目追求高级架构。优化时要先确认瓶颈在哪里。如果瓶颈是模型推理本身可以考虑TensorRT、ONNX Runtime等加速推理引擎如果瓶颈是网络IO可以调整服务并发模型或使用连接池如果瓶颈是数据预处理可以把它放到模型输入之前做批处理。很多时候问题比你想的更朴素。3.2 MLOps基础版本、CI/CD、监控不少人听到MLOps就头大觉得这是大厂才需要的东西。其实它本质上是把软件工程的最佳实践搬进机器学习生命周期。哪怕你只是一个人开发也应该具备下面这些意识。代码版本管理。所有训练、评估、部署代码都进Git仓库不能有“这一版训练代码没问题先放桌面”这种操作。模型版本管理。一个模型文件应该对应一个明确的版本号记录它的结构、参数、训练数据和指标。数据版本管理。数据一旦被用于训练或测试就应该被固定下来不能事后偷偷修改。CI/CD不是只给Web应用用的训练流程、评估流程、部署流程都可以做成自动化的流水线测试通过后自动发布。监控则是必须一开始就考虑的事情。线上预测结果要记录分布、延迟、错误率还要定期跟训练时的分布对比。我见过很多人把MLOps当作一个“以后再说”的事情结果模型上线后出了漂移问题既不知道什么时候开始的也没有数据可以追溯只能回滚到“看起来没问题的版本”非常被动。这个项目里特意设计了一个很简单的监控模板用Grafana展示预测分布和延迟指标让新手也能建立最基本的可观测性。3.3 一个最小可落地的端到端案例为了把前面所有模块串起来这个项目里内置了一个端到端案例从一份原始日志数据出发构建用户流失预测系统。整个链路包括数据清洗、特征构造、模型训练、评估筛选、打包API、容器化部署再加一个简单的监控页面。案例用docker-compose拉起来换一台干净的机器也能一键启动。这个案例的业务很朴素但价值在于完整。你会看到数据定义和模型代码如何组织、模型文件如何挂载、API服务如何读取模型、监控如何采集线上指标。很多人在这一步会突然意识到原来训练一个模型只是整个系统里很小的一部分前面有数据管线后面有服务架构和运维。做完这个案例你基本能够理解AI工程的全貌了后面再遇到更复杂的框架也不会觉得无从下手。4. 实操过程与工具选型4.1 工具链选型对照很多初学者会陷入“工具选择恐惧症”生怕选错了浪费时间。我的建议是最小可行组合够用就行后面再按需替换。下面是我在这个项目里常用的一套组合。环节常用工具我的选择备注实验跟踪MLflow、WBMLflow可以本地一条命令跑起来支持模型注册数据版本DVC、dvc、自带脚本DVC习惯后能省很大的心训练代码PyTorch、TensorFlowPyTorch个人项目调试更灵活API服务FastAPI、FlaskFastAPI自带请求参数校验和文档省事容器化Docker、docker-composedocker-compose单机开发完全够用监控Prometheus Grafana同一套云原生标配理解一次通用这套组合的好处是每个环节都有清晰的边界且相互之间可以通过标准接口连接。比如MLflow记录模型产物DVC记录数据FastAPI读取模型并对外提供接口Prometheus采集服务指标。不需要学习一大堆新概念核心是把每个工具的职责搞清楚。4.2 几个必须养成的实操习惯这个项目里我反复强调几个习惯它们看起来琐碎但能帮你躲掉大部分返工。第一每次实验固定随机种子。如果随机种子不固定两次相同参数训练的结果可能相差很大你很难判断改动到底是有效还是随机波动。至少保证数据切分和模型初始化是可复现的。第二不修改历史实验记录。实验记录是随时间累积的如果发现某次实验的参数设置错了应该新建一条实验去修正而不是偷偷改掉旧记录否则之后的对比就全乱套了。第三代码和配置分离。训练脚本不要硬编码数据路径、超参数、模型保存位置外部传参或读取配置文件。这样方便切换环境也方便后面做超参数搜索。第四定期清理无用实验但保留一张结论摘要表。实验多了之后UI列表会非常乱。我会把有价值的结论写进项目的notes文件方便回顾然后清理掉历史垃圾实体。4.3 成本与效率的平衡个人开发者做AI工程经常遇到GPU资源不够。项目里我专门分享了一套成本控制方法论。核心思想是先用小数据验证再上全量。任何新想法都先在千分之一的数据上跑通确认有效后再花全量资源做正式实验。训练过程中可以开启混合精度速度提升明显显存占用也低很多。设置合理的早停策略loss不再下降就自动停止能省下一大笔开销。云服务器尽量选抢占式实例用完即关不要一直开着什么都没跑。另外一个很容易被忽略的浪费是“疯狂堆参数”。超参数搜索当然有用但不要让搜索空间无限扩大。先固定一批不敏感参数只对两三个关键参数做搜索性价比最高。5. 常见问题与排查技巧5.1 训练不收敛怎么办训练不收敛是最常见的问题。我一般按这样的顺序排查先看数据是否有异常特征是否归一化标签是否正确再看学习率是否过大或过小过大loss震荡甚至发散过小收敛太慢然后用一个小样本做“过拟合测试”比如只拿几十条数据看模型能不能把训练集背下来如果连这个都做不到那大概率是代码bug而不是模型问题。loss曲线的形态也很重要。如果loss一上来就是nan可能是梯度爆炸或存在NaN数据如果loss缓慢下降到某个平台就不动了可能卡在局部最优可以尝试换学习率策略或加动量。遇到问题不要急着换模型先用这些方法定位。5.2 离线指标很好线上效果差这是模型上线后最常见的翻车场景。首要嫌疑是数据分布漂移。线上实时特征分布和训练时的分布可能完全不一样最简单的检测方式是每天统计关键特征的均值和方差画趋势图。其次是训练测试切分泄漏比如对时间序列数据做了随机切分导致模型“偷偷”看到了未来信息离线表现虚高。再次是特征一致性问题线上请求中有某个特征缺失代码里用了默认值填充而这个默认值在训练时不存在模型输出自然就偏了。解决这些问题的前提是有监控和数据记录。如果一开始没有记录线上特征后面根本无从分析。所以我在项目里特意要求大家上线第一天就要记录预测分布而不是等出问题之后才想着补数据。5.3 环境依赖与复现问题“在我电脑上是好的”这句话在AI工程里同样危险。换一台机器跑训练代码可能因为Python版本、CUDA版本、依赖库版本差异结果完全不同。为了减少这类问题项目里要求使用虚拟环境或容器固定依赖版本并生成锁文件。镜像构建的时候要把训练、评估、部署用到的依赖都写清楚。即使不发布给别人你自己过三个月后再跑原来的项目也一样会遇到环境问题。所以把环境配置当成代码一样管理这是AI工程最基本也最容易被忽略的规范动作。6. 个人体会与扩展建议6.1 最想放弃的时刻按照这个项目从零走一遍大多数人会在“第一次端到端跑通之前”最想放弃。也许是docker-compose起不来也许是某个依赖版本冲突也许是模型接口返回的数据格式跟预期不一致。我当时也是这样反复折腾了两三天一度怀疑自己是不是不适合做AI工程。后来我总结出一个心法先别追求完美。用最简单的方式跑通一个完整流程哪怕只是一个极小的模型、一个很简陋的API、一个只能看一两个指标的页面先让整条链动起来。动起来之后再一点一点优化难度会小很多。这个心法也是我后来教很多新人时最常强调的一点。6.2 后续可以怎么扩展如果你走完这个项目会发现在这套流程之上还有很多可以深挖的方向。比如现在很火的LLM应用工程化同样离不开数据版本、评估集、可观测性和持续迭代这些底子。RAG系统里怎么评估检索效果token成本怎么监控这些本质上还是AI工程的问题。再往上走可以做特征平台、全链路可观测性、自动化模型评测甚至让整个AI系统具备自动修复和自愈能力。但不管方向怎么延展我在 ai-engineering-from-scratch 里搭建的那套骨架都还能复用。这也是我后来最欣慰的地方。