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个副本还是被打得喘不过气——特征计算里有几个高频的外部查询走到了数据库成了瓶颈。后来把数据库查询改成批量预取加本地缓存内存多花了不到100MBQPS直接翻倍。所以性能优化的核心思路是找到真正的瓶颈环节而不是盲目加机器。第二个踩的坑是线上效果和离线评估不一致。离线评估准确率91%上线后抽样复核只有84%左右。排查半天发现原因有两方面一是线上用户工单的表达方式比训练集里审过的工单要随意得多——口语化、错别字、语义跳跃更多这类样本在离线评估集里占比偏低二是业务方中途调整了工单类型定义——新增了一个“发票问题”类型老模型完全没有相关训练数据。这两个问题叠加起来效果自然掉得厉害。应对策略也分了两步第一步上了一个快速兜底规则通过关键词匹配把“发票”相关工单先分流到人工处理避免系统乱判第二步立刻组织数据标注收集线上真实工单做了一轮针对性的增量训练。经过这两步调整线上效果回到了89%左右虽然离91%还有距离但基本在可接受区间内。这个经历让我深刻意识到AI系统上线不是终点而是持续运营的起点。监控体系里除了基础设施指标我还加了一个“数据漂移”相关的监控——记录线上推理输入的文本长度分布、关键词频率等统计信息定期和训练集分布做对比一旦发现显著偏移就发出告警。这套东西看起来简单真遇到数据分布变化时帮助特别大——比如某次业务大促导致工单类型分布剧变系统提前两天就告警了我们提前做好了应对预案。4. 常见问题与排查技巧实录最后这部分我把这么多年做AI工程项目遇到的高频问题和排查思路整理成一个速查表每一类都是我实际处理过的不是从书上抄来的理论。问题现象可能原因排查思路训练loss降不下去学习率不合适数据噪声太大标签错误率高先用小批量数据试跑看看能不能过拟合检查数据清洗逻辑调整学习率范围验证集效果好但线上效果差数据分布不一致特征不一致模型过拟合训练集对比线上和训练数据的分布检查特征处理逻辑是否一致增加线上样本到训练集线上偶发推理超时外部依赖变慢并发突增冷启动问题看全链路追踪定位耗时环节做压力测试预留配额和降级策略模型效果随时间变差数据漂移业务规则变化用户行为变化监控输入分布变化检查业务方是否调整了定义和流程定期用最近数据做评估多类别里某些类别效果特别差样本不足类别之间语义相似标注不一致单独统计每个类别的样本量和指标做错误样本的归类分析针对少数类做增强或采集推理服务内存持续上涨模型加载多副本缓存没清理框架内存泄漏监控内存曲线检查缓存策略逐个依赖做内存压测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”这个起点一路走到现在的完整路径。希望这次的分享能帮你少走一些弯路这大概也是这个领域里最难能可贵的东西。
