1. 先把“从零开始”这个说法掰开揉碎1.1 “AI工程”这个词这两年变模糊了最近在社区里聊到“ai-engineering”发现一个很有意思的现象一百个人嘴里有一百种理解。有人说AI工程就是用大模型写Prompt有人说是在云上部署模型推理服务还有人觉得是搭一套Fine-tuning流水线。这些说法都对但都只是切面。我在实际带项目时最大的感受是——AI工程的本质根本不是某个模型或某个框架而是把AI项目从“实验室能跑”变成“业务上能持续跑、出了问题能查、换了数据能更新”的一整套工程体系。这也是我为什么特别喜欢“from scratch”这个限定词。它不是说你的代码要从零写而是说当你想用一个AI能力去解决业务问题时你脑子里的那张建设蓝图是不是真的能从零画出来。市面上工具太多了框架更新太快了今天学的API明天就变。但工程系统本身是有稳定结构的。把结构想清楚工具只是填空题。我自己在2020年前后开始从传统软件工程转向AI方向当时最大的错觉就是“模型是核心”。实际上把项目拆开算账会发现模型训练只占很小一块成本数据准备、验证评估、服务化、监控追踪这些环节哪一块做得糙项目就卡在哪一块。今年我复盘了手头几个真实落地的AI项目把“从零开始”的经验和踩坑教训整理成这篇长文分享给正准备或正在搭AI工程体系的团队。适合以下三种人阅读刚入门想建立全局认知的开发者、在业务里负责AI落地的技术负责人、以及想从算法岗位往工程方向横跳的同学。1.2 从零开始到底从哪开始如果非要给“从零开始”定一个起点我的答案是从业务问题定义开始而不是从技术选型开始。大部分项目翻车翻在连“这个模型到底要解决什么、服务谁、什么时候用、多久更新一次”都没想清楚就开始比较PyTorch和TensorFlow、比较GPU型号。这相当于你要盖楼先在某宝上选瓷砖样式。我现在的习惯是先写一页纸的“项目意图说明”包含四块内容业务场景的现状、AI介入后的期望变化、失败的可接受标准、上线后谁来维护。这四块写完技术方案基本可以倒推出来。从零开始还有一个容易被忽略的维度——团队能力基线。如果你的团队没有人写过生产级的服务代码没有人做过监控告警那你的第一个AI项目哪怕模型精度再高也大概率死在线上事故里。所以从零开始不是从模型开始从数据开始而是从“团队欠缺哪些工程能力”开始。补能力永远先于补模型。2. 一张总图系统工程视角下AI项目需要的所有件2.1 一张图把AI项目拆成六个模块我倾向于把AI工程体系拆成六个模块需求定义、数据工程、模型开发、评估验证、服务交付、观测运维。任何一个AI项目都可以在这六个模块里找到自己的坐标。很多初学者的误区是把精力全砸在第三个模块上结果发现数据没人管、评估靠人工看几条样例、线上出问题无法回滚。我拿一个实际做过的项目来拆解给一个电商平台做商品描述的自动质检判断描述里是否包含违规词、虚假宣传、夸大承诺。放在这个框架里就是需求定义质检什么商品、什么内容算违规、实时拦截还是事后抽检、允许的误判率阈值是多少数据工程抓取历史描述样本、标注合规与违规两个类别、处理类别严重不均衡的问题模型开发文本分类模型的选型一开始直接用了通用预训练模型加分类头评估验证建立基于类别的精确率/召回率矩阵尤其是违规类别必须控制漏判服务交付提供HTTP接口供审核系统调用支持批量跑历史数据观测运维监控接口延迟、预测置信度分布设置置信度低于阈值的转人工队列。这六个模块缺一不可。**从工程实践看前两个模块和后两个模块的耗时通常占整个项目周期的七成以上。**模型开发反而是最快的一块。这个比例很多人不信真去执行一遍就明白了。2.2 数据、训练、推理、评估四个轮子别让它单轮跑如果把AI项目比作一辆车四个轮子就是数据、训练、推理、评估底盘是基础设施算力、存储、CI/CD方向盘是需求定义。很多团队的车是三轮或独轮的——比如数据团队疯狂标注但训练流程还没搭建或者模型训练环境特别好但推理部署迟迟没接上再或者从头到尾没人认真做评估上线全靠拍脑袋。这四个轮子的依赖关系不是单向的而是循环的数据决定模型上限评估反馈指导数据迭代训练产生的新模型通过推理服务面对真实流量观测数据又回补到训练数据里。所以AI工程真正的核心能力是“让这个环转起来”而不是某一环多强。举个具体的例子。我们做质检模型时第一版模型的违规召回率只有65%不高但已经很够用了违规样本本身在全部商品里占比极少按这个召回率跑一天能抓出几百条漏网内容。关键是抓出来的内容怎么回流标注团队标注完的新样本再进训练集两星期后召回率升到78%。这个回流机制就是工程体系的功劳比单纯调参数有意义得多。3. 数据工程没数据一切白搭3.1 数据获取与初筛源头对了后面少走一个月弯路数据工程做得好不好直接影响后面所有环节的上限。这也是最容易“按头做”却做不壮的地方。先说获取。大多数情况下不是没有数据而是数据散落在各种业务系统里用户行为日志在Kafka里业务表在MySQL里历史报表在数仓里客服对话在工单系统里。把数据归拢到统一的数据湖或数据集目录是第一件事。这里要特别提醒千万不要闷头写代码去拉数据先盘一盘现有系统里有哪些表、哪些日志、哪些离线文件可能跟业务场景相关。跟业务方做三次访谈把表结构和字段含义弄清楚比写一万行ETL有用。再说初筛。真正生产环境的数据脏的程度远超想象字段缺失、格式错乱、标点符号全角半角混用、同一件事有八种表述。初筛的目标不是把数据洗得干干净净而是把“明显不可用”的样本剔除掉并统计出问题分布为后续清洗策略提供依据。这一步通常用简单的规则脚本就能完成不需要上模型。我见到最多的问题发生在“标注口径不一致”上。两个标注员对同一条描述一个判“违规”一个判“合规”。如果不做标注一致性校验你的训练集就是一个意见分裂的训练集模型怎么学都学不好。所以数据初筛阶段就要同步设计标注规则文档一条规则配一个正例一个反例规则之间不重叠、无矛盾。这个文档的工程质量比模型结构设计更重要。3.2 清洗与标注质量红线不能省清洗的核心逻辑是“从业务规则到数据规则”的翻译。比如质检场景里“夸大承诺”在业务上怎么定义可能是绝对化用语“最好”“第一”“顶级”可能是不合质量法的描述。把这些业务定义转成可执行的数据过滤规则才算清洗完成。清洗值得投入自动化写一批基于正则和字典的初洗脚本把明显噪音数据比如纯URL、纯乱码、少于5个字去掉再设计半自动流程让清洗脚本识别出“高置信正常样本”和“低置信待人工确认样本”后者送人工复核。原则是机器能干的不用人人只处理机器拿不准的。标注阶段我个人强烈建议做三件事双人标注加仲裁每个样本至少两个人标不一致的由第三人仲裁。质检类这种高风险场景尤其需要。动态抽检标完的批次按5%-10%抽检抽检出问题的整批打回重标。标注日志留痕谁标的、什么时间标的、依据哪条规则全部记录。没有这个日志后续发现标注错误想追溯根本无从下手。这三件事做起来不便宜但和“模型上线后错误判断带来的业务损失”相比便宜太多了。3.3 数据版本管理与一致性你训练模型用的数据必须可回溯做软件工程的人都理解代码要版本管理但数据同样需要版本管理这个意识在AI团队里还很薄弱。训练数据改了哪个文件、新增了哪些样本、旧版本是什么样如果完全没有记录那么模型效果波动时你根本说不清是模型的问题还是数据变了。我的做法是为每个训练数据集建立一个数据版本包含三个要素一个语义化版本号v1.2.0、一份数据清单包含数据来源、清洗规则版本、标注规则版本、一条不可变存储记录。每次数据更新都按新版本发布旧版本不删除。这样配合训练实验记录任何模型效果变化都能溯源到“数据变了、参数变了、代码变了”三类原因中的哪一类。实现上不需要很重的工具。用DVCData Version Control或者简单的“数据集目录加hash校验文件”都可以。关键不在于工具在于习惯。有一次我们某个模型效果突然提升追查原因发现是训练集里多了一条重复数据的副本相当于模型把同一条数据多学了一遍。如果没有数据版本记录这种幽灵式提升会直接误导后面的决策。4. 训练体系的工程化改造从调参到实验体系4.1 实验追踪没有记录谈何重复训练一个模型不是跑一次就完了而是要跑几十上百次实验调学习率、换网络层、改数据处理方式。如果不做实验追踪你脑海里记的是“这次好像比上次好一点”但等到想复现这个“好一点”时发现既不知道用了哪份数据也不知道训练了多长时间日志早被覆盖了。实验追踪就是给每次训练拍一张身份证配置信息、代码版本、数据版本、评估结果、模型产物地址。把这些信息集中到一个地方之后对比实验、分析基线、回溯问题才变成可能。产品形态上有MLflow、Weights Biases、Neptune等工具但从零开始的团队没必要一上来就上重型系统。最简单有效的起步方案是每次训练自动导出一份YAML格式的配置文件和一份评估结果JSON文件名带上时间戳统一存到一个目录里。这个习惯坚持一个月你就会尝到甜头某个实验效果意外地好可以完整复现某个实验效果暴跌也能快速定位变量。实验追踪的本质是“反记忆依赖”。人类的记忆适合用来猜方向不适合用来记技术细节。4.2 基线模型与评估集一开始就别给自己挖坑很多人拿到数据就直接上当前最牛的模型训了好久效果一般回头才发现连一个简单粗暴的基线都没做。**基线模型是评估体系的绝对前提。**它不一定是最优解但它是“你说模型效果好到底比什么好”的参照系。对文本分类任务我的基线选择顺序是首先是基于规则的关键词匹配模型然后是简单的TF-IDF加逻辑回归最后才是预训练模型微调。这么排的目的很明确先用最便宜的方法跑出一个效果下限再逐步投入更重的方案看投入产出比是否划算。评估集的设计也大有讲究。最忌諱的是随机抽样当评估集那样评估结果只能证明“模型在整体上大致OK”无法回答“模型在场景A、时段B、人群C上到底行不行”。正确做法是按业务维度切片评估按商品类目切片、按文本长度切片、按违规类型切片。每个切片单独计算精确率和召回率任何一项不过线都不能放行。有一个真实教训我们第一版质检模型全量准确率不错但把评估结果按“新商品”切片一看召回率低得吓人。原因是训练数据里历史商品占了九成以上模型对新表述几乎没有见过。这个评估就是靠切片暴露的如果只看平均指标上线后第一批新商品就会漏过去。4.3 训练稳定性和可重复性GPU一挂别让几天的活白干训练稳定性是工程化改造的重点。很多人第一次跑大规模训练不敢中断训练因为一旦中断就得从头再来。解决方案有两个层面一是周期性保存checkpoint二是训练任务的自动化重跑机制。周期保存checkpoint应该按时间和步数双重维度做。比如每500步保存一次同时每30分钟至少确保有一个最新checkpoint落盘。这样即使训练进程崩溃也可以从最近的checkpoint恢复丢失的只是最近几步的进度而不是几天的进度。自动化重跑听起来稀松平常但真正做得好的团队不多。我的做法是把训练封装成标准流程输入是数据版本号加配置版本号输出是模型版本号加评估报告中间所有步骤数据加载、预处理、切分、训练、评估都写成可重入的Stage。哪个Stage失败只需从那个Stage重跑而不是整个流程推倒重来。这个能力在训练数据动辄几十GB、训练时长以天计的项目里价值不用多说。还有一点——固定随机种子能让训练过程更可复现。严格来说由于硬件层面的非确定性固定种子不能保证100%一致但它能大幅缩小不确定性范围让调试变得容易。这个细节很多人忽略等到想精确对比“改了某行代码到底有没有效果”时才发现两次训练的差异噪声远大于代码改动的影响那就晚了。5. 部署与监控模型上线后才是真正考验5.1 离线和在线架构把推理服务当成一个普通后端服务来设计模型训练完只是拿到一个文件或一个权重目录。从上线的角度看它要变成一个稳定的服务。我的强烈观点是不要把推理服务想得多神秘它就是一个普通后端服务只不过函数体的核心是模型推理。在线推理场景下最基本的架构是客户端打请求进来经过网关、鉴权、参数校验进入推理服务推理服务从模型存储拉取模型到内存或显存对输入做预处理比如转Token然后跑前向计算再对输出做后处理最后返回结构化响应。这里最容易忽略的是“预处理和后处理跟训练时保持一致”。训练时文本清洗用的规则是A线上推理时却因为图省事用了规则B模型没见过这种格式的输入输出自然不可靠。训练/推理一致性是所有稳定性问题的第一源头。离线推理场景比如每天夜里跑一次批量质检没必要开常驻服务。更合理的方案是用任务调度系统提前构建好镜像按计划拉起一批推理Worker从队列消费任务处理完写回结果表然后自动释放。两种模式的核心不同点在于在线重延迟和并发离线重吞吐和成本。5.2 模型监控与漂移检测上线不等于万事大吉模型部署上线那天很多团队会放个烟花庆祝但我要说这一天其实是“观测运维”的开始。模型在真实世界会失效原因多种多样数据分布变了、用户行为变了、平台规则变了、外部环境变了。做好监控才能在失效造成大损失之前发现它。三个监控维度必须覆盖性能指标接口延迟、每秒请求数、错误率、超时率。这些和普通后端监控完全一样。预测指标预测置信度分布、预测类别的比例分布。分布发生显著偏移通常意味着输入数据变了。业务效果指标比如质检模型的直接业务效果是“人工复核通过率”或“漏检率”。这个可能需要离线计算但要建立周期任务。漂移检测可以做简单版每天把当天的输入数据特征分布和训练集特征分布做一次对比算PSIPopulation Stability Index或KL散度超过阈值就告警。这个方案不用GPU用CPU跑足够。数据漂移不是“可能发生”的黑天鹅而是“必然发生”的灰犀牛建模时必须默认它会发生。5.3 A/B测试与模型更新改版本要像发版一样走流程模型更新比代码发布更敏感。为什么代码更新的影响通常是确定性的模型更新则有可能让一部分场景变好、另一部分场景变差而这种分布变化在A/B测试跑完之前是不透明的。我的建议是模型更新必须遵守灰度发布流程先在影子模式跑一段新的模型和线上模型同时接流量但新模型的输出不入库只记录差异看影子日志统计新模型和现网模型的预测分歧率人工抽样判读新版是不是更好切10%流量试运行盯预测指标和业务指标确认稳定后逐步放大到全量全量后再保持一定时间的双跑观察期便于快速回滚。回滚机制也要提前准备。最稳妥的方案是保留前一个版本的模型服务需要回滚时只需切换流量入口不要临时去重新加载旧模型。哪怕只是多花几十秒的加载时间在线上故障场景里都嫌慢。6. 两年踩坑浓缩成的检查清单6.1 隐形的时间和金钱杀手经验和教训这种东西写出来只有几行字但每一条背后可能都是一整周的无眠夜。我从过去两年真实项目里挑出几个“最容易被人忽略但又杀伤力极大”的坑走之前先看一眼绝对省大钱。第一个坑数据标注口径不做一致性校验。标注员的理解因人而异不建立“双标仲裁”机制你的模型会在互相矛盾的标签里反复横跳。一个质检项目因为漏了这一步模型的违规召回率卡在60%上不去了三个星期。后来花两天做了一致性校验发现15%的标注样本是矛盾的清洗重标后召回率直接跳到72%。成本差异非常悬殊。第二个坑训练环境不固定靠运气出结果。今天在A环境上训练过几天换到B环境跑参数完全一样效果就是不一样。排查了两天才发现是CUDA版本和依赖库差异导致的数值精度变化。后来我把训练环境封进镜像基础镜像版本锁定版本信息全程可查这个坑才算填掉。第三个坑在线推理和离线训练的数据处理逻辑不一致。这个前文提过但值得反复强调。模型在线上“表现不佳”很多时候并不是模型不行而是线上输入没经过训练时做过的清洗和变换。把训练和推理的数据处理代码抽成同一个库这个习惯能从源头上消除一整类问题。第四个坑不做成本监控。GPU资源越开越多月底账单出来才知道预算超了几倍。后来我们给训练任务加了“预计消耗实际消耗”的成本标注任务提交前必须填预估GPU时跑完自动对比实际值。对资源消耗建立预算意识比事后控制有效得多。6.2 值得提前投入的工程能力如果让我现在回去重新搭一套AI工程体系我会把下面的工程能力放在最优先的位置而不是急着调模型可重复性代码、数据、配置、环境四类要素全部版本化任何一次实验结果都能被完整复现。自动化测试给数据清洗和评估逻辑写单元测试和集成测试。很多人不给这类逻辑写测试但这类逻辑恰恰是整个链条上最容易悄悄出错的地方。监控告警把模型指标当业务指标看建立多维度的监控看板告警规则宁可多几条也别少。渐进式发布影子环境、灰度、一键回滚。这套机制建设的初期成本不高但对长期运维的收益巨大。这些能力总结起来就是一句话**让AI项目从“一堆代码加一个模型”变成一个“有纪律、可经营、能迭代”的工程体。**如果只能记住这篇文章里的一段话我希望是这一段模型只是AI工程体系里一个被训练出来的产物真正决定项目成败的是围绕数据、实验、交付、运维这四条线建立起来的工程秩序。从零开始不是从算法开始而是从秩序开始。