很多人一提到 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, transformNone): 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, dtypetorch.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, dim1) 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 size64 或者 128具体根据显存来。Epoch参考模型验证集表现动态决定不设死。数据增强随机裁剪、随机水平翻转、归一化。数据增强这部分我建议用以下代码作为起点train_transforms transforms.Compose([ transforms.RandomResizedCrop(224, scale(0.8, 1.0)), transforms.RandomHorizontalFlip(), transforms.ColorJitter(brightness0.2, contrast0.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), dim1) 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_memoryTrue减少 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把这些过程变成肌肉记忆。希望这篇内容能给你画出一张踏实的地图剩下的路真的得自己走一遍。