我最近大半年都在折腾一件事：把手头几个AI项目从“能跑通代码”变成“能稳定上线服务”。这整个过程的本质，就是标题里写的ai-engineering-from-scratch——AI工程从零开始。老实讲，模型调参本身并没有那么折磨人，真正让人半夜爬起来看监控的，是数据、版本、部署、监控这些工程环节。任何一个地方掉链子，模型在离线指标上再漂亮，上线也是原形毕露。
这篇文章不聊算法Paper，也不提供“AI速成大法”，而是把我从零搭建AI工程体系时踩过的坑、验证过的方案、留下的配置，原原本本梳理一遍。适合谁看？一种是刚入行、想从“会调库”走向“能交付”的算法工程师；另一种是团队里已经开始有多个模型项目，但总感觉“每次上线都像第一次上线”的工程负责人。
1. 先搞清楚：AI工程到底在解决什么问题
1.1 为什么“模型跑通”和“系统可用”之间隔着一条鸿沟
很多人在Notebook里把模型跑通，准确率看着不错，就觉得完事了。但把同样一个模型放到线上，你会发现一堆Notebook里根本不存在的问题：请求一多就超时、特征顺序变了导致预测结果错乱、模型文件和生产环境依赖不一致导致加载失败、训练数据分布和线上实时数据分布根本不匹配。这些问题不带任何学术美感，却直接决定项目能不能落地。
AI工程的定义，我自己的理解很朴素：把“某一次成功的实验”变成“可重复、可控、可观测的稳定系统”。它关注的是模型之外的那部分——数据怎么管、实验怎么记、服务怎么发、线上怎么盯。一旦你开始同时维护两三个模型项目，就会明白没有这套工程体系会乱成什么样：你今天改了数据集，明天改了预处理逻辑，后天换了个基座模型，结果线上效果变差了，你根本说不清是哪一步引入的。
所以AI工程不是锦上添花，是雪中送炭。它是模型从实验品变成产品之间的一切必要工作。
1.2 AI工程的最小闭环长什么样
我一开始犯的错误是追求大而全，上来就想上Kubernetes、搞Feature Store、搭完整的ML平台。结果光在基础设施上就耗了两周，业务模型一点没推进。后来我砍掉大部分想法，只保留一个最小闭环：
环境可复现 → 数据有版本 → 实验有记录 → 模型可打包 → 服务可部署 → 线上有监控 → 监控反馈回数据集。
这七个环节首尾相接，形成一个圈。每个环节不需要用多复杂的工具，但必须有。刚开始哪怕用Shell脚本和CSV记录都行，先把闭环跑通，再逐步把每个环节的工具替换成更专业的方案。如果一上来就追求生产级MLOps基建，大概率是建了个漂亮的空壳，业务根本用不起来。
我给出的顺序建议是：先做模型打包和服务化，再做实验记录，再做数据版本，最后做监控。因为前两件事能立刻让业务方看到“模型能上线了”，给了信心，后面的事才好推进。
2. 从零搭AI工程：环境、数据与实验管理
2.1 环境一致性：别在“我机器上能跑”上栽跟头
AI工程的第一道坎，是环境一致性。最常见的翻车现场：本地Python 3.9、PyTorch 1.13，一切正常；测试服务器上是Python 3.8、PyTorch 1.12，结果某个算子行为不一样，推理结果直接对不上；再换到生产环境的Docker容器，CUDA库版本又不对，模型加载报错。你说这算谁的锅？
解决方案一句话：从第一行代码开始，就把环境写死。具体做法是：
- 用
requirements.txt或pyproject.toml锁住Python包版本，包括传递依赖也尽量锁住。直接用pip freeze > requirements.txt是最原始的方案，但会把一堆无用包也锁进来。更建议用 Poetry 或 uv，它们能生成可锁版本的 lockfile。 - 操作系统和基础镜像固定。训练和推理各自维护一个Dockerfile，基础镜像写死具体tag，比如
pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime，不要用latest。每次跑完训练，把当时的镜像tag记进实验记录里。 - CUDA、cuDNN 的版本要跟框架编译时对齐。最简单的验证方法：在目标环境跑一遍模型的CPU和GPU推理，输出差的绝对值如果超过1e-4，说明环境不一致的可能性很大，先排查环境再排查代码。
我习惯在项目根目录放一个environment/文件夹，里面存着：基础镜像对应的Dockerfile、requirements文件、Makefile或justfile（用来一键搞定“构建镜像→启动训练→启动服务”之类常规操作）。新人接手项目时，第一件事不是装环境，而是执行make dev，如果失败就知道是环境问题而不是代码问题。
2.2 数据版本管理：喂给模型的数据不能“随缘”
模型训练里有个我最开始忽视的问题：数据集变了，但没有记录“什么时候变的”“在哪一版基础上变的”。结果就是，同一个模型代码，隔一个月重跑，指标完全不同，而整个团队没人记得清训练集到底增删了多少样本。
数据版本管理的核心原则：把数据集当作代码一样对待。数据集每次变更，都应该有一个明确的版本号、变更说明和哈希校验值。
在入门阶段，最轻的方案是：
- 每个数据集文件夹里放一个
metadata.yaml，记录数据来源、清洗规则、样本数量、标签分布、生成时间。 - 用
git-lfs存小数据集（几个GB以内可以），或者用对象存储 + 一个 JSON/YAML 清单文件记录版本。 - 训练脚本启动时，加载指定版本的数据快照，并把版本号写入训练日志。
如果数据集比较大、结构比较复杂，再上 DVC（Data Version Control）。DVC 的核心思想不复杂：把数据文件放在对象存储或NAS上，用Git管理“数据文件的指针和哈希”。你切换Git分支，数据也跟着切换，训练时拉取的就是当时对应的快照。DVC让“哪个代码版本 + 哪个数据版本”成为一个可以精确回溯的组合。
我在实操中的体会是：数据版本化最重要的不是选哪个工具，而是把“训练集/验证集/测试集不允许覆盖式修改”这条纪律定下来。每次数据清洗、去重、修复标签，都必须生成新版本，旧版本保留。否则你线上模型出问题，想复盘时连“模型当时是用什么数据训的”都说不清。
2.3 实验追踪：让每一次尝试都能复现
实验追踪我是最晚补的，代价是我吃过大亏：有一版模型效果特别好，但我死活想不起来用了什么超参组合。因为我是Notebook里随手改几个参数跑出来的，没有记录。后来回头复盘，那版的关键在于学习率调度策略，而那个策略我根本没记下来。
从那以后，所有训练任务都接入实验追踪系统。我的首选是 MLflow Tracking，因为它是开源方案里对团队最友好的，安装轻量，Python API简单，而且除了跟踪指标外，还能顺便管理模型文件。
MLflow 里的核心概念三个：
mlflow.set_experiment("project_name")：划定实验范围。mlflow.log_param()记录超参数，mlflow.log_metric()记录每个Step的指标。mlflow.log_artifact()把模型文件、预处理配置、标签映射表等文件归档进去。
实操中的建议：把模型的预处理逻辑也当作“参数”记录下来。很多人只记超参，不记预处理。其实preprocessing的不同（比如是否做标准化、用什么方式做缺失值填充）对效果的影响往往比某个超参还大。我会在训练脚本里把预处理的关键配置序列化成JSON，然后log_artifact存进去。这样复盘时打开一次实验，代码、数据、预处理、超参、指标、产物全都能对上，才叫真正的可复现。
3. 模型训练与评估：从跑通到可交付
3.1 选基座模型还是自己训练，标准是什么
很多新人面对的第一个AI工程决策是：这个任务到底用别人训练好的模型，还是自己从零训练？这本质上是一个工程成本问题，不是技术面子问题。
我的决策标准很直接：
- 如果任务属于通用领域（文本分类、NER、情感分析、通用目标检测），首选使用预训练模型或大模型API做微调，而不是从零预训练。理由是预训练成本极高，你一个人或一个小团队根本刷不出和数据规模匹配的收益。
- 如果任务非常垂直（比如特殊文档版式解析、特定工业场景缺陷检测），需要大量领域数据，那应该基于通用基座做继续预训练或充分微调，而不是从零Random Init。
- 如果对延迟和成本敏感，且任务逻辑简单直接，可以考虑蒸馏一个小的专用模型。
具体实操里，我给大家一个“最稳妥起步”的路径：先用现成模型/API做一版端到端POC，验证业务可行性；然后把POC里的badcase汇总，判断是缺数据、缺特征还是任务定义不清；最后再决定要不要微调、用什么模型微调。这样每一步都有依据，不会把宝贵的算力和时间浪费在自嗨式调参上。
3.2 评估体系怎么搭：不能只盯着准确率
AI工程落地时，业务方问“效果怎么样”，如果你只回“准确率93%”，这个对话大概率会出问题。因为离线准确率高不等于线上好用。比如一个欺诈识别场景，正样本只占0.1%，你模型把所有样本都判为正常，准确率也是99.9%，但业务上一分钱防不住。
我的经验是把评估切成三层：
- 模型层指标：除了总体准确率，还必须看查准率、查全率、F1，尤其是少数类上的表现。建议同时输出混淆矩阵。对于排序任务看NDCG、MAP；对于生成任务看ROUGE/BLEU以及人工抽检率。
- 业务层指标：模型产出的结果真实投到业务里会产生什么变化，比如信用卡反欺诈里的“拦截率”“误伤率”、搜索场景里的“点击率”“无结果率”。这些指标才真正代表模型对业务产生了正向价值。
- 稳定性指标：训练集、验证集、测试集之间的指标方差，以及同分布样本在不同时间段的指标波动。如果模型测试集分数很高，但换个时间段的数据就崩，说明泛化能力不行，上线风险极大。
所以我建议每个模型项目都建一份评估文档，固定评估脚本和评估数据集。每次算法迭代，必须跑同一套评估流程，量化对比，而不是拍脑袋说“感觉好多了”。为此，我写了一个evaluate.py，输入模型产物路径，输出一份JSON报告，里面包含模型层指标、分阈值曲线、badcase列表。这份报告会自动归档到MLflow，供以后回溯。
3.3 训练资源有限时的省钱策略
不是所有人都有一柜子GPU可以随便造。我自己做AI工程的经验里，训练资源往往是瓶颈，所以省钱策略必须前置。
- Batch Size 和梯度累积：大Batch一般更稳，但显存不够时用梯度累积模拟大Batch，关键是把有效Batch调大后适当调整学习率，否则收敛不稳。
- 混合精度：FP16能大幅省显存和加速，但注意 loss 可能出现 NaN，尤其是小模型和大学习率组合下。建议AMP和Loss Scaling一起用，跑短实验验证稳定性。
- 提前停止、早停和模型快照：监控验证集指标，连续N个epoch不涨就停止，同时保存最佳模型快照。而不是傻跑固定epoch数。
- 合理选择模型体量：先用小模型（比如BERT-tiny、ResNet18）把流程跑通，再把规模换大。全流程（数据处理→训练→评估→导出→上线）用小模型验证没问题，再上大模型，能省大量试错成本。
- 微调时冻结大部分层，只训练最后几层或Adapter。这样显存占用和计算量能缩小一个数量级。如果效果不够，再逐层解冻。
这块想跟大家多说一句：训练资源少不丢人，用有限资源把流程跑通、把证据链留全，比在超大集群上跑一堆没人看的实验有价值得多。AI工程考量的从来不是“谁算力大”，而是“谁交付得稳定”。
4. 模型上线：部署链路与推理优化
4.1 FastAPI+Docker：把模型包成一个标准服务
模型训练完之后，最重要的一步是把它变成一个可以被业务调用的服务。我推荐的最轻量、最可靠方案是 FastAPI + Uvicorn + Docker。FastAPI 的优势是自带请求参数校验、自动生成OpenAPI文档、性能也不错，对AI服务来说完全够用。
一个标准的模型服务结构大概长这样：
server/ app.py # FastAPI 入口 model_loader.py # 模型加载与预热 inference.py # 前处理/推理/后处理 schemas.py # 请求/响应模型 requirements.txt Dockerfile我在app.py里的最低必要配置：
- 启动事件中加载模型，并将模型对象放在全局变量里。不要在每次请求时去加载模型，否则延迟会高得离谱。
- 用Pydantic定义请求Schema，保证输入合法性，比如文本长度限制、数值范围校验，不要指望下游模型能处理乱七八糟的输入。
- 包一层可观测中间件，记下每次请求的耗时、模型版本号、输入长度分布。
Dockerfile 里的关键点：基础镜像尽量用官方python:3.10-slim，如果你需要GPU推理则用带CUDA的镜像；把requirements.txt先复制进镜像并安装依赖，再复制代码。这会利用Docker Layer缓存，改动代码时不会每次都重装依赖。启动命令用uvicorn app:app --host 0.0.0.0 --port 8080 --workers 2。worker数量建议先设为CPU核数，再压测调整。
提示：千万不要把训练时用的整个虚拟环境或模型Checkpoint直接塞进生产镜像。镜像里只放推理必需的东西：模型导出文件（如ONNX或TorchScript）、预处理配置、后端依赖。镜像越小，启动越快，出问题面也越小。
4.2 推理延迟优化：能省一点是一点
上线之前一定要压测，不压测你根本不知道这个服务能扛多大流量。我在压测中发现的一个典型问题：模型本身推理只需要几毫秒，但Python端前处理和JSON序列化却花了上百毫秒，导致整体延迟不可接受。总的来说，推理优化有几个层级的思路：
- 输入输出层：能批量推理就批量推理。单条请求过来时，可以把多条请求攒一小段时间（比如攒10条或50ms）再统一过一次模型，吞吐能提升好几倍。但要权衡延迟，不是所有场景都能接受攒批。
- 模型编译层：PyTorch 可以用
torch.compile()，或导出成ONNX后用ONNX Runtime跑。ONNX Runtime在CPU上的加速通常很明显，尤其在Transformer结构上。简单任务里，导成ONNX后推理开销能降低30%-50%，强烈建议试一下。 - 量化层：INT8量化对显存和速度都有帮助，代价是精度损失。一个折中的做法是用FP16精度推理，损失很小，速度也能提升。生产环境里最好做量化前后的对比评估，不要默认“量化没损失”。
- 缓存层：对重复性高的请求，比如相同文本查相同内容，可以用LRU缓存或者Redis缓存结果。注意缓存key的规范化，避免因空格或全半角差一点导致缓存完全失效。
这一段的实操心得是：先压测，再优化。用locust或wrk打一下，看P95延迟和吞吐，找到瓶颈再动手。别一上来就搞TensorRT，很多场景把FastAPI处理层优化一下，比折腾推理引擎收益大得多。
4.3 服务治理：版本、灰度与回滚
模型是要迭代的，所以服务从第一天起就要考虑多版本的问题。我见过最原始的方式：直接改代码把新模型路径替换掉，重启服务。这种做法一旦新模型有严重线上问题，想回滚都不知道旧文件还不在。正确做法是：
- 模型文件带上版本号放到对象存储或NAS镜像目录里，比如
model/mt5_sentiment_v3.onnx。路径里带版本号，而不是都用model.onnx覆盖。 - 应用支持通过环境变量指定加载哪个版本，比如
MODEL_VERSION=v3。这样升级时只需要改Kubernetes的环境变量配置，就可以平滑切换版本。 - 线上保留至少一个旧版本路径，万一新版本出问题，立刻把环境变量切回去。整个过程不修改代码、不重新构建业务逻辑，只做配置变更。
- 更稳妥的做法是灰度发布：先切5%流量到新版本服务，观察一段时间指标，没问题再加到50%、100%。如果团队已经有网关或服务网格，用它们的路由能力实现；如果没有，也可以先做“影子流量”——把线上请求复制一份打到新版本服务上，比对新旧版本输出差异，但不影响真实业务。
服务治理这部分最容易被算法团队忽略，但对运维和业务连续性至关重要。一个不起眼的“模型版本管理”，能把故障恢复时间从小时级降到分钟级。
5. 线上监控与持续迭代
5.1 模型在线上跑偏了怎么及时知道
模型上线不是终点，而是持续运营的起点。我吃过最大的亏，就是模型上线后两周没盯，然后业务方跑过来说“最近效果怎么明显变差了”。我一看，需求的数据分布早就变了，模型还在用老逻辑硬扛。
线上的监控指标我分成两类：
- 系统指标：CPU、内存、GPU显存、请求量、延迟P50/P95/P99、错误率。这部分用Prometheus+Grafana就能解决，配合告警规则。我建议最优先盯两个：错误率超过阈值（比如5%）和P95延迟突增。
- 模型指标：预测结果分布、空结果率、平均置信度、特征分布偏移。这部分要结合业务来看。比如一个交易风控模型，上线后平均分从0.3漂到0.7，那就说明特征分布变了或者有异常数据进来，需要触发人工排查。
更专业的做法是记录每次请求的输入特征快照和预测结果，按天或者按小时做统计，存入数据库或者数据仓库。当天的特征均值、方差和训练集特征均值、方差如果出现大幅度偏差，就说明发生了数据漂移。
我自己的监控告警设置：白天每5分钟检测一次最近1小时的数据分布变化，如果PSI超过某个阈值（比如0.2），立刻发告警到企微/钉钉群。宁可误报多点，也不要漏报。
5.2 数据回流与自动重训的门槛
监控发现问题之后，最理想的流程是：把线上badcase回流到标注池，由人工标注或算法辅助修正，扩充训练集，然后重训模型，验证通过后重新发布。这就是数据闭环。
但自动重训没有想象中那么简单。我团队里最早尝试“每周自动重训一次”，结果新模型上线后效果反而更差了——因为新数据本身有偏，自动标注质量参差不齐，直接把模型带偏了。从那以后，我总结出自动重训必须满足的几个门槛：
- 有足够高质量标签。自动标注或弱监督标签必须经过采样抽检，抽检准确率低于90%就不会直接用。
- 有稳定的评估集。不能用一个持续变化的评估集来评判模型好坏，否则指标的波动会让你分不清是模型变好了还是评估集变严了。
- 有明确的发布标准。新老模型做离线对比，必须在关键指标上不差于老模型（比如F1不降、badcase数量不增），才能进入灰度。
- 有快速回滚能力。自动重训发布后如果线上指标异常，要能一键回滚到上一个稳定版本。
最终我把“自动重训”降级为“半自动重训”：系统自动采集数据、自动触发训练、自动生成评估报告，但最终是否发布由人确认。既保留了闭环的效率，又加了一道人为把关的风险阀。这套流程跑顺之后，我的模型迭代效率比之前手工处理高了一倍不止。
6. 我踩过的坑与实操清单
6.1 几个典型翻车现场
聊聊我记忆特别深、也特别有代表性的几个坑。很多问题在网上基本搜不到系统性的解决方案，都是一点点踩出来的。
坑一：训练脚本在本地能跑，一上GPU服务器OOM。原因是本机显存大，Batch Size开得很高，换到小显存机器直接爆。后来我把Batch Size、显存占用做成配置项，并用torch.cuda.max_memory_allocated()观察显存峰值，在训练脚本里加自动Batch Size检测，超了就自动降配，而不是崩溃。
坑二：换了机器，模型推理结果完全对不上。排查一圈发现是sklearn版本不一致导致的预处理结果不同。从那以后，预处理逻辑全部固定版本，并且把关键预处理步骤输出成SavableArtifact（比如归一化参数、词表映射），由模型服务统一加载，不依赖训练时的全局状态。
坑三：模型服务上线后每天凌晨出现大量超时。查了半天，发现是日志库在凌晨做切分，阻塞了事件循环。这是典型的“系统性问题被模型问题掩盖”。后来把日志写入改成异步，并且独立进程导出日志，服务本身才稳定。
坑四：灰度发布一刀切，全量切过去后新模型在某个流量段上疯狂输出低质量结果。解决方案就是前面说的灰度+影子对比，先让新模型“无流量”在线上一段时间，比对输出，稳定后再放量。
6.2 给准备动手的人的checklist
如果我现在要带领一个新团队从零搭建AI工程体系，我会按下面这张清单推进，每项都是低成本高收益的：
- [ ] 项目根目录有
environment/，锁住Python依赖和Docker基础镜像。 - [ ] 训练脚本支持传入数据版本号，并在输出日志中记录数据目录的哈希。
- [ ] 每次实验都能在MLflow或同类系统中找到完整记录（参数、指标、代码commit、数据版本、产物）。
- [ ] 模型导出为稳定的推理格式（TorchScript/ONNX），生产环境不直接加载训练Checkpoint。
- [ ] 推理服务用FastAPI封装，加载模型预热，Pydantic校验输入，中间件记录延迟。
- [ ] 用Docker构建生产镜像，镜像尽量小，启动命令固定。
- [ ] 压测完成，知道服务的P95延迟和最大吞吐能力。
- [ ] 模型路径带版本号，支持环境变量切换版本和快速回滚。
- [ ] Prometheus+Grafana监控系统、模型指标，配置基础告警规则。
- [ ] 设计好数据回流路径，哪怕是人工收集badcase，也要有稳定的通道。
- [ ] 制定模型发布规范：离线对比→灰度→全量→回滚预案，每条都要可执行。
我自己在实际操作中有一个很深的感受：AI工程的本质就是把不确定性变成确定性。模型有不确定性是正常的，但环境、数据、版本、监控这些环节的不确定性，是可以通过纪律和工具消除掉的。你每补上一个环节，半夜被叫起来的概率就小一点。这大概就是“从零开始做AI工程”最直接的回报。
最后再分享一个小技巧：团队里如果只有你一个人懂这套流程，一定要把每一步的操作文档写下来，哪怕只是几行命令和注意事项。因为等你忙起来，或者有新同事接手，最怕的不是不懂算法，而是不知道你当时是怎么把模型送上线的。文档不追求长篇大论，能让人照着三步走到上线就够了。
