1. 先弄清楚AI 工程到底是一门什么样的“工程”如果你最近逛技术社区会发现“AI 工程”这个词出现的频率越来越高。但说实话它跟传统的软件工程不太一样也跟你理解的那种“搞算法研究”不是一回事。我见过不少朋友一开始以为 AI 工程就是写 Python 调库、把别人的模型拿过来跑一跑结果真正上手才发现这条路绕不过去的是数据、训练、部署、评估、迭代这一整条链路。这也正是“ai-engineering-from-scratch”这个主题最核心的地方——它不是让你从零开始重新发明机器学习算法而是让你从零开始具备把 AI 模型落地成产品的完整工程能力。换句话说你要会的不是“怎么推导 Transformer 的数学公式”而是“当我手里有一个真实业务场景时如何从数据准备开始训练出一个可靠的模型并把它稳定地放到线上还要持续维护它”。这两者的差距就是工程师和理论研究者最大的分水岭。从零开始意味着你得自己踩一遍那些文档里永远不会写的坑。比如同样是装一个 PyTorch装 CPU 版和 CUDA 版的命令不一样混装之后会出现各种莫名其妙的报错比如训练集里混进去几条脏数据模型效果就是上不去可你以为是自己参数调得不对再比如模型在本地跑得好好的一到线上推理就变慢原来你忘了做 batch padding 和模型量化。这些经验只有在真正动手的过程中才会长在身上。这篇文章适合谁两类人。一类是转行做 AI 的软件工程师你已经懂编程但不知道 AI 项目的完整链路长什么样另一类是有一定算法基础、想从 Kaggle 比赛走向真实业务场景的同学。我会把整条路的关键节点都梳理出来包括路线规划、环境准备、第一个实战项目、工程化落地的具体方法以及我踩过的坑和排查心得。这一篇看下来你对“AI 工程从零开始”该怎么学、怎么干心里应该就有底了。2. 从零到一先搭出一套能跑通的 AI 工程环境2.1 硬件和算力先别急着买显卡很多新手一上来就问我要 4090 还是 A100其实完全不用那么着急。AI 工程的第一阶段大概率跑的是中小规模模型的训练和推理一张中端消费级显卡甚至云上租用的实例完全够用。我自己就是从一块 GTX 1060 起步的整个入门阶段最重的活就是训练一个文本分类模型显存占用 4GB 多点照样跑得舒服。如果预算有限我建议按这个顺序考虑先看手头有没有支持 CUDA 的 NVIDIA 显卡显存不低于 6GB 基本就能跑大多数入门项目没有的话直接用 Google Colab 的免费 GPU 额度或者云服务商的按量付费 GPU 实例按分钟计费那种前期学习成本几乎为零。千万别一上来就上多卡多机分布式训练的知识等你真遇到大规模任务再补也不迟。内存方面32GB 是个人开发比较舒服的配置。为什么强调内存因为加载数据集、预处理、特征工程这一步非常吃内存。我试过用 16GB 内存机器处理一份几 GB 的原始文本数据光是做分词就撑不住了后来换了机器才算顺利。硬盘的话SSD 是刚需尤其是训练集是图片或大文本时IO 瓶颈会直接影响你的迭代速度。提醒一句有条件别省内存和 SSD 的钱。算力不够可以靠时间和云资源弥补内存不够连数据都读不进去那才是真的干着急。2.2 环境管理Python 版本、包管理器、框架选择的讲究环境问题是我见过劝退新手最多的地方。Python 版本不兼容、CUDA 版本不匹配、包依赖冲突每一个都能让人耗上大半天。我自己现在的标准配置是这样的Python 3.10搭配 venv 或 conda 做环境隔离深度学习框架优先选择 PyTorch。为什么推荐 PyTorch 而不是 TensorFlow说实话现在学术界的模型权重发布、预训练模型库、Fine-tuning 案例几乎都以 PyTorch 为主。你用 PyTorch遇到问题随便一搜就能找到大量中文资料和社区讨论用 TensorFlow 则经常是文档看着明白、一跑就报错。当然TensorFlow 在部分生产部署场景里依然有优势但新手从 PyTorch 起步是阻力最小的路径。CUDA 问题必须单独拎出来说。安装 PyTorch 之前先用nvidia-smi看一下本机显卡驱动支持的 CUDA 版本然后去 PyTorch 官网选对应的安装命令。最稳妥的做法是直接用pip install torch --index-url https://download.pytorch.org/whl/cu121这种方式安装让 pip 帮你把配套的 CUDA runtime 一起装好避免手动配 CUDA 环境变量的坑。这里有个关键认知你本机不需要装完整的 CUDA ToolkitPyTorch 自带的 CUDA runtime 就够用了。依赖管理的技巧也值得说一下。项目一到中后期requirements.txt 就有点不够用了我习惯用uv或 conda-lock 把依赖锁定到具体版本保证换机器之后还能复现。强依赖的包比如 numpy、pandas、torch不要随便升级大版本版本一换很可能引发连锁问题。2.3 五分钟冒烟测试验证你的环境真的没问题环境装完不测试等于白装。我第一次搭环境时就是跳过了这步结果第二天训练时才报 CUDA 不可用排查了半天。现在我的习惯是环境装完先跑一段冒烟测试占用五分钟能把大部分隐藏问题暴露出来。import torch import numpy as np print(PyTorch 版本:, torch.__version__) # 验证 CUDA 是否可用 print(CUDA 是否可用:, torch.cuda.is_available()) if torch.cuda.is_available(): print(GPU 型号:, torch.cuda.get_device_name(0)) # 验证基本张量计算 x torch.randn(3, 3) y torch.matmul(x, x) print(张量计算正常结果形状:, y.shape) # 验证与 NumPy 的互操作 z x.numpy() print(NumPy 互操作正常类型:, type(z))这段代码如果顺利通过说明 CPU、GPU、CUDA 这一层没问题。接下来我会再跑一个小到不能再小的网络训练两步确保反向传播和参数更新链路是通的。import torch.nn as nn import torch.optim as optim model nn.Linear(10, 1) loss_fn nn.MSELoss() optimizer optim.SGD(model.parameters(), lr0.01) x torch.randn(4, 10) target torch.randn(4, 1) for _ in range(3): pred model(x) loss loss_fn(pred, target) optimizer.zero_grad() loss.backward() optimizer.step() print(训练链路正常loss 输出:, loss.item())到这里环境才是真的就绪了。记住这个经验任何新环境、新设备先用最小化脚本验证链路再往上叠加复杂度。我自己后来换新电脑、配服务器都是这个流程省下了大量排查时间。3. 第一个真正的工程项目从零做一个文本分类服务3.1 怎么选项目别一上来就挑战大语言模型新手最容易犯的错误就是感觉“既然现在大模型这么火我是不是直接学微调大模型”。说实话上来就折腾大模型你会被显存占用、分布式策略、长文本处理、评估指标这些事情打得没脾气。我带的几个初级工程师最快建立起工程自信的项目反而都是那些“看起来不起眼”的分类或回归任务。我建议你做的第一个完整项目是情感二分类给一批影评文本判断正面还是负面。为什么是这个一是数据集好找比如 IMDB 影评数据集网上直接可下载二是任务足够简单模型可以很小训练时间短方便快速迭代三是它覆盖了 AI 工程的完整链路——数据清洗、特征处理、模型训练、评估、部署、接口调用一样都不少。项目开始前先在心里过一遍你要用的评估指标。二分类任务里准确率有一定参考价值但类别不平衡时就不够看建议同时盯住 F1-score 和混淆矩阵。刚开始做可以给自己定个及格线测试集 F1 不低于 0.85。0.85 是一个“模型真的学会了而不只是在训练集上死记硬背”的分水岭。3.2 数据准备八成的工作量都在这里很多新手拿到数据就开训这是效率最低的做法。我做一个项目时数据预处理的时间通常占整个项目周期的 60% 到 70%。你可别嫌繁琐这一段做得越扎实后面训练就越顺。拿 IMDB 数据集来说原始数据的格式是每一条样本包含文本和标签。第一件事是清洗去掉 HTML 标签、统一大小写、处理标点符号。但这里有个误区很多人会顺手把所有停用词都去掉比如“not”“no”这类词在情感分析里恰恰是关键的否定词去掉之后模型可能把“not good”误判为正面。我踩过这个坑后来处理文本数据时都会先做少量人工检查再决定要不要做去停用词这一步。接下来是文本向量化。传统做法是 TF-IDF 逻辑回归深度学习做法是词嵌入 LSTM/TextCNN。工程入门阶段我建议两条腿走路先跑一个 TF-IDF 逻辑回归的基线模型然后再上神经网络模型。基线模型的价值在于给你一个参考点后续模型如果连基线都打不过说明哪里出了问题。数据集划分同样要较真。随机切分在简单任务上没问题但如果数据里包含同一来源的多条文本随机切分会造成信息泄露评估结果虚高。稳妥的做法是按“来源”或“时间”维度切分保证训练集和测试集互不重叠。通用比例按 8:1:1 划分训练、验证、测试验证集用来调参测试集只在最后评估时碰一次。3.3 模型训练从零手写还是用现成框架第一个项目要不要从零自己实现神经网络我的建议很直接不要。AI 工程的目标是解决业务问题不是造轮子。你现在学的是工程落地能力先把 PyTorch 的nn.Module用明白等对整个训练流程有感觉了再回头看反向传播的实现细节理解和收获都会更深。用 PyTorch 实现一个基础的 TextCNN 模型大概六十行代码就能写完。TextCNN 的思路很直观用多个不同尺寸的卷积核去提取 n-gram 级别的局部特征然后做最大池化接一个全连接层输出分类概率。它比 LSTM 简单训练速度快适合作为第一个深度学习基线。import torch.nn as nn class TextCNN(nn.Module): def __init__(self, vocab_size, embedding_dim, num_filters, num_classes, kernel_sizes): super().__init__() self.embedding nn.Embedding(vocab_size, embedding_dim, padding_idx0) self.convs nn.ModuleList([ nn.Conv1d(embedding_dim, num_filters, kernel_sizek) for k in kernel_sizes ]) self.fc nn.Linear(num_filters * len(kernel_sizes), num_classes) def forward(self, x): x self.embedding(x) # [batch, seq_len, embedding_dim] x x.transpose(1, 2) # 转为 [batch, embedding_dim, seq_len] pooled [] for conv in self.convs: c conv(x) # [batch, num_filters, seq_len - k 1] p c.max(dim2).values # 最大池化 pooled.append(p) x torch.cat(pooled, dim1) return self.fc(x)模型负责前向计算训练逻辑则要多花点心思。训练时需要注意的细节非常多我挑几个关键的说。学习率是最重要的超参数。我的经验是先用一个中等学习率比如 5e-4观察 loss 曲线再决定方向。loss 一直不降就降低学习率loss 剧烈震荡就降学习率loss 降得特别慢也可以考虑适当提高。可千万别一次性设个 1e-2 就埋头训练那种情况我见太多了。批次大小会影响训练的稳定性和显存占用。文本分类这种小任务32 到 128 都是合理范围。我习惯从 32 开始显存有余量就增大训练集会更平稳。批次太大也会有问题模型收敛会更慢还容易陷入较差的局部最优。Epoch 数不能拍脑袋定。正确做法是配合早停机制每个 epoch 在验证集上算一次指标连续两三个 epoch 验证集指标不再提升就停止训练同时保留验证集指标最好的那一版模型权重。这样既省钱又能避免过拟合。optimizer torch.optim.Adam(model.parameters(), lr5e-4) criterion nn.CrossEntropyLoss() best_f1 0.0 patience 0 for epoch in range(30): train_loss 0.0 model.train() for batch_x, batch_y in train_loader: optimizer.zero_grad() logits model(batch_x) loss criterion(logits, batch_y) loss.backward() optimizer.step() train_loss loss.item() train_loss / len(train_loader) val_f1 evaluate(model, val_loader) print(fepoch {epoch}, loss: {train_loss:.4f}, val f1: {val_f1:.4f}) if val_f1 best_f1: best_f1 val_f1 torch.save(model.state_dict(), best_model.pt) patience 0 else: patience 1 if patience 3: print(验证集指标不再提升早停) break第一次跑通训练看到验证集指标超过基线时那种成就感是无可替代的。但实际上这只是一个开始真正的工程环节还在后面。4. 工程化落地从训练好的模型到可以交付的服务4.1 模型部署的两种主流路线模型训练完了到这一步很多同学会松口气但我说句实在话模型训练只是 AI 工程的 40%剩下 60% 是部署、监控、迭代这些让人头疼的事。如果你只会在 Jupyter Notebook 里跑模型那跟做个课设没太大差别。部署方案的选择跟你的业务场景强相关我按使用频率给你介绍两条路线。第一条是自建服务。简单说就是自己写一个 HTTP 接口包装模型推理逻辑。如果你用 PyTorch可以试试 TorchServe也可以直接用 FastAPI 手写。FastAPI 的方案我比较推荐部署灵活生态丰富出了问题好排查。模型上线前有个关键步骤叫模型序列化。PyTorch 里通常用torch.jit.script或torch.jit.trace把模型导出成 TorchScript 格式这样模型就能脱离原始的 Python 类定义独立运行部署方不用安装训练时那一堆依赖。这一步很关键我在生产环境踩过一个大坑直接pickle保存模型结果部署时因为本地和服务器 PyTorch 版本不一致导致反序列化失败后来老老实实改用 TorchScript 才彻底解决。用 FastAPI 部署推理接口的简化版代码如下from fastapi import FastAPI from pydantic import BaseModel app FastAPI() model torch.jit.load(best_model.pt) model.eval() class InputText(BaseModel): text: str app.post(/predict) def predict(input_data: InputText): tokens tokenize(input_data.text) logits model(tokens) prob torch.softmax(logits, dim-1) label torch.argmax(prob).item() return {label: label, probability: float(prob.max())}这里有个容易被忽视的性能优化点。模型推理时如果请求一批一批地来每批的文本长度不一样Naive 的做法是每个请求单独进模型这样每次都要处理填充后的最大长度浪费大量算力。更好的做法是在接口层做动态批处理将一小段时间窗口内的多个请求攒在一起统一补齐到相近的长度一次推理返回多个结果。并发量上来了之后这个优化能帮我把吞吐量提升 3 到 5 倍。第二条路线是直接用模型推理框架。比如 Hugging Face TGI、vLLM、ONNX Runtime 这类工具。它们内部做了很多重度优化包括显存管理、连续批处理、量化推理等适合更大规模的服务场景。如果你的项目开始要求低延迟、高并发那很值得引入这些框架。4.2 模型压缩小模型也很有必要学很多入门教程不会讲模型压缩但这个技能在工程里非常实用。哪怕你只做一个二分类模型压缩之后也能明显降低部署成本。最基础的手段是量化。把模型的浮点权重从 FP32 降到 INT8模型体积直接缩小到四分之一推理速度提升一倍以上精度损失通常可以控制在 1% 到 2% 以内。PyTorch 里做 PTQ训练后量化很方便几行代码就搞定。import torch model torch.jit.load(best_model.pt) model.eval() quantized_model torch.quantization.quantize_dynamic( model, {torch.nn.Linear, torch.nn.Embedding}, dtypetorch.qint8 ) torch.jit.save(quantized_model, best_model_quantized.pt)另一个手段是蒸馏。用一个大模型的输出作为软标签去训练一个小模型小模型可以保留大模型绝大部分精度但体量和推理速度都更友好。如果你将来真的要接触大模型部署这个小技巧简直就是必选项。4.3 项目经验记录从第一次到第十几次变化在哪我第一次做这个文本分类项目时从数据清洗到部署上线零零碎碎花了两周。现在让我重做一遍可以压缩到一天内完成就差在手感上。很多步骤走过了才知道轻重缓急这里我分享几个环节的变化过程作为参考。数据清洗环节第一次我做每一步都很忐忑担心清洗过度后来我会先用统计方法看数据分布再动手清洗做到有所依据。模型训练环节第一次我特别执着于调参提升那零点几的分数后来明白工程项目的核心是交付稳定可用的方案那些过拟合验证集上刷出来的高分并不可靠。部署环节第一次做线上环境和本地行为不一致的问题想都想不明白后来知道关键是把依赖锁死、把模型导出成独立格式、并做好线上日志监控。从第一次到熟练的差异本质上是从“能跑通”走向“能掌控”的过程。保持节奏多复盘不用急。5. 实战中遇到的高频问题与排查实录5.1 训练不收敛、过拟合、显存溢出怎么办问题一训练 loss 不降或反向飙升。排查顺序从数据开始先检查标签是否错位尤其是用过zip打包数据时很容易出现样本特征和标签对不上。再查学习率太大会导致 loss 变成 NaN太小则降低收敛速度。如果数据没问题、学习率也看似合理尝试换一个优化器或者调整 momentum你会发现有些玄学就在这些配置之间。问题二模型在验证集上的表现远差于训练集。这是典型的过拟合信号。通俗讲就是模型把训练集背下来了却没有归纳出真实的规律。解决手段从易到难大概是加 Dropout、加大正则强度、降低模型复杂度、扩充更多数据或用数据增强。我自己的经验是文本分类任务中加 Dropout 的效果非常明显参数从 0.3 开始调就对了。问题三训练时显存不足CUDA out of memory。最容易出错的是把完整数据集一次性加载进显存新手常犯。正确处理方式是数据按批次加载。此外减少批次大小、降低序列长度、使用混合精度训练也都是立竿见影的办法。如果显存依然不够再考虑梯度累积技术分几步攒够一个大的梯度再更新一次参数效果等同于大批次训练。5.2 部署之后模型预测异常模型训练时效果好部署上线后效果变差这类反馈我收到过太多次。大概率是训练和线上特征不一致。举个例子训练时文本做了清洗比如去掉了br标签但部署代码里漏了这一步线上模型拿到的数据和训练时完全不是一个分布效果当然变差。排查这类问题的思路就是看数据流重新检查训练阶段的数据预处理代码把每一步都在部署的预处理函数里对齐。简单粗暴但有效的方法是找几条训练样本用部署环境的预处理流程走一遍对比处理前后的结果。只要有一条对不上就能锁定问题。5.3 环境相关的几个坑和对应的处理方案下面的表格是我在带新人和自己做项目时反复遇到过的问题直接整理出来给你当参考。问题现象核心原因一句式解决方案PyTorch 调用 GPU 时报错“CUDA not available”conda 或 pip 安装了 CPU 版 PyTorch重新用 GPU 版安装命令覆盖安装训练时多个包版本冲突没有做依赖隔离用 conda 或 venv 建独立环境锁定版本模型加载时提示类定义缺失用 pickle 保存而非 TorchScript改用torch.jit.save导出模型部署代码文本格式异常训练和部署预处理不一致写一个共享的预处理模块两边统一调用推理速度很慢每次都做单条推理引入动态批处理或模型量化训练 loss 变成 NaN学习率过大或数据含 NaN降低学习率检查数据清洗逻辑5.4 从零做一个项目前先给自己一张计划表经验之谈一个标准的从零 AI 工程项目大致的时间分配可以这样安排环节时间占比注意事项任务理解与数据探索10% 至 15%别急着动手写代码先看清数据和问题数据清洗与特征工程25% 至 35%这是决定模型上限的环节模型选型与训练迭代20% 至 30%记录每个实验的参数和结果方便回归评估与调优10% 至 15%用多个指标综合看别只看准确率部署与监控10% 至 20%留充足时间处理线上环境差异文档与项目总结5% 至 10%好记性不如烂笔头沉淀下来这份计划表同样适配其他 AI 工程项目。每当你接到一个新任务可以先按这个框架拆分一下心里有数了才不会在某个环节里陷进去出不来。6. 一些掏心窝子的经验和这条路的后续扩展从零入门 AI 工程真正拉开差距的往往不是聪明程度而是能不能沉下心把一条完整链路老老实实走通了。做第一个项目的时候可以每天晚上写个几行进度记录今天完成到哪一步、遇到什么问题、怎么解决的都记下来。等过一个星期回头看你会发现自己已经跨过了很多当初以为过不去的坎。还有个小建议如果你身边有正在做 AI 项目的同事或朋友多看看人家的工程目录结构和代码组织方式然后模仿着改进自己。我以前拿到一份老工程师的项目代码光是目录组织方式就学了不少东西——哪个文件夹放数据、哪个放模型、哪个放配置文件这些都是踩过坑之后才沉淀下来的经验。这个主题走到最后你会发现“从零开始”其实只是一个起点。当你能熟练地把一个小型项目完整落地之后后面进阶的方向很多把单机训练切换到分布式训练、把简单的目标函数替换成更复杂的定制损失、把传统深度学习模型升级到大模型的微调和推理优化。这些方向都离不开你在这篇文章里学到的工程基本功环境管理、数据处理、训练评估、部署监控。这一路不需要你有多么高深的数学功底也不需要你先发几篇论文只要一步一步动手做把每个环节的理解补全你就能真正踏入 AI 工程的大门。希望这篇记录对你有一点帮助也期待你早日完成自己的第一个从零到落地的 AI 项目。