从"调包侠"到"手写派"，我为什么把 AI Engineering 从头学起
大概两年前，我还处在"调包一时爽，一直调包一直爽"的阶段：拿一个预训练模型，套一层 API，跑通一个 notebook，就觉得自己已经会人工智能了。直到有一次，业务方拿着一个线下 AUC 很漂亮的模型做线上验证，结果用户反馈一塌糊涂。我打开线上日志一看，特征分布和训练时完全对不上，我当时甚至找不到模型到底喂的是什么特征。那一刻我才意识到，我缺少的不是"调模型"的能力，而是 AI Engineering 的底层功底。也是从那天起，我开始沿着一条"from scratch"的路线重学 AI 工程：不依赖现成框架的封装，把数据、训练、部署、监控这条链路的每一环都亲手搭一遍。
这篇文章就是我这套"从零开始"学习路线的完整复盘，包括我为什么要这样学、每一步具体做了什么、踩了哪些坑，以及哪些地方其实不该从零写。内容偏工程实践，不是理论科普，适合那些已经在用现成框架跑模型、但真正上线时总感觉心里没底的人，也适合理清 AI Engineering 到底要学什么的入门者。
1. 先搞清楚 AI Engineering 在解决什么问题，而不是急着装环境
我把"从零开始"的第一站定在定位问题，而不是安装 TensorFlow 或 PyTorch。因为回头看，大多数人学 AI 工程学到最后学成一堆碎片知识，根源就是没搞明白自己到底在解决哪一类问题。
1.1 数据科学、机器学习研究与 AI 工程的分界线
我在网上看过无数张"AI 岗位图谱"，画得都挺复杂。我自己用一句话总结三者的区别：
- 数据科学：核心是"从数据里发现规律"，产出通常是分析报告或实验结论，不一定要有稳定的在线服务。
- 机器学习研究：核心是"提出新模型或新算法"，产出是论文或开源代码，追求在基准数据集上的指标突破。
- AI Engineering：核心是"让模型在真实系统里稳定、可靠、持续地发挥价值"，产出是可维护、可观测、可迭代的软件系统。
AI Engineering 的特殊之处在于，它横跨了软件工程和机器学习两个领域。一个模型从 notebook 到生产环境，要经历数据校验、特征一致性、推理性能优化、监控告警、模型版本管理、灰度上线、回滚等一系列环节，这些没有一个是"训练"本身，但每一个都可能让模型在线上彻底失效。
1.2 一个从零开始的人最容易犯的方向性错误
我观察到的最典型错误是：用"学算法"的方式去学"AI 工程"。具体表现就是扎进深度学习理论里，把 Transformer 的各种变体如数家珍，但让他描述一下自己线上模型的延迟预算、吞吐上限、特征更新周期，却答不上来。
另外一个常见错误是反过来：完全倒向纯工程，认为只要会用 Docker、K8s、MLflow 就算 AI 工程了。这也是误区。AI 工程的核心对象是"数据 + 模型 + 系统"三者的结合，只懂容器编排而理解不了训练和推理的本质区别，照样会在模型部署时做出灾难性的技术选型。
1.3 给自己定一条"从零到能上线"的主线
基于这个认知，我给自己定了一条完整的学习主线，后面所有内容都是沿着这条线展开的：
- 数据链路：从零搭建数据获取、清洗、特征工程、数据版本管理。
- 训练链路：手写训练循环，理解反向传播、优化器、评估指标。
- 服务链路：把训练好的模型封装成服务，处理好特征对齐与推理优化。
- 运维链路：评估盲区、线上监控、反馈闭环。
这条主线最大的价值是：每一步都以前一步为输入，形成一个能真正端到端跑通的最小系统。学完它之后，再去看 MLflow、Kubeflow、Feast 这些工业级工具，心里就有一张地图了。
提示：如果你也是从零起步，建议至少用一张纸画出这条主线的每个环节，标记出"现在最不熟的那个环节"，先攻它。不要跟着网上的课程清单从头线性刷，那些清单多半是罗列，不是系统。
2. 动手第一部分：从零写数据管线，才算真正碰过数据
我在"from scratch"路线上做的第一个大工程，是不用任何数据 pipeline 框架，用 Python 自己写一条完整的数据处理流程。听起来很原始，但这个阶段给我带来的收益远超预期——它让我第一次理解了框架背后到底隐藏了多少脏活。
2.1 为什么我拒绝直接用现成的 pipeline 框架
市面上有很多现成方案，比如 Airflow 做调度、Feast 做特征存储、Great Expectations 做数据校验。直接用它们当然没错——生产环境里我强烈推荐这么干。但作为"从零开始"的学习项目，我故意没用。
原因很简单：框架把复杂度藏起来了，而你需要在某个阶段亲手把它揭开一次。比如用 Airflow 时，你只需要写好 DAG 就能调度任务，但你不会真正理解"任务依赖、失败重试、幂等性"这些概念在数据场景下为什么重要。当我亲手写过一条带重试机制的数据加载脚本之后，再去看 Airflow 的 retry 参数，感受完全不同。
2.2 手写数据加载、清洗与特征变换的核心环节
我选了一个公开的电商点击数据集作为实验对象，数据量不大，但足够真实。这条手工管线我实现了四个核心环节：
数据加载：我故意模拟了"生产中可能出现的一切异常"——文件缺字段、编码不一致、时间戳格式混乱。写加载器的关键不是用 pandas 一读了事，而是要对数据做schema 校验：
import pandas as pd from typing import Dict, List, Optional REQUIRED_COLUMNS = {"user_id": "int64", "item_id": "int64", "timestamp": "datetime64[ns]", "click": "int8"} def load_and_validate(path: str) -> pd.DataFrame: df = pd.read_csv(path, dtype=REQUIRED_COLUMNS, parse_dates=["timestamp"]) missing = set(REQUIRED_COLUMNS.keys()) - set(df.columns) if missing: raise ValueError(f"数据缺少必要字段: {missing}") # 空值比例超过阈值直接拒绝，而不是悄悄填充 null_ratios = df.isnull().mean() if (null_ratios > 0.05).any(): raise ValueError(f"存在空值比例超过5%的列: {null_ratios[null_ratios > 0.05]}") return df这里有个我后来才想透的设计点：数据加载阶段就必须"严进"，错误要尽早抛出。很多数据事故不是模型出了问题，而是脏数据悄悄混进了训练集和线上特征流，导致模型在错误的前提下"正常"工作。
清洗逻辑：我把清洗动作拆分成了独立的、可测试的小函数：去重、异常值截断、时间戳规范化、用户行为序列排序。每个函数都配上单元测试，这一习惯让我在后面扩展特征时吃了大红利。
特征变换：我在这一层实现了一组基础特征——用户历史点击率、物品最近7天热度、用户活跃时段等。最有价值的练习是做特征的时间一致性处理：特征计算时只允许使用"预测时刻之前"的数据，禁止把未来信息泄露进去。这一点在手工实现里很难做错，但如果直接用一些自动特征工程库，反而很容易在不经意间引入泄露。
2.3 数据版本化的坑：一份数据在训练和上线时不一致
这条手工管线让我踩了最深刻的一个坑：训练时统计的归一化参数，到了线上推理时没有对齐。
具体场景是：我给用户的历史点击率做了 min-max 归一化，训练时 min 是 0.02，max 是 0.87。线上服务启动后，模型拿到的特征全部是 0.5 上下——因为线上统计的 min、max 变成了 0.1 和 0.95。整个模型相当于被喂了一组分布完全不同的输入，效果当然崩。
解决方式很简单但容易被忽视：把训练阶段计算得到的统计量序列化成一个 schema 文件，线上推理时强制加载同一个文件。
{ "feature_click_rate_7d": { "type": "continuous", "norm_min": 0.02, "norm_max": 0.87, "impute_value": 0.0 } }我同时给数据文件加了版本号，每次改动特征时递增版本，并在模型训练时把这个版本号写进模型的元信息里。这样线上服务加载模型时能自动校验"模型期望的特征版本"和"当前特征版本"是否一致，不一致就直接拒绝启动。
注意：数据版本化是我认为"AI 工程"区别于"机器学习 demo"的第一个关键分水岭。没有版本控制的数据 pipeline，本质上还停留在实验阶段。
3. 手写训练循环：反向传播、优化器与评估，一个都不能省
第二条主线是训练链路。这一部分我没用高级框架里的 Trainer API，而是用纯 Python + NumPy 手写了一个两层神经网络的完整训练循环。不是因为手写的比 PyTorch 好，而是因为只有失去框架的保护之后，你才会开始关注那些被框架自动处理、但上线时至关重要的细节。
3.1 用纯 Python + NumPy 实现一个两层网络
这个练习的完整代码不算长，核心就这几块：前向传播、损失计算、反向传播、参数更新。
import numpy as np def relu(x): return np.maximum(0, x) def forward(X, W1, b1, W2, b2): Z1 = X @ W1 + b1 A1 = relu(Z1) Z2 = A1 @ W2 + b2 return Z2, (Z1, A1) def loss_fn(logits, y): # 二分类交叉熵，带数值稳定性处理 logits = np.clip(logits, -30, 30) return np.mean(np.logaddexp(0, -logits * (2 * y - 1))) def backward(X, y, logits, cache): Z1, A1 = cache m = X.shape[0] dZ2 = (2 * y - 1) * (1 / (1 + np.exp(-logits)) - y) # 二分类场景的简化梯度 dW2 = A1.T @ dZ2 / m db2 = np.mean(dZ2, axis=0) dA1 = dZ2 @ W2.T dZ1 = dA1 * (Z1 > 0) dW1 = X.T @ dZ1 / m db1 = np.mean(dZ1, axis=0) return dW1, db1, dW2, db2写这段代码时我犯过一个经典错误：ReLU 的梯度在 Z1 正好等于 0 时被我置为 0，这没问题；但我在反向传播时忘了把梯度除以 batch size，导致 loss 曲线剧烈震荡。框架自动处理了这些统计性细节，手写时每个都要自己盯着——这恰恰是练习的意义。
3.2 训练循环里必须自己控制的三个细节
手写完训练循环后，我总结出三个框架帮你做了、但你必须理解的细节：
参数初始化。我第一次用全 0 初始化，结果两层网络训了半天 loss 纹丝不动，因为梯度对称性问题让所有神经元学到了同样的特征。后来改用 He 初始化（np.random.randn * np.sqrt(2 / fan_in)），问题立刻缓解。初始化是训练能否收敛的第一道关卡。
学习率的调整策略。我从固定学习率起步，0.1 时 loss 发散，0.001 时收敛太慢。手工实现了简单的余弦退火后，收敛速度和质量都明显提升。你只有在手写时才会体会到：学习率不是一次定死的超参数，而是一个需要随训练动态调整的决策。
梯度裁剪。在训练初期某个异常样本的梯度特别大时，参数会被推到很远，然后再也回不来。加了 max_norm 梯度裁剪后，训练稳定性提升非常明显。PyTorch 一个 API 就能做这件事，但它背后的动机只有在你见过"参数爆炸"后才真正理解。
3.3 从"能跑"到"收敛"：我踩过的三个训练坑
这一步我详细记录一下排查过程，因为它代表了一类典型问题：模型能跑，但效果不对。
第一个坑是 loss 出现NaN。我先打印了中间变量的统计值，发现数据里有缺失值被 pandas 编码成了负数，经过 log 运算后直接 NaN。修复方式是在数据清洗阶段增加缺失值显式标记，而不是让 NaN 一路传进训练。
第二个坑是训练集准确率极高，验证集极低——明显的过拟合。我把网络从两层扩到四层后这个现象变严重了，最后靠 dropout 和数据增强压下去。这不算特别深刻的教训，但让我养成了每次都记录"训练集/验证集指标差"的习惯。
第三个坑最有价值：评估指标骗人。我用准确率评估二分类模型，测试集上 92%，看似不错；但我打印 confusion matrix 后发现，正负样本比是 1:9，模型学会了"全部预测为负样本"。准确率 90% 以上，实际毫无用处。后来换成 AUC + Precision/Recall，才看到真相。
经验之谈：手写训练循环不需要做很复杂的模型。用最简单的网络把手动反向传播、评估、调参跑通一遍，你对框架 Trainer 的信任就不再是盲目的——你知道每一步底层在发生什么。
4. 从训练到服务：模型部署时不只是把权重保存下来
训练完一个指标不错的模型之后，我遇到了"from scratch"路线上最痛苦的一环：把它部署成一个能在线使用的服务。这一环的坑密度，远超我的预期。
4.1 为什么一个能训练好的模型不能直接上线
最初我想得很简单：模型训练完了，把权重存成文件，写个 Python 脚本加载权重，接收请求算个预测，完事。结果第一次联调就发现问题：训练脚本里的特征处理逻辑和线上脚本里写的不完全一致。
我排查了很久，最后发现一根非常隐蔽的线：训练时我把用户 id 做成了整数编码，编码表存进了训练脚本所在目录的一个 pickle 文件；部署时我复制代码却漏了那个 pickle 文件，新用户和旧用户的编码出现了错位。模型接收的每个特征数值，含义都和训练时对不上。
这个经历让我明白了一个核心道理：部署本质上是"保持训练环境与生产环境在数据语义层面的一致"。权重文件只是模型的一部分，特征计算逻辑、编码映射、归一化统计量，每一个都是模型的一部分。
4.2 自己搭一个最小推理服务，理解特征对齐
为了解决这个问题，我给自己定了一条规矩：训练和推理必须共享同一份特征计算代码。
我把特征工程代码抽成了独立模块，训练脚本和推理服务都从同一个包导入。具体实现时用 FastAPI 搭了一个最小推理服务：
from fastapi import FastAPI from pydantic import BaseModel from model_pkg.features import build_features from model_pkg.preprocess import normalize app = FastAPI() model = load_model("artifacts/model_v3.pkl") class PredictRequest(BaseModel): user_id: int item_id: int timestamp: str history: list[dict] @app.post("/predict") def predict(req: PredictRequest): raw = req.dict() features = build_features(raw) features = normalize(features, schema_path="artifacts/features_schema_v3.json") prob = model.predict_proba(features)[0][1] return {"probability": float(prob)}这里最关键的设计是：build_features和normalize与训练时使用的完全是同一份代码，而且通过 schema 文件强制校验。训练完成后我会把模型和 schema 打包成一个 artifact，部署时只使用这个包，不重新写任何特征逻辑。
4.3 推理优化的常见手段与取舍
部署跑通之后，我又遇到性能问题：单次请求预测耗时 80ms，但业务方要求 P99 小于 50ms。我尝试了几个优化手段，从易到难：
批处理。把多个请求合并成一个 batch 做矩阵运算，吞吐提升明显。缺点是增加了单请求的等待延迟，实现时要小心不要让 batch 凑不齐导致请求挂起。我设了一个 10ms 的等待窗口，窗口内到了 32 条请求就立即处理。
量化。把模型权重从 float32 转成 float16，延迟直接减半，准确率几乎无损。这个操作在 PyTorch 里一行代码搞定，但在生产环境要小心 CPU 上的 float16 支持情况。我实测下来，如果部署机器不支持加速指令，float16 反而更慢。
特征缓存。用户统计特征的重复请求率很高（同一用户短时间内多次请求），我加了一层简单的 LRU 缓存，把特征计算耗时降到了接近 0。缓存时需要额外考虑 key 的设计——我在 key 里包含了特征 schema 版本号，避免 schema 更新后命中旧缓存。
提示：推理优化的顺序很重要。先解决"算法层"（batch、缓存），再解决"硬件层"（量化、专用推理引擎）。一上来就引入复杂的推理框架，往往收益不大还增加运维负担。
5. 一个人扛下生产环境的隐形工程：评估、监控与反馈闭环
模型上线的那一刻，我以为最难的部分结束了。事实证明，上线只是 AI Engineering 的开始。前面所有环节的失误，都会在运行阶段以各种诡异的形态冒出来。
5.1 离线评估的三大盲区
我在离线测试集上验证过的模型，上线后依然出现各种问题，盘点下来有三类离线评估覆盖不到的盲区：
第一，时间分布偏移。我的训练数据是过去三个月的，测试集也是同分布采样，所以离线表现很好。但线上流量天然包含"未来时刻"，当用户行为模式发生变化（比如节假日、促销活动），模型就失效了。解决方式是做时间序列切分验证：用前两个月训练、后一个月验证，模拟真实的时间递进关系。
第二，反馈延迟。很多业务场景的标签不是立刻产生的——用户点击后是否购买可能要等几天才能确定。离线评估时我用了即时标签，线上评估时才发现标签还没到齐。这直接影响了模型更新策略的设计。
第三，群体偏差。离线评估看整体 AUC 时一切正常，但按用户群体分层评估后发现，新用户群体 AUC 只有 0.52。原因是新用户的特征稀疏，模型学不到有效模式。从那以后，我把评估指标一律拆成"整体 + 分群"两部分，至少看活跃用户、新用户、高价值用户三个群体。
5.2 线上监控指标怎么选：不只是准确率
模型上线后我一度只监控准确率，直到某天准确率从 88% 掉到 55%，而我浑然不觉——因为那个模型本来就是处理正负样本不平衡问题的，准确率本身就不是它的核心指标。
我重新设计了监控体系，分成三层：
数据健康指标：特征覆盖度、特征分布距离（我用的是 PSI，群体稳定性指数）、请求量波动。任何一层异常都意味着"喂给模型的数据变了"。
模型行为指标：预测均值的滑动平均、预测分布直方图、正类率。如果模型整体预测概率突然抬高，常常意味着特征分布偏移或上游行为改变。
业务效果指标：AUC（有延迟标签时）、转化率、用户满意度。这层是最终价值所在，但反馈延迟也最大。
# 一个轻量的 PSI 计算片段，用于特征分布监控 def calculate_psi(expected: np.ndarray, actual: np.ndarray, bins: int = 10) -> float: expected_hist, edges = np.histogram(expected, bins=bins) actual_hist, _ = np.histogram(actual, bins=edges) expected_ratio = np.clip(expected_hist / expected_hist.sum(), 1e-6, 1) actual_ratio = np.clip(actual_hist / actual_hist.sum(), 1e-6, 1) psi = np.sum((actual_ratio - expected_ratio) * np.log(actual_ratio / expected_ratio)) return float(psi)我设的经验阈值是：PSI 小于 0.1 表示稳定，0.1 到 0.25 需要关注，超过 0.25 必须告警触发重训。这个阈值不是理论值，而是我在几个数据集上试出来的经验值。
5.3 从用户反馈到数据回流：最容易被忽略的闭环
最后一个环节最容易被忽略，也最让我受益：模型产生预测后，怎么把后续的真实结果收集回来，形成可训练的新数据。
一开始系统只有"请求日志 + 预测结果"，没有后续行为标签的采集逻辑。后来我加了一个简单的标签回填流程：用户对推荐物品的后续点击/购买行为会通过埋点写入事件表，然后一个定时任务将事件与之前的预测请求关联，生成新的训练样本。
这个闭环的价值有两个层面：一是提供了新训练数据，让模型能跟上分布变化；二是提供了线上真实表现数据，让离线评估方法可以持续被校验。如果你发现线上指标和离线指标长期对不上，多半是反馈闭环出了问题，而不是模型效果问题。
6. 复盘：这条"从零开始"的路踩过的坑，以及什么样的项目值得从零写
最后做一次整体复盘。我不打算把话题收得很"圆满"，因为 AI Engineering 本身就是一条没有终点、只有持续踩坑和补课的路。但有几条经验，我觉得对后来者确实有直接参考价值。
6.1 时间分配建议：哪些必须从零写，哪些直接用
从零写了很多代码之后，我整理了一张"值得/不值得从零开始"的对照表，给后来者做参考：
| 环节 | 我的做法 | 建议 | 理由 |
|---|---|---|---|
| 特征计算与清洗 | 手工实现 | 至少手写一次 | 这是数据语义的源头，不亲手做一次难以理解特征一致性 |
| 训练循环与反向传播 | 纯 NumPy 手写 | 至少手写一次 | 理解梯度、优化器、学习率背后的机制 |
| 模型结构 | 手写两层网络 | 直接用框架 | 复杂结构手写没有学习价值，框架更可靠 |
| 推理服务 | FastAPI 手写 | 可以手写可以框架 | 重点是特征对齐，不是服务框架本身 |
| 监控告警 | 手写 PSI 脚本 | 生产环境用成熟方案 | 成熟监控平台功能完备，手写维护成本高 |
| 工作流调度 | 手写重试逻辑 | 直接用 Airflow 等 | 调度器的分布式可靠性是手写很难覆盖的 |
这个原则可以总结成一句话：凡是锤炼"数据理解"和"模型原理"的环节，值得从零写一遍；凡是解决"分布式可靠性"和"规模化运维"的环节，直接用成熟工具。
6.2 我现在的工程 checklist
项目做到现在，我每次上线新模型都会过一遍这个 checklist，它也基本就是本文所有内容的浓缩：
- 数据 schema 是否有版本号？训练和线上加载的是否为同一份？
- 特征计算代码是否训练/推理共享？归一化统计量是否固化为文件？
- 评估是否做了时间序列切分和分群评估？正负样本比例是否记录？
- 模型 artifact 是否包含权重、特征 schema、预处理参数、版本号四件套？
- 推理服务是否有特征版本校验，版本不匹配时是否拒绝启动？
- 监控是否覆盖数据健康、模型行为、业务效果三层？
- 反馈闭环是否能把线上预测结果和后续真实标签关联回填？
每次过这个清单都让我想起最初那个线上翻车的模型——当时如果有一条满足，那场事故可能就不会发生。
6.3 我给后来者的三点具体建议
如果你也想走一遍"AI engineering from scratch"，我的建议很朴素：
第一，选一个真实但可控的场景。不要用玩具数据集，也不要一上来挑战工业级规模。一个中等规模的公开数据集，加上一个能说清楚业务价值的预测问题，就足够。
第二，每一环都要产出"可检查的 artifact"。数据版本、schema 文件、训练日志、评估报告、模型包，都当成正式产物保存。这不仅帮助你 debug，也逼你把每个环节做扎实。
第三，主动制造故障来测试系统。我在跑通完整链路后做了一次"故障演练"：故意改掉特征计算函数的一行代码，看看监控能否发现、部署校验能否拦截。结果还真有漏网之鱼，这也成了我加"版本校验"功能的直接原因。
回头看这两年的经历，我最深的感受是：AI Engineering 的门槛不在于模型有多复杂，而在于你愿不愿意把一个简单模型当作一个严肃的软件系统去对待。特征对齐、数据版本、监控体系这些"不性感"的环节，才是线上模型真正靠谱的基石。如果有人问我从零到一最该从哪一步开始，我的答案不是学框架，不是刷论文，而是先亲手处理一批真实数据，把它变成一条可靠的、可重复运行的数据管线——从那一步开始，你才算真正踏进了 AI Engineering 的门。
