AI工程这个词这两年几乎被说烂了。打开任何技术社区都能看到“基于大模型的应用”“智能体”之类的内容。但真让一个人从零开始把一个AI项目从环境搭建一路做到上线部署很多人会卡在半路——不是模型训练不起来而是工程化的细节把时间全吃掉了。我做了几年AI工程落地也带过不少新人这个“ai-engineering-from-scratch”的项目本质上就是把我踩过的坑、验证过的路径、沉淀下来的工具链全部串成一条可以照着走的主线。这篇文章适合两类人。一类是刚入门、想系统了解AI工程到底包含什么的同学另一类是有一定基础、但总觉得项目停留在“跑通一个demo”阶段的人。我会从环境搭建、数据链路、模型训练、服务化部署到常见问题排查把整个工程闭环拆开讲清楚。所有方案都是我在实际项目里验证过的参数和命令可以直接抄作业。1. 这个项目到底在做什么AI工程的能力地图1.1 “从零开始”不等于从反向传播开始很多人听到“from scratch”会下意识以为要手写神经网络、自己造轮子。实际恰恰相反AI工程里的“从零开始”指的是把一个AI应用从无到有地落地而不是重复发明已经成熟的东西。我见过太多新手把时间浪费在重复造轮子上自己写数据加载逻辑、自己实现一个简易优化器、自己搭一个推理框架。这些工作不是没有价值但在工业项目里它们已经有非常成熟的解决方案。你真正要做的是把这些成熟方案按正确的方式组合起来形成一个完整的、可维护的、能上线的系统。这个项目的核心目标很简单用一套标准化的流程把AI项目从“能跑”提升到“能上线、能维护、能迭代”。你需要掌握的不只是某个模型怎么调用而是数据怎么管理、训练怎么追踪、模型怎么部署、服务怎么监控。这些能力合在一起才算AI工程。1.2 能力地图一条完整的AI工程链路拆开来看AI工程涉及的能力模块比大多数人想象的要广。我把整个链路分成五个环节环境层、数据层、训练层、服务层、迭代层。环境层负责把运行基础打牢包括Python环境、GPU驱动、容器化配置。数据层负责让模型吃上干净、正确的数据包括采集、清洗、标注、版本管理。训练层看起来最“核心”但实际上只是整个流程的一部分它负责模型结构选择、超参数调整、实验记录。服务层解决的是模型怎么对外提供能力包括接口封装、性能优化、并发控制。迭代层则关注模型上线之后怎么监控、怎么更新、怎么应对数据漂移。很多个人项目只停留在训练层最多加一点简易的服务层。但这恰恰是问题所在——没有环境层的规范管理换一台机器项目就跑不起来没有数据层的版本控制Model A 和 Model B 之间根本没法对比没有迭代层的监控模型在线上默默退化你都不知道。五个环节缺一个整个系统就不算完整。2. 环境与工具链把地基打牢2.1 Python虚拟环境和依赖管理是第一道门槛我必须强调Python虚拟环境不是可选项是必选项。我接手过不少半路项目最常见的灾难就是“在我机器上跑得好好的”——一查所有依赖都装在系统Python里版本横七竖八。我现在的标准做法是每个项目默认使用conda创建独立环境同时用poetry管理依赖。conda的好处是对Python版本本身的管理非常干净还可以直接处理CUDA相关依赖。poetry则把依赖的传递关系梳理得清清楚楚pyproject.toml一个文件搞定声明poetry.lock锁定所有子依赖版本。依赖管理中最大的坑是“能用就行”的心态。今天手动装了个包版本冲突了也不管过了两周项目的依赖状态已经不可复现。我的建议是从第一天就形成纪律所有依赖变更必须通过poetry add完成提交代码时带上 lock 文件。这样同事拉下代码执行一条命令就能把环境完整复现出来。如果你还在用requirements.txt手动维护趁早换掉。pip freeze产生的文件里全是传递依赖的绝对版本号一不小心就会锁错平台相关的包。2.2 GPU环境与容器化方案GPU环境是整个环境层里最容易让人崩溃的部分。驱动版本、CUDA版本、PyTorch自带CUDA、cuDNN四者之间的兼容关系能让人折腾一整天。我第一次配环境时看到驱动报错就重装结果把系统搞崩了。后来的经验是先确认NVIDIA驱动本身没问题然后尽量使用官方预编译的深度学习框架镜像而不是自己一步步装CUDA。比如PyTorch官方Docker镜像已经帮你把CUDA版本、cuDNN、常用库全部匹配好你只需要在这个基础上叠加自己的依赖。容器化是这个环节的关键。我在所有项目里都会写一个Dockerfile把训练环境和推理环境分开。训练环境用pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime这类镜像打底推理环境则用更精简的python:3.11-slim加必要运行时镜像体积能小一半以上。启动容器时记得安装nvidia-container-toolkit并用--gpus all参数把GPU挂进去。我踩过的坑是明明本机有GPU容器里nvidia-smi却看不到设备基本都是工具包没装或配置没生效造成的。这个检查脚本我建议写进项目文档里遇到问题先跑一遍。2.3 实验追踪与模型注册很多项目做到后面模型文件乱成一团model_final_v2_真的最终版.pth、model_0515_0823.pth这种文件名到处都是。更可怕的是问一圈没人知道哪个模型是用的哪份数据、哪个超参数组合训练出来的。这时候你才意识到实验追踪不是锦上添花而是刚需。我现在的方案是使用 MLflow 做实验追踪和模型注册。每次训练跑起来自动记录代码版本git commit hash、数据版本、超参数、训练指标、模型文件路径。跑完之后通过模型注册表把表现最优的模型标记为 Production。用过MLflow之后我最大的体会是它不只是个仪表盘更是一个“记忆系统”。三个月后有人问你“线上那个模型是怎么来的”你能一条SQL查出来它是哪次实验的产物用的什么数据阈值怎么定的。就凭这一点这套工具的引入就值回票价。3. 数据链路模型质量的真正源头3.1 数据采集与清洗实操数据是AI项目的根基这句话被引用太多次反而没人真正当回事。实际上我见过的AI项目失败至少一半不是模型不行而是数据有问题。脏数据、错标数据、不平衡数据会让任何花哨的模型结构都白搭。清洗的第一步是拿掉重复样本。有两个层面完全相同的样本要去重高度相似的样本要考虑是否保留因为重复的相似样本会让训练集和验证集之间产生数据泄漏导致验证指标虚高。我见过一个分类项目验证集AUC高达0.99上线之后表现崩盘就是因为在清洗时没有考虑相似样本的归属问题。第二步是检查标注质量。分类问题可以算标注一致性Kappa系数回归问题要画出标注分布直方图看看有没有明显离群点。我常用的快速方法随机抽100条样本用模型预测和人工标注比对不一致率超过5%就说明标注规范有问题需要回去和标注团队对齐。清洗完成之后一定要记录每个清洗步骤。这个看似小事的习惯在复现和写技术报告时能救你的命。我习惯用文档记录每次数据处理的完整SQL或脚本代码并注明执行时间。后续如果模型出现奇怪行为可以回溯检查数据链路。3.2 特征工程与数据版本管理特征工程听起来是老话题但在AI工程化里依然占据核心位置。我通常把特征分为三类原始特征、派生特征、外部特征。原始特征直接用数据源字段派生特征通过计算产生比如时长、间隔、比例外部特征则要从外部数据源引入比如天气、节假日标记。派生特征要特别注意时间泄漏。做时间序列预测时如果你用了未来时间点的数据构造特征模型在训练集上会表现完美上线后立刻露馅。我自己排查线上问题就遇到过预测模型用到了一个聚合特征生成时不小心包含了当天的真实标签信息导致模型在训练集上AUC接近1上线后掉到0.6。数据版本管理我用 DVCData Version Control。它的工作方式有点类似Git但针对大文件做存储和切换。每次训练前在代码中固定一个数据版本训练跑完数据版本和模型版本就绑定在一起。以后无论模型出什么问题我都能毫厘不差地回到当初训练所使用的数据。关于数据集的切分不能简单用随机切分。在用户维度上分组切分确保同一个人的数据不会被拆到训练集和测试集两边这样才能避免“记忆”导致的指标虚高。这一条在做推荐、风控类项目时尤其重要。4. 模型训练、评估与调优4.1 训练参数怎么选从batch size到学习率模型训练看起来是AI工程最核心的环节但它其实是最不需要“创造力”的部分——我这么说可能会被很多人反驳但事实上绝大多数场景下你需要的不是魔改结构而是稳定、高效地训练一个已有的模型架构。几个关键参数的选择逻辑我可以直接分享。Batch size 其实受限于显卡显存一般我们先看显存能容纳多大的 batch然后在这个基础上调整。以Transformer类模型为例一个大概的估算方法显存占用约等于 batch size × 序列长度 × 隐藏层维度 × 4字节FP32训练时单参数占4字节Adam优化器额外还要占8字节。在复现项目时我一般先用小batch做一次前向传播观察显存占用再按比例放大大约留20%余量。学习率的选择则和优化器强相关。用 AdamW 时3e-5 到 1e-4 是一个比较稳妥的初始范围。如果要节省调参时间线性预热加余弦衰减是我最常用的组合。前5%的训练步数把学习率从0线性升到目标值避免模型在初始阶段因为更新步长过大而震荡后面再平稳衰减。4.2 不收敛的排查顺序模型loss不降、指标异常是整个工程链里最让人头疼的问题但绝大多数都有固定排查路径。我建议严格按下面的顺序来第一看训练代码本身有没有bug。这是新人最容易忽略的却也是最高频的问题。先把模型换成随机初始化跑几个step看loss是否在正常下降。接着可以拿一个非常小的样本集几十条足够试跑看看模型能力是否能够完全覆盖——如果连小样本都学不到接近0的loss代码或者数据链路大概率有问题。第二检查数据。看样本里是不是混进了大量空值或者异常值查看标签分布是不是严重倾斜确认特征标准化是否正确。我曾遇到一个回归任务特征没有做标准化数值范围差异巨大导致任务始终不收敛。做了标准化之后loss立刻就下降了。第三查看学习率和优化器设置。学习率太高会让loss在初期爆炸式增长太低则会让模型“半天不动”。我习惯用学习率扫描LR Finder的方法从1e-6到1e-1指数递增看loss曲线的下降区间然后取一个相对稳妥的中间值。4.3 评估指标怎么选别被准确率骗了评估指标选错项目基本上方向就错了。我见过太多人用准确率Accuracy评判分类模型结果在样本极度不平衡的场景下比如欺诈检测正样本只有1%一个“全预测为负”的模型准确率就能有99%看起来美得不行实际上毫无价值。我通常在分类问题上优先看 Auc 或 F1。Auc 对类别不平衡更鲁棒它看的是排序能力F1 则结合了精确率和召回率更适合关注正样本识别效果的场景。在模型服务上线之前我还会专门计算实际业务最关心的“阈值点”——比如风控项目里更关注高召回率下的精确率就把阈值调整到业务可接受的区间。回归任务的话不能只看均方误差MSE。MSE对异常值极度敏感一个超级大的离群点就能把MSE拉升好几倍掩盖整体趋势。我会同时看平均绝对误差MAE和 R²结合业务含义去判断如果MAE很低但R²不行说明模型整体趋势有偏差如果MAE很高但R²还可以说明模型能抓住总体规律但存在少数极大误差样本。评估环节还要警惕“过拟合”。过拟合的表现是训练loss持续下降而验证指标不涨甚至下跌。解决办法不外乎几条降低模型复杂度、增加正则化Dropout、Weight Decay、做数据增强或者干脆上早停Early Stopping——监控验证集指标连续多少个epoch没有提升就停止训练保存最优模型。5. 部署与服务化模型真正开始干活5.1 从模型文件到 API 服务训练结束不等于项目完成模型文件安安静静躺在磁盘里毫无价值。部署和服务化这一步才是把一个模型变成可被用户使用的产品的关键。我最常用的方案是 FastAPI 加 Uvicorn。选 FastAPI 的原因很直接写起来快自带OpenAPI文档而且基于异步架构在并发场景下表现不错。一个最小推理服务核心代码就是加载模型、定义输入输出结构、跑一次预测然后返回结果。模型加载有个细节不要在每个请求里重新加载模型。模型文件动辄几百MB加载时间可能超过几十秒如果每次请求都加载一次服务基本瘫痪。正确做法是在服务启动时把模型加载到全局变量之后所有请求共用这一个模型实例做推理。如果你要封装的是大模型服务输入输出往往是文本还需要考虑上下文长度限制、超时控制、异常返回等细节。一个标准的响应结构建议把“状态码、业务码、数据体、错误信息”四个字段都带上这样调用方解析起来非常清晰。5.2 性能优化与延迟控制服务上线之后性能问题会立刻暴露。模型推理速度慢 API 响应延迟高用户直接就走了。做优化之前先搞清楚瓶颈在哪儿不要一上来就盲目上GPU或者换更快的服务器。推理耗时一般可以分为两部分单次前向计算时间和传输时间。单次前向算不过来我常用的方案是把模型导出成 ONNX然后使用 ONNX Runtime 推理。ONNX Runtime 对计算图做了大量优化在很多模型上能够获得1.5到3倍的提速而且不需要改动任何业务代码只是换一个推理引擎而已。如果并发量高而单次推理又慢排队就会变长。这里有个实用技巧把推理请求做并发批处理。也就是说同时到达的多个请求合并成一个 batch 送进模型整体耗时只比单条多一点但吞吐量能提升非常多。我实现过一个简单的动态批处理攒积50毫秒或者攒够8条请求再统一推理整体QPS直接翻了一倍。还需要考虑缓存。如果很多请求是重复的比如同样的文本转同样的向量构建一层简单的缓存LRU缓存或者Redis可以极大降低计算压力。实测下来一些文本分类服务加了缓存之后平均延迟从80毫秒降到5毫秒以下。5.3 模型监控与版本更新模型上线只是开始监控才是运维的重头戏。模型在线上跑着效果会随时间变化数据分布一旦悄悄变化模型表现就会下滑这就是数据漂移。我建议监控三件事业务指标比如转化率、通过率、用户满意度、模型输出分布预测分数均值、分类比例、输入数据分布特征均值、方差、空值率。这三件套覆盖了“业务效果、模型状态、数据状态”任何一处出现异常都能第一时间感知。拿到监控告警之后还要有快速回滚和更新的能力。我通常会把模型版本号和接口路由绑定线上流量通过分流权重进行切换。比如新模型先放5%流量观察一段时间指标稳定再逐步放量到百分百。一来避免模型劣化造成大规模影响二来在A/B实验中也顺便做了在线验证。这里有个非常大的体会模型更新迭代难度远大于第一次上线。因为这时候系统已经有很多依赖数据管线在跑、监控面板在刷新如果你最初没有预留模型注册、版本管理这套机制更新的时候就是痛苦的开始。这也是我在前文反复强调工具链的原因。6. 从工程到产品这些方向值得继续深挖6.1 用RAG做知识增强一套完整的工程框架如果你是基于大模型做应用现在最值得深挖的方向肯定是 RAG检索增强生成。RAG 的核心是把外部知识库检索结果和生成模型结合起来减少模型“凭空编造”的概率。RAG的工程化关键在知识库那一侧。不是往向量数据库里塞一堆文档就行要先把文档切片、清洗、构建索引检索时也要做查询改写、权重调参。切多长呢我常用的经验是512到1024个token之间太短缺乏语义太长又容易把无关信息混杂进去。切片要尽量按语义边界来段落结束的地方断而不是硬切。检索质量的评估经常被忽略。我一般会提前标注一批查询-答案对用来测试召回效果。做完向量检索之后还必须加一个重排rerank环节把TopK从50扩大到200再做重排取前5效果明显优于直接取前5。这个是当前RAG工程里性价比较高的优化手段强烈建议尝试。6.2 模型微调与Agent下一层台阶再往下一步就是模型微调和Agent。微调不是提高模型智商的手段它的核心目标其实是“让模型可靠地按你的方式输出”。比如让输出格式保持一致、让模型学会某个业务语言习惯、让模型在你积累的高质量数据上表现稳定。在数据量小的情况下优先尝试LoRA这类高效微调方法。它通过只训练一小部分参数把训练成本降下来而且可以很方便地在同一个底座模型上切换不同的任务适配器。Agent方面我建议从“单一工具调用”开始。给模型定义好工具接口让它学会“判断什么时候需要调用工具、怎么把参数传对、怎么解析工具返回结果”。先跑通一个完整的小场景再扩展成多步骤任务。工程化Agent的核心挑战在于状态管理、错误恢复和工具调用的可靠性这些都需要大量工程手段去兜底而不是单纯依赖模型能力。结尾把工程化的习惯沉淀成肌肉记忆如果你完整走一遍前面说的流程你会发现“AI工程”本质上是把无数个小习惯串成一条顺畅的流水线。环境用容器固定、数据用版本管理、训练用实验追踪、部署用服务化标准、上线用监控兜底。每一个环节单独拿出来都不复杂难的是把每一个环节都做到位并且形成不依赖个人记忆的、可复现的系统。我自己做下来最大的体会是AI工程能力很难靠看文档学会只看不练知识永远是散点。真正有效的路径是找一个真实的小项目哪怕是一个简单的文本分类、一个小型图像识别服务强迫自己从环境搭建一路推到上线部署中间经历几次版本冲突、几次显存溢出、几次模型指标诡异波动这些踩坑的过程本身就是最宝贵的经验。这个项目后续还可以在几个方向继续深挖把训练流程做成自动化的Pipeline、把服务架构升级成微服务、把模型监控做细粒度告警。每一个方向都够单独写成一篇实战笔记。需要的不是一次做完而是先完整跑通再逐步打磨。祝你在踩坑的路上少走弯路早点把这条链路走成自己的肌肉记忆。