说来惭愧我正儿八经开始搞 AI 工程不是从一门网课开始的而是从一份叫ai-engineering-from-scratch的项目清单开始的。这个项目名字很直白把 AI 工程的全流程从环境初始化到模型上线不靠现成平台不靠一键训练硬生生自己搭一遍。做完之后我对“AI 工程”这四个字的理解彻底变了模型训练只是其中一小块真正难的是怎么把数据、训练、部署、监控串成一个能持续运转的系统。这个项目适合谁我觉得最适合两类人一种是从算法岗转工程岗、总感觉缺了一块拼图的人另一种是独立开发者或小团队技术负责人想把模型真正落地成服务而不是停留在 notebook 里跑个准确率。项目不预设你已经很懂工程但确实需要你愿意动手踩坑。下面我把整个搭建过程和思考完整拆开讲所有细节都是我实际摸过、试过、翻过车的。1. 项目整体设计先看清 AI 工程的完整地图1.1 这个项目到底要解决什么问题很多人一聊 AI 工程第一反应就是“找个模型练一练”。但实际上一个能在生产环境跑起来的 AI 系统模型只是链路上的一环。ai-engineering-from-scratch要解决的第一个问题就是把这条链路完整走通并且让每个环节都可重复、可回溯、可监控。我画过一张自己的链路图不是文档里的抽象架构是踩坑后总结出来的业务问题转成模型问题再做数据采集与清洗然后是特征工程与实验管理接着训练评估再往后是模型导出与服务的封装上线之后还有监控与定期重训。任何一个环节缺了模型都很难持续发挥价值。这个项目最大的设计初衷就是让你亲手把每一个环节都搭出最小可用版本而不是用一个现成的端到端平台把自己屏蔽在黑盒外面。1.2 为什么选择 from scratch 的路线一开始我也犹豫过市面上有现成的机器学习平台有 AutoML有各种成熟的推理框架为什么还要从零搭我的理由是只有自己搭过一遍才能理解每个组件为什么存在。比如模型注册这个概念第一次接触时觉得只是存个模型文件等我自己做实验记录、回滚版本、对比指标时才知道模型注册本质上是在解决“可复现”和“可治理”两个问题。这个项目选择的路线是“半手工”基础设施用开源工具尽量不重复造轮子但核心流程比如训练脚本、评估逻辑、模型打包服务全部自己写。这样做的好处是你对整个系统有完全的控制力坏处是一开始会很慢而且每一步都可能踩坑。但正是这种慢把知识真正沉淀下来了。如果你未来想去大厂或者成熟团队这套底层认知能让你很快看懂别人搭的系统。1.3 技术栈与工程范围先定边界再动手做这种从零项目最大的风险是范围失控。我给自己定了三条边界第一做单机可跑通的小型项目不追求分布式训练第二聚焦结构化数据和经典深度学习任务比如二分类和简单图像分类第三部署目标是单容器服务不做复杂的多服务编排。最终技术栈是一个很务实的组合Python 3.11 做语言基础PyTorch 训练模型pandas 和 Polars 做数据处理MLflow 管实验和模型注册FastAPI 做推理服务Docker 做打包GitHub Actions 跑简单 CI。工具没有追求最热门但都是社区成熟、资料多、出问题能搜到解答的东西。范围定清楚之后后面的每个环节就都有了锚点。2. 环境与工具链选型打好地基才能谈训练2.1 Python 虚拟环境依赖冲突会让你怀疑人生这个项目踩的第一个大坑就是 Python 依赖管理。你可能会想直接pip install不就行了但 AI 项目里涉及 PyTorch、NumPy、pandas、scikit-learn 这些库彼此版本牵连非常紧密。尤其是 CUDA 相关的包装错一个版本就能让 GPU 直接罢工。所以我的第一道防线是虚拟环境。实际项目里我用了venv加uv的组合。venv保证环境隔离uv负责快速安装和解析依赖。如果你还在用裸的pip install直接装到系统 Python我强烈建议立刻改掉。一个虚拟环境就是给项目造一个独立的屋子里面再怎么折腾都不影响整个系统。虚拟环境之外还要给每个项目锁住 Python 版本。我见过太多人项目跑得好好的换台机器 Python 版本不一样就崩了。用.python-version配合pyenv或者干脆在 Docker 里固定基础镜像版本都能把这个变量控制住。依赖管理这件事看着不起眼但它是所有后续可复现工作的地基。2.2 依赖锁定让训练结果可以复现环境隔离只是第一步第二步是依赖锁定。requirements.txt里如果只写着torch2.0那么半年后你重新安装可能拿到一个行为完全不同的版本。这种不确定性对 AI 工程是致命的因为模型训练结果可能因为一个库的细微变化就产生指标波动。我最终的做法是维护两层文件上层是requirements.in写上直接依赖的大版本范围下层是requirements-lock.txt用工具锁定每个包的具体版本号连传递依赖也锁死。训练时我还会把pip freeze的结果存进实验记录确保以后回滚时不仅代码能回到旧版本环境也能重建。这里有个容易被忽略的细节操作系统层和 GPU 驱动层也要记录。我踩过“换了一台机器CUDA 驱动版本不对容器能起来但 PyTorch 找不到 GPU”的坑。后来我在项目 README 里专门维护了一份环境基线表包括操作系统、驱动、CUDA 运行时、Python版本、关键依赖版本。这才是真正意义上的可复现。2.3 GPU 资源选型不是越贵越好训练一个从零项目是不是必须上 GPU我的回答是看任务规模和你的耐心。我第一次跑通全流程其实是在 CPU 上完成的用的是一个很小的数据集模型也很浅。CPU 环境能让你不受资源限制优先把代码逻辑和工程链路跑通这是一个非常划算的策略。等逻辑稳定后我切换到一台带 RTX 3060 的机器上做正式训练。对于实践型项目单卡 12GB 显存已经覆盖了绝大多数中小模型的训练需求。真正要小心的不是卡不够强而是显存管理。我经常在训练脚本里看到有人直接把整个数据集加载进显存结果 OOM。合理做法是使用DataLoader分批加载必要时用混合精度训练。混合精度这个东西不玄乎就是让部分计算用 FP16既能减显存又能提速度但要注意梯度缩放和某些算子的精度问题不能无脑开。3. 数据工程模型质量的上游命脉3.1 先想清楚评价指标再去收集数据ai-engineering-from-scratch的原则里有一条指标先于数据。很多人拿到数据就开训最后发现模型指标不好看但不知道是数据问题还是模型问题。我的做法是先定义业务目标和对应的评价指标再把指标拆到数据要求。举个实际例子我当时做的是一个用户流失预测的二分类任务。业务上最关心的是能不能把真正流失的用户找出来而不是整体准确率。所以我选择用召回率和 F1 作为核心指标而不是 accuracy。这个决定直接影响了数据采集的时候要关注哪些字段也影响了后面的重采样策略。如果一开始用准确率定目标模型大概率会倾向预测“不流失”因为流失用户占比少模型全部猜负样本也能有很高的准确率但那对业务毫无用处。数据收集前我会写一份简单的数据说明包含每条样本代表什么、预测目标怎么定义、类别分布大概什么样、哪些字段可能缺失。不是要写很正式的文档而是要逼自己把问题说清楚。项目走到后面你会感谢这份说明因为很多调试问题最终都要回到数据定义上。3.2 清洗和特征工程能自动化就自动化清洗数据看起来是脏活累活但在这个项目里我反而觉得是最值得花时间研究的部分。缺失值怎么填、异常值怎么处理、类别特征怎么编码这些决策都会直接进到模型效果里。我给自己定的一条铁律是所有清洗逻辑必须写成函数不能靠 notebook 里手工改单元格。比如处理缺失值我先区分两种缺失完全随机缺失和跟业务相关的缺失。如果是收入字段缺失可能暗示这个用户类型特殊简单填充均值反而是错的。更稳的做法是为缺失单独建一个二值特征或者用“未知”类别填充。对于异常值我不是直接用统计阈值删掉而是先画出分布图搞清楚异常是脏数据还是真实极端情况。真实极端值删掉以后模型上线会变得很脆弱因为线上也会出现极端情况。特征工程我只建议做两件事基于业务逻辑构造少量有解释性的特征然后用交叉验证验证这些特征是否稳定有效。不要一上来就搞几十个自动生成的特征那样不仅难以解释还容易引入目标泄露。所谓目标泄露就是特征里不知不觉包含了未来信息导致训练指标虚高上线后立刻现原形。我做过一个非常典型的错误用“用户是否投诉过”这个字段预测“用户是否流失”但投诉记录是在流失之后才产生的这就在时间上构成了泄露。这个问题很难靠模型自动发现只能靠人工审计。3.3 数据版本管理给模型做审计准备代码有版本管理模型有模型注册但数据往往被忽略。这个项目早期我因为没有做数据版本管理吃过一次大亏模型训练时用的数据跟评估时用的数据对不上导致指标乱掉后来花了两天排查才发现是数据文件被覆盖了。从那以后我引入了 DVC 来做数据版本管理。DVC 的思想并不复杂像 Git 管代码一样管数据数据和代码绑定在同一个 commit 里但数据本体存储在远端本地只保存元数据。每次模型实验都会记录数据集的版本哈希这样复现实验时只要切到对应的 commit就能把当时的数据一起拉下来。我建议的最小数据版本实践是至少给每个数据集文件加一个SHA256校验文件并在实验记录里存下这个值。如果你的项目还没有上 DVC可以先做这一步成本很低但救命效果很好。数据版本管理属于那种“没出事时觉得多余出了事才知道有多必要”的基建。4. 模型训练与实验管理从跑通到可控4.1 用最简单的基线模型建立流程很多人在这一步会犯一个错误一上来就想用最新的 SOTA 模型。我的经验是第一个模型一定是“能跑通全流程的最简模型”。在分类任务里我起手用的是逻辑回归和一层浅 MLP目标不是刷分而是验证数据管道、特征处理和评估代码是不是正确的。为什么这么做因为复杂模型会把问题掩盖掉。举个例子如果数据清洗阶段有 bug逻辑回归会因为指标异常而暴露问题但换成大型深度模型它可能凭借强大的拟合能力硬生生把分数拉回来让你误以为一切正常。这种“虚假的正常”在 AI 工程里最危险。建立基线模型时我会写一个非常标准的训练脚本包含数据加载、切分、训练循环、验证、保存。脚本的目标是确定性设置随机种子关闭不必要的随机性让同一次输入重复运行得到近乎相同的结果。只有基线稳定了后面做的任何优化才敢说是优化而不是噪声。4.2 超参数调优把经验变成可复现参数基线跑通后接下来是调参。但调参不是玄学也得有流程。我先用手动网格搜索确定关键参数的粗略范围再用随机搜索做更细的探索。有人会问为什么不用贝叶斯优化我也试过但项目早期样本量小贝叶斯优化很容易过拟合到验证集。反而是随机搜索配合足够的交叉验证轮数在实践中更稳妥。调参过程中要特别留意“验证集污染”。如果你反复在同一份验证集上看结果最终选出来的超参数其实已经悄悄记住验证集了。这个问题的解法是再做一层留出测试集调参只用训练集和验证集最后在完全没碰过的测试集上做一次终极评估。这个测试集最好从项目一开始就锁在保险箱里连看都不要多看。另外每个实验都要记录超参数组合和对应的指标。我早期靠脑子记实验结果调了二十多次参数之后完全分不清哪次是什么配置。后来老老实实用 MLflow每次实验自动记录参数、指标、代码版本和模型产物。你可以不用 MLflow但必须有一个同样的机制否则你的所有调参经验都是一笔糊涂账。4.3 实验管理让每次尝试都能回放实验管理是ai-engineering-from-scratch里我最想推荐给所有人的一环。很多独立开发者跑到最后手里有好几个模型文件但已经分不清哪个是在什么数据、什么参数下训练出来的。这种状态非常危险因为你不敢把任何一个模型放心上线。我用的方案是 MLflow 自建服务其实也可以用简单的方式每个实验建一个目录存放配置文件、日志、模型权重和评估结果。关键是要形成一套固定命名规则比如experiments/2026-05-01/lr_focal_cv3。但在多人协作或长期项目中MLflow 的模型注册能力会更有价值。它可以给模型标记阶段staging、production、archived。我在部署阶段就是通过模型注册中心拿到指定版本然后再打包这样上线和回滚都变得非常清晰。实验管理还有一层作用逼迫你写训练配置而不是写死常量。我在代码里没有把学习率写死而是用 YAML 配置文件这样每次实验改配置就像填表一样简单。这个习惯一旦建立会让你后续跑实验的效率提升一个量级。5. 服务化部署让模型真正被使用5.1 模型导出与封装离线推理和在线推理要分开训练完一个模型离上线还差十万八千里。第一个问题是模型导出。PyTorch 训练保存的是state_dict不能直接用于服务。我一般先把它转成 TorchScript 或 ONNX再部署到服务里。ONNX 的好处是中间表示统一生态支持广泛但某些自定义算子可能转换失败TorchScript 和 PyTorch 绑定更紧兼容性更好但跨框架能力差一些。我的建议是如果项目只用 PyTorchTorchScript 就够了如果要对接不同推理后端再考虑 ONNX。封装模型时要区分离线推理和在线推理。离线推理场景比如批量预测一批用户吞吐比延迟更重要可以一次处理大量样本允许跑得慢一点在线推理场景比如 API 实时预测延迟是关键模型加载、输入预处理、推理、后处理都要优化到百毫秒级甚至更低。我在项目里做了两个服务入口共用同一个模型文件但批处理大小和超时策略完全不同。预处理和后处理的代码要跟训练时保持一致。这是一条容易翻车但极其重要的规则。训练时你把文本做了小写化、去停用词上线时忘了这些步骤模型性能会暴跌。我在项目里把数据变换器单独抽成一个模块并且用训练时的测试样例做了回归测试。每次部署前我都会用同一样本在本地模型和线上服务各跑一遍保证输出完全一致。5.2 API 服务设计并发、超时、限流和优雅降级在线模型本质上是一个计算资源有限的函数。FastAPI 是很好的选择它天然支持异步和并发配合 Pydantic 做输入校验很容易写出干净的服务。但服务不是能响应请求就够了。我在项目里重点处理了三个问题超时、限流和优雅降级。模型推理如果遇到极端输入可能非常慢所以我给推理接口设置了超时时间超时后立刻返回一个默认结果而不是让客户端一直挂着。限流方面我用简单的令牌桶实现防止瞬时大流量把服务打崩。降级策略则是当模型服务不可用时返回一个预设的业务逻辑兜底结果比如预测概率设成历史平均值。这里我遇到的教训是不要把模型预测做成同步阻塞调用。曾经我把推理函数直接放在 FastAPI 的请求处理里结果一个慢请求占住了 worker后面请求全部排队服务整体被拖垮。后来的方案是用异步任务队列加结果轮询或者至少配合批量推理收集器把并发请求聚合成 batch一次喂给 GPU大幅提升吞吐。批量推理是需要自己写逻辑的但收益非常大。5.3 容器化与 CI/CD让发布模型变成顺手的事模型服务的部署我选择用 Docker 打包。Dockerfile 里有几个关键点基础镜像要固定版本比如python:3.11-slim不要用latest系统依赖要一次性装好模型文件尽量通过镜像层复制进去而不是在容器运行时再从外部下载。镜像构建好后我用 GitHub Actions 做简单的 CI/CD。CI 阶段跑单元测试和模型精度校验比如用测试集跑一次最近训练的模型确认关键指标没有跌破阈值CD 阶段构建并推送镜像然后在测试服务器上替换服务。这个流程看着简单但它让模型更新变成了一件“很自然”的事而不是每次都要手动登录服务器上传文件。部署完成后我还会做一个冒烟测试用制作好的测试请求打一遍线上 API确保服务正常。曾经有一次代码改动后服务能启动但推理时输入格式不对导致所有请求报错而单元测试没覆盖到这个场景。从那以后冒烟测试和线上健康检查卡点就成了必选项。6. 监控、评估与迭代AI 工程的长期命脉6.1 线上监控不只是延迟和 QPS模型上线不是终点而是监控的起点。很多人部署完服务只盯着延迟和 QPS却完全不管模型预测质量。延迟反映的是系统健康而预测质量反映的是模型价值。我在项目里把监控分成两层系统层和模型层。系统层监控主要是 CPU、内存、GPU 利用率、请求数、错误率、P99 延迟。这些指标用 Prometheus 加 Grafana 就能搭起来。模型层监控则更关键每个请求的预测分数分布、正负样本比例、输入特征分布都要记录并定期画图。一旦发现预测分数整体偏移或者输入特征分布跟训练集有了明显差异就是预警信号。监控数据要沉淀成日志或数据库不要太早丢弃。有一次我排查一个线上问题最后靠的就是三周前的请求日志。那批日志在排查完模型 bug 后差点被我删掉幸好多留了一个月后来做复盘时又用到了。日志和监控数据是 AI 工程里最容易被低估的资产。6.2 数据漂移模型什么时候会失效数据漂移是模型上线后最隐蔽的风险。训练时用的数据分布和线上真实数据分布不一致模型效果就会悄悄下滑。常见有两种漂移概念漂移指业务规律发生变化比如用户行为模式改变了数据漂移指特征本身的分布变化比如新注册用户的年龄结构与老用户完全不同。我做的检测方法很直接对关键特征做分布对比用 KS 检验或 PSI 指标观察线上数据与训练集数据的差异。KS 检验适合连续特征PSI 把分布分成多个区间后计算偏移程度两者可以结合使用。发现漂移之后不一定要立刻重训但至少要把问题记录在案并评估是否需要补充新数据。这里有一个我特别想强调的观念离线指标不能完全代表线上表现。我的模型在测试集上 AUC 是 0.85上线两周后线上预估的正样本比例明显下降而真实业务数据也证实了趋势在变。如果只看离线指标会以为一切正常实际模型已经在失效。所以监控指标必须包含“预测分布 vs 真实标签”的对比有条件的项目还要做人工抽样评估。6.3 重训策略从定期重训到按需重训模型重训策略在我最初的设计里是“每个月定时重训一次”。但实际跑下来发现固定周期不够灵活有时候数据分布变化很快一个月等太久有时候数据平稳重训反而引入噪声。我后来改成“周期训练 触发器”的结合策略。触发器包括几个条件检测到明显的数据漂移、核心线上指标跌破阈值、有新的高质量标注数据积累到一定量。每次重训都要走一遍完整的训练评估和发布流程并且跟当前线上版本做 A/B 对比。我的原则是新模型必须至少在一个小流量桶上跑几天确认没问题再全量发布。这个做法看起来慢但极大减少了上线翻车的概率。重训还有一个容易忽略的环节版本回滚预案。新版模型上线前要确保旧版镜像和模型文件还保存着并且具备一键回滚能力。我经历过一次新模型上线后效果反而变差的情况幸好保留了旧版镜像十分钟内就完成了回滚不然影响会更大。7. 常见问题与排查技巧实录7.1 环境相关依赖冲突、CUDA 版本、磁盘占满这类问题我可以列一个速查表问题现象可能原因排查思路训练时找不到 GPUCUDA 驱动版本与 PyTorch 不匹配检查nvidia-smi驱动版本对照 PyTorch 官方要求的 CUDA 版本安装某个包时依赖冲突多个包对同一底层库版本要求不同用uv或pip-tools重新解析依赖必要时新建虚拟环境训练中途报磁盘满日志、模型权重和缓存文件占用过大检查~/.cache、/tmp设置日志轮转定期清理模型备份容器内无法访问 GPU容器没有挂载 GPU 驱动用--gpus all运行容器并确认镜像内安装了对应 CUDA runtime环境问题看起来繁琐但解决方案通常是体系化的虚拟环境隔离依赖、Docker 隔离系统环境、状态记录区分版本。只要这三条线做到位环境问题会少掉八成。7.2 模型训练效果差先查数据再调参数模型效果不好时我的排查顺序永远是数据 → 特征 → 模型 → 参数。这不是理论而是实际操作后的教训。先看数据有没有泄露样本有没有重复标签有没有噪声再看特征有没有异常分布最后才去调模型结构和超参数。我做过一次定位了很久的排查。模型训练损失不降怎么看都像模型容量不够于是不停加层数结果还是没改善。后来一步步回查发现数据里 30% 的样本特征全是空值被我用一个常量填了。这类样本对模型来说就是噪声把数据清洗正确后浅层模型的表现立刻有了明显提升。这件事之后我再也不允许自己跳过数据验证直接调模型。7.3 部署上线模型封装不一致和线上数据格式变化部署阶段最常见的坑有两个一个是训练和推理的预处理不一致另一个是线上数据格式变化。预处理不一致的问题靠回归测试能解决大部分。我会在训练代码和部署服务里共用同一份特征变换模块并用保存的样例数据做单元测试。线下数据格式变化是更难发现的上游业务字段改了命名新增了枚举值或者某个字段在特定时段全是空值。这些情况如果没提前做防御服务会默默用错误数据推理。我的对策是在服务入口对每个特征做范围校验和类型校验遇到未知枚举值直接走日志告警而不是静默处理。这样至少能保证问题发生时有迹可循。写在最后ai-engineering-from-scratch走完一遍最大的收获不是某个模型的指标而是我终于理解了 AI 工程里“工程”两个字的分量。以前写 notebook 只需要对自己负责现在却要对数据、模型、服务、监控整个链路负责。如果让我重新做一次我会把更多时间花在数据验证和线上监控上而不是调参数。这两个环节做得越扎实后续迭代就越省心。最后再分享一个小技巧每踩完一个坑就把原因和解决过程写进项目仓库的docs/lessons.md。这份文档现在是我最常翻阅的资料也是这个项目从“练习”变成“资产”的关键一步。AI 工程这条路没有终点但只要每一步都有记录下次就能走得更稳。