1. 从零搭建AI工程能力为什么“会调包”远远不够很多人第一次接触AI工程是从一行model.fit()或者一个pip install transformers开始的。跑通一个Demo看着损失曲线往下掉准确率往上走就觉得自己“入门AI”了。但真正到了要交付一个能扛住真实流量、能持续迭代、能被人维护的系统时才发现自己手里只有一堆散落的脚本和几个不知道什么时候会崩的Notebook。ai-engineering-from-scratch这个标题核心不在“AI”而在“engineering”和“from scratch”。它指向的是一类非常具体的人不满足于调包跑通而是想搞清楚一个AI系统从数据进到结果出中间到底经过了哪些环节、每个环节的工程约束是什么、哪些地方最容易出问题。这篇文章就是围绕这个目标展开的适合有一定Python基础、做过几个小项目、但还没系统梳理过AI工程全链路的人。我会把从数据管道、特征处理、模型训练、评估、部署到监控的完整链条拆开讲重点放在那些“文档里不会写、但实际会卡住你”的地方。先说一个反直觉的结论AI工程项目里真正花在模型结构设计上的时间通常不到总时间的百分之十。剩下百分之九十全在数据清洗、特征一致性、训练与推理的偏差对齐、服务稳定性这些“脏活”上。一个刚入行的人如果只盯着模型做出来的东西大概率是“实验室能跑线上就崩”。所以这篇内容的主线是把工程视角贯穿始终而不是再讲一遍Transformer或者梯度下降。2. 数据管道从原始文件到可训练张量的完整链路2.1 为什么数据管道的设计决定了项目上限我见过太多项目模型换了一茬又一茬指标就是上不去最后发现问题出在数据管道上——训练时用的特征和推理时算出来的特征压根不是同一套逻辑。这种问题在Demo阶段完全看不出来因为Demo里训练和推理用的是同一份数据、同一段代码。一旦拆成两个服务偏差就出来了。数据管道的核心目标只有一个保证任何时刻、任何来源的数据经过这条管道后产出的张量在语义和数值分布上是一致的。听起来简单做起来要处理的事情包括缺失值怎么填、类别特征怎么编码、数值特征怎么归一化、时间序列怎么切窗口、样本怎么采样。每一个决策都会影响最终模型的行为而且这些决策必须被记录下来否则你没法复现。2.2 用配置文件驱动数据处理的每一步从零搭建时我强烈建议不要把所有处理逻辑写死在代码里而是用配置文件描述“做什么”代码只负责“怎么做”。比如用一个YAML文件定义每个字段的处理方式fields: age: type: numeric missing: median normalize: standard city: type: categorical encoding: onehot max_categories: 50 signup_date: type: timestamp features: [day_of_week, hour, days_since_epoch]这样做的好处是训练和推理可以共用同一份配置只要配置不变处理逻辑就不会漂移。我试过在项目里引入这种配置驱动的方式后训练和推理的特征偏差问题直接减少了八成以上。而且当你要加一个新字段时改配置比改代码安全得多也更容易做代码审查。2.3 训练与推理的特征一致性校验光有配置还不够你还需要一个校验机制。我的做法是在管道里加一个“特征快照”步骤每次处理完一批数据把每个特征的统计量均值、方差、分位数、类别分布记录下来存到一个地方。训练前拿训练集的快照和推理集的快照做对比如果某个特征的分布偏移超过阈值就报警。这个校验在离线阶段就能发现很多问题。比如某次我加了一个新特征训练集里这个特征有百分之三十的缺失我用中位数填充了但推理服务里这个字段是必填的缺失率为零。结果模型在线上对这个特征的依赖程度和训练时完全不一样指标直接掉了一截。如果没有这个校验这种问题要等到线上出事故才会被发现。提示特征快照的统计量不要只存均值和方差对于长尾分布的特征分位数比均值更能反映真实分布。我一般会存P1、P25、P50、P75、P99这五个点。3. 模型训练工程让每次实验都可复现、可比较3.1 实验管理不是可选项是必选项从零做AI工程最容易忽略的就是实验管理。很多人训练模型就是改改代码、跑一下、看看结果然后接着改。跑了几十次之后自己也记不清哪次用了什么参数、哪次的数据集是哪个版本。等到要写报告或者复现最佳结果时完全抓瞎。我的做法是从第一天就引入实验追踪。不需要多复杂的工具一个简单的方案是每次训练自动生成一个实验ID把超参数、数据版本、代码commit哈希、环境依赖版本、最终指标全部写到一个JSON文件里按实验ID归档。同时把模型权重也按实验ID命名保存。这样任何时候你都能回答“这个结果是怎么来的”。import json, hashlib, subprocess from datetime import datetime def log_experiment(config, metrics, model_path): exp_id hashlib.md5( (str(config) datetime.now().isoformat()).encode() ).hexdigest()[:12] record { exp_id: exp_id, config: config, metrics: metrics, model_path: model_path, git_commit: subprocess.check_output( [git, rev-parse, HEAD] ).decode().strip(), timestamp: datetime.now().isoformat() } with open(fexperiments/{exp_id}.json, w) as f: json.dump(record, f, indent2) return exp_id这段代码很朴素但它解决的是“可复现”这个核心问题。你不需要一开始就上MLflow或者Weights Biases但你必须有一个地方能查到每次实验的完整上下文。3.2 训练循环里必须埋进去的三个监控点训练不是跑完看最终指标就完事了。我在训练循环里一定会监控三个东西梯度范数、学习率实际值、每层的激活值分布。梯度范数突然变大说明可能遇到了异常样本或者学习率太高学习率实际值和设定值对不上说明调度器配置有问题激活值分布如果某一层全部趋近于零说明那层已经“死”了。这些监控不需要很复杂每N个step打印一次或者写进日志就行。关键是你要在训练过程中看而不是等训练完了再回头分析。我踩过的坑是有一次训练了八个小时最后发现中间有三个小时梯度一直是NaN模型早就不更新了但因为没监控白白浪费了算力。3.3 检查点策略什么时候存、存什么、怎么清理检查点不是存得越频繁越好。存太频繁IO会成为瓶颈尤其是大模型存太少一旦训练中断损失太大。我的经验是按时间间隔存比如每半小时同时保留最近K个和历史上最好的N个。最好的N个按验证集指标排序这样即使训练后期过拟合了你也能找回中间最好的那个版本。存的时候不要只存模型权重还要存优化器状态、学习率调度器状态、当前的epoch和step。否则恢复训练时优化器的动量信息丢了模型行为会和没中断时不一样。这个细节很多人不注意但在做长周期训练时非常关键。4. 评估体系离线指标好看不等于线上能用4.1 离线评估的常见陷阱离线评估最大的陷阱是“数据泄漏”。比如你用未来数据预测过去或者特征里混入了标签信息。这类问题在Demo里很难发现因为Demo的数据集通常是干净的、经过处理的。但真实项目里数据往往来自多个源时间边界模糊很容易不小心把不该用的信息喂给模型。我的做法是在评估之前先做一次“特征-标签相关性审计”。对每个特征计算它和标签的互信息或者相关性如果某个特征的相关性异常高比如超过0.95就要警惕是不是泄漏了。另外对于时间序列问题一定要用时间切分不能用随机切分。随机切分会让模型“看到未来”离线指标虚高线上直接崩。4.2 构建分层评估集而不是只看总体指标总体准确率或者AUC只能告诉你模型平均表现如何不能告诉你它在哪些子群体上表现差。我习惯把评估集按关键维度分层比如按用户类型、按时间段、按数据来源。然后分别看每个层的指标。经常出现的情况是总体指标很好但某个小群体上指标很差。如果这个群体恰好是业务上重要的群体那这个模型就不能上线。分层评估的另一个好处是能帮你定位问题。如果某个层的指标特别差你可以去看那个层的数据有什么特点是样本太少、特征缺失严重、还是标签噪声大。这些信息对后续改进非常有用。4.3 线上评估A/B测试之外还能做什么A/B测试是线上评估的金标准但它需要时间、需要流量、需要工程支持。在A/B测试之前我通常会先做“影子模式”评估新模型和旧模型同时跑新模型的输出只记录不生效然后对比两者的差异。影子模式不需要切流量风险低能快速发现新模型和旧模型在行为上的系统性差异。影子模式跑一段时间后如果差异在可接受范围内再上小流量A/B测试。A/B测试期间除了看业务指标还要看模型层面的指标比如预测分布、延迟、资源消耗。有时候业务指标没变但模型延迟增加了一倍这种问题也要及时发现。5. 部署与服务化把模型变成别人能用的接口5.1 模型服务化的三种形态与选型逻辑模型部署不是只有一种方式。常见的形态有三种嵌入式模型和业务代码在同一个进程里、独立服务模型作为一个单独的HTTP/gRPC服务、批处理离线跑完结果存起来业务直接查。选哪种取决于你的场景。嵌入式适合模型小、延迟要求极高、业务逻辑和模型逻辑耦合紧密的场景。独立服务适合模型需要独立扩缩容、多业务共用、需要频繁更新的场景。批处理适合对实时性要求不高、但吞吐量大的场景。我见过有人不管什么场景都上独立服务结果一个简单的分类任务加了一次网络调用延迟从5毫秒变成了50毫秒完全没必要。5.2 服务化时必须处理的边界情况模型服务上线后你会遇到各种在训练时想不到的输入。比如空字符串、超长文本、非法字符、数值溢出。这些输入在训练集里可能从来没出现过但线上一定会遇到。我的做法是在服务入口加一层“输入守卫”对每个字段做基本的合法性检查不合法的直接返回默认结果或者错误码不要让它们进入模型。另外模型的输出也要做后处理。比如分类模型输出的概率要检查是否在0到1之间、是否和为1。如果模型输出异常要有兜底逻辑。这些看起来是小事但线上事故往往就是这些小事引起的。5.3 版本管理与灰度发布模型更新不能像普通代码更新那样直接全量替换。你需要版本管理每个模型版本有唯一的标识服务能根据配置加载指定版本。灰度发布时先切一小部分流量到新版本观察一段时间没问题再逐步扩大。灰度发布的关键是“可回滚”。一旦新版本出问题要能在一分钟内切回旧版本。所以旧版本的模型文件不能删服务要支持同时加载多个版本。这些工程细节在Demo阶段完全不会考虑但它们是AI工程和AI实验的分水岭。6. 监控与迭代上线只是开始6.1 模型层面的监控指标服务层面的监控QPS、延迟、错误率是基础但不够。你还需要模型层面的监控预测分布、特征分布、置信度分布。预测分布突然偏移说明输入数据变了或者模型出问题了。特征分布偏移说明上游数据管道可能有问题。置信度分布如果整体下降说明模型遇到了它不熟悉的数据。这些监控不需要很复杂每天算一次和上周同期对比就行。关键是你要有这个意识并且把监控结果可视化出来让团队里所有人都能看到。6.2 数据漂移的检测与应对数据漂移是模型性能下降的主要原因之一。检测漂移的方法有很多简单的是对比训练集和当前线上数据的特征分布用KL散度或者PSI群体稳定性指标来衡量。PSI超过0.2通常认为有显著漂移。发现漂移后不要急着重新训练。先分析是哪个特征漂移了、为什么漂移。有时候是上游数据采集逻辑变了有时候是业务本身变了。如果是前者修数据管道就行如果是后者可能需要重新标注数据、重新训练。盲目重训可能解决不了问题还会浪费资源。6.3 反馈闭环把线上数据变成训练数据模型上线后你会得到大量真实数据。这些数据是宝贵的但不能直接拿来训练。因为线上数据没有标签而且分布和训练集不一样。你需要设计一个反馈闭环收集线上数据、人工标注一部分、用标注数据评估模型、决定是否重训。这个闭环的设计要考虑成本和时效。全量标注不现实通常是采样标注。采样策略也很关键不能随机采样要优先采样模型置信度低的数据、预测错误的数据、以及业务上重要的数据。这样标注的性价比最高。7. 从零搭建时最容易踩的五个坑7.1 坑一在Notebook里写生产代码Notebook适合探索不适合生产。Notebook的执行顺序是乱的变量可以重复定义状态难以复现。我见过有人把Notebook直接导出成Python脚本部署结果因为执行顺序问题线上行为和本地完全不一样。从零搭建时一定要把探索代码和生产代码分开。探索在Notebook里做生产代码写成模块化的Python包有明确的入口和依赖。7.2 坑二忽略依赖版本管理AI项目的依赖特别多而且版本之间经常不兼容。今天跑通的代码明天换个环境就崩了。我的做法是用虚拟环境隔离用requirements.txt或者pyproject.toml锁定版本并且在Docker镜像里固化整个环境。不要相信“在我机器上能跑”要相信“在镜像里能跑”。7.3 坑三没有单元测试AI代码也需要单元测试。数据处理的每个函数、特征工程的每个步骤、模型的输入输出都应该有测试。测试不需要很复杂验证输入输出形状、类型、取值范围就行。这些测试能在你改代码时快速发现回归问题。我试过在一个项目里加了数据处理的单元测试后因为改代码引入的bug减少了七成以上。7.4 坑四把日志当调试工具日志不是用来调试的是用来监控和排查的。调试应该用断点或者交互式环境。日志要结构化包含时间戳、请求ID、关键字段的值。这样出问题时你能快速定位是哪个请求、哪个环节出了问题。我习惯在日志里记录每个请求的输入摘要、模型版本、输出摘要、耗时。这些信息在排查线上问题时非常有用。7.5 坑五低估了数据标注的成本很多人做项目时假设数据是现成的、标注是准确的。但真实情况是标注数据往往很少、很贵、质量参差不齐。从零搭建时一定要把标注成本算进去。如果标注成本太高就要考虑用弱监督、半监督、或者主动学习的方法来减少标注量。这个决策要在项目早期做不要等到模型训不出来才想起来。8. 一套可以照着搭的最小可行工程结构说了这么多最后给一个我实际用过的目录结构适合从零开始一个AI工程项目时参考project/ ├── configs/ # 配置文件 │ ├── data.yaml │ └── model.yaml ├── data/ # 数据目录不纳入版本控制 │ ├── raw/ │ ├── processed/ │ └── snapshots/ ├── src/ │ ├── data/ # 数据管道 │ │ ├── pipeline.py │ │ └── validation.py │ ├── features/ # 特征工程 │ │ └── build.py │ ├── models/ # 模型定义与训练 │ │ ├── train.py │ │ └── evaluate.py │ ├── serving/ # 服务化 │ │ ├── app.py │ │ └── guards.py │ └── monitoring/ # 监控 │ └── drift.py ├── tests/ # 单元测试 ├── experiments/ # 实验记录 ├── Dockerfile ├── requirements.txt └── README.md这个结构不复杂但它把数据、特征、模型、服务、监控分开了每个部分有明确的职责。从零搭建时不要一上来就追求完美先把骨架搭起来然后一个模块一个模块填充。每填一个模块就加对应的测试和日志。这样搭出来的系统虽然一开始功能少但扩展性和可维护性都很好。我在实际项目里最大的体会是AI工程和AI研究的区别不在于谁更聪明而在于谁更注重细节和可重复性。研究可以容忍失败和随机工程不能。每一个环节都要有明确的输入输出、有校验、有监控、有回滚方案。这些东西在Demo阶段看起来是“过度设计”但到了真实场景里它们就是你和事故之间的那道墙。