1. 先分清：你是在做AI实验，还是在做AI工程
“ai-engineering-from-scratch”这个项目名挂在我仓库里已经大半年了。最初我以为它只是一条学习路线图，把算法从线性回归讲到Transformer就算完成。直到自己亲自带过几个真实落地的AI项目，才明白“from scratch”的关键根本不是从头学算法，而是从零搭起一套能让模型稳定运行、持续迭代的AI工程体系。数据怎么接入、特征怎么管理、模型怎么评估、上线之后靠什么兜底，这些问题不解决，再好的算法也走不出实验室。
这几年我看过太多AI项目死在“最后一公里”：模型在离线验证集上指标漂亮，一进生产环境就全线崩溃；或者工程师花两周调参，却花两个月跟特征对齐作斗争。问题从来不在算法，而在工程体系缺位。这篇文章就是我基于一线实战对这套体系的重构记录，适合两类人：刚转行的AI工程师，以及正在把算法往产品里塞的团队负责人。我尽量不堆理论，只讲自己真正验证过的东西。
1.1 模型训练只占项目工作量的三成
先说一个可能不太符合直觉的结论：一个完整的AI项目里，模型训练和调参通常只占三成工作量，剩余七成全部花在数据、评估、上线和运维上。我之前做过一个反欺诈模型，第一次提交可用的XGBoost只花了两周，但为了让它能在生产环境安全运行，我在数据接入层写了三套校验，在评估平台搭建了多维度报表，在监控看板配置了十几条告警，前后折腾了两个多月。不是说模型不重要，而是模型的正确性必须靠工程来证明和保护。
我现在的项目拆解通常长这样：
- 需求拆解：把业务问题转成可优化目标函数；
- 数据盘点与接入：弄清楚有哪些数据可用、成本多大、口径谁定；
- 基线建立：先用简单规则或小模型跑通全链路；
- 特征工程与存储：特征能回放、能追溯、能对比；
- 实验管理：训练实验可复现，参数和数据版本完整；
- 评估体系：离线多维评估加回归集，线上护栏指标；
- 上线部署：灰度发布、监控、回滚预案；
- 持续迭代：样本回流、模型再训练、定期复核。
每一步都可能翻车。很多团队把90%的精力押在第三步的“模型调优”上，结果是模型换了一版又一版，生产环境却连一次稳定运行都没做到。工程这件事没有任何浪漫可言，它就是一份把不确定性一点一点消灭掉的工作。
1.2 实验思维和工程思维的差别，决定项目生死
做算法实验的时候，大家习惯用notebook：加载数据、调个参、画个AUC曲线，看起来不错就结束了。这种“实验思维”本身没有错，它是探索阶段最有效率的方式。但如果你把实验代码直接当生产代码用，就已经埋下了炸弹。
实验思维关注“能不能跑出结果”，工程思维关注“结果能不能重复、能不能被信任、能不能被维护”。我见过最典型的翻车现场：同事三个月前用notebook调出了一个AUC很高的模型，上线时想重新跑一遍训练，结果发现数据当时是从一个临时目录手动下载的，清洗逻辑散落在十几个单元格里，特征构造过程没做记录。最后大家只能凭记忆重建，那个模型也被迫回炉重造。这不是算法问题，这是工程体系缺位。
两者的差别可以浓缩成一张表：
| 维度 | 实验思维 | 工程思维 |
|---|---|---|
| 代码组织 | notebook、脚本堆叠 | 模块化、流水线化 |
| 数据来源 | 本地文件、手工下载 | 数据管道、版本化存储 |
| 模型产物 | 一个训练好的权重文件 | 带版本、带元数据的制品 |
| 评估方式 | 看一眼准确率 | 多维评估加回归集 |
| 上线方式 | 手动保存、直接替换 | 灰度、监控、回滚 |
| 出问题后 | 靠现场排查 | 靠日志、版本、追踪链路复盘 |
所以“ai-engineering-from-scratch”真正的含义，不是从零手写一个神经网络，而是从零建立一套能控制不确定性的体系。模型的参数可以被替换，但数据和工程的地基不能晃。地基稳了，换模型就只是一次普通发布；地基不稳，每一次模型更新都是一次惊险蹦极。
2. 数据侧：80%的AI工程问题都埋在这里
如果只能给一个建议，我会说：把AI项目当成数据工程来做。绝大多数模型上线后的“灵异事件”，深挖下去都是数据问题。数据管道的健壮性、特征定义的一致性、脏数据拦截的及时性，决定了模型在真实环境里能不能立住脚。这一节我把数据侧的几个关键环节拆开讲。
2.1 数据管道当工程来做，别让脚本变成一团乱麻
第一版数据管道通常是一个notebook跑完清洗、特征、标签三条链路。做demo可以，但生产环境千万不能这么干。生产数据管道至少要分五层：原始接入层、清洗与标准化层、特征计算层、标签生成层、训练集构建层。每一层输出一个可被下游引用的表或文件，并带日期分区和版本号。
def build_train_sample(date: str) -> str: raw = read_records(f"ods://events/dt={date}") cleaned = clean(raw, rules_version="20240101") features = compute_features(cleaned, feature_version="20240101") labels = join_label(features, date=date, label_version="20240101") validate_and_write(labels, output=f"features://train/dt={date}") return output这段代码的核心思想是“可重放”：任何时刻重跑同一日期，都应该得到同样的输出。为了做到这一点，原始数据要尽量存成不可变的快照，清洗规则和特征计算代码必须跟着输入变化一起留痕。调度上建议用成熟的任务编排系统，比如Airflow、Prefect这类工具，把每层之间的依赖、重试、报警都管理起来。
我第一次搭数据管道时犯过一个错，觉得调度系统是多余的，直接写了几个shell脚本用crontab定时跑。初期确实没出事，但后来数据量大了以后，某一天上游任务延迟，下游脚本读到了半天的数据，训练集静默产出，模型质量直线下滑，问题是过了两天才被线上指标暴露出来。从那之后我学乖了：任务依赖必须有显式声明，数据覆盖必须有校验，任何一层失败都要能自动重试并告警。
2.2 Schema校验：把脏数据挡在训练和推理门外
数据质量问题是“静默杀手”。比如某天埋点字段类型变了、来源端新增了-1占位符、下游忘记过滤用户注销记录……如果训练前没有校验，模型就会悄悄学到错误规则。这种问题在离线评估阶段几乎不可见，往往要上线后由用户投诉或者业务指标波动暴露出来。
我的做法是在三个节点强制做校验：原始数据接入后、特征计算完成后、训练集生成前。校验工具可以用pandera、Great Expectations，甚至最简单的pydantic也行。核心不是工具选得多花哨，而是规则要覆盖关键字段。
import pandera as pa schema = pa.DataFrameSchema({ "user_id": pa.Column(str), "click_count_7d": pa.Column(int, pa.Check.ge(0)), "price": pa.Column(float, pa.Check.in_range(0, 100000)), "channel": pa.Column(str, pa.Check.isin(["organic", "ads", "referral"])), }) schema.validate(train_df)常见的数据校验规则大概有这几类：非空率是否达到阈值、数值是否在合理范围、类别字段是否在合法白名单里、时间字段是否保持单调、关键字段的分布是否发生突变。不需要试图一次堵住所有问题，先把历史上导致线上事故的Top3原因写成规则，再逐步加严。我见过有团队追求完美校验导致上线进度一拖再拖，那是本末倒置。校验是为了拦截大概率会出问题的高危变更，不是为了证明数据永远正确。
另外，规则更新本身也要记录原因和生效时间。线上推理时同样要走校验逻辑。训练集校验和线上请求校验尽量复用同一套schema，避免两套逻辑不一致。
2.3 特征版本化：回滚不到特征，模型就是瘸腿跑
特征版本化是AI工程里最容易忽略、却最容易出大事的环节。特征会随业务改版而变：产品把“用户近7日点击量”改成“用户近30日点击量”，渠道新增了一个投放来源，价格字段从“分”改成“元”……如果特征定义和模型版本对不上，模型上线后数据分布直接错位。
我踩过一个经典大坑。当时团队优化了一个CTR模型，离线指标提升明显，上线却出现了负面效果。查了很久才发现，特征服务已经更新了“用户点击窗口”的口径，但训练流水线还在用旧版特征，导致离线评估时使用的是旧特征，而线上推理使用的是新特征，评估结果自然失真。那次事故之后，我们强制要求：每个特征必须有定义文档、创建时间、责任人；特征计算代码进版本库；训练集文件名带特征版本号；模型注册时显式绑定特征版本。
回到现实中，可以加一道“离线回放”验证：抽一条线上真实请求，用当前特征工程代码回放计算，与线上特征服务输出做对比，误差超过阈值就报警。这样可以提前发现“离线特征”和“线上特征”悄悄分叉的问题。特征存储不用追求一键全自动，先把版本和口径管住，再考虑更复杂的Feature Store平台。
3. 模型侧：评估体系决定你有没有资格上线
数据问题解决之后，模型评估是第二道关卡。我见过太多团队评估模型时只看一个数字，比如准确率或者AUC，然后拍脑袋决定上线。这样的流程非常危险。模型评估需要一套体系，能回答“这版模型到底哪里比旧版好、哪里比旧版差、上线后业务是否真的受益”三个问题。
3.1 单点指标会骗人，建一套多维评估矩阵
准确率在商业场景里特别会骗人。拿风控举例，负样本只占0.2%，模型把所有样本都预测成负类，准确率就是99.8%，看起来完美，实际上一条欺诈都没拦住。这种“看似优秀、实则废物”的模型，只盯单点指标永远发现不了。
按业务场景选择核心指标更靠谱：
| 业务场景 | 核心指标 | 理由 |
|---|---|---|
| 推荐/排序 | NDCG、Recall@K | 重点在排序，关注头部结果质量 |
| 风控/反欺诈 | 召回率、代价敏感误伤率 | 漏掉坏人损失高，误伤影响体验 |
| CTR/CVR预估 | AUC、LogLoss | 需要概率校准，不只是排序 |
| 文本分类 | macro F1、混淆矩阵 | 类别严重不均衡时单看accuracy失真 |
| 回归预测 | MAE、分位数误差 | 避免个别极端值掩盖普遍误差 |
做评估不要只看均值。我负责过一个定价模型，整体MAPE很低，但在价格分布两端误差非常大。后来把误差按价格分桶、按用户分层、按渠道分组来看，问题立刻暴露出来。模型不是要“平均好”，而是要在关键业务切片上稳定。给业务方汇报时，最好能说清楚“模型在哪些人群上表现好、在哪些场景下表现差”，这比一个空洞的AUC数字有说服力得多。
3.2 离线评估和在线指标之间的天然缝隙
离线评估做得再精细，和线上真实表现之间也一定有缝隙。原因很简单：离线评估的前提是“历史数据分布近似未来线上分布”。这个前提不总成立。常见的缝隙有三类：时间穿越、采样偏差、样本选择偏差。
时间穿越是最隐蔽也最致命的。我见过一个CTR模型，离线AUC从0.75涨到0.85，仔细查代码才发现特征工程里用了“用户最近一次点击时间”，而标签恰好就是“该用户本次是否点击”。这等于拿答案预测答案，离线指标当然漂亮，上线之后必崩。要防住这一点，训练样本构建时所有特征必须只使用预测时刻之前的数据；每次新增特征都要做“lookahead审计”，写自动化脚本检查特征时间戳晚于标签时间戳的样本占比，超过阈值就报警。
采样偏差和样本选择偏差也常见。比如线下抽样只取某几天的数据，没有覆盖全周；或者只对已转化用户统计特征，导致线上冷启动用户特征大面积为空。处理方式也不复杂：抽样时按时间、按渠道做分层，特征统计必须从全量口径计算，不能从已转化子集中反推。
3.3 回归测试集：防止修好东墙拆了西墙
模型迭代最怕“漂移式进步”：整体指标上升了，但某些关键case反而变差了。第二次迭代时，如果只看整体指标，你可能永远发现不了模型对某类重要流量偷偷“失明”。这就是回归测试集存在的意义。
回归测试集是一份固定的、不会被新样本污染的评测集。每次更新模型都必须在这份集上跑一遍，并且要比较新旧模型在关键case上的表现差异。实操上，回归集不能只存特征文件和标签，还要保存每条样本的来源ID、旧模型预测结果、真实标签，方便之后复盘。线上发现了badcase，要及时回流补充进回归集。
下面这种表格非常有用：
| 样本ID | 旧模型预测 | 新模型预测 | 真实标签 | 备注 |
|---|---|---|---|---|
| A10001 | 0.72 | 0.34 | 1 | 新模型漏判，渠道：ads |
| A10002 | 0.18 | 0.51 | 0 | 新模型误报，品类：低价 |
我习惯把回归集分成“核心保护集”和“探索集”。核心保护集基本固定，用来守护业务命脉；探索集定期扩充，吸收线上新case。模型上线前必须过一遍检查清单：跑全量回归、看关键case差异、查特征覆盖率是否下降、确认推理耗时无回退。这一套下来，虽然每次迭代新模型都要多花一两天，但能拦住大量“离线好看、线上翻车”的情况。
4. 运营侧：模型上线只是亡羊补牢的开始
很多团队以为模型上线就是项目结束，实际上上线那一刻才是真正进入长期维护阶段。模型失效往往不是一瞬间的崩溃，而是缓慢的、不易察觉的技能退化。运营侧要解决的核心问题是：当模型开始变差时，你能不能及时发现、定位原因、并且安全地切换回去。
4.1 模型监控：别把AI系统当成普通Web服务监控
传统应用监控看CPU、内存、QPS、错误率，只要服务不宕机就万事大吉。AI系统多了一层“模型有效性”的监控：服务可能一直返回200，但模型已经在给出一堆垃圾预测。业务方只看到指标掉了，技术这边却找不到异常，因为系统层面一切正常。
我的监控矩阵分四层：
- 系统指标：CPU、内存、推理延迟、QPS；
- 数据质量指标：特征缺失率、非法值率、字段格式异常率；
- 分布漂移指标：输入特征分布、模型输出分布；
- 业务护栏指标：转化率、客诉量、覆盖率、关键漏斗变化。
模型输出分布的监控尤其简单有效。比如每天画一张预测分数的直方图，如果整体分布明显偏移，大概率有外部环境变化或者上游数据口径变更。告警配置原则是“把能自动算的先自动算，再由人来判断该不该动”，不要在第一时间就让团队陷入告警疲劳。之前我们设置过十几条告警，结果全是误报，大家逐渐无视告警，反而错过了真正重要的那次漂移。后来砍掉一半规则，保留真正有区分度的指标，告警才有意义。
4.2 数据漂移不是玄学，用PSI就能抓
数据漂移指的是线上推理时的输入分布和训练时的分布不一致。常见诱因包括产品改版、渠道结构调整、用户行为变化、节假日效应，甚至数据口径悄悄改动。特征层面感知漂移，最常用的指标是PSI（Population Stability Index）。
import numpy as np def compute_psi(expected, actual, bins=10): expected_hist, edges = np.histogram(expected, bins=bins) actual_hist, _ = np.histogram(actual, bins=edges) expected_ratio = expected_hist / len(expected) actual_ratio = actual_hist / len(actual) psi = 0 for exp, act in zip(expected_ratio, actual_ratio): if exp == 0 or act == 0: continue psi += (act - exp) * np.log(act / exp) return psiPSI的计算也不复杂：把训练期的特征分布作为基准，把线上最近一段时间的特征分布作为实际，比较两者在各分箱中的比例差异。经验阈值大概是PSI小于0.1属于稳定，0.1到0.25需要关注，大于0.25就要介入排查。离散特征可以用卡方检验或者直接对比各取值的占比变化。
有一点要强调：漂移指标升高不一定是坏事。大促期间全场特征分布都会剧烈变化，这时候PSI高是正常的业务波动，不需要立刻干预。监控工具的意义是标记“需要人去看一眼”的时刻，而不是替代人去判断“现在是不是该重训模型”。
4.3 灰度发布和回滚：AI系统最后的安全绳
模型更新最忌讳一次性全量替换。哪怕离线评估指标再好，线上流量也会带来意想不到的惊喜。稳妥的流程是先让新模型接5%流量，观察核心护栏指标，确认无异常后再逐步放量到10%、30%、50%、100%。每一步都要有明确的观察期和退出标准。
灰度期间最好配合A/B测试，让一部分用户走新模型、一部分用户走旧模型，对比业务指标是否真的有提升。模型注册表要把模型制品管好：模型文件、预处理代码、特征版本、训练数据版本、评估报告都要关联起来。
回滚机制要提前演练，不能等到出事再想。我有一条血泪教训：某次新模型灰度到50%时，上游特征服务接口变更，线上特征大面积缺失。想回滚旧模型，结果发现旧模型依赖的旧特征服务已经被下线了，只能紧急重建，业务抖动了半天。后来我们形成纪律：每次灰度前，先确认完整回滚路径。回滚的不仅是模型文件，还有配套的特征计算逻辑和预处理代码。
现在我做模型发布，必做三件事：第一，灰度前先在预发环境跑一遍全链路，确认推理输入输出格式正确；第二，准备好一键回滚脚本，并每月演练一次；第三，发布后第一小时盯紧模型输出分布和业务护栏指标，有问题立刻切回。这套动作虽然繁琐，但它在真实事故中帮我省下了很多补救成本。
回到“from scratch”这件事，我个人的体会是：AI工程的起点不是“从零实现一个模型”，而是“从零确认每一个环节都可控”。数据可回放、特征可追溯、模型可评估、发布可回滚，这四件事做到位，AI项目成功率会提高一个量级。如果你恰好也在搭建自己的体系，可以从这四个零件开始，一块一块补，不必一次性追求完美。先跑通链路，再逐步加固，比一开始就设计一个庞大平台要现实得多。
