几年前我给自己定了一个目标把ai-engineering-from-scratch变成现实。那会儿我对AI工程的理解非常粗暴——把PyTorch官方示例跑通再套一个Flask接口就算“会做AI”了。结果第一个真实项目就在生产环境翻车训练集准确率看着还行上线后面对真实请求直接崩掉。后来我走了很多弯路才慢慢理解AI工程不是“模型代码”而是模型周围那一圈容易被忽略的管线环境、数据、实验、部署、监控缺一环都不行。如果你正准备开始自己的AI项目或者已经跑过几个模型但卡在“demo能跑、生产不可用”这个阶段这篇文章就是我一路从零踩过来之后的结构化复盘。我会把每一步为什么这么选、具体命令怎么做、以及那些没人提前告诉你的坑尽量原原本本写出来。目标只有一个让你少走我走过的弯路。1. 先打破幻觉AI工程不是“写模型”而是一整套系统工程1.1 为什么我一开始的“AI项目”全部失败我做过一个文本分类工具当时的感觉非常良好GitHub上克隆BERT示例改改数据路径训练几个epoch准确率92%然后我用Flask包了一个接口感觉自己已经是“AI工程师”了。结果这个工具一放到真实业务数据上准确率直接掉到70%左右。最奇怪的是我本地测试还好好的上了服务器就变样。后来排查出三个致命原因每一个都和模型结构无关训练数据分布和真实数据分布完全不一致。官方demo用的是新闻语料我的业务数据是客服工单词汇、句式、长度都不一样模型在demo上看到的“经验”在真实场景里基本不适用。代码、预处理、模型版本全都没有记录。我今天改了分词逻辑明天又换了模型权重到了复盘的时候根本不知道哪个版本对应哪次实验结果。推理性能完全没有设计。单个请求在CPU上要3秒多根本没法在生产环境用。这三个问题没有一个是“换个更好的模型”能解决的。它们全是工程问题。1.2 AI工程与AI研究的本质区别稳定性 酷炫我以前以为AI工程就是AI研究的一个子集后来发现这两个领域的目标差异很大。AI研究追求在公开数据集上的指标上限算法创新是核心AI工程追求的是在真实、受限、多变的环境里让模型稳定、可控、可住地输出结果。工程里的“住”包括可复现、可监控、可回滚。我做过一个不算恰当的类比研究像是实验室里造一辆能跑500km/h的赛车工程则是造一辆在城市里每天通勤、耐造、不出毛病的家用车。赛车很酷但大多数时候我们需要的是后者。所以我给自己的第一条原则是把对“新模型”的痴迷先压一压把注意力放到模型之外的管线上。管线不牢模型再炫也没用。2. 从零搭建AI工程的第一步环境与项目骨架2.1 我最终选定的技术栈Python、PyTorch、MLflow、Docker技术选型的原则是“先用最主流、最成熟的东西”不要在起步阶段追求独特。我的最终选择是组件作用为什么选它Python 3.10主语言生态最全AI相关库基本都围绕它PyTorch深度学习框架动态图调试友好社区活跃自定义模型心智负担低MLflow实验跟踪与模型管理能记录参数、指标、产物复现实验的标配Docker环境打包解决“我本地能跑你环境跑不了”的核心矛盾DVC数据版本控制数据集和代码一样需要版本化追踪为什么不选TensorFlow不是它不好而是对于工程调试来说PyTorch的“运行时才建图”方式让我更容易定位问题。你如果更熟悉TensorFlow也没问题关键在于把整个工程管线搭起来而不是纠结框架本身。2.2 用Cookiecutter搭建可复制的项目模板很多新手拿到数据就开始写train.py写到一半文件路径乱飞连自己都找不到昨天生成的结果。我的建议是先搭一个可复制的项目骨架推荐用Cookiecutter。安装pip install cookiecutter然后可以用现成的AI项目模板比如cookiecutter https://github.com/drivendata/cookiecutter-data-science它会生成一个包含关键目录的结构我最终沉淀下来的是这样. ├── configs/ # 项目配置yaml或json ├── data/ │ ├── raw/ # 原始数据只读不修改 │ ├── processed/ # 清洗后数据 │ └── external/ # 外部引入数据 ├── notebooks/ # 探索性分析不参与线上流程 ├── src/ │ ├── data/ # 数据处理代码 │ ├── features/ # 特征工程 │ ├── models/ # 模型定义和训练 │ └── api/ # 推理服务 ├── models/ # 产出的模型文件 ├── tests/ # 测试代码 └── Makefile # 一键执行常用流程这个结构最重要的原则是数据、代码、产物分离。你不会在改代码的时候误伤数据也不会在训练完不知道该把模型文件放到哪里。2.3 环境依赖管理的坑conda、pip、poetry该怎么选环境管理是第一个容易翻车的地方。我早期直接用pip freeze requirements.txt打包环境后来发现这个文件里混了很多不该锁的间接依赖换一台机器装完经常起冲突。后来我采用的方案是用conda管理基础环境Python版本、CUDA、系统级库用poetry管理项目级别的依赖并提交poetry.lock文件。创建环境conda create -n ai-engineering python3.10 conda activate ai-engineering pip install poetry poetry init poetry add torch transformers fastapi uvicorn mlflow dvc为什么非要用poetry因为poetry.lock会把所有依赖的精确版本和传递依赖都锁住。只要有这个文件任何人在任何机器上执行poetry install得到的环境都和我一样。conda也能锁但它的环境解析和跨平台支持有时候会让人抓狂。注意不要只写一个requirements.txt然后手动维护。我第一次项目就是手动维护结果某次升级torch之后模型结果变了但没人知道查了三天才发现是依赖版本变了。3. 数据工程模型好不好早在数据处理时决定了3.1 拿到原始数据后我做了什么清洗、去重、格式归一很多AI项目的时间分配里数据整理占掉的精力比模型训练多得多。我自己的经验是一个项目里50%以上的时间都会花在数据上不是在“玩数据”而是在“让数据变成模型能吃的样子”。我拿到原始数据后的固定流程缺失值处理先看每一列缺失比例缺失过多的字段要么丢弃要么用“unknown”之类的占位符绝不能用随机数强行填充。去重这一步要定义清楚“重复”是什么。文本数据里一行字完全相同是比较容易判断的重复但语义上相近但表达不同的样本比如“订单没到”和“我的包裹还没送过来”不能简单去重需要业务规则或人工判断。格式归一日期统一成YYYY-MM-DD文本统一成小写除非大小写有语义标点符号做统一处理。标签分布检查打印每个类别的样本数量如果有类别特别少要提前决定是否做采样、加权或者收集更多数据。异常样本剔除比如单条文本长度超过正常范围100倍多半是复制粘贴错误保留反而会干扰模型。我做文本分类时原始数据里有大量长度超过2000字的“垃圾样本”实际上是页面爬取时把导航栏和广告也抓下来了。清洗之后模型的表现提升非常明显——这个变化远大于我换一个预训练模型带来的提升。3.2 标注质量怎么把控双人标注抽检如果你的项目需要自建标注集质量控制是关键。我最早是自己标标了一个下午觉得挺简单。后来发现人的注意力会下降到了后半段同一个样本的标签可能跟前面都矛盾。推荐的方案是双人标注加抽检每个样本至少两个人独立标注计算两人标注的一致性如果一致性低于某个阈值比如75%说明标注指南本身有问题要先修改指南而不是继续标对已标注数据定期抽检抽检比例建议不低于5%。一致性指标可以简单算agreement sum(1 for a, b in zip(labels_1, labels_2) if a b) / len(labels_1)只看准确率不够还要看每个类别的召回和精确度尤其是少数类。类别不平衡是文本分类里最常见的问题如果不处理模型会“聪明地”把所有样本都预测成多数类整体准确率看着挺高但少数类全错。3.3 数据版本管理为什么我不用CSV直接覆盖代码有Git版本管理数据也必须要有。我早期经常干的事情是把data.csv改一下重新训练过两天觉得效果还不如之前想回退到旧数据然后发现旧数据已经被覆盖了彻底找不到。DVCData Version Control解决的就是这个问题。它不把数据本身放到Git里而是用指针文件记录数据的版本。常用命令dvc init dvc add data/processed git add data/processed.dvc git commit -m 更新清洗后的数据以后想切换到任意一个历史数据版本只需要git checkout commit dvc checkout数据和代码的版本就一起出来了。这个操作看起来多花了几分钟但在项目周期长的时候价值极大。我至少有两次靠DVC救回了被覆盖掉的旧数据集不然整个实验对比都要重做。4. 模型训练从“能跑通”到“能用的”关键转折4.1 选定基线模型后先做一次完整训练而不是急着调优新手最容易犯的错是一上来就上最强模型比如直接上几十层的大模型指望效果一步到位。我的经验是反过来的先做一个最简单的基线模型走通整个流程再逐步升级。基线模型可以是逻辑回归、小型CNN或者一个小号的预训练模型。它的作用不是拿出去打比赛而是帮你确认数据预处理和加载管线是否正确训练流程能否完整跑通评估方式是否符合业务目标。我第二个项目就学乖了先用TF-IDF 逻辑回归跑了一遍虽然准确率不如BERT但从数据处理到评估接口全部跑通之后我再把模型换成BERT很快就能看到提升。如果一开始就直接上BERT出了问题都不知道是数据的问题还是模型的问题。4.2 训练中的指标监控loss、验证集、过拟合判断训练时不能只盯着终端里刷新的loss要同时看训练集和验证集的曲线趋势。最简单有效的判断规则现象结论训练集loss下降验证集loss也下降还算正常继续观察训练集loss下降验证集loss不降或上升过拟合信号需要加正则/减小模型训练集loss和验证集loss都高欠拟合或模型容量不足、特征不够评估分类模型时只看accuracy会骗人。我处理过一个类别不平衡项目正负样本比1:9模型把所有样本都预测成负类accuracy是90%看起来很高但正样本一个都没抓到。这种场景必须看precision、recall、F1甚至画PR曲线。建议在训练时把评价指标定义成一个独立模块至少包含lossaccuracymacro F1 / weighted F1少数类的precision/recall这些指标不光要打印还要通过日志记录下来。4.3 实验记录MLflow怎么帮我记住每次超参数训练一次模型涉及的数据版本、代码版本、超参数、随机种子、评估结果信息量很大。如果不记录三天之后你就会忘掉“当前这个模型到底是怎么来的”。我用的是MLflow Tracking。基本用法import mlflow with mlflow.start_run(): mlflow.log_param(model_name, bert-base) mlflow.log_param(learning_rate, 2e-5) mlflow.log_param(batch_size, 16) mlflow.log_metric(eval_f1, 0.87) mlflow.log_artifact(model.bin)跑完之后在浏览器打开MLflow UI能看到每一次实验的参数和指标一眼就能对比哪个实验更好。有了它我再也不会出现“这个结果好像是用某个版本跑出来的但我忘了是哪个版本”这种状态。对于团队协作MLflow还能做Model Registry可以给模型打上Staging、Production的标记——这个后续部署特别有用。5. 部署与上线真正让我崩溃的是这里5.1 本地能跑和线上能跑是两个世界模型训练完之后本地跑通只是第一步上线才是真正的考验。我吃过的亏包括本地有GPU服务器是纯CPU模型推理慢得没法用tokenizer版本不一致线上环境的tokenizer和训练时不是同一个版本导致文本被切成不一样的分词预测结果直接变化本地内存够大服务器容器内存只有2GB模型加载完直接OOM。所以“本地能跑”和“线上能跑”完全不是一回事。部署前一定要明确线上环境的硬件限制CPU还是GPU内存多少允许的推理延迟是多少。这些参数直接决定你要不要做模型量化、剪枝或者换更小的模型。5.2 用Docker打包模型服务的完整流程Docker解决的是环境一致性问题。我的标准做法是把推理服务做成一个Docker镜像确保任何环境行为一致。一个最小的FastAPI推理服务# app.py from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class PredictRequest(BaseModel): text: str app.post(/predict) def predict(req: PredictRequest): # 这里加载模型做预处理和推理 result {label: positive, score: 0.98} return result对应的DockerfileFROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY src/ ./src/ COPY models/ ./models/ EXPOSE 8000 CMD [uvicorn, src.api.app:app, --host, 0.0.0.0, --port, 8000]构建镜像docker build -t ai-engineering-service . docker run -p 8000:8000 ai-engineering-service注意模型文件比较大的时候不建议直接塞进镜像因为镜像会变得特别大每次推送都很慢。更好的做法是用共享存储比如S3或NFS在容器启动时把模型加载进来。5.3 推理服务的性能优化批处理、缓存、动态batch上线之后你很快会发现“单个请求推理耗时”不是唯一指标。还有两个常见指标吞吐量每秒能处理多少个请求和延迟单个请求从发出到返回需要多久。这两个指标往往要权衡。几个我在实践中最有效的优化手段缓存对完全相同的请求直接返回之前结果。文本分类里重复问题特别多加一个简单的缓存能减少一半以上的计算量。动态batch不要让每个请求单独跑一次推理而是把并发请求攒起来凑成一批再推理能显著提高GPU或CPU利用率。实现起来可以用队列或者FastAPI的BackgroundTasks。模型序列化优化如果只用推理可以导出为TorchScript或ONNX格式比直接跑原始PyTorch模型更快内存占用也更低。我做过一个经验数据同样的BERT模型单条请求CPU推理耗时3.2秒用动态batch一次处理8条之后平均每条降到0.8秒左右。这就是工程优化的力量。5.4 上线后的监控数据漂移和模型退化模型上线不是终点而是开始。我负责过的模型上线后最怕的就是“静默退化”——线上指标慢慢变差但没人知道。最基础的监控包括两件事输入数据监控记录线上输入的特征分布比如文本长度、关键词频率、缺失值比例定期和训练集分布比较。如果分布变化明显说明发生了数据漂移。预测分布监控统计模型输出的预测类别比例如果某天某个类别的预测比例突然飙升大概率是线上数据变化了需要告警。简单的漂移检测不一定非要复杂统计模型可以先看均值、方差、分位数的变化。比如训练集里文本平均长度是120个字符线上如果连续几天变成200个字符说明业务场景或数据来源变了。我建议上线前至少把“输入特征统计摘要”和“预测结果统计摘要”落库并配置一个简单的阈值告警。哪怕只有日志和定时脚本也比完全没有强。6. 工程化复盘从个人Demo到团队协作6.1 代码、数据和模型的版本管理如何统一一个人做项目可能还能靠记忆力但多人协作必须把代码、数据、模型三者关联起来。我的做法是Git管理代码每次实验切换对应commitDVC管理数据用data/processed.dvc记录数据版本MLflow管理模型每次训练都会记录Git commit、DVC数据版本、超参数、评估指标。这样一套打通后任何人拿到一次实验的run_id都能复现出完全一样的模型。这种能力在交接工作时特别重要——别人不用来问你“当时的预处理是什么样的”直接查记录就行。6.2 自动化测试在AI项目中的特殊做法很多人以为AI项目没法写测试其实不是。我通常把AI项目测试分成三层数据测试检查数据列是否存在、标签是否在合法集合内、缺失值比例是否超过阈值。数据测试在每次数据更新时都会跑。特征转换测试同样的输入特征转换函数在不同版本上要保证输出一致。比如tokenizer版本升级后要测试同一句话的分词结果是否和升级前一样。模型输出格式测试模型接口返回的JSON结构、score范围、label集合要固定。上游调用方依赖这些契约不能今天返回label明天变成prediction。我踩过一个经典坑某次重构把模型输出里的分数含义从“正类概率”改成了“得分减去0.5之后的偏移量”下游团队没收到通知结果线上业务逻辑直接错乱。写个输出格式测试就能避免这种问题。6.3 我对AI工程新人最想说的几点经验我从零走完这条路之后有几条很实在的心得先跑通端到端最小闭环再优化指标。一开始就用最简单的模型把“数据→训练→部署→请求”走通这个闭环就是你的及格线。之后每一步提升都是在闭环上做加固。多用Makefile或脚本把流程串起来。我后期会在项目根目录写Makefile把make data、make train、make serve都固化下来。手动敲命令越少越不容易出错。日志一定要多打。模型推理时记录输入的摘要和输出的摘要出了问题才能回溯。没有日志的AI服务等于在黑夜中闭眼开车。不要盲目追逐最新模型。真实业务先解决的是可靠性和成本新模型如果能带来明显收益再换否则老模型维护得好同样有价值。这些经验多数不是从书上学来的而是踩坑之后总结的。我希望你能在看完这篇文章后把“从零开始AI工程”变成一条清晰可见的路径环境、数据、训练、部署、监控每一步都不神秘但每一步都需要认真对待。