开始前我先捋一下。这几年很多人问我“AI工程怎么从零学起”我发现大家对这个“零”的理解往往不太对。大多数人以为从零是“编程零基础开始学”但真正干过AI工程落地的人会告诉你更残酷的从零是你接手一条业务线手上只有一堆没人维护的表、一个模糊的目标和一套完全没有为模型迭代准备过的技术栈。ai-engineering-from-scratch说的其实是后面这件事——从什么都没有到把AI工程体系真正搭起来、能跑、能迭代、能扛住流量。这篇文章我会把过去几年从0到1搭建AI工程体系的完整经历摊开来聊包括技术选型、数据管线、实验管理、部署上线以及一个完整的业务案例。目标读者是准备入行AI工程、或者已经在做算法但每次上线都“像渡劫”的工程师朋友。我尽量不讲虚的把我踩过的坑和验证过的方案直接给出来。1. 一个反直觉的判断AI工程真正难的不是模型而是围绕模型的整条链路先说个我自己的观察。每次招人面试我几乎必问一个问题你把一个模型从写代码到上线最短需要多久能给出完整答案的候选人大概只有三成。很多人会把时间花在讲网络结构、讲loss怎么调但一问到“训练好的模型用什么服务化框架封装”“线上特征和离线特征怎么对齐”“模型上线后怎么监控效果衰减”立刻就卡住了。这不是个别现象而是整个行业对AI工程的理解还停留在“建模”这个环节上。这里我想先把这个概念拧清楚。1.1 一份真实的时间账单训练只占两成其余全是工程我管理过多个机器学习项目也帮团队梳理过耗时分布。结论很稳定模型训练和调参通常只占整个项目周期的20%左右剩下的时间花在数据清洗、特征对齐、环境搭建、服务部署、监控排障这些东西上。网上很多教程把“训练一个模型”包装成了AI的全部这是个很大的误导。举一个具体的数据。一个典型的推荐排序模型项目8周交付周期里大概是这样消耗的数据探查和清洗2周。表结构乱七八糟字段缺失、类型错误、时间戳时区不统一这些问题都在这两周里集中爆发。特征工程与验证2周。特征不是越多越好而是要保证离线和在线计算结果一致很多团队在这上面栽跟头。模型训练与评估1.5周。真正调参的时间反而最短因为现在成熟的框架和baseline太多跑通一个不错的模型很快。服务化与上线1.5周。要搞定接口、鉴权、监控、回滚这部分工作量大且琐碎。灰度与效果验证1周。放流量、对比效果、写结论这周决定模型是否真正能推广。我之前带过一个应届生他用了两天就把XGBoost模型训练出来了但上线花了两周每天遇到的问题都不一样先是对外接口的高可用设计没做过然后发现测试环境内存不够接着又发现线上请求的特征格式跟训练时不一致。最后他跟我感慨“原来训练模型只是整个项目里最简单的一步。”这句话我印象很深。1.2 AI工程、算法工程、数据工程三个岗位的边界与重叠很多人分不清这三个方向其实它们的核心工作差异很大。我直接用一张对比表说明方向核心问题主要交付物关键技能算法工程模型效果怎么更好模型、特征实验、算法策略模型结构、loss设计、数据处理数据工程数据怎么稳定、可靠地流动数据管道、数据仓库、质量监控SQL、ETL、流式计算AI工程模型怎么稳定地上线并持续迭代推理服务、训练平台、监控体系后端开发、容器化、CI/CD、MLOpsAI工程岗位最核心的定位是“桥”——把算法工程师研究出来的模型变成线上稳定运行的服务同时保证算法同学能持续地做实验、迭代模型而不是每次上一回线都要整个团队脱层皮。我曾经在一个团队里体会到这种“桥”的价值。当时算法同学一个月迭代一版模型每版都需要手动导出权重文件、更新服务器上的代码然后重启服务。后来我搭了一个简单的模型管理平台支持上传模型、在线切流、自动回滚上线一个模型的时间从半天缩短到十分钟。算法同学从那以后对工程的评价从“拖后腿”变成了“没你不行”。这就是AI工程的核心价值让模型迭代像流水线一样顺畅。2. 从零开始的第一批技术债环境隔离、框架选型与GPU成本如果没有任何工程基础第一件要恶补的不是模型而是基础设施思维。为什么因为模型代码本身是确定的而不确定性往往来自环境。你见过“在我电脑上能跑”这句话引起的血案就明白环境问题在AI工程里有多致命。2.1 环境从“在我电脑上能跑”到“容器里可复现”AI项目依赖极多Python版本、CUDA版本、PyTorch版本、各种C库版本。随便哪个不一致模型结果就可能出现微妙差异。早期团队常用虚拟环境管理依赖比如venv或conda但这只解决了Python层隔离没有解决系统和CUDA层隔离。我给团队定的标准是所有训练任务和推理服务都必须容器化。具体来说是两步用Docker定义训练镜像里面固定好Python版本、CUDA版本、所有pip依赖。每次训练都用同一个镜像保证训练环境的可复现性。用容器封装推理服务测试环境和生产环境跑同一个镜像避免“测试环境好好的生产环境报错”这种经典问题。这个选择的原因很简单不管是本地开发机、公司GPU服务器还是云上实例只要跑的是同一个镜像环境就是一致的。镜像就是环境的“快照”它是AI工程最基础的复现单元。新手一开始会觉得Docker增加学习成本但我后来发现这个成本非常值得。因为我见过太多团队花一整天排查一个“跑不通”的问题最后发现只是某个系统库版本不同。2.2 框架选型训练看生态部署看亲和力PyTorch和TensorFlow之争到今天已经不太需要争论了——研究社区和中小团队多数用PyTorch因为它调试方便、代码自然。但AI工程师不能只看训练框架本身还要看它跟部署链路的亲和度。我最常用的路线是训练用PyTorch部署时把模型转为ONNX格式再由ONNX Runtime或者Triton Inference Server承载。为什么绕一步因为ONNX格式是模型交换的标准中间格式好处是推理阶段的优化做得更通用不依赖具体训练框架的运行时。把模型格式与训练框架解耦后换来的是后续模型切换的自由度——今天用PyTorch训练明天用TensorFlow训练只要都能导出ONNX推理服务完全不用改。当然如果团队里全是TF背景那TF Serving也很成熟。我的建议是选择依据不是“哪个框架代码写起来更爽”而是“你们团队的部署链路和运维能力更熟悉哪个生态”。框架只是起点部署和服务化才是终点。2.3 GPU成本不是所有模型都需要GPU推理从零搭建AI工程时很多人一上来就买GPU服务器跑推理服务结果成本高得吓人。我在这里给一个很实际的建议先评估模型大小和延迟要求再决定推理用CPU还是GPU。我做过一个文本分类模型模型是BERT-base参数量1.1亿。一开始团队直接上了GPU推理一张T4卡月成本上千。后来我在CPU上用int8量化配合batch合并单条请求延迟只从15ms涨到40ms但成本直接降到原来的三分之一。业务方对40ms延迟完全无感省下的钱拿来扩了一倍资源。这就是AI工程区别于算法研究的地方算法看重“最佳效果”工程看重“满足约束下的最优成本”。用CPU扛得住就别上GPU用单机扛得住就别上集群。资源规划能力是AI工程师的硬本领。3. 数据管线的坑比模型训练的坑多十倍我越来越觉得AI工程的核心在“数据”二字。模型不好可以换结构但数据管线的坑往往隐蔽到让人崩溃。从源表到特征中间任何一步都可能导致模型训练和线上结果不一致——而这个问题一旦出现排查成本极高。3.1 从业务源表到干净特征一份数据管线骨架我搭数据管线时最常用的骨架分六层数据采集从业务数据库、日志系统或第三方API拉取原始数据。数据清洗处理缺失值、异常值、重复记录统一字段类型和时区。数据校验对关键口径做断言检查比如“今日订单量变化不超过昨日三倍”否则告警。特征计算把清洗后的数据转化为模型可用的特征集。特征存储把特征结果落到特征库或文件存储供训练和推理共用。数据版本管理对数据集快照打标签确保后续可以追溯。框架层面轻量级方案用Airflow做定时调度配合Python脚本即可规模大一点可以考虑Prefect或Dagster。但工具是其次关键是每一层都要有监控和校验否则数据哪天悄悄变了模型效果跟着变差你还不知道源头在哪。3.2 时间泄漏我最常强调的“隐形杀手”数据管线里最隐蔽、也最致命的坑是时间泄漏。所谓时间泄漏就是无意中把“未来信息”带进了训练数据让模型在离线评估时很好看上线后立刻原形毕露。举个真实例子。我之前做一个金融风控模型训练数据里包含了一个字段“用户是否逾期”这个字段在特征表中是T1更新的。训练时我直接用当天全量表做特征看似没问题。但实际情况是当天用户的某些操作在业务库里要等第二天才能确认是否逾期这个信息在预测时根本拿不到。模型“偷看”了未来离线AUC高得离谱上线后效果断崖下跌。从那以后我从源头定了一条死规矩所有特征必须严格按照时间点对齐严格用T时刻之前的数据训练来预测T时刻之后的结果。训练集和测试集按时间切分绝不能随机切分。这条规矩帮我避开了后续很多坑。3.3 数据版本管理和特征一致性模型复现的底线先说数据版本管理。很多团队对代码有Git版本管理但数据完全不受控。前一个版本的数据集到哪去了特征口径是什么没人说得清。后来我引入DVCData Version Control把数据集快照跟Git commit绑定用一句话就可以回滚到任意历史版本的数据。效果显著模型复现问题从“靠运气”变成了“按步骤走”。再说特征一致性——这是线上效果和离线评估对齐的关键。离线训练时你从特征表里取的是历史值线上推理时你从接口里实时算的是当前值。两边计算逻辑但凡有一点差异模型输出就会偏离。解决思路是特征平台化把特征的计算逻辑集中起来离线和在线共用同一份代码。这样既能训练时批量算特征也能线上按需实时算两边永远保持一致。初期不需要上很重的框架先用一个简单的特征计算库离线在线都调它就能避免大多数特征不一致问题。4. 让实验结果可复现从随机种子到实验记录的工程化“跑通”和“可复现”之间有一道很宽的鸿沟。面试的时候我问候选人“你的实验结果能完全复现吗”很多人会愣住。在他们看来训练完了保存结果就够了。但AI工程的底线思维是如果换个人、换台机器、换个时间跑同一个实验还能不能拿到同样的结果4.1 随机种子之外的“隐形随机性”一提可复现大家第一反应是设置随机种子。但设置随机种子只是第一步而且是最容易的一步。实际上还有几个“隐形随机性”容易被忽略GPU浮点运算结果在前向传播时的原子操作顺序不一定每台机器一致同代码同种子可能得到微小不同结果。PyTorch DataLoader多线程加载数据时数据的shuffle顺序会受线程调度影响。cuDNN的benchmark模式会动态选择算法导致同一网络在不同GPU型号上的计算结果略有差异。要在这层保证可复现除了固定全局随机种子还需要固定DataLoader的worker数和shuffle种子关闭cuDNN benchmark把环境声明完整。这些东西很琐碎但对于追求严谨复现的工程环境每一项都要查缺补漏。4.2 实验日志不是log文件是决策记录不少团队的实验管理停留在“保存一个.py文件和一个模型文件”超参数写在代码里评估指标记在聊天记录里。等到要对比几十个实验或者过几周回看某个模型为什么效果最好完全无从下手。我的做法是引入MLflow做实验跟踪。每个实验自动记录五类信息超参数学习率、batch size、epoch、模型结构等。指标训练集、验证集的loss、AUC、精确率、召回率等。代码版本当前Git commit号。数据版本使用的数据集快照标识。环境信息Python版本、关键依赖版本、GPU型号。这样每次实验都变成一个可追溯的“快照”过几个月回来还能清楚知道这个模型是用什么数据、什么代码、什么环境训练出来的。MLflow的好处是轻量本地就能跑团队规模不大的时候完全够用。4.3 离线评估的“及格线思维”别高估AUC别忽视baseline这里想聊一个多数新人容易犯的错误过度关注离线指标而忘了评估框架本质上是为了“预判上线效果”服务的。AUC、LogLoss这类指标可以衡量模型的排序能力和概率校准度但它们和“业务赚钱”、和“用户体验”之间隔着好几层。我之前做一个商品推荐模型离线AUC提升了0.03团队信心满满。上线做AB实验人均点击率反而是下降的。后来分析发现离线AUC提升是因为模型对冷门商品的预测更“自信”但这种自信并没有体现在推荐位的点击行为上。离线指标好只是忠实反映了数据分布下的表现并不等于业务目标达成。从那以后我养成一个习惯任何模型上线前必须先跑一个简单的业务baseline比如最近热销榜、最近点击率最高的内容跟复杂模型做对比。如果复杂模型连简单baseline都赢不了那这个模型就没有上线价值。这个习惯在资源有限时尤其重要能帮团队省掉大量无意义的复杂度。5. 模型上线那一下部署、服务化与流量冲击很多算法团队项目死在“上线”这一步。本地跑通了离线指标刷好了但一旦要变成线上服务各种幺蛾子就来了。我见过最典型的场景是算法工程师拿着笔记本去运维那边说“你帮我跑起来”运维问“你告诉我需要什么环境什么依赖什么端口”两人面面相觑。5.1 模型服务化的四种姿势怎么选模型上线没有唯一正确答案关键看业务场景对延迟和吞吐的要求场景延迟要求常用模式实时风控/推荐毫秒级在线HTTP/gRPC服务常配合特征平台离线批量打标分钟到小时级Spark/批处理框架定时跑流式计算秒级Kafka Flink/Spark Streaming边缘端推理极低延迟模型压缩端侧推理引擎从零开始搭建我建议优先打通“在线HTTP服务”这条最常用的路。具体技术栈可以是FastAPI做接口层模型用ONNX Runtime加载用Docker封装前置Nginx做负载均衡。这个组合轻量、灵活团队上手速度快。有些大厂会用TorchServe、Triton等更重的推理服务框架它们自带监控、并发控制、模型管理能力但学习成本和运维成本也高。我的建议是初期不要被“业界都在用Triton”带节奏先跑通一个最小可用服务再逐步引入更重的框架。功能加得太快代价是复杂度失控。5.2 性能与成本并发、延迟和资源三者的平衡模型服务上线前要做一件事压力测试。不要等到线上流量来了才发现服务扛不住。我一般用Locust或wrk做压测重点看三个指标QPS最大吞吐、P99延迟、CPU/内存占用。举个例子一个ONNX Runtime跑BERT分类的推理服务单核CPU大约能扛50 QPSP99延迟100ms以内。如果业务要求200 QPS那就要起4个实例或者加并发优化。上线前的压测数据就是扩容依据没有压测就上线等于闭眼开车。成本优化上我有三个常用招低精度推理int8量化通常能让模型体积缩小四倍在CPU上快2-3倍精度损失通常可控。batch推理把多条请求打包给模型一次推理吞吐显著提升。不少推理框架内置了动态batching。缩容与混合部署低峰期自动缩容多个小模型共用一套服务资源。这每一项实践起来都有细节但核心思路一致以最低成本满足业务延迟要求别一口上GPU别一口上集群。5.3 上线只是开始模型监控与回滚才是保命符模型上线不是终点而是运维的起点。AI模型和普通代码不一样它的行为会随着线上数据分布变化而漂移。数据变了、业务变了、季节变了模型性能都会跟着波动。我的模型监控体系分三层服务层监控QPS、延迟、错误率。这部分用常规监控就能覆盖一旦异常立即告警。特征层监控线上请求的特征分布有没有跟训练时明显偏离比如训练数据里用户年龄字段在20-30岁之间线上突然来了一波60岁用户这就是特征漂移。检测特征漂移可以用PSIPopulation Stability Index这类指标。效果层监控业务指标变化趋势。这一步最难因为真实标签往往有延迟。比如风控模型要等一个月才知道用户是否逾期。短期可用“预测分布的变化”做间接监控长期看真实效果。回滚机制同样重要。我每次上线新模型都会保留旧模型的服务版本并预置一键回滚方案。因为线上环境里最危险的不是模型效果差而是模型挂了却没有恢复能力。6. 一个从0到1的完整案例信贷反欺诈模型落地全记录前面讲了很多原则和技巧这里用一个完整案例把它们串起来。这个案例来自我之前参与的一个信贷反欺诈项目业务目标是识别异常申请行为降低被欺诈的概率。整个项目从0到1刚好能覆盖前面提到的所有核心环节。6.1 业务目标与技术约束第一件事不是建模而是定义边界客户方的目标很直接降低欺诈损失。但“降低欺诈损失”这句话不能直接转化为建模任务必须先拆解。我们花了两周做业务调研和规则梳理最后把目标拆成对每一笔贷款申请实时返回一个欺诈风险分分数高于阈值则人工审核或直接拒绝。技术约束也很明确实时调用必须在200ms内返回结果。数据可用性部分外部征信数据要次日才能拿到所以模型只能用“当前时刻”可得的数据。可解释性业务方要求风险分能解释才好跟审核人员沟通。这些约束决定了很多技术选型。比如实时性要求我们不可能用复杂的大模型跑在线推理所以选择了梯度提升树模型它在分类问题上效果优秀、推理快、特征重要性天然可解释。6.2 数据管线、特征实验与模型评估标准流程里的关键动作数据部分我们接入了申请记录表、历史还款表、用户行为日志三份数据源。第一步不是写特征而是花了整整三天做数据质量探查。结果发现了大量“看起来正常、实际有问题”的数据申请表中同一用户存在多条记录但证件号格式不统一还款表里日期字段常出现空值行为日志存在重复埋点部分字段因为时区差异导致时间错位。这些问题如果不清干净后面所有特征都是错的。我们建立了数据清洗和校验脚本对关键字段设置了规则告警。然后才进入特征工程构造了申请人基本属性、历史借贷行为、设备指纹、申请频次、关联风险等特征总共100多个初筛特征。训练和评估环节我们重点做了两件事。一是严格按时间切分训练集和验证集避免时间泄漏二是设了一个业务baseline——现有规则引擎的AUC作为下限新模型如果整体表现还不如规则引擎就没有上线价值。最终模型相比baseline在相同召回率下精确率提升了约15%达到了上线标准。6.3 上线后的第一周问题比想象中多上线后的第一周是我在这个项目里收获最大的一段时间。第一天就发现线上请求的特征分布跟训练数据有偏差——上线前的测试流量太少没有覆盖到部分真实场景。具体现象是训练数据里申请金额集中在1000-50000元区间但上线当天就来了几笔500万元以上的大额申请模型在这种情况下明显“底气不足”。我们当晚就加了监控告警并设置了高频特征漂移报警。第三天监控显示某外部数据源开始周期性返回空值导致模型特征大面积缺失在线预测分整体偏低。排查后发现这是因为对方接口升级了鉴权方式我们没有及时适配。如果没有特征监控这个坑可能要等到业务方反馈“最近怎么审核结果怪怪的”才会发现代价不可控。一周后系统稳定下来我们复盘时确认了一条经验新模型上线不是“交付”而是“开始”。后续的监控、告警、定期重训、数据更新这些才是AI工程日常的主旋律。7. 从一个真实教训讲起AI工程“从零开始”最重要的是建立“工程体质”想讲一个很多团队都会踩但很少有人写出来的教训。我们曾经有一个模型项目开发周期比预期多了整整三周原因不是模型难调而是“环境不一致”。研究环境的依赖是散装的生产环境的依赖是另一个版本训练数据散落在每个人的网盘里换一台机器就找不到实验记录靠微信聊天。整场开发一半的时间花在“对齐环境”和“找数据”上而不是花在模型本身。这个教训让我意识到AI工程所谓的“从零开始”如果只学模型知识、只学算法调参那搭建出来的依旧是一座沙滩城堡。真正值得优先建立的是一套贯穿环境、数据、训练、部署、监控全链路的“工程体质”。量化的指标可以是环境能否一键复现。数据能否版本化管理。实验能否完整回溯。模型能否一键上线、一键回滚。线上效果能否实时观测。如果你刚准备入行我的建议是从这些“不性感”的基建学起先熟练用Docker管理训练环境用DVC管理数据版本用MLflow记录实验再学一个推理服务框架跑通全流程。最后拿一个真实项目把整个链路串一遍。算法模型的学习永远重要但决定你能走多远的是工程化能力。我在实际带人时还有一个习惯要求每位工程师隔三个月就把自己之前的项目重新部署一遍部署不上的地方就是技术债。还清它们剩下的就是真正的AI工程能力。这条路没有捷径但我可以负责任地说只要把数据、环境、模型、上线、监控这五件事做扎实你已经超过绝大多数“只会跑模型”的人了。