很多人一提到 AI 工程，第一反应都是“我要不要先去读个硕士”“是不是得把 Transformer 论文从头推一遍”。我做了几年 AI 落地相关的工作，带过项目也面试过不少人，最大的感受是：真正缺的往往不是理论深度，而是那种能把模型从论文里搬到生产环境里、让它稳定跑起来的“工程手感”。ai-engineering-from-scratch这个题目，想说的就是这么一件事——不依赖现成的平台、不靠复制别人的代码，而是从环境搭建、数据处理、模型训练到服务部署，完整地把一套 AI 工程体系亲手建起来。这篇文章适合那些想系统入门 AI 工程、或者已经会用框架但总觉得“差点意思”的同学。我会结合自己做过的项目，把从零搭一套 AI 工程体系的关键路径、工具选型、实操踩坑都拆开讲清楚。
1. 内容整体设计与思路拆解
1.1 先搞清楚：AI 工程不是“调包”
我记得几年前有个同事，用pytorch跑通了几个开箱即用的模型，觉得自己已经“会 AI”了。直到有一天需要把模型接到公司的业务系统里，他才发现连一个transformers的 pipeline 都懒得去查，更别说GPU利用率、请求延迟、模型版本管理这些事儿了。
AI 工程全称为AI Engineering，指的是从数据处理、模型开发、训练调优，到部署上线、监控运维的一整套工程化流程。它和纯算法研究有本质区别。算法研究关注“准确率还能不能涨”，AI 工程关注“这个模型在真实业务里能不能稳定跑起来、出了问题能不能快速定位”。我面试的时候经常问一个题：如果你的模型上线后延时飙升，你会从哪些维度排查？能答出“看GPU显存、看数据加载瓶颈、看推理框架配置、看业务峰值流量”的人，才是真正在做 AI 工程的人。
所以在这个项目里，我一直把内容设计的核心放在“为什么”而不是“怎么做”。比如为什么要用 Docker 来固化环境？为什么要做数据版本管理？为什么训练时要设固定随机种子？这些“为什么”才是工程思维的内核。没有这批思维，你学再多工具也是个 API 调用员。
1.2 为什么“从零”这条路对新手最友好
很多人入门 AI 时喜欢看别人的完整项目，比如“某某分类项目源码”“某某推荐系统源码”。我不建议这么做，因为这种方式有一个致命的坑：别人的项目里已经完成了大部分脏活累活，你拿过来往往改不动、调不了，出了报错也不知道根源在哪。
ai-engineering-from-scratch的核心设计思路，就是刻意“不用现成的全量代码”，从一条尽可能小的端到端链路开始。比如先不管复杂模型，先用线性回归或小型神经网络走通“数据 -> 模型 -> 预测结果 -> API 服务”的闭环。这个过程看似简单，但它逼着你自己解决环境配置、数据格式、模型序列化、接口定义这些问题。这些问题如果在前期不解决，后面只会越积越多。
我自己带人时的经验是：一个能把 MNIST 从原始数据处理到最终 HTTP 接口全链路跑通的人，比一个会读 ResNet 论文但只会在 Jupyter 里跑 demo 的人可靠得多。因为前者已经具备了“工程闭环”的思维，这在真实的工作环境中是压倒性的优势。
1.3 整体路径：四层递进式架构
我设计的从零到一路径，大致上分成四层：
- 第一层：基础能力层。线性代数、Python 工程语法、数据处理库。这一层是地基，但不需要学太深，够用就行。
- 第二层：核心训练层。理解数据管线、模型结构、损失函数、训练循环、评估指标。要求是能独立训练一个模型，并且能分析和改进效果。
- 第三层：工程封装层。把模型封装成 API、用容器打包依赖、设计统一的输入输出协议。这一层是 AI 工程师和算法工程师的真正分水岭。
- 第四层：稳定运营层。做模型版本管理、性能监控、数据漂移检测、故障恢复。其实这层是生产环境的隐形要求，也是“工程”二字最扎实的体现。
建议不要跳层。我曾经见过有人跳过第二层直接学部署，做出来的 API 接口连个批量请求都处理不好，因为他对模型推理的 batch 机制完全没有概念。基础层虽然枯燥，但决定了上层的上限。
2. 核心细节解析与实操要点
2.1 环境管理：从“我的机器能跑”到“任何机器都能跑”
这一步我踩过最多的坑。早期我训练模型喜欢直接在全局环境里pip install所有依赖，结果某次升级了 NumPy，老模型无法运行，只能靠回忆重装版本，损失了整整两天。
后来我在这个项目里实践出来的标准做法是：
- 用Python 虚拟环境做隔离，而不是直接在系统解释器里装包。
- 为每个项目准备一个
requirements.txt。如果涉及深度学习的底层依赖（CUDA、cuDNN），一定要写明版本范围。 - 统一用Docker固化运行时环境，Dockerfile 里明确安装顺序和版本。这样无论训练还是推理，在不同机器上结果都是一致的。
以下是这个项目里常用的基础环境配置参考：
FROM python:3.10-slim RUN apt-get update && apt-get install -y --no-install-recommends \ build-essential \ libgl1-mesa-glx \ libglib2.0-0 \ && rm -rf /var/lib/apt/lists/* WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . /app CMD ["uvicorn", "api:app", "--host", "0.0.0.0", "--port", "8000"]这个 Dockerfile 是我在项目里实际用过的版本，它解决了两个问题：第一，基础镜像固定为python:3.10-slim，依赖不会漂移；第二，先复制requirements.txt再装依赖，之后改代码重新构建镜像时能充分利用 Docker 的层缓存，不会每次都重装依赖。别小看这种细节，在频繁迭代的时候效率差距很明显。
2.2 数据管线的正确打开方式
数据是 AI 工程里最容易被低估的一环。很多新手训练模型时直接把图片读进内存，或者把 CSV 全量加载，等到数据集一大就发现内存爆了。这个项目里我用的数据管线是这样组织的：
- 原始数据层：存储原始文件（图片/文本/日志），只读不修改，并且做快照备份。
- 预处理层：实现清洗、格式转换、特征提取，把原始数据转为训练格式。
- 数据集层：在代码中通过
Dataset类读取数据，仅在实际使用时加载到内存，配合多进程加载减少 I/O 瓶颈。
以 PyTorch 为例，一个合格的Dataset不仅要实现__len__和__getitem__，还应该在__getitem__里完成归一化、增强、转张量等操作。这样数据预处理的逻辑内聚，后续做分布式训练或跨设备复现也容易。
以下是我在这个项目中用过一个简洁的图片分类Dataset片段：
import torch from torch.utils.data import Dataset from PIL import Image import torchvision.transforms as transforms class ImageFolderDataset(Dataset): def __init__(self, file_list, labels, transform=None): self.file_list = file_list self.labels = labels self.transform = transform or transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]) ]) def __len__(self): return len(self.file_list) def __getitem__(self, idx): image = Image.open(self.file_list[idx]).convert("RGB") label = self.labels[idx] if self.transform: image = self.transform(image) return image, torch.tensor(label, dtype=torch.long)注意这里的Normalize参数，使用的是 ImageNet 的均值和标准差。如果你用的预训练模型是在 ImageNet 上训练的，那就不能乱改，否则模型效果会大打折扣。这种“看起来无关紧要但实际影响巨大”的细节，就是工程经验的体现。
2.3 训练循环：不只是loss.backward()
训练代码是这个项目的核心环节之一，但很多人写训练循环时过于简陋，缺少监控和容错机制。我在这个项目里的训练循环会包含以下必备元素：
- 固定随机种子。模型要可复现，必须先固定 PyTorch、NumPy 和 Python 的随机种子。
- checkpoint 定期保存。保存模型权重、优化器状态、当前 epoch，方便中断后恢复。
- 早停机制。监控验证集指标，连续 N 轮不提升就停止，防止过拟合和浪费时间。
- 日志记录。每一轮记录 loss、准确率、学习率等，而且最好用结构化的方式存成 JSONLines，方便后续分析。
这段是训练主体部分的示意，属于这个项目里每一轮迭代都会重复使用的“模板”：
def train_one_epoch(model, loader, optimizer, criterion, device): model.train() total_loss, correct, total = 0.0, 0, 0 for images, labels in loader: images, labels = images.to(device), labels.to(device) optimizer.zero_grad() outputs = model(images) loss = criterion(outputs, labels) loss.backward() optimizer.step() total_loss += loss.item() * images.size(0) _, preds = torch.max(outputs, 1) correct += (preds == labels).sum().item() total += labels.size(0) return total_loss / total, correct / total我特别想说一下optimizer.zero_grad()。很多初学者会忘记，或者不理解为什么每轮要清零梯度。其实 PyTorch 的梯度默认是累积的，如果不调用zero_grad()，梯度会不断叠加到旧值上，导致参数更新一步比一步乱。这种坑非常隐蔽，报错不会爆，但模型怎么训练都不会收敛。只有亲手从头写过训练循环的人，才可能对这种细节产生警觉。
2.4 模型封装与 API 设计：让模型变成可调用的服务
训练完模型，AI 工程的“后半场”才刚开始。模型要对外提供服务，必须考虑接口协议、性能、容错。我最常用的方案是FastAPI，因为它原生支持异步处理，而且能方便地生成 Swagger 文档，对接前端和测试工具都很方便。
一个合格的模型推理 API 至少要做三件事：接收原始输入、对输入做预处理、调用模型推理并返回结构化结果。不能直接把模型的前处理逻辑藏在模型代码里，因为请求的输入（比如一张网络图片）和模型训练时的输入（归一化后的张量）之间差了十万八千里。
在这个项目里，我实现过这样一个推理接口：
import torch from fastapi import FastAPI, UploadFile, File from torchvision import transforms from PIL import Image import io app = FastAPI() model = load_model_from_checkpoint("./models/best_model.pt") model.eval() preprocess = transforms.Compose([ transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]) ]) class_mapping = ["cat", "dog", "bird"] @app.post("/predict") async def predict(file: UploadFile = File(...)): image_bytes = await file.read() image = Image.open(io.BytesIO(image_bytes)).convert("RGB") tensor = preprocess(image).unsqueeze(0) with torch.no_grad(): logits = model(tensor) probs = torch.softmax(logits, dim=1) top_prob, top_idx = torch.topk(probs, 1) return { "prediction": class_mapping[top_idx.item()], "confidence": round(top_prob.item(), 4) }这里有一个很重要的细节：推理阶段要加torch.no_grad()。否则模型前向传播时会默认构建计算图，占用显存，甚至可能撑爆显存。另一个要点是模型必须设置成eval()模式，因为像 Dropout 和 BatchNorm 这类层，训练和推理时的行为是不同的，不切换会导致每一次推理结果都不一样。
3. 实操过程与核心环节实现
3.1 里程碑一：从零手写一个微型神经网络
千万不要一上来就抱大模型，那样你根本体会不到每一层张量的形状变化。这个项目里第一个里程碑，是用纯 NumPy 写一个两层全连接网络去识别手写数字的简化版。虽然性能不怎么样，但能把“前向传播、反向传播、梯度下降”这三个核心在脑子里面彻底打通。
用 NumPy 定义全连接层其实非常简单，但亲手写一遍的意义在于：你会发现W1和W2的维度必须写对，dW1的计算必须用到前一层缓存的输入，relu的反向传播必须把小于零的梯度清零。这些如果只是在 PyTorch 里调用nn.Linear，是永远不会有体感的。
我强烈建议读者在这里停留至少两到三天，把每个矩阵变换的 shape 都写在纸上。很多后续调参的技巧，比如“学习率太大导致梯度爆炸”“隐藏层太深导致梯度消失”，从手写网络里都能直观感受到。有了这一层的感知，后面用深度学习框架时才不会变成盲人骑瞎马。
3.2 里程碑二：用 PyTorch 走通完整的分类任务
第二个里程碑是使用 PyTorch 训练一个真实的图像分类模型。数据集我推荐先从小型公开数据集入手，CIFAR-10 或者你的自定义小规模数据集都可以。目标不是刷 SOTA，而是把主流程走通，包括数据划分、数据增强、模型定义、训练循环、验证评估、保存加载。
在 Pytorch 里，我常用这样的训练配置：
- 优化器：Adam，初始学习率
1e-3，配合余弦退火调度。 - Batch size：64 或者 128，具体根据显存来。
- Epoch：参考模型验证集表现动态决定，不设死。
- 数据增强：随机裁剪、随机水平翻转、归一化。
数据增强这部分，我建议用以下代码作为起点：
train_transforms = transforms.Compose([ transforms.RandomResizedCrop(224, scale=(0.8, 1.0)), transforms.RandomHorizontalFlip(), transforms.ColorJitter(brightness=0.2, contrast=0.2), transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]) ])RandomResizedCrop能模拟目标大小变化，ColorJitter能轻微扰动颜色，增强后的模型对光照和角度变化更鲁棒。但增强不是越多越好，比如有些任务中左右翻转会破坏语义（如车牌识别、文字方向识别），这时候就绝对不能加。做 AI 工程首先要理解数据本身的语义。
3.3 里程碑三：搭建端到端的模型服务
第三个里程碑，是把训练好的模型封装成完整的服务。我用到的技术栈是FastAPI + Uvicorn + Docker，在 API 层再做一层输入校验和错误处理。这一步搞完，项目就真正“活”了，可以给前端同事对接，也可以给测试团队压测。
以下是这个项目里 API 代码的一个关键片段，它既能处理单张图片，也能处理批量图片：
@app.post("/batch_predict") async def batch_predict(files: list[UploadFile] = File(...)): tensors = [] for file in files: image = Image.open(io.BytesIO(await file.read())).convert("RGB") tensors.append(preprocess(image)) batch = torch.stack(tensors) with torch.no_grad(): probs = torch.softmax(model(batch), dim=1) probs_list = probs.tolist() return {"results": [{"prediction": class_mapping[p.index(max(p))], "confidence": max(p)} for p in probs_list]}批量推理时有个容易被忽略的问题：预处理阶段每张图片Resize之后可能尺寸不一致，但torch.stack要求所有张量形状相同。所以我在预处理阶段已经固定了Resize((224, 224))，这样才能安全堆叠。如果你处理的是文本数据或者目标检测数据，shape 统一的问题会更复杂，所以最好提前在接口层把输入标准化。
此外，服务上线时必须配置 CORS、超时时间和并发参数，这些看似和模型无关，但直接决定了业务方调用时的体验。我在项目里固定了一组参数：--workers 4 --timeout-keep-alive 30，有效避免了长连接占用过多 worker 的问题。
3.4 追踪实验与保存产物
前面不断提到训练模型，但如果没有科学的实验管理，模型训练完可能连自己当时用的什么参数都不知道。我做这个项目时养成了一个习惯：每次实验都用MLflow或者简单的 JSON/CSV 记录参数、指标和生成时间。
一个更轻量的做法是在项目目录下维护一个experiments/文件夹，每次跑训练就生成一个带时间戳的子文件夹，里面存放：
config.yaml：模型、优化器、数据划分参数。metrics.json：每一轮验证集指标。model.pt：当前最佳权重。predict_logits.npy：最后在测试集上的预测概率，方便复盘。
在实际项目中我遇到过这样的情况：同一份代码，昨天训练出来的模型准确率 90%，今天变成了 88%，排查半天发现是某个数据增强的概率设置不小心改掉了。有没有实验记录的差别就在这个时候体现出来：没有记录的人是“凭运气跑模型”，有记录的人半小时内就能定位原因。
4. 常见问题与排查技巧实录
4.1 Loss 始终不下降，甚至变 NaN
这个问题我在这个项目的早期迭代中遇到过非常多次。排查思路我总结成了一个固定套路：
- 检查数据：标签是否从 0 开始连续编号？有没有脏标签？label 出现 -1 或超大值，模型根本学不了。
- 检查学习率：学习率太大，loss 会在几个 step 内冲到 NaN。出现这种情况时先调低
1e-4或1e-5跑几轮试试。 - 检查归一化：输入数据不归一化，features 范围差距悬殊会让梯度方向混乱。
- 检查损失函数：比如用
CrossEntropyLoss配了未经softmax的裸 logits 是正确的，如果多套一层softmax反而会破坏数值稳定性。
排除到这一步，绝大多数 loss 异常都能被解决。剩下的一小部分概率是底层 CUDA 或者 GPU 驱动问题，那通常换个环境就能定位了。
4.2 GPU 利用率上不去，训练太慢
第一次用 GPU 训练时，我特别兴奋地打开nvidia-smi看显存占用，结果利用率只有 20%，训练速度跟 CPU 差不多。排查后发现，最大的瓶颈不是模型，而是数据加载和预处理。
在这个项目里，我用以下手段把 GPU 利用率从 20% 提到了 80% 以上：
- 打开
DataLoader的num_workers，让多个子进程并行加载数据。 - 打开
prefetch_factor，让数据在模型计算时提前准备下一批。 - 打开
pin_memory=True，减少 CPU 到 GPU 的拷贝时间。 - 把不需要的变量在循环里及时释放，避免显存中堆积历史计算图。
还要注意：DataLoader的num_workers不是越大越好。在 Docker 容器里或者 Windows 环境上开多了反而会报错或者导致内存爆炸。我个人的经验是从2开始往上调，观察训练速度和内存占用之间的关系。
4.3 模型离线指标好，线上却崩了
训练集准确率 98%，上线之后业务方说“预测结果差得很”。这个问题在上线第一个版本模型时让我非常窘迫。后来复盘发现几个原因：
- 线上和离线预处理不一致。模拟线上拿到的是压缩后的图片，训练时用的是高分辨率原图，两者经过相同的
Resize后细节差异明显。 - 训练数据跟真实业务分布不匹配。比如训练集大多是室内光线，线上全是室外强光。
- 后处理规则缺失。离线评测只看 top-1 准确率，但业务方需要的是“低置信度时拒绝预测”，而我的 API 没有做置信度阈值过滤。
针对第 3 点，我在 API 里增加了置信度判断逻辑：当最大概率低于0.6时返回"prediction": "unknown"。这个简单的兜底策略让线上反馈一下子好了不少。做 AI 工程，永远先思考“模型在业务里怎么用”，而不是“模型离线分多高”。
4.4 环境依赖地狱与可复现性问题
日常做 AI 项目时最怕听到的话是“我这边能跑啊”。因为这个现象说明环境依赖已经处于不可复现状态。为了根治，这个项目从第一天起就要求：
- 所有依赖必须放进
requirements.txt，使用pip freeze锁定精确版本。 - 关键系统依赖要写进 Dockerfile。
- 模型推理和训练代码入口统一通过
argparse或config.yaml读取参数，不允许在代码里硬编码路径和超参数。
一旦做到这三件事，“环境不一致导致结果复现不了”的问题基本上被消灭了。就算换了电脑、换了队友的机器，一条docker build就能还原出完全一致的环境。这也是“从零搭建 AI 工程”给人带来的最大安心感之一。
5. 经验沉淀与后续迭代建议
做到这里，这套从零搭建的 AI 工程体系已经涵盖了环境、数据、训练、部署、监控五块骨架。我个人的体会是：真正让一个人成长为 AI 工程师的，不是你用了多少 transformer，而是你能不能在模型 crash 的时候快速缩小排查范围，能不能把一个实验从开始到上线做得有条理、可复现。
最后分享一个我一直在用的工作习惯：每次完成一个 AI 项目，我会花 30 分钟写一份简短的复盘，内容包括“当时设计的关键决策是什么”“哪些选择后来被证明是错的”“如果再让我做一次，哪里会不同”。这个习惯看着费时间，但能帮你把经验真正沉淀下来。ai-engineering-from-scratch这条路没有想象中那么难，但也没有捷径。它要求你亲手踩一遍坑、亲手解一遍 bug，把这些过程变成肌肉记忆。希望这篇内容能给你画出一张踏实的地图，剩下的路，真的得自己走一遍。
