如果你点进这篇文章多半和我当年一样对“AI工程”这个词充满好奇手头会一点Python看过几个热门开源项目的demo但真要独立负责一个从数据到上线全流程的AI项目时心里完全没底。我过去两年一直在做AI工程方向的落地从零开始把模型训练、部署、评估、迭代这套链路完整走了一遍又一遍。中间踩过的坑比写过的代码还多调通一个开源项目就以为懂了结果一上线线上效果立刻翻车模型在测试集上F1好看得不得了换成真实生产数据之后连及格线都碰不到。这篇文章就是那两年经验的浓缩版。它不会教你背某个框架的API而是告诉你从零建立“能交付、可维护、可迭代”的AI工程能力到底要跨过哪些坎、按什么顺序跨以及每一个阶段我在实践里认为最值得投入时间和最该避开的坑。适合谁看三类人一是刚入门AI、想往工程方向走的初学者你缺的不是课程而是一张完整的地图二是已经能跑通demo、但项目一上线就各种幺蛾子的半成品工程师三是团队里需要从0到1搭AI基础设施、被老板追着问“到底要多久能上线”的技术负责人。全文不会只讲思路会有具体的工具选型、代码片段、指标口径和复盘逻辑你可以直接照着排自己的路线。1. 别把“AI工程”当调库先搞清楚这套能力到底在解决什么很多人对AI工程有个误解觉得“会用模型就是AI工程”。会调库和会做工程中间隔着一条巨大的河。我见过不少同学跑通了BERT finetune代码兴奋地跟我说项目快完成了结果我问了几个问题训练数据是怎么来的跑一次实验要多久换一批数据结果还能复现吗上线之后准确率掉了怎么发现他一个都答不上来。这就是典型的研究式demo和工程式交付的区别。1.1 算法工程师、数据科学家、AI工程师三张名片的分工真相先给这三类角色画个界线因为很多人连自己要成为谁都没想清楚学了一堆东西却用不上。角色核心产出主要工作范围典型交付物算法工程师模型效果模型结构设计、训练调参、论文复现实验报告、模型权重、指标对比数据科学家业务洞察与决策数据探索、统计分析、AB实验解读分析报告、特征方案、业务建议AI工程师稳定运行的AI系统数据管线、训练流程、部署监控、迭代机制可上线服务、监控看板、自动化管线AI工程师的关键词是“稳定”和“成本”。算法工程师可以把模型精度从80%调到82%AI工程师要做的是让这个82%的模型在线上稳定跑三个月、每天处理几百万请求、关键时刻还能快速回滚。两者有重叠但视角完全不同。从零开始的你如果目标是“独立交付一个AI项目”那你需要的主要是AI工程师这套能力算法深度可以后面慢慢补。1.2 一个能跑的demo和一个能上线的系统差在哪里我习惯用一个特别简单的例子来解释这个区别房价预测。Demo版本的逻辑是拿一份csv用sklearn训练一个线性回归跑出来R²等于0.85打印个预测结果完事。看起来挺成功。生产版本面对的问题是这样一堆这份csv是谁给的数据更新的频率是多久如果下周来一批新房源数据特征缺失值从5%涨到30%管线还能跑吗模型文件放在哪个服务器上推理接口延迟能不能控制在100毫秒以内客户反馈预测明显偏离时我们怎么定位是数据源的问题、特征处理的问题、还是模型本身该重训了两类工作用的模型可能一模一样但差的恰恰是数据、配置、监控、版本、回滚这些“不性感”的东西。软件工程里那些被反复强调的习惯——版本控制、单元测试、日志监控、灰度发布——AI项目一个都不能少还得额外多处理一层“模型会变老”的问题。1.3 从零必须建立的三种工程思维我总结下来真正让一个人从“会调库”走向“能做工程”的不是某个具体框架而是三种底层思维第一可重现优先。任何一次实验结果半年后应该有办法完整还原代码版本、数据版本、超参数、随机种子、环境依赖五样缺一不可。做不到可重现的实验做得再多也只是一堆没有积累的碎片。第二评估先行。AI项目最大的陷阱是“感觉模型还行”。必须在上手之前就想清楚业务上到底用什么指标衡量成功是降低人工处理成本还是提升响应准确率然后把它翻译成可计算的离线指标和可观测的线上指标。我见过太多项目是模型训完了才开始想怎么评估结果发现数据采样本身就有问题白白返工。第三简化优先。从零开始的时候永远先选最简单的方案跑通全链路再逐步加复杂度。很多人一上来就上分布式训练、K8s集群、特征平台结果项目一个月过去了还在搭环境。我的做法是先用sklearn或单卡小模型把端到端链路跑通把数据、评估、部署的骨架立起来再往里面填更强大的模型。2. 地基阶段数学、Python与工程工具链学到什么程度就算合格“从零开始”最大的焦虑是不知道地基要挖多深。我见过有人花了三个月啃《统计学习方法》才肯动手写第一行训练代码也见过完全不懂数学、抄了个transformer就跑。两个极端都不对。AI工程需要的数学是“够用就好随用随补”不是让你去当数学家。2.1 数学以“够用”为边界别掉进推导黑洞我把AI工程真正用得到的数学列成了一张最小集每块对应到工程中的实际用途你按这个表学就行学多了短期也用不上。数学模块必须掌握的点工程中的用途建议投入线性代数向量、矩阵乘法、范数、特征值的基本直觉理解Embedding、降维、Transformer里的矩阵运算1-2周概率与统计条件概率、贝叶斯、常见分布、期望与方差理解模型输出概率、采样逻辑、AB实验2周微积分导数、偏导数、链式法则、梯度方向理解反向传播、学习率为什么不能太大1周统计思维偏差-方差、过拟合、显著性检验的直觉判断模型是不是真的有效而不是偶然1周关键点是不需要会推导矩阵分解的完整证明但必须知道矩阵乘法是在做特征空间的变换不需要会证明中心极限定理但必须知道样本量太小的时候评估结果不可信。学习这些内容的时候我强烈建议边学边用numpy和sklearn去验证比如用几行代码算出矩阵相乘、亲手调一次learning rate看loss曲线的变化这比抱着课本刷题高效十倍。2.2 Python之外的工程工具五件套比语言本身更重要所有教程都在教Python语法但真正让工程跑起来的是Python之外的一套工具链。我建议从零开始就养成习惯而不是等项目复杂了再补Git不只是把代码存起来。要养成每个实验一个分支、每次提交附带实验说明的习惯这样出了问题能精确回退到某个版本。Conda或uv管理Python环境。早期图省事全装在一个环境里半年后依赖冲突能把人逼疯。我后来每个项目单独建环境成本很低收益极高。Docker把模型服务打包成镜像保证开发、测试、生产环境一致。“在我机器上是好的”这句话在AI项目里会经常出现Docker是唯一的解药。GPU环境基础操作nvidia-smi看显存占用、nvtop看实时利用率。不熟练这些后面做训练连进程被OOM杀掉都发现不了。Linux命令行日志查看、进程管理、端口排查这些基本功遇到线上问题的时候每一条都能救命。看到这里你可能会觉得“工程”很枯燥但事实就是这些枯燥的东西决定了项目能不能活到上线那天。我把它们比喻成开车时的后视镜平时不怎么看变道和倒车的时候没有它必出事故。2.3 从零到能独立交付项目的时间盒路线总有人问我到底要学多久才能开始做AI工程我给一个基于我带人经验的参考节奏前提是你已经具备基础Python能力时间周期学习内容阶段产出第1-2周快速补齐numpy、pandas学会用jupyter做数据探索能用pandas做清洗、分组、透视第3-4周sklearn标准流程数据划分、训练、评估跑通线性回归、逻辑回归、随机森林第5-6周PyTorch基础张量、自动求导、简单神经网络手写一个两层网络的训练循环第7-8周做第一个小项目文本分类或图像分类拥有一个评估指标可解释的模型第9-10周用FastAPI包模型、写Dockerfile、本地部署有一个能通过HTTP调用的预测接口第11-14周端到端迭代换更好的模型、做误差分析、加监控完成一个从数据到上线的完整项目这个路线最大的特点是不追求单个阶段的完美而是尽快把全链路走通。我见过很多人卡在“把PyTorch学完”这一步半年了还在看教程。一定要记住AI工程的能力是项目喂出来的不是课程喂出来的。学完第4周的内容就可以接真实项目了后面边做边补。当时我带过一个实习生完全按这个节奏走第10周就独立交付了一个工单分类的小服务效果虽然算不上惊艳但流程是完整规范的。3. 数据管线模型效果的真正上限藏在你看不见的清洗环节里我在团队里带项目的时候最常对新人说的一句话是模型结构决定的是效果的地板数据质量决定的是效果的天花板。这句话业界都听过但真正信的人不多。直到某次我用一份看起来“挺干净”的数据训练意图识别模型跑了两个月发现线上效果一天比一天差最后排查出来的原因是数据采集阶段的去重逻辑把用户最新意图的样本误当成重复数据删掉了。从那以后我把数据管线当成整个项目最优先建设的部分。3.1 数据工作在AI项目里的真实占比如果你去看一些行业报告会发现一个被反复引用的说法AI项目里数据准备要占掉80%的时间。我第一次看到这个数字觉得夸张真做起来才知道不但不夸张甚至可能低估了。原因不在于数据工作本身有多难而在于它极其琐碎字段口径要对齐、缺失值要决定策略、异常值要判断是噪声还是真实业务、标签要人工确认、样本分布要定期检查……任何一环出问题训练出来的模型都会在某个看不见的地方悄悄出错。而且数据问题有个特别恶心的特性它不会让程序报错。代码写错了会崩溃模型因为数据问题变差训练过程照样正常收敛、loss照样下降如果评估集也被同样的问题污染你甚至完全察觉不到。这是数据和代码最大的区别。3.2 采集与清洗四类最隐蔽的数据事故我在实际项目里吃过亏的数据问题总结起来有四类新手几乎都会踩第一重复与近似重复。精确去重比较简单按主键或全文哈希就可以。难的是近似重复同一件事用户换了个说法两条样本文本80%相似但标签都是正样本直接去重会误删有效信息。我的做法是对文本类数据用MinHash或SimHash做相似度预估设定一个较高的相似度阈值只处理那些几乎完全重复的样本其余保留并人工抽检。第二标签噪声。标注员的理解不一致、标注规范模糊、甚至标注工具本身有bug都会产生错误标签。模型对标签噪声有天然的鲁棒性但超过一定比例性能会明显下降。后面会讲怎么通过抽检来管理这个问题。第三特征泄漏。这是最坑的一类。特征里包含了未来信息或者目标本身的影子训练时指标漂亮得吓人上线后立刻现原形。我见过一个典型案例做用户流失预测特征里包含了“本月是否已经续费”这个字段而续费恰好就是流失的标签来源模型直接把标签抄过去了。排查方法很简单对高重要性的特征逐个问一遍“线上预测那一刻这个值我能提前拿到吗”拿不到就是泄漏。第四类别不平衡。正负样本比例到1100甚至更低时准确率这个指标会骗人模型可能全部预测负样本也能有99%的准确率。处理方式包括重采样、加权损失、改用PR曲线或AUC评估但最根本的还是要想办法多收集正样本不要只在数据层面硬掰。3.3 数据版本化让每个实验都能被重新打开代码有Git管着数据却经常被当作文档一样随手覆盖。这种情况我在不少团队都见过新数据到了旧的csv直接替换等模型效果变差想对比时原始数据已经找不回来了。数据版本化这件事从零开始就要做。轻量方案不需要引入太重的基础设施每次数据变更时记录数据的哈希值、生成时间、来源说明。等你需要更系统地管理时再上DVC这类数据版本管理工具。但一开始至少要做到“每个实验能对应到一份不可变的数据快照”。我自己的习惯是目录按版本命名比如data/v20250601_raw.csv然后在训练配置里记录这个数据文件路径和哈希值保证半年后还能复现同一个实验。3.4 标注质量怎么管不能只靠“标得认真一点”如果项目需要人工标注质量管控必须流程化。我的经验是三件事第一标注规范先于标注执行。写一份详细的标注指南里面要有明确的边界案例处理方式比如情感分类中“中性偏正面”算哪个类别每个可能出现歧义的地方都要有例子。第二抽检不能只看正确率。除了抽一部分样本让资深人员重新标注之外我更推荐计算标注一致性。两个标注员标同一批样本计算Cohen‘s Kappa系数一般要求达到0.7以上才认为标准可靠。如果只有0.4说明标准本身有问题返工不是标得不够认真而是规则根本说不清。第三标注数据要留痕。谁标的、什么时间、哪个批次、最终审核结论这些信息全部要记录。模型出错时可以回溯到标注环节定位到底是标注问题还是模型问题而不是两边互相甩锅。4. 训练与微调把“能跑的notebook”升级成“可复现的实验流程”训练是大多数人最兴奋的环节也是我之前翻车最严重的环节。从零开始的话我的核心建议是不要碰复杂模型先把训练流程本身搞规范。一个规范的训练流程比一个花哨的模型结构值钱得多。4.1 先跑一个简单基线再上复杂模型拿到任何任务第一步永远是跑一个最简单的基线而不是直接上预训练模型。我常用逻辑回归或者带TF-IDF特征的线性模型作为文本任务的基线几行代码就能完成from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.pipeline import Pipeline pipe Pipeline([ (tfidf, TfidfVectorizer(max_features20000, ngram_range(1, 2))), (clf, LogisticRegression(max_iter1000)), ]) pipe.fit(X_train, y_train)这个基线有两个作用。第一给你一个效果的地板后续复杂模型如果没有明显超过它就要反思是不是数据或评估出了问题。第二帮你验证数据管线是通畅的如果连逻辑回归都能跑出合理的结果说明数据本身没有硬伤这时再上复杂模型出了问题也更容易定位。我见过太多团队一上来就finetune大模型训练了三天发现效果不如TF-IDF逻辑回归然后开始怀疑人生。其实不是模型不行而是根本没在地基上验证过。4.2 训练循环里必须盯住的五个信号训练过程中不能只看最终指标过程中这些信号要实时关注训练损失有没有稳步下降。震荡剧烈通常意味着学习率过大或batch size太小。验证损失是否在某个点开始回升。这是过拟合开始的信号要在回升之前就保存模型检查点。梯度是否出现异常。梯度爆炸会让loss突然变成NaN常见缓解手段是梯度裁剪。训练损失与验证损失的差距。差距持续拉大说明模型在记忆训练数据而不是学习规律。离线评估指标和loss趋势是否一致。有时候loss下降但目标指标没变说明loss和指标之间存在错位要考虑调整训练目标。我放一个最基础的PyTorch训练循环结构注意里面的验证和检查点保存逻辑这是工程化训练最基本的要求import torch from torch.utils.data import DataLoader torch.manual_seed(42) # 固定种子确保可复现 def train_one_epoch(model, loader, optimizer, criterion, device): model.train() total_loss, total 0.0, 0 for x, y in loader: x, y x.to(device), y.to(device) optimizer.zero_grad() loss criterion(model(x), y) loss.backward() optimizer.step() total_loss loss.item() * x.size(0) total x.size(0) return total_loss / total def evaluate(model, loader, criterion, device): model.eval() total_loss, total, correct 0.0, 0, 0 with torch.no_grad(): for x, y in loader: x, y x.to(device), y.to(device) logits model(x) loss criterion(logits, y) total_loss loss.item() * x.size(0) correct (logits.argmax(1) y).sum().item() total x.size(0) return total_loss / total, correct / total工程化的关键在循环之外每轮迭代结束要在验证集上评估只有当验证指标超过历史最佳时才保存权重这样你最后拿到的永远是验证集上最好的那份模型而不是最后一轮可能已经过拟合的模型。4.3 微调预训练模型的取舍与显存控制当基线跑通、确认数据没问题之后再上预训练模型微调。但从零做工程一开始就要学会控制显存因为大部分个人开发者的显卡都不大。我的实操经验是把这几招按优先级排好手段作用使用难度用LoRA或Adapter微调大幅减少可训练参数量显存占用和训练时间都会显著下降低梯度累积用小batch size跑多个step再更新一次等价于大batch低混合精度训练用fp16/bf16减少显存占用还能加速低限制序列长度文本截断到模型可接受范围避免无效的显存消耗低全参数微调效果上限最高但显存开销大小规模数据容易过拟合高我第一次微调BERT做文本分类直接全参数微调8G显存跑一个batch就爆。后来换了LoRA只训练约1%的参数效果只掉了不到一个点但显存占用直接降了一半以上。对这个结论我现在的态度是非必要不裁员全量微调绝大多数业务任务用LoRA足够。4.4 实验追踪让每次训练都不白跑实验不带记录等于白做。这个道理我是在连续调了三周参、最后想对比不同配置的效果、发现完全不记得每组实验用了什么超参数之后才彻底明白的。现在的做法是每个实验对应一个yaml配置文件记录数据版本、模型结构、超参数、随机种子训练过程中用MLflow或Weights Biases记录loss和指标曲线训练结束后写一行实验结论。这样半年后再看每个数字都有来龙去脉。提示随机种子必须在所有随机操作之前设置包括数据打乱、模型初始化和dropout否则复现实验时结果会对不上。5. 部署与推理优化模型从研究环境走进生产环境的那道窄门模型训练只是开始真正考验工程能力的是部署环节。多少人死在最后这一步模型在notebook里预测飞快封装成服务之后延迟高得没法用源代码运行正常上了GPU服务器就各种依赖问题接口能响应了但并发一高就超时。这些我都经历过这章直接给你我现在稳定使用的方案。5.1 模型导出别把训练产物直接当交付物PyTorch训练出来的.pt文件是训练产物不是部署产物。部署要考虑推理速度和环境依赖通常需要把模型转换成专门为推理优化的格式。我常用的对比是这样的格式优点缺点适用场景原版PyTorch权重灵活、和训练环境一致依赖PyTorch环境启动慢推理优化少快速原型、离线批处理TorchScript可脱离Python运行部分动态结构支持不佳对兼容性要求高的C环境ONNX跨框架、可加速、生态好部分算子转换需要处理首选推荐默认用它TensorRT推理速度极快绑定NVIDIA GPU转换复杂延迟要求极高的生产服务我的默认选择是ONNX。训练完模型后用torch.onnx.export导出再用onnxruntime加载推理。好处是部署环境不需要装PyTorch镜像体积小还能自动利用CPU或GPU加速。大多数情况下这一层优化就能让推理时间减半。5.2 推理性能的三个抓手批量、量化、缓存上线前一定要做压测不压测就不知道服务的真实承载力。压测之后如果性能不达标按这个优先级排查第一批量推理。单个样本逐个推理非常浪费算力尤其是GPU。把多个请求攒成batch一起推理吞吐量能提升好几倍。我自己的经验是吞吐量和延迟要分开看如果你更看重吞吐量动态批处理是最划算的优化。第二模型量化。把模型从fp32压缩到int8显存占用降到四分之一推理速度通常还能再快一到三倍代价是精度可能下降1-2个点。量化之前必须在验证集上测好精度损失量化和蒸馏一样出来的模型一定要挂回评估流程里验证不能想当然。第三结果缓存。业务里大量请求其实是重复的比如相同或相似的商品描述。对这类请求加一层缓存命中率能达到几十个百分点等于白送的性能提升。TextEmbedding这类模型的向量结果尤其适合缓存特征更新不频繁的场景收益更高。5.3 用FastAPI暴露模型服务的完整姿势我现在的标准方案是FastAPI加ONNX Runtime起步快、生态好、性能也够用。下面是一个最简但完整的推理服务示例from fastapi import FastAPI from pydantic import BaseModel import onnxruntime as ort import numpy as np app FastAPI() sess ort.InferenceSession( model.onnx, providers[CUDAExecutionProvider, CPUExecutionProvider] ) class Item(BaseModel): text: str app.post(/predict) def predict(item: Item): # 这里要和你训练时的预处理保持一致 features preprocess([item.text]) proba sess.run(None, {input: features})[0] label int(np.argmax(proba, axis1)[0]) return {label: label, confidence: float(np.max(proba, axis1)[0])}几个容易忽略的细节模型加载要放在模块级别不要在每次请求时加载不然光加载模型就把请求拖垮了启动后可以先发一个预热请求把显存分配和算子优化触发掉避免第一个线上请求格外慢用uvicorn跑服务时建议设置合理的workers数量但每个worker都会额外占用一份显存多开之前先算好显存预算。5.4 上线第一天就该配好的监控模型服务的监控和普通Web服务不太一样除了常规的请求量、错误率、延迟之外还要盯这两类AI特有的信号输入分布和预测分布。我见过一个真实事故上线时模型对文本做情感分类三个月后业务方接入了一个新的内容渠道措辞风格和训练数据差异很大模型对这部分内容的置信度越来越低但服务没有任何报错延迟正常、请求量正常如果不看预测分布的漂移根本发现不了效果已经崩了。所以我的监控配置思路是记录每个请求的输入特征分布按天统计均值、方差、分位数。记录每个请求输出的标签分布和平均置信度。设定阈值当每天的预测分布和基线分布偏差超过预设值时触发告警。这样才能在用户大规模投诉之前发现问题。6. 评估与回归为什么你的模型在测试集上好看一上线就露馅评估是AI工程里最容易被轻视、也最致命的一环。很多人把评估等同于“在测试集上算一下准确率”然后就没有然后了。我花了好长时间才建立起一套“从离线到在线”的完整评估体系这里把关键内容整理出来。6.1 离线评估指标准确率是最容易骗你的那个数准确率Accuracy在类别分布均匀的时候还挺直观一旦遇到类别不平衡它就变成了一个会骗人的指标。比如一个欺诈检测任务正样本只有1%模型把所有样本都预测成“正常”准确率也有99%但业务上这个模型毫无价值。所以选指标先看业务场景业务场景更关注的指标原因欺诈检测召回率、精准率、F1漏掉一个欺诈案代价高需要看少数类的表现搜索排序NDCG、MAP关注排序位置的正确性而非单点分类文本分类各类别的F1尤其是Macro-F1类别样本不均衡时Macro-F1对少数类更敏感推荐系统点击率、转化率、覆盖率综合衡量匹配程度和多样性我建议从零开始就养成看混淆矩阵的习惯。首先确定分类阈值其次关注错在哪里最后才能对症下药。只盯着一个汇总指标很难发现模型其实只对某一类效果好、其他类一塌糊涂。6.2 线上翻车的经典原因和排查路径线下指标好看、线上崩盘原因往往不在模型本身而在“线下和线上不一致”。我排查这类问题的固定路径是这样的第一步对比训练时的预处理和线上推理时的预处理是否完全一致。这是最常见的原因比如训练时特征做了标准化线上推理忘了减均值除方差效果立刻雪崩。我建议把预处理代码抽成独立模块训练和推理共用同一个实现从机制上杜绝这种不一致。第二步检查样本分布是否发生漂移。训练数据来自上季度线上流量已经是本季度的趋势用户话术、商品描述都会随时间变化。这时候需要做数据漂移检测我会用PSIPopulation Stability Index算法它衡量两个分布的差异程度import numpy as np def psi(expected, actual, bins10, epsilon1e-6): edges np.percentile(expected, np.linspace(0, 100, bins 1)) exp_hist, _ np.histogram(expected, binsedges) act_hist, _ np.histogram(actual, binsedges) exp_ratio exp_hist / expected.size epsilon act_ratio act_hist / actual.size epsilon return np.sum((act_ratio - exp_ratio) * np.log(act_ratio / exp_ratio))经验规则是PSI小于0.1表示分布稳定0.1到0.25表示有轻微漂移需要关注大于0.25表示显著漂移模型很可能需要重训或重新校准。第三步检查标签口径是否一致。离线标注和线上真实反馈的定义如果不同评估结果就没有意义。我遇到过客服工单分类项目离线标签是“投诉”线上用户真实诉求却是“咨询进度”两者被分到同一个类模型自然怎么调都不对。6.3 灰度发布与回滚模型也要像代码一样管版本模型更新不能搞“一把梭”。我现在的做法是固定采用“冠军挑战者”模式线上正在服务的模型是冠军新训练好的模型是挑战者。挑战者先跑影子流量也就是复制线上请求给挑战者模型做预测但不返回给用户离线对比挑战者和冠军的输出差异。确认差异在可接受范围之后先切一小部分真实流量比如5%给挑战者观察线上指标再逐步放大到100%。整个流程里最关键的一条是任何时候都要保留上一个版本的模型文件和它对应的配置回滚操作必须能在5分钟内完成。模型回滚比代码回滚更复杂因为还要考虑数据版本和特征版本是否兼容所以我在部署目录里会同时存放模型文件、配置文件和对应的数据版本哈希三个绑定在一起。6.4 数据漂移监控与重训触发最后一个问题是什么时候该重训模型不能靠“感觉效果不行了”来拍脑袋。设置了PSI监控之后可以结合业务指标双条件触发重训。比如连续三天同时满足这俩条件输入数据PSI大于0.2且线上核心指标较基线下滑超过5%。光有指标下滑可能只是季节性波动光有漂移可能还没影响到效果双条件触发能减少无效重训。重训也不是简单用最新数据重新跑一遍。每次重训前要做一个决策记录重训原因、新增数据量、预期指标变化、回滚方案。没有这个记录半年后你根本说不清模型为什么每隔几个月变一次版审计和追溯都会变成灾难。7. 端到端演练用两周时间从零交付一个文本分类服务前面讲了这么多最后用一个我实际带过新人的案例把整条链路串起来。需求是给客服工单做自动分类把工单分到5个业务类别里目标是减少人工初筛成本。两个人、两周、从零开始完全不依赖任何已有AI基础设施。7.1 需求边界与评价口径先定死开工第一天我们不写代码先做两件事一是和业务方确认分类体系5个类别到底怎么定义边界案例怎么处理这一步直接决定标注规范二是定评价口径离线看Macro-F1线上看人工抽检准确率服务性能要求P95延迟小于200毫秒。这些数字写进项目文档后续所有决策都对照着来。7.2 两周交付的具体安排时间很紧所以我们按照“先通后优”的顺序安排天数任务产出第1-2天导出历史工单数据清洗去重和业务方一起标了800条样本可训练的数据集和标注规范第3-4天跑TF-IDF加逻辑回归基线拿到基线Macro-F1确认数据可用第5-7天用LoRA微调一个轻量预训练模型固定随机种子做实验记录模型效果明显超过基线第8-9天导出ONNX用FastAPI封装写Dockerfile做压测可部署的模型服务第10-12天写评估脚本做误差分析修了几个明显的bad case上线前完整评估报告第13-14天部署到测试环境配监控写项目文档可立即切流量的服务这个过程里最耗时的不是模型训练而是第1-2天的数据准备和第10-12天的误差分析。模型本身用LoRA微调只花了几小时这是大多数第一次做AI项目的人完全没想到的。7.3 复盘哪些东西被我主动砍掉了这个项目只有两周我们主动砍掉了三件事每件在更复杂的场景下需要做但现阶段做了就是拖慢交付第一没上K8s。单模型单服务的场景用Docker Compose管理一组服务就够了K8s的复杂度是我们的业务量五倍时才值得引入。第二没做自动重训管线。两周内数据分布不太可能突变人工触发重训完全够用。第三没追求SOTA模型。我们评估过更大模型带来的提升也就两个百分点的Macro-F1但推理成本翻了三倍业务上不值得。注意砍功能的前提是明确记录了“为什么现在不做”和“什么条件下要做”而不是单纯图省事。这份决策记录就是项目后续演进的地图。最后再分享一个我自己的小习惯每做完一个项目我都强制自己写一页纸的decision log记录关键决策、当时的选择、后来验证的结果。半年后回头看这份日志的价值超过了我看过的任何教程。从零搭建AI工程能力这件事本质上不是积累代码量而是积累决策经验——你做的每个选择在什么条件下成立在什么条件下崩塌这才是工程能力的真正内核。希望这份从零到一的路线图能帮你少走我走过的那些弯路。