如果你以为ai-engineering-from-scratch指的是从零训练一个模型那大概率会在项目做了一半时发现真正卡住你的往往不是模型而是模型旁边那一整圈基础设施。这个标题我很熟因为它几乎就是我这几年做 AI 工程落地的真实写照——从零开始把一条 AI 业务链路从想法推到线上稳定运行中间踩过的坑、绕远的路比模型本身的调试多得多。这篇文章不是课程目录也不是工具清单整理而是一份如果让我重新从零做一遍我会按什么顺序、用什么思路、避开哪些坑的工程复盘。适合正在从算法实验往工程落地转型的工程师也适合技术负责人想快速建立 AI 项目完整心智模型的场景。1. 在动手编码之前先明确 AI 工程和做个模型根本不是一回事很多人对 AI 工程的第一印象是数据科学家把模型训练好工程师负责部署上线。但实际上AI 工程从零到一真正要解决的是把一个不确定的研究过程变成一个可重复、可度量、可回滚的生产流程。这中间差距极大。1.1 一个典型 AI 工程项目的完整生命周期一个完整的 AI 工程项目按我自己的经验生命周期大概是这样的业务需求拆解 - 数据可达性评估 - 数据管道建设 - 基线模型构建 - 实验迭代 - 性能评估 - 推理服务化 - 灰度上线 - 线上监控 - 持续迭代。这十个环节里模型训练只占其中两三个环节而且从时间占比看数据准备和监控运营通常比建模更耗精力。我在早期犯过的错误是把 80% 的精力放在换个更好的模型结构上结果最后发现业务方要的响应时间做不到、数据延迟导致特征对不上、模型一更新线上效果就波动。这些问题没有一个是靠改模型结构能解决的。1.2 我在项目启动时逼着团队回答的几个问题现在我在任何 AI 项目启动的前两周都会先拉着相关角色把下面几个问题聊透。不是走形式是真的要白纸黑字写下来。业务指标和模型指标分别是什么比如订单转化率提升 1%是业务指标AUC 提升 0.02是模型指标两者之间的换算逻辑要事先想清楚。模型预测之后下游系统拿它做什么是直接展示给用户还是进入一个自动化决策流程这个答案直接决定延迟和稳定性要求。数据从哪来、多久更新一次、谁负责维护没有明确数据负责人的项目后面一定会因为数据断更而停摆。模型的失败模式能否承受比如推荐系统给用户推了个完全无关的内容和风控系统误杀了一笔交易严重程度完全不同系统设计也完全不同。这个项目做完后谁来持续维护如果答案是上线再说那基本可以预见上线后三个月模型就失效了。这些问题会比模型选型更早决定项目的成败。我自己见过最典型的案例是一个团队花三个月把离线 AUC 做到了 0.95结果上线后发现特征实时性根本跟不上线上特征和训练特征分布不一致AUC 直接掉到 0.7。这就是典型的需求没对齐问题——如果启动时明确预测需要依赖 T1 数据还是实时特征整个架构都会不一样。2. 数据工程是第一块硬骨头从零搭起可靠的数据管道从零开始做 AI 工程最枯燥但最不能省的就是数据管道。很多快速原型项目能在一两周内跑通但一旦进入生产环境数据管道的问题就会集中爆发。我见过太多项目死在了特征明明离线验证过上线就取不到数这种基础问题上。2.1 先选一条足够简单的数据接入路径数据接入的第一步不是选技术栈而是明确数据源头。是业务数据库、用户行为日志、第三方 API还是离线数仓不同来源对应完全不同的接入方式。我的建议是从零开始时一定不要上来就搞复杂的流式计算。如果业务对实时性没有硬性要求先用定时批处理把数据管道跑起来是性价比最高的选择。比如最朴素的方案用 Celery 或 Airflow 定时任务每天凌晨从业务库抽取增量数据写入数仓的贴源层再做清洗转换。这套方案的好处是依赖少、链路清晰、出问题好排查。只有当业务明确要求用户行为发生后秒级响应才需要考虑引入 Kafka 加 Flink 这类流处理体系。即便如此我也建议先让批处理链路稳定运行一段时间再逐步叠加实时链路两条链路并行验证特征一致性。2.2 数据版本管理比模型版本管理更早需要很多人以为模型版本管理是最重要的实际上在 AI 工程里数据版本管理才是一切的基石。没有数据版本管理模型出了问题你根本说不清楚是代码改坏了还是训练数据变了。具体的做法不复杂给每份训练数据集打上唯一标识记录数据的时间范围、抽取逻辑、清洗规则、样本数量、特征分布摘要。这些信息可以存成一个 manifest 文件和模型产物一起归档。DVC 是开源里比较常见的工具但如果你团队规模小、链路简单用一个 JSON 文件加对象存储也能实现核心需求。我踩过最贵的坑是某次重新跑了历史实验对比发现效果差异巨大查了两天最后定位到是数据管道里某个过滤条件被人悄悄改了导致训练集分布变化。从那以后我立了个规矩任何数据集进入训练流程前必须经过版本注册否则不允许使用。2.3 数据质量的自动化检查项设置数据管道跑起来之后真正花时间的是数据质量监控。这里我建议至少覆盖四类检查项。第一是完整性检查比如每天到表的数据量是否在合理区间如果某天数据量突然腰斩大概率是采集链路出问题了。第二是唯一性检查主键重复会导致样本泄漏训练和线上评估都会有虚高。第三是分布漂移检查对关键特征监控均值、分位数和缺失率一旦发现分布变化超过阈值就得告警。第四是时效性检查数据从产生到可用之间的延迟是否在预期范围内这个对近实时特征尤其重要。这些检查不需要一开始就做得很重可以在数据管道的关键节点埋点用一段配置化的规则引擎先跑起来。等团队成熟了再引入 Great Expectations 这类专门工具。我的原则是先有检查的意识再谈检查的工具。AI 工程最怕的不是没有高级工具而是链路里没人对数据质量负责。3. 模型开发阶段的工程化改造环境、实验与算力管理当数据管道稳定之后才进入大家最熟悉的模型训练阶段。但从零到一的 AI 工程里这个阶段同样需要工程化改造。纯粹的单机 Notebook 训练方式在项目初期可以一旦进入多人协作和多版本迭代就一定会出问题。3.1 环境一致性为什么必须容器化我见过最典型的协作事故是A 同学用 Python 3.10 加某个库的 2.0 版本训练出很好的结果B 同学拉代码后发现环境装不上折腾两天最后发现是依赖冲突。AI 项目对依赖版本极其敏感CUDA 版本、PyTorch 版本、NumPy 版本任何一个不一致都可能让结果无法复现。从零开始的正确做法是第一天就使用 Docker 把训练环境固化。Dockerfile 里明确基础镜像、CUDA 版本、Python 版本再用 lock 文件锁定所有 Python 依赖的精确版本。这样任何人在任何机器上都能复现同样的环境。还没用上容器的时候我自己的环境崩溃过无数次每次都要花半天重新配置。容器化之后这类问题基本绝迹。如果你嫌 Docker 麻烦退一步也要用虚拟环境加 requirements.txt 锁定精确版本千万别用pip install package装完就不管了。3.2 实验追踪到底在追什么实验追踪工具很多MLflow、Weights Biases、Neptune选哪个其实不太重要重要的是想清楚要记录什么。以我自己的实践每次实验必须记录三类信息。第一类是参数配置包括数据版本、特征列表、模型超参数、训练集和验证集的切分方式。第二类是结果指标包括损失函数值、业务相关指标、推理耗时、模型体积。第三类是产物信息包括模型文件路径、预处理器的参数、特征工程代码的 commit id。记不全这三类信息实验对比就是空中楼阁。我见过不少团队跑了几百个实验最后问哪个模型效果最好没人能准确回答就是因为实验记录太随意。记住可复现比效果好更重要因为效果好但不可复现等于没有效果。3.3 算力利用率不高的常见原因从零开始搭训练环境时GPU 利用率低是一个普遍问题。你以为模型在跑就一定是充分利用了 GPU实际上可能利用率只有 30%。常见原因有几个数据加载太慢GPU 在等 CPU 喂数据模型太小但 Batch Size 设置保守计算密度不够日志打印频繁每步都往终端输出大量信息验证太频繁训练中途不断切到评估模式。解决的思路也很直接用 DataLoader 的num_workers和prefetch_factor把数据加载提前适当增大 Batch Size 并同步调整学习率日志输出降频每 N 步打一次验证频率降低或者用单独的验证进程。用 nvidia-smi 或更细的 profiling 工具观察 GPU 利用率曲线比凭感觉调参靠谱得多。4. 训练加速与调优的实战经验模型进入正式训练迭代后速度就是效率。这个阶段的核心矛盾是实验周期太长一天只能跑几个实验调参就像盲人摸象。所以工程化手段在这里的目标只有一个——缩短单次实验的反馈时间。4.1 混合精度训练的正确打开方式混合精度训练几乎已经是标配了它的原理是模型训练中不需要所有计算都保持 FP32部分操作可以用 FP16 加速同时通过损失缩放来避免精度下溢。在英伟达 GPU 上Tensor Core 对 FP16 的计算吞吐是 FP32 的好几倍所以收益非常明显。但混合精度不是无脑开启。我的经验是从零开始的项目直接使用 PyTorch 的torch.cuda.amp或torch.autocast是非常安全的框架已经处理了大部分细节。真正容易出问题的是某些自定义算子不支持 FP16导致数值异常或直接报错。遇到这种情况可以在这些算子上显式使用 FP32做一个混合中的混合。另外一个容易忽略的点是混合精度训练下某些指标可能出现小幅波动这不一定是模型变差了而是数值精度导致的噪声。判断实验效果时不要被小数点后第三位的差异迷惑。4.2 超参数搜索是在为 GPU 交学费得省着花超参数搜索是最容易烧钱的地方。网格搜索的复杂度是组合爆炸级别穷举不现实。从工程角度我建议按下面这个顺序做超参数搜索。初始阶段用少量数据加小模型跑通训练流程验证数据和代码的正确性。这一步不要在意效果只在意能不能跑通。粗搜阶段用中等数据量对学习率、Batch Size、优化器三个最关键的超参数做随机搜索或贝叶斯搜索每个参数尝试 10 到 20 组。细调阶段锁定最优区间后微调正则化系数、网络层数、Dropout 比例等次要参数。这里的关键工程手段是提前停止。训练过程中实时监控验证集指标如果连续多个 Epoch 没有提升就自动终止实验释放 GPU 跑下一组。这个机制能省下大量算力。如果有条件用 Ray Tune 这类分布式调参框架可以进一步提升效率。但团队规模小的时候不必强求自己写一个简单的调参循环加提前停止也足够用。4.3 分布式训练从单卡到多卡的正确升级路径很多项目在单卡时代一切正常一上分布式训练就出现一堆玄学问题Loss 突然变成 NaN、不同卡之间梯度不一致、数据重复采样等等。从零开始做分布式训练我建议按下面的路径渐进式升级。先做单机多卡的数据并行用 PyTorch 的DistributedDataParallel这是稳定性和性能最均衡的选择。要注意设置好torch.distributed.init_process_group并让每个进程绑定到正确的 GPU。数据并行稳定之后如果模型大到单卡显存放不下再考虑模型并行或 ZeRO 这类显存优化手段。这里我强烈建议先检查模型是不是真的需要那么大——很多时候是 embedding 表太稀疏或者特征维度设计不合理压缩之后单卡就能放下。最不推荐的做法是一开始就上多机多卡。网络延迟、节点故障、存储并发问题会让排错成本成倍增加。我见过团队花了三周调试多机训练最后发现问题的根源竟然是一台机器的 CPU 型号不同导致数据预处理结果有差异。这种问题在分布式环境下极难定位所以在单机阶段把链路跑稳是最大的省钱策略。5. 模型部署从指标好看到线上稳定的最后一公里模型在离线评测里指标好看和线上稳定运行完全是两码事。这个阶段的目标是把模型封装成一个可靠的服务让上下游系统按约定格式拿到预测结果。从零开始做 AI 工程这部分决定项目能不能真正产生业务价值。5.1 部署形态的选型逻辑在线、离线还是边缘部署形态不是越高级越好而是越匹配业务场景越好。我见过团队为了技术先进性引入了复杂的在线推理平台结果业务量根本没那么大运维成本反而压垮了项目。部署形态典型场景延迟要求主要成本点离线批量推理用户画像、日报生成、风控批量检查分钟级到小时级调度系统、存储在线同步推理推荐服务、实时反欺诈、搜索排序50ms 到 500msGPU 资源、服务高可用边缘端部署手机上的人脸识别、IoT 设备异常检测10ms 量级模型压缩、端侧适配从零开始我默认的建议是先做离线批量推理。因为大部分 AI 项目的业务节奏允许有一定的延迟而离线推理架构简单、排错容易、成本低。只有当业务方明确说了用户点了按钮必须马上拿到结果才需要考虑在线推理。5.2 推理服务的性能优化清单如果确实要做在线推理服务性能优化有几个优先级很高的方向。模型推理引擎选型GPU 场景优先考虑 TensorRT 或 ONNX RuntimeCPU 场景可以试试 Intel OpenVINO。大部分情况下这些引擎比直接用 PyTorch 的 eager mode 快很多。批处理策略在线服务允许同时处理多个请求时可以把多个请求拼成一个 Batch 喂给模型充分利用 GPU 并行能力。动态 Batching 是实现这个能力的关键K 个请求等待 M 毫秒凑一批是对延迟和吞吐的权衡。特征计算的优化很多时候模型推理只占几十毫秒特征计算反而要几百毫秒。特征计算要尽量提前、复用、缓存不要在请求链路里临时算。资源规格匹配对于在线推理GPU 显存够用即可过大的显卡反而是浪费。CPU 和内存配置要根据推理引擎的实际占用动态调整。性能测试一定要用真实的请求样本不要用离线评测的数据集来压测。因为在线请求的分布和特征缺失模式和离线数据差异很大。5.3 模型上线前必做的稳定性测试代码上线前要测试模型上线前同样要测试而且模型测试有它自己的特殊性。我的稳定性测试清单包括以下几项并发压测下服务的最大吞吐和延迟分位数长时间运行的内存泄漏检查很多推理服务跑几天后会因为缓存或线程问题内存持续上涨异常输入验证包括空特征、全零输入、极端值确保服务不会崩溃返回 500依赖服务降级验证比如特征存储挂了服务要怎么降级是返回兜底结果还是报错。有一个细节容易被忽略模型推理的数值稳定性。同样的输入在不同批大小下、在不同推理引擎下输出可能在小数点后几位有差异。业务方如果对结果一致性有要求一定要在测试阶段定好可接受的误差范围。6. 上线之后的工程运营监控、迭代和复盘模型成功上线对 AI 工程来说最多算完成了三分之一。真正体现工程成熟度的是上线后的运营能力。很多项目在离线阶段风光无限上线后一个月内效果就迅速衰减然后团队开始互相甩锅。要避免这种局面需要在系统设计阶段就把监控和迭代机制考虑进去。6.1 线上模型的体检指标体系线上模型监控不应该只盯着准确率这类单点指标而是要建立一套分层监控体系。第一层是服务健康指标包括请求量、延迟分位数、错误率、GPU 利用率。这些指标反映的是系统本身是否正常。第二层是预测分布指标包括预测值的均值、分位数、离散程度。当模型预测分布发生明显偏移的时候往往是输入数据或业务环境发生了变化。第三层是反馈效果指标包括业务方关注的核心指标比如点击率、转化率、人工复核通过率。这个指标有滞后性但最终价值都由它体现。工具层面Prometheus 加 Grafana 是开源领域比较成熟的组合可以覆盖第一层和第二层的指标监控。第三层指标通常需要业务系统配合埋点但这个投入绝对值得。6.2 数据漂移怎么发现和处置数据漂移是模型线上效果衰减的最常见原因。它的本质是模型训练时的数据分布和线上实际输入的数据分布不一致了。发现漂移的方法是定期对比训练数据分布和近期线上数据分布。常用的手段有对每个特征做统计检验或者计算 PSI 这类分布距离指标。当关键特征的分布距离连续多天超过阈值就要触发告警。处置漂移的常规路径是先排查上游数据是否发生了口径变化比如某个字段的定义被业务方改了再确认是否出现了新的数据来源如果没有明确的异常原因就需要触发重新训练或增量更新。这里有一个工程细节重训后的模型上线前一定要做一遍影子验证也就是把新模型的预测结果和线上模型做离线对比和灰度对比不要一把梭直接切换。6.3 一个月至少要做的定期复盘AI 工程的迭代不是无休止地加新模型而是要有一个固定的复盘节奏。我习惯每四周做一次模型运营复盘内容是固定的。对比最近四周和之前四周的业务指标确认模型效果是否稳定。分析告警事件看看哪些是误报哪些暴露了真实问题。检查训练数据的更新时延确认数据管道没有悄悄拖慢。讨论下一个迭代周期是继续优化模型还是优化数据质量还是优化系统性能。这个复盘最大的价值是让所有人对当前系统真实状况有一致的认知。很多团队的问题不是技术不行而是每个人对系统状态的判断完全不一致。定期复盘用数据说话能解决大部分认知分歧。最后说一点个人体会。ai-engineering-from-scratch 这件事技术方案最后往往不是瓶颈心态和方法才是。我从零走到现在最大的感受是AI 工程的本质不是追新模型、不是堆 GPU而是把不确定性一点点变成确定性的过程——数据是确定的环境是确定的实验是可复现的上线是可回滚的。这个确定性建立起来之后不管大模型还是传统模型不管什么场景你都有能力把项目稳稳地推到线上并且持续运营下去。
