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 里写torch1.0和写torch2.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 的地方。还有一个容易被忽略的点是数据加载的随机性。如果shuffleTrue但随机种子没固定每次 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要写torch2.1.0cu118把 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_CONFexpandable_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记录这次改了什么、为什么改、结果如何。三个月后回头看你会感谢当时的自己。因为人的记忆不可靠但记录可靠。这也是可复现性的一部分而且是成本最低的那部分。