1. 从零搭建AI工程能力，到底在搭什么
很多人第一次看到“ai-engineering-from-scratch”这个标题，脑子里冒出来的第一个念头是：是不是又要手撸一个Transformer？是不是得先把反向传播推一遍？我一开始也这么想，后来发现方向完全跑偏了。这个标题真正指向的，不是让你从零实现一个模型，而是让你从零搭建一套能跑通、能迭代、能交付的AI工程体系。模型只是其中一个零件，真正吃功夫的是模型之外的那一整套东西。
先把话说清楚：AI工程和机器学习研究是两码事。研究关心的是“这个结构能不能把指标刷上去”，工程关心的是“这套东西明天上线之后会不会崩、崩了怎么查、查到了怎么修、修完怎么验证”。你去看那些真正在生产环境里跑AI的团队，代码里模型定义可能只占百分之十，剩下百分之九十全是数据管道、特征存储、服务封装、监控告警、回滚机制。所以“from scratch”搭的不是模型，是这套骨架。
那这套骨架具体包含哪些东西？我把它拆成五块：数据层、训练层、评估层、服务层、观测层。数据层负责把原始数据变成模型能吃的格式，训练层负责把参数调出来，评估层负责判断这模型到底能不能用，服务层负责把模型能力暴露给业务方，观测层负责在出问题的时候告诉你哪里出了问题。这五块缺一块，你的AI系统就是个玩具，不是工程。
适合谁来参考这篇内容？如果你已经会写Python、调过几个sklearn或者PyTorch的demo，但一到“要把这个东西做成一个能给别人用的服务”就卡住，那这篇就是写给你的。如果你是完全零基础，建议先把Python和基础的数据处理过一遍再回来，不然有些工程上的取舍你体会不到痛。
我见过太多人卡在“demo跑通了，然后呢”这个阶段。demo跑通只证明模型能拟合，不证明系统能交付。从demo到交付之间那条鸿沟，就是AI工程要填的东西。下面我按我自己搭过几套系统的顺序，把每一层怎么落地、坑在哪、怎么绕，一块一块讲清楚。
2. 数据层：别急着建模，先把数据管道焊死
2.1 为什么数据层要第一个搭
我踩过最惨的一次坑，是模型在本地跑得好好的，一上训练集群指标就掉。查了两天才发现，本地读取的时候pandas自动把某一列推断成了float，集群上因为文件顺序不同推断成了object，模型吃进去的特征完全变了。这件事让我彻底明白：数据管道不稳定，后面所有工作都是沙上建塔。
所以from scratch的第一步，不是import torch，是把你数据的来源、清洗、切分、版本管理这四件事定下来。来源要明确是数据库、对象存储还是日志文件；清洗要明确哪些字段丢、哪些字段补、缺失值怎么填；切分要明确训练验证测试的比例和切分依据；版本管理要明确每次训练用的是哪一版数据。这四件事任何一件含糊，后面复现实验就是噩梦。
2.2 数据版本管理的最小可行方案
很多人一听“数据版本管理”就想到上DVC或者Pachyderm，其实起步阶段没必要那么重。我的做法是：每次数据清洗产出一个parquet文件，文件名带上日期和内容哈希，比如train_20240512_a3f9.parquet，同时在一个manifest.json里记录这次清洗用的脚本版本、输入文件列表、输出行数、字段列表。训练脚本启动时先读manifest，把哈希写进实验记录。这样任何一次训练都能追溯到具体是哪份数据。
这个方案土，但管用。等数据量上来了、多人协作了，再迁移到专业工具也不迟。关键是先有这个意识，而不是等出了问题才补。
2.3 特征处理里最容易埋雷的三个地方
第一个是时间泄漏。比如你用“用户过去30天消费总额”做特征，但计算这个特征的时候不小心把预测当天之后的数据也算进去了，离线指标会好得离谱，上线就崩。防的办法是：所有时间窗口特征必须显式指定截止时间，代码里加断言，确保窗口右端点不超过样本时间。
第二个是类别特征的编码一致性。训练时把类别映射成0到N的整数，上线时来了一个训练集里没见过的新类别，直接报错或者映射成-1。我的做法是预留一个unknown槽位，所有未见类别都映射到它，同时打日志记录，方便后续补数据。
第三个是数值特征的归一化参数。训练时算的均值和方差必须存下来，上线时用同一套参数做变换。我见过有人上线时重新算了一遍归一化，结果分布对不上，模型输出全乱。这个参数要和模型文件一起版本化，不能分开管理。
2.4 数据质量监控要放在管道里，不是放在人眼里
数据管道跑起来之后，不能靠人定期去看。要在管道里加检查点：行数波动超过阈值告警、关键字段缺失率超过阈值告警、数值分布偏移超过阈值告警。这些检查用简单的统计量就能做，不需要复杂的工具。我一般会在清洗脚本末尾加一段校验，把结果写进日志，异常时直接让管道失败，而不是让脏数据流到训练环节。
提示：数据管道的失败要“响亮”，宁可训练任务起不来，也不要让脏数据静默通过。静默通过的数据问题，排查成本是显式失败的十倍以上。
3. 训练层：把实验当工程做，而不是当玄学调
3.1 训练脚本的骨架应该长什么样
一个能用于工程的训练脚本，结构上必须包含这几段：配置加载、数据加载、模型构建、训练循环、验证循环、检查点保存、指标记录。每一段都要能被单独替换，而不是揉成一坨。我习惯用一个config.yaml管所有超参，脚本里不出现任何硬编码的数字。这样换一组参数不用改代码，实验对比也清晰。
配置加载这块，我强烈建议用dataclass或者pydantic做一层校验。你写learning_rate: "0.001"字符串进去，训练到一半才报错，不如启动时就校验类型。这个习惯能省掉大量低级调试时间。
3.2 随机种子这件事，工程上必须较真
研究里随机种子可能无所谓，工程上不行。同一个配置跑两次结果不一样，你就没法判断是改动生效了还是随机波动。我的做法是：在脚本入口固定Python、NumPy、框架的随机种子，同时把cudnn的确定性开关打开。这会牺牲一点速度，但换来的是可复现。等你要对比两个方案的时候，这点速度损失完全值得。
还有一个细节：数据加载的shuffle也要固定种子，否则每个epoch的数据顺序不同，指标波动会被误认为是模型问题。这个坑我在早期项目里踩过，白白调了一周参数。
3.3 检查点策略：别只存最好的那个
很多人只保存验证集指标最好的那个检查点，这在实际工程里不够。你需要至少保存三类：最新检查点（用于断点续训）、最佳检查点（用于最终交付）、定期快照（用于回溯）。最新检查点每个epoch覆盖，最佳检查点按指标更新，定期快照每N个epoch存一份带时间戳的。
为什么要定期快照？因为有时候最佳检查点是在过拟合之后才出现的，你事后想回到中间某个状态做分析，没有快照就回不去。存储成本不高，但排查问题时价值很大。
3.4 训练日志要结构化，不要print
print("loss:", loss)这种日志，人看还行，机器没法分析。工程上要用结构化日志，每条记录是一个JSON，包含step、epoch、loss、lr、指标、耗时。这样你可以直接把日志导进分析工具画曲线，也可以写脚本自动检测异常。我用过的方案里，最轻量的是直接写JSONL文件，每行一条，不需要任何额外依赖。
日志里还要记录环境信息：代码版本、数据版本、依赖版本、硬件信息。出问题的时候，这些信息能帮你快速定位是代码变了、数据变了还是环境变了。
3.5 分布式训练什么时候该上
我的建议是：单卡能跑完一个epoch在可接受时间内，就别上分布式。分布式带来的调试复杂度、通信开销、故障率，在中小规模下完全不划算。等到单卡跑一个epoch要几个小时、且你已经把单卡性能压榨到极限了，再考虑上多卡。
上多卡的时候，第一个要确认的是数据切分是否正确。我见过有人用了分布式但数据没切分，每张卡都在跑全量数据，等于白搭。第二个要确认的是梯度同步是否正常，指标是否和单卡一致。这些验证做完再谈加速。
4. 评估层：指标好看不等于能用
4.1 离线指标和业务指标之间的鸿沟
模型训练完，AUC 0.95，看起来很漂亮。但业务方问的是：这个模型能帮我减少多少人工审核量？能提升多少转化率？这两个问题离线指标回答不了。所以评估层要做的第一件事，是把模型输出翻译成业务语言。
我的做法是：在评估阶段就引入业务侧的样本，比如人工标注的一批真实case，看模型在这些case上的表现。同时和业务方一起定义一个“可接受阈值”，比如准确率低于多少就不能上线。这个阈值要在训练之前就定好，而不是训练完再拍脑袋。
4.2 评估集要分层，不能只有一个总数
一个总体的准确率数字，掩盖的信息太多了。你需要按关键维度分层看：新用户和老用户、高频和低频、不同地区、不同设备。某个分层上表现特别差，上线后就会在那部分用户身上出问题。我一般会做一个分层评估表，每个分层一行，列出样本量、指标、置信区间。样本量太小的分层要标注出来，避免过度解读。
4.3 置信区间和显著性检验，工程上也要看
两个模型指标差0.5%，是真的有提升还是随机波动？这个问题不搞清楚，你会把噪声当成改进。简单的做法是bootstrap重采样算置信区间，如果两个模型的置信区间重叠，那这个差异就不显著。这个计算不复杂，几十行代码就能实现，但能帮你避免很多无效迭代。
4.4 评估要自动化，不能靠人跑
每次改完模型手动跑评估脚本，迟早会漏。要把评估做成流水线的一环：训练结束自动触发评估，评估结果自动写入实验记录，指标不达标自动标记。这样你打开实验管理界面，一眼就能看到哪些实验达标、哪些不达标，不用一个个去翻。
5. 服务层：把模型变成别人能用的东西
5.1 模型服务的基本形态
模型服务最朴素的形态就是一个HTTP接口，收JSON请求，返回JSON结果。但要做好，要考虑的东西不少：请求校验、批量推理、超时控制、并发限制、优雅降级。我见过太多服务因为没做请求校验，收到脏数据直接崩掉；因为没做超时控制，一个慢请求拖垮整个服务。
请求校验这块，用pydantic定义请求体结构，字段类型、范围、必填项都写清楚，不合法直接返回400，不要让它进到模型推理环节。批量推理这块，如果单次请求量小但QPS高，可以把短时间内的请求攒一批一起推理，吞吐能提升好几倍。超时控制这块，给推理设一个上限，超了就返回降级结果，不要让请求无限等待。
5.2 模型版本切换怎么做才安全
新模型上线，不能直接替换。我的做法是：新模型先以影子模式跑，也就是线上流量同时打到新旧两个模型，但只返回旧模型结果，新模型结果只记录不返回。跑一段时间对比两者差异，确认新模型没问题再切流量。切流量也要灰度，先切1%，观察指标，再逐步放大。
这个流程听起来麻烦，但能避免“新模型上线导致线上事故”这种最坏情况。我经历过一次没做影子直接切，结果新模型对某个特征的处理有bug，线上错误率飙升，回滚花了半小时。那半小时的损失，比做影子模式多花的时间大得多。
5.3 特征一致性：线上线下必须对齐
这是AI工程里最经典的坑：离线训练用的特征，和线上推理时算的特征，对不上。原因可能是计算逻辑不同、数据源不同、时间窗口不同。防的办法是：把特征计算逻辑抽成一个共享模块，离线和线上都调这个模块。如果做不到共享，至少要用同一批样本做一致性校验，离线算一遍、线上算一遍，对比差异。
我一般会在上线前跑一个一致性测试：取1000条线上真实请求，分别用离线和线上管道算特征，逐字段对比。差异超过阈值的字段要重点排查。这个测试能拦住大部分特征不一致问题。
5.4 降级方案要在上线前就准备好
模型服务不可能永远可用。依赖的数据源挂了、模型文件损坏了、流量突增打满了，这些情况都要有应对。降级方案可以是返回默认值、走规则兜底、或者直接返回错误让上游处理。关键是这个方案要提前定好、提前测试，而不是出事的时候临时想。
6. 观测层：出问题的时候能快速定位
6.1 监控指标要覆盖哪些维度
模型服务的监控，至少要看四个维度：延迟、吞吐、错误率、模型指标。延迟看P50、P95、P99，不要只看平均，平均值会掩盖长尾问题。吞吐看QPS和并发数。错误率要区分是请求错误还是推理错误。模型指标看输出分布是否偏移，比如分类模型各类别占比是否和训练时一致。
这四个维度任何一个异常，都可能是问题的信号。我一般会设两级告警：警告级和严重级。警告级发通知，严重级直接打电话。阈值根据历史数据定，不要拍脑袋。
6.2 日志、指标、追踪三件套怎么落地
日志记录离散事件，指标记录连续数值，追踪记录请求链路。三件套配合使用，排查效率最高。日志用结构化格式，指标用Prometheus这类工具采集，追踪用OpenTelemetry这类标准。起步阶段不用全上，但日志和指标是最低要求。
我排查过一次线上问题，模型输出突然变得很奇怪。看指标发现延迟正常、错误率正常，但输出分布偏移了。看日志发现那段时间数据源换了格式，某个字段从字符串变成了数字，模型吃进去的特征变了。如果没有输出分布监控和结构化日志，这个问题可能要查很久。
6.3 模型漂移检测的简单做法
模型漂移是指线上数据分布和训练数据分布逐渐偏离，导致模型效果下降。检测方法不复杂：定期拿线上最近一批样本，算特征分布和训练分布的差异，常用PSI或者KL散度。差异超过阈值就告警，提示需要重新训练。
这个检测要自动化，按天或者按周跑。不要等业务方反馈效果变差了才去查，那时候损失已经产生了。
6.4 事故复盘要形成闭环
每次线上问题解决后，要写复盘：问题现象、排查过程、根因、修复方案、预防措施。预防措施要落到具体的监控项或者流程改动上，而不是一句“下次注意”。我见过太多复盘写完就归档，同样的问题反复出现。复盘的价值在于把经验固化成系统能力，而不是写一篇文档。
7. 把这五层串起来：一个最小可用的AI工程骨架
7.1 目录结构建议
project/ configs/ # 配置文件 data/ # 数据管道脚本 features/ # 特征计算共享模块 training/ # 训练脚本 evaluation/ # 评估脚本 serving/ # 服务代码 monitoring/ # 监控配置 experiments/ # 实验记录 manifests/ # 数据版本清单这个结构不复杂，但每一块职责清晰。新人进来能快速找到对应代码，不会所有东西堆在一个目录里。
7.2 从零到跑通的最短路径
第一步，写数据清洗脚本，产出带版本的数据文件。第二步，写训练脚本，能读数据、能训练、能存检查点、能记日志。第三步，写评估脚本，能算分层指标、能输出报告。第四步，写服务代码，能收请求、能推理、能返回结果。第五步，加监控，能看到延迟、错误率、输出分布。这五步走完，你就有了一个最小可用的AI工程骨架。
这个骨架不完美，但能跑通完整链路。后续所有优化都是在这个骨架上迭代，而不是推倒重来。我见过太多人想一步到位搭一个完美系统，结果卡在某个环节迟迟跑不通，最后不了了之。先跑通，再优化，这个顺序不能反。
7.3 几个我踩过的坑，你可以直接避开
第一个坑：过早引入复杂工具。一开始就上Kubernetes、上特征平台、上实验管理平台，结果光配置环境就花了两周，业务代码一行没写。我的建议是先用最朴素的方案跑通，等遇到具体瓶颈了再引入对应工具。
第二个坑：忽略依赖管理。训练环境和服务环境依赖版本不一致，导致模型加载失败。用requirements.txt或者poetry锁定版本，训练和服务用同一套依赖。
第三个坑：不做端到端测试。数据管道、训练、评估、服务各自测试都通过，串起来跑就报错。要有一个端到端的冒烟测试，用少量数据跑完整链路，确保各环节衔接正常。
第四个坑：文档缺失。系统搭完只有作者知道怎么跑，作者一休假系统就没人敢动。关键流程要写文档，配置项要写注释，新人能照着文档跑通。
注意：AI工程的核心不是模型多先进，而是系统多可靠。一个AUC 0.85但稳定运行的系统，价值远大于一个AUC 0.95但三天两头出问题的系统。
8. 关于迭代节奏和团队协作的一点个人体会
搭这套东西的过程中，我最大的体会是：AI工程的迭代节奏和纯软件开发不一样。纯软件可以小步快跑，每天发版。AI系统因为涉及数据、模型、服务多个环节，每次改动的影响面更大，需要更谨慎的验证。但也不能因此就几个月不发版，那样业务方等不起。
我的做法是：数据管道和服务层的改动走常规发布流程，模型更新走影子加灰度流程。两条线分开，互不阻塞。数据管道改了不影响模型服务，模型更新也不影响数据管道。这样既能保持迭代速度，又能控制风险。
团队协作上，数据、训练、服务最好由不同的人负责，但接口要定义清楚。数据产出什么格式、训练消费什么格式、服务需要什么输入，这些契约要提前定好，写成文档。接口定了之后，各方可以并行开发，不用互相等。
还有一点：实验记录要共享。谁跑了什么实验、用了什么配置、结果如何，团队里所有人都能看到。这样避免重复劳动，也能让好的经验快速传播。我用过最简单的方案就是一个共享的表格，每次实验加一行。工具不重要，重要的是有这个习惯。
这套骨架我前后搭过三遍，每一遍都比上一遍精简。第一遍什么都想上，结果复杂度失控。第二遍砍掉一半，还是觉得重。第三遍只保留最核心的五层，反而跑得最顺。所以如果你刚开始搭，我的建议是：从最简版本开始，遇到问题再加东西，不要一开始就追求大而全。
