1. 先搞清楚什么是"从零开始的AI工程"
我见过很多人对ai-engineering-from-scratch这个说法有误解，以为是要从零手写神经网络、当一次"不用框架造轮子"的英雄。实际上，真正做过AI项目落地的人会明白，这个标题的核心压根不是算法，而是工程——即"你怎么把一个模型从实验笔记本里搬出来，变成一个能稳定运行、能监控、能迭代的线上系统"。
在我看来，from-scratch不是什么都要自己重造，而是"从零开始搭一套AI工程体系"。这包括数据怎么治理、训练怎么组织、模型怎么评估、服务怎么上线、线上效果怎么跟踪，最后是一整套让模型持续变好的闭环。很多团队不是缺模型，而是缺这条链路。拿着训练好的模型直接开个HTTP接口对外提供服务，看起来是上线了，但没过多久就会出问题：输入分布变了没人发现、模型效果退化没机制感知、毒样本进来了没有回滚路径。这就是典型的"AI研究很强，AI工程很弱"。
这篇文章就是写给打算把模型真正推向生产环境的人看的。你可以是刚入门AI的应用工程师，也可以是带团队的研发负责人。我要讲的是一套我自己踩过不少坑之后整理出来的最小可用工程框架，以及每一步选择背后的理由。不迷信"最佳实践"，只讲"可落地的实践"。你不需要先成为基础设施专家，但你需要理解AI系统在生产环境里是怎么运转的，哪些东西必须一开始就设计好，哪些可以后面再补。
先说一个前提：这套体系与你用什么框架、跑什么模型无关。PyTorch、TensorFlow、ONNX、自有推理引擎，都适用。体系的价值在于它把混乱的模型开发过程变成了有节奏的工程迭代，让你随时知道"当前这个AI系统处在什么状态，下一步该做什么"。
2. 整体架构拆解：一个AI工程系统的五个关键零件
2.1 从"训练脚本"到"生产系统"的思维转换
在本地做实验时，你的代码可能是这样的：读数据、预处理、训练、验证、打印指标。整个过程线性执行，结束后留下一堆.pth或.h5权重文件。但生产环境里的AI系统，输入是随时到达的、分布在各地的真实请求，数据分布会漂移，模型会变慢，第三方依赖会悄悄升级。这个时候，促使系统运转的不再是"训练逻辑"，而是围绕模型建立起来的基础设施。
我习惯把生产级AI系统拆成五个零件：
- 数据管道：负责批量数据和在线数据的采集、清洗、转换、打标、版本管理。
- 训练与实验平台：负责模型训练的编排、算力调度、实验记录、超参数管理。
- 模型评估体系：负责离线和在线评估，用业务指标而不是学术指标衡量模型价值。
- 推理服务层：负责把模型部署为API、批处理任务或边缘端应用，包含灰度、回滚、限流。
- 监控与迭代闭环：负责追踪模型表现、及时发现异常、收集新的训练数据并触发重新训练。
五个零件不是一次建成的，但架构意识要从第一天就有。我见过最惨烈的情况是：模型已经在线上跑了一个月，团队忽然发现没有日志系统，不知道模型每天收到多少请求、预测结果分布如何。这时候想补监控，几乎等于重新做一遍工程。
2.2 为什么"数据版本管理"是你的第一块基石
很多从零开始的AI团队，最先没有想清楚的往往不是模型结构，而是数据。训练数据的来源、时间范围、标注版本、清洗规则都直接影响模型行为。如果这些信息不可追溯，模型出了问题你连"这个模型是用什么数据训练出来的"都答不上来。
数据版本管理的核心，不是搞一套复杂的系统，而是给每次训练用的数据集打上唯一标识，并把数据生成方式记录下来。我常用的一种轻量方案：数据目录 + 数据集清单。目录里保存原始文件，清单记录每份数据的时间范围、来源、预处理脚本版本、标注版本号、已知问题。训练框架读取的不是直接路径，而是清单中某个版本标识对应的数据。
这样做的好处，等到你会明白。模型效果不好的时候，复盘第一步就是"数据版本是否与预期一致"。如果你的验证集、训练集和上一次实验完全一样，那算法的改进才有对照意义。否则，你优化了半天，以为是自己模型改好了，实际上只是换了一版更好做的数据——这在我的经历中并不少见。
2.3 训练与实验平台：别在实验阶段就给未来埋坑
训练与实验平台听起来高大上，实际最核心的就是三件事：复现、记录、对比。也就是说，任何一次训练都能在一台干净的机器上重新跑出来；每一次跑完，超参数、代码版本、数据版本、权重路径、指标结果都能随时查到；不同实验之间能直接横向对比。
整套设计里最容易忽视的是随机性控制。深度学习模型训练天然带随机性，GPU算子、数据加载顺序都会引入细微差异，导致同一份代码跑两次指标不完全一样。为了消除随机性，需要固定随机种子，并对数据加载过程做有序采样。对应到GPU浮点运算，还可以通过设置torch.backends.cudnn.deterministic = True和torch.cuda.manual_seed_all()让计算尽量可复现，但代价是训练速度略降。生产中我通常只对关键实验开启完全确定性配置，普通探索实验则记录随机种子和随机状态，允许轻微浮动。关键是，记录必须做全，这样任何一次结果波动都有解释入口。
3. 核心细节解析：数据、评估与推理服务的设计要点
3.1 数据标注里的坑：质量一致性比规模更重要
真实业务中，你很难拿到一张完美的标注数据集。数据标注的坑，第一是标注者之间的不一致，第二是标注标准自身的漂移。
先说标注入员之间的不一致性问题。两个标注员看过同样的指南，对同一个样本的理解可能不同。比如情感分类里"挺好"是正向还是中性，不同人判断有差异。如果你的标注工具只记录最终标注结果、不记录标注人，你就永远不知道数据里藏着多少这种模糊地带。结果就是模型在某些样本上学到的不是规律，而是噪声。
我采用的方案是"双人标注 + 仲裁"。每份关键样本至少两个人标注，结果不一致时由资深标注员或算法负责人仲裁。此外定期计算标注一致性指标（比如 Cohen's Kappa 系数），如果一致性低于0.8，就说明标注规则本身有问题，先解决规则再继续扩展数据量。
另一个常见问题是标准漂移。业务需求变化会导致标注规则调整，比如"包含优惠信息的咨询"算不算营销意图，一开始界定宽泛，后来变得严格。如果新旧规则下的数据混在一起训练，模型会学到前后矛盾的模式。所以我建议，每次标注规则变更，都新建一个数据集版本。旧版本数据可以保留用于分析，但不会与新版本混用，除非做明确的重新标注。
3.2 训练集和验证集的划分：别让"时间泄漏"毁掉你的评估
机器学习101里就讲，数据要划分训练集、验证集、测试集。但真实业务数据不是随机乱序的样本，而是随时间流动的。最经典的错误是随机划分，这会造成时间泄漏：训练集和验证集在时间上重叠，模型"见过"验证集对应的未来信息。
举个例子，训练一个职场闲聊场景的意图分类模型，数据是历史上一天天积累的会话。如果你随机抽取20%做验证集，那么验证集里可能有大量与训练集同一天的对话。常识告诉我们，同一天的对话主题往往高度关联，比如某天大家都在讨论系统更新，验证集和训练集都含这种话题，模型验证指标就会虚高。上线之后，真实业务中遇到的是新一天的新话题，模型效果立刻下滑。
我始终坚持按时间划分数据，比如用某一天零点作为边界，之前的数据训练，之后的数据验证。如果数据不足，可以在边界附近留出隔离带（gap），把边界前后几小时的数据都剔除，防止时间相关性污染验证集。此外，验证集必须保留真实业务分布，不能降采样或做过度增强，否则验证指标会"失真"。
3.3 模型评估：业务指标优先，模型指标为辅
模型工程师习惯盯着精确率（Precision）、召回率（Recall）、F1这类指标，但业务方关心的是成本、收入、留存、用户投诉率。做AI工程最怕的事情是：模型离线评估分数很好，线上业务却毫无起色。
我设计评估体系时坚持两条链：离线指标链和业务指标链。离线指标链由算法团队定义，用标准数据集衡量模型本身的能力；业务指标链由业务团队和算法团队共同定义，用真实业务数据衡量模型对业务的影响。
比如一个智能客服转人工模块，离线看的是意图识别正确率，在线看的则是转人工率是否下降、用户满意度是否提升、客服处理时长是否缩短。离线指标告诉我们"模型有没有学对"，业务指标告诉我们"这件事做了有没有用"。两条链都必须有基线，而且基线就是当前线上模型的表现。任何一次新模型实验，如果离线指标提升但业务指标不明确，我宁可不上。原因很简单：真实业务的非线性变化太多，推理出"离线好=在线好"的前提条件经常不成立。
3.4 推理服务层的四个核心设计：延迟、并发、灰度、回滚
推理服务是离用户最近的一环，它的问题暴露得最快。我总结过四个必须提前想清楚的设计点：延迟预算、并发策略、灰度发布和快速回滚。
延迟预算不是技术指标，是商业指标。比如一个实时推荐接口，业务要求响应时间低于200毫秒，那么模型推理耗时、网络传输耗时、特征构造耗时都要计入预算。我习惯把预算拆成三份：30%给特征工程、30%给模型推理、20%给网络和其他开销、20%作为安全余量。模型推理时间不稳定时，可视化耗时分布比只看平均值更有用，因为平均耗时80毫秒掩盖不了P99耗时800毫秒的事实，而真实用户感知的就是最坏的边缘情况。
并发策略涉及推理服务是同步还是异步、是否需要批量推理。对于实时性要求高的场景，一般用同步接口加批量队列；对于大量非实时任务（比如批量打标），用异步任务队列更合理。模型batch化通常能成倍提升吞吐，但会引入每请求等待时间，所以batch窗口需要调参，不是越大越好。
灰度发布的核心是"逐步增加风险敞口"。新模型上线，先切5%流量，观察半天到一天，没有异常再逐步提高到20%、50%、100%。灰度期间的对比不能只看模型自身指标，还要看业务侧指标是否有波动。更具体地讲，我在灰度前会确定一个"回滚触发条件"，比如"错误率上升超过2%""P99延迟超过预算20%""业务指标下降超过5%"，满足任何一个条件就自动触发回滚。这一套逻辑用代码写死在发布系统里，而不是靠人盯着盯板来决定。
4. 实操过程：搭建一套最小可用AI工程闭环
4.1 工程量级评估与选型：从最小可行系统开始
很多团队第一步就走错了，试图一次性构建完整平台，包括分布式训练、自动标注、模型仓库、大模型服务网关。结果做了三个月，业务没跑起来，平台也没做完。我建议反过来：先跑通一套最小闭环，之后再逐步扩展。
最小闭环只需要满足四条：数据可追溯、训练可复现、上线可灰度、线上可监控。具体到工具选型上，最朴素的方式其实就足够：
| 环节 | 轻量起步方案 | 后期可演进方向 |
|---|---|---|
| 数据版本管理 | 数据目录 + 数据集清单（JSON/YAML） | DVC、LakeFS |
| 模型版本管理 | 文件目录 + 模型记录表 | MLflow、Model Registry |
| 实验记录 | 自定义日志CSV/Markdown | W&B、Neptune |
| 流水线编排 | Shell脚本 + Python调度 | Airflow、Prefect |
| 推理服务 | FastAPI + PyTorch/ONNX Runtime | Triton、TorchServe |
这不是否定期货化平台的价值，而是强调"匹配当前阶段"。前期用Shell脚本就能解决的问题，没必要引入Kubernetes。当团队规模变大、项目变多、协作变复杂后，再逐步规范化，成本更低。
4.2 冻结基线：没有对比参照就没有改进方向
搭建闭环后，第一件事不是优化模型，而是冻结一个基线版本。我用一个"基线冻结清单"来约束团队：
- 模型结构固定（含代码Git提交号）
- 训练数据版本固定（含数据更新时间）
- 超参数固定（含随机种子）
- 评估流程固定（同一套验证集和离线指标）
- 推理延迟基线固定（同一测试机器上的耗时记录）
基线冻结后，任何人提交的优化结果都要和基线对比。没有对比结果，就进不了实验评审。这听起来像繁琐的流程，实际上在节省团队时间。它把"我感觉模型变好了"变成了"可验证的量化结论"。
对比又分三个层次：离线指标对比（算法层面）、推理性能对比（工程层面）、线上效果对比（业务层面）。我见过不少团队做到第一层就急着上线的，结果推理速度翻了三倍，延迟不可接受，不得不重新优化。所以在评审阶段就把工程层面的延迟测试和离线测试放在同一优先级，这能让上线前的返工时间大幅减少。
4.3 上线发布会：从模型到服务的"最后一公里"
模型训练好了，评估也过了，接下来是把它封装成服务。这个过程中，最容易出问题的地方是特征处理一致性。离线训练时特征是从全量数据集中构造的，在线推理时特征需要从实时请求中构造。如果两边代码不是同一份、参数不是同一套，线上效果就会稀烂。所以我要求训练特征代码必须和在线推理特征代码合并到一个项目，通过依赖注入替换数据源，而特征构造逻辑只有一个实现。
第二步是封装有状态服务和无状态服务的取舍。对有状态的场景（比如对话记忆、多轮上下文），我建议把状态外置到Redis或专门的会话存储层，推理服务保持无状态。这样服务水平扩缩容就简单了，滚动发布也不会丢上下文。无状态的理由跟Docker部署要求一致：无状态服务才可以在任意节点重启。
第三步是部署与资源估算。建议先算清楚模型的内存占用、单并发推理耗时、CPU/GPU利用率。举个例子，一个BERT-base模型大约需要400MB参数存储，float32下推理时内存占用约1.6GB（算上激活值），你部署8个副本就需要至少13GB内存，这还不算框架本身的开销。不做资源估算就上线，大概率是在第一次流量高峰到来时才发现机器不够、服务雪崩。
4.4 监控指标和可观测性建设：别等用户投诉才发现问题
可观测性不是锦上添花，是AI工程的"仪表盘"。四个级别的监控指标我都建议做：
- 系统层：CPU、内存、GPU利用率、网络IO。
- 服务层：QPS、错误率、响应时间分布（P50/P95/P99）。
- 模型层：预测类别分布、平均置信度、拒绝率、触发频率。
- 数据层：输入特征分布、缺失率、取值范围漂移。
其中数据层最容易忽视，也最致命。上线三个月后，用户行为变了，某些特征的取值分布会整体偏移，模型预测分布也会跟着变。如果没有数据层监控，你会在用户投诉率飙高之后才被动发现。我采用的做法是对每个特征建立基线分布，在线统计滑动窗口内的分布，用 KL散度或者简单的"均值偏移超过3个标准差"作为告警条件。不要求复杂，关键是可操作、可解释。
5. 常见问题与排查技巧实录
5.1 机器学习平台的常见故障速查表
| 问题表象 | 可能原因 | 排查思路 |
|---|---|---|
| 线上预测结果与离线不一致 | 特征处理不一致、版本错配 | 对比线上特征值和离线特征样例，检查模型输入Tensor与训练时是否同构 |
| 线上QPS上升后延迟飙升 | 并发资源不够或推理服务非批量 | 先看服务层监控确认瓶颈，再调大batch窗口或加副本 |
| 模型预测分布与训练时差异大 | 线上数据分布漂移 | 拉取最近N天线上请求特征，计算与训练特征的分布差异 |
| 新模型灰度期间业务指标下降 | 新模型规则与业务预期不符 | 暂停灰度，对比新老样本输出，定位差异模式 |
| 模型训练结果不可复现 | 随机性未固定、数据版本未锁定 | 固定种子、锁定数据版本并复核代码提交号 |
| 标注数据质量太差导致训练异常 | 标注标准不一致 | 做一致性分析，仲裁争议样本 |
| 推理服务内存越来越大 | 可能存在内存泄漏或模型副本数太多 | 用内存剖析工具检查，控制带状态对象 |
5.2 我第一次上线时踩过的三个重要教训
第一次把NLP模型推上线时，我犯过自己以为很小的错误。第一次是在灰度阶段只看了模型准确率，没看业务侧指标。新模型准确率碾压旧模型，我高兴地切了全量流量，第二天客服团队反馈"意图分类设备相关的问题全跑偏了"。后来一查，是因为新模型在"设备故障"这个类别召回很高，代价是把很多"使用咨询"的样本也分到了"设备故障"。准确率虽然提升了，但用户需要不断转人工，满意度明显下降。从那以后，灰度期间的业务指标必须先看。
第二次教训是"依赖版本漂移"。训练用的scikit-learn版本是1.2.3，线上环境跑推理的版本被其他同学升级成1.3.0，序列化加载出来的模型对象行为出现细微不一致，导致某个类别得分偏移了0.08。这个Bug很难发现，表现又是间歇性的，最后通过比对两台机器上模型输出的逐项差值才定位到。我把所有模型依赖都写死在Dockerfile里，并锁定到具体patch版本。
第三次我与标注同学配合，发现"质量把关不严"差点酿成大问题。模型在灰度期整体效果向好，但业务方指出某类实体解析率奇差。抽检了500条被模型错判的样本，发现原始标注里就有30%是错标漏标。也就是说不是模型学歪了，是训练数据的标签就是错的。从此以后，上线前的数据抽检就成了我个人的强制动作：不管模型指标多好，随机挑300~500条训练样本，逐条过一遍。
5.3 冷启动数据不够怎么办：两种可落地的思路
不少真实业务面临的现实问题是：刚刚起步，根本没有历史数据可供训练。我处理冷启动的思路有两种。
第一种是少样本 + 规则兜底。先收集少量人工标注种子数据（几百条到一两千条），训练一个小模型或使用预训练模型做初版。产线逻辑上把这个AI能力作为一种"建议引擎"，输出给业务人员参考，但不完全取代人工判断。规则系统负责兜底，能通过规则判断的直接给结果，不能判断的才走模型，这样就在数据不足时保证基本效果。随着线上运行，系统持续积累人工修正后的样本，冷启动期一过，逐步提高模型的决策权重。
第二种是迁移学习 + 无监督预训练。如果目标任务数据稀缺，但相关领域有公开数据，可以通过预训练加微调的方式先获得基础能力。比如做一个垂直领域的文本分类，先在海量通用语料上训练语言模型，再在有少量标注的垂直语料上微调，这样通常比直接在有标注的的小数据上训练更稳。
两种思路可以叠加使用。冷启动期一定要设定"数据量阈值"和"模型性能阈值"，两者都达标后，再考虑让AI系统全量上线、减少人工兜底。这个里程碑式的切换方式，能避免系统"还没学会就能输出风险结论"的尴尬期。
6. 把AI工程当作持续运营的产品
最后想聊一个心态问题。很多人误以为AI项目是"训练完模型就结束了"。真实情况恰好相反：模型上线才是工程的开始。数据在变、业务在变、用户行为在变，模型和系统必须跟着变。
我习惯设定固定的迭代节奏，而不是等模型出问题了才去修。每两周做一次评估，每月做一次数据分布回顾，每季度做一次重大版本升级。每次迭代都严格走"数据版本化-模型训练-离线评估-灰度发布-业务指标复盘"这条流水线，形成一套可重复、可预期的循环。最初这样做会觉得繁琐，但坚持一段时间后，团队速度和稳定性反而会明显提升。因为"模型上线"变成了一个普通事件，而不是一次惊心动魄的赌博。
再补充一个小技巧：每次灰度发布时，记得保存当天的线上流量日志，抽样存下来作为后续的召回测试集（regression set）。这些真实样本比任何离线人工构造的数据都更贴近业务。有了这套召回测试集，每次新模型在上线前都可以先跑一遍回归测试，发现新模型在某些类型上明显退化时，就有机会在上线前处理掉。这个小技巧帮我拦下了很多次"指标涨了但局部能力崩了"的问题。
