在AI这个圈子里待得越久我越发现一个有意思的现象真正让团队拉开差距的往往不是谁家的模型效果高零点几个点而是谁能把模型稳定、高效、可维护地跑在生产环境里。前者叫算法研究后者才是“ai-engineering”。而当你决定从零开始搭建一整套AI工程体系也就是标题里那个“from scratch”的时候面对的就不再是单个模型的问题而是一条从数据、训练、部署到监控的完整链路。这篇文章我会把这些年从零搭体系的经验、踩过的坑、以及最终沉淀下来的方法论完整拆给你看。我默认读到这里的朋友可能是刚接手AI平台建设的后端工程师也可能是算法团队里被推着做工程化的算法工程师或者只是想搞清楚AI工程到底是什么的架构师。这套内容不绑定任何具体框架也不预设你公司规模它只回答一个问题当你想让AI真正变成业务系统里可靠的一部分到底该先做什么、后做什么、哪些坑可以提前绕开。1. 先想清楚再动手从零搭建AI工程的顶层设计1.1 AI工程到底管哪几件事很多团队在启动AI工程化的时候第一反应是“上K8s”“上MLflow”“上监控平台”工具还没选好先把自己埋在选型文档里。我的建议是反过来先用一张图把工程边界画清楚。AI工程内部其实可以拆成三横一纵三横是数据工程、模型工程、发布工程一纵是贯穿始终的可观测性与自动化。这个划分不是我发明的是我在复盘好几个失败项目后总结出来的。数据工程解决的是“模型吃什么”采集、清洗、特征计算、数据版本、样本存储。模型工程解决的是“模型怎么长出来”实验追踪、训练编排、超参调优、评估准入。发布工程解决的是“模型怎么见客”镜像构建、服务化、灰度、回滚、容量管理。而贯穿的监控与自动化决定了这套体系是“能跑”还是“能自己跑”。我见过太多团队把AI工程等同于“训练平台”结果数据管道一团乱麻模型上线全靠手工copy文件这本质上只做了三分之一的事。1.2 从零搭建 vs 引入现成平台的真实取舍“from scratch”这个词容易让人误解以为必须所有轮子都自己造。我的真实建议是框架可以借但关键控制点必须掌握在自己手里。一个比较常见的做法是列一个自建与采购的决策矩阵数据管道和特征存储这种跟业务深度耦合的部分别买通用产品自己搭实验追踪、模型注册这种行业已有成熟开源方案的直接用MLflow或者同类的工具服务化推理这种有性能门槛的先封装开源方案等规模撑不住了再替换。这套取舍背后有很实际的理由。数据管道和你的数仓、指标体系、业务日志强绑定通用工具很难适配你的数据方言。而实验追踪这种需求是行业通用的自己写一套记录指标的系统除了浪费工时没有任何优势。我记得有次和一个团队聊他们说花了两周自建了一个“实验指标对比工具”功能就是展示两列数字和折线图——这就是典型的没有想清楚边界。真实经验是凡是不产生业务差异化的部分尽量站在开源巨人肩膀上腾出精力去啃数据和服务化这些硬骨头。1.3 最小可用闭环先跑通再丰满从零搭建体系最常见的失败模式是贪大。一上来就规划“AI中台”拉齐十几个部门的需求画了一整面墙的架构图结果半年过去一个模型都没上线。我现在的铁律是先做最小可用闭环也就是一个最简但端到端完整的模型上线流程。这个最小闭环有多小一个样本数据集、一个baseline模型、一条推理API、一份接口日志监控就这四样。目标是让业务方看到“模型从数据变成了线上服务”哪怕这个模型效果一般、服务性能也很朴素但整条链路是通的。补全细节的话链路至少应该覆盖数据读取、训练启动、模型产物保存、镜像打包、部署、线上调用、日志落盘。先把这七个节点跑通之后再一个一个替换成更专业的组件。这个思路和软件工程里的“垂直切片”完全一致但很多AI团队因为习惯了对拍模型的思维反而最容易在这个环节翻车。2. 数据侧工程特征管道、数据版本与质量门禁2.1 数据管道分层设计从采集到特征计算数据管道做不好后面所有环节都是空中楼阁。我推荐的分层方式是四层采集层、清洗层、特征层、存储层。采集层负责从业务数据库、日志、消息队列里拿到原始数据核心要求是“不漏不重”。清洗层处理缺失值、异常值、格式统一产出的是所谓的“明细宽表”。特征层做的是特征工程把宽表加工成模型输入。存储层则负责把样本和特征按时间窗口存起来供训练和线上拉取复用。这个分层看着基础但真做起来全是细节。采集层最常见的问题是重复采集导致样本漂移清洗层最头疼的是“清洗逻辑上线后旧数据要不要重跑”特征层最大的隐患是“离线特征和在线特征不一致”。后者我特别想强调很多模型上线后效果大跌不是模型坏了而是训练时用的特征计算逻辑和线上服务时用的那段代码根本不是同一份。所以特征层有个硬性要求——离线在线统一计算逻辑要么同一套代码打两个包要么用特征平台统一生成绝不能离线一套、在线又写一遍。2.2 为什么数据版本管理比代码版本管理更让人头疼代码回滚很成熟Git三两下就搞定。但数据回滚呢你训练时用的那份数据长什么样过三个月还能复现吗我见过太多团队模型表现不理想想回看训练数据结果当时的数据已经被新的清洗逻辑覆盖了怎么都对不回来。这就是数据版本管理要解决的问题。主流做法有两条路一条是引入DVC这类数据版本工具本质是把数据和代码一样纳入版本控制用哈希或者清单文件记录每个版本对应的文件快照另一条是在自己的存储层实现快照逻辑每次清洗任务跑完把产物表标记一个版本号和时间戳并记录清洗代码的版本。我更推荐后者因为它跟数据管道天然结合回放起来也更灵活。数据版本管理的关键不是“存多份数据副本”而是“能精准找到某个时间点模型训练背后的那批数据长什么样”。我说句实在话这个能力在事后排查模型事故时价值怎么强调都不为过。2.3 数据质量门禁给数据管道装红绿灯模型是吃数据长大的数据质量不过关后面的一切都是负资产。我落地数据质量检查的经验是在每层管道出口设置质量门禁规则就五类完整性、唯一性、时效性、范围合法性和分布漂移。完整性检查统计表行数是否达到预期唯一性检查主键是否有重复时效性检查数据延迟是否超阈值范围合法性检查字段值是否落在合理区间比如年龄不能是负数、金额不能超过上限分布漂移则用PSI或者简单的均值方差对比判断今天的数据分布和训练集有没有明显差异。给一张表加上自动检查任务后规则不必一开始做得很复杂先卡住行数、主键、Featurenull率这些硬指标等稳定了再逐步累加。我记得有个业务场景某天标签数据因为上游任务失败没更新如果是人工发现大概率要过半天加了行数门禁后作业一跑完就报警直接把问题扼杀在源头。3. 训练与实验管理模型侧的核心工程3.1 实验追踪三件套指标、超参数、产物算法团队最常犯的工程毛病是实验记录全靠个人习惯有人写在Excel有人记在Notion还有人靠脑子回忆。等到模型要复盘根本说不清哪个指标是哪个超参跑出来的。我自己的做法是标准化到三件套指标数据全量记录超参配置全量记录模型产物地址固定关联。每跑一次实验就生成一条不可变记录包含这三个维度。工具选型上MLflow是目前最省力的方案它天然支持这三件套的关联存贮。如果不想引额外依赖也可以自己在实验脚本里写记录逻辑但我建议最终还是落到一个可查询的存储里而不是分散的文本文件。实验追踪的核心价值不在于“记录”本身而在于让团队日后能对任何模型效果给出可追溯的解释。很多团队不重视这个环节直接导致后续的模型注册准入、甚至跨团队协作都没法顺畅开展。3.2 GPU利用率与训练资源调度的常见坑训练侧工程很重要的一个环节是资源管理尤其GPU集群的调度。很多平台搭起来了但GPU利用率维持在20%团队还以为是正常的。说实话这是工程浪费的大头。GPU利用率低的原因无非三块显存设置不合理导致batch撑不上去数据读取IO太慢导致GPU空转等数据以及任务调度机制太粗糙导致资源碎片化。针对第一块我建议用动态batch或者自动显存检测来逼近上限不要手动拍一个很小的batch图省事。针对第二块要把数据加载做成异步预取让GPU在喂数据时不用等CPU。第三块则要看集群调度策略很多团队用简单的“谁先来谁占卡”容易导致大任务排不上、小任务占着卡不放需要用队列配合优先级来调度。另外提一句GPU监控不要只看nvidia-smi输出的一瞬间要用DCGM或者同类的指标采集工具连续记录利用率、显存、温度、功耗。有一次我们排查训练变慢靠瞬时快照怎么看都正常拉出曲线才发现每过几分钟显存利用率就归零定位到是数据Loader在周期性做大量预处理。这种问题不用连续监控根本发现不了。3.3 模型注册表从实验到准入的关卡设计训练完成后模型不能直接部署中间应该有一道“准入闸门”。我的习惯是建立模型注册中心统一登记所有候选模型的信息并设计一个模型准入清单包含五项核心检查评估指标是否达到业务底线、评估过程是否可复现数据版本和代码版本是否锁定、是否已用回放数据做过验证、推理资源预估是否符合线上容量、以及负责人和上线说明是否填写完整。这个清单看起来行政化但它能挡住九成以上的“带病上线”。有一次我问一个团队他们的新模型为什么效果更好结果对方的实验记录里连数据版本都没锁这意味着连他自己都不知道这次训练的数据和上一次有什么区别。这种模型就算指标再好看我也不会放行。模型注册表的意义就是让“部署一个模型”从一个技术动作变成一个受控的工程决策是工程化成熟度的重要标志。4. 部署与服务化绕不开的推理架构设计4.1 在线推理、批量推理、流式推理三种形态怎么选模型部署最忌讳“一招鲜吃遍天”。不同业务场景对延迟、吞吐、成本的要求完全不同部署形态也应该不同。我把推理分为三种在线推理、批量推理、流式推理。在线推理面向实时请求要走REST或者RPC接口延迟要求在百毫秒级批量推理面向离线任务比如每日跑一次的预测报表关注的是吞吐和成本不要求实时流式推理则对接消息队列数据到达即处理适合事件驱动型的业务。选型判断上有一个很实用的问题列表业务方需要多快拿到结果如果答案是“点击之后立即”那就是在线如果是“明天早上看到”那就是批量如果希望“事件一发生就触发”那是流式。很多团队不分场景所有模型都包一个在线API其实特别浪费。举一个实际案例一个推荐团队的召回模型每天跑全量打分完全可以用批处理框架每天凌晨算好结果导出结果他们搭了一套在线服务天天跑定时请求既浪费了GPU还增加了在线链路故障面。分清形态很多工程复杂度自然就降下来了。4.2 服务化选型与镜像治理确定了推理形态后就要选推理框架。我的经验是从简单到复杂排队先不要上重量级框架。初期用FastAPI或者Flask封装模型推理函数跑通流程没问题在线服务成型后再考虑用Triton这类高性能推理服务器来做多模型管理、动态batch和GPU复用。选择中间有一些权衡点我整理成表格会更好理解方案适用阶段优点代价自封装FastAPI团队初期、模型量少简单直接、定制自由高性能场景吃力、多模型管理差开源推理框架Triton等模型量中等、需要GPU复用多模型并发、动态batch、GPU利用率高学习成本、配置复杂度自研RPC服务大规模专用场景极致性能和定制能力开发维护成本极高另外镜像治理是服务化里最容易被忽略的一环。模型镜像里应该把依赖、版本、启动脚本、健康检查都固化下来而不是每次部署靠手工跑命令。我们内部的要求是每个可部署的模型版本必须对应一个不可变镜像标签线上什么版本跑什么镜像账目必须清晰。有次排查一个线上模型预测全为0的问题最后发现是部署时依赖库版本变化导致预处理逻辑被跳过——如果能做到镜像版本与服务版本严格对应这类问题是可以直接规避的。4.3 灰度发布、回滚与模型版本切流模型上线和普通代码上线最大的区别在于“模型效果是概率性的”你不能指望全量上线后用一两天试错。所以灰度发布在模型场景几乎是必选。我的做法是支持按流量百分比切流先把5%的流量给新模型观察核心指标稳定后再逐步扩大直到100%。如果要更谨慎可以在切流前用“影子模式”跑一段时间也就是新模型和旧模型同时接收请求但新模型的结果不外发只做逻辑对比。回滚机制的侧重点也和代码不一样。代码回滚把进程切回旧版本就行但模型回滚要小心数据形态的变化如果线上生产服务期间特征逻辑已经在往前演进旧模型可能需要旧的特征代码才能正常工作。所以我的建议是模型和特征逻辑一起打包为一个“可回滚单元”回滚时不是单独rebuild模型镜像而是整个单元回到上一版本的组合。这个细节我们踩过一次坑才意识到希望你不要等着踩第二次。5. 模型监控与反馈闭环上线才算工程的开始5.1 数据漂移与模型漂移两个完全不同的问题模型上了线很多团队觉得大功告成实际上最难的环节才开始。模型的线上表现会随时间变化原因无非两类要分开监控。一类是数据漂移线上输入数据的分布和训练集分布产生了差异。比如销售预测模型训练时用的用户行为数据分布和现在的实际分布不一样了。监控数据漂移的指标我用得比较多的是PSI和KL散度同时关注核心特征的均值、方差和空值率变化。PSI值有一个经验参考区间小于0.1表示稳定0.1到0.25表示轻度漂移超过0.25就要拉响警报。另一类是概念漂移数据分布没变但“数据和标签之间的映射关系”变了。比如用户的购买倾向和同样的行为序列之间的关联变了这在业务规则调整、市场环境变化时特别常见。概念漂移更难监控通常需要结合业务指标的变化来综合判断。简单说数据漂移看输入特征概念漂移看预测结果和实际反馈的偏差两者监控口径完全不同不要混为一谈。5.2 反馈闭环从被动监控走向自动迭代监控只是发现问题的眼睛闭环才是解决问题的双手。一个完整的AI工程体系最终应该形成数据到模型的反馈环线上预测结果定期回流到存储通过标注或者隐式反馈生成新样本新样本进入数据管道形成训练集触发重新评估和重训候选模型通过注册准入后再灰度上线。这个闭环转起来之后AI系统才算有了自我迭代的雏形。这个闭环的落地难度不在机制设计而在中间环节的自动化程度。我见过很多团队卡在“样本回流”这一步线上日志存了一堆但没人写任务去抽取和转换成标注样本。所以我的建议是在搭建早期就明确“线上日志的消费方是谁”每个接口在出日志时就要带上request_id、模型版本、特征快照、预测结果这几个字段方便后续回溯。重训的触发条件我习惯用组合策略监控指标触发、定时周期性重训、业务方手动触发三管齐下。自动重训之后必须走准入清单不能直接替换线上模型否则一个坏数据批次就能让整个模型退化到失控。6. 大模型时代的AI工程变化6.1 从传统ML到LLM应用工程关注点有哪些转移大模型这一波起来后AI工程的重心发生了一些明显变化但底层的地基并没有变。传统ML工程的核心是把一个模型训练好、部署好而LLM应用工程包括RAG、Agent这些方向的核心变成了如何编排好一个外部大脑真正困难的不再是训练而是“如何用好这个模型”。具体来说工程关注点有三个明显变化。第一从模型训练转向上下文工程传统的特征工程变成了系统提示词的拼装、知识库切片的组织本质上仍是“给模型喂对材料”。第二从确定性评估转向概率性评估LLM的输出每次都不一样评测需要一个包含标准答案的评估集并且要反复测而不是单看一两次表现。第三从模型单体转向系统链路一个LLM应用往往由多个模块串联比如检索模块、大模型调用模块、外部工具模块整个链路的状态追踪与观测变得特别重要。6.2 RAG应用工程化的关键检索、缓存与追踪如果你做一个RAG应用AI工程的细节会集中在几个地方文档切片策略、检索质量、缓存设计、向量库运维和链路追踪。文档怎么切看起来是数据预处理的小问题实际对效果影响巨大。切得太碎语义被切断切得太整检索命中率下降。我的经验是按语义段落切再用重叠窗口保留上下文一套切法需要拿评测集去调不能拍脑袋。向量库的运维也是一个典型的AI工程课题向量维度的选择、索引类型、分片策略、以及数据更新时的重新索引策略都会直接影响查询延迟和召回效果。此外LLM调用是有成本的高频问题要做缓存缓存键必须考虑问题和上下文切片内容的哈希避免缓存不命中导致预算失控。链路追踪是所有RAG应用的必修课。用户问了一个问题系统走到了哪个分支检索命中了哪些片段大模型是否调用了工具最终答案用了哪几块知识碎片这些都得有日志可查。否则线上出了问题你连是“检索坏了”还是“模型答错了”都分不清。我给团队的要求是任何一个线上反馈都要能追踪到完整的链路LLM应用本质上就是一个有状态的分布式系统。6.3 Prompt、Agent与评估治理大模型工程的软基建大模型应用里Prompt和Agent配置也变成了需要工程化管理的资产。我见过团队把Prompt直接写在业务代码里改一句提示词就要重新发布服务这个做法长远看非常危险。更好的做法是把Prompt作为独立配置项来做版本管理配合评测集来验证每一次改动是否真的改善了效果而不是凭感觉调。Agent方向更需要治理。多个工具调用、多轮自主决策如果没有护栏和审计日志线上风险会迅速放大。我的建议是给Agent系统加三类基本约束权限边界哪些工具能调、哪些数据不能碰、决策日志每次工具调用都记录上下文和参数、人工确认点高影响动作必须人审。这些和传统AI工程的可观测性一脉相承只是作用对象从模型服务变成了智能体行为。回到“from scratch”这个话题我想说一些个人体会。AI工程体系和庞然大物的软件系统一样不可能一步到位也不应该一步到位。它是一点点“生长”出来的先解决数据可见再解决训练可复现然后搞定上线可回滚最后完善监控可迭代。每往前走一步系统都在变得更稳定、更自动而所有这些步骤加在一起才是“AI工程”这四个字的真正分量。那些一上来就追求完美架构的团队通常撑不到体系长成的那个阶段反而是愿意从小闭环开始、一步步扎扎实实补全的团队最后跑得更远。这个道理放在任何时候都不会过时。
AI工程从零搭建：数据、训练、部署与监控全链路实践
在AI这个圈子里待得越久我越发现一个有意思的现象真正让团队拉开差距的往往不是谁家的模型效果高零点几个点而是谁能把模型稳定、高效、可维护地跑在生产环境里。前者叫算法研究后者才是“ai-engineering”。而当你决定从零开始搭建一整套AI工程体系也就是标题里那个“from scratch”的时候面对的就不再是单个模型的问题而是一条从数据、训练、部署到监控的完整链路。这篇文章我会把这些年从零搭体系的经验、踩过的坑、以及最终沉淀下来的方法论完整拆给你看。我默认读到这里的朋友可能是刚接手AI平台建设的后端工程师也可能是算法团队里被推着做工程化的算法工程师或者只是想搞清楚AI工程到底是什么的架构师。这套内容不绑定任何具体框架也不预设你公司规模它只回答一个问题当你想让AI真正变成业务系统里可靠的一部分到底该先做什么、后做什么、哪些坑可以提前绕开。1. 先想清楚再动手从零搭建AI工程的顶层设计1.1 AI工程到底管哪几件事很多团队在启动AI工程化的时候第一反应是“上K8s”“上MLflow”“上监控平台”工具还没选好先把自己埋在选型文档里。我的建议是反过来先用一张图把工程边界画清楚。AI工程内部其实可以拆成三横一纵三横是数据工程、模型工程、发布工程一纵是贯穿始终的可观测性与自动化。这个划分不是我发明的是我在复盘好几个失败项目后总结出来的。数据工程解决的是“模型吃什么”采集、清洗、特征计算、数据版本、样本存储。模型工程解决的是“模型怎么长出来”实验追踪、训练编排、超参调优、评估准入。发布工程解决的是“模型怎么见客”镜像构建、服务化、灰度、回滚、容量管理。而贯穿的监控与自动化决定了这套体系是“能跑”还是“能自己跑”。我见过太多团队把AI工程等同于“训练平台”结果数据管道一团乱麻模型上线全靠手工copy文件这本质上只做了三分之一的事。1.2 从零搭建 vs 引入现成平台的真实取舍“from scratch”这个词容易让人误解以为必须所有轮子都自己造。我的真实建议是框架可以借但关键控制点必须掌握在自己手里。一个比较常见的做法是列一个自建与采购的决策矩阵数据管道和特征存储这种跟业务深度耦合的部分别买通用产品自己搭实验追踪、模型注册这种行业已有成熟开源方案的直接用MLflow或者同类的工具服务化推理这种有性能门槛的先封装开源方案等规模撑不住了再替换。这套取舍背后有很实际的理由。数据管道和你的数仓、指标体系、业务日志强绑定通用工具很难适配你的数据方言。而实验追踪这种需求是行业通用的自己写一套记录指标的系统除了浪费工时没有任何优势。我记得有次和一个团队聊他们说花了两周自建了一个“实验指标对比工具”功能就是展示两列数字和折线图——这就是典型的没有想清楚边界。真实经验是凡是不产生业务差异化的部分尽量站在开源巨人肩膀上腾出精力去啃数据和服务化这些硬骨头。1.3 最小可用闭环先跑通再丰满从零搭建体系最常见的失败模式是贪大。一上来就规划“AI中台”拉齐十几个部门的需求画了一整面墙的架构图结果半年过去一个模型都没上线。我现在的铁律是先做最小可用闭环也就是一个最简但端到端完整的模型上线流程。这个最小闭环有多小一个样本数据集、一个baseline模型、一条推理API、一份接口日志监控就这四样。目标是让业务方看到“模型从数据变成了线上服务”哪怕这个模型效果一般、服务性能也很朴素但整条链路是通的。补全细节的话链路至少应该覆盖数据读取、训练启动、模型产物保存、镜像打包、部署、线上调用、日志落盘。先把这七个节点跑通之后再一个一个替换成更专业的组件。这个思路和软件工程里的“垂直切片”完全一致但很多AI团队因为习惯了对拍模型的思维反而最容易在这个环节翻车。2. 数据侧工程特征管道、数据版本与质量门禁2.1 数据管道分层设计从采集到特征计算数据管道做不好后面所有环节都是空中楼阁。我推荐的分层方式是四层采集层、清洗层、特征层、存储层。采集层负责从业务数据库、日志、消息队列里拿到原始数据核心要求是“不漏不重”。清洗层处理缺失值、异常值、格式统一产出的是所谓的“明细宽表”。特征层做的是特征工程把宽表加工成模型输入。存储层则负责把样本和特征按时间窗口存起来供训练和线上拉取复用。这个分层看着基础但真做起来全是细节。采集层最常见的问题是重复采集导致样本漂移清洗层最头疼的是“清洗逻辑上线后旧数据要不要重跑”特征层最大的隐患是“离线特征和在线特征不一致”。后者我特别想强调很多模型上线后效果大跌不是模型坏了而是训练时用的特征计算逻辑和线上服务时用的那段代码根本不是同一份。所以特征层有个硬性要求——离线在线统一计算逻辑要么同一套代码打两个包要么用特征平台统一生成绝不能离线一套、在线又写一遍。2.2 为什么数据版本管理比代码版本管理更让人头疼代码回滚很成熟Git三两下就搞定。但数据回滚呢你训练时用的那份数据长什么样过三个月还能复现吗我见过太多团队模型表现不理想想回看训练数据结果当时的数据已经被新的清洗逻辑覆盖了怎么都对不回来。这就是数据版本管理要解决的问题。主流做法有两条路一条是引入DVC这类数据版本工具本质是把数据和代码一样纳入版本控制用哈希或者清单文件记录每个版本对应的文件快照另一条是在自己的存储层实现快照逻辑每次清洗任务跑完把产物表标记一个版本号和时间戳并记录清洗代码的版本。我更推荐后者因为它跟数据管道天然结合回放起来也更灵活。数据版本管理的关键不是“存多份数据副本”而是“能精准找到某个时间点模型训练背后的那批数据长什么样”。我说句实在话这个能力在事后排查模型事故时价值怎么强调都不为过。2.3 数据质量门禁给数据管道装红绿灯模型是吃数据长大的数据质量不过关后面的一切都是负资产。我落地数据质量检查的经验是在每层管道出口设置质量门禁规则就五类完整性、唯一性、时效性、范围合法性和分布漂移。完整性检查统计表行数是否达到预期唯一性检查主键是否有重复时效性检查数据延迟是否超阈值范围合法性检查字段值是否落在合理区间比如年龄不能是负数、金额不能超过上限分布漂移则用PSI或者简单的均值方差对比判断今天的数据分布和训练集有没有明显差异。给一张表加上自动检查任务后规则不必一开始做得很复杂先卡住行数、主键、Featurenull率这些硬指标等稳定了再逐步累加。我记得有个业务场景某天标签数据因为上游任务失败没更新如果是人工发现大概率要过半天加了行数门禁后作业一跑完就报警直接把问题扼杀在源头。3. 训练与实验管理模型侧的核心工程3.1 实验追踪三件套指标、超参数、产物算法团队最常犯的工程毛病是实验记录全靠个人习惯有人写在Excel有人记在Notion还有人靠脑子回忆。等到模型要复盘根本说不清哪个指标是哪个超参跑出来的。我自己的做法是标准化到三件套指标数据全量记录超参配置全量记录模型产物地址固定关联。每跑一次实验就生成一条不可变记录包含这三个维度。工具选型上MLflow是目前最省力的方案它天然支持这三件套的关联存贮。如果不想引额外依赖也可以自己在实验脚本里写记录逻辑但我建议最终还是落到一个可查询的存储里而不是分散的文本文件。实验追踪的核心价值不在于“记录”本身而在于让团队日后能对任何模型效果给出可追溯的解释。很多团队不重视这个环节直接导致后续的模型注册准入、甚至跨团队协作都没法顺畅开展。3.2 GPU利用率与训练资源调度的常见坑训练侧工程很重要的一个环节是资源管理尤其GPU集群的调度。很多平台搭起来了但GPU利用率维持在20%团队还以为是正常的。说实话这是工程浪费的大头。GPU利用率低的原因无非三块显存设置不合理导致batch撑不上去数据读取IO太慢导致GPU空转等数据以及任务调度机制太粗糙导致资源碎片化。针对第一块我建议用动态batch或者自动显存检测来逼近上限不要手动拍一个很小的batch图省事。针对第二块要把数据加载做成异步预取让GPU在喂数据时不用等CPU。第三块则要看集群调度策略很多团队用简单的“谁先来谁占卡”容易导致大任务排不上、小任务占着卡不放需要用队列配合优先级来调度。另外提一句GPU监控不要只看nvidia-smi输出的一瞬间要用DCGM或者同类的指标采集工具连续记录利用率、显存、温度、功耗。有一次我们排查训练变慢靠瞬时快照怎么看都正常拉出曲线才发现每过几分钟显存利用率就归零定位到是数据Loader在周期性做大量预处理。这种问题不用连续监控根本发现不了。3.3 模型注册表从实验到准入的关卡设计训练完成后模型不能直接部署中间应该有一道“准入闸门”。我的习惯是建立模型注册中心统一登记所有候选模型的信息并设计一个模型准入清单包含五项核心检查评估指标是否达到业务底线、评估过程是否可复现数据版本和代码版本是否锁定、是否已用回放数据做过验证、推理资源预估是否符合线上容量、以及负责人和上线说明是否填写完整。这个清单看起来行政化但它能挡住九成以上的“带病上线”。有一次我问一个团队他们的新模型为什么效果更好结果对方的实验记录里连数据版本都没锁这意味着连他自己都不知道这次训练的数据和上一次有什么区别。这种模型就算指标再好看我也不会放行。模型注册表的意义就是让“部署一个模型”从一个技术动作变成一个受控的工程决策是工程化成熟度的重要标志。4. 部署与服务化绕不开的推理架构设计4.1 在线推理、批量推理、流式推理三种形态怎么选模型部署最忌讳“一招鲜吃遍天”。不同业务场景对延迟、吞吐、成本的要求完全不同部署形态也应该不同。我把推理分为三种在线推理、批量推理、流式推理。在线推理面向实时请求要走REST或者RPC接口延迟要求在百毫秒级批量推理面向离线任务比如每日跑一次的预测报表关注的是吞吐和成本不要求实时流式推理则对接消息队列数据到达即处理适合事件驱动型的业务。选型判断上有一个很实用的问题列表业务方需要多快拿到结果如果答案是“点击之后立即”那就是在线如果是“明天早上看到”那就是批量如果希望“事件一发生就触发”那是流式。很多团队不分场景所有模型都包一个在线API其实特别浪费。举一个实际案例一个推荐团队的召回模型每天跑全量打分完全可以用批处理框架每天凌晨算好结果导出结果他们搭了一套在线服务天天跑定时请求既浪费了GPU还增加了在线链路故障面。分清形态很多工程复杂度自然就降下来了。4.2 服务化选型与镜像治理确定了推理形态后就要选推理框架。我的经验是从简单到复杂排队先不要上重量级框架。初期用FastAPI或者Flask封装模型推理函数跑通流程没问题在线服务成型后再考虑用Triton这类高性能推理服务器来做多模型管理、动态batch和GPU复用。选择中间有一些权衡点我整理成表格会更好理解方案适用阶段优点代价自封装FastAPI团队初期、模型量少简单直接、定制自由高性能场景吃力、多模型管理差开源推理框架Triton等模型量中等、需要GPU复用多模型并发、动态batch、GPU利用率高学习成本、配置复杂度自研RPC服务大规模专用场景极致性能和定制能力开发维护成本极高另外镜像治理是服务化里最容易被忽略的一环。模型镜像里应该把依赖、版本、启动脚本、健康检查都固化下来而不是每次部署靠手工跑命令。我们内部的要求是每个可部署的模型版本必须对应一个不可变镜像标签线上什么版本跑什么镜像账目必须清晰。有次排查一个线上模型预测全为0的问题最后发现是部署时依赖库版本变化导致预处理逻辑被跳过——如果能做到镜像版本与服务版本严格对应这类问题是可以直接规避的。4.3 灰度发布、回滚与模型版本切流模型上线和普通代码上线最大的区别在于“模型效果是概率性的”你不能指望全量上线后用一两天试错。所以灰度发布在模型场景几乎是必选。我的做法是支持按流量百分比切流先把5%的流量给新模型观察核心指标稳定后再逐步扩大直到100%。如果要更谨慎可以在切流前用“影子模式”跑一段时间也就是新模型和旧模型同时接收请求但新模型的结果不外发只做逻辑对比。回滚机制的侧重点也和代码不一样。代码回滚把进程切回旧版本就行但模型回滚要小心数据形态的变化如果线上生产服务期间特征逻辑已经在往前演进旧模型可能需要旧的特征代码才能正常工作。所以我的建议是模型和特征逻辑一起打包为一个“可回滚单元”回滚时不是单独rebuild模型镜像而是整个单元回到上一版本的组合。这个细节我们踩过一次坑才意识到希望你不要等着踩第二次。5. 模型监控与反馈闭环上线才算工程的开始5.1 数据漂移与模型漂移两个完全不同的问题模型上了线很多团队觉得大功告成实际上最难的环节才开始。模型的线上表现会随时间变化原因无非两类要分开监控。一类是数据漂移线上输入数据的分布和训练集分布产生了差异。比如销售预测模型训练时用的用户行为数据分布和现在的实际分布不一样了。监控数据漂移的指标我用得比较多的是PSI和KL散度同时关注核心特征的均值、方差和空值率变化。PSI值有一个经验参考区间小于0.1表示稳定0.1到0.25表示轻度漂移超过0.25就要拉响警报。另一类是概念漂移数据分布没变但“数据和标签之间的映射关系”变了。比如用户的购买倾向和同样的行为序列之间的关联变了这在业务规则调整、市场环境变化时特别常见。概念漂移更难监控通常需要结合业务指标的变化来综合判断。简单说数据漂移看输入特征概念漂移看预测结果和实际反馈的偏差两者监控口径完全不同不要混为一谈。5.2 反馈闭环从被动监控走向自动迭代监控只是发现问题的眼睛闭环才是解决问题的双手。一个完整的AI工程体系最终应该形成数据到模型的反馈环线上预测结果定期回流到存储通过标注或者隐式反馈生成新样本新样本进入数据管道形成训练集触发重新评估和重训候选模型通过注册准入后再灰度上线。这个闭环转起来之后AI系统才算有了自我迭代的雏形。这个闭环的落地难度不在机制设计而在中间环节的自动化程度。我见过很多团队卡在“样本回流”这一步线上日志存了一堆但没人写任务去抽取和转换成标注样本。所以我的建议是在搭建早期就明确“线上日志的消费方是谁”每个接口在出日志时就要带上request_id、模型版本、特征快照、预测结果这几个字段方便后续回溯。重训的触发条件我习惯用组合策略监控指标触发、定时周期性重训、业务方手动触发三管齐下。自动重训之后必须走准入清单不能直接替换线上模型否则一个坏数据批次就能让整个模型退化到失控。6. 大模型时代的AI工程变化6.1 从传统ML到LLM应用工程关注点有哪些转移大模型这一波起来后AI工程的重心发生了一些明显变化但底层的地基并没有变。传统ML工程的核心是把一个模型训练好、部署好而LLM应用工程包括RAG、Agent这些方向的核心变成了如何编排好一个外部大脑真正困难的不再是训练而是“如何用好这个模型”。具体来说工程关注点有三个明显变化。第一从模型训练转向上下文工程传统的特征工程变成了系统提示词的拼装、知识库切片的组织本质上仍是“给模型喂对材料”。第二从确定性评估转向概率性评估LLM的输出每次都不一样评测需要一个包含标准答案的评估集并且要反复测而不是单看一两次表现。第三从模型单体转向系统链路一个LLM应用往往由多个模块串联比如检索模块、大模型调用模块、外部工具模块整个链路的状态追踪与观测变得特别重要。6.2 RAG应用工程化的关键检索、缓存与追踪如果你做一个RAG应用AI工程的细节会集中在几个地方文档切片策略、检索质量、缓存设计、向量库运维和链路追踪。文档怎么切看起来是数据预处理的小问题实际对效果影响巨大。切得太碎语义被切断切得太整检索命中率下降。我的经验是按语义段落切再用重叠窗口保留上下文一套切法需要拿评测集去调不能拍脑袋。向量库的运维也是一个典型的AI工程课题向量维度的选择、索引类型、分片策略、以及数据更新时的重新索引策略都会直接影响查询延迟和召回效果。此外LLM调用是有成本的高频问题要做缓存缓存键必须考虑问题和上下文切片内容的哈希避免缓存不命中导致预算失控。链路追踪是所有RAG应用的必修课。用户问了一个问题系统走到了哪个分支检索命中了哪些片段大模型是否调用了工具最终答案用了哪几块知识碎片这些都得有日志可查。否则线上出了问题你连是“检索坏了”还是“模型答错了”都分不清。我给团队的要求是任何一个线上反馈都要能追踪到完整的链路LLM应用本质上就是一个有状态的分布式系统。6.3 Prompt、Agent与评估治理大模型工程的软基建大模型应用里Prompt和Agent配置也变成了需要工程化管理的资产。我见过团队把Prompt直接写在业务代码里改一句提示词就要重新发布服务这个做法长远看非常危险。更好的做法是把Prompt作为独立配置项来做版本管理配合评测集来验证每一次改动是否真的改善了效果而不是凭感觉调。Agent方向更需要治理。多个工具调用、多轮自主决策如果没有护栏和审计日志线上风险会迅速放大。我的建议是给Agent系统加三类基本约束权限边界哪些工具能调、哪些数据不能碰、决策日志每次工具调用都记录上下文和参数、人工确认点高影响动作必须人审。这些和传统AI工程的可观测性一脉相承只是作用对象从模型服务变成了智能体行为。回到“from scratch”这个话题我想说一些个人体会。AI工程体系和庞然大物的软件系统一样不可能一步到位也不应该一步到位。它是一点点“生长”出来的先解决数据可见再解决训练可复现然后搞定上线可回滚最后完善监控可迭代。每往前走一步系统都在变得更稳定、更自动而所有这些步骤加在一起才是“AI工程”这四个字的真正分量。那些一上来就追求完美架构的团队通常撑不到体系长成的那个阶段反而是愿意从小闭环开始、一步步扎扎实实补全的团队最后跑得更远。这个道理放在任何时候都不会过时。
