1. 这个项目到底在解决什么问题
第一次看到ai-engineering-from-scratch这个标题，我脑子里蹦出来的第一个念头是：终于有人把这件事拎出来单独讲了。过去两年，市面上讲 AI 的内容基本分成两拨——一拨是调 API 的应用层教程，教你用几行 Python 调个模型接口做个聊天机器人；另一拨是论文精读，上来就是注意力机制的矩阵推导。中间那一大块真正决定一个 AI 项目能不能落地的工程能力，反而没人系统讲。
ai-engineering-from-scratch要填的就是这个坑。它不是一个具体的库或者框架，而是一套从零开始构建 AI 工程能力的知识体系与实践路径。核心关键词就三个：从零、工程化、可复现。从零意味着你不只是会调包，而是理解每一层在干什么；工程化意味着你关注的是数据管道、训练稳定性、推理性能、部署成本这些真正烧钱的地方；可复现意味着你搭出来的东西别人能跑起来，明天自己还能跑起来。
这套东西适合谁？我梳理了一下，大概三类人最需要。第一类是有一定编程基础但没做过完整 AI 项目的开发者，比如写了几年后端想转 AI 方向，或者做数据分析想往上游走。第二类是算法工程师但工程能力偏弱的人，模型能训出来，但一到上线就各种问题。第三类是技术负责人，需要判断团队的技术选型和架构是否合理。如果你只是想快速做个 demo 玩玩，这个方向可能有点重；但如果你想真正把 AI 能力变成产品的一部分，那这套从零构建的思路就是绕不开的。
我自己的经历是，早年做推荐系统的时候，模型部分其实只占整个项目工作量的两成不到，剩下八成全是数据清洗、特征管道、线上服务、监控告警这些"脏活"。而恰恰是这些脏活决定了项目成败。ai-engineering-from-scratch的价值就在于，它把这些容易被忽略的环节放到了台面中央。
2. 从零构建 AI 工程能力的整体设计思路
2.1 为什么强调"从零"而不是"从框架开始"
很多人学 AI 的第一反应是找个框架，PyTorch 或者 TensorFlow，然后跟着官方教程跑一遍 MNIST。跑通了觉得自己会了，换个数据集就懵了。问题出在哪？出在跳过了对底层数据流动的理解。
从零构建的思路，我理解是分层的。最底层是数学和数值计算的基础，你得知道张量是什么、梯度怎么传、矩阵乘法在硬件上是怎么被加速的。往上一层是数据工程，怎么把原始数据变成模型能吃的格式，怎么处理缺失值、类别不平衡、时序对齐。再往上是模型训练，损失函数怎么选、学习率怎么调、过拟合怎么判断。最上层才是部署和运维，推理延迟、吞吐量、显存占用、版本管理。
这个分层不是让你每一层都手写一遍，而是让你在每一层都有"如果框架挂了我知道去哪找问题"的能力。我见过太多人，训练 loss 不下降就只会换学习率，其实问题可能出在数据标签错了或者特征归一化没做。从零构建的意义就是让你有排查的底气。
2.2 工程化视角下的核心模块拆解
一个完整的 AI 工程项目，我习惯把它拆成六个模块。数据采集与存储、数据预处理与特征工程、模型训练与调优、模型评估与验证、推理服务与部署、监控与迭代。这六个模块环环相扣，任何一个环节出问题都会传导到最终效果。
ai-engineering-from-scratch的思路是每个模块都先讲清楚"为什么需要它"和"它解决什么问题"，再讲"怎么实现"。比如数据预处理，为什么要做归一化？因为不同特征的量纲差异会让梯度下降走偏，这是数学上的原因；为什么类别特征要做 embedding 而不是 one-hot？因为高维稀疏会让模型参数爆炸，这是工程上的原因。把原因讲透了，你才知道什么时候该用、什么时候不该用。
我特别想强调的一点是，工程化不等于复杂化。有些团队一上来就搞微服务、搞特征平台、搞实时计算，结果数据量根本撑不起来，维护成本反而拖垮了迭代速度。从零构建的另一个含义是，你清楚每个组件的引入成本，能判断什么时候该上、什么时候不该上。
2.3 可复现性为什么是工程能力的试金石
可复现性这个词听起来很学术，但实际工作中它直接关系到你能不能信任自己的实验结果。我踩过最深的坑就是，某次调参把效果提升了两个点，高兴了三天，结果换台机器重跑，效果没了。排查了一周才发现是随机种子没固定，加上数据加载顺序依赖了文件系统的返回顺序。
可复现性涉及的东西比想象中多。随机种子要固定，包括 Python 的、NumPy 的、框架的、甚至 CUDA 的。数据版本要管理，今天用的训练集和明天用的可能不一样。环境依赖要锁定，requirements.txt 里写torch>=1.0和写torch==2.1.0完全是两回事。硬件也要记录，同样的代码在 A100 和 3090 上结果可能不同。
ai-engineering-from-scratch把可复现性作为一条主线贯穿始终，我觉得这是它区别于普通教程的关键。因为只有可复现，你才能做 A/B 对比，才能定位问题，才能让团队协作有意义。
3. 核心细节解析与实操要点
3.1 数据管道的搭建细节
数据管道是 AI 工程的地基，但也是最容易被敷衍的部分。我见过太多项目，数据加载就是写个pd.read_csv，然后train_test_split一拆就开干。小数据集没问题，一旦数据上到 GB 级别，这种写法就是灾难。
搭建数据管道，我建议从三个维度考虑。第一是数据格式。CSV 适合小数据和调试，但读取慢、占内存。Parquet 是列式存储，读取快、压缩率高，适合中等规模。如果数据量再大，就要考虑 TFRecord 或者 WebDataset 这种为流式读取设计的格式。第二是加载方式。PyTorch 的 DataLoader 支持多进程加载，num_workers设多少有讲究。设太小加载跟不上计算，设太大内存爆掉。经验值是 CPU 核数的 70% 左右，但要看具体任务。第三是预处理位置。预处理放在 CPU 还是 GPU，放在加载时还是训练时，直接影响吞吐量。
这里有个实操细节：数据增强如果放在 DataLoader 的__getitem__里，每个 epoch 都会重新做一遍，增加 CPU 负担。如果数据集不大，可以预先增强好存下来；如果数据集大，就得在加载时做，但要控制增强的复杂度。我一般会先用小批量数据测一下加载速度，确保 GPU 利用率能到 80% 以上，否则就是数据管道拖了后腿。
3.2 模型训练中的稳定性控制
训练不稳定是新手最容易崩溃的地方。loss 突然变成 NaN，梯度爆炸，准确率震荡，这些问题背后往往有明确的工程原因。
梯度裁剪是最常用的稳定手段。torch.nn.utils.clip_grad_norm_这个函数，max_norm设多少？一般设 1.0 到 5.0 之间。设太小会限制模型学习能力，设太大等于没裁。我通常先不裁剪跑一遍，观察梯度范数的分布，再决定阈值。学习率预热也很关键，特别是 Transformer 类模型，前几百步用很小的学习率，让模型先适应数据分布，再逐步升到目标值。这个 warmup 步数一般是总步数的 5% 到 10%。
混合精度训练是另一个既提速又省显存的手段。torch.cuda.amp用起来很简单，但要注意 loss scaling。动态 loss scaling 会自动调整，但有时候会不稳定，这时候可以手动设一个固定值。我实测下来，混合精度能省 30% 到 40% 的显存，速度提升 20% 左右，但数值稳定性需要额外关注，特别是涉及 softmax 和 layernorm 的地方。
还有一个容易被忽略的点是数据加载的随机性。如果shuffle=True但随机种子没固定，每次 epoch 的数据顺序都不同，loss 曲线就会抖动。这不是模型的问题，是数据的问题。固定种子后，曲线会平滑很多。
3.3 推理服务的性能优化
模型训出来只是第一步，上线推理才是真正的考验。推理性能和训练性能的关注点完全不同。训练看吞吐量，推理看延迟；训练可以批处理，推理往往要处理单条请求。
批处理是推理优化的第一手段。把多个请求攒成一个 batch 一起送进模型，能大幅提升 GPU 利用率。但攒批会引入延迟，用户等不起。所以要在延迟和吞吐之间找平衡。常见的做法是设一个最大等待时间，比如 10 毫秒，超时或者攒够一定数量就发出去。这个策略叫动态批处理，Triton Inference Server 和 TorchServe 都支持。
模型量化是另一个大杀器。FP32 转 FP16 能省一半显存，速度提升明显，精度损失通常很小。再往下 INT8 量化，省得更多，但需要校准数据集，精度损失要看具体模型。我一般先用 FP16，如果显存还紧张再考虑 INT8。量化不是万能的，有些模型对量化很敏感，特别是小模型和涉及大量小数值运算的模型。
还有模型剪枝和蒸馏，这些属于模型压缩的范畴。剪枝是把不重要的权重去掉，蒸馏是用大模型教小模型。这些手段在资源受限的场景下很有用，但会增加训练复杂度，需要权衡。
3.4 监控与迭代的工程实践
上线不是终点，而是起点。没有监控的 AI 系统就像没有仪表盘的飞机，飞是能飞，但什么时候出事你不知道。
监控要盯几个核心指标。服务层面：QPS、延迟 P99、错误率、GPU 利用率、显存占用。模型层面：输入分布、输出分布、置信度分布。业务层面：点击率、转化率、用户反馈。服务层面的指标用 Prometheus 加 Grafana 就能搞定，模型层面的需要额外埋点。
数据漂移是线上模型效果下降的主要原因。训练时的数据分布和线上推理时的数据分布不一致，模型效果就会打折。检测漂移的方法有 PSI、KL 散度、KS 检验等。我一般会每周跑一次漂移检测，如果 PSI 超过 0.2 就触发告警，考虑重新训练。
模型更新策略也有讲究。全量更新简单但风险大，灰度发布稳妥但流程复杂。我推荐的做法是影子模式，新模型先上线但不接真实流量，只做推理并记录结果，和旧模型对比一段时间，确认没问题再切流量。这样既安全又能拿到真实对比数据。
4. 实操过程与核心环节实现
4.1 环境搭建与依赖管理
环境搭建听起来简单，但它是可复现性的第一道关卡。我强烈建议用容器化方案，Docker 是首选。基础镜像选nvidia/cuda对应的版本，然后装 Python、装框架、装依赖。
依赖管理我踩过的坑最多。pip install直接装，版本冲突是家常便饭。我的做法是分两层：底层是框架和 CUDA 相关的，用 conda 管理，因为 conda 能处理二进制依赖；上层是业务代码的依赖，用 pip 加requirements.txt，并且所有版本号都写死。requirements.txt里不要写torch，要写torch==2.1.0+cu118，把 CUDA 版本也带上。
还有一个细节是 Python 版本。3.8 到 3.11 之间，不同框架的支持程度不同。我一般选 3.10，兼容性最好。如果用到一些新的语法特性，再考虑 3.11。3.12 目前还有些库没跟上，不建议在生产环境用。
环境搭好后，写一个Makefile或者setup.sh，把安装步骤固化下来。新人入职第一天，跑一个脚本就能把环境搭好，这是工程化的基本要求。
4.2 数据准备与特征工程实操
假设我们要做一个文本分类任务，从原始数据到模型输入，中间要经过好几步。我用一个具体例子来说明。
原始数据是 CSV，两列：text和label。第一步是清洗，去掉 HTML 标签、特殊字符、多余空格。这一步用正则表达式就能搞定，但要注意不要过度清洗，比如把表情符号去掉了可能损失情感信息。第二步是分词，中文用 jieba 或者 sentencepiece，英文用 spaCy 或者直接空格切分。分词后要处理停用词，但停用词表不是固定的，要看任务。情感分析里"不"字很重要，不能当停用词去掉。
第三步是构建词表。统计词频，保留频率最高的 N 个词，其余用<UNK>代替。N 设多少？一般 30000 到 50000。太小会导致太多未知词，太大 embedding 矩阵会很大。第四步是序列截断和填充。设一个最大长度max_len，超过的截断，不足的补零。max_len怎么定？统计所有文本长度的分布，取 95 分位数。这样能覆盖大部分样本，又不会让 padding 太多浪费计算。
第五步是划分数据集。训练集、验证集、测试集的比例一般是 8:1:1 或者 7:1.5:1.5。划分时要分层采样，保证每个类别的比例一致。如果数据有时间属性，要按时间划分，不能用随机划分，否则会数据泄露。
这些步骤看起来繁琐，但每一步都有明确的工程目的。跳过任何一步，后面都可能出问题。
4.3 模型训练全流程记录
训练流程我习惯用一个配置文件来管理所有超参数。YAML 或者 JSON 都行，我偏好 YAML，可读性好。配置文件里包括数据路径、模型结构、优化器参数、训练轮数、日志路径、检查点路径。
训练循环的核心逻辑是：取一个 batch，前向传播，算 loss，反向传播，更新参数。但工程实现上有很多细节。比如梯度累积，当显存不够放不下大 batch 时，可以分多次前向反向，累积梯度后再更新，等效于大 batch。accumulation_steps设多少？目标 batch size 除以实际 batch size。
日志记录要详细。每个 step 记录 loss 和学习率，每个 epoch 记录验证集指标。用 TensorBoard 或者 WandB 可视化，能直观看到训练趋势。我一般会同时记录训练 loss 和验证 loss，如果训练 loss 下降但验证 loss 上升，就是过拟合了，该加正则化或者早停。
检查点保存策略也要设计。不是每个 epoch 都存，太占空间。我一般存两个：最好的模型和最后一个模型。最好的模型按验证集指标选，最后一个模型用于恢复训练。如果训练时间很长，中间也存几个，防止意外中断。
4.4 推理服务部署实操
部署推理服务，我推荐 FastAPI 加 Uvicorn 的组合。FastAPI 写接口简洁，Uvicorn 性能不错。模型加载在服务启动时完成，不要每次请求都加载。
接口设计要考虑批处理。定义一个/predict接口，接收一个文本列表，返回预测结果列表。服务内部维护一个队列，请求来了先入队，后台线程定期从队列取数据攒批，送进模型推理，再把结果分发回去。这个模式叫异步批处理，能显著提升吞吐量。
模型版本管理用 MLflow 或者简单的文件目录都行。关键是每个版本要有唯一标识，能追溯。推理时记录用了哪个版本，方便排查问题。
性能测试用 Locust 或者 wrk。测的时候要模拟真实流量分布，不能只测单一请求。关注 P50、P95、P99 延迟，以及最大 QPS。如果 P99 延迟太高，说明有长尾请求，要排查是数据问题还是模型问题。
5. 常见问题与排查技巧实录
5.1 训练不收敛的排查思路
训练不收敛是最常见的问题，原因可能有很多。我一般按这个顺序排查。
先看数据。把 batch 里的数据打印出来，看看输入和标签对不对。我遇到过标签整体偏移一位的情况，模型怎么学都学不会。再看 loss 函数。分类任务用交叉熵，回归任务用 MSE，用错了 loss 不下降很正常。然后看学习率。太大导致震荡，太小导致下降慢。可以画学习率和 loss 的关系图，找一个合适的值。
如果这些都没问题，看模型结构。层数太深可能有梯度消失，加残差连接。激活函数选错也可能有问题，ReLU 在负半轴梯度为零，用 LeakyReLU 或者 GELU 试试。初始化也很关键，全零初始化会让所有神经元学一样的东西，要用 Xavier 或者 Kaiming 初始化。
最后看数值稳定性。如果 loss 是 NaN，检查有没有除零、log 零、exp 溢出。加一个很小的 epsilon 通常能解决。
5.2 显存不足的优化手段
显存不足是另一个高频问题。优化手段按性价比排序。
第一是减小 batch size，最直接但可能影响效果。第二是梯度累积，等效大 batch 但不占额外显存。第三是混合精度，省显存又提速。第四是梯度检查点，用计算换显存，适合超深模型。第五是模型并行，把模型拆到多张卡上，实现复杂但能训超大模型。
还有一个容易被忽略的点是显存碎片。PyTorch 的缓存分配器有时候会留下碎片，导致明明有空间却分配不了。设PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True能缓解这个问题。
排查显存泄漏，用torch.cuda.memory_summary()看显存分布。如果每次迭代显存都在涨，说明有张量没释放。常见原因是把张量存到了列表里，或者计算图没断开。用torch.no_grad()包住推理代码，用detach()断开不需要梯度的张量。
5.3 线上效果下降的定位方法
线上效果下降，先别急着重新训练。按这个流程排查。
第一步，确认是不是数据问题。对比线上输入和训练数据的分布，看有没有明显偏移。第二步，确认是不是服务问题。检查推理代码和训练代码的预处理是否一致，我见过训练时归一化了但推理时忘了的情况。第三步，确认是不是模型问题。把线上的输入存下来，离线跑一遍，看结果和线上是否一致。如果不一致，就是服务的问题；如果一致但效果差，就是模型的问题。
如果确认是数据漂移，考虑重新训练。但重新训练之前，先分析漂移的原因。是用户行为变了，还是数据采集出了问题？如果是采集问题，重新训练也没用，得先修数据管道。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| loss 为 NaN | 学习率过大、除零、log 零 | 检查 loss 计算、打印中间值 | 降低学习率、加 epsilon |
| 训练 loss 降验证 loss 升 | 过拟合 | 对比训练和验证曲线 | 加正则化、早停、增数据 |
| 显存不足 | batch 太大、模型太大 | memory_summary 查看 | 减 batch、混合精度、检查点 |
| 推理延迟高 | 批处理不当、模型太大 | 性能测试、profiling | 动态批处理、量化、剪枝 |
| 线上效果差 | 数据漂移、预处理不一致 | 对比线上线下输入输出 | 修管道、重新训练 |
| 梯度爆炸 | 学习率大、网络深 | 打印梯度范数 | 梯度裁剪、降学习率 |
| 训练速度慢 | 数据加载瓶颈、GPU 利用率低 | nvidia-smi 看利用率 | 增 workers、优化数据管道 |
这张表是我这些年踩坑总结出来的，基本覆盖了八成以上的常见问题。遇到问题先查表，能省不少时间。
6. 我在这条路上踩过的坑和体会
做 AI 工程这些年，最大的体会是：模型只是冰山一角，水面下的工程能力才是决定性的。我见过太多团队，算法很强，论文复现得飞快，但产品就是做不出来。问题往往出在数据管道不稳定、训练不可复现、推理性能不达标这些工程细节上。
ai-engineering-from-scratch这个方向的价值，就在于它把这些水面下的东西系统化了。从零构建不是让你重复造轮子，而是让你理解轮子怎么转，这样轮子坏了你才知道怎么修。
如果让我给刚入行的人一个建议，我会说：先把一个完整的项目跑通，从数据到部署，哪怕模型很简单。跑通一遍，你对整个流程的理解会比看十篇论文都深。然后再回头补数学和理论，这时候你才知道那些公式在实际中对应的是什么。
还有一个心得是，工具在精不在多。PyTorch 生态足够覆盖大部分场景，没必要今天学 TensorFlow 明天学 JAX。把一个框架用透，比每个都懂一点强得多。数据版本管理用 DVC，实验跟踪用 MLflow 或者 WandB，服务部署用 FastAPI 加 Docker，这套组合能解决九成问题。
最后分享一个我常用的技巧：每次实验都写一个README，记录这次改了什么、为什么改、结果如何。三个月后回头看，你会感谢当时的自己。因为人的记忆不可靠，但记录可靠。这也是可复现性的一部分，而且是成本最低的那部分。
