1. 从零搭建AI工程能力为什么大多数人第一步就走偏了聊到“从零开始做AI工程”这个话题我见过太多人一上来就扎进模型训练里结果折腾了两周连数据管道都没跑通。这个项目标题“ai-engineering-from-scratch”本身就点出了一个关键问题AI工程不等于调模型它是一整套从数据到部署的工程体系。很多人把注意力全放在算法上却忽略了工程化才是让AI真正跑起来的那根脊梁。我自己带过几个从零起步的AI项目踩过的坑基本都集中在几个地方数据版本混乱、实验无法复现、模型上线后性能断崖式下跌。这些问题的根源不在于模型不够好而在于工程基础设施没搭起来。所以这篇内容我想聊的不是某个具体算法怎么调参而是当你面对一个空白的AI工程项目时应该按什么顺序、用什么工具、避开哪些坑把整套工程能力从零建立起来。适合读这篇的人包括刚转行做AI工程的开发者、需要独立负责AI项目但缺乏工程经验的研究人员、以及想系统梳理AI工程知识体系的技术负责人。我会尽量用实际项目中的做法来讲而不是停留在概念层面。2. 数据管道AI工程里最容易被低估的地基2.1 为什么数据管道要先于模型设计很多人拿到项目的第一反应是“用什么模型”但我的经验是先把数据管道跑通再考虑模型。原因很简单模型可以换数据管道一旦设计得不好后面所有环节都要跟着遭殃。我见过一个团队因为数据加载逻辑写得太随意导致训练和推理阶段的数据预处理不一致模型离线指标很好上线后效果直接腰斩。数据管道的核心任务是把原始数据变成模型可消费的格式并且保证这个过程可复现、可追溯。具体来说你需要解决三个问题数据从哪里来、数据怎么变、数据版本怎么管。数据来源这块常见的有数据库直连、文件系统读取、API拉取几种方式。我的建议是尽量把原始数据落地到对象存储或本地文件系统不要每次训练都去查数据库。原因有两个一是数据库查询会给线上业务带来压力二是原始数据落盘后可以做版本快照方便回溯。数据变换环节我习惯用配置文件来定义整个预处理流程而不是把逻辑散落在代码里。比如用YAML定义每个字段的处理方式fields: - name: user_age type: numeric transform: normalize params: min: 0 max: 120 - name: user_city type: categorical transform: onehot params: max_categories: 200这样做的好处是预处理逻辑和代码解耦换一个数据集只需要改配置不用动代码。而且配置文件本身可以纳入版本管理每次实验用的什么预处理参数一目了然。2.2 数据版本管理的实操方案数据版本管理是很多人忽略的一环。你可能会说我用Git管理代码不就行了但数据文件通常很大放Git里不现实。我的做法是用DVC或者类似的工具来管理数据版本核心思路是数据文件存在对象存储里Git里只存一个指向具体版本的元数据文件。具体操作流程是这样的先把原始数据放到一个固定的目录结构下比如data/raw/2024-01-15/然后用DVC把这个目录纳入管理。每次数据更新时创建一个新的日期目录DVC会自动生成对应的.dvc文件把这个文件提交到Git里。这样你的代码版本和数据版本就绑定在一起了任何时候checkout一个commit都能找到当时用的数据。注意数据版本管理不要等到项目做大了才补一开始就做成本很低。后期补的话历史数据可能已经找不到了。还有一个细节是数据校验。我习惯在数据管道里加一层校验逻辑检查数据的基本统计特征是否在合理范围内。比如某个字段的缺失率突然从5%涨到50%那大概率是上游数据出了问题这时候应该让管道直接报错停止而不是把脏数据喂给模型。校验规则可以用Great Expectations或者自己写简单的断言关键是每次数据更新都跑一遍。2.3 数据加载的性能优化经验数据加载的性能直接影响训练效率。我遇到过最典型的问题是数据预处理逻辑写在Python的__getitem__里每次取一个batch都要做一堆CPU计算GPU利用率只有30%不到。解决办法是把预处理逻辑提前到数据管道阶段训练时只做轻量的读取和拼接。另一个经验是合理设置数据加载的并行度。PyTorch的DataLoader有个num_workers参数设置得太小会导致数据供给跟不上太大又会造成内存溢出。我的经验值是设置为CPU核心数的70%左右然后根据实际的内存占用情况微调。如果数据是从网络存储读取的还要考虑网络带宽的限制这时候可能需要先把数据缓存到本地SSD。还有一个容易被忽略的点是数据格式。同样一份数据存成CSV和存成Parquet读取速度可能差好几倍。我的建议是中间处理阶段的数据尽量用列式存储格式比如Parquet或者Feather读取时只加载需要的列能省不少时间。3. 实验管理与可复现性让每次训练都有据可查3.1 实验追踪到底要记录什么实验管理是AI工程里另一个容易被轻视的环节。很多人做实验就是改改代码跑一下跑完看看结果然后接着改。这样做短期没问题但当你跑了上百次实验之后根本记不清哪次用了什么参数、哪次的数据预处理有改动。我的做法是从项目第一天就引入实验追踪工具记录每次实验的完整信息。需要记录的内容包括代码版本Git commit hash、数据版本DVC版本号、超参数配置、环境信息Python版本、依赖包版本、训练指标曲线、最终模型文件路径。这些信息看起来多但用工具自动化记录其实不费事。比如用MLflow的话几行代码就能把参数和指标记下来import mlflow mlflow.log_params({learning_rate: 0.001, batch_size: 64}) mlflow.log_metrics({train_loss: 0.23, val_loss: 0.31}) mlflow.log_artifact(model.pth)关键是养成习惯每次实验都记录不要觉得“这次只是随便试试”就不记。往往就是那些随便试试的实验后来发现效果最好却找不到当时的配置了。3.2 环境隔离与依赖锁定环境不一致是导致实验无法复现的头号原因。你本地跑通的代码换一台机器可能就报错因为依赖包的版本不一样。解决办法是用虚拟环境加依赖锁定文件。Python项目我习惯用conda创建独立环境然后用pip-tools或者poetry来锁定依赖版本。具体做法是维护一个requirements.in文件里面只写直接依赖然后用pip-compile生成requirements.txt里面包含所有间接依赖的精确版本。这样任何人拿到这个文件都能装出一模一样的环境。# 生成锁定文件 pip-compile requirements.in # 安装锁定版本 pip install -r requirements.txt对于更复杂的项目可以考虑用Docker把整个环境打包。Dockerfile里明确指定基础镜像的版本比如python:3.10.12-slim而不是python:3.10因为后者会随着时间推移指向不同的具体版本。提示Docker镜像的构建也要纳入版本管理每次代码更新后重新构建镜像打上对应的tag不要用latest标签。3.3 模型检查点与回滚策略训练过程中保存模型检查点是个好习惯但怎么保存、保存哪些也有讲究。我的做法是每个epoch保存一次检查点但只保留最近N个和验证集指标最好的那个。这样既能防止训练中断后从头开始又不会把磁盘撑爆。检查点的命名要包含足够的信息比如model_epoch10_val_loss0.31_20240115.pth这样即使不看实验记录也能大致知道这个检查点的情况。另外检查点里除了模型参数最好把优化器状态、学习率调度器的状态也存下来这样恢复训练时能无缝衔接。回滚策略方面我建议每次上线新模型时都保留上一个版本的模型文件并且记录两个版本在验证集上的指标对比。如果新模型上线后效果不好可以快速回滚。这个流程最好自动化不要等到出问题了再手动去找旧模型。4. 模型部署与服务化从训练脚本到线上服务4.1 模型导出与推理优化训练好的模型不能直接扔到线上用中间需要经过导出和优化。PyTorch模型通常先导出成TorchScript或者ONNX格式这样做的好处是推理时不再依赖训练代码而且可以做图优化。导出TorchScript的代码大概长这样model.eval() example_input torch.randn(1, 3, 224, 224) traced_model torch.jit.trace(model, example_input) traced_model.save(model_traced.pt)导出之后要做推理性能测试看看延迟和吞吐量是否满足要求。如果延迟太高可以考虑量化、剪枝或者用TensorRT做进一步优化。但要注意优化之后一定要重新验证精度确保优化没有带来不可接受的精度损失。我遇到过一个坑模型在GPU上跑得好好的导出成ONNX之后在CPU上推理结果精度掉了好几个点。排查后发现是某些算子在CPU上的实现和GPU有细微差异累积起来就放大了。所以导出后一定要做精度对比测试不要想当然。4.2 API服务的设计要点模型服务化最常见的方式是提供一个HTTP API。用FastAPI或者Flask都能快速搭起来但有几个细节需要注意。首先是输入校验。不要假设调用方传过来的数据一定是合法的要在API层做严格的校验。比如图像分类服务要检查上传的文件是不是图片、尺寸是否在允许范围内、通道数对不对。校验不通过直接返回400错误不要让它走到模型推理那一步。其次是批处理。如果服务需要处理高并发请求单条推理的效率会很低。可以在服务端做动态批处理把短时间内到达的多个请求合并成一个batch一起推理。这个逻辑可以用一个队列加一个后台线程来实现但要注意设置合理的超时时间不要让请求等太久。from fastapi import FastAPI, File, UploadFile from pydantic import BaseModel app FastAPI() class PredictRequest(BaseModel): image_base64: str threshold: float 0.5 app.post(/predict) async def predict(request: PredictRequest): # 校验输入 if not request.image_base64: return {error: image_base64 is required}, 400 # 推理逻辑 result model_inference(request.image_base64, request.threshold) return {result: result}还有一个重要的是健康检查接口。负载均衡器需要定期检查服务是否存活所以至少要提供一个/health接口返回200表示服务正常。如果服务依赖数据库或缓存健康检查里也应该包含这些依赖的连通性检查。4.3 监控与告警的落地方法模型上线不是终点而是起点。线上服务的监控至少要做到三个层面系统层面CPU、内存、GPU利用率、服务层面请求量、延迟、错误率、模型层面预测分布、置信度分布。系统和服务层面的监控用Prometheus加Grafana就能搞定模型层面的监控需要自己埋点。我的做法是在每次推理时记录预测结果的统计信息比如各类别的预测数量、平均置信度等然后定期上报到监控系统。告警规则要根据业务特点来定。比如错误率超过1%持续5分钟就告警或者某个类别的预测占比突然从30%掉到5%也告警。后者往往意味着数据分布发生了变化模型可能需要重新训练。注意监控指标不要只盯着技术指标业务指标同样重要。比如推荐系统的点击率、风控系统的拦截率这些才是最终衡量模型价值的标准。5. 持续迭代AI工程能力的长期维护5.1 模型再训练的策略选择模型上线后随着时间推移数据分布会发生变化模型效果会逐渐下降。这时候需要再训练。再训练的策略有几种定时全量再训练、增量再训练、触发式再训练。定时全量再训练最简单比如每周用最近三个月的数据重新训练一次。优点是实现简单缺点是计算成本高而且如果数据分布没怎么变可能白跑一次。增量再训练是在原有模型基础上用新数据继续训练。这种方式计算成本低但有个风险是模型可能会遗忘旧数据中的模式也就是灾难性遗忘。缓解办法是混合一部分旧数据一起训练。触发式再训练是监控到模型效果下降到某个阈值时再触发训练。这种方式最经济但需要有一套可靠的监控体系来准确判断模型效果是否下降。我的建议是组合使用平时用定时增量再训练保持模型更新同时设置效果监控如果指标下降超过阈值就触发全量再训练。5.2 特征管道的维护与更新AI工程里有一块很容易被忽略的是特征管道。训练时用的特征和线上推理时用的特征必须一致否则会出现训练-服务偏差。这个问题在特征工程比较复杂的时候尤其突出。解决办法是建立统一的特征计算层训练和推理都调用同一套特征计算逻辑。比如用Feast这样的特征存储工具定义好特征视图离线训练时从特征存储读取历史特征线上推理时从特征存储读取实时特征。这样能最大程度保证一致性。特征管道的更新也要谨慎。如果要新增一个特征需要先离线验证这个特征对模型效果有没有提升然后再上线。上线时要注意新旧特征的兼容性避免因为特征缺失导致推理失败。5.3 技术债务的定期清理AI项目跑起来之后很容易积累技术债务。比如临时写的脚本没有整理、实验代码和线上代码混在一起、文档过时等等。这些债务短期不影响运行但长期会拖慢迭代速度。我的做法是每个季度安排一次技术债务清理专门花时间做几件事把临时脚本整理成正式的工具函数、把实验代码和线上代码分离、更新文档和注释、清理不再使用的依赖包和模型文件。还有一件重要的事是回顾监控告警。随着业务变化有些告警可能已经不再适用有些新的风险点可能还没有覆盖到。定期回顾一遍告警规则该删的删该加的加。6. 一些踩坑之后的个人体会做AI工程这几年最大的体会是工程能力比算法能力更稀缺。一个模型效果提升几个点很难但把工程流程理顺让迭代速度翻倍相对容易得多。而且工程能力是可以复用的换一个项目、换一个领域数据管道、实验管理、部署监控这些经验都能直接用。另一个体会是不要追求一步到位。我见过有人一开始就想搭一套完美的MLOps平台结果花了三个月还没跑通第一个模型。正确的做法是先让流程跑起来哪怕是用最土的办法然后再逐步优化。先解决有无问题再解决好坏问题。最后说一个具体的技巧每次开始一个新项目先花半天时间把项目目录结构定好。我的习惯是分成data/、notebooks/、src/、configs/、tests/、scripts/几个目录数据放data/探索性分析放notebooks/正式代码放src/配置文件放configs/测试放tests/运维脚本放scripts/。这个结构看起来简单但能避免后期代码乱成一团。目录结构定好之后再往里填内容思路会清晰很多。
