AI工程ai-engineering这几年被说成了热词但说的人越多概念反而越模糊。我面试过不少候选人简历上都写着“熟悉AI工程全流程”深聊之后发现大多数人说的其实是“会调API、会在notebook里跑通模型”。那和真正的AI工程中间还隔着一整个生产环境。这篇文章写的是我从零开始搭AI工程能力的完整过程——环境、数据、训练、评估、部署、监控、迭代每一步怎么走、哪些坑必须替你踩一遍。适合刚入门的开发者也适合手里已经有几个模型项目、但总觉得自己做的是“玩具”而不是“系统”的人。读完之后你至少能建立起一张清晰的路线图什么阶段该做什么、什么时候该补什么技能。1. AI工程与“会调API”之间的真实距离1.1 大多数人理解的AI工程是错的我经常被问到同一个问题“AI工程是不是就是写Python调模型”这个问题本身就把ai-engineering理解小了。写Python调模型属于“用工具”而工程的核心是在约束下交付可靠系统。什么叫约束数据会变、模型会退化、流量会涨、机器会挂、团队会换人。AI工程就是一套应对这些约束的方法论它包含数据处理、实验管理、模型训练、评估验证、上线部署、持续监控以及围绕这些环节的自动化与标准化。打个比方会用燃气灶和开餐厅之间隔着什么隔着菜单设计、食材供应链、后厨动线、卫生标准、成本核算、应急处理。同样的道理模型训练只是AI工程里的“炒菜”环节而且很可能是最容易被复制的一步。真正消耗精力的是“上菜之前”的数据准备、环境搭建、评估设计和“上菜之后”的服务部署、监控告警、迭代回滚。这些环节单独看都不难难的是把它们串成一条可靠的流水线。1.2 生产级AI系统多了什么为了把这个问题讲清楚我通常让新人先做这样一张对比表把“教学项目里的AI”和“生产环境里的AI”放在一起比维度教学/实验项目生产级AI系统数据固定的、干净的公开数据集脏数据、缺失值、分布漂移模型训练一次跑通即可可复现、可追踪、可对比评估看准确率/损失分人群指标、业务指标、公平性部署本地notebook演示高并发、低延迟、容灾监控无漂移检测、异常告警、日志审计迭代改代码重跑灰度发布、A/B实验、自动回滚做完这张表大多数人会沉默一会儿。他们意识到自己之前做的“AI项目”其实只覆盖了表格左边那一半——数据是现成的、模型训练是一次性的、评估只看准确率、部署是notebook演示、监控完全没有。而市场上真正稀缺的、也是薪资回报最高的能力正好是右边那一半把脏数据洗干净的能力、让训练可复现的能力、把模型稳定服务出去的能力、让系统可观测可回滚的能力。1.3 一张从零到一的路由图基于我的实操经验从零建立AI工程能力可以拆成五个阶段。第一阶段是环境工程化目标是任何时间、任何机器都能重建相同的运行环境。第二阶段是数据工程化目标是让数据可校验、可追溯、可版本化管理。第三阶段是训练实验化目标是让每次实验都有完整记录指标可横向比较。第四阶段是交付工程化目标是让模型能以服务形式稳定对外提供能力。第五阶段是监控与迭代工程化目标是让模型效果可观测、退化可感知、更新可控制。后面每个章节都对应这五个阶段里的具体落地方法。2. 搭好AI工程的底座环境与可复现性2.1 Python环境管理从venv到conda的选择如果把AI工程比作盖楼环境就是地基。地基没打好后面全白搭。我见过的翻车现场最多的就是项目在本地跑得好好的换一台机器或者一个月后重新打开怎么都起不来。原因基本都是包版本不一致。我早期习惯用venv隔离环境后来在一个深度学习项目上被狠狠教育了一次。当时同事拉了我的代码跑起来直接报CUDA相关的错查了半天发现是系统里的cudnn版本对不上。venv只能隔离Python包管不了CUDA、cudnn这些底层二进制库的版本一旦系统环境变了模型结果就复现不出来。后来我全面切到conda它的channel机制能把CUDA工具链也纳入虚拟环境管理。具体操作上我现在的标准配置是用conda管理Python解释器和虚拟环境用pip-tools锁定依赖版本。下面是我常用的环境创建命令conda create -n ai-engine python3.10 conda activate ai-engine conda install -c nvidia cuda-toolkit11.8 cudnn8.6 pip install -r requirements.txt这里有个小细节requirements.txt我建议用pip-compile生成而不是直接pip freeze。pip freeze会把环境里所有无关包也锁进去锁出来的文件又臭又长而pip-compile只解析你声明的顶层依赖生成一份干净且可复现的完整依赖树。2.2 依赖锁定与容器化让“在我机器上能跑”消失环境问题的终极解法是容器化。当我需要把项目从开发机搬到服务器、或者交给同事复现的时候Docker几乎是唯一能保证一致性的方式。我会把环境配置写成Dockerfile把代码版本、依赖版本、底层库全部固化进去别人拿到镜像就能跑不再有“在我机器上能跑”这种对话。这里有一个极其容易踩的坑镜像里的CUDA版本必须和宿主机显卡驱动兼容。很多人镜像里装了CUDA 11.8但宿主机的驱动只支持CUDA 12.0结果容器起不来报错还特别隐晦。我的做法是先跑nvidia-smi看驱动的driver version再对照官方兼容表选CUDA版本最后写进Dockerfile。这个动作看起来简单但我见过太多次有人跳过去然后卡在奇怪的报错上浪费大半天。2.3 项目目录结构的工程化布局环境之外项目结构也是“工程味”的重要体现。我见过太多AI项目所有的代码、数据、模型文件堆在一个文件夹里连个README都没有能不能跑起来全靠记忆。我现在的项目目录长这样my_ai_project/ ├── config/ # 所有配置文件 ├── data/ │ ├── raw/ # 原始数据只读 │ ├── processed/ # 清洗后的数据 │ └── external/ # 外部导入数据 ├── src/ │ ├── data/ # 数据处理代码 │ ├── models/ # 模型定义 │ ├── train.py # 训练脚本 │ ├── evaluate.py # 评估脚本 │ └── serve.py # 部署入口 ├── tests/ # 单元测试、数据校验测试 ├── scripts/ # 一键运行脚本 ├── notebooks/ # 探索性分析 ├── models/ # 模型产物配版本号 └── docker/ └── Dockerfile规则很简单数据分原始和处理后原始数据只读不改代码分成数据处理、模型、训练、评估、服务几个模块每个模块尽量独立所有实验产物放进带版本号的目录。这套结构背后是一个核心原则让项目的每个环节都可以被单独验证和回滚。当模型出了问题时你能快速定位是数据污染了、代码写错了还是参数调崩了而不是对着一个混沌文件夹干瞪眼。3. 数据工程从“有数据”到“可信数据”3.1 先校验数据再谈训练很多人在数据上吃的亏都是因为拿到数据后直接就喂给模型。我第一次做真实项目时也这样结果跑出来准确率95%兴奋了半天后来才发现训练集和测试集有大量重复样本模型的“高准确率”其实是背题背出来的。数据校验应该在训练之前就自动化。我写过一个最基础的数据检查脚本包含三类检查空值率、数值范围、类别分布。时间顺序这种业务相关的校验脚本里不好写死需要结合具体场景手动设计。def validate_data(df, config): checks [] # 空值检查 null_ratio df.isnull().mean() for col, threshold in config[max_null_ratio].items(): if null_ratio[col] threshold: checks.append(f列 {col} 空值率 {null_ratio[col]:.2%} 超过阈值) # 数值范围检查 for col, (lo, hi) in config[value_range].items(): actual_lo, actual_hi df[col].min(), df[col].max() if actual_lo lo or actual_hi hi: checks.append(f列 {col} 范围 [{actual_lo}, {actual_hi}] 超出预期) # 类别分布检查 for col in config[categorical_cols]: top_ratio df[col].value_counts(normalizeTrue).iloc[0] if top_ratio config[max_category_skew]: checks.append(f列 {col} 类别分布严重倾斜: 最高占比 {top_ratio:.2%}) return checks这个脚本不复杂但它会在你满怀信心跑训练之前把最可能导致“指标虚高但上线翻车”的问题拦住。拿时间序列举例训练集的时间范围绝对不能包含测试集的时间范围否则就是未来信息泄露。这类问题在代码里不容易发现但用专门的切分逻辑和校验脚本一查一个准。3.2 数据版本化git管代码数据谁来管代码有git做版本管理但数据呢数据每天都在变化标注会修改新样本会加入如果数据没有版本那么“模型效果变好了”这句话就没有意义——你根本不知道它是在哪份数据上变好的。我用的是DVC来做数据版本管理。它把数据和代码的版本绑定数据存在本地或云存储而DVC只记录一个hash。这样每次实验我都能精确地对到“哪份代码 哪份数据 哪个模型”这三个变量。具体流程是dvc init dvc add data/raw git add data/raw.dvc data/.gitignore git commit -m feat: add v1.2 dataset之后任何人拉代码只需要dvc pull就能拿到完全一致的数据。这个过程可能要多花十分钟但它能省掉无数个“我们数据怎么对不上”的扯皮。你也不需要把动辄几十GB的原始数据塞进gitDVC的存储层可以对接S3、OSS或者本地磁盘。3.3 标注清洗与数据泄露两个最常见的翻车点数据泄露我再多说两句因为十个项目里至少有四个会在这里翻车。常见场景是做特征工程时用了目标变量的未来信息或者对全量数据做归一化时把测试集的均值方差也算进去了。正确答案是先切分、再训练scaler只用训练集的数据来拟合归一化参数。这个顺序错了验证指标就会虚高而且很难察觉。另一个容易被忽视的是标注一致性问题。多人标注数据时经常出现同一条样本不同人给不同标签的情况。我做过一个NLP项目标注一致率只有70%模型再强也白搭。解决办法是在标注规范里写明边界case的处理规则然后定期抽检一致性把低于阈值的数据打回重标。这些工作看起来不是核心技术但它们决定了模型的真实效果上限。没做数据清洗之前我和很多人一样总想换更好的模型架构做完了才发现光是把标注质量从70%拉到85%效果提升就超过了换任何模型。4. 训练与评估的工程化闭环4.1 实验追踪让每次训练都有账可查一开始做实验我是靠手动抄Excel记录参数和指标。后来实验多了发现抄完就忘参数调了但忘了和哪版对比。真正把实验管理起来是从引入MLflow开始的。每跑一次训练自动记录代码commit hash、数据集hash、超参数、关键指标、模型产物路径、资源消耗。用MLflow记录实验的方式非常简单import mlflow with mlflow.start_run(): mlflow.log_params({lr: 1e-4, batch_size: 32}) mlflow.log_metrics({val_acc: 0.923, f1: 0.887}) mlflow.pytorch.log_model(model, model)有了这套记录后续做的所有优化都有了明确参照物。别人问我“你这个模型比上个版本好在哪”我不需要靠回忆直接查实验记录。而且实验追踪还带来一个额外的好处当你要写技术总结或者向团队汇报时所有数据都在那里不用临时补。4.2 评估集设计比模型结构更影响结论的东西我在工作中反复强调一个观点评估集的设计质量决定了你对模型能力的判断是否靠谱。很多新人的误区是随便切一个train_test_split就开跑。我见过一个分类项目因为没做分层采样测试集里某个类别的样本只有个位数得出的准确率波动极大换个随机种子结果就完全不同。正确做法至少要考虑三件事第一通过分层采样保证训练集和测试集的类别比例一致第二如果是时序数据必须按时间切分不能用随机切分第三给模型留一个“没见过”的holdout集等所有实验做完、模型定版之后再在它上面跑最终评估。这里有个反直觉的点很多人为了追求更高的评估分数反复在测试集上调参。调着调着测试集就变成了第二个训练集——模型开始在测试集上过拟合分数虚高上线就露馅。所以要留holdout集并且只在最后碰它。这个道理简单但能做到的人不多因为“最后再碰”需要极大的自律。4.3 调参的工程化思路别靠感觉调参本身很容易变成玄学。我的经验是先用一份配置文件管住所有超参数而不是改代码里的魔法数字。训练脚本读取config文件每次实验记录config的版本。然后通过网格搜索或贝叶斯优化做小范围搜索而不是凭感觉随机试。# config/experiment_001.yaml model: name: resnet50 pretrained: true train: lr: 1e-4 batch_size: 32 epochs: 50 optimizer: adamw data: version: v1.2 augment: true每个实验就是一个配置文件配置跟着实验走想复现随时能复现。我见过太多团队调参靠改代码、记录靠聊天记录三个月后连自己都说不清模型为什么这样能work。等你需要给客户或者老板解释模型表现的时候这种工程化记录比“我觉得这个参数效果好”有说服力得多。5. 模型上线部署、监控与持续迭代5.1 选择合适的serving方式不是所有模型都要上微服务部署这块的第一个问题不是“用什么框架”而是“用什么方式对外提供服务”。我把常见方式分为三类批处理、在线API、边缘部署。批处理适合不需要实时响应的场景比如每日生成一次风控评分、每月跑一次用户分群。实现简单用定时任务驱动训练好的模型对全量数据打分就行。在线API适合实时交互场景比如搜索排序、对话系统。这里需要把模型封装成服务并且要考虑并发、延迟、限流。边缘部署适合网络不稳定或数据敏感的端侧场景模型要压缩、量化对工程的要求更高。新手最容易犯的错是一上来就要搞在线API实际上很多业务场景用批处理就能解决成本低得多稳定性也高得多。我一个朋友做的库存预测项目刚开始花了大力气搭实时推理服务结果业务方说“我们每周跑一次预测就够了”。先搞清楚场景再决定架构这是工程的基本素养。5.2 延迟与吞吐容易被忽视的工程指标模型上线时模型本身的指标反而退居二线延迟和吞吐才是最先要测的。我的套路是先用少量请求做冒烟测试然后逐步加压记录P99延迟和每秒可处理的请求数。如果P99延迟超过业务要求就得考虑优化了——从模型量化、批处理、缓存到换更轻量的模型架构优先级从低到高。有一个我踩过的坑本地压测一切正常上线后发现延迟暴涨。后来排查发现服务端和数据库在同一台机器上数据库慢查询吃掉了CPU。这提醒我一件事压测必须在接近生产的条件下做本地notebook里的性能数据基本没有参考价值。生产环境的网络拓扑、依赖服务、并发模型都会影响真实表现。5.3 监控与回滚模型跑起来只是开始模型上线只是开始之后是漫长的运营阶段。我用三个维度做监控数据漂移输入分布变化、概念漂移特征与目标的关系变化、业务指标漂移点击率、转化率等实际效果。这三个信号分别对应“数据出了问题”“模型本身过时了”“业务目标偏移了”处理方式完全不同。监控配置了告警之后还要准备回滚方案。一旦监控指标异常系统能自动切回上一版模型或者切到一个兜底规则。不要指望出了问题再来讨论方案线上每多宕一分钟损失都是实打实的。我现在每个模型上线前都会写一份一页纸的回滚预案列清楚什么指标触发回滚、由哪个人执行操作、具体执行哪些命令、回滚后如何验证。还会安排一次模拟演练确保预案真的可用而不是写在文档里自我安慰。6. 从零到一踩过的那些坑6.1 数据泄露让我白干了两周第一个想讲的坑是数据泄露。当时做一个时序预测项目为了“增加训练数据”我把数据做了滑窗拼接但切分时用的是随机切分而不是时间切分。结果模型在验证集上表现非常好我还以为是自己调参有天赋。上线前做最后验证holdout集上的效果崩了一半。排查了两天才发现验证集里包含了未来的数据。那次之后我给自己定了一条铁律时序项目里任何切分都必须先按时间排序然后禁止随机切分。这条铁律后来帮我避免了好几次类似的翻车。6.2 “在我机器上能跑”的高昂学费第二个坑和环境有关。有一次我把训练好的模型交付给同事对方运行时报错CUDA error: no kernel image is available for execution on the device。查了半天发现他那台机器的GPU是旧架构我用的PyTorch版本编译时没兼容这个架构。解决办法是换一个兼容版本的PyTorch然后所有代码重跑一遍。从那以后我再也不在环境上省时间开发机、预发机、生产机的环境配置全部用Docker统一。这句话看起来是常识但只有真正被环境问题折磨过的人才会理解“能复现”这三个字值多少钱。6.3 没有监控的代价模型退化没被发现第三个坑是最痛的。当时一个推荐模型上线后效果一直不错我也就没加监控。结果一个月后业务方来投诉说推荐内容越来越偏。我拉数据一看用户的反馈行为变了但模型还是按照旧的行为模式在推——概念漂移已经发生了一周多我却完全不知道。那次之后我把监控提到和模型训练同等重要的位置。甚至可以说如果资源有限我宁愿牺牲一部分模型效果也要保证监控到位。因为一个效果平庸但有监控的模型可以快速迭代改进一个效果很好但无监控的模型一旦出问题就是灾难你连从哪里开始排查都不知道。6.4 三点给后来者的实用建议最后分享三个我自己沉淀下来的建议。第一先画数据流图再写代码。把数据从采集、清洗、训练、上线的完整链路画出来标清每个环节的输入输出再动手写代码。看似多花半小时实际能避免大量返工。第二把能自动化的事全部自动化。环境搭建、数据校验、模型评估、部署发布每件事都有对应的工具不要靠手动操作人是会忘记的和犯错的。第三保留手工验证的习惯。自动化是手段手工验证是兜底。重要项目上线前我会手动跑一遍核心流程确保整条链路是通的。这些都是我付了学费才换来的教训。你要是能照着这套思路把环境、数据、训练、部署、监控一步步工程化你的AI项目就不再是“能跑”而是“能扛”。
