1. “AI工程”和“AI算法”之间隔着一整条生产流水线两个月前有个做工业质检的朋友拿着“ai-engineering-from-scratch”这个关键词来找我说他团队刚招了两个算法工程师模型在notebook里跑得很欢准确率98%但老板一句话把他问住了“这东西什么时候能上产线”这问题我太熟了。AI工程化ai-engineering根本不是把模型训练出来就完事而是把算法变成一套可运行、可监控、可迭代、出了问题能找到根因的系统。初看这个领域大家容易陷入一个误区以为买张好显卡、跑通一个开源模型、再封装个API就是工程化。实际上去产线跑一圈你会发现真正的难点全在模型之外的环节——数据版本管理、训练可复现性、推理延迟抖动、特征一致性、灰度发布、错误兜底。这篇文章就是我梳理的“从零开始做AI工程”完整路线不是概念堆砌而是我实际从空项目起步、一步步把模型推到生产环境过程中的全部关键决策、踩坑记录和思考方式。无论你是后端想转AI方向的开发者、刚带团队的算法负责人还是一个人扛AI模块的全栈工程师这路线都能让你少走至少三个月的弯路。我先把结论抛出来AI工程化的本质是提高“交付能力”不是提高“模型分数”。你可以在排行榜上刷到SOTA但工程化要解决的问题是“这个模型明天还能不能跑、后天数据变了怎么办、线上出了错能不能十分钟定位”。理解了这句话后面所有环节都有了判断标准。2. 环境这堵墙依赖地狱、Conda与Docker的分工与妥协任何一个从零开始的项目第一关都是环境。但大部分人死在这一关的方式并不相同——有人卡在CUDA版本有人卡在torch和tensorflow的纠缠有人卡在“在我机器上跑得好好的”这句千古名言。2.1 先理清Python包管理的四种工具边界我在项目初期先把工具边界划清楚了这帮我少踩了至少一半的坑工具解决什么问题不擅长什么pip安装Python包处理非Python系统依赖、隔离环境virtualenv/venv隔离Python环境管理CUDA等系统级库版本conda同时管理Python解释器和系统库跨平台lockfile一致性弱Docker把整个操作系统依赖一起锁死Windows/macOS上的GPU直通实战结论是日常开发用conda交付部署用Docker。conda能让你快速切换不同项目环境Docker则解决“第二天开机跑不起来”的噩梦。但这里有个关键细节——Dockerfile里的基础镜像版本必须固定不能写FROM nvidia/cuda:latest这种我吃过一次亏某天基础镜像更新后cudnn行为变化整条推理链路精度掉了0.3个百分点查了整整一天。2.2 CUDA、cuDNN与PyTorch的版本三角关系这不是玄学是真实存在的兼容性问题。我的建议是直接建立一张对照表把项目所有依赖版本钉死并且在新环境验证时同时跑两个东西训练脚本的一次前向推理、和一个0/1测试样例。我当时用的组合是CUDA 11.8不是最新版但生态兼容面最广cuDNN 8.6.0与CUDA配套PyTorch 2.0.1cu118对应版本Python 3.10注意不要因为新版出来了就随手升级CUDA或PyTorch版本。AI项目里牵一发动全身模型权重、算子实现、分布式策略都可能受版本影响。锁版本是第一位的升级必须有明确理由。2.3 可复现性的最后一道保险requirements-lock与离线安装包当项目成员变多、机器变杂之后一个新的问题浮出水面requirements.txt不够用了。你的同事拿到这份文件照样装出不同环境——传递依赖版本漂移。我后来做了两件事用pip freeze requirements-lock.txt把所有传递依赖精确到版本号在离线环境生产网闸机器用pip download -r requirements-lock.txt -d ./packages拉好所有包再拷贝进去离线安装这套流程之后“我这边环境没问题”这句话在公司内部彻底消失。环境问题的本质是不确定性而工程化就是一层层把不确定性替换成确定性。3. 第一个从零训练的模型分类任务的选型逻辑与造轮子过程环境搭好终于可以碰模型了。很多教程上来就让用大模型或迁移学习但“from scratch”的真正意义不是什么都从裸权重练起而是把技术的每个环节都亲手摸一遍理解它为什么这样运作。3.1 为什么第一个项目选文本分类而不是图像识别我当时给自己定的题目是“客服工单自动分类”用BERT做中文短文本多分类。选这个项目的原因有三个数据可以自己造不用外部标注成本、对延迟和算力要求不极端单卡能搞定、业务价值清晰直接替代人工打标。如果你连一个GPU都没有也完全可以做——用CPU跑小模型如textCNN、FastText也能体验全流程关键是流程本身。3.2 数据是第一个大坑标注体系与标签分布自己造数据比想象中耗时。我写了大概3000条客服工单模拟文本涉及5个类别。这时候出现第一个值得讲清楚的问题样本不均衡。5个类别里“查询订单状态”这类自然分布超过60%而“投诉建议”可能只有5%。如果直接拿原始分布训练模型会把绝大多数样本预测为大类整体准确率看起来不低但小类别几乎全挂。我的做法是对少数类做过采样不是简单复制而是基于模板改写句子结构对多数类做欠采样控制在总样本的40%以内最终让所有类别比例接近2:3:3:1:1仍然保留一定真实分布特征这里分享一个后验教训数据清洗的目的是保留真实噪声而不是消灭噪声。我第一次清洗时把所有标点、语气词全删了结果模型在真实线上数据上泛化变差因为真实用户就是会打错字、会用口语。3.3 从零搭一个训练脚本应该包含什么我不推荐一上来就上Lightning或Trainer这种高级封装。先用原生的PyTorch手写循环训练把每个环节暴露在眼前后面用任何框架你都能理解它在替你做什么。关键代码骨架长这样——虽然简单但每个部分都有具体原因import torch import torch.nn as nn from torch.utils.data import DataLoader, Dataset from transformers import BertTokenizer, BertForSequenceClassification from torch.optim import AdamW # 1. 固定随机种子保证可复现 def set_seed(seed42): torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) # 2. 数据类清洗 - tokenize - padding - mask class TicketDataset(Dataset): def __init__(self, texts, labels, tokenizer, max_len128): self.encodings tokenizer( texts, truncationTrue, paddingTrue, max_lengthmax_len ) self.labels labels def __getitem__(self, idx): item {k: torch.tensor(v[idx]) for k, v in self.encodings.items()} item[labels] torch.tensor(self.labels[idx]) return item def __len__(self): return len(self.labels) # 3. 训练策略batch_size先小后大线性warmup # 这样做的意图 # 小batch起步——梯度噪声更大相当于正则化避免初期不稳定 # warmup的目的是让模型先适应数据分布再全力收敛训练脚本里有三个容易被忽略的配置我分别说下它们的理由batch_size: 我选了16。太小收敛慢太大会爆显存开始追求快没有意义稳定才是第一位。学习率: 5e-5。BERT微调这类Transformer模型用太大直接灾难用太小一个星期都训不动。eval_steps: 每500步评估一次不是每epoch评估。数据量大时一个epoch可能要几小时只在epoch结束看指标出了问题没法及时发现。3.4 评估指标的坑准确率在类别不均衡下会骗人这是我特别想讲清楚的一点。模型训练完第一步永远是看混淆矩阵不是准确率。比如我的测试集上准确率达到94%表面看起来很好但混淆矩阵显示“投诉建议”类别的查全率只有52%。也就是说将近一半的投诉被模型分到了“一般咨询”里。在客服场景里这直接意味着严重漏单。这种情况下我会选择用加权F1作为核心指标而不是准确率。因为F1对少数类更敏感你优化的时候才知道模型是在靠大类刷分还是真正学会了区分。这段经历最重要的结论是从零训练模型本身不难难的是你知道每一步的指标、参数、数据操作是在为什么目标服务。模版能帮你写出代码但只有理解每个环节的意图你才能应对真实问题的千奇百怪。4. 工程化的体感模型性能漂移、数据一致性与推理链路的鲁棒性模型训完POC跑通接下来是最无聊但最要命的一段让它变成能被别人稳定使用的服务。这一阶段遇到的问题和训练阶段完全不一样。4.1 训练-服务特征不一致一个让我纠结了整晚的bug上线后第一周模型预测结果在线上频繁出现与离线评估不符的情况。离线F1在0.90以上线上抽检却只有0.82左右。我排查了整整一晚上最后发现根因在分词环节训练时我用的是BertTokenizer默认的lowercaseFalse但服务端接数据前置处理器时谁在之前偷偷把所有英文转成了小写。就这么一个和模型质量无关的数据处理差异让整体效果掉了近8个点。这个问题在AI工程里有个专门说法叫训练-推理一致性Training-Serving Skew。解决方式的版本管理思路是把预处理逻辑做成独立模块训练和服务端共用同一个模块对预处理模块写单元测试任意输入文本训练时预处理后的结果必须和服务端完全一致线上加一个“预测-记录-回放”机制每周拿线上真实请求样本回测离线模型对比效果强烈建议从第一天开始就把预处理环节当成和模型权重同等重要的产品资产来管理。模型可以重新训练但数据流向错乱了神仙也救不了。4.2 延迟与吞吐单条推理1.2秒还是30毫秒的决定性差异模型训完你还需要决定用什么姿势提供服务。以BERT分类为例单条推理用PyTorch直接跑平均耗时120ms用TensorRT/ONNX优化可以压到30ms用批量推理batch推理吞吐能提升5-8倍但延迟会稍微变大我当时的业务要求是日均5万条工单不要求实时响应可以异步处理所以主用批量推理模式。在GPU上每次塞32条样本进batch整体吞吐直接拉满。但对那些要实时交互的AI应用比如在线客服机器人延迟就是生命线。这时候你需要的就不是batch了而是蒸馏或换小模型BERT-large换BERT-base再不行换ALBERT或DistilBERT这是最直接的降延迟方式量化FP16混合精度推理显存和延迟都能降模型裁剪去掉冗余层或head精度损失控制在可接受范围在选型时要同时使用以上策略不要一上来就上最重的模型。我见过太多团队辛辛苦苦训一个大模型然后花三倍的时间去压缩它。不如一开始就定好约束响应时间小于200msGPU显存小于8GB在这个约束里去选模型。4.3 模型服务的健康检查不是“进程活着”就行上线后还要考虑可靠性的问题。很多人写健康检查就是curl /health返回200就认为一切正常。但模型服务比普通Web服务的健康检查要复杂得多状态正常不等于结果正常进程活着、显存没爆但可能模型权重加载失败退回到了随机初始化的状态特征漂移需要监控线上输入文本的平均长度、未知词比例、类别预测分布这些都要周期性跟踪我最终设计了一套双层的健康检查方案层级检查内容频率告警方式基础存活GPU进程、显存占用、接口连通性30s一次电话告警业务质量抽样预测分布漂移、置信度阈值、平均延迟5分钟一次工作群通知这套机制上线后的第二周就发挥了一次关键作用某天数据的平均文本长度突然翻倍是从一个没接入的新业务线来的模型置信度整体下降明显。如果没有这种业务质量监控这个问题可能要过一个月才会有人反馈“最近效果变差了”到时候回溯原因会非常痛苦。5. 从脚本到服务模型部署架构的演进路线模型本身搞定了接下来是最容易被忽视的部署架构。很多人觉得部署就是写个Flask/FastAPI包一层然后扔到服务器上。其实这个阶段有非常清晰的演进路线每一步都有它的逻辑。5.1 第一阶段单体推理服务POC验证用第一版我直接写了一个FastAPI应用内部预加载模型对外暴露/predict接口。代码核心思路如下from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import BertTokenizer, BertForSequenceClassification app FastAPI() tokenizer BertTokenizer.from_pretrained(../models/ticket_bert) model BertForSequenceClassification.from_pretrained(../models/ticket_bert) model.eval() class InputText(BaseModel): text: str app.post(/predict) async def predict(data: InputText): inputs tokenizer(data.text, return_tensorspt, truncationTrue, paddingTrue, max_length128) with torch.no_grad(): outputs model(**inputs) pred torch.argmax(outputs.logits, dim-1).item() return {prediction: pred}这一版的使命是“能用”不做并发优化不做模型热加载甚至不考虑多worker。但它的价值在于把模型从notebook里搬到了一个标准接口后面。5.2 第二阶段引入消息队列与异步处理扛住流量单体接口直接扛不住高并发因为GPU推理本身是阻塞操作FastAPI的线程池很快会被占满。我后来的改造思路是把推理任务异步化客户端请求进来先写入Redis队列LPUSH独立的worker进程从队列取任务BRPOP批量组合成batch推理完成后把结果写回Redis或直接回调业务系统接口这个架构的优势是把“推高吞吐”这个目标从“改模型”变成“改队列策略”模型服务自身不再需要处理高并发连接只需要专心吃batch。对稳定性也有好处业务高峰期哪怕请求暴增排队也可以起到削峰填谷的作用不会把GPU服务打挂。5.3 第三阶段做模型版本管理与灰度发布模型是会迭代的训练一个新模型不难难的是让它上线而不影响线上效果。这个阶段我用了一个很土但很实用的方案文件系统上维护模型目录目录名带版本号ticket_bert_v2_20250301配置中心记录当前线上使用的版本号发布新模型时先在测试环境跑回放测试用历史线上真实请求预测对比与老模型的差异差异可控后在线上用10%流量灰度跑几天监控业务指标再全量切换这套方法不需要任何复杂的框架但它解决了一个大问题在“能跑”和“能发布”之间建立了标准动作。团队里任何人拿到新模型都知道要走完整的发布路径不会有人直接把权重文件拖到服务器覆盖。5.4 什么时候你需要引入推理引擎TensorRT / ONNX Runtime / vLLM深度学习的部署还有一层优化空间就是推理引擎的选择。如果你只想快速交付直接用PyTorch的TorchScript或ONNX导出就行如果你做的是大模型场景LLM直接用vLLM做高吞吐推理是最省力的路径。我当时用一个文本分类模型做了简单对比推理方式单条延迟ms吞吐条/秒显存占用备注PyTorch直接推理120304GB最简单ONNX Runtime70553.2GB需要导出与验证TensorRT FP16351102.1GB优化最强工程复杂度高vLLM不适用不适用不适用主要面向生成式模型我最终的策略是先用ONNX Runtime因为它能在不重写代码的前提下拿到最直接的性能收益风险和复杂度都最低。TensorRT这种级别的优化留给业务体量真正需要的时候再去碰。6. 数据回流与持续迭代模型上线不是终点是起点模型上线服务后项目看起来完成了。但我一直觉得AI项目的真正分水岭在于你能否形成数据回流和持续迭代的闭环。很多团队在模型上线的那一刻就解散了然后三个月后模型效果变差没人知道为什么也没人愿意接这个烂摊子。6.1 反馈回路预测结果 加 用户行为 等于 新训练集我做的客服工单分类项目是这样闭环的模型每天处理约5000条新工单系统保留每一条工单的预测结果和置信度分数置信度低于0.7的样本打上“待人工确认”标记运营人员会修正修正结果自动进入“标注池”每周汇总一次每周五把新标注数据合并进训练集增量训练新模型新模型走灰度发布流程验证F1提升则上线没有提升就回滚这个回路的精髓在于数据在流动模型在成长。它不是“训一次用了半年”而是每两周就有一次小版本迭代。对于业务方来说模型的进化速度能跟上业务变化。6.2 模型监控不只是看API错误率作为AI工程的收尾还要说监控。普通后端监控看的是QPS、错误率、响应时间。AI服务还要额外看四样东西预测分布漂移线上各类别预测的比例是否与训练集分布接近如果突然某类占比猛增大概率是业务环境变了置信度均值变化整体置信度持续下降说明模型面对的数据开始偏离训练分布未知Token比例文本预处理后未知Token比例上升说明遇到了新词或新的语言习惯人工修正率有多少样本被业务人员修正了标签这是模型质量最真实的反馈这些指标不需要搞得很花哨用Prometheus Grafana就能做出一套很好的监控面板。重要的是指标设计思路——监控模型输出的变化趋势而不是只监控系统是否活着。6.3 失败预案模型崩了怎么办最后说一个很多人没想过的问题。模型服务挂了怎么办常规方案是降级——模型挂了就返回规则兜底比如默认固定分类、或者直接转人工。但这里有个容易被忽略的产品决策在你的接口契约里必须明确规定“不可用时的响应信号”也就是让调用方区分“模型正常预测结果”和“模型崩了在降级”。否则你的业务方会把降级结果当成正常结果问题被掩盖等到发现时已经不知道积累了多少错误数据。我在接口里增加了model_status字段正常预测返回ok兜底时返回fallback。这样数据链路下游就能自动过滤掉兜底样本不会污染后续的数据回流。7. 回看整个From Scratch之路真正难的不是模型现在回头看从空项目起步到把AI能力稳定交付到业务线真正难的环节依次是环境的确定性、训练-服务一致性、数据闭环的设计、发布流程的规范。每一个都比“把模型准确率从90%提到92%”更折磨人也更重要。如果你想按这条路线走我的建议是把项目拆成四个里程碑环境锁死的“能跑”、POC跑通的“能动”、服务上线的“能用”、数据闭环的“能进化”。每个里程碑都对应一套验收标准不要指望一步到位。最后分享一个个人感受很多人在“from scratch”这条路上花太多时间研究最新模型和冷门trick却忽略了这些基础的工程能力。实际上能把一个简单分类模型稳定可靠地跑上一年比在竞赛里拿一次高分更接近AI工程的真谛。你需要的不是更多技巧而是对每个环节确定性的敬畏和掌控。