如果你最近刷到“ai-engineering-from-scratch”这样的标题或者在思考怎么从零开始做真正的AI工程而不是只会在 Notebook 里跑通一个模型那这篇文章就是给你准备的。我结合自己多年做算法工程和平台建设的经验把从零搭建AI工程这件事的完整思路、技术选型、实操步骤和踩坑记录整理成一篇可以照着做的东西。这里的“从零”不是指从线性代数开始学而是指从零开始构建一套能落地、能上线、能维护的AI系统——包括环境、数据、训练、评估、部署和监控。内容会按一条完整链路展开适合刚入行的算法工程师、想转型的后端开发以及在大模型时代想建立全局视野的技术人。1. AI工程与算法工程的边界先搞清楚你在做什么1.1 什么是AI工程解决什么问题很多人以为AI工程就是“训练模型”其实那只是其中一小块。AI工程这个词往大了说是把机器学习、深度学习算法工程化、产品化、系统化的整套方法论。它要解决的核心问题是模型怎么从一段实验代码变成稳定运行的服务并且在数据变化、流量冲击、硬件故障面前依然可靠。我见过不少团队算法同学在离线测试时准确率很高一上线就崩或者过两周效果就衰减得没法看。问题往往不在算法本身而在工程链路。AI工程就是把“离线能用”变成“线上好用”的那一环。它涵盖数据管道、特征存储、模型训练、模型评估、模型部署、在线推理、监控告警、回滚机制、版本管理、CI/CD等。你可以在网上搜索几个叫“ai-engineering”的仓库看下来基本都是在讲这些模块的组合。如果你要独立从零构建一个AI系统那你就不能只盯着model.fit()。你需要有整体架构感数据从哪来、怎么清洗、怎么储存、怎么喂给训练、模型怎么打包、服务怎么调度、怎么应对模型漂移。这套东西每个环节都有坑而坑往往不在你熟悉的那个环节。1.2 为什么从零开始反而更难也更重要从零开始做AI工程比在已有框架里加需求难得多。因为框架已经替你想好了许多边界比如用什么Runner、怎么记录指标、怎么存储模型产物。从零开始你得自己做决策而且每个决策都会影响后续的维护成本。但正因为难它更重要。只有从零搭建一遍你才会真正理解每个组件存在的理由。举个例子很多人喜欢用现成的MLflow管理训练但如果他自己从零写过一次实验记录脚本他就能明白MLflow里的experiment_id、run_id、artifact存储到底解决什么问题遇到问题也能快速定位。我从零做过好多次玩具级AI工程每次做完都对工具的本质理解深一层。从零开始还有一个好处就是可以按自己的业务场景裁剪方案。大厂的AI平台很完善但那是用很多人力堆出来的注定是重型的。你在小团队或独立项目里从零搭一套轻量但完整的工程链路反而更灵活迭代更快。1.3 一个合格的AI工程知识栈长什么样我画个不太严谨但实用的图谱。基础层Python、Linux、Docker、Git。数据处理层SQL、Pandas、Spark或者更大规模时用上Ray。模型层PyTorch或TensorFlow至少要一个精通。调度层Airflow、Prefect、Argo Workflows这类。实验管理MLflow、WB、或者自己写的一套。服务化FastAPI、Flask、TensorFlow Serving、TorchServe。监控Prometheus、Grafana、Evidently、WhyLabs。最后还要懂一点DevOps的思维自动化测试、CI/CD、容器编排K8s至少懂原理。这个知识栈看起来很多但不需要一开始就全部精通。你只需要按“能跑通最小闭环”来学装环境、写数据脚本、训一个小模型、打包成服务、部署到本地、加监控。先跑通再扩展。很多初学者天天学新框架从不串联导致知识像散沙。从零构建一个完整小项目比看十篇教程有用得多。2. 从零构建你的AI工程底座环境、数据与项目骨架2.1 开发环境搭建不是装个Python就完事如果你用Anaconda装好Python就开始了那你很快就会撞墙。AI工程需要可重现环境尤其是当你要部署到服务器或协作时。我的建议是优先用Docker。把Python版本、CUDA版本、系统依赖全部锁进镜像。你可能会问本地也要用Docker吗是的即使你本机就是Linux也建议用Docker因为可以把开发环境和部署环境保持一致。一个常见做法是项目根目录维护一个Dockerfile基于python:3.10-slim安装必要系统库然后复制requirements.txt先安装依赖再复制代码。这样可以利用Docker的层缓存改代码后构建很快。如果你有GPU需求基础镜像可以用nvidia/cuda:12.1.0-runtime-ubuntu22.04但注意大小和层数。还有一点千万别在镜像里装一个完整版的Anaconda体积巨大而且很多包用不上。用requirements.txtpip就够了。如果团队协作还要用poetry或uv这类工具锁定精确版本。以前我用requirements.txt固定版本号但不同人的机器Python版本不一样还是会出现“我本地能跑你本地不能跑”的问题。后来把项目和依赖一起容器化这种情况基本消失。具体步骤先写好Dockerfile和docker-compose.yml把训练脚本挂载进容器用docker-compose up一次性拉起训练环境。当然这只适合单机分布式训练再考虑别的方案。2.2 数据管线的设计工程化第一步是让数据可控数据是AI系统的地基但很多项目直到失败才意识到数据问题。从零设计数据管线第一个原则是原始数据不可变。所有原始文件只读不对原始文件做原地修改。任何清洗逻辑都生成新版本数据比如raw/2024-01-01/、processed/v3/。这样做的好处是你可以随时溯源知道模型用的到底是哪份数据。第二个原则是每条数据要有明确的版本和Schema。在工程中用Parquet或JSON Lines格式存储比CSV更合适因为Parquet有类型信息且能按列压缩。我见过太多CSV导致字段解析错误的问题明明那列是整数读出来变字符串训练时才发现。用Pandas读CSV时dtype行为在不同版本还有细微差异。为避免这类问题写成显式的数据校验函数加载时检查字段类型和值域。第三个原则是数据加工过程要可复现。比如你用train_test_split时固定random_state但如果你把数据顺序打乱后又做特征映射可能会影响结果。更好的做法是把样本的唯一ID作为种子做确定性划分。数据管线还可以用dvcData Version Control管理或者简单粗暴地在目录命名中加入版本号。在小项目中我会用dvc跟踪数据文件的变化这样每次训练都有对应的数据版本回滚时恢复也方便。2.3 项目结构组织约定优于配置从零搭建AI工程项目结构决定后期维护效率。我推荐一个简单但分层的目录结构project/ ├── configs/ # yaml配置 ├── data/ │ ├── raw/ │ ├── processed/ │ └── features/ ├── src/ │ ├── data/ # 数据加载、清洗 │ ├── features/ # 特征工程 │ ├── models/ # 模型定义 │ ├── train.py # 训练入口 │ └── evaluate.py # 评估入口 ├── models/ # 模型产物 ├── notebooks/ # 探索分析 ├── tests/ ├── Dockerfile ├── requirements.txt └── config.yaml不要把所有代码写在一个train.py里。至少拆成“数据加载”“模型定义”“训练循环”“评估”四个模块。为什么因为模型训练周期长你肯定需要单独调试某一部分。如果耦合在一起改一个数据加载逻辑就要跑完整训练太浪费时间。配置管理也建议用YAML。写死在代码里的超参数是最难维护的慢慢就忘了当初用了哪个值。YAML配置可以算作一种“代码即文档”把model_name、learning_rate、batch_size、data_version都放在里面。用dataclass加载配置还能有类型检查比直接读dict舒服得多。3. 核心环节实操从训练到评估的完整链路3.1 模型选型与基线建立很多朋友一开始就上复杂模型结果出了问题根本分不清是数据问题还是模型问题。我的原则是先建一个极简基线。比如做分类任务先用逻辑回归或浅层MLP不做特征交叉不加预训练。基线的作用不是拿高分而是确认数据管线、训练代码、评估流程是通的。我见过一上来就训练BERT跑一天后发现数据标签错了一半白费力气。基线模型跑通后再逐步增强先加关键特征再换更强模型每走一步都记录效果变化。这个过程能帮你判断收益来自哪里。模型选型还要考虑推理成本和上线约束。如果你的服务要跑在CPU上那大Transformer就不现实可以考虑蒸馏或量化。所以选型不是光看榜单而是看你的部署环境。在训练代码结构上我用过PyTorch Lightning和原生PyTorch。如果你是从零学我建议先弄懂原生PyTorch的训练循环DataLoader、optimizer.zero_grad()、loss.backward()、optimizer.step()。这些基本功不能丢。Lightning这类框架省代码但也藏了很多细节。等你理解训练本质后再用高级框架不迟。3.2 训练脚本的工程化写法训练脚本不是把Notebook里的单元格照搬成.py就行。工程化训练脚本有几个关键点支持命令行参数和配置覆盖、定时保存checkpoint、日志输出结构化、能断点续训。举个例子你训练一个epoch要6小时中途断电了如果没有断点保存那6小时全白费。PyTorch里可以这样写保存逻辑每N个step保存一次保存内容包括model.state_dict()、optimizer.state_dict()、scheduler.state_dict()、epoch和step。重启时只要检测到checkpoint就加载这些状态继续训练。日志也不能只打印loss。至少要把loss、学习率、当前epoch、当前step、数据吞吐量samples/s都记录下来。我一般用structlog或标准的logging模块把日志输出为JSON方便后续采集到ELK里。同时把关键指标传给MLflow或自己写的CSV加SQLite。这里有一个容易被忽略的点训练脚本需要设置随机种子包括Python、NumPy、PyTorch以及CUDA的随机种子才能保证可复现。你在启动训练前最好做一个“单batch过拟合测试”用一个小数据集比如32个样本反复训练观察loss能不能降到接近0。如果这个测试不通过说明代码逻辑有bug比如梯度没更新、反向传播写错、数据标签不匹配。我每次写新模型都会先做这个测试它能省掉你排查训练不收敛的时间。3.3 评估体系与可复现性离线评估是AI工程的守门员。但很多人评估方式太随意只在测试集上算一个accuracy就完了。我建议至少建立一个完整的评估目录按业务维度拆分。比如做用户流失预测不光看整体AUC还要看高价值用户子集的召回率、新用户子集的表现。否则你会被平均指标骗了上线后发现核心人群效果很差。第二个要点是评估代码要和训练代码分离。训练时产出的临时预测结果不能直接用于最终评估。评估要重新加载模型和测试数据走一遍统一的推理接口保证你评的就是线上会用的那个模型。这里的“统一推理接口”很关键你要把模型封装成一个predict()函数输入原始特征输出业务结果。只暴露这个函数内部怎么做预处理、怎么做推理都封装起来。这样评估和线上服务用同一个函数能避免“训练时预处理和服务时预处理不一致”的问题。可复现性方面除了随机种子和配置记录还要记录每个模型产物的来源代码commit hash、数据版本、训练参数。MLflow能自动记录下来一部分但如果你不想引入额外组件也可以用脚本生成一个metadata.json放在模型目录里。包含这些字段trained_by、date、commit_sha、data_version、config_path、metrics。这样你拿到一个模型文件就能反推出它是怎么来的而不是一个黑箱。最后要用同一个评估脚本和测试集来比较不同模型。我们经常需要对比两个候选模型可以通过计算差异显著性来确定A是否真的优于B而不是只看单次运行的指标起伏。虽然统计显著性在深度学习中实现有点门槛但至少跑三次取均值能降低随机性带来的误判。4. 上线部署与监控工程化的真正考验4.1 模型服务的常用架构模型训练好只是开始真正让你头疼的是如何把它变成可用服务。我推荐的最小组网方案是FastAPI Gunicorn Nginx。模型在启动时加载一次放到全局变量推理时调用。注意推理进程要设置preloadTrue避免每个worker重复加载模型导致启动极慢。我自己用Gunicorn启动FastAPI时踩过很多坑比如默认Worker是同步的推理时长几秒时并发一高队列全堵死。所以一般要用--worker-class uvicorn.workers.UvicornWorker并且把worker数设为CPU核数的两倍左右。如果模型用到GPU还要考虑GPU显存的限制通常一个worker对应一个GPU进程或者用GPU上的MPS/共享机制。对于高吞吐场景还得加消息队列或批处理机制。你可以把请求先打进Kafka或Redis队列后台批量推理后再返回。这样避免每个请求都做昂贵的模型推理能显著提升吞吐。批处理还能通过合适的数据布局优化GPU利用率。不过这会增加复杂度从零开始的话先把同步接口做稳定再考虑异步。另一种常见架构是把推理服务与训练平台分离。训练项目产出的模型通过模型仓库如MLflow Model Registry或简单文件系统交付给推理服务。推理服务只加载指定版本的模型不关心训练细节。在我的实践中哪怕只是小项目我也建议做这个逻辑隔离这样模型迭代时线上服务可以独立重启和灰度上线不影响训练流程。灰度上线时可以用金丝雀发布先切一部分流量到新模型观察指标稳定后再全量切换。别小看这个流程它能防止新模型上线导致效果崩盘。4.2 漂移检测与自动回滚机制模型上线后最怕的是数据漂移和概念漂移。数据漂移指线上输入特征分布变了比如用户年龄从20-30变成40-50概念漂移指特征和标签的关系变了比如疫情期间线上购物行为规律就完全变了。如果监控不到漂移模型会悄悄失效。从零开始可以把监控分为三层。第一层是系统监控CPU、内存、GPU利用率、请求延迟、错误率。这是基础保障用Prometheus Grafana即可。第二层是输入监控对每个请求的特征做统计比如均值、方差、缺失率和训练时保存的基准分布对比计算PSI或KS距离。当指标超过阈值时告警。第三层是输出监控预测结果的分布、置信度变化。比如一个二分类器之前预测正例的概率均值是0.2现在变成0.5说明模型可能漂移了。实现时训练结束后保存一份特征分布基准文件可以是每维的均值/方差/分位数。推理服务在返回结果后异步把特征和预测结果记录下来。定时任务或流式计算去计算当前窗口的分布和基准分布的距离。如果漂移严重可以自动触发模型回滚从模型仓库中拉取上一个稳定版本的模型替换当前服务。但这要谨慎必须有完善的可观测性否则误回滚也可能造成问题。还有一个工程技巧为每次推理请求记录一个唯一的request_id日志和特征都带上它。当用户反馈结果异常时你可以根据request_id把当时的输入特征、模型版本、预测结果全部拉出来复现问题。没有这个ID排查线上问题会异常痛苦只能靠猜。5. 常见问题与排查技巧实录5.1 环境依赖地狱从零搭建AI工程的人几乎都遇到过“环境跑不起来”的问题。特别是CUDA、cuDNN、PyTorch版本不匹配整个训练就是起不来。我排查的顺序是先看torch.version.cuda和torch.cuda.is_available()如果返回False多半是Driver或PyTorch与CUDA版本不匹配。注意Driver版本要和CUDA runtime兼容但PyTorch是自带CUDA runtime的所以重点看NVIDIA驱动是否大于等于所需版本。用nvidia-smi查看驱动支持的CUDA版本别把这个和nvcc版本搞混。我建议锁Docker镜像时直接使用官方提供的基础镜像例如pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime里面已经配好了基本不会再出现版本不匹配的问题。但不建议自行在Ubuntu镜像里装CUDA很容易踩坑。另一个常见坑是Python版本。PyTorch对Python版本有要求比如某些版本只支持3.8-3.11。你可以在项目根目录放一个.python-version文件配合pyenv使用团队里每个人都用同一个Python版本。不要凭感觉装最新版有时候新版本Python最新的包还没跟上。依赖冲突也很常见。解决方案是使用虚拟环境或容器并在requirements.txt中做精确锁定用pip freeze requirements.lock。但更推荐用poetry或uv这类解析器它会把包依赖解析成锁文件。在写Docker镜像时先安装所有依赖再拷贝代码能利用层缓存。如果修改了依赖构建速度会慢一些但能避免每次改代码都要重新解析依赖。5.2 显存溢出的排查思路显存溢出OOM是训练中高频出现的错误。最简单的做法是减小batch_size但这只是权宜之计。根本原因可能是模型太大、batch太大、激活值未释放、梯度累积不当。可以先计算一下理论显存需求参数数量×每个参数字节数再加上优化器状态Adam需要2倍额外、激活值。如果不想细算就开启梯度检查点gradient checkpointing来节省激活显存。PyTorch中设置model.gradient_checkpointing_enable()即可但会慢一些。排查时把batch_size设为1看显存占用如果依然很大说明模型或激活值有问题。用torch.cuda.max_memory_allocated()记录峰值显存也能用torch.profiler查看内存分配热点。还有一个容易忽略的问题DataLoader的num_workers过多会占用CPU内存但GPU显存也可能因为数据拷贝到GPU时缓存未释放而异常增加。注意在每轮迭代后清理中间变量或者使用torch.cuda.empty_cache()但别在训练循环里频繁调用它本身也有开销。5.3 线上效果与测试效果不一致这是AI工程最扎心的问题。离线指标挺好的一到线上就崩。原因通常有四类。第一类是数据不一致线上请求的特征预处理和训练时的预处理不一样。比如同一个数值特征训练时做了标准化线上推理时忘了减去同一组均值方差。解决方法是把预处理逻辑封装成可导入的模块训练和推理都用同一个函数甚至可以在推理服务启动时加载训练好的scaler。第二类是特征穿越。离线数据里用了未来信息比如用t1的用户行为预测t的标签看起来效果很好但线上没有未来信息。这是逻辑错误无法靠工程解决只能在数据设计时避免。第三类是样本分布不一致。离线测试集是随机划分的而线上真实流量有时间序列特性。如果训练数据来自过去三个月测试集随机包含过去的数据那新模型的评估是有偏的。最好按时间划分验证集和测试集模拟上线后的时间点。第四类是推理延迟导致的用户体验问题。线上如果响应太慢用户早走了后续行为也变了导致算法表现差。这要通过系统监控定位延迟瓶颈。除了这些模型版本管理混乱也会导致线上运行的根本不是离线评估的那个模型。所以一定要记录线上服务的模型版本号每次发布时都核对一下。5.4 自动化测试的缺失很多AI项目只跑通就算完完全不写测试导致数据一变就出各种怪问题。作为工程必须给关键模块写测试。至少要为数据清洗写单元测试给定构造的输入断言输出结构和值域。为特征处理写测试相同输入多次调用结果完全一致。为模型推理写测试加载一个小模型输入一批模拟特征输出维度符合预期且正样本概率在[0,1]区间。为API接口写测试用FastAPI的TestClient发一个请求断言状态码和响应结构。这些测试不需要覆盖所有情况只要把最容易出错的环节保护起来。比如数据版本升级后旧的预处理函数跑在新数据上会报字段缺失有测试就能提前发现。训练代码虽然不容易做完整的单元测试但可以对“单batch前向传播”和“梯度更新一步”做测试确保没有NaN或形状错误。CI中挂上这些测试每次提交代码都自动跑一遍能拦截很多低级错误。6. 工具链选型与个人实践建议6.1 实验管理从内置到MLflow如果你的实验量少可以先把自己写的CSV日志和模型目录当成实验管理。当项目复杂后建议直接上MLflow。MLflow不仅有Tracking还有Model Registry可以管理模型从实验到生产的整个生命周期。我自己用MLflow追踪实验时会记录每个run的参数、指标、模型文件路径、以及数据集版本。这样对比不同run很方便还能直接找出某个指标最好的几个run。但MLflow也有一点学习成本比如它的artifacts如果存在本地文件系统在多机训练时会有同步问题。小项目用本地./mlruns即可大项目建议配置S3或NFS。6.2 一步一步从零到一一个最小可行闭环的项目清单我来给你一个可以直接照着做的清单。第一步建好Docker环境和项目结构。第二步写一个数据下载和预处理的脚本输出Parquet记录数据版本。第三步写一个简单的模型和训练脚本能在CPU上训练一个极小模型并用MLflow记录。第四步写评估脚本输出分类报告和混淆矩阵。第五步写一个FastAPI推理服务加载模型暴露/predict接口并封装统一的预处理逻辑。第六步写一个Dockerfile启动推理服务本地用docker-compose跑起来联调测试。第七步加入Prometheus监控记录请求量、延迟、模型预测分布。第八步写一个漂移检测脚本定期比较线上特征分布和基准分布。这个清单每一步都不复杂但连起来就是一个完整的AI工程项目。6.3 个人经验别为了“工程化”而过度设计还有一个必须提醒的点从零做AI工程容易陷入过度设计的陷阱。有些人一开始就上K8s、上Flink、上特征平台结果两周连数据都没搞定。我见过一个团队为了做一个简单的推荐排序愣是上了五个中间件最后维护成本比算法迭代成本还高。工程化的目标是稳定和可控不是堆技术栈。你只需要在确实遇到瓶颈时再扩展。比如单机跑得动就别急着上分布式用文件系统存模型够用就别搭Model Registry服务。先跑通一个最小闭环然后再逐步完善。我个人后期的做法是同一个项目先用最原始的组件Python脚本文件存储Flask实现一条链路把每一步的耗时和问题记录下来。然后根据痛点渐进式引入工具。这样才能有底气说“这个组件是我真需要的”而不是“大家都在用所以我也用”。总的来说AI工程从零开始的路是漫长但值得的。它会强迫你把每一个黑盒打开理解里面的机制。如果你正在走这条路希望这份从链路拆解到工具选型再到踩坑实录的内容能让你少走几个弯路。最后再分享一个小技巧每次做完一个阶段都把这个阶段的关键配置和输出目录写进一个README.md包括启动命令、注意事项、版本信息。过两周你回来就会感谢当初的自己。