从零搭建AI工程能力这件事我前前后后折腾过三轮。第一轮是2019年前后那时候大家还在争论算法工程师要不要会写后端第二轮是2022年大模型爆发突然发现光会调模型根本不够用数据管道、推理服务、评测体系、成本控制每一样都能把人卡死第三轮就是现在我开始系统性地把AI工程当成一门独立的手艺来练而不是把它当成算法岗的附属技能。这篇内容就是我这三轮折腾下来对从零构建AI工程能力这件事的完整拆解——它适合刚入行想搞清楚学习路径的人也适合做了几年算法但总觉得自己只会跑实验的人更适合那些被临时拉来负责AI项目、却不知道从哪下手的工程同学。我先把结论摆前面AI工程不是算法工程的简单拼接它是一套围绕让模型在真实业务里稳定产生价值而组织起来的能力体系。你如果只盯着模型精度最后大概率会死在数据漂移、推理延迟、成本失控和评测缺失上。下面我按自己实际踩过的顺序把这条路径拆开讲。1. 先搞清楚AI工程到底在解决什么问题1.1 从跑通一个notebook到上线一个服务之间隔着什么很多人对AI工程的第一个误解是以为它等于把notebook里的代码搬到服务器上。我早期也这么想结果第一次上线就翻车本地跑得好好的模型到了线上推理延迟飙到800ms用户直接投诉。后来复盘才发现问题根本不在模型本身而在于我从来没考虑过批处理、并发、显存复用这些工程问题。从notebook到线上服务中间至少隔着五层东西数据层训练数据和线上数据的分布是否一致、特征层特征怎么算、怎么存、怎么保证线上线下一致、模型层模型怎么版本化、怎么回滚、服务层怎么部署、怎么扩缩容、怎么控延迟、评测层怎么知道线上效果变差了。这五层里任何一层没做好模型精度再高都是白搭。我见过太多团队模型指标刷到SOTA上线后业务指标纹丝不动最后查出来是特征穿越——训练时用了未来信息线上根本拿不到。这种问题不是算法能力能解决的是工程能力的问题。1.2 AI工程和传统后端工程的本质差异在哪有人会问那我把AI服务当成普通后端服务来做不就行了不行因为AI系统有几个传统后端没有的特性。第一是不确定性。传统后端接口输入A必然输出B你可以写单元测试断言。但AI模型同样的输入可能因为随机种子、硬件差异、批大小不同而输出不同结果。这意味着你的测试策略、监控策略都要重新设计。第二是数据依赖的强耦合。传统后端改代码才改行为AI系统改数据就改行为。你的训练数据一变模型行为就变哪怕代码一行没动。这就要求你把数据当成一等公民来管理而不是当成静态资源。第三是资源消耗的非线性。传统后端加一台机器性能就翻倍AI推理不是——显存、算力、批大小、序列长度之间的关系是非线性的调参空间巨大。你不懂这些成本能差出十倍。理解了这三点差异你才能明白为什么AI工程需要一套独立的方法论而不是照搬后端那套。1.3 一个合格AI工程师的能力地图长什么样我把AI工程能力拆成四块按优先级排能力模块核心内容优先级常见误区数据工程数据采集、清洗、版本化、特征管理最高以为清洗就是去重去空模型工程训练、微调、量化、蒸馏、版本管理高只关注精度不关注推理成本服务工程部署、扩缩容、延迟优化、容错高上线就不管了评测工程离线评测、在线AB、监控告警最高只看离线指标注意我把数据工程和评测工程都标了最高。这是有原因的我踩过的坑里80%的问题根源在数据剩下20%里有一半是因为没有评测体系导致问题发现太晚。模型工程和服务工程反而相对成熟有大量现成工具可用。2. 数据管道AI工程里最脏最累但最不能省的一环2.1 为什么说数据管道决定了AI项目的上限我有个很深的体会一个AI项目能走多远在数据管道搭好的那一刻就基本定了。模型可以换框架可以升级但数据管道一旦设计得烂后面全是补丁。举个真实例子。我之前参与一个文本分类项目初期数据量小大家直接用pandas读CSV训练跑得挺欢。后来数据涨到千万级pandas直接内存爆炸临时换成Spark结果发现之前的清洗逻辑里有一堆pandas特有的操作迁移成本极高。更坑的是清洗逻辑散落在十几个notebook里没人说得清最终训练数据到底经过了哪些处理。这就是典型的数据管道债。正确的做法是从第一天起就把数据处理写成可复现的管道每一步都有输入输出、有版本、有测试。听起来很重但比起后期返工这点投入太值了。2.2 数据版本化别再用文件名区分数据集了我早期管理数据版本的方式极其原始train_v1.csv、train_v2_fixed.csv、train_v2_fixed_real.csv。到后来自己都分不清哪个是哪个。这种土办法在小规模时能用一旦多人协作就彻底失控。数据版本化要解决三个问题哪个版本训练了哪个模型、两个版本之间差了什么、怎么回滚到旧版本。我现在的做法是用DVC或者类似的工具把数据和代码版本绑定。核心思路是数据本身不进git太大但数据的哈希值和生成脚本进git。这样你checkout任何一个commit都能复现出当时的数据。具体操作上我会给每个数据集打三个标签来源从哪来的、处理链经过了哪些步骤、用途训练/验证/测试。这三个标签缺一不可。我见过有人只标来源不标处理链结果两个数据集看起来一样实际一个做了去重一个没做训练出来的模型效果差一大截。2.3 特征一致性线上线下不一致是AI事故的头号杀手特征一致性这个问题我愿称之为AI工程第一大坑。它的本质是训练时你用的特征和线上推理时能拿到的特征必须完全一致。听起来是废话但实际做起来处处是雷。最常见的雷是时间穿越。比如你训练一个预测用户是否会购买的特征用了用户过去30天购买次数。训练时你从历史数据里算这个特征没问题。但线上推理时你算的是截至当前时刻过去30天如果特征计算逻辑里有个时间窗口没对齐就会引入未来信息。模型离线AUC 0.9上线0.6八成是这个原因。第二个雷是计算逻辑分叉。训练时用Python算特征线上用Java算两边实现不一致。我见过一个团队Python里用的是四舍五入Java里用的是银行家舍入就这一个差异导致线上特征分布偏移模型效果掉了一截。解决这个问题的标准做法是特征平台把特征计算逻辑统一成一份代码离线和线上都调这一份。Feast、Tecton这类工具就是干这个的。如果团队小用不起特征平台至少要做到特征计算逻辑只有一份实现离线用批处理跑线上用同样的逻辑实时算并且定期做一致性校验。提示上线前一定要做一次离线重放测试——把线上最近一周的真实请求日志拿过来用线上特征计算逻辑重新算一遍特征喂给模型看输出和线上实际输出是否一致。这一步能拦下大部分特征一致性问题。2.4 数据质量监控别等模型崩了才发现数据脏了数据质量监控这件事很多团队是等出了事故才补的。我的建议是从项目第一天就上。监控什么我一般盯四个指标空值率某个字段突然大量为空说明上游出问题了、分布漂移特征分布和训练时比偏移了多少、取值范围有没有超出预期的异常值、数据量突然暴涨或暴跌都是信号。分布漂移的监控尤其重要。我一般用PSI群体稳定性指标或者KL散度来衡量。PSI小于0.1算稳定0.1到0.25算轻微漂移超过0.25就要告警了。这个阈值不是绝对的要根据业务调整但有个量化标准总比拍脑袋强。监控告警的落地方式简单点可以用定时任务跑统计脚本结果写进监控系统复杂点可以上专门的数据质量平台。关键不是工具多高级而是有人看告警、有人处理告警。我见过太多团队监控搭得漂漂亮亮告警发到群里没人理等于没做。3. 模型工程从能训出来到能管起来3.1 训练可复现随机种子只是冰山一角为什么同样的代码我跑出来和你跑出来结果不一样这个问题困扰过每一个AI工程师。很多人以为设个随机种子就解决了实际上远不止。影响训练可复现性的因素至少有这些随机种子Python、NumPy、框架各自的、硬件不同GPU型号浮点运算有差异、并行策略数据并行、模型并行的切分方式、算子实现cuDNN不同版本行为不同、数据加载顺序多worker时顺序可能乱。我的做法是能固定的全固定不能固定的记录下来。种子全部设死框架版本、CUDA版本、驱动版本全部锁死数据加载用固定顺序。如果用了分布式训练把并行配置也记下来。这样即使不能100%复现至少能知道差异来自哪里。更进一步我会把每次训练的完整配置存成一个manifest文件包括代码commit、数据版本、超参数、环境信息。这个文件跟着模型一起存。半年后回头看能清楚知道这个模型是怎么来的。3.2 模型版本管理不只是存个权重文件模型版本管理很多人理解成把pth文件存起来。这远远不够。一个完整的模型版本应该包含权重文件、训练配置、数据版本、评测结果、依赖环境、以及这个模型对应的推理代码。为什么推理代码也要管因为模型结构和推理逻辑是绑定的。你换了个模型结构推理代码不改加载就报错。我见过有人只存权重不存代码结果要重新上线旧模型时发现代码已经改得面目全非根本跑不起来。我现在的做法是用模型注册表Model Registry来管。MLflow、Weights Biases这类工具都提供这个功能。每个模型版本有唯一ID关联所有元信息支持阶段标记staging、production、archived。上线时不是把某个文件拷过去而是把某个版本从staging提升到production。回滚也是同理一键切回旧版本。3.3 量化与蒸馏让模型跑得动、跑得起的必修课模型训出来只是第一步能不能跑得动、跑得起才是关键。我见过太多项目模型精度很漂亮但推理成本高到业务方直接否掉。量化和蒸馏是两个最常用的压缩手段。量化是把模型权重从FP32降到INT8甚至INT4显存占用和推理延迟都能大幅下降。蒸馏是用大模型教小模型让小模型达到接近大模型的效果。量化的坑在于精度损失不可控。不是所有模型量化后都能保持精度有些层对量化特别敏感。我的经验是先做训练后量化PTQ看精度掉多少如果掉太多就做量化感知训练QAT在训练时模拟量化误差。QAT效果更好但成本更高要权衡。蒸馏的坑在于教师模型的选择。不是越大越好教师模型和学生模型的能力差距太大时蒸馏效果反而差。我一般选比学生模型大2到3倍的教师模型效果比较稳。另外蒸馏不只是学logits中间层特征、注意力分布都可以学具体用哪种要看任务。压缩手段典型压缩比精度损失适用场景FP162x极小几乎所有场景INT8 PTQ4x小到中对延迟敏感、精度要求不极端INT8 QAT4x小精度要求高INT48x中到大边缘设备、极致成本控制蒸馏视学生模型而定可控需要小模型但精度要求高3.4 微调策略全量、LoRA还是Prompt怎么选现在微调大模型的选择比几年前多太多了。全量微调、LoRA、QLoRA、Prompt Tuning、Prefix Tuning每种都有适用场景。我的选择逻辑是这样的数据量少几千条以内、任务简单优先Prompt Engineering不行再上LoRA。数据量中等几万到几十万、任务需要模型学新知识用LoRA或QLoRA。数据量很大百万级以上、任务和预训练分布差异大才考虑全量微调。LoRA之所以成为主流是因为它在效果和成本之间取得了很好的平衡。它只训练一小部分参数显存占用低训练快而且可以多个LoRA适配器共享一个基座模型切换成本极低。我现在的项目里80%的微调需求都用LoRA解决。但LoRA也有坑。它的秩rank选择很关键太小了学不动太大了容易过拟合。我一般从8开始试效果不够就加到16、32。另外LoRA对学习率比全量微调更敏感需要单独调。4. 服务工程让模型真正扛住线上流量4.1 推理服务的三种形态批处理、实时、流式推理服务不是只有一种形态。根据业务需求至少要区分三种批处理离线跑对延迟不敏感追求吞吐。比如每天凌晨跑一遍全量用户打分。这种场景优化重点是吞吐量可以用大batch、多卡并行。实时在线请求延迟敏感追求响应速度。比如用户点击时的实时推荐。这种场景优化重点是P99延迟要用小batch、动态批处理、模型量化。流式边生成边返回比如对话生成。这种场景优化重点是首token延迟和生成速度要用KV Cache、投机采样等技术。我见过有人把批处理的方案直接搬到实时场景结果延迟高得没法用。这三种形态的优化思路完全不同选型时一定要先搞清楚业务需求。4.2 延迟优化的几个实操手段延迟优化是AI服务工程的核心技能。我按投入产出比排个序第一模型量化。前面说过INT8量化通常能带来2到4倍的延迟下降精度损失可控。这是性价比最高的手段。第二动态批处理。把短时间内到达的多个请求合并成一个batch推理能大幅提升GPU利用率。vLLM、Triton这些框架都支持。但要注意batch太大会增加单个请求的等待时间要设个超时上限。第三KV Cache复用。对生成式模型如果多个请求共享相同的prompt前缀可以复用KV Cache。这在多轮对话场景特别有用。第四算子融合和编译优化。用TensorRT、ONNX Runtime这类工具把模型图优化一遍能去掉不少冗余计算。这个需要一些底层知识但收益可观。第五硬件选型。不同GPU对不同模型的适配度不一样有时候换个卡延迟就降一半。这个要实测不能只看参数。注意延迟优化一定要有基线。优化前先测清楚当前的P50、P95、P99延迟优化后再测一遍用数据说话。我见过有人凭感觉优化改了一堆东西结果延迟没降反升。4.3 容错与降级模型挂了业务不能挂AI服务比传统服务更容易出问题模型加载失败、显存溢出、推理超时、输入格式异常每一种都可能让服务挂掉。所以容错和降级设计是必须的。我的做法是三层防护第一层输入校验。请求进来先校验格式、长度、取值范围不合法的直接拒绝不要让它进到模型里。这一步能拦掉大部分异常。第二层超时和熔断。给推理设个超时时间超了就返回降级结果。如果连续多次超时触发熔断直接走降级逻辑不再调模型。第三层降级策略。模型不可用时返回什么可以是缓存的上次结果、可以是规则引擎的结果、可以是默认值。关键是业务不能因为模型挂了就完全不可用。我经历过一次事故模型服务因为显存泄漏挂了但没有任何降级逻辑整个推荐模块直接空白。后来加了降级模型挂了就返回热门榜单虽然效果差些但业务至少能跑。4.4 成本控制AI项目最容易失控的地方AI项目的成本控制很多人是等账单来了才重视。我的建议是从第一天就把成本当成一等指标来监控。成本主要来自三块训练成本、推理成本、存储成本。训练成本相对可控跑一次就完了。推理成本是大头尤其是流量大的场景。存储成本容易被忽略但数据、模型、日志累积起来也很可观。控制推理成本的手段模型压缩前面说过、动态批处理提升GPU利用率、自动扩缩容低峰期缩容、缓存相同请求直接返回缓存结果。我一般会算一个单次推理成本指标每次优化后看这个指标有没有下降。还有一个容易被忽略的点GPU利用率。很多团队的GPU利用率长期在20%以下等于80%的钱白花了。提升利用率的方法包括多模型共享GPU、混部不同任务、用MPS多进程服务等。这个需要一些运维知识但收益很大。5. 评测工程没有评测就没有AI工程5.1 离线评测的陷阱指标好看不等于效果好离线评测是AI工程里最容易自欺欺人的环节。我见过太多项目离线指标刷得很高上线后业务方说没感觉。问题出在离线评测和真实业务目标脱节。常见的陷阱有几个。指标选错分类任务只看准确率但业务关心的是召回率因为漏判的代价远大于误判。测试集泄漏测试集和训练集有重叠指标虚高。分布不一致测试集是从训练数据里随机切的但线上数据分布完全不同。我的做法是离线评测一定要用和线上同分布的测试集而且这个测试集要定期更新。指标选择上先和业务方对齐什么算好再选对应的指标。如果业务目标复杂就构造一个综合指标把多个维度加权起来。5.2 在线AB测试唯一可信的效果验证方式离线评测再严谨也只是近似。真正可信的只有在线AB测试。AB测试的核心是把流量随机分成两组一组用旧模型一组用新模型看业务指标有没有显著差异。AB测试的坑主要在统计显著性上。很多人看到新模型指标高一点就急着全量结果发现是随机波动。正确的做法是先算清楚需要多少样本量才能达到统计显著跑够样本量再看结果。样本量不够就下结论等于赌博。另一个坑是指标选择。AB测试不能只看模型指标要看业务指标。模型AUC涨了0.01但用户点击率没变那这个涨就没意义。我一般会同时看模型指标和业务指标两者都正向才推全量。5.3 线上监控模型上线只是开始模型上线不是终点是起点。线上监控要盯三类指标服务指标QPS、延迟、错误率、GPU利用率。这些是基础保证服务本身健康。模型指标输入分布、输出分布、置信度分布。这些能帮你发现数据漂移和模型退化。比如输入特征分布突然偏移说明上游数据变了模型可能不准了。业务指标点击率、转化率、留存率。这些是最终目标但变化慢需要长期观察。监控的告警阈值要动态调整。我一般用历史数据的均值和标准差来定阈值比如超过均值3个标准差就告警。固定阈值容易误报或漏报。5.4 模型退化的排查链路模型退化是线上最常见的问题。我总结了一套排查链路按顺序走第一步确认是不是真退化。先看业务指标再看模型指标排除流量波动、统计口径变化等干扰。第二步看输入分布。输入特征分布有没有漂移如果有是上游数据变了还是特征计算逻辑变了第三步看输出分布。模型输出的分布有没有变化置信度是不是普遍降低了第四步抽样人工检查。拿一批bad case人工看是模型错了还是标注错了还是业务定义变了第五步对比新旧模型。如果最近上了新模型先回滚看看问题是否消失。这套链路能覆盖大部分退化场景。关键是每一步都要有数据支撑不能凭感觉。6. 从零构建AI工程能力的实操路径6.1 第一个月把数据管道和服务框架搭起来如果你现在要从零开始我建议第一个月只做两件事搭数据管道、搭服务框架。数据管道不用多高级能跑通原始数据→清洗→特征→训练集这条链路就行。关键是每一步可复现、有版本、有测试。工具上小规模用pandas加DVC大规模用Spark加Airflow。服务框架也不用多复杂能跑通加载模型→接收请求→返回结果就行。关键是接口定义清晰、有超时和降级、有基础监控。工具上Python用FastAPI或TritonJava用Spring Boot加ONNX Runtime。这两件事搭好你就有了一个能跑通的最小闭环。后面所有优化都是在这个闭环上迭代。6.2 第二到三个月补评测体系和监控有了闭环之后第二到三个月重点补评测和监控。离线评测要有固定的测试集和评测脚本在线要有AB测试框架线上要有监控告警。这一步最容易被跳过因为模型能跑看起来就够了。但没有评测和监控你根本不知道模型什么时候变差了等业务方反馈时已经晚了。我一般会在这个阶段建立三个例行机制每周跑一次离线评测、每次上线跑AB测试、每天看一次监控大盘。这三个机制建立起来AI项目才算真正进入工程化。6.3 半年之后优化成本和迭代效率半年之后基础都稳了重点转向成本和效率。成本优化前面说过效率优化主要是缩短想法→上线的周期。缩短迭代周期的手段包括自动化训练管道提交代码自动触发训练、自动化评测训练完自动跑评测、自动化部署评测通过自动上线到staging。这一套下来迭代周期能从几周缩短到几天。我现在的项目从改代码到上线staging全流程自动化半天就能完成。这个效率带来的最大好处是可以快速试错。以前试一个想法要一周现在一天能试好几个找到好方案的概率大大提升。6.4 那些没人告诉你但很重要的经验最后分享几条我踩坑踩出来的经验都是文档里不会写的。经验一模型不是越新越好。新模型往往有未知的坑线上稳定性可能不如老模型。我一般会等新模型出来两三个月社区踩过坑了再上。经验二简单方案往往更稳。我见过太多团队为了追求先进上了复杂的架构结果维护成本高、故障率高。能用规则解决的别上模型能用小模型解决的别上大模型。经验三文档比代码重要。AI项目人员流动快代码写得再漂亮没人看得懂等于零。我要求每个模块必须有README写清楚输入输出、依赖、常见问题。经验四留一手降级方案。任何AI服务都要有降级方案模型挂了业务不能挂。这个前面说过但值得再强调一遍。经验五定期做故障演练。主动把模型停掉、把数据源断掉看系统能不能扛住。这种演练能发现很多平时发现不了的问题。AI工程这条路说难也难说简单也简单。难在细节多、坑多简单在只要按部就班把每一层搭好系统自然就稳了。我最大的体会是不要追求一步到位先跑通最小闭环再逐步优化。那些一上来就想搭完美架构的往往连第一步都迈不出去。
从零构建AI工程能力：数据、模型、服务与评测全链路拆解
从零搭建AI工程能力这件事我前前后后折腾过三轮。第一轮是2019年前后那时候大家还在争论算法工程师要不要会写后端第二轮是2022年大模型爆发突然发现光会调模型根本不够用数据管道、推理服务、评测体系、成本控制每一样都能把人卡死第三轮就是现在我开始系统性地把AI工程当成一门独立的手艺来练而不是把它当成算法岗的附属技能。这篇内容就是我这三轮折腾下来对从零构建AI工程能力这件事的完整拆解——它适合刚入行想搞清楚学习路径的人也适合做了几年算法但总觉得自己只会跑实验的人更适合那些被临时拉来负责AI项目、却不知道从哪下手的工程同学。我先把结论摆前面AI工程不是算法工程的简单拼接它是一套围绕让模型在真实业务里稳定产生价值而组织起来的能力体系。你如果只盯着模型精度最后大概率会死在数据漂移、推理延迟、成本失控和评测缺失上。下面我按自己实际踩过的顺序把这条路径拆开讲。1. 先搞清楚AI工程到底在解决什么问题1.1 从跑通一个notebook到上线一个服务之间隔着什么很多人对AI工程的第一个误解是以为它等于把notebook里的代码搬到服务器上。我早期也这么想结果第一次上线就翻车本地跑得好好的模型到了线上推理延迟飙到800ms用户直接投诉。后来复盘才发现问题根本不在模型本身而在于我从来没考虑过批处理、并发、显存复用这些工程问题。从notebook到线上服务中间至少隔着五层东西数据层训练数据和线上数据的分布是否一致、特征层特征怎么算、怎么存、怎么保证线上线下一致、模型层模型怎么版本化、怎么回滚、服务层怎么部署、怎么扩缩容、怎么控延迟、评测层怎么知道线上效果变差了。这五层里任何一层没做好模型精度再高都是白搭。我见过太多团队模型指标刷到SOTA上线后业务指标纹丝不动最后查出来是特征穿越——训练时用了未来信息线上根本拿不到。这种问题不是算法能力能解决的是工程能力的问题。1.2 AI工程和传统后端工程的本质差异在哪有人会问那我把AI服务当成普通后端服务来做不就行了不行因为AI系统有几个传统后端没有的特性。第一是不确定性。传统后端接口输入A必然输出B你可以写单元测试断言。但AI模型同样的输入可能因为随机种子、硬件差异、批大小不同而输出不同结果。这意味着你的测试策略、监控策略都要重新设计。第二是数据依赖的强耦合。传统后端改代码才改行为AI系统改数据就改行为。你的训练数据一变模型行为就变哪怕代码一行没动。这就要求你把数据当成一等公民来管理而不是当成静态资源。第三是资源消耗的非线性。传统后端加一台机器性能就翻倍AI推理不是——显存、算力、批大小、序列长度之间的关系是非线性的调参空间巨大。你不懂这些成本能差出十倍。理解了这三点差异你才能明白为什么AI工程需要一套独立的方法论而不是照搬后端那套。1.3 一个合格AI工程师的能力地图长什么样我把AI工程能力拆成四块按优先级排能力模块核心内容优先级常见误区数据工程数据采集、清洗、版本化、特征管理最高以为清洗就是去重去空模型工程训练、微调、量化、蒸馏、版本管理高只关注精度不关注推理成本服务工程部署、扩缩容、延迟优化、容错高上线就不管了评测工程离线评测、在线AB、监控告警最高只看离线指标注意我把数据工程和评测工程都标了最高。这是有原因的我踩过的坑里80%的问题根源在数据剩下20%里有一半是因为没有评测体系导致问题发现太晚。模型工程和服务工程反而相对成熟有大量现成工具可用。2. 数据管道AI工程里最脏最累但最不能省的一环2.1 为什么说数据管道决定了AI项目的上限我有个很深的体会一个AI项目能走多远在数据管道搭好的那一刻就基本定了。模型可以换框架可以升级但数据管道一旦设计得烂后面全是补丁。举个真实例子。我之前参与一个文本分类项目初期数据量小大家直接用pandas读CSV训练跑得挺欢。后来数据涨到千万级pandas直接内存爆炸临时换成Spark结果发现之前的清洗逻辑里有一堆pandas特有的操作迁移成本极高。更坑的是清洗逻辑散落在十几个notebook里没人说得清最终训练数据到底经过了哪些处理。这就是典型的数据管道债。正确的做法是从第一天起就把数据处理写成可复现的管道每一步都有输入输出、有版本、有测试。听起来很重但比起后期返工这点投入太值了。2.2 数据版本化别再用文件名区分数据集了我早期管理数据版本的方式极其原始train_v1.csv、train_v2_fixed.csv、train_v2_fixed_real.csv。到后来自己都分不清哪个是哪个。这种土办法在小规模时能用一旦多人协作就彻底失控。数据版本化要解决三个问题哪个版本训练了哪个模型、两个版本之间差了什么、怎么回滚到旧版本。我现在的做法是用DVC或者类似的工具把数据和代码版本绑定。核心思路是数据本身不进git太大但数据的哈希值和生成脚本进git。这样你checkout任何一个commit都能复现出当时的数据。具体操作上我会给每个数据集打三个标签来源从哪来的、处理链经过了哪些步骤、用途训练/验证/测试。这三个标签缺一不可。我见过有人只标来源不标处理链结果两个数据集看起来一样实际一个做了去重一个没做训练出来的模型效果差一大截。2.3 特征一致性线上线下不一致是AI事故的头号杀手特征一致性这个问题我愿称之为AI工程第一大坑。它的本质是训练时你用的特征和线上推理时能拿到的特征必须完全一致。听起来是废话但实际做起来处处是雷。最常见的雷是时间穿越。比如你训练一个预测用户是否会购买的特征用了用户过去30天购买次数。训练时你从历史数据里算这个特征没问题。但线上推理时你算的是截至当前时刻过去30天如果特征计算逻辑里有个时间窗口没对齐就会引入未来信息。模型离线AUC 0.9上线0.6八成是这个原因。第二个雷是计算逻辑分叉。训练时用Python算特征线上用Java算两边实现不一致。我见过一个团队Python里用的是四舍五入Java里用的是银行家舍入就这一个差异导致线上特征分布偏移模型效果掉了一截。解决这个问题的标准做法是特征平台把特征计算逻辑统一成一份代码离线和线上都调这一份。Feast、Tecton这类工具就是干这个的。如果团队小用不起特征平台至少要做到特征计算逻辑只有一份实现离线用批处理跑线上用同样的逻辑实时算并且定期做一致性校验。提示上线前一定要做一次离线重放测试——把线上最近一周的真实请求日志拿过来用线上特征计算逻辑重新算一遍特征喂给模型看输出和线上实际输出是否一致。这一步能拦下大部分特征一致性问题。2.4 数据质量监控别等模型崩了才发现数据脏了数据质量监控这件事很多团队是等出了事故才补的。我的建议是从项目第一天就上。监控什么我一般盯四个指标空值率某个字段突然大量为空说明上游出问题了、分布漂移特征分布和训练时比偏移了多少、取值范围有没有超出预期的异常值、数据量突然暴涨或暴跌都是信号。分布漂移的监控尤其重要。我一般用PSI群体稳定性指标或者KL散度来衡量。PSI小于0.1算稳定0.1到0.25算轻微漂移超过0.25就要告警了。这个阈值不是绝对的要根据业务调整但有个量化标准总比拍脑袋强。监控告警的落地方式简单点可以用定时任务跑统计脚本结果写进监控系统复杂点可以上专门的数据质量平台。关键不是工具多高级而是有人看告警、有人处理告警。我见过太多团队监控搭得漂漂亮亮告警发到群里没人理等于没做。3. 模型工程从能训出来到能管起来3.1 训练可复现随机种子只是冰山一角为什么同样的代码我跑出来和你跑出来结果不一样这个问题困扰过每一个AI工程师。很多人以为设个随机种子就解决了实际上远不止。影响训练可复现性的因素至少有这些随机种子Python、NumPy、框架各自的、硬件不同GPU型号浮点运算有差异、并行策略数据并行、模型并行的切分方式、算子实现cuDNN不同版本行为不同、数据加载顺序多worker时顺序可能乱。我的做法是能固定的全固定不能固定的记录下来。种子全部设死框架版本、CUDA版本、驱动版本全部锁死数据加载用固定顺序。如果用了分布式训练把并行配置也记下来。这样即使不能100%复现至少能知道差异来自哪里。更进一步我会把每次训练的完整配置存成一个manifest文件包括代码commit、数据版本、超参数、环境信息。这个文件跟着模型一起存。半年后回头看能清楚知道这个模型是怎么来的。3.2 模型版本管理不只是存个权重文件模型版本管理很多人理解成把pth文件存起来。这远远不够。一个完整的模型版本应该包含权重文件、训练配置、数据版本、评测结果、依赖环境、以及这个模型对应的推理代码。为什么推理代码也要管因为模型结构和推理逻辑是绑定的。你换了个模型结构推理代码不改加载就报错。我见过有人只存权重不存代码结果要重新上线旧模型时发现代码已经改得面目全非根本跑不起来。我现在的做法是用模型注册表Model Registry来管。MLflow、Weights Biases这类工具都提供这个功能。每个模型版本有唯一ID关联所有元信息支持阶段标记staging、production、archived。上线时不是把某个文件拷过去而是把某个版本从staging提升到production。回滚也是同理一键切回旧版本。3.3 量化与蒸馏让模型跑得动、跑得起的必修课模型训出来只是第一步能不能跑得动、跑得起才是关键。我见过太多项目模型精度很漂亮但推理成本高到业务方直接否掉。量化和蒸馏是两个最常用的压缩手段。量化是把模型权重从FP32降到INT8甚至INT4显存占用和推理延迟都能大幅下降。蒸馏是用大模型教小模型让小模型达到接近大模型的效果。量化的坑在于精度损失不可控。不是所有模型量化后都能保持精度有些层对量化特别敏感。我的经验是先做训练后量化PTQ看精度掉多少如果掉太多就做量化感知训练QAT在训练时模拟量化误差。QAT效果更好但成本更高要权衡。蒸馏的坑在于教师模型的选择。不是越大越好教师模型和学生模型的能力差距太大时蒸馏效果反而差。我一般选比学生模型大2到3倍的教师模型效果比较稳。另外蒸馏不只是学logits中间层特征、注意力分布都可以学具体用哪种要看任务。压缩手段典型压缩比精度损失适用场景FP162x极小几乎所有场景INT8 PTQ4x小到中对延迟敏感、精度要求不极端INT8 QAT4x小精度要求高INT48x中到大边缘设备、极致成本控制蒸馏视学生模型而定可控需要小模型但精度要求高3.4 微调策略全量、LoRA还是Prompt怎么选现在微调大模型的选择比几年前多太多了。全量微调、LoRA、QLoRA、Prompt Tuning、Prefix Tuning每种都有适用场景。我的选择逻辑是这样的数据量少几千条以内、任务简单优先Prompt Engineering不行再上LoRA。数据量中等几万到几十万、任务需要模型学新知识用LoRA或QLoRA。数据量很大百万级以上、任务和预训练分布差异大才考虑全量微调。LoRA之所以成为主流是因为它在效果和成本之间取得了很好的平衡。它只训练一小部分参数显存占用低训练快而且可以多个LoRA适配器共享一个基座模型切换成本极低。我现在的项目里80%的微调需求都用LoRA解决。但LoRA也有坑。它的秩rank选择很关键太小了学不动太大了容易过拟合。我一般从8开始试效果不够就加到16、32。另外LoRA对学习率比全量微调更敏感需要单独调。4. 服务工程让模型真正扛住线上流量4.1 推理服务的三种形态批处理、实时、流式推理服务不是只有一种形态。根据业务需求至少要区分三种批处理离线跑对延迟不敏感追求吞吐。比如每天凌晨跑一遍全量用户打分。这种场景优化重点是吞吐量可以用大batch、多卡并行。实时在线请求延迟敏感追求响应速度。比如用户点击时的实时推荐。这种场景优化重点是P99延迟要用小batch、动态批处理、模型量化。流式边生成边返回比如对话生成。这种场景优化重点是首token延迟和生成速度要用KV Cache、投机采样等技术。我见过有人把批处理的方案直接搬到实时场景结果延迟高得没法用。这三种形态的优化思路完全不同选型时一定要先搞清楚业务需求。4.2 延迟优化的几个实操手段延迟优化是AI服务工程的核心技能。我按投入产出比排个序第一模型量化。前面说过INT8量化通常能带来2到4倍的延迟下降精度损失可控。这是性价比最高的手段。第二动态批处理。把短时间内到达的多个请求合并成一个batch推理能大幅提升GPU利用率。vLLM、Triton这些框架都支持。但要注意batch太大会增加单个请求的等待时间要设个超时上限。第三KV Cache复用。对生成式模型如果多个请求共享相同的prompt前缀可以复用KV Cache。这在多轮对话场景特别有用。第四算子融合和编译优化。用TensorRT、ONNX Runtime这类工具把模型图优化一遍能去掉不少冗余计算。这个需要一些底层知识但收益可观。第五硬件选型。不同GPU对不同模型的适配度不一样有时候换个卡延迟就降一半。这个要实测不能只看参数。注意延迟优化一定要有基线。优化前先测清楚当前的P50、P95、P99延迟优化后再测一遍用数据说话。我见过有人凭感觉优化改了一堆东西结果延迟没降反升。4.3 容错与降级模型挂了业务不能挂AI服务比传统服务更容易出问题模型加载失败、显存溢出、推理超时、输入格式异常每一种都可能让服务挂掉。所以容错和降级设计是必须的。我的做法是三层防护第一层输入校验。请求进来先校验格式、长度、取值范围不合法的直接拒绝不要让它进到模型里。这一步能拦掉大部分异常。第二层超时和熔断。给推理设个超时时间超了就返回降级结果。如果连续多次超时触发熔断直接走降级逻辑不再调模型。第三层降级策略。模型不可用时返回什么可以是缓存的上次结果、可以是规则引擎的结果、可以是默认值。关键是业务不能因为模型挂了就完全不可用。我经历过一次事故模型服务因为显存泄漏挂了但没有任何降级逻辑整个推荐模块直接空白。后来加了降级模型挂了就返回热门榜单虽然效果差些但业务至少能跑。4.4 成本控制AI项目最容易失控的地方AI项目的成本控制很多人是等账单来了才重视。我的建议是从第一天就把成本当成一等指标来监控。成本主要来自三块训练成本、推理成本、存储成本。训练成本相对可控跑一次就完了。推理成本是大头尤其是流量大的场景。存储成本容易被忽略但数据、模型、日志累积起来也很可观。控制推理成本的手段模型压缩前面说过、动态批处理提升GPU利用率、自动扩缩容低峰期缩容、缓存相同请求直接返回缓存结果。我一般会算一个单次推理成本指标每次优化后看这个指标有没有下降。还有一个容易被忽略的点GPU利用率。很多团队的GPU利用率长期在20%以下等于80%的钱白花了。提升利用率的方法包括多模型共享GPU、混部不同任务、用MPS多进程服务等。这个需要一些运维知识但收益很大。5. 评测工程没有评测就没有AI工程5.1 离线评测的陷阱指标好看不等于效果好离线评测是AI工程里最容易自欺欺人的环节。我见过太多项目离线指标刷得很高上线后业务方说没感觉。问题出在离线评测和真实业务目标脱节。常见的陷阱有几个。指标选错分类任务只看准确率但业务关心的是召回率因为漏判的代价远大于误判。测试集泄漏测试集和训练集有重叠指标虚高。分布不一致测试集是从训练数据里随机切的但线上数据分布完全不同。我的做法是离线评测一定要用和线上同分布的测试集而且这个测试集要定期更新。指标选择上先和业务方对齐什么算好再选对应的指标。如果业务目标复杂就构造一个综合指标把多个维度加权起来。5.2 在线AB测试唯一可信的效果验证方式离线评测再严谨也只是近似。真正可信的只有在线AB测试。AB测试的核心是把流量随机分成两组一组用旧模型一组用新模型看业务指标有没有显著差异。AB测试的坑主要在统计显著性上。很多人看到新模型指标高一点就急着全量结果发现是随机波动。正确的做法是先算清楚需要多少样本量才能达到统计显著跑够样本量再看结果。样本量不够就下结论等于赌博。另一个坑是指标选择。AB测试不能只看模型指标要看业务指标。模型AUC涨了0.01但用户点击率没变那这个涨就没意义。我一般会同时看模型指标和业务指标两者都正向才推全量。5.3 线上监控模型上线只是开始模型上线不是终点是起点。线上监控要盯三类指标服务指标QPS、延迟、错误率、GPU利用率。这些是基础保证服务本身健康。模型指标输入分布、输出分布、置信度分布。这些能帮你发现数据漂移和模型退化。比如输入特征分布突然偏移说明上游数据变了模型可能不准了。业务指标点击率、转化率、留存率。这些是最终目标但变化慢需要长期观察。监控的告警阈值要动态调整。我一般用历史数据的均值和标准差来定阈值比如超过均值3个标准差就告警。固定阈值容易误报或漏报。5.4 模型退化的排查链路模型退化是线上最常见的问题。我总结了一套排查链路按顺序走第一步确认是不是真退化。先看业务指标再看模型指标排除流量波动、统计口径变化等干扰。第二步看输入分布。输入特征分布有没有漂移如果有是上游数据变了还是特征计算逻辑变了第三步看输出分布。模型输出的分布有没有变化置信度是不是普遍降低了第四步抽样人工检查。拿一批bad case人工看是模型错了还是标注错了还是业务定义变了第五步对比新旧模型。如果最近上了新模型先回滚看看问题是否消失。这套链路能覆盖大部分退化场景。关键是每一步都要有数据支撑不能凭感觉。6. 从零构建AI工程能力的实操路径6.1 第一个月把数据管道和服务框架搭起来如果你现在要从零开始我建议第一个月只做两件事搭数据管道、搭服务框架。数据管道不用多高级能跑通原始数据→清洗→特征→训练集这条链路就行。关键是每一步可复现、有版本、有测试。工具上小规模用pandas加DVC大规模用Spark加Airflow。服务框架也不用多复杂能跑通加载模型→接收请求→返回结果就行。关键是接口定义清晰、有超时和降级、有基础监控。工具上Python用FastAPI或TritonJava用Spring Boot加ONNX Runtime。这两件事搭好你就有了一个能跑通的最小闭环。后面所有优化都是在这个闭环上迭代。6.2 第二到三个月补评测体系和监控有了闭环之后第二到三个月重点补评测和监控。离线评测要有固定的测试集和评测脚本在线要有AB测试框架线上要有监控告警。这一步最容易被跳过因为模型能跑看起来就够了。但没有评测和监控你根本不知道模型什么时候变差了等业务方反馈时已经晚了。我一般会在这个阶段建立三个例行机制每周跑一次离线评测、每次上线跑AB测试、每天看一次监控大盘。这三个机制建立起来AI项目才算真正进入工程化。6.3 半年之后优化成本和迭代效率半年之后基础都稳了重点转向成本和效率。成本优化前面说过效率优化主要是缩短想法→上线的周期。缩短迭代周期的手段包括自动化训练管道提交代码自动触发训练、自动化评测训练完自动跑评测、自动化部署评测通过自动上线到staging。这一套下来迭代周期能从几周缩短到几天。我现在的项目从改代码到上线staging全流程自动化半天就能完成。这个效率带来的最大好处是可以快速试错。以前试一个想法要一周现在一天能试好几个找到好方案的概率大大提升。6.4 那些没人告诉你但很重要的经验最后分享几条我踩坑踩出来的经验都是文档里不会写的。经验一模型不是越新越好。新模型往往有未知的坑线上稳定性可能不如老模型。我一般会等新模型出来两三个月社区踩过坑了再上。经验二简单方案往往更稳。我见过太多团队为了追求先进上了复杂的架构结果维护成本高、故障率高。能用规则解决的别上模型能用小模型解决的别上大模型。经验三文档比代码重要。AI项目人员流动快代码写得再漂亮没人看得懂等于零。我要求每个模块必须有README写清楚输入输出、依赖、常见问题。经验四留一手降级方案。任何AI服务都要有降级方案模型挂了业务不能挂。这个前面说过但值得再强调一遍。经验五定期做故障演练。主动把模型停掉、把数据源断掉看系统能不能扛住。这种演练能发现很多平时发现不了的问题。AI工程这条路说难也难说简单也简单。难在细节多、坑多简单在只要按部就班把每一层搭好系统自然就稳了。我最大的体会是不要追求一步到位先跑通最小闭环再逐步优化。那些一上来就想搭完美架构的往往连第一步都迈不出去。
