从零开始做AI工程我是怎么把“会调模型”变成“能上线跑”的做AI工程这行的朋友应该都有体会模型本身不是最难的部分难的是把模型稳定、可控、可复用地放进一套工程体系里。我发起这个“ai-engineering-from-scratch”项目坦白说是给自己补课。过去两年我一直在一线做算法落地的活儿天天和数据集、训练脚本、推理接口打交道但真正让我下定决心把这些经验整理成完整体系的是一次生产事故——模型在实验环境里跑得好好的一到线上服务就内存爆炸回滚又找不到版本最后靠手动重启撑了三天。那之后我就认了一件事AI工程能力不能靠零散经验堆得从头搭一套自己的方法论。这个项目就是干这个的。它不是教你写几个神经网络不聚焦某一个模型而是把数据、训练、评估、部署、监控、迭代这一整条链路当成一个系统工程来讲。从我自己的实操视角出发把每一步怎么做、为什么这么做、哪里有坑全部记录下来。适合谁看刚入门AI开发、想把算法模型做成真实服务的人已经在做算法、但欠缺工程化思维的人以及想复盘自己工作流、提升交付效率的团队。这篇文章就是项目的一份总纲性复盘把我踩过的坑和沉淀下来的方法一次性讲透。1. 从零搭建AI工程体系的整体思路1.1 先回答一个关键问题为什么强调“从零开始”很多人的学习路径是“拿来主义”——直接用现成的库、现成的预训练模型、现成的框架跑通一个demo就觉得已经入门。但真正到了工程现场你会发现所有现成的东西都有隐藏夹层数据格式不兼容、依赖版本冲突、训练结果无法复现、模型上线后性能和实验指标对不上。这些问题靠“会调模型”根本解决不了你需要的是对每个环节底层逻辑的掌控力。“从零开始”不是说每个算法都要自己实现也不能这么干而是说对于整条流水线你必须具备“亲手搭起来”的能力。数据怎么收集、怎么清洗、怎么做特征、怎么切分训练集、训练脚本怎么写、模型怎么序列化、怎么包装成服务、怎么做压测、怎么监控漂移每一步都自己动手搭建过出了问题时才能定位到具体节点。我在这套项目里给自己定了一个硬性原则所有核心代码不依赖重型框架的自动流程全部手工实现一遍。比如数据处理用Pandas自己写清洗逻辑模型训练用PyTorch但自己写训练循环部署这一块则用FastAPI自己封装推理接口。这样做的副作用是前期进度慢但好处在后端爆发——每一层怎么工作、什么参数影响什么我都清楚。1.2 从想法到落地的路线图拆解整个项目我拆成了五个阶段每个阶段对应一个独立模块可以单独看也可以串联用数据工程数据的获取、清洗、标注、增强、切分。这是整个流水线的地基数据质量直接决定模型上限。模型实验基线选择、训练脚本、超参数调优、评估指标、实验结果记录。推理落地把训练好的模型转成可部署的产物封装API处理并发和延迟。部署上线容器化、接口网关、自动扩容、日志采集、监控告警。迭代闭环模型漂移检测、数据回流、重新训练、版本切换。用一张表可以快速看到每个阶段的输入、输出和关键工具阶段输入输出常用工具/手段数据工程原始数据干净可用的训练/验证/测试集Pandas、NumPy、自定义清洗脚本模型实验处理好的数据模型权重、评测报告PyTorch、Optuna、MLflow推理落地模型权重推理服务APIONNX、FastAPI、Docker部署上线Docker镜像稳定运行的线上服务Kubernetes、Grafana、Prometheus迭代闭环线上日志/新数据新模型版本、评估结果事件流、标注工具、CI/CD流水线对初学者来说最容易掉进去的坑是直接跳到第三阶段以后想赶紧把模型部署出去看效果。但后面你会发现在生产环境里修数据比调模型更常见。所以我在项目里强迫自己按顺序来每个阶段完成后写一段复盘文档确保前一步没有“欠债”。2. 技术选型为什么是这套组合2.1 语言与核心框架选型这个项目我用Python作为主语言原因很直接AI工程生态几乎都在Python这边无论是数据处理、模型训练还是服务封装都有成熟的库做支撑。但这里有个被很多人忽略的问题——Python的性能边界。训练阶段是GPU密集不太care Python本身的开销但推理服务阶段如果也直接用Python写同步接口并发一上来很容易卡死。所以我在项目里做了一个关键决策训练用Python推理接口仍然用Python封装但服务层引入异步和批处理优化并且做压力测试来量化瓶颈。深度学习框架选的PyTorch这是目前工程落地最稳的选择没有之一。TensorFlow也有强项尤其在生产部署上有自己的生态但PyTorch的优势在于动态图和调试的直观性对做工程的人特别友好。我在项目里尝试过两边都写一遍同样的训练循环明显感觉PyTorch的代码可读性更高、排查问题更直接。2.2 数据与实验管理选型数据版本管理很多人不重视只用文件夹加日期就不管了。我吃过亏有一次训练出来的模型效果特别好但后来发现用的是一份被手工改过、没记录变更的训练集模型虽然指标高却不可复现上线后立刻翻车。所以这个项目从一开始就给数据加了一层版本管理用的是DVC因为它在Git基础上做了一层数据引用管理学习成本低、和现有工作流兼容度高。实验管理用的MLflow虽然它不算最轻量但它对PyTorch的支持好而且能同时管指标、参数、模型产物和注册表省掉我一个一个造轮子的时间。我一直强调实验记录要自动化、结构化因为人手动记的笔记靠不住输出端口的精度、训练步数、随机种子都会影响结果人手记录很容易漏。2.3 部署与监控选型部署层选的是Docker加Kubernetes这是现在的事实标准。FastAPI负责推理HTTP服务。之所以不用Flask一是FastAPI天然支持异步对推理服务这种IO和计算混合的场景更合适二是pydantic的请求校验在接口这块省了非常多的事。模型推理我转了ONNX这样做的好处是模型脱离了PyTorch的运行环境依赖Docker镜像可以更小、更快、更安全。监控这里很多小团队会忽略以为服务不崩就万事大吉。我在项目里用了Prometheus加Grafana把推理时延、QPS、显存占用、错误码都打点记录。这些指标倒不是给老板看的而是优化和预警用的。3. 核心实操数据到模型的完整链路3.1 数据处理从原始日志到规整数据集我选择了一个真实场景练手预测服务器CPU使用率。原始数据是系统日志里采集下来的时间序列格式非常乱时间戳时区都不统一部分字段还会缺失或重复。这个场景特别适合入门因为数据形态原始问题直观和实际业务贴得近。第一步是写清洗脚本。核心就一件事把非结构化的文本转成结构化的表格。用Pandas逐行解析统一时间戳格式、去重、填充缺失值。这里有个细节值得说填充缺失值不能随便用均值或中位数要看数据的时序特性。CPU使用率有明显的周期规律我用同小时内相邻几天的中位数来填充既保留了周期信号又不引入过多噪声。如果直接用均值填充等于把尖峰和谷底都抹平了模型学到的规律就是错的。第二步是特征工程。时序数据不能直接喂给普通模型我做了三部分特征滑动窗口统计过去30分钟均值、最大值、趋势、周期性编码小时、星期几的one-hot和sin/cos编码、外部特征当前负载、连接数等。这部分我特别推荐大家花时间做一个真正可用的AI工程特征工程往往是效果提升最明显的一环比换模型结构还管用。第三步是数据切分。原则是严格按时间顺序禁止随机切分。这一点很多人忽视时间序列数据如果用随机切分相当于让模型偷看到了“未来”训练时的评估指标会虚高很多等上线拿到真实数据就露馅。我按照时间序前70%训练、后15%验证、最后15%测试并且保证验证集时间上紧挨训练集之后模拟真实环境里“用过去预测未来”的用法。3.2 模型训练一项一档吃透训练循环很多人习惯了PyTorch Lightning或者Keras的封装训练循环是一行代码内部发生了什么完全不知道。这个项目里我坚持手写训练循环因为只有手写你才会理解backward、optimizer.step()、gradient accumulation这些概念在真实训练里到底怎么联动。基线模型我选了一个简单的多层感知机输入特征维度大约30个两层隐藏层各64和32个神经元输出层一个神经元预测CPU使用率。损失函数用MSE优化器选Adam学习率初始设置为1e-3。代码关键部分长这样import torch import torch.nn as nn class MLP(nn.Module): def __init__(self, input_dim): super().__init__() self.net nn.Sequential( nn.Linear(input_dim, 64), nn.ReLU(), nn.Linear(64, 32), nn.ReLU(), nn.Linear(32, 1) ) def forward(self, x): return self.net(x) model MLP(input_dimX_train.shape[1]) optimizer torch.optim.Adam(model.parameters(), lr1e-3) loss_fn nn.MSELoss() for epoch in range(100): model.train() for batch_x, batch_y in train_loader: optimizer.zero_grad() pred model(batch_x) loss loss_fn(pred, batch_y) loss.backward() optimizer.step()学习率1e-3不是拍脑袋选的。我先跑了几个小实验对比不同量级的lr发现在1e-3时loss下降平稳1e-2时发散1e-4时收敛太慢。做AI工程一定要养成这种小实验对比的习惯每次改一个变量做好记录不要一次改多个变量那样结果根本没法归因。训练过程中还加了早停机制验证集的loss连续10个epoch不下降就停止训练并恢复最佳权重。这个早停的耐心参数也是试出来的太小会欠拟合太大浪费时间10这个数值对这个场景刚好。3.3 评估指标和调优回归任务的评估指标我用的是RMSE和MAE。RMSE对大误差敏感适合判断有没有极端预测偏差MAE更直观单位就是真实值单位。两个指标结合看能判断误差的分布形态。如果RMSE远大于MAE说明存在一些预测特别离谱的样本需要针对性排查。调优这一块我用的是Optuna做贝叶斯搜索。虽然网格搜索更简单但维度一多网格搜索的组合数爆炸根本不现实。Optuna有智能剪枝机制差劲的试验会被提前终止节省大量时间。我设置的搜索范围包括隐藏层大小32到128、层数1到3层、dropout0到0.3、学习率1e-4到1e-2、batch size16到128。搜索结束后模型在测试集上的RMSE比基线下降了大约22%。这个提升主要来自三个改动特征窗口从15分钟增加到30分钟、隐藏层宽度增大、加了一点dropout。调参找方向这种事经验不足时搜索引擎式地试是最有效的方法前提是每次试验都规范记录。4. 工程化落地从训练到部署4.1 项目结构设计工程化项目最重要的不是代码本身是目录结构的可维护性。这个项目我按层次分了几个核心目录ai-engineering-from-scratch/ ├── data/ │ ├── raw/ # 原始数据只读 │ ├── processed/ # 清洗后的数据 │ └── splits/ # 切分好的训练/验证/测试集 ├── features/ │ ├── build_features.py │ └── feature_config.yaml ├── models/ │ ├── train.py │ ├── evaluate.py │ └── predict.py ├── api/ │ └── serve.py # FastAPI推理服务 ├── deployment/ │ ├── Dockerfile │ └── k8s/ ├── monitoring/ │ └── prometheus_config.yml └── run/ ├── train.sh └── serve.shdata/raw目录设成了只读这是刻意为之。任何对原始数据的错误修改都会导致不可复现的结果只读是最底层的保护。processed和splits是可以重建的中间产物我会在文件头记录生成这些文件用的脚本哈希值确保版本可追溯。4.2 把模型封装成推理服务模型训练好只是第一步真正上线前要把它包装成一个稳定、可控的服务。我选择ONNX作为中间格式把PyTorch模型转成ONNX后的推理速度提升了不少尤其是在CPU上。转换代码import torch import onnxruntime model.eval() dummy_input torch.randn(1, input_dim, devicecpu) torch.onnx.export( model, dummy_input, cpu_model.onnx, input_names[input], output_names[output], dynamic_axes{input: {0: batch}, output: {0: batch}} ) session onnxruntime.InferenceSession(cpu_model.onnx)FastAPI的封装里我做了两个重点处理一是请求和响应都通过pydantic定义了严格格式字段对不上会直接报4xx而不是内部错误二是做了一层预测的缓冲区单次请求进来不打点批量评估或监控时再统一收集避免把推理服务搞成日志系统。上线前压测是必要的不压测你根本不知道服务真实的吞吐上限。4.3 用Docker固定环境避免“在我这儿跑得好好的”依赖环境不一致是所有AI项目最大的杀手。我踩过最经典的坑是本机torch是2.0线上跑的镜像里是1.12结果张量的某些运算行为变了模型输出全乱。解决办法就是容器化锁死所有版本。写Dockerfile时我特别注意镜像分层FROM python:3.9-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD [uvicorn, api.serve:app, --host, 0.0.0.0, --port, 8000]有一部分细节值得展开先复制requirements.txt再复制代码这不是随手写的顺序而是为了利用Docker build缓存。依赖如果没变后半段就不会重新跑pip install日常迭代镜像的构建时间能缩短一大截。另外安装依赖我不用固定死所有传递依赖但核心依赖的版本必须严格固定防止意外升级。4.4 部署不只是起一个容器单机起一个Docker容器最多只能算demo离生产部署还有距离。我在项目里用Kubernetes部署了推理服务配置了水平自动伸缩规则是QPS超过阈值自动增加副本内存接近上限时自动滚动重启。这个配置的好处在于模型服务的流量波动通常很大新建副本需要拉镜像这个耗时在流量突增时是致命的所以我对推理服务没有用常见的KEDA缩到零策略而是长期保持两个副本。上线后我把监控指标接进了Grafana主要盯四件事推理时延P95、每分钟请求数、内存占用、预测结果分布。前三个是服务健康指标第四个是模型健康指标。预测分布发现异常偏移时多半是数据分布变了连续的告警是触发模型迭代的直接信号。5. 踩坑记录和问题排查实录5.1 训练和线上数据分布不一致有过一次很典型的教训模型在测试集上表现良好上线后第一天指标就开始恶化。排查下来发现线上实时数据经过传输链路会偶发乱序和延迟导致特征计算时的窗口统计和训练时不一致。解决办法是在服务端做了一层数据缓冲对齐同时对特征输入做合法性校验非法数据直接拒绝而不是悄悄塞给模型。做AI工程这点必须养成习惯训练时的输入条件和推断时的输入条件要做到完全一致任何差异都可能让模型“被动失效”。5.2 序列化与反序列化的精度损耗模型训练用FP32推理服务用FP16加速转换后精度确实有损耗但通常很小。我在项目里测试的模型转换后RMSE只增加了约1.5%可接受。但教训在于这种精度损耗必须通过实际转换后再评估来确认不要只看理论上的“应该没问题”。有一次在另一个任务里模型对异常点非常敏感FP16直接让某些极端值的预测彻底失真如果不测评就上线后果不堪设想。5.3 常见问题速查表现象可能原因处理手段训练loss不下降学习率过大或过小、特征没有归一化检查学习率、检查数据标准化训练正常但测试指标差数据泄露、过拟合、测试集分布不同检查数据切分逻辑、加正则化推理时延忽高忽低GC频繁、请求批量效应、冷启动预热模型、请求批量缓存线上预测异常值多特征分布漂移、非法输入混入输入校验、特征漂移监控回滚后效果仍然差数据版本不一致、模型版本记录缺失用DVC/MLflow完整记录版本5.4 关于调试和日志的小技巧排查线上问题最大的痛点是没有足够的信息。我给推理服务加了结构化的请求日志每次预测记录三个核心字段输入特征的哈希值、模型版本号、输出值。哈希值的好处是可以通过同样的哈希算法反向追溯判断某类预测异常是不是集中在特定输入模式上。这个习惯帮我在后续迭代排查时节省了大量时间。日志不是越多越好但关键信息一定要留全。另外补一个经验写训练脚本和推理脚本时把随机种子设置好。种子固定了模型结果才能复现。这个细节初期无所谓等你需要对比两个实验的差异时会发现不固定种子连“这版模型更好”这句话都没法说死。6. 如何继续扩展这套工程体系在我个人实际操作中接下来最值得扩展的方向是基于这套基础设施做多模型管理把不同任务、不同版本的模型都放到统一的注册中心里让线上切换模型版本不再是改代码而是改配置。另一个方向是数据回流闭环线上收集到的真实推理请求过滤掉异常之后回流到训练集定期增量训练这样模型才能不断适应新数据分布。这套从零搭建的体系目前已经完全能支撑我日常的算法交付工作凡是新任务进来我都按这套流程先搭骨架再填肉出问题的概率明显比以前凭感觉走低了一个数量级。如果你正在从算法学习迈向工程落地我的建议很简单挑一个真实小场景别太复杂但一定要把数据、训练、封装、上线走完一遍再来说自己做过AI工程。