1. 先搞清楚AI工程和算法实验的边界1.1 从 notebook 到服务的距离提到AI工程这个词很多人第一反应是训练一个模型、调高几个指标甚至以为把Kaggle上的代码跑通就算入门了。我在被问过无数次模型精度不是已经到95%了吗怎么还不能上线之后才意识到大部分人对AI工程的理解完全偏了。两年前我接手过一个从零开始的AI工程任务把一个只在notebook里跑通的文本分类模型变成一套每天处理百万级请求的线上服务。那个项目前后花了七个月数据管线、训练框架、模型仓库、推理服务、监控告警全部重写真正让我明白一件事——AI工程的核心不是更聪明的模型而是一套能稳定支撑模型生命周期的系统。一个典型的算法实验长什么样拿数据、写预处理、切训练集测试集、跑模型、看混淆矩阵没了。但一个AI工程链路至少包含数据采集与版本管理、离线训练与评估、模型注册与镜像打包、线上推理与性能优化、反馈回收与持续迭代五层。你在notebook里拿到的95%准确率很可能在换一个数据分布之后就跌到80%以下你在本地环境能跑的推理代码放到线上容器里可能因为CUDA版本不一致直接崩掉。这些才是AI工程要处理的问题。那AI工程和算法实验的边界到底在哪我给一个很朴素的判断标准如果一份代码只要喂给它新数据、重新执行就能复现代上一次的结果并且中途不需要你手动改任何路径、参数或环境变量那它才算沾到了工程的边。否则那只是一个会动的实验。1.2 决定先做哪一层的工程化从零开始做AI工程最容易犯的错误就是什么都想一步到位。我见过一个团队上来就搭Kubernetes集群、搞分布式训练、上全套MLOps平台结果模型还没训明白先被运维问题拖垮了一个月。正确做法是先分清当前项目最痛的点在哪一层然后集中资源解决那一层。我自己的经验是分三步判断第一步看模型迭代效率。如果训练一次要三天、记录结果靠手写Excel那么优先做训练和实验管理。第二步看数据流转方式。如果数据还靠网盘传来传去、每次预处理结果不一样那么优先做数据版本化和Pipeline。第三步看线上稳定性。如果推理服务经常超时、模型更新一次要停机半小时那么优先做部署和监控。以我那个文本分类项目为例当时最痛的不是模型准确率——我们用的模型在测试集上已经不错了——而是训练数据每次都有微调导致同样的参数跑出来的结果忽高忽低。所以那轮的工程化重点全部放在数据固定和实验可复现上部署反而用了最简单的Flask加Docker先顶上去。先解决最痛的环节永远比追求工具链的大而全更有效。工具是补丁不是目的。2. 数据管线的工程化稳定性和可追溯是第一优先级2.1 用版本化数据集替代手工下载做AI工程这么久我有一条铁律数据必须是版本化的。模型可以换、参数可以调但训练集和验证集如果没法精确复现那所有实验对比都是空中楼阁。很多人一开始不重视这个我自己也吃过亏。有次我重新跑一个三周前的实验怎么跑都觉得比当时差了一点最后查了半天才发现当时用的那份数据文件已经被某个同事替换掉了一部分。从那之后我再也不允许项目里出现data_final_v2.csv、data_最新2024.csv这种文件名。现在我的标准做法是给每个数据集打上唯一的版本标识并在训练时记录这个标识。具体来说我会用一个类似这样的数据版本清单字段示例说明version2024.05.11-001按日期和当天序号生成的唯一版本号schema_hash7f3a91b2...数据列名和类型的一致性校验值row_count1,284,209数据行数便于快速检查source_paths3://bucket/raw/2024/05/11/原始数据的存储位置pipeline_hashb5c2e8f1...数据预处理代码的Git commit hash为什么要记录pipeline_hash因为很多所谓的数据版本变化根本不是原始数据变了而是预处理逻辑变了。比如你用正则清洗文本时多加了一条规则整个数据集的分布就会跟着变。如果不在训练时把预处理代码版本一起记录下来后面排查为什么模型效果变了会非常痛苦。如果你现在还在用Jupyter Notebook做数据清洗建议尽快把预处理逻辑抽成独立脚本放进Git管理。Notebook适合探索但不适合作为数据管线的唯一载体。原来在Notebook里顺序执行的一堆单元格很可能在换了执行顺序之后得到不同的结果。Pipeline脚本配上确定的执行入口和版本输出才具备工程层面的可靠性。2.2 数据校验与异常漂移处理数据的第二个工程化要点是校验。很多AI服务上线后效果劣化根本不是模型退化了而是线上到达的数据和训练时见过的数据长得不一样了。这种数据漂移是AI工程里最常见的慢性病。我第一次做线上监控的时候只盯着模型输出指标比如AUC、F1结果大概是上线第二周业务方反馈预测结果开始离谱而我这边看模型指标还一切正常。后来才发现线上有一条上游数据流把某个字段的含义改了原本这个字段是用户点击次数现在变成了用户曝光次数分布整个变了。模型根本没变变的是喂给它的数据。那之后我养成了一个习惯每次推理请求除了要预测的样本还会同时计算一组轻量级数据分布统计比如字段均值、方差、缺失率、类别分布。不一定要全量入库可以按分钟粒度做采样统计。一旦发现分布偏移超过阈值立刻告警并触发模型重训评估流程。我常用的一个简单规则是如果某一维特征的均值偏移超过训练期间均值的三倍标准差就判定为疑似漂移。当然阈值可以根据实际业务调整但原理是一致的——你必须在模型效果恶化之前先感知到输入分布的变化。另外数据校验还包括最基础的质量规则比如空值比例不能超过5%、类别特征取值必须在预设候选集内、数值特征范围不能超出合理区间。这些规则写起来不复杂但它们能把很多莫名其妙的效果下降挡在发生之前。3. 训练工程的落地经验可复现比单纯调参更重要3.1 配置驱动的训练脚本训练脚本的工程化改造是我觉得从零做AI工程性价比最高的一步。因为改造成本低收益却极其明显。最原始的训练代码长什么样一堆常量散落在代码里learning_rate 1e-4写在第50行batch_size 32写在第80行换一组参数就得改代码、重新跑还容易改错。工程化的做法是让训练流程由配置文件驱动把模型结构、数据路径、超参数、训练轮数、学习率调度等全部放到一个YAML或JSON文件里代码本身保持通用。我通常会用类似这样的目录结构experiments/ ├── baseline_0511/ │ ├── config.yaml │ ├── metrics.json │ ├── model.pt │ └── logs/ ├── dropout_add_0520/ │ ├── config.yaml │ ├── metrics.json │ ├── model.pt │ └── logs/每次实验就是一个独立的文件夹里面完整记录这次实验的配置、结果、模型权重和日志。这样有几个很直接的好处第一你对比两个实验时可以直接diff它们的config.yaml而不是靠回忆第二任何一次实验都可以被完整复现只要把config.yaml和代码commit hash对上第三后续做模型选型时你翻各个文件夹就能找到历史上表现最好的候选不需要去翻聊天记录。我之前遇到过有人跑来问我上次那个效果好的模型用的什么参数结果发现他只记在脑子里现在忘了。这个场景想必很多做过算法项目的人都熟悉。配置驱动训练脚本本质上是给每个实验建立起一份可检索的档案。3.2 实验记录与模型注册光有配置还不够实验结果的集中记录同样重要。做AI工程就像做菜如果你不记录盐放了几克、炒了几分钟下次想复制同一个味道基本靠运气。一个简单的实验记录表至少包含这几次信息experiment_name: text_cls_0511 dataset_version: 2024.05.11-001 config_file: experiments/text_cls_0511/config.yaml git_commit: b3af21d metrics: {accuracy: 0.914, f1: 0.892} model_uri: models/text_cls_0511/model.pt deployment_count: 2我建议把这份记录放到团队都能访问的地方可以是简化的MLflow也可以是一个只带插入权限的数据库表。一开始不用追求功能完整只要能回答清楚哪个实验用什么数据做了什么配置得到什么结果就够了。模型注册这一步容易被忽略。很多人训完模型就丢一堆.pt文件在硬盘里过几天连这个模型是拿什么数据训出来的都说不清。我自己的习惯是每次训练完把当次产出的模型打包成一个带元信息的产物至少包含模型文件、config.yaml、metrics.json、依赖环境的快照比如requirements-lock.txt然后上传到统一的模型仓库。这样后面不管是要回溯对比还是要把模型拉起来做线上推理都有据可依。一个很现实的场景线上模型出了问题需要回滚到上一个版本。如果你有模型注册机制回滚只是切换一个版本号的事如果没有你得去服务器上翻文件甚至可能因为模型格式不兼容而无法直接回滚。这种差异直接决定了事故的恢复时间是五分钟还是五小时。4. 部署与上线从离线模型到实时推理的坑4.1 模型格式的选型和转换模型训练完之后怎么把它变成线上能跑的服务是另一个容易翻车的环节。很多人以为只要把训练好的模型用Pickle保存写个Flask接口就能上线。模型小的时候确实可以但一旦模型变大、QPS上来事情就没那么简单了。在格式选型上我吃过一次亏。有一次我在PyTorch里训练了一个BERT类模型直接用torch.save保存了完整的模型对象然后拿到线上服务里加载。结果发现线上环境缺少模型定义代码里用到的一个辅助类加载直接报错。后来我学乖了优先采用标准的模型格式而不是私有的、依赖代码结构的Python对象。现在通用的做法是导出为ONNX格式或者至少用TorchScript来序列化。ONNX的好处是它把模型的计算图固化下来部署时不需要再依赖原始训练代码。以下是三种常见格式的对比格式适用场景主要优点主要坑点Pickle/torch.save实验阶段临时保存简单直接依赖代码结构跨环境容易坏TorchScriptPyTorch服务化部署保留动态控制流不需要原始类定义部分Python自定义算子不支持ONNX跨框架、跨硬件推理生态广支持GPU/CPU加速某些算子在转换时存在兼容性问题如果你只是做研究和快速验证Pickle足够但如果目标是长期运行的服务务必在部署之前完成格式的标准化。格式转换看起来只是多一个步骤实际是把你和训模型的代码解耦让推理服务可以独立演进。4.2 推理服务的压测与资源预估模型服务上线前的压测是我认为AI工程和算法Demo标志性的区别。很多算法工程师在本地一测响应时间几十毫秒就觉得可以上线了结果并发一上来延迟直接暴涨到几秒。我给新手一个简单的估算方法先确定线上预期的峰值QPS然后据此做压测。比如预计峰值每秒200个请求那你压测时至少压到300QPS保证有1.5倍冗余。压测过程别只盯着平均延迟要看P99延迟——也就是最慢的1%请求它往往才是用户体验的真实瓶颈。有一次压测一个通过ONNX部署的模型平均延迟只有45毫秒看起来非常理想。但压到高并发之后P99延迟突然跳到800毫秒一查原因发现是线程池配置过小大量请求在排队等CPU资源。把线程数从4调成16之后P99回到了80毫秒以内。这个例子充分说明模型本身的推理速度快不等于服务就快你还得把服务框架的开销、线程调度、内存带宽一起算进去。资源预估方面我常用的经验公式是单实例能扛住的QPS乘以实例数量要大于峰值QPS乘以波动系数。比如单机压测能扛300QPS线上峰值估计200QPS波动系数1.5那最低需要(200 * 1.5) / 300 1个实例考虑故障冗余再乘2也就是2个实例起步。千万别为了省成本把实例压到临界点AI服务的特征是一旦过载延迟会雪崩式恶化而不是优雅地降级。4.3 在线监控与回滚策略模型服务上线只是开始监控部署完之后才算真正结束。而且AI服务的监控比普通Web服务多一层——你不仅要监控CPU、内存、延迟、错误率还要监控模型预测质量本身。我记得第一版文本分类服务上线后一周内没有收到任何报错业务方也没投诉我以为一切正常。直到后来做了一次抽样人工审核才发现模型对一类长句子的分类结果已经全面偏掉了。为什么没发现因为我没有对预测结果做抽样监控。从那以后我的标准监控面板上至少包含五类指标基础设施层CPU使用率、内存占用、GPU显存、网络IO。服务层QPS、平均延迟、P99延迟、错误率。数据层输入特征均值、缺失率、离散特征分布。预测结果层预测置信度均值、各类别预测占比、被拒样本比例。业务层如有点击率、转化率、用户反馈率。监控不光是有没有挂更重要的是有没有正在变坏。而和监控同样重要的是回滚策略。模型更新不是一键切换就完了你必须保证旧版本模型随时可以被恢复。我的做法是每个版本模型部署到一个不覆盖旧版本的目录然后通过版本号切换流量的入口。比如统一通过一个model_name参数来指定当前线上使用的版本切换时只是改一个配置项而不是重新上传文件。这样一旦发现问题可以秒级回滚到上一个稳定版本。5. 给零基础者的六个月路线图5.1 按阶段划分的技能清单如果你完全是从零开始不知道从哪里下手我根据自己的经历整理了一个六个月的路线图。这个路线图不追求让你成为全栈专家而是让你在最短时间内把一条最小的AI工程链路完整跑通。有人可能会问不是应该先学算法吗我的回答是算法基础当然要学但不要先陷在算法里。你应该先有一条能跑通的全链路然后再逐步加深每一个环节。在一个端到端的项目里学东西比啃十本理论书高效得多。以下是我建议的阶段划分阶段时间核心任务产出物第一阶段第1-2月Python熟练 机器学习基础 完成一个Kaggle入门赛一个可以复现的baseline模型第二阶段第3月将baseline改造成配置驱动训练脚本 数据版本化实验文件夹 数据版本记录第三阶段第4月学习Docker基础把训练好的模型封装成推理服务本地可运行的容器化推理API第四阶段第5月补上模型格式转换如ONNX、压测和监控告警带监控和压测报告的部署方案第五阶段第6月完成一个综合项目串联数据、训练、部署、监控一个可展示的AI工程Demo这里特别强调第二阶段不要跳。我见过很多人在第一阶段裸奔每次跑完实验文件夹乱得一塌糊涂到后面想回看某个实验的准确率都找不着。如果你从第二个项目开始才引入实验管理前面那些时间等于白跑了。尽早建立工程习惯比多刷几个模型重要得多。5.2 个人项目的经典选题很多人会问入门AI工程应该做什么项目我的建议是选那些数据获取方便、业务逻辑清晰、端到端链路完整的题目。与其追求任务本身多复杂不如追求流程多完整。这里列几个我比较推荐的经典选题垃圾邮件/短信分类数据网上有很多公开集任务直观适合完整走一遍数据清洗、模型训练、服务部署、监控告警。电商评论情感分析涉及中文NLP的预处理和模型选择可以体验文本数据漂移的问题。图像分类的自动标注辅助工具把预训练模型包装成一个微服务配合人机协同标注流程是很贴近实际业务的工程场景。选项目时有一个判断标准这个项目能不能让你自然遇到数据和环境带来的问题而不是只有一个编译通过就完了。比如如果你选的是玩具级的Minst手写数字识别可能还没到部署就结束了因为它的数据太规整、模型太成熟你很难踩到真实的坑。反之选一个有噪声、分布会漂移、数据需要清洗的真实场景你才会被迫去处理那些AI工程里真正难搞的问题。6. 我在实际项目里踩过的几个典型问题6.1 隐性数据泄漏导致的线上劣化关于从零做AI工程有些问题是我希望当年有人提前告诉我的因为它们总是在你最不设防的时候出现。隐性数据泄漏就是其中之一。什么叫隐性数据泄漏就是训练数据里混入了在真实预测时拿不到的信息。我之前做一个推荐排序模型训练时用了用户是否点击了该商品作为标签这很正常但特征是0.2节里提到的那个用户曝光次数。问题就出在曝光次数这个特征上曝光次数本身是在用户看到推荐结果之后才产生的线上预测时你根本不知道这一次曝光会有多少次只能从上一次或者预估里拿。训练时用真实曝光线上用预估值分布完全对不上模型效果自然一落千丈。这种问题在工程化不完善的时候特别难发现因为你拿线上数据回测时精度可能很高但上线后就是不行。我的经验是在做特征工程时对每一个特征都问一遍在预测时点这个值是否已经确定且能被系统取到。如果答案是否定的哪怕它在训练时带来再大的提升也要丢掉。宁可这个特征不用也不要把未来的信息喂给模型。6.2 依赖环境不一致带来的能跑但诡异另一个典型问题不是算法问题而是环境问题。训练环境和线上环境的依赖版本不一致会让模型表现变得很诡异。最常见的表现是线下测试正常线上预测的置信度明显偏低——不是模型坏了而是某个依赖库的版本升级后底层计算精度变了。我在一个语义匹配模型上遇到过类似情况线下验证集AUC是0.93线上回放测试只有0.89查了半天最终锁定到transformer库的一个小版本更新上它改变了某个归一化层的实现细节导致同一份模型权重在不同环境下的推理结果有细微偏差。从那之后我把线上环境锁定做到了极致的确定性训练阶段的依赖锁定到精确版本号并且把requirements-lock.txt作为模型产物的必备文件线上容器构建时不使用latest标签全部固定到不可变版本。每次部署时还要做一次模型一致性校验——拿同一批样本分别在训练环境和线上环境跑一遍比对输出结果的一致性。如果差异超过预设阈值则不允许继续发布。这个步骤看起来额外花时间但避免的是上线后找一个半天都查不出来的诡异问题。考虑到我经历过这些如果你也是从零开始准备自己的AI工程链路我能给的最实用建议就是不要急着把每个环节都用上最流行的工具先从最有可能让你返工的环节入手——数据版本化、实验记录、配置驱动训练、环境锁定。这四个点看起来平淡但它们的每一分投入都会在你后面排坑时成倍地还给你。工具会换、模型会变但真正让一个AI系统稳定运行的永远是这些不起眼的工程习惯。