AI工程实战：从零搭建可稳定运行的机器学习系统

1. AI工程的真正边界：它到底在解决什么问题

老实说，我第一次看到“ai-engineering-from-scratch”这个项目名的时候，第一反应是“又一个模型微调教程”。但真正把整个体系捋下来之后，我发现事情远没有那么简单——它讲的不是怎么训一个模型，而是怎么把一个AI想法变成一套能稳定运行、可维护、可迭代的工程系统。这完全是两个层级的事。

我见过太多团队死磕模型结构、调参调得昏天黑地，结果模型在测试集上表现不错，一上生产环境就崩——推理延迟高到没法用、数据分布一变效果就滑坡、模型版本和特征版本对不上、监控告警形同虚设。这些问题根本不是模型问题，是工程问题。AI工程（AI Engineering）这个词这两年越来越热，核心原因就在于：大家发现了一个残酷的事实——训练出一个模型只占整个系统工作的10%都不到，剩下的90%全是围绕着数据、部署、监控、迭代这些工程环节。

从零开始做AI工程，最难的不是某个单独的技术点，而是建立一套完整的工程思维。它要求你同时具备软件工程的严谨性、数据工程的规范性、机器学习的建模意识，还要有DevOps的运维能力。这篇文章我就从实际项目的角度，把这个“从零到一”的路径完整拆开讲一遍。如果你正好是那种“模型会调、系统不会搭”的工程师，或者想从传统后端转AI方向，这篇文章应该能帮你把整个地图补齐。

1.1 AI工程和机器学习研究的本质区别

很多人会把AI工程和机器学习研究混为一谈，这是最大的认知误区。研究的目标是探索未知，比如设计一个新的注意力机制、提出一种新的损失函数，它的交付物是一篇论文或者一个实验结论；而工程的目标是在给定约束条件下构建一个可靠的产品系统，交付物是可运行的代码、稳定的服务和持续的业务价值。

我举个具体例子：研究者训练了一个文本分类模型，准确率99%，论文发了，工作结束了。但工程师拿到这个模型，要面对的是——线上流量每小时几百万次请求，单次推理不能超过50毫秒；模型在训练数据上很准，但线上用户输入千奇百怪，错别字、表情符号、中英混排，全都得兜住；半夜模型表现突然恶化，得有告警通知你；三个月后数据分布变了，模型得能快速迭代重新上线。这些事没有哪个是研究论文会告诉你的，但每一个都能直接决定项目成败。

所以AI工程本质上是在做“约束下的系统设计”——计算资源有限、响应时间有要求、数据分布会漂移、业务指标要达标。你需要做的不是在某个环节做到完美，而是让所有环节组合起来达到一个平衡的、可用的、可持续的状态。这也是我反复强调的一个点：AI工程更多时候是在做成本和效果的权衡，而不是一味追求SOTA。

1.2 一个AI系统里真正耗时间的部分

根据我的实际经验，一个完整的AI应用系统，从零开始到稳定运行，时间分配大致是这样的：数据和特征工程大概占40%~50%，模型训练和调优占20%~30%，部署上线和监控体系建设占20%~30%。这不是随口说的比例，我参与过的几个项目基本都是这个分布，数据相关的活永远是最重头的。

为什么数据这么耗时？因为现实世界的数据永远比想象中脏。文本里有各种奇怪的编码、图片里有模糊和遮挡、日志里有缺失字段和异常值，更不用说大量的重复样本和标注错误。我碰到过一个项目，业务方拍胸脯说数据质量没问题，结果我们一跑分析，光重复样本就占了30%，还有接近10%的标注和数据内容对不上。这些坑不填平，后面做再多模型优化都是白费力气。

还有一个容易被低估的部分是评估体系的搭建。你要回答一个问题：“这个模型到底行不行？”如果你只能回答准确率是多少，那说明评估体系还没建立起来。真正的评估要考虑不同用户群体的表现差异、不同时间段的表现稳定性、错误类型分布、业务指标的最终影响等等。这套评估体系看起来不产生什么直接产出，但它是整个项目的方向盘——没有它，你根本不知道往哪个方向调。

1.3 从零开始的四个关键阶段

从一个空目录到一个运行中的AI服务，我习惯把整个流程拆成四个阶段。

第一个阶段是需求定义和方案选型。这个阶段很多技术人员容易跳过或者草草了事，但它恰恰是最不该省的。你要明确业务上到底要解决什么问题、用什么指标衡量效果、数据从哪来、延迟和吞吐的底线是多少。方案选型也不是“哪个模型最新就用哪个”，而是要综合考虑效果、推理成本、生态成熟度和团队掌握程度。

第二个阶段是数据链路搭建。包括数据采集、清洗、标注（如果有监督信号的话）、特征工程、数据版本管理。这个阶段的目标是产出一份各方都认可的数据集，并且数据链路是可复现的——任何时候重新跑一遍，能得到相同的数据。

第三个阶段是模型开发和迭代。包括基线模型、训练框架选择、超参数调优、离线评估。这里的关键是要把“第一版模型”尽快跑出来——哪怕是效果很差的简单模型。原因很简单：尽早跑通全流程，才能更早暴露问题，也才能给业务方一个可以评估的基线参照。

第四个阶段是部署和运营。包括模型服务化、性能优化、监控告警、版本更新策略、模型和数据的一致性保障。很多团队做到第三阶段就觉得完事了，结果上线一周就被各种线上问题打回原形。部署运营这个阶段没做好，前面所有工作等于白做。

2. 从头搭建AI项目的核心环节拆解

说完了整体阶段，我来把每个核心环节的关键细节摊开讲。这些内容都是我在实际项目里反复踩坑之后总结出来的，每一条都对应一个真实的教训。

2.1 数据：决定上限的第一道关卡

数据这块我建议从一开始就建立三个习惯。

第一个习惯是做数据版本管理。别说“这个数据集就是最终版了”，数据永远在变——业务方可能补了一批新数据，可能修正了标注错误，可能调整了采样逻辑。如果没有版本管理，你自己的训练实验都会乱套：昨天跑的结果和今天跑的结果用的可能根本不是一个数据版本，你还在那对比模型效果，意义全没了。我现在的做法是给每份数据一个不可变的ID和版本记录，包括来源、清洗脚本、生成时间、统计摘要，全部记录清楚。

第二个习惯是写数据清洗脚本而不是手工改数据。任何数据修改都要能自动复现。有人可能会想“就这么几百条脏数据，我Excel里改一下不就行了”，绝对不行——今天你手工改了，明天数据一更新，脏数据又回来了，你又要手工改一遍，永远没有尽头。必须把清洗逻辑写成代码，数据进来自动跑。

第三个习惯是拆分数据子集时要考虑时间维度。如果数据有时序属性，一定要保证训练集和验证集在时间上是先后的——用过去预测未来，而不是随机打乱。我碰到过有人随机划分数据，结果同一个事件的多个相关样本被分到了训练集和验证集两边，指标虚高得离谱，上线就现原形。

2.2 模型选型：不要重复造轮子

模型选型这块我给的建议特别直接：优先用成熟的开源模型和预训练模型，除非你有极其特殊的需求，否则不要自己从头训模型。原因很简单——从头训练一个大模型的成本动辄几百万，而且效果还不一定干得过开源社区持续迭代出来的成果。你的核心价值在于把模型用好、把系统做好，而不是重造一个轮子。

我见过一个团队花了大半年时间自己训练一个文本生成模型，理由是“开源模型不够定制化”，结果训出来的效果还不如当时最新开源的模型。浪费时间不说，还拖慢了整个项目进度。正确的做法是：先用开源模型快速跑通流程，确认业务价值之后，再考虑要不要在特定场景下做微调或者蒸馏。

还有一个选型原则：模型的“天花板”不是越高越好，而是要匹配你的约束条件。一个几百亿参数的大模型，即使效果再好，如果你的业务场景要求50毫秒内返回结果、部署成本又有限，那它就不是合适的方案。这时候可能一个几亿参数的小模型经过精心调校，反而在实际业务中表现更均衡。

2.3 评估体系：没有度量就没有改进

评估体系这件事，我从一个反面案例说起。有个项目的模型阶段性训练完成了，我问对方负责人“效果怎么样”，他给我看了一份报告，上面写着整体准确率96.5%。我再问“不同类别准确率分别是多少？错误样本主要是什么类型？和上一个版本比提升了多少？”——他答不上来。这种状态做AI工程是绝对不行的。

一个合格的评估体系至少包含三个层面。第一个层面是总体指标，包括准确率、精确率、召回率、F1这些基础度量，但这只是起点。第二个层面是分层分析，要拆到每个类别、每个用户群体、每个时间段去看，很多时候整体指标没问题，但某个细分群体表现极差，这种问题不拆开看是发现不了的。第三个层面是错误分析，随机抽几百条错误样本，人工看一遍，归类总结——这是最花时间但最有价值的环节，它直接告诉我们模型在哪些地方有缺陷，下一步该往哪个方向优化。

评估体系还有一个作用容易被忽略：它是你和业务方沟通的语言。技术团队说“模型准确率96.5%”，业务方听了没感觉；但你说“这个模型能把90%的常见问题自动解决，剩下10%需要人工处理，其中一半是用户表达不清楚导致的”，业务方马上就能理解价值。评估指标的设计直接影响项目的话语权和推进节奏。

2.4 部署与服务化：让模型真正跑起来

模型训练完了只是开始，能不能稳定跑在生产环境才是关键。部署这块最容易出问题的不是模型本身，而是它和周边系统的配合。

首先是推理性能问题。模型在GPU上跑一次推理可能只要10毫秒，但完整服务链路里有请求解析、特征计算、模型推理、结果后处理、日志记录等各个环节，叠加起来可能就是100毫秒。我曾经优化过一个服务，模型本身只占30%的时间，剩下70%全在特征处理——一些特征要实时查询外部数据库，慢得离谱。后来加了缓存和预计算，整体延迟腰斩。所以性能优化一定是从全链路看，不能只盯着模型。

其次是模型版本和特征一致性。训练时你用的特征定义是特征表里的A版本，上线时服务里跑的特征逻辑如果悄悄变成了B版本，效果就会莫名其妙地变差。这种问题排查起来极其痛苦，因为程序不报错，只是效果下降。我现在的做法是强制要求特征逻辑单点维护，训练和推理共用同一份特征代码，从根上消除不一致的可能。

还有一个部署细节是模型的灰度发布策略。别一次把流量全部切到新模型——先放5%的流量，观察一段时间，确认指标稳定之后再逐步放量，发现问题立刻回滚。这套策略和传统后端服务的灰度逻辑类似，但在AI场景下尤其重要，因为模型的效果评估不像接口正确性那么二元，它需要真实流量来验证。

3. 实操记录：一个完整的从零到一项目

为了把这些内容落地，我拿一个实际操作过的项目来完整过一遍流程。这个项目是做一个面向客服场景的工单智能分类系统——用户提交一个工单，系统自动判断工单类型（比如"账号问题""支付问题""退款申请"等），并推荐给对应处理团队。这是一个非常典型的AI工程从零到一的例子，难度适中，又覆盖了所有关键环节。

3.1 场景定义与方案选型

项目启动第一件事，不是选模型，而是定义清楚“判断准确”这件事。

我们和业务方对齐结论是：工单分类系统的主要价值在于减少人工流转时间，所以核心指标定为“分类准确率”和“处理时效”。分类准确率可以通过抽样人工复核来度量，处理时效可以直接对比自动分派和人工分派的时长差异。目标定为：分类准确率不低于90%，处理时效降低30%以上。

技术选型上，因为工单文本是中文短文本，长度一般在几十到几百字，同时业务希望部署在自有的小型服务器集群上（有数据合规要求），所以我们排除了调用大型云API的方案，选择了开源的中文预训练模型做微调。具体用的是基于BERT架构的一个中文预训练模型，当时在同量级模型里效果和性能都比较均衡。选型理由写得很清楚：它能自托管、推理延迟可控、微调成本在可接受范围内。

模型选型阶段我们特别注意了一个点：避免过度追求模型规模。团队里有同学提出换更大的模型，理由是效果可能更好。但我坚持先用小模型跑通全流程——事实证明这个决定帮我们省了很多时间，因为后面数据处理和特征工程花的精力远大于模型本身的调优，如果用大模型，光训练和部署的成本就会拖慢迭代节奏。

3.2 数据准备与清洗

这个项目最耗时的部分就是数据处理。原始数据是从客服系统导出的工单记录，大概有几十万条，带有人工打好的分类标签，看起来很美——实际一分析，问题一堆。

第一轮清洗下来，我们发现：空文本工单约1.5%、重复工单约12%、标签明显标错的约3%、文本内容乱码的约0.5%。纯文本和标签的分布也不均衡，“账号问题”占了快一半，“其他”类目里混了一堆说不清是啥的内容。这些数据直接用的话，模型学出来一定会偏向大类，而且噪声会把准确率拉低好几个点。

清洗策略是分步走的：先做基础清洗，包括去重、去空、编码统一——这块大概去掉了13%左右的数据；再做标签修正，抽样了一万条工单让人工重新标注，用这个子集来估计并修正全量数据中的错标分布；最后做类别重平衡，对少数类进行过采样、对多数类做下采样，最终得到一个相对均衡的训练集。每一步清洗都做了统计记录：原始数据多少条、去掉多少条、为什么去掉、剩余多少条。这套记录后来帮了大忙——模型效果不理想时，我们第一件事就是回查数据清洗逻辑，确实发现过两次因清洗过度导致信息丢失的问题。

特征工程在这个项目里不是重头戏，因为我们用的预训练模型可以自动从文本中抽取语义特征。不过我们做了一个很小的特征增强：把工单长度、是否包含关键词、工单来源渠道这几个信息拼接进模型的输入。事实证明作用有限，但聊胜于无。这里我也想强调一个态度：不迷信特征工程，也不要完全抵触它，一切以离线评估结果为准。

3.3 训练与微调的实践参数

数据准备好之后，训练这块反而相对标准化了。我用的是开源框架做微调，加载中文预训练模型，在它基础上接了一个分类头。关键参数我这里列一下，方便参考。

学习率设置在2e-5，这是预训练模型微调常用的范围，再大容易破坏预训练权重中的通用语义信息，再小训练收敛太慢。批次大小是32，序列最大长度256——工单文本绝大多数在200字以内，留点余量。训练轮数是3轮。优化器用的是带权重衰减的AdamW，权重衰减系数0.01。学习率加了线性衰减加预热机制，前一步的10%步数做预热，从0线性上升到设定值，防止训练初期震荡。

训练过程中的监控也很关键，我每500步记录一次训练loss和验证集指标。这里有个细节——不要只看loss曲线，loss降不代表效果一定好，我们第一版训练完loss降得挺漂亮但验证准确率就88%，后来加了一次数据增强，把一些同义词替换加入训练，验证准确率提到了91%左右。这个提升幅度不大，但它证明了数据层面的优化仍然有收益空间。

微调完成后就是评估。除了整体指标，我们做了几个维度的分析：每一类工单的精确率和召回率分开看，发现“退款申请”和“订单修改”这两类容易混淆，因为文本语义本来就是相似的。关于错误样本，也抽样了一百条人工过了一遍，发现错两类的共性问题在于“请求的语义焦点”不同——一个是要退款，一个是要修改收货信息。这个观察后面反馈给了特征层，加了轻微的规则辅助后，这两类的准确率又各涨了一个点左右。

3.4 上线部署与持续监控

模型训练完，真正磨人的阶段才刚开始。部署方案我们选了基于容器的方式：模型推理服务打包成镜像，对外提供HTTP接口；服务前面挂负载均衡和灰度路由；旁边配了一个监控面板，实时展示请求量、平均延迟、不同类别的置信度分布。

第一个踩的坑是推理服务的并发性能。之前单机压测觉得没问题，结果一上生产流量，4个副本还是被打得喘不过气——特征计算里有几个高频的外部查询走到了数据库，成了瓶颈。后来把数据库查询改成批量预取加本地缓存，内存多花了不到100MB，QPS直接翻倍。所以性能优化的核心思路是找到真正的瓶颈环节，而不是盲目加机器。

第二个踩的坑是线上效果和离线评估不一致。离线评估准确率91%，上线后抽样复核只有84%左右。排查半天，发现原因有两方面：一是线上用户工单的表达方式比训练集里审过的工单要随意得多——口语化、错别字、语义跳跃更多，这类样本在离线评估集里占比偏低；二是业务方中途调整了工单类型定义——新增了一个“发票问题”类型，老模型完全没有相关训练数据。这两个问题叠加起来，效果自然掉得厉害。

应对策略也分了两步：第一步上了一个快速兜底规则，通过关键词匹配把“发票”相关工单先分流到人工处理，避免系统乱判；第二步立刻组织数据标注，收集线上真实工单，做了一轮针对性的增量训练。经过这两步调整，线上效果回到了89%左右，虽然离91%还有距离，但基本在可接受区间内。这个经历让我深刻意识到：AI系统上线不是终点，而是持续运营的起点。

监控体系里除了基础设施指标，我还加了一个“数据漂移”相关的监控——记录线上推理输入的文本长度分布、关键词频率等统计信息，定期和训练集分布做对比，一旦发现显著偏移就发出告警。这套东西看起来简单，真遇到数据分布变化时帮助特别大——比如某次业务大促导致工单类型分布剧变，系统提前两天就告警了，我们提前做好了应对预案。

4. 常见问题与排查技巧实录

最后这部分，我把这么多年做AI工程项目遇到的高频问题和排查思路整理成一个速查表，每一类都是我实际处理过的，不是从书上抄来的理论。

4.1 训练loss不降怎么办

loss不降这个问题，我见过太多人一上来就调学习率，这是个思路陷阱。第一件要做的事是缩小数据规模——取几百条样本，跑一两个batch，看看模型能不能过拟合这批数据。如果不能过拟合，说明模型结构或者数据处理有bug，比如标签和特征没对齐、模型参数没正确初始化之类；如果能过拟合但全量数据上loss不降，那大概率是数据问题或者学习率设置不合理，这时候再考虑调整学习率。

我排查过一个典型的案例：模型在验证集上效果不错，但训练loss一直高，后来发现是数据处理脚本在跑全量数据的时候有个边界条件写错了，一部分样本的标签和文本错位了。几百条小批量测试根本发现不了这个bug，因为恰好抽到的样本没有触发边界条件。从那以后，我所有数据管道都有“抽样验证”和“全量验证”两套检查逻辑。

4.2 线上和离线效果不一致

这个问题基本是AI工程的第一大坑。我的统一排查思路是分三步走。第一先查特征一致性——对比训练时记录的特征和线上请求时实际算出来的特征，因为哪怕是同一个特征名，如果计算逻辑版本不同，结果都可能差很远。第二查数据分布——把线上真实输入抽样一批，和训练集的统计特征做对比，看分布差异有多大。第三查评估口径——线上评估是不是用了和离线完全相同的标准，很多时候线上“效果差”是因为评估标准变了，比如线上计入了一些离线评估时被排除的边界用例。

这里我分享一个反直觉的经验：线上效果比离线好也是可能发生的。原因是线上用户提交的工单通常已经经过一轮系统预检查，少了很多脏输入；或者线上有些高频类别恰好是模型学得最好的类别。所以不要默认“线上一定比离线差”，一切以实际度量为准。

4.3 模型效果时间衰减问题

时间衰减这个事很微妙，它不是突然发生的，而是一点一点变差的——这周比上周低0.2%，下周又低0.3%，等你有感知时可能已经过了两个月。所以我强烈建议从系统上线第一天就把指标监控建立起来，哪怕只是每天算一次核心指标，存成曲线，一个月后回看就能看出趋势。

时间衰减的应对方法有几种：定期增量训练、周期性重新标注和评估、上线自动化的数据漂移监控。增量训练要注意别在旧模型上反复微调——时间久了模型可能会“遗忘”早期的知识，最好定期用累积数据重新训练一个基线，再做增量调整。这个策略虽然成本高一些，但模型的长期健康度好得多。

4.4 成本控制：别让账单绑架项目

最后说一个大家容易忽略但无比现实的问题：成本。AI项目的成本大头通常不在GPU采购，而在持续运营——数据存储、模型推理、人工标注、增量训练，每个环节都是支出。GPU给钱就能用，但数据质量监测、特征治理这些“软功夫”，账面上看不到，实际价值比想象中大得多。

我的成本控制原则是：关键路径核销，非关键路径省钱。推理服务是核心路径，该上GPU加速就上，该扩容就扩；训练实验是核心路径，不能为了省算力砍掉必要的验证实验；但日志存储这类非核心路径，可以用便宜的冷存储方案。这里有一个比较实用的技巧：模型推理的批处理。有些业务场景不用实时响应，可以把多条请求攒一批再送推理，吞吐量一下能提好几倍，成本也能省不少。

5. 项目复盘与长期演进建议

项目上线稳定运行三个月后，做一个完整的复盘，我认为是“从零开始做AI工程”这个流程里最后、也最有价值的动作。

先说数据层面。复盘时我们对全量线上数据做了一次分布分析，发现一个当时没注意到的问题：我们最初的数据清洗策略是为了短期效果设计的——比如把“长度过长”的工单直接丢弃，但线上真实数据里有不少长工单恰恰是高价值用户提交的复杂问题。这类工单虽然数量少，但对业务影响大。复盘之后我们把长文本处理策略改成了截断加摘要，效果比直接丢弃好很多。这个案例说明：数据清洗策略需要结合业务知识动态调整，而不能固守一次性的技术判断。

再说评估层面的演进。上线初期我们的评估周期是一周一次、抽样量是500条，这能发现大问题但发现不了慢性的细微退化。运营三个月后，我们把评估调整成了“每日自动采样+每周详细分析”的节奏：每天自动抽200条线上样本打标并计算指标，每周做一次完整的错误类型分析。这个调整的作用是让退化趋势在几天的尺度上就能被看到，而不是等一两周甚至一个月后才后知后觉。

有件事我想提醒大家——复盘一定要看“指标以外的信号”。除了分类准确率这类核心指标，还要关注一些间接指标：人工作单处理时长变化、用户重复提交工单比率、业务方对自动分类结果的接受率等等。这些间接指标往往能更早反映系统的真实价值和数据健康度。

关于长期演进，我建议做三件事。第一，建立定期的数据健康度检查机制——不是出问题才查，而是每隔一段时间主动检查数据分布、标注质量、特征有效性，把问题消灭在萌芽期。第二，搭建自动化的重训流水线——当监控告警数据漂移或者效果退化超过阈值时，系统自动触发数据采集、清洗、标注、增量训练、离线评估、灰度发布的完整链路。这个流水线初期可以比较粗糙，手动确认后触发也可以，但流程一定要通。第三，持续追踪最新的模型和工具——AI领域发展速度很快，半年后可能出现更合适的新方案。但这不意味着要追新，而是在新方案有明确收益证据的前提下做技术升级。换模型的成本很高，特征逻辑、评估基准、部署方案全要跟着变，所以升级决策一定要让数据说话。

我见过不少团队做AI项目，一开始轰轰烈烈，上线后疏于运维，三个月后系统表现下降，业务方失去信心，项目就被叫停了。说起来挺可惜的——他们不是技术不行，而是缺少“AI系统建设不是一锤子买卖”这个基本认知。如果你能把这套从数据、模型、评估到部署运营的闭环跑通，并且让它持续循环起来，那你做的不只是一个项目，而是一个能不断产生业务价值的工程体系。这就是我从“ai-engineering-from-scratch”这个起点，一路走到现在的完整路径。希望这次的分享能帮你少走一些弯路，这大概也是这个领域里最难能可贵的东西。