既然要聊“ai-engineering-from-scratch”，我先说一个大家心照不宣的现实：现在市面上九成号称做AI的项目，本质上是“API调用工程”或“Prompt调参工程”。不是说这样不对，而是如果你只停留在那个层面，遇到性能瓶颈、成本失控、效果波动这类问题的时候，你会发现自己根本无从下手，因为你对底层的工程链路一无所知。这也是我为什么一直坚持要把AI工程从零到一整个走一遍——从数据怎么进来到模型怎么训，从推理服务怎么扛高并发到线上效果怎么监控回归，每一层都得亲自动手搞过，才算真正入行。
这篇内容就是来拆解“从零开始做AI工程”这条路上，一个资深工程师眼中最核心的东西：不是推公式，也不讲花哨的模型结构，而是告诉你一套可落地的技术选型逻辑、实操步骤和排查思路。不管你是想转行AI方向的软件开发，还是正在做技术方案选型，又或者刚入职AI团队想快速建立全局认知，这篇内容都能帮你把散落的知识点串成一条完整的工程链路。
1. 内容整体设计与思路拆解
先聊聊“从零开始”这四个字到底意味着什么。
很多人一听到AI工程，第一反应是装个深度学习框架，然后跑通一个示例项目就算入门。但这恰恰是最容易踩的坑，因为示例项目和真实系统之间隔着十万八千里。真实场景里，你的数据可能是脏的、乱的、分布在好几个数据库里的，你的模型推理速度可能达不到线上要求的毫秒级延迟，你的训练任务可能跑一半就因为显存溢出崩掉了，你的线上效果可能上线一周后就开始悄悄衰减。这一系列问题，才是AI工程要解决的核心。
所以，从零开始搞AI工程，我建议把整个体系的认知框架拆成五个相互咬合的闭环环节：
1.1 数据工程层：一切效果的起点
数据工程在整个AI工程里往往是最容易被低估的一层。很多人觉得搞定模型结构、调参、上GPU训练就是AI的核心，可实际做下来你会发现，决定效果天花板的不是模型有多复杂，而是喂给它的数据质量有多高。数据没洗干净、样本分布不均、标签不一致，这些隐患在训练阶段不会立刻暴露，等模型上线后就会以各种诡异的方式反噬回来。
数据工程至少要覆盖采集、清洗、标注、版本管理、特征计算这几块。采集环节要解决数据从哪里来、怎么同步、怎么保证实时性；清洗环节要处理缺失值、异常值、重复样本；标注环节要保证标注口径的一致性，还要有一套质检机制；版本管理这块是很多人容易忽略的，但数据是会迭代的，训练集和验证集一旦变了，模型的评估结果就不具备可比性；特征计算是打通数据和模型的关键桥梁，特征设计和特征的在线离线一致性直接影响模型效果。
1.2 模型训练层：实验追踪是护身符
模型训练这一层，新手最容易犯的毛病是“裸奔式训练”，就是代码一跑，盯着loss下降就以为万事大吉。但训练过程里需要被记录的参数远远不止loss一个数值，学习率的变化曲线、梯度的范数、每一层的权重分布、验证集上各项指标的变化，这些都是判断训练是否健康的重要信号。
更重要的是实验追踪，也就是你每次改了一个参数、换了一种数据处理方式后，模型效果的变化到底是因为什么引起的。如果没有记录的习惯，你会发现自己调参调了两周，最后根本说不清楚哪个改动带来了提升。我个人是强烈建议在项目初期就搭一套实验记录系统，哪怕是最简单的命名规范加CSV记录也行，先解决“有和无”的问题，再谈“好和坏”。
1.3 模型部署层：生产环境的试金石
模型训练出来只是一个开始，生产环境才是真正的试金石。训练代码和推理代码是有本质区别的：训练时你可以用Python的灵活性和便利性，但推理时要面对的是请求延迟、并发量、吞吐率、显存管理、模型版本切换这类工程问题。模型部署的形态也有很多选择，是走在线HTTP服务还是离线跑批，是用原生框架直接服务还是转成优化后的推理格式，这取决于你的业务场景。
这里涉及一个非常核心的判断：你的场景到底是追求极致延迟还是追求高吞吐，这决定了你要不要引入推理框架、要不要做模型量化、要不要用批处理策略。很多时候，不是技术越高级越好，而是越匹配你的业务需求越好。
1.4 模型服务与调度层：把模型变成稳定服务
说完了部署再说服务与调度。实际上，在线推理服务最难的不是把模型加载进显存，而是怎么应对不确定的流量、怎么平滑升级、怎么做多模型的管理与路由。这些听着不是AI的事，但在实际项目中，稳定地对外提供推理能力会比模型本身的准确率更让人头疼。
比如流量突增时服务怎么扩容、模型发布新版本时怎么做到无损切换、多个不同模型之间怎么把资源隔离好避免互相干扰。这一层做得好不好，直接影响你整个AI系统在业务方那里的靠谱程度。
1.5 监控与运维层：AI系统的生命线
最后一层是很多人做了好久才发现自己遗漏的核心工程组件——监控与运维。传统软件工程的监控关注的是请求量、错误率、响应时间这些，AI工程在此基础上还要多一个维度的监控：模型效果的监控。
模型效果是会衰减的，可能因为数据分布变了，也可能因为用户行为变了。如果不做效果监控，你根本不知道模型什么时候开始偷偷变笨了，等业务方来反馈的时候，损失早就造成了。所以我一直强调，AI工程里的监控体系要同时关注健康度和业务度，前者是系统层面的指标，后者是模型效果层面的指标，两者缺一不可。
1.6 工程闭环的核心价值
把这五个环节串起来看，就会发现AI工程和传统软件工程最大的区别在于：它不是一条从需求到代码到上线的流水线，而是一个不断循环、不断迭代的闭环。数据变了要重新训练，效果跌了要排查原因，新数据积累到一定程度要迭代模型。这个闭环的运转效率，决定了一个AI团队真正的工程水平。
我见过太多团队花大力气把模型精度从80%提到82%，但模型迭代一次要花两周，数据要手工导出再手工上传，训练实验全凭脑子记忆，上线靠人工操作。这样的团队就算模型做得再好，整体效率也是低的。从零搭建AI工程，本质上是搭一套让AI系统能够持续进化的基础设施，而不是做一两个模型Demo。
2. 核心技术选型与关键参数解析
技术选型是一个很微妙的事情，因为网上每个人都有自己的偏好，但你真正做项目的时候要考虑的是当前的团队规模、已有的技术栈、业务的阶段，以及最关键的——维护成本。我从实际工程角度出发，给大家一套我多次验证过的选型思路。
2.1 编程语言与开发框架怎么选
在AI工程这个领域，Python是绝对的统治语言，这不光是因为AI生态在Python里最成熟，还因为从数据处理到模型训练的整个工具链，Python的库支持是最完整的。但是，如果你要做一个面向大量用户的在线推理服务，纯Python在某些场合会有性能瓶颈。
我的建议是：不用纠结要不要换语言，而是用分层策略。数据处理、模型训练、实验迭代这些环节，Python无可替代；在线推理服务如果并发要求高，可以用高效的异步框架来承载（比如FastAPI这类基于ASGI的方案），再配合负载均衡横向扩展，绝大多数场景都够用了。如果你真到了单机性能极限，再去考虑用C++或者Rust重写热点路径，但那是极少数项目才需要做的事情。
2.2 模型训练与推理框架的选择逻辑
训练框架这一块，现在基本是主流深度学习框架二分天下的格局，但具体选型要看你的团队更熟悉哪个，以及整个社区生态的成熟度。我的看法是不要频繁切换框架，因为每种框架的API风格和底层逻辑差异很大，团队切换成本极高。
推理框架的选择则更要看业务场景。如果追求极致的推理性能，可以引入专门的推理优化方案；如果业务量没那么大，直接用训练框架自带的推理接口再配合模型量化，也完全够用。不少团队一开始就用上了全套高性能推理栈，结果发现业务量根本跑不满，反而是运维复杂度上来了。方案选型的匹配度，永远比方案本身的高级感更重要。
这里还需要重点提一下模型格式转换。训练时保存的模型权重文件通常体积大、加载慢，而且有时候会依赖训练框架的环境。推理时用的格式则更轻量、更利于优化。从训练格式转成推理格式，这个环节在真实项目里几乎是必经之路，提前在技术方案里规划好，能省掉很多临时抱佛脚的麻烦。
2.3 数据栈的搭建：离线与实时双轨并行
数据栈是AI工程里最容易出问题、也最容易被忽视的地方。我的实践是先规划两层数据体系：离线数据层和实时数据层。离线数据层服务于训练和批量分析，它不需要极致的实时性，但要求数据完整、可靠、可回溯；实时数据层服务于在线推理时需要的实时特征计算，它要求低延迟，但对历史的完整性要求没那么高。
这两套体系的底层存储选型差别很大。离线层我会倾向于用批处理引擎加分布式存储的组合；实时层则需要消息队列加流处理引擎来支撑。很多团队犯的错误是把两套体系混在一起用，导致离线任务影响在线稳定性，或者在线数据回溯困难。
2.4 可观测性体系的指标设计
可观测性这个词听起来有点大，但落到AI工程里其实很具体：日志、指标、链路追踪，这三件套是基础。关键是要设计好哪些指标值得记录，哪些日志要打，以及怎么把一次线上推理请求从入口到模型推理再到结果返回的完整链路串起来。
对于AI推理服务，性能指标之外，还要记录模型相关的信息，比如输入数据的基本分布情况、推理结果的置信度分布。这些信息对于监控模型健康状态至关重要，因为往往性能指标一切正常的时候，模型输出效果已经在悄悄恶化了。
2.5 算力资源怎么规划才不浪费
算力是AI项目里最大的成本项之一，如果没有规划，钱会烧得非常快。训练阶段要按任务需求申请资源，避免大材小用；推理阶段要按流量模型来预估资源用量，预留合理的缓冲区间而不是盲目放大。
我见过一些团队用非常大规模的计算集群跑一个很小的模型，理由是“反正集群空着也是空着”，结果成本和产出完全不成比例。正确的做法是先搞清楚资源瓶颈是算力还是显存还是IO，再针对性地扩容，还要周期性审视资源水位，把空闲资源释放掉。
3. 实操过程与核心环节实现
前面讲的是蓝图和选型，这部分我来展示一个最小可行的AI工程系统要如何落地。我会从零开始搭建一个文本分类系统，走通从数据接入到模型上线再到监控的全套流程。之所以选文本分类，是因为它麻雀虽小但五脏俱全，而且几乎是每个AI工程师的必修课题。
3.1 第一步：数据接入与清洗的工程化处理
数据接入听起来很简单，就是读数据嘛，但工程化的数据接入要考虑的东西远比“读数据”三个字多得多。
我在这个项目里使用的数据来自多个线上业务库的日志数据，每天的数据量在几百万条的量级。具体的做法是先用批处理任务把原始数据从业务库同步到数据仓库的原始层，然后在原始层之上做清洗和结构化处理。这里的清洗不是简单地去个重，而是包括：统一时间格式、过滤无效字段、处理缺失值、剔除明显异常样本，以及最容易被忽略的——标签口径的校验。
标签口径这点我得单独拎出来说。文本分类的数据集往往是半人工标注的，不同标注人员对同一段文本的理解不一致是常态。我的做法是写一个标签分布校验脚本，在每个训练周期前跑一遍，统计每个类别的样本量、标签转移矩阵、以及和上一版数据的差异。如果发现某个类别的样本量骤减或者标签分布突变，就说明数据管线出问题了。这个习惯帮我挡掉了很多次因为数据问题导致的训练事故。
数据版本管理这块，强烈建议在一开始就做起来。哪怕只是给每次生成的数据集一个带时间戳的唯一标识，并在训练任务里记录这个标识，也能让后续的实验对比、效果回溯变得清晰很多。否则你会发现训练了三天的模型，最后根本说不清它是用哪一版数据训练的。
3.2 第二步：特征工程与训练数据生成的坑
特征工程这一步，核心逻辑是“怎么把原始文本变成模型能理解的数值表达”。对文本分类这种任务，选择什么粒度的特征、怎么分词、词表怎么构建，都直接影响模型效果。
我的习惯是先构建一个基准词表，覆盖训练语料里出现频率达到一定阈值的词汇，再把低频词和停用词做过滤。这个阈值设置很关键，设高了会导致信息丢失严重，设低了词表会非常庞大而且噪声多。实际操作中我会跑一个词频分布分析，看看词频下降的拐点在哪个位置，再结合任务背景来确定。
数据增强也是训练文本分类模型时经常用到的手段，但我建议谨慎使用。对文本做同义词替换、随机插入删除等操作，处理不好会产生语义错误的伪样本，反而把模型带偏。我的实践是先不加数据增强，把基准效果跑出来，如果发现某些类别的泛化能力不行，再有针对性地做增强，而不是一上来就全局加。
这里还要说一个很多新手容易忽略的细节：训练集、验证集、测试集的划分方式。如果是常规的随机划分，要注意类别分布的一致性；如果是按时间划分，要确保训练集的时间在前、验证和测试集的时间在后，避免引入时间穿越的信息泄露。特征数据泄露在文本任务里更隐蔽，比如把测试集里出现过的特殊词汇统计进了词表，这种问题排查起来很痛苦，所以一开始划分数据时就要有严格的纪律。
3.3 第三步：模型训练与实验追踪的完整流程
模型结构的选择上，我会先说结论：对于绝大多数实际场景，不要一上来就用超大模型，而是从一个结构简单但合理的baseline模型开始，逐步迭代。这跟我前面说的选型匹配度是一个道理。baseline模型用来快速验证数据管线和训练流程，等一切跑顺了再上更强的模型，路径会更稳。
训练脚本里，有几个关键参数值得展开说说学习率这个参数。它决定了模型参数更新的步长，步子太大了loss会震荡发散，太小了训练收敛慢到让人怀疑人生。我的做法是设定一个相对偏大的初始学习率，同时配一个warmup策略，也就是在训练最开始的一小段步数里线性增加学习率，之后再按预定的衰减方案慢慢降下来。这么做的好处是既照顾了训练初期的稳定性，又不会因为持续的小学习率导致收敛过慢。
批次大小这个参数也很重要，它受限于显存容量。调大批次可以提升训练吞吐量，但也会影响梯度估计的噪声水平。实际调参时，我会在显存允许的范围内尽量用稍大的批次，同时配合学习率调整，让整体更新量保持匹配。如果显存不够，我不太建议就硬撑着跑，而是先考虑梯度累积，也就是把几个小批次的梯度累加起来再更新一次参数，效果接近大批次训练，只是速度慢一些。
整个训练过程里的实验追踪，应该是像记账一样自然的事情。我给自己的硬性要求是：每次启动训练前，把数据集版本号、特征配置、模型结构、超参数、启动时间、代码commit号全部写进实验记录。训练结束后把各项指标的回填进去。这个习惯在初期会觉得烦琐，但一旦开始并行做多个实验对比，你就会发现它的价值。
3.4 第四步：模型评估与验证的工程化方法
模型评估不是“看准确率”那么简单。在文本分类任务里，如果类别不平衡，准确率会有很大的迷惑性。比如95%的样本都是A类，那模型只要全都预测成A类就能拿到95%的准确率，但这对B类一个都没识别出来，业务根本无法使用。
我自己在评估时必看三类指标：一是整体准确率和宏平均F1，即每个类别的F1先算出来再取平均，这样能综合看所有类别的表现；二是每一类单独的精确率和召回率，方便定位模型在哪些类别上偏保守、在哪些类别上偏激进；三是混淆矩阵的可视化，它能直观展示类别之间互相混淆的情况，对找漏判方向非常有帮助。
在验证集之外，我还会再切一小块“盲测集”，它的作用是在多个候选模型之间做最终裁决，避免对验证集过拟合。这类做法在超参数调几轮之后特别有用，因为你会不自觉地根据验证集的表现去做决策，模型多多少少会沾上验证集的信息，盲测集就是为了让最后一次决策更干净。
3.5 第五步：部署上线与推理服务的高并发实践
训练好的模型要上线服务用户，这一步我建议直接把模型转换到轻量的推理格式。转换的动作不复杂，但要做好两件事：一是转换前后要对比预测结果，确保转换没有引入精度损失；二是要确认推理环境和训练环境的关键依赖版本保持一致。
服务的承载方案上，我会先用异步框架把模型的推理逻辑包成一个HTTP接口，然后挂到容器化编排环境上，配合负载均衡器对外提供服务。这里有个工程细节值得注意：模型加载进显存或内存的耗时通常较长，所以服务启动时要做预加载，也就是在真正接收请求之前就把模型加载好，否则第一批请求会被冷启动时间拖垮。
针对并发请求的处理，我要说一个很多教程不会写的点：GPU推理是天然适合批处理的，也就是把多个请求拼在一起进模型算一次，吞吐量会显著提升。但要享受这个收益，你需要在服务层做一次请求的排队和攒批，牺牲一点单请求的等待时间，换取整体吞吐的提升。攒批的窗口时长需要仔细调，太短攒不到足够的请求，太长单请求延迟又会超标，一般我会先设一个中等偏小的窗口，再根据线上流量逐步调整。
3.6 第六步：模型灰度发布与线上验证
新模型上线不是直接把旧模型替换掉就完事了。我强烈建议走灰度发布的流程：新老模型同时在线，把一部分流量切到新模型上，观察线上真实效果，确认没问题后再逐步放大流量比例。
灰度发布在AI工程里的价值比传统软件工程更大，因为离线评估的指标再好看，也和线上真实表现有差距。线上数据分布更复杂，用户的反馈也更难预测。通过灰度发布，你可以用真实流量来检验模型效果，如果发现问题可以及时回滚到旧版本，把影响面控制在最小范围。
灰度发布期间，除了关注服务层面的性能指标，更要关注业务层面的效果指标，比如新模型在高置信度样本上的表现是否和旧模型一致，会不会出现以前没见过的失败模式。这里我建议在推理接口里加上透明追踪用的参数，比如请求带上使用哪个版本的模型，响应也回传版本号，这样在后续的数据分析里可以精确区分模型的贡献。
3.7 第七步：推理服务监控与效果回归
模型上线以后，监控就是日常运维的重头戏了。
服务层面的监控我看几个固定指标：推理请求的QPS、TP99延迟、错误率、GPU利用率和显存占用。这些指标能快速反映系统服务本身的健康状况。效果层面的监控则要看模型预测结果的分布情况，比如预测类别的比例和置信度分布的均值，这些指标的变动往往比准确率更早暴露问题。
效果回归这块，最经典的操作方式是每日或每周跑一次“影子评估”，也就是把线上最近一段时间的新数据收集下来，用当前线上的模型和新训练的候选模型各跑一遍，对比两者的表现。这样能持续跟踪模型是否有衰减迹象，也能在积累足够多的新数据后，判断什么时候该启动新一轮的训练迭代。
4. 常见问题与排查技巧实录
在从零搭建AI工程这条路上，我踩过的坑比顺利通过的桥多多了。把最有代表性的问题整理出来，做成一个速查式的清单，希望各位能少走弯路。
4.1 训练loss正常下降但验证指标不涨怎么办
这个问题几乎每个做AI的都遇到过。模型在训练集上表现得越来越好，但验证集的指标像钉死了一样不动，这通常是过拟合的前兆。
我第一件事是检查训练和验证的数据分布是否一致，常见的原因有清洗逻辑不一致、数据划分时泄露、预处理参数在两套数据上统计口径不同。如果数据这块没问题，就看模型容量是否过大，以及正则化措施是否到位。还有一种可能是验证集本身太小，指标噪声太大，根本看不出变化趋势。这种情况我一般会扩大验证集，或者是换一个更稳定的评估指标。
4.2 推理服务延迟突然飙升
延迟飙升这个问题，原因往往是多方面的。我会先看是不是流量突增导致服务排队，这个从QPS曲线一眼就能看出来；如果流量没变，就要看是不是GPU显存不够触发了内存换出，或者是某张卡上模型推理任务互相争抢资源。
还有一个很容易被忽略但堪称经典的坑：CPU和GPU之间的数据传输瓶颈。数据预处理和模型推理如果各自在不同设备上做，中间的拷贝耗时可能成为瓶颈。文本任务的特征化过程尤其容易出这个问题。排查方法是在链路里逐步打点计时，看耗时到底堆积在哪一段，不要靠猜。
4.3 线上模型效果与离线评估差距很大
这个现象在行业里叫“训练服务偏差”，几乎每个团队都会碰到。原因通常是离线和在线两套数据处理逻辑不一致：离线特征计算和在线推理时用的特征计算代码是两套实现，只要有一点细节差异，效果就可能被放大。
我的处理办法是推行“一套代码、两处复用”的原则，也就是离线环境和在线环境共用同一份特征处理代码。如果实在没法共用，至少要做严格的单元对齐测试，把特征处理的输出结果做对比，确保离线在线等价。
4.4 模型服务显存溢出崩溃
显存溢出这个问题在做大型模型或者多发并发请求时特别常见。我通常会先看是不是模型本身太大，如果是，优先考虑模型量化；如果量化还解决不了，就要看推理批处理时是否同时加载了过多请求导致显存峰值过高。
我建议在推理服务里设置一个显存水位检查，接近阈值时就不再接收新请求，而不是等到显存爆了直接崩溃。因为对在线服务来说，一个请求失败可以重试，整个服务宕掉影响面就太大了。
4.5 数据管线的任务经常延迟导致训练赶不上节奏
数据管线和训练任务之间是严格的上下游关系，上游数据任务延迟，下游训练只能干等。这个问题很容易让团队研发节奏混乱。
我处理的方法是两个方向同时推进：一是给数据任务设置监控和告警，让延迟问题早暴露早处理；二是给训练任务增加自动触发机制，数据任务一完成就自动拉起训练，减少人工等待的时间。
4.6 新模型上线后业务反馈“变差了”但指标还很好
这种情况最让人头疼，就是因为离线指标正常、服务健康度也正常，但业务方就是觉得效果不对劲。后来我总结出规律，很多时候是模型对某个子群体的处理效果变差了，但因为这个子群体占总样本的比例小，宏观指标根本体现不出来。
所以我在监控体系里加了一项：按不同业务分支维度拆分的效果指标。大的指标要拆到细的维度里看，才能发现那些占比不大但业务上很重要的部分是否受到了影响。
5. 从零搭建AI工程的进阶建议
当你已经能跑通上面这一整套系统之后，AI工程的框架算是初步搭起来了。但工程能力的进阶是永无止境的，我再说几个我最近在思考、也在实践的进阶方向。
一个方向是强化推理服务的性能调度。模型越来越多，单张卡上怎么分配显存、多张卡之间怎么做优先级调度、混合负载场景下怎么做资源隔离，这些问题的复杂度会远超你的预期。我建议尽早引入专门做模型服务调度的方案，不要等到模型多了再来补课。
另一个方向是构建完整的模型血缘关系图谱。一个线上模型，它用了哪版数据训练的、对应的代码是哪个commit、经过了几次转换，这些信息如果能自动串联起来，团队在排障和复盘时会轻松非常多。这个方向是反直觉的：看起来跟模型效果没直接关系，但实际上决定了你的AI系统能走多远。
数据闭环和自动迭代这个方向也特别值得投入。当你的系统能够自动从线上收集数据、清洗脱敏、回流到训练集、自动重训模型、自动评估、自动灰度发布，整个AI系统的迭代周期就能从“两周一次”压缩到“一天多次”。这是AI工程最理想也最有价值的状态。
我个人的体会是，AI工程这条路没有什么捷径。网上那些“一周入门AI”的口号听听就好，真正让你在行业里立得住的，永远是那些你亲手排查过的线上事故、亲手调过的特征工程、亲手搭起来的监控体系。从零开始做一遍，每一步都踩实，之后你面对任何新的AI项目都会很从容。最后分享一个我坚持到现在的小习惯：无论多忙，每个迭代周期结束后都记录一篇简短的技术复盘，把当时觉得难的问题、后续真实的走向、如果重来一遍会怎么做都写下来。这个习惯让我避免了很多次在类似问题上重复踩坑。AI技术更新迭代很快，但工程里的底层逻辑，变化比大多数人想象中慢得多，把这些基本功打扎实，你就能以不变应万变。
