直接开始写这篇博文。我换个切入方式从个人经历出发聊聊从零开始做 AI 工程这件事。1. 为什么要从零手写一个 AI 工程我接触 AI 工程有段时间了最深的感受是网上到处是五分钟训练一个模型一行代码调用大模型的教程看着热闹但真正上手做一个完整的 AI 应用时很多人会卡在第一步——不是模型不会调而是不知道整个工程该怎么搭起来。ai-engineering-from-scratch这个项目名的意思就是从零开始做 AI 工程。它不是让你去研究 Transformer 的数学原理也不是让你复现某个顶会论文而是把 AI 落地的完整链路走一遍环境怎么搭、数据怎么处理、模型怎么选、训练怎么调、结果怎么评估、最后怎么把模型真正用起来。这条链路走通了你才算真正入了 AI 工程的门。这个项目适合三类人。第一类是刚入门 AI 的开发者想找一个系统的路线图而不是东一榔头西一棒子地刷教程第二类是工程师转行做 AI已经有编程基础但缺少把算法变成产品的工程思维第三类是业务侧的同学需要和算法团队协作想搞明白对方在做什么、为什么这么做。我的建议是如果你目标明确、愿意花几个小时动手跑代码这篇文章能帮你少走很多弯路。如果你只想看概念、不想实操那收获会大打折扣。2. 整体设计拆解从算法到工程的关键一步2.1 核心思路把 AI 当作软件工程来做很多人做 AI 项目失败的根源是把 AI 当成算法实验而不是软件工程。算法实验的思路是拿一个公开数据集跑一个开源模型看准确率达标就收工。但真实世界的 AI 项目准确率只是起点后面还有数据质量、特征分布、训练稳定性、推理延迟、模型监控一堆问题。所以这个项目从一开始就刻意强调工程视角。举个例子数据处理阶段很多人直接用开源数据集跑通就完事。但真实业务场景里数据可能是脏的、缺字段的、标签不一致的。如果你不会写数据校验、不会做分布分析、不会处理数据泄漏问题模型上线后会发现线下评估很漂亮线上效果一塌糊涂。我在设计这个项目时把整个流程拆成了六个模块环境搭建、数据处理、模型训练、调优迭代、评估验证、部署上线。每个模块都有明确的技术选型、踩坑记录和验收标准。这样拆的好处在于任何一个环节出问题你能快速定位是环境问题、数据问题还是模型本身的问题而不是整个链路黑盒。2.2 技术选型为什么我选了 Python PyTorch技术选型是第一个需要拍板的决定。我在这个项目里用的是 Python PyTorch而不是 TensorFlow 或者直接用现成的纯 API 封装。原因有三点。Python 生态在 AI 领域是绝对主流。数据处理可以用 pandas、numpy计算可以用 PyTorch部署可以用 FastAPI调试可以用 Jupyter每个环节都有大量现成工具不会让你在语言层面卡脖子。PyTorch 的调试体验是它在工程落地中胜出的关键。PyTorch 用的是动态计算图你可以随时 print 中间结果也可以随时打断点查看张量内容。相比之下TensorFlow 的静态计算图在调试时就像在黑盒里操作出错提示也经常让人一头雾水。对初学者和新项目来说PyTorch 的上手曲线更友好。选 PyTorch 还有一个隐藏原因现在社区里的预训练模型、最新论文代码大部分是 PyTorch 实现的。这意味着你做模型迁移、复现对比时能找到的参考资料更多。选生态更繁荣的框架本质上是在降低后续维护成本。2.3 目标用户与使用场景我见过太多教程犯一个毛病默认读者什么都知道。讲模型训练直接丢一段代码说运行即可但读者连 conda 环境怎么建都没搞清楚。这个项目刻意做了分层。对于零基础读者我提供了一个标准的安装脚本和目录结构照着抄就能跑起来。对于有经验的工程师我保留了完整的参数调整空间不把超参数写死。项目里的每个模块都可以独立替换比如你想从 CNN 换成 Transformer改动应该控制在模型注册文件里而不是把整个流程推翻。还有一个场景容易被忽略离线开发与实际生产环境的差异。很多人在本地 Jupyter 里跑得好好的上线到服务器就报错。所以项目里专门加了环境一致性管理把依赖和版本固定下来确保换一台机器也能复现。3. 核心细节解析数据、模型与评估的实操要点3.1 数据处理比模型更值得花时间数据处理是决定 AI 项目成败的第一要素没有之一。很多初学者把精力全放在模型调参上但实际工程里数据的质量和数量往往更影响最终效果。我的实践经验是数据处理占一个项目 60% 以上的工作量这不是夸张。首先拿到原始数据的第一件事是摸底不是直接训练。我会用 pandas 做快速统计分析样本总量多少、字段缺失率多少、标签分布是否均匀、有没有重复样本。这一步虽然枯燥但能提前排除很多隐患。比如标签分布严重偏斜时直接训练得到的模型可能对多数类表现好、少数类几乎不识别需要提前采样策略。其次数据清洗要有记录、可追溯。我在项目里会写一个 transform 配置文件记录每一步清洗逻辑去重、去异常值、文本标准化、数值特征缩放。这么做的好处是你调完参数后想回退某个操作能清楚知道是哪一步影响了结果。有一个常被忽略的细节是数据泄漏问题。比如做用户行为预测时如果预处理时不小心把未来信息比如时间窗口之后的标签放进了特征里模型在训练集上表现会好得出奇但上线后立刻露馅。检查的方法是把时间维度拆开做验证集而不是随机拆分。3.2 模型选择先跑通基线再谈优化面对一堆模型算法初学者最容易犯的选择困难症。我的建议是不要一开始就追求 SOTAstate-of-the-art最先进的结果先搭一条最简基线baseline让整个流程先通起来。什么叫基线模型就是用最简单的方法、最少的特征、最朴素的模型结构跑通一遍训练和评估流程。比如文本分类可以先试 Logistic Regression图像分类可以先试一个小型 CNN。基线模型的准确率不一定要高核心目的是验证数据 pipeline 是不是通的、评估逻辑是不是对的、模型能不能正常收敛。基线跑通之后再逐步升级模型复杂度。这背后的逻辑是如果基线模型效果就很好说明问题本身不难不必过度用复杂模型如果基线效果差你要先判断是数据问题还是模型能力不够而不是盲目换更大的模型。我见过有人第一天就上 BERT结果显存不够、训练速度极慢最后连报错信息都看不懂。正确的路径一定是循序渐进的简单模型出基线复杂模型做突破。3.3 训练与调参超参数的感觉从哪来训练过程的调参是很多人觉得 AI玄学的部分。但其实超参数不是完全没规律核心就那几个学习率、批大小batch size、训练轮数epochs、正则化系数。最关键的是学习率。以最常用的 Adam 优化器为例默认学习率一般是 0.001但这个值不是固定的。如果 loss损失值来回震荡不下降多半是学习率偏大如果 loss 下降特别缓慢可能学习率偏小。最常用的办法是先用一个小数据子集试跑几个步骤观察 loss 的变化趋势找到一个基础学习率再正式训练。这里有个实操技巧把训练日志保存下来每个 epoch 的 loss 和验证集指标都记录下来。你会发现调参的时候光靠肉眼盯终端是不够的需要对比多轮实验数据。我用 TensorBoard 或者简单的 CSV 日志记录到后期做实验对比时效率高得多。还有一个容易踩的坑训练轮数不是越多越好。模型在训练集上的 loss 持续下降但验证集指标不再提升甚至下降就是过拟合信号。做法是加 early stopping早停机制比如连续好几个 epoch 验证集指标不涨就提前终止训练。这既能省时间也能防止模型过拟合。3.4 评估指标准确率之外还有哪些坑初学者评价模型第一反应是看准确率accuracy。但工程落地时准确率会骗人。比如一个风控场景99% 的样本是正常交易1% 是欺诈你就算把所有样本都判为正常准确率也有 99%——但模型毫无用途。这个项目里我详细解释了怎么根据业务场景选择评估指标。二分类问题要看精确率precision、召回率recall、F1-score排序问题要看 AUC回归问题要看 MAE、RMSE。不理解这些指标的差别就无法判断模型到底好不好。还有一个关键是区分线下评估与线上效果。线下评估用的是历史数据线上是实时数据两者分布可能有差异。业界有句话叫模型漂移指的就是数据分布随时间变化导致模型效果下降。所以我在项目里留了一个模型监控模块定期统计线上输入数据的分布发现异常就触发重新训练流程。4. 实操过程从零搭起一个可运行的 AI 项目4.1 环境准备一次配好少踩一天坑环境配置是我见过卡住最多新人的环节。这个项目的环境准备我用 conda 管理 Python 版本和依赖包用 pip 安装具体库。告诉你一个实用的顺序可以少踩很多坑。第一步创建干净的虚拟环境。不要直接在 base 环境装包因为你做的项目多了包之间的依赖冲突会把你逼疯。建议固定 Python 版本比如 3.10避免一些旧库不兼容新版本 Python 的问题。第二步安装 PyTorch。这里有个容易困惑的地方PyTorch 安装命令要看是否有 GPU 加速。有 NVIDIA 显卡的话装 CUDA 版本没有的话装 CPU 版本。判断方法其实很简单命令行输入 nvidia-smi有输出说明有驱动。第三步安装数据处理和工程化相关库。pandas、numpy、scikit-learn 这几个是基础的。然后看项目需要装 transformers 还是其他库。我踩过的一个坑是版本兼容性问题。PyTorch 不同版本之间的 API 有小变化有些开源模型代码是旧版写的直接跑在新版会报错。解决方案是项目的 requirements.txt 里固定版本号并且把测试过的环境和版本信息写进 README方便别人复现。4.2 代码结构让项目可读、可改、可复用很多 AI 项目只放几个 Jupyter Notebook全是一股脑顺序执行。Notebook 做探索性分析还可以但作为交付的代码工程它的缺陷很明显不方便测试、不方便复用、不方便部署。这个项目采用了一种更工程化的目录结构。核心是数据加载、模型定义、训练逻辑、评估逻辑、配置信息各归各类。比如src/data/放数据加载和预处理代码src/models/放模型结构定义src/trainer/放训练循环逻辑src/evaluation/放评估指标计算configs/放超参数 YAML 配置文件这种分层设计的好处是你换一个数据集只需要改数据加载模块换一个模型只需要改模型注册部分。整个流程不用推到重来。对维护期长、需求不断变动的项目来说可维护性远高于一个超级 Notebook。配置分离这块值得多说一句。超参数不应该硬编码在训练代码里而是放进一个独立配置文件。每次跑实验时你可以在配置文件里改学习率、批大小然后记录哪份配置跑出了哪个结果。这样实验的规范性就建立起来了。4.3 训练流程从跑通到跑稳训练的第一步是快速验证代码没有低级错误。我建议不要一上来就全量数据训练而是先取一个小数据集几百条跑一两个批次。这样如果有维度错误、类型错误一两分钟就能发现而不是等几个小时训练到一半才报错。第二步是完整训练。你会观察到 loss损失值的下降曲线。一个典型的趋势是开始阶段 loss 下降较快之后逐渐趋于平缓。如果 loss 完全不下降常见原因包括学习率设置不当、数据预处理有问题、模型结构有 bug。第三步是模型保存。不要只保存模型参数还要保存配套的预处理逻辑。我常用的做法是用 pickle 或 joblib 把数据预处理器如标准化器、编码器一并保存加载模型时一起加载。务必让预处理 — 模型预测的流程保持完全一致。训练过程中还要注意可复现性。同样的代码跑两次结果完全一样吗不一定因为 GPU 计算有随机性。为了保证可复现我会在训练前设置随机种子包括 Python 的 random、numpy、PyTorch 的随机种子。这样跑实验时对照组和实验组的差异才真正来自代码改动而不是随机波动。4.4 评估与部署模型不是在 Notebook 里终结模型训练好之后评估环节不能只输出一个准确率数字就结束。我会做三个层面的评估一是整体指标包括准确率、F1 等二是分维度分析比如不同类别分别表现如何三是错误样本分析把预测错的样本捞出来逐条看确认是标注错误、特征缺失还是模型理解不到位。错误样本分析是提升模型效果最有效的手段。很多情况下你会发现某些错误是预处理逻辑导致的。比如文本清理时把关键信息连同噪声一起过滤掉了或者某些样本本身标签就有问题。修补这些数据层面的问题往往比调模型参数涨点更多。部署这块我讲一个最轻量的方案用 FastAPI 封装模型推理接口把模型预测变成一个 HTTP 服务。具体做法是写一个预测函数接收输入数据、做预处理、传给模型、返回结果再用 FastAPI 包一层 API 接口。调用方只需要发 HTTP 请求不需要关心模型内部细节。部署时的细节容易被忽略模型推理必须保持和训练时一致的预处理方式。比如你训练时对文本做了全部转小写 去除特殊字符那线上推理也必须有同样的步骤否则预测效果会有偏差。最好把预处理逻辑抽象成同一个函数文件训练和推理共用。5. 常见问题与排查实录5.1 环境依赖冲突与报错PyTorch 与 CUDA 版本的兼容性是最常见的问题。装完 PyTorch 后在 Python 里执行 import torch再打印 torch.version.cuda如果和显卡驱动版本差距太大代码可能报错或者根本没启用 GPU。另一个常见的坑是 pandas 版本新老 API 差异。比如排序函数 sort 在新版里改成 sort_values代码在旧版能跑、新版就报错。我的经验是遇到 AttributeError 先查对应函数在 pandas 文档里的变更记录通常不是你的代码有问题而是库版本变了。Conda 环境的另一个问题是包解析有时非常慢。如果安装命令卡住可以换用 pip 安装特定包或者把 conda-forge 频道加进来。但要注意混用 conda 和 pip 安装时环境可能会乱建议主力用 conda 管理大的环境如 Python 版本、CUDA 相关具体库用 pip 装。5.2 过拟合与欠拟合的应对过拟合和欠拟合是模型训练最需要关注的两个问题。过拟合的表现是训练集指标很好、验证集指标差欠拟合的表现是训练集指标本身就不好。两个问题的处理策略完全不同。过拟合的处理方式有增加训练数据量、降低模型复杂度、加正则化如 dropout、权重衰减、做数据增强。欠拟合的处理方式则相反换更复杂的模型、增加特征、减少正则化强度。很多人一上来就加数据增强但如果是欠拟合问题加数据增强只会让情况更糟。还有一个判断技巧把训练集和验证集的 loss 曲线放在一起看。两条线差距很大说明过拟合两条线都高说明欠拟合两条线都在高位震荡可能有其他问题。用这个思路比盯着单个指标瞎猜更有效。5.3 GPU 显存不足的处理显存不足是训练视觉类模型和大语言模型时的常客。如果报 CUDA out of memory我的排查顺序是这样的先看是不是 batch size 太大调小一点再看。如果还不行看是不是有变量没释放尤其要检查训练循环里是否人为保存了不需要的中间张量。数据加载部分也可能占显存试着用 DataLoader 的 num_workers 参数,让数据加载并行化。还有一个偏门的点PyTorch 的显存不会自动完全清空。你如果连续跑了好几个实验可能有残留显存占用。用 nvidia-smi 查看进程确认没有僵尸进程在占用显存。最根本的解决方案是改变思维方式在小 batch 下跑更多步数往往比大 batch 少步数更稳定而且显存占用小。很多人一味追求大 batch size以为能加快训练实际上还可能让收敛变差。5.4 模型效果不好先排查数据最后一个常见场景模型效果就是不好怎么调参也不行。这时候我建议做个快速诊断判断源头在哪随机抽 100 条训练数据人工逐条看一遍确认数据标签是否合理。接着做特征相关性分析看看特征和目标有没有明显关系。然后单独跑一个极简模型比如在数值特征上跑线性回归看能不能学到点东西。如果极简模型完全学不动那你先别调模型了回头处理数据。很多时候问题的根源都很朴素数据收集方式导致偏差、标签定义不清晰、特征工程有误。模型只是把数据里的信号学了出来数据本身没信号模型再复杂也白搭。我记得有一次做文本分类验证集准确率只有 70%我调了两天参后来才发现是数据清洗时把一些重要关键词给过滤掉了。模型不是能力不够是根本没见过那些关键词。这个教训让我后来每次调参之前一定先回到数据里找答案。6. 个人经验与复盘如果让我复盘ai-engineering-from-scratch这一个完整的项目过程最大的体会是AI 工程的核心能力其实是拆解复杂问题的能力。你看起来是在跟模型打交道实际上更多时候是在跟环境配置、数据质量、代码结构打交道。把这些底层问题解决好了模型训练本身反而成了比较顺理成章的一步。还有一个心态上的建议不要被别人的 benchmark基准测试结果吓到。公开数据集上的 SOTA 分数是在特定数据分布、特定算力条件下取得的放到你的业务场景里未必适用。你需要的是适合自己场景、能在算力和时间约束下跑出来的模型而非一个不可能达到的论文数字。最后分享一个一直沿用的小技巧每做一个实验都用 Markdown 记录下目标、配置、结果、结论。哪怕只是两三行。一个月后你会发现这份实验日志是你在项目复盘中最重要的资产。很多踩过的坑在第二次遇到时翻日志就知道该怎么处理了。这个项目做完之后后续可以做很多扩展把模型封装成 Docker 服务、加入自动重训练流程、接入模型监控指标看板。每一步都是在从零开始的基础上长出来的但每一步都不会太难因为你知道整条链路是怎么串起来的。