直接聊点实在的。看到ai-engineering-from-scratch这个标题我第一反应是这哥们在给自己挖坑而且是那种越挖越深、最后能挖出一整套体系的坑。我自己两年前做个人项目时就是从裸环境一路跌跌撞撞搭起来的从 Python 环境、Docker、数据管道、模型训练到上线部署每一步都踩过不止一次。现在回头再看“AI 工程”这四个字重点根本不在“AI”——模型训练谁都能跑通真正难的是“工程”是把这个模型变成一条稳定、可复现、能迭代、能上线的系统流水线。这篇文章就是来拆这件事的如果你也想从零开始搭建一套 AI 工程体系不做依赖别人封装好的全栈方案而是把一个项目从环境、数据、模型到部署全链路吃透应该怎么思考、怎么选型、怎么落笔。内容不涉及某个具体算法调参奇技淫巧更多是我切割这个标题时整理出的工程骨架、决策逻辑以及我踩过的坑。先给个结论from-scratch不代表什么都自己造轮子而是“不盲目用别人封装好的黑盒”每一层都要自己判断、自己组装。这个定位直接决定了整个项目的推进方式。下面按我实操时的环节顺序拆解。1. 从零起步先想清楚AI工程到底“工程”在哪里1.1 这个标题到底在解决什么问题ai-engineering-from-scratch翻译过来就是“从零开始的 AI 工程”。听起来像一门课的大纲但拆开看里面真正隐含的问题是一个只学过模型训练的人和一个能把系统稳定交付的人差距到底在哪里我个人的答案是差距在“管线思维”。训练一个模型你只需要数据、算力和一份 PyTorch 代码但 AI 工程是一条完整的链路从数据收集、清洗、版本管理到特征工程、实验追踪、模型评估、打包部署、线上监控任何一个环节断了项目就卡住。更直白点说论文里的模型是“点”工程里的模型是“流”我们做的是把无数个点连接成一条自动化流动的线。这个标题之所以让我觉得有价值是因为它指向的是“重建轮子的全过程”。很多事情你用现成平台做三天就能跑通但你对整套系统没有掌控权从零搭一遍你会被迫搞清楚每一个模块为什么存在、什么时候会出问题、出了问题怎么定位。这种掌控感才是工程能力和调包侠之间的分水岭。1.2 我为什么选择“从零搭建”而不是直接用封装框架我知道你想问现在大把现成的 AI 平台、AutoML 工具拖拽几下就能出模型为什么还要从零搭我的看法是封装框架解决的是“从0到1的可用性”解决不了“从1到100的工程问题”。平台帮你把模型训练好了但一旦你需要定制数据处理逻辑、切换模型架构、调整服务部署方式、接入内部监控系统等待你的就是各种“平台不支持”“这个功能要企业版”“底层逻辑没法改”。我在实际项目里吃过这个亏刚开始用某平台觉得很爽后来业务方要自定义特征交叉方式平台的字段系统根本表达不了最后被迫重写白白浪费了三周。从零搭建的好处有三个每一层逻辑都在你掌控范围内出了问题知道去哪里排查。训练、部署、迭代之间没有隐藏的黑盒适合深入了解 AI 系统的工作原理。当项目要换底层框架比如从 PyTorch 换到 TensorFlow或从单机训练换到分布式你有能力做迁移而不是被平台绑定。当然这不代表要把所有组件都手写。我的原则是底层依赖成熟库PyTorch、Transformers、FastAPI但“系统的组装逻辑”必须自己掌控。2. 环境搭建与项目骨架地基不牢后面全是坑2.1 依赖管理用可复现环境代替“在我电脑上可以跑”从零搭项目第一个遇到的硬骨头就是环境。我见过太多项目代码写得花团锦簇一看 README 只有一句“pip install -r requirements.txt”结果换台机器根本跑不起来最后排查半天是 Python 版本不对、CUDA 版本和 PyTorch 不匹配、某些包只支持 Linux、某个依赖锁定的版本和另一个冲突。所以我的第一条铁律是环境必须可复现。具体做法上我比较推荐用pyenv管理 Python 版本再用poetry或uv管理依赖。选型时对比过 conda、piprequirements.txt、poetry 和 uv实际的取舍逻辑如下方案优点缺点适合场景conda可以装非 Python 的二进制依赖如 CUDA 库环境解析慢锁文件对 pip 包支持不稳定重度科学计算、需要混装 C/C 库pip requirements.txt简单直接所有人都会用没有依赖树解析版本冲突容易踩雷快速原型、一次性脚本poetry依赖解析严谨有 lock 文件保证可复现与部分深度学习库的安装方式有冲突解析慢中大型 Python 工程推荐uv极快兼容 pip/requirements支持 lock生态相对较新团队不熟时需要学习成本新项目推荐尝试我现在的标准配置是pyenv固定 Python 版本 uv管理依赖和虚拟环境。训练类项目还需要把 CUDA、cuDNN 版本写进一个.env文件或Makefile变量里同时锁死 PyTorch 版本不推荐直接pip install torch装最新版——因为最新版对 CUDA 版本很敏感很容易装完后一跑就报CUDA error: no kernel image is available。提示把以下信息写进项目的README.md否则换个环境你可能会被迫“考古”操作系统版本、Python 版本、CUDA 版本、PyTorch 版本、关键 Python 包版本。2.2 目录结构与代码分层环境只是地基的一部分目录结构是另一部分。很多从零开始的 AI 项目目录长这样project/ ├── train.py ├── data.py ├── model.py ├── utils.py └── requirements.txt所有代码堆在顶层函数之间互相 import训练逻辑和数据处理混在一起改一处数据格式模型代码也要跟着改。这种结构前期跑 demo 没问题到后期要加新模型、跑多组实验、做模型版本对比时会乱到怀疑人生。我推荐从第一天就搭成“src 布局”project/ ├── src/ │ ├── data/ # 数据加载、清洗、增强 │ ├── models/ # 模型定义 │ ├── train/ # 训练逻辑 │ ├── evaluate/ # 评估逻辑 │ └── serve/ # 推理/API服务 ├── configs/ # 实验配置YAML ├── tests/ # 单元测试 ├── scripts/ # 一次性脚本、入口脚本 ├── data/ # 数据存放通常gitignore ├── outputs/ # 模型输出实验产物 ├── pyproject.toml └── Makefile这样分层的核心意图是数据、模型、训练、评估、服务互不污染。每个模块都有清晰的输入输出接口替换数据源时不用动模型代码替换模型架构时不用动训练逻辑上线服务时可以单独拆出 serve 模块。配置管理我建议用 YAML 简单 dataclass或者直接用 Hydra。从零搭的项目不需要一开始就上重型配置框架但至少要养成“参数不进代码”的习惯。把 batch size、learning rate、模型名称、数据路径全部丢进configs/experiment.yaml训练时一行python scripts/train.py --config configs/experiment.yaml就能跑这样后面做实验对比才能批量推进。3. 数据管道工程化要从数据治理开始3.1 数据获取、清洗与标注的坑很多教程默认“数据已经准备好了”但真实项目里 80% 的问题都出在数据链路。从零搭建一个 AI 项目我建议倒排时间数据清洗和治理占 50% 以上建模只占 20%部署和监控占 30%。第一坑是“数据收集看似简单实则格式五花八门”。我接过一个需求要判断用户反馈文本的情感倾向。业务方给的数据是 Excel 表里面有合并单元格、emoji、HTML 标签、大小写混排、中英文混合。直接用原始数据训练模型学到的全是噪声。清洗时至少要做以下步骤统一编码UTF-8和换行符。去除 HTML 标签、不可见字符、重复标点。规范化文本全角转半角统一大小写按业务需要做分词或保留标点。对用户生成内容可以考虑做 PII个人隐私信息脱敏避免模型记忆敏感信息。第二坑是“标注标准不统一”。如果项目需要人工标注或者用已有标注不同人标注同一句话可能给出不同标签。一定要先做标注一致性测试比如让两个人标同一批 100 条数据计算 Cohen’s Kappa 系数低于 0.8 就需要重新对齐标准。否则模型的上限已经被数据质量卡死了调什么都白搭。第三坑是“数据版本管理缺失”。数据文件经常更新但模型训练的成果依赖于某一版数据。我经历过数据文件被同事覆盖更新我拿新数据重新训练效果反而变差排查半天才发现是数据版本变了。解决方案是用 DVCData Version Control或类似工具管理数据集的版本每个版本对应一个 hash训练配置里记录当时使用的数据版本和代码 commit。这样任何实验都可以精确复现。3.2 训练集/验证集/测试集的正确划分划分数据集看着简单其实暗藏不少坑。先说两个最常见的错误随机划分导致数据泄露比如做时间序列预测直接用随机分割会拿未来的数据去预测过去看似效果不错实际上线就崩。同源样本污染同一个用户在短时间内产生多条行为记录简单随机划分后训练集和测试集可能都包含同一用户的不同记录模型相当于已经见过了这个人评估结果虚高。我的实操建议是先根据业务场景决定划分维度按时间划分、按用户划分、按文本主题划分而不是默认train_test_split(random_state42)。数据集划分要在清洗之后、所有预处理之前完成。如果在全局做归一化或向量化再切分会引入信息泄漏因为测试集的信息已经被训练集的统计量“污染”了。再单独留一份“黄金测试集”这份数据从项目一开始就锁死任何人不能动。平时调参用的测试集可以反复用但黄金测试集只在最终评估时跑一次用来反映模型的真实泛化表现。我自己通常把原始数据分成 80/20然后从训练集里再切 10% 作为验证集最终比例大约是训练 72%、验证 8%、测试 20%。验证集用来做早停和超参选择测试集只做最终评估。如果数据量特别大比例可以根据实际情况调整但原则不变。4. 模型开发从基线模型到可迭代的实验流程4.1 不要一上来就上大模型先定基线想象一下这个场景你拿到一个文本分类任务第一反应是上 BERT加载预训练权重跑几个 epoch准确率 91%你觉得不错。但业务方问“这个效果到底好不好”你答不上来因为没有基线对比。基线模型的作用是给所有后续模型提供一个“最低通过线”如果一个复杂模型连简单规则都打不过说明模型设计或数据链路有问题。我一般先做一个最简单的模型比如 TF-IDF 逻辑回归或者随机森林在五分钟内跑完得到一个准确率。如果后续模型表现没有显著超过这个基线说明不是模型复杂度不够而是数据特征没提取好或者数据本身有问题。先跑基线还有一个隐藏好处能快速验证整套训练管道是否通畅。从数据加载、预处理、模型输入输出到评估函数每一步都可能出 bug。用简单模型跑通一遍就相当于给管道做了一个端到端“冒烟测试”管道通了再换复杂模型排查问题范围就小很多。实验追踪也是从零搭建项目必须早早就做的事。我习惯用 MLflow 或 WandB 记录每一次实验的关键数据。记录内容至少包括代码版本git commit hash数据版本DVC hash超参数从配置文件中读取每个 epoch 的训练损失、验证损失、评估指标训练时间和显存峰值没有实验追踪你很快会陷入“我记得之前试过某个学习率效果不错但不知道是什么时候试的、结果存哪里了”的泥潭。4.2 训练脚本与微调时的“细节魔鬼”模型训练看起来就是model.fit(x, y)或几行 PyTorch 循环但真正跑起来细节决定成败。第一个要点固定随机种子并测试可复现性。在训练脚本开头固定random.seed、numpy.random.seed和torch.manual_seed在 GPU 上还需要设置torch.cuda.manual_seed_all并把cudnn.deterministic设为 True。这样做不是为了学术洁癖而是为了排查问题如果每次跑结果都不一样你没法判断效果波动是代码改动导致还是随机性导致。第二个要点学习率和 batch size 是联动关系。新手最容易踩的坑是把别人的 batch size 和 learning rate 直接抄过来用。实际上batch size 翻倍学习率通常也要相应调整比如按线性缩放规则调大。如果显存不够强行用小 batch又不调学习率模型训练过程会震荡损失曲线不稳定。第三个要点loss 的设计要匹配任务目标。文本分类用交叉熵没问题但如果是回归任务、排序任务、多标签任务用错 loss 的情况还挺常见的。比如多标签分类误用 Softmax CrossEntropy模型输出概率总和为 1导致多个标签同时存在时训练效果差。这个点看起来基础但实战中真的会遇到。第四个要点早停条件不要只看验证损失。我的做法是验证损失连续 N 个 epoch 不下降才停N 通常设 5~10但还要同时看其他指标如验证准确率、AUC因为有时候验证损失还在降业务指标已经开始变差也就是过拟合已经开始了。我在实际项目中踩过最大的一个坑是忘记做梯度裁剪训练过程碰到某些离群样本loss 爆炸成 NaN整个模型权重全部被污染只能从头再来。从那以后凡是 RNN、Transformer 类模型我必加clip_grad_norm_而且会把 max norm 设到 1.0 左右这已经成为我的默认模板。5. 评估、部署与监控工程闭环的最后一段5.1 离线评估与线上评估的差异模型训练完在测试集上指标很好看不代表上线后就一定好用。离线评估和线上评估之间存在一个“缺口”这主要是因为离线数据集和线上真实数据分布不同数据漂移。离线评估用的指标不等于业务指标比如离线的 AUC 很高但业务方关心的是“高价值用户的转化率”。推理阶段的性能约束延迟要求和训练阶段不同可能需要做模型压缩或量化压缩后效果会打折。所以我的建议是在线下评估阶段除了常用指标准确率、F1、AUC还要和业务方对齐“业务指标”。比如客户流失预测模型AUC 是技术指标业务方更关心“在召回率 80% 的前提下精准率是多少”。这个指标要从模型预测概率的阈值选择开始而阈值选择是线下就要做的工作不是上线后拍脑袋决定的。另外强烈建议为线上环境准备一份“Golden Set”——一组高置信度、能覆盖典型场景的样本集合。每次更新模型前先在 Golden Set 上跑一遍如果新模型在 Golden Set 上表现下降就要慎重上线哪怕其他指标涨了。这和回归测试是同一个思路给模型迭代上一道保险。5.2 部署方式选择API服务与批处理部署是 AI 工程里离“工程”最近的一环。模型训练完是 .pt / .h5 / .onnx 文件要变成真正可用的服务至少要考虑三种情况离线批处理比如每天凌晨对全量用户打标适合用脚本定时跑直接批量推理不需要实时响应。在线 API比如用户请求进来实时返回预测结果适合用 FastAPI 封装成一个 HTTP 服务。边缘/嵌入式部署如果对延迟和隐私有要求可能要把模型转换成 ONNX 或 TensorRT部署到端侧。我给自己项目的默认选择是 FastAPI Docker。FastAPI 的好处是天然支持异步和 Pydantic 数据校验接口文档自动生成调试也方便。Docker 负责把环境完整打包镜像里固定好 Python、CUDA、依赖库换机器部署直接docker run就行。部署时有个容易忽略的细节模型加载时机。模型文件很大如果在每次请求时才加载第一次请求会慢到怀疑人生。正确做法是在服务启动时就把模型加载进内存推理函数只做前向计算。推理阶段的性能优化我一般按三步走先量化好延迟基线单次请求耗时多少毫秒。如果 CPU 推理太慢迁移到 GPU如果 GPU 显存不够考虑 FP16 半精度推理。如果还需要更快转 ONNX 格式并用 ONNX Runtime 做推理通常能带来 20%~50% 的加速还能减少框架锁定的风险。压测也是必要环节。不要等上线后被用户反馈“接口好慢”自己先拿locust或wrk跑一轮并发测试观察 P99 延迟和吞吐量。我遇到过的情况是单次推理 30ms看起来很快但并发 50 时 GPU 显存直接爆掉。这提醒我部署时的并发能力和显存规划必须在压测阶段就算清楚。5.3 监控数据漂移、模型漂移模型上线不是结束而是工程化运维的开始。很多从零搭建的项目死于“模型上线后没人管”线上数据分布变了模型过期了但没人发现直到业务方反馈“最近预测结果越来越不准”。我的监控方案分三层服务层监控请求延迟、QPS、错误率、GPU 显存使用率。这些用 Prometheus Grafana 就能搭一套基础看板。数据层监控统计线上输入特征分布和训练集分布做对比。如果某个特征在线上分布发生明显偏移比如平均值漂移超过阈值说明数据漂移了需要告警并考虑重新采集训练数据。模型层监控如果模型有真实标签反馈比如用户是否点击、是否流失需要定期计算线上模型的精确率/召回率或者至少绘制预测分数分布图。日常监控可能做不到“真值实时回流”但可以用“预测分数分布是否剧烈变化”作为一个代理信号。这些监控看板都不需要很复杂核心是把关键指标收集起来、可视化、设阈值、告警。从零搭一套半小时到一天能完成但收益极大——至少你不会在产品出问题后还是最后一个知道的人。6. 常见问题与排查技巧实录6.1 环境与依赖问题速查现象排查思路我遇到过的一次教训CUDA error: no kernel image检查 PyTorch 版本与 CUDA 版本是否匹配用了 PyTorch 1.12 搭配 CUDA 11.7但显卡驱动只支持最新 CUDA 12最后重装了匹配组合ModuleNotFoundError但明明装了包检查当前 Python 环境是否用的是项目虚拟环境忘了激活虚拟环境pip 装到了全局环境代码却跑在虚拟环境里训练时 OOM减少 batch size或开启梯度累积也可以尝试混合精度直接调小 batch size 后 loss 曲线异常因为学习率没跟着调6.2 训练阶段常见问题速查现象可能原因解决办法Loss 完全不降学习率太大/太小数据预处理错误模型输出和 label 不匹配先用一个 batch 做“过拟合测试”模型应能学到接近 100% 的准确率否则代码有 bug训练损失降、验证损失升高过拟合早停、加正则化L2/ Dropout、数据增强、降低模型复杂度Loss 变成 NaN学习率过高、梯度爆炸、数据里有 NaN梯度裁剪 检查输入数据是否有 NaN 降低学习率不同次训练结果差异大随机种子没有固定固定随机种子或增加cudnn.deterministicTrue同时接受可能的训练速度损失6.3 部署与迭代阶段避坑指南不要在模型服务里写业务逻辑。模型只管输出预测结果业务规则放到 API 层之前或之后处理否则想换模型时你会连业务代码一起重写。模型版本和配置文件要一起保存。我习惯把 config 里的关键参数直接写进模型文件的命名比如model_bert_lr2e5_bs32.pt省得事后猜“这个模型当时用的什么超参数”。做 A/B 测试时要保证流量切分和模型预测相独立。不要让同一个用户的请求在同一时间落在两个模型版本上否则用户感知会不一致评估结果也会被污染。注意如果你是第一次把模型封装成 API先在本地用requests模拟几轮真实请求而不是只用 FastAPI 自带的 Swagger 文档点一两下。真正的业务请求头、参数格式、异常输入都会带来你在开发时根本预想不到的问题。7. 一点个人收尾的实操体会写了这么多最后再分享一个我觉得最有价值的习惯每次跑实验前先花 10 分钟确认“这次实验要回答什么问题”。如果你能清晰地说出“我要验证当数据量为 X 时模型 A 比模型 B 的 F1 高多少”那这次实验才有意义。不然很容易陷入反复调参但说不清每个参数价值的泥潭。还有一个小技巧是我踩过几次坑之后养成的每次训练完除了保存模型权重一定要保存一份“实验报告”内容包括最终指标、关键超参数、数据版本、代码 commit、跑实验的时间、当时的 GPU 型号。哪怕是随手写的几行 Markdown等你三个月后回头想复现模型时就知道这东西有多值钱。ai-engineering-from-scratch从来不是一门课、一个仓库或者一份教程能概括的。它本质上是一连串“知道自己不知道”的瞬间终于理解了为什么需要数据版本管理、为什么实验要固定随机种子、为什么线上指标会跟离线差那么多。把这些瞬间攒下来你才算真正从零走进 AI 工程这个领域。