翻开去年的项目仓库我还能想起当时从一堆 Notebook 里硬生生提炼出一个可交付 AI 服务的那种狼狈。说起来是 AI 工程师实际干的是数据清洗、环境修复、接口调试的杂活。所以朋友问我从零开始学 AI 工程到底要经历什么时我决定把这个从 scratch 搭建的完整项目复盘出来不谈大模型参数不谈炫酷算法只讲从原始数据到稳定服务之间那段最容易被忽略、也最值得投入的工程链路。这篇文章适合三类人已经在跑模型但没做过工程化交付的算法工程师想从后端或数据分析转 AI 工程方向的新人以及正在搭团队协作规范的小组负责人。我会从项目拆解、技术选型、核心原理、最小落地实操到高频坑点全部过一遍很多内容不是文档里能直接抄到的属于被坑过之后才理解的细节。1. 项目整体定位与知识地图1.1 这个项目到底想解决什么问题这个项目的名字叫 ai-engineering-from-scratch核心目标不是训练出一个 SOTA 模型而是从零搭建一套可复现、可测试、可观测、可交付的 AI 应用流水线。很多从 Notebook 入门的朋友最大的困惑就在这里单机实验里 loss 降到 0.2一到线上就崩本地能跑换台机器就报错模型文件用网盘传来传去版本都对不上。这个项目就是为了把这些最后一公里的问题一次性趟完。我用一个非常经典的场景作为载体中文短文本分类服务。数据来自公开的带标签评论集规模不大几万条。任务本身很简单但麻雀虽小五脏俱全从数据清洗、特征工程、模型训练、实验记录、服务化部署到监控告警每个环节都能独立展开。这个选择是有意为之如果一开始就冲多模态大模型工程细节会被模型复杂度掩盖根本练不到基本功。项目交付物也不只是一堆代码文件而是一套完整可复现的工程资产数据版本库、训练脚本、实验记录、Docker 镜像、部署配置、监控面板和给团队看的协作文档。这也回答了很多人学 AI 工程到底学什么的问题——学的是如何让算法稳定复现、团队高效协作、系统持续运转。1.2 从零到一的技术栈选型逻辑我见过太多人一上来就争论 PyTorch 和 TensorFlow 哪个好然后陷入框架选型泥潭。选型真正的逻辑只有一条能不能让你的系统在三个月后依然有人愿意维护。这个项目里我选的是 PyTorch不是因为它在所有场景都碾压而是因为社区生态活跃、调试时出错信息可读性好、迁移到生产环境时的工具链最全。数据版本化用的是 DVCData Version Control搭配本地 MinIO 作为远端存储。为什么不直接用 Git 管理数据因为 Git 设计目的是文本源码一个几百 MB 的二进制数据集提交进去仓库立刻膨胀clone 一次要等半天。DVC 用 Git 记录数据文件的元信息和哈希真正的数据丢到对象存储里需要的时候拉取指定版本这才是数据版本管理的标准姿势。实验跟踪平台我选了 MLflow模型服务框架用 FastAPI容器化用 Docker编排调度先用简单的 Shell Makefile 顶住。这套组合最大的好处是每个组件都只解决一个问题互相之间用标准接口通信不会被某个全家桶套牢。就像装修不用全屋定制而是挑了几件耐用、修起来方便的家具。1.3 为什么AI 工程不等于写模型很多人的误区是把 AI 工程理解为训练模型其实训练在整个交付生命周期里只占很小一块。一个完整的 AI 工程岗位日常大约是这样分布的数据准备工作量排在第一位因为喂给模型的数据质量直接决定效果上限其次是上线后的监控和维护你得能判断模型是不是悄悄生病了再然后是训练实验和调优最后才是写接口、调并发这些服务化事务。用生活类比解释这个问题训练模型有点像做菜很多人以为菜好吃全靠掌勺那一下但真正的后厨大师会告诉你食材处理、火候控制、出餐顺序才是稳定出品的关键。厨师要是只盯着锅里的翻炒前面配菜没备好、后面出餐盘子没准备好整桌菜照样砸掉。AI 工程就是这样一套后厨管理而不是单纯的炒菜手艺。2. 核心环节拆解与关键原理2.1 数据工程喂给模型的可复现数据数据环节第一件事是数据版本化。我用 DVC 给原始数据、清洗后数据、特征工程产物分别建了版本节点每个节点对应一个 Git commit。这样做的好处很直接模型效果突然反弹时我能精确定位是哪一批数据进入训练导致的而不是靠记忆去猜好像是上周三那份文件。如果你经历过模型损失函数神秘恶化只因为训练集被人悄悄换了个版本就会明白这条流程的重要性。数据质量校验也被提到了代码层面。我写了一个 validation 脚本每次数据入库前检查字段完整性、类型合法性、类别分布和重复率。举个例子短文本分类数据的标签字段偶尔会出现空值或者混入奇怪的换行符不经校验直接喂给模型轻则训练崩溃重则线上推理出错。这个脚本相当于给数据设了一道安检闸口不干净的数据根本进不了下游。特征工程最容易被忽略的坑是训练/推理不一致。我在训练脚本里写了一个清洗函数推理服务里又随手写了一份类似逻辑结果某天服务端的文本预处理多做了一个截断操作线上准确率肉眼可见地掉了好几个点。这种 bug 最难察觉因为两边逻辑看着一样实际行为却不同。后来我把特征代码抽成一个独立模块训练和推理只从同一个入口 import彻底杜绝了双套逻辑分叉的问题。2.2 训练工程从实验到可复现训练环节第一原则是每次实验必须可复现。我用 MLflow 记录环境信息、Git commit、超参数、指标曲线和模型产物。听起来多此一举实际上救过我很多次某次调参后效果不错但根本想不起来用的是哪个学习率有了实验记录我可以像查账一样回溯每一步改动。MLflow 的 Model Registry 还承担了模型版本管理可以不重启服务地切换模型版本。随机种子管理也被上升到工程规范。PyTorch 里设置torch.manual_seed(42)还不够还要管住 NumPy、Python 内置 random 和 DataLoader 的 worker 进程否则每次训练的验证集划分都会漂移实验对比结果根本没有可信度。我会把所有种子相关的设置统一放在一个set_seed()函数里训练脚本开头就调用强迫自己养成习惯。训练资源的估算也是工程基本功。很多人只盯着模型参数量实际上训练显存占用主要来自四个部分模型权重、优化器状态、梯度和激活值/中间缓存。以 1.1 亿参数的 BERT-base 微调为例FP32 权重就占 440MB参数量 × 4 字节Adam 优化器要为每个参数保存一阶矩和二阶矩再加上权重本身约等于 12 字节每参数也就是 1.2GB梯度还要 440MB激活值则在几百 MB 到数 GB 之间波动。所以一口咬定4G 显存能跑 BERT是极其危险的我在 6G 显存的卡上试过batch size 稍大就 OOM。入门阶段最好养成用nvidia-smi观察显存实际占用的习惯。2.3 模型服务把模型封装成稳定接口模型训练完只是一个.pt文件真正面向业务的是它对外提供服务的能力。我选择了 FastAPI 作为服务框架最重要的理由是它自带 Pydantic 数据校验请求体结构会在入口处被校验字段类型不对、字段缺失直接返回 400 错误不会让脏数据一路穿透到模型内部把进程打崩。这一点比早期 Flask 时代需要自己手写参数校验舒服太多。服务接口设计我坚持了两个原则一是响应结构里必须带版本号比如{model_version: 3, result: ...}这样前端和下游可以放心缓存二是模型推理必须放在异步线程池或者独立进程中避免一个慢请求把整个事件循环堵死。实际部署时我还加了加载预热服务启动后先向模型发送少量 sample 数据触发权重加载避免第一个真实请求被冷启动延迟拖垮。在线服务按延迟敏感度可以分成几类我在梳理架构时把各场景列了个表方便大伙按需选择场景推理方式典型框架延迟要求并发特点实时 API在线同步FastAPI TorchServe毫秒到百毫秒级流量波动大需要弹性扩缩容离线批量异步任务Spark 批量脚本分钟到小时级吞吐优先可排队边缘设备本地推理ONNX Runtime离线可得算力受限模型需量化2.4 评估与监控模型也会生病离线评估指标不能直接等同于线上效果。我在项目里同时维护两套指标一套是训练时的准确率、F1、ROC-AUC用来看模型能力有没有提升另一套是线上的业务指标比如请求成功率、平均延迟、预测标签分布、用户反馈率。两者的关系有点像体检报告和实战状态体检指标正常的人也可能因为熬夜状态下滑线上监控的作用就是捕捉这种状态下滑。数据漂移检测是很多人完全不设防的地方。某个类别的输入文本风格一变模型预测分布就跟着偏但模型本身不会主动报错。我在服务里加了预测类别分布的定期统计每 1000 次请求算一次分布如果和历史训练集分布出现显著差异就告警。这个功能只花了一天时间实现却让我免于一次线上准确率莫名其妙下降的长时间排查。模型上线也不是一步到位的动作。我先跑 shadow deployment把线上流量复制一份打到新模型上但结果不返回给用户只记录到日志里。观测几天确认新模型效果不差再切真实流量。如果直接把新模型全量替换万一它有隐藏 bug影响面就是全部用户了。3. 实操过程一个最小可行 AI 项目的完整落地3.1 第一阶段搭建可复现的工程骨架项目目录从一开始就按模块化设计而不是把脚本全扔在根目录。下面这个结构是我实践后觉得比较顺手的模板ai-engineering-from-scratch/ ├── data/ # 数据目录DVC 管理 │ ├── raw/ # 原始数据 │ ├── processed/ # 清洗后数据 │ └── features/ # 特征工程产物 ├── src/ # 核心源码 │ ├── data/ # 数据加载与清洗 │ ├── features/ # 特征工程 │ ├── models/ # 模型定义 │ ├── training/ # 训练脚本 │ └── serving/ # 推理服务 ├── notebooks/ # 探索性分析专用 ├── configs/ # 超参数与部署配置 ├── tests/ # 单元测试 ├── scripts/ # 运维脚本 ├── Dockerfile ├── requirements.txt └── Makefile依赖管理我用了两层requirements.txt记录顶层依赖再用pip freeze生成requirements.lock固定所有传递依赖的精确版本。这么做能避免常见的我这能跑你那报错问题。每次新装包后我会重新生成 lock 文件并提交到 Git方便任何协作者在完全相同的依赖环境下复现实验。工程骨架还有一个细节容易被忽略DataLoader 在多进程模式下如果主进程没有if __name__ __main__保护Windows 和部分容器环境会报错或无限重启。我们在所有可执行脚本的入口处都加了这行保护这属于典型的不踩一次不会长记性的经验。3.2 第二阶段搞定数据管道数据管道我分成了三步原始数据入库、清洗校验、特征生成与切分。原始数据来自公开的评论数据集格式是 CSV字段包含text和label。入库前先跑一个校验脚本检查文件是否损坏、编码是否为 UTF-8、列数是否一致一旦检查不通过直接中止管道不把脏数据带到下游。清洗逻辑看起来简单但坑藏在细节里。HTML 标签、多余空格、全角半角标点、URL 都要处理更麻烦的是部分短文本本身全是大写或乱码。我用一个统一的clean_text()函数集中处理同时记录清洗前后的字符数变化方便后面定位异常。清洗完成后把类别分布打印出来发现某个类别样本过少就触发警报避免模型对少数类别完全失明。数据切分我用的是分层采样而不是随机切分保证训练、验证、测试三个集合里的类别比例大致一致。有一点我特别想强调切分操作必须在特征工程之前完成否则全部数据参与特征变换再将切分后的子集用于训练就引入了特征泄漏离线指标会虚高到让人误以为自己训练出了神级模型。第一次入坑的时候验证集 F1 高达 0.98上线后真实准确率只有 0.72就是被这个环节坑的。3.3 第三阶段训练与验证的工程规范训练脚本我坚持用命令行参数接收所有超参数而不是在代码里写死。简单版本长这样# train.py import argparse import mlflow import torch from src.models import build_model from src.training import train_epoch, validate def main(): parser argparse.ArgumentParser() parser.add_argument(--lr, typefloat, default2e-5) parser.add_argument(--batch_size, typeint, default32) parser.add_argument(--epochs, typeint, default5) parser.add_argument(--seed, typeint, default42) args parser.parse_args() mlflow.set_experiment(comment_classifier) with mlflow.start_run(): mlflow.log_params(vars(args)) model build_model() train_loader, val_loader load_data(args.batch_size) for epoch in range(args.epochs): train_loss train_epoch(model, train_loader, args.lr) val_acc validate(model, val_loader) mlflow.log_metric(train_loss, train_loss) mlflow.log_metric(val_acc, val_acc) mlflow.pytorch.log_model(model, model)这段骨架体现了几个工程原则超参数不埋在代码里因为调参记录和复现都依赖它们每次实验都自动记录指标曲线方便横向对比模型产物以 MLflow 标准格式保存后续可以直接从 Model Registry 加载不需要手工翻找文件。训练过程中我还做了 Early Stopping但严格一点只有在验证指标连续 N 个 epoch 没提升时才停止并保留最佳 checkpoint。最容易犯的错误是在验证指标开始下降时立刻停止其实那可能只是随机波动过早停掉会错过后续更好的结果。我的经验是 patience 至少设 3 轮同时把每次 epoch 的指标曲线都画出来眼见为实再判断。3.4 第四阶段部署与监控模型训练结束后我把 PyTorch 模型导出为 ONNX 格式再用 ONNX Runtime 做推理。这样做的一大好处是摆脱了对 PyTorch 运行时的依赖容器镜像可以瘦身将近一半另外 ONNX Runtime 的图优化让推理延迟比原始 PyTorch 低了不少。导出过程有个关键点必须固定输入维度或用动态维度配置否则带上批量维度导出后线上单条请求进入时就容易维度报错。部署服务我写了一个不到 80 行的 FastAPI 应用核心只有三个接口/healthz健康检查、/predict推理接口、/metrics暴露监控指标。健康检查不只是返回 OK而是真正加载模型跑一次小样本推理确认模型文件没有损坏监控指标则记录了 QPS、P99 延迟、错误率和标签分布Prometheus 可以直接抓取。监控告警我设置了三个阈值P99 延迟超过 300ms、连续 5 分钟错误率高于 1%、预测标签分布和训练分布样本量差异显著。这三个阈值不是说拍脑袋定的而是我从踩坑教训里总结出来的延迟异常通常是资源瓶颈或上游依赖抖动错误率抬头大概率是代码改动或数据格式变化分布偏移则是数据漂移的信号。三者分别对应稳定性、正确性和数据质量缺一个都会让排查陷入盲区。4. 常见问题与排查技巧实录4.1 环境与依赖管理的高频事故这个领域的经典灾难是 CUDA、cuDNN、PyTorch 三者版本对不上。某个版本 PyTorch 要求 CUDA 11.8机器上驱动只支持 CUDA 11.0于是你得到一堆莫名其妙的undefined symbol报错或者 GPU 设备就是加载不出来。我的解决思路是不直接在宿主机上装深度学习框架而是用官方 PyTorch Docker 镜像作为基础镜像内部已经锁定了匹配的 CUDA 版本宿主机只需要提供 NVIDIA 驱动和容器运行时。另一个高频问题是不同项目对同一种包的要求互相冲突。A 项目要pandas1.3B 项目要pandas2.0装一个把另一个弄坏。所以每个项目都应该有独立虚拟环境conda 或 venv 都行关键是不要偷懒图省事把所有项目塞在同一个环境里。我现在的规矩是新项目先在本地创建虚拟环境再安装依赖并生成 lock 文件没有例外。4.2 训练过程的 Bug 与排查思路Loss 不降是最让人慌的场景。不要立刻去调学习率先做这几件事检查数据预处理后的字符串是不是全变成了空值标签是否从 0 开始连续编码模型输出层和损失函数是否匹配。排查的手法也很简单在训练循环前单独打印几个 batch 的输入输出亲眼确认数据和张量形状比看堆栈快得多。过拟合则是另一个常见病。我碰到过训练集准确率 0.99、验证集 0.76 的情况第一反应不是加正则化而是检查验证集的数据分布有没有和训练集严重偏移以及数据切分时是不是发生了泄漏。确认切分没问题后再依次试增加 dropout、降低模型容量、做数据增强。不要一上来就同时改五个超参数这样永远不会知道自己到底靠哪一步救回来。GPU 利用率上不去很多新人不知道如何下手。最常见的原因是数据加载太慢GPU 在空等 CPU 喂数据。排查方式很简单跑训练时另开一个终端执行nvidia-smi如果 GPU 利用率经常掉到 50% 以下而 CPU 占用很高就把DataLoader的num_workers调大、prefetch_factor设成 2 或 4并确保pin_memoryTrue。我在这个项目里把num_workers从默认 0 调到 4 后训练耗时直接缩短了三分之一。4.3 服务化部署与性能瓶颈部署阶段的第一坑是端口冲突。同一个开发机上跑多个服务端口占用会导致模型服务起不来报错信息有时候还很隐晦。我后来给所有服务统一用环境变量配置端口并且启动脚本先检查端口是否被占用避免反复怀疑代码写错了。模型冷启动延迟也是性能痛点。一个几百 MB 的模型文件首次推理可能要花几秒钟加载权重这个延迟对于线上请求完全不可接受。解决思路就两个字预热。服务启动时执行一次空推理让权重真正进入显存或内存之后的请求延迟就能降到正常水平。还有一个小技巧是给 FastAPI 开一个线程池跑推理因为 PyTorch 推理是同步的放在协程里并不会自动变快多个请求同时进来时反而可能互相阻塞。我实测同一个推理函数从协程直接调用改成线程池执行后P99 延迟下降了约 30%。4.4 团队协作与流程规范问题多人协作最容易翻车的是 Notebook。两个同事同时改同一个.ipynbGit 冲突永远处理不干净。我现在的原则是Notebook 只做探索性分析最终训练脚本、特征逻辑、服务代码全部用.py文件维护Notebook 提交前先清理输出。这个习惯让代码评审变得可行毕竟 code review 一个.py的 diff 比 review 一个充满 JSON 的 notebook 容易太多。模型文件放进 Git 也是常见事故。一个 500MB 的.pth文件用 Git LFS 管理可以缓解但如果团队没约定好配额仓库体积依然会爆炸。更干净的方案是 DVC 管理模型和数据Git 只保留小体积的元信息。模型文件的问题我在项目里统一走 MLflow Model Registry某次老板想回退到上周那版效果好的模型我只需要在注册表里选版本号而不是去 Git 历史里翻二进制文件。5. 实操心得与长期习惯5.1 我踩过最深的一次坑特征不一致前面提到过的特征不一致问题我在这里再展开讲讲。当时训练脚本里有个函数会去掉文本中的连续空格推理服务里复制了一份后来又有人手贱给推理端加了一句text[:200]截断因为觉得长文本没用。结果新模型上线后线上效果直线下降排查了一整天最后逐行对比两端预处理逻辑才发现差异。这个坑给我的教训非常深刻训练和推理共用同一份特征代码是 AI 工程的底线之一。现在我把特征工程代码抽成独立 Python 库训练脚本和 FastAPI 服务都通过 pip 安装同一个库并固定版本。任何想改动特征逻辑的人必须先发新版特征库再部署推理服务训练脚本也要同步升级整个流程有 trace 可查。5.2 新手最容易低估的部分数据质量与评估体系大多数新人会把精力全放在模型结构和超参数选择上但说实话从工程视角看决定项目成败的往往是数据质量和评估体系。我在做这个项目时建立了 golden dataset人工标注了 500 条高置信度样本每次模型改动后先跑这一组样本做回归测试。只要有一条原本预测正确的样本被改错就会弹窗提醒让我立刻意识到改动可能引入了行为偏移。评估体系也远比单个准确率复杂。对于分类任务我同时看每个类别的 precision 和 recall而不是只盯着总准确率。之前有个二分类模型整体准确率 0.93但少数类 recall 只有 0.4业务方用起来满肚子意见。上线前就要把分层的指标矩阵分析清楚否则指标好看和业务好用完全是两码事。5.3 给从零开始的你一份行动路线如果你正在筹备自己的 ai-engineering-from-scratch 项目我的建议是别一上来就追求大模型先挑一个小而具体的方向比如垃圾评论识别、商品标题分类、日志异常检测。第一步把环境、依赖、目录结构搭好确保别人 clone 项目后能一键跑通第二步用一批有代表性的真实数据做端到端 baseline哪怕准确率不高也没关系关键是让整个链路完整跑起来第三步再逐步替换模型的每一环每一步都用实验记录和评估指标说话。不要急着读一百篇论文也不要三天两头换框架。AI 工程的本质是让模型稳定地产生价值这句话我花了很久才真正理解。你的第一个项目不需要惊艳需要的是一套能不断迭代的骨架以及你在这个过程中踩过的每一个坑沉淀下来的判断力。如果你也在从零开始走这条路记住别先钻研花哨算法先把你手上的工程骨架打磨到搬上任何机器都能稳定运行后面的一切都会顺很多。