1. 从零手搓AI工程：为什么我不建议你直接调包
很多人第一次接触AI工程，脑子里想的都是“找个开源模型，pip install一下，跑个demo就完事”。我刚开始也是这么想的，直到我在实际项目里被现实反复捶打——模型推理慢得像蜗牛、显存说爆就爆、部署到生产环境后请求一多直接崩掉。这时候你才发现，只会调包的人连问题出在哪都定位不了。
ai-engineering-from-scratch这个方向，核心不是让你重新发明Transformer，而是让你具备“从底层理解到工程落地”的完整能力。它解决的是一个非常具体的痛点：当AI应用从实验室玩具变成生产系统时，中间那条巨大的鸿沟——数据管道怎么搭、模型怎么压缩、推理怎么加速、服务怎么编排、监控怎么做——这些在教程里往往一笔带过，但在真实项目里每一个都能要你半条命。
这篇文章适合三类人：一是刚入行AI工程、只会跑notebook的新人；二是从后端转过来、想补齐AI系统知识的开发者；三是带团队的技术负责人，需要知道AI工程的全貌才能做技术决策。我会把从零搭建AI工程能力的关键环节拆开讲，包括底层原理、工具选型逻辑、实操步骤，以及我在真实项目里踩过的坑。不堆砌名词，只讲能落地的东西。
2. 先搞清楚AI工程到底在工程什么
2.1 模型训练只是冰山一角
很多人把AI工程等同于模型训练，这是一个巨大的认知偏差。在一个真实的AI系统里，模型训练代码可能只占整个代码库的5%到10%。剩下的90%是什么？是数据采集和清洗、特征工程、模型版本管理、推理服务、负载均衡、缓存策略、监控告警、A/B测试框架、回滚机制。
我参与过一个推荐系统的搭建，模型本身用的是现成的开源架构，训练脚本两周就写完了。但整个系统上线花了将近四个月，时间全花在数据管道的稳定性、推理延迟的优化、以及线上出问题时的快速定位上。所以如果你问AI工程的核心是什么，我的答案是：让模型在真实环境下稳定、高效、可维护地跑起来。
2.2 从Notebook到生产环境的五道坎
从你在Jupyter里跑通一个模型，到它能支撑线上业务，中间至少隔着五道坎：
- 数据一致性：训练时的数据处理逻辑和推理时不一致，导致线上效果暴跌。这个问题极其常见，我见过太多团队在这里翻车。
- 性能瓶颈：实验室里batch size设大一点无所谓，生产环境每个请求都要考虑延迟和吞吐。
- 资源管理：GPU显存是稀缺资源，多个模型怎么共享、怎么调度，直接决定成本。
- 版本管理：模型迭代频繁，怎么保证新版本上线不出问题、出问题能快速回滚。
- 可观测性：线上模型效果下降了，你怎么知道？靠用户投诉就太晚了。
这五道坎，每一道都需要具体的工程手段来解决。接下来的章节我会逐一展开，讲清楚每个环节的核心逻辑和实操方法。
2.3 一个被低估的能力：写可复现的代码
在AI工程里，可复现性不是加分项，是及格线。我见过太多项目，换一台机器跑出来的结果就不一样，甚至同一个人隔一周跑结果都不同。原因通常藏在随机种子没固定、依赖版本没锁死、数据加载顺序不确定这些细节里。
我的做法是：所有涉及随机性的地方必须显式设置种子，包括Python的random、numpy、深度学习框架的随机模块；依赖用锁文件管理，精确到patch版本；数据管道的每一步都记录输入输出的hash值。这些看起来是小事，但当你需要排查一个线上问题时，可复现性决定了你能不能快速定位。
3. 数据管道：AI工程里最脏最累但最重要的活
3.1 为什么你的模型上线后效果暴跌
模型上线后效果暴跌，十有八九是数据管道的问题。训练时你用Pandas做特征处理，推理时用另一套代码做同样的处理，两边的逻辑稍微有一点不一致，结果就天差地别。比如训练时对缺失值填了0，推理时忘了填，模型直接输出垃圾。
解决这个问题的核心原则是：训练和推理共用同一套数据处理代码。具体做法有很多种，我比较推荐的是把特征处理逻辑封装成独立的模块或服务，训练管道和推理管道都调用它。这样虽然多了一层抽象，但换来的是行为一致性。
另一个常见问题是特征穿越。训练数据里不小心包含了未来信息，模型在离线评估时表现极好，上线后直接崩盘。排查方法是仔细检查每个特征的生成时间戳，确保在预测时刻该特征的值是已知的。
3.2 数据版本管理：别再用文件名区分了
我见过太多团队用data_v1.csv、data_v2_final.csv、data_v2_final_真的最终版.csv这种方式管理数据。这在项目初期还能凑合，一旦多人协作或者需要回溯实验，就是灾难。
数据版本管理工具我用过几种，DVC是比较轻量的选择，它把大文件存在对象存储里，Git仓库里只保留元数据指针。另一个思路是用数据湖的方案，每次数据处理生成一个新的分区，用时间戳或版本号标识，配合元数据服务记录每个版本的来源和用途。
不管用哪种工具，核心要求是：给定一个模型版本，你能精确地知道它用了哪份数据训练，并且能重新拉取那份数据。这个能力在排查问题和复现实验时价值巨大。
3.3 数据质量监控的实操方法
数据质量监控不是上线后才做的事，应该从数据管道搭建的第一天就纳入。我通常会在管道里加几个检查点：
- 空值率检查：某个字段的空值率突然从1%涨到30%，大概率是上游出问题了。
- 分布偏移检测：用KL散度或PSI指标监控特征分布，超过阈值就告警。
- 取值范围校验：年龄字段出现负数、金额字段出现异常大值，直接拦截。
- 数据量波动：每天的数据量突然减半，先别急着训练，查清楚原因。
这些检查用简单的规则引擎就能实现，不需要多复杂的工具。关键是要有告警机制，问题发生时能第一时间知道，而不是等模型效果下降了才去回溯。
4. 模型推理优化：让模型跑得又快又省
4.1 推理加速的四个层次
模型推理优化可以从四个层次入手，从易到难分别是：
第一层：框架层面的优化。比如用ONNX Runtime或TensorRT替换原生框架做推理，通常能带来1.5到3倍的加速，而且改动量很小。我一般会先做这一步，投入产出比最高。
第二层：模型量化。把FP32的权重转成INT8，模型体积缩小4倍，推理速度提升2到4倍，精度损失通常在1%以内。量化分训练后量化和量化感知训练两种，前者简单但精度损失稍大，后者需要在训练时模拟量化误差，效果更好但流程更复杂。
第三层：模型剪枝和蒸馏。剪掉不重要的权重或神经元，或者用大模型教小模型。这两个方法能显著减小模型体积，但需要重新训练和调参，工作量较大。
第四层：算子融合和手写kernel。这属于比较底层的优化，需要对硬件架构有深入理解，一般团队用不到这个层次。
4.2 显存不够用？先搞清楚显存去哪了
显存不够是AI工程里最常见的报错之一。很多人第一反应是减小batch size，但这只是治标。要治本，得先搞清楚显存到底被什么占用了。
模型推理时的显存占用主要分三块：模型权重、激活值、以及框架自身的开销。模型权重是固定的，激活值跟batch size和序列长度相关，框架开销则跟具体实现有关。用工具把这三块拆开看，你才知道优化空间在哪里。
我常用的手段包括：用梯度检查点换显存（训练场景）、用PagedAttention管理KV Cache（大模型推理场景）、以及把不常用的层卸载到CPU内存。这些方法各有适用场景，选哪个取决于你的瓶颈具体在哪。
4.3 批处理的艺术：延迟和吞吐的平衡
批处理是提升推理吞吐最有效的手段，但批越大延迟越高。生产环境里，你需要在延迟和吞吐之间找一个平衡点。
我的经验是：先确定业务能接受的最大延迟，然后在这个约束下尽可能增大batch size。对于在线服务，通常用动态批处理，也就是把短时间内到达的请求攒成一个batch一起推理。动态批处理的关键参数是等待窗口，窗口太短batch攒不大，窗口太长延迟又上去了。
还有一个技巧是连续批处理，它允许一个batch里的请求在不同时间完成，新请求可以随时加入。这个技术在大模型推理里特别有用，能把GPU利用率从30%提升到80%以上。
5. 服务化与部署：让模型真正对外提供服务
5.1 推理服务的三种架构模式
推理服务的架构模式主要有三种，各有适用场景：
嵌入式模式：模型直接加载在业务服务进程里，通过函数调用推理。优点是简单、延迟低，缺点是模型更新需要重启服务，而且模型和业务代码耦合。
独立服务模式：模型单独部署成一个服务，业务通过RPC调用。优点是解耦、可以独立扩缩容，缺点是多了网络开销，延迟略高。
流式处理模式：请求先进入消息队列，推理服务消费队列并写回结果。优点是削峰填谷、适合异步场景，缺点是不适合低延迟的在线请求。
我一般推荐独立服务模式，它在灵活性和性能之间取得了比较好的平衡。具体选哪种，取决于你的业务对延迟的要求和请求的模式。
5.2 模型热更新的正确姿势
模型更新是高频操作，如果每次更新都要重启服务，那可用性就没法保证。热更新的核心思路是：新模型加载好之后，通过一个原子操作切换流量，旧模型等正在处理的请求完成后卸载。
具体实现上，可以用双缓冲的方式：维护两个模型槽位，新模型加载到空闲槽位，加载完成后切换指针，旧模型在引用计数归零后释放。这个过程对调用方完全透明，不会中断服务。
需要注意的是，热更新时要做好版本校验，确保新模型的输入输出格式和旧模型兼容。我见过因为新模型输出维度变了导致线上报错的案例，这种问题在灰度阶段就应该发现。
5.3 灰度发布和回滚机制
模型上线不能一把梭，必须灰度。我的做法是先把新模型放给1%的流量，观察核心指标（延迟、错误率、业务指标）没有异常后，逐步扩大到5%、20%、50%，最后全量。每一步都要设置观察期，确认稳定后再进入下一步。
回滚机制同样重要。新模型出问题时，要能在分钟级别切回旧版本。这要求旧模型在灰度期间一直保持可用状态，不能一上线就把旧模型删了。另外，回滚的触发条件要明确，是人工判断还是自动触发，阈值设多少，这些都要提前定好。
6. 监控与可观测性：线上出问题怎么快速定位
6.1 模型服务的三类核心指标
模型服务的监控指标分三类：
系统指标：CPU、内存、GPU利用率、显存占用、网络IO。这些指标反映的是基础设施的健康状况，用常规的监控工具就能采集。
服务指标：QPS、延迟分布（P50、P95、P99）、错误率、超时率。这些指标反映的是服务质量，是告警的主要依据。
模型指标：预测分布、特征分布、置信度分布。这些指标反映的是模型本身的行为，能帮你发现数据漂移或模型退化。
三类指标缺一不可。只看系统指标，模型效果下降了你看不出来；只看模型指标，服务挂了你也发现不了。
6.2 数据漂移检测的落地方法
数据漂移是模型效果下降的头号原因。检测方法主要有两种：一是监控输入特征的分布变化，二是监控模型输出分布的变化。
特征分布监控常用PSI（Population Stability Index）指标，它衡量的是当前分布和基准分布的差异程度。PSI小于0.1表示分布稳定，0.1到0.25之间表示有轻微漂移，超过0.25就说明漂移严重，需要关注。
输出分布监控则看预测结果的分布是否发生偏移。比如一个分类模型，之前预测为正类的比例是10%，现在突然变成30%，那大概率是输入数据变了或者模型有问题。
这些检测不需要实时做，按小时或按天跑一次就够了。关键是要有基准分布，并且基准分布要定期更新，否则时间长了检测会失效。
6.3 日志和追踪：排查问题的最后一道防线
当监控告警响起，你需要快速定位问题。这时候日志和追踪就是你的救命稻草。
日志方面，我要求每个请求都记录：请求ID、输入数据的摘要（注意脱敏）、模型版本、推理耗时、输出结果的摘要。这样出问题时，你可以根据请求ID把整个链路串起来看。
追踪方面，用分布式追踪工具把请求经过的每个环节都记录下来，包括数据预处理、模型推理、后处理。这样你能一眼看出时间花在哪个环节，是数据处理的锅还是模型的锅。
我踩过的一个坑是：日志打得太少，出问题时完全不知道当时输入是什么；后来改成打太多，磁盘一周就满了。平衡点在于：记录关键信息，但不要记录全量数据。输入输出各取摘要和统计量就够了，需要详细数据时再单独采样。
7. 我踩过的那些坑和总结出的经验
7.1 环境依赖：锁死版本比什么都重要
AI项目的依赖极其复杂，框架、CUDA、cuDNN、各种Python包，版本之间还有兼容性要求。我吃过最大的亏就是没有锁死版本，本地跑得好好的，部署到服务器上就报错，排查了一整天发现是某个包的版本差了一个小版本号。
现在的做法是：用conda或poetry管理环境，导出精确到patch版本的锁文件；Docker镜像里固定基础镜像的digest，不用latest标签；CUDA和框架的版本对应关系查官方文档确认，不凭记忆。
7.2 别在训练代码里写业务逻辑
训练代码和业务代码要严格分离。我见过把业务规则写在训练脚本里的项目，后来业务规则改了，训练脚本也得跟着改，改完还得重新训练，整个流程极其混乱。
正确的做法是：训练代码只负责模型本身，数据从标准化的数据源读取，输出标准化的模型文件。业务逻辑放在推理服务里，通过配置或后处理实现。这样模型可以独立迭代，业务规则也可以独立调整。
7.3 性能优化要先测量再动手
性能优化最大的忌讳是凭感觉猜瓶颈。我见过有人一上来就优化模型推理，结果发现瓶颈其实在数据预处理上。正确的流程是：先用profiler测量，找到真正的瓶颈，再针对性优化。
常用的profiling工具包括Python的cProfile、PyTorch的profiler、以及NVIDIA的nsight。测量时要模拟真实负载，不要用玩具数据，否则测出来的结果没有参考价值。
7.4 文档和注释：写给三个月后的自己
AI工程项目迭代快，三个月前的代码你可能完全不记得当时为什么那么写。所以文档和注释不是给别人看的，是给未来的自己看的。
我的习惯是：每个模块的README里写清楚输入输出格式、依赖关系、已知限制；关键决策点在代码注释里写清楚为什么这么选，而不是做了什么；实验记录用表格管理，记录每次实验的配置、结果、结论。
这些习惯看起来增加了工作量，但当你需要回溯一个三个月前的实验时，你会感谢当时的自己。
7.5 从小处着手，别一上来就搞大架构
最后一条经验：AI工程能力的建设要循序渐进。不要一上来就搞微服务、搞Kubernetes、搞特征平台，这些在项目初期都是过度设计。
我的建议是：先用最简单的方案把流程跑通，单体服务加一个数据库就够了。等业务量上来了，再逐步拆分和优化。架构是演进出来的，不是设计出来的。过早优化不仅浪费精力，还会增加系统的复杂度和维护成本。
在实际项目里，我见过太多团队在只有几百QPS的时候就上了全套分布式架构，结果运维成本高得吓人，开发效率反而下降了。找到当前阶段的瓶颈，解决它，然后进入下一阶段，这才是务实的做法。
