最近在整理自己这大半年从零开始折腾AI工程的实践项目代号就叫ai-engineering-from-scratch。名字很直白就是想记录一个没有深厚算法背景、也不是科班出身的工程师到底是怎么一步步把AI项目真正工程化跑起来的。这篇内容不是课程也不是完整教程更像是我把自己踩过的坑、走过的弯路、最终沉淀下来的方法论摊开给你看。先说结论AI工程的难点从来不在调参或者跑通一个模型而在于把模型放进真实的业务系统里让它稳定、可维护、能迭代。这中间隔着数据管道、训练环境、模型服务、监控反馈、版本管理这一大堆平时在Notebook里根本看不见的问题。如果你正准备从零开始或者已经在路上希望这篇内容能帮你少走一些我走过的弯路。1. 先搞懂AI工程和AI研究不是一回事1.1 我在这个项目里最想解决的问题很多人看到from scratch第一反应是从零写一个神经网络。但我理解的from scratch是把你从会用框架调模型的状态拉到能独立交付一个AI系统的状态。这两个状态之间的距离比想象中大得多。我最初的状态很典型能在Jupyter Notebook里跑通FashionMNIST分类能调一些超参让Accuracy往上走一点点知道卷积池化Dropout这些概念大概是什么意思。可真要让我把这些东西部署到服务器上提供一个HTTP接口让别人调用支撑每天几万次的请求我整个人是懵的。所以这个项目的第一个目标很朴素我要亲手搭出一个端到端的AI系统从原始数据采集开始到模型训练、评估、打包、部署、监控全部走一遍。1.2 从Notebook到生产系统的四个跨越我用一个比较粗的框架总结了一下从Notebook到生产系统至少隔着四道坎维度Notebook原型生产系统数据本地文件直接读入管道化采集、清洗、校验、版本化训练交互式跑一个cell可复用、可复现、可回滚的训练流程模型形态内存里的一个对象打包后的静态产物带版本、带元信息服务方式到model.predict()结束API接口 性能保证 监控告警这四道坎每一项单独拎出来都不算难但合在一起就是一座山。我花了大半个月才把第一版完整走通中间无数次想放弃但走通之后再看以前的东西确实有种降维打击的感觉。1.3 能力和心态的双重转变除了技能心态上也要转个弯。做工程和做实验有一个本质区别实验追求的是能不能成工程追求的是稳不稳定。做实验的时候模型效果不好换参数再跑一次就是了。做工程不一样你上线一个模型它效果不好不只是你一个人的事是业务方、用户、你一起承担。所以你必须在模型效果和系统稳定性之间找一个平衡点。我自己的体会是AI工程师一半是数据科学家一半是全栈开发者外加一小部分运维。不要抗拒这些杂活它们才是工程能力的主体。2. 从零搭起工具链和项目骨架第一周先别急着写模型2.1 环境管理Python版本、依赖、GPU驱动的三角关系我踩的第一个大坑就是环境。有一阵子我发现requirements.txt在某台新机器上怎么都装不上报错信息五花八门。后来才发现问题根源是Python版本不一致——我在本地用的是3.10那台机器是3.8很多新版本的库根本装不上。如果你是从零开始我强烈建议环境管理这件事从第一天就规范化。具体做法统一用conda管理Python环境一个项目一个环境不要混用。锁定Python大版本比如python3.10小版本也尽量锁死。依赖至少区分requirements.txt直接依赖和requirements-lock.txt全量锁定版本。进阶用法是用uv lock或poetry这类工具做依赖解析省心很多。GPU环境更折磨人。CUDA、cuDNN、PyTorch的版本必须匹配否则就是无穷无尽的undefined symbol错误。我后来学乖了就是用官方的基础镜像或者直接从nvidia/cuda镜像往上叠再固定PyTorch的版本。2.2 项目目录结构一个能长远的骨架比想象中重要以前写代码都是随便放一个文件夹里堆着一堆.py和.ipynb。这次我特意设计了一个目录结构后面所有迭代都在这个骨架上进行ai-engineering-from-scratch/ ├── configs/ # 参数配置yaml格式 ├── data/ # 原始数据 处理后数据 ├── src/ # 源码 │ ├── data/ # 数据采集与清洗 │ ├── features/ # 特征工程 │ ├── models/ # 模型定义与训练逻辑 │ └── serving/ # 模型服务化 ├── experiments/ # 实验记录 ├── scripts/ # 脚本如数据下载、训练启动 ├── tests/ # 单元测试 └── README.md这个结构一开始看着挺空但每个模块的边界很清晰。数据、模型、服务的代码不混在一起后面重构的时候特别爽。目录不是摆设它是你项目可维护性的第一道保障。2.3 数据先行先把数据管线跑通再谈模型我以前的习惯是赶紧把模型跑起来看效果数据这块是先凑合用。后来被现实教育了。数据干净与否直接决定模型训练能不能进行、效果能有多好。在ai-engineering-from-scratch项目里我选了一个文本分类任务来练手。数据是一批用户反馈文本需要分类到几个预定义标签里。数据管线的核心逻辑# 伪代码示例展示数据管线的各环节 def build_dataset(raw_path, output_path): # 1. 读取原始数据 df load_raw(raw_path) # 2. 简单清洗去重、去空、长度过滤 df df.drop_duplicates(subsettext) df df[df[text].str.len() 5] # 3. 标签编码 label_map {label: idx for idx, label in enumerate(sorted(df[label].unique()))} df[label_id] df[label].map(label_map) # 4. 按时间排序切分训练/验证/测试集 df df.sort_values(timestamp) train, val, test split_by_time(df) # 5. 保存为tfrecord或parquet方便后续加载 save_as_parquet(train, output_path / train.parquet) ...我特别要强调一点数据切片要用时间切不要用随机切。因为真实业务里模型要预测的是未来的数据如果训练集和测试集是从同一批数据里随机分的等于考试时偷偷看了一眼未来的答案。用时间切分模型才是在真正模拟上线后的情况。3. 第一个端到端项目从原始数据到可调用的服务接口3.1 选一个小而完整的任务靠谱的起点练习项目最忌讳一上来就整大的。什么多模态、大模型微调那是后面的事。我当时选了文本多分类是因为它数据好找、模型不用太深、评估指标直观但又能覆盖一个端到端项目所需要的全部环节。选任务可以按这个标准来判断数据规模适中几千到几万条最好既能体现数据工程的作用又不会让你陷在数据处理里出不来。模型复杂度可控用一个不是特别深的模型就能跑出不错的效果比如入门级的就是几层Transformer或者经典的TextCNN。有清晰的业务场景比如自动对用户反馈打标签这样你做的每一步都能对应到实际的业务价值上而不是纯粹为练习而练习。我当时选的是用户反馈分类输入是一段文本输出是若干个预定义标签中的一个。这个任务看起来简单但已经足够帮我建立完整的工程闭环。3.2 模型训练的关键配置与实验记录训练阶段我最大的改变是开始用配置文件和实验记录。以前调参就是改代码里的变量改完就跑跑完就忘。这次我把所有关键参数抽到configs/train.yaml里model: name: bert-base-uncased # 基于预训练模型做微调 max_length: 128 dropout: 0.1 training: batch_size: 32 learning_rate: 2e-5 epochs: 3 warmup_ratio: 0.1 weight_decay: 0.01 data: train_path: data/processed/train.parquet val_path: data/processed/val.parquet每跑一次实验我都会用时间戳记录一个实验目录里面包含当前用的配置文件、训练日志、模型checkpoint、最终的评估指标。这样任何一次实验结果都能追溯回去知道是哪个参数组合产生了这个结果。这里我要推荐一个工具mlflow。它做实验追踪太合适了能自动记录参数、指标、模型产物还带一个简单的UI。如果你不想引入额外依赖自己用一个日志文件记录也行。但记录本身绝对不能省否则你做的实验都是一次性实验下一次就忘了上一次怎么跑的了。3.3 模型服务化的三种方案对比模型训练完了怎么把它变成服务接口我对比了三种方案方案优点缺点适合场景Flask/FastAPI 自写接口灵活、可控、轻量要自己处理并发、生命周期管理个人项目、小流量TorchServe专为PyTorch设计支持模型版本、监控指标配置略复杂学习成本高中大型项目、需要模型版本管理Triton Inference Server性能强支持多模型、动态batch、GPU调度上手门槛最高高并发、生产级GPU部署我自己当时因为还是起步阶段选了FastAPI。方案很朴素加载模型到内存然后用FastAPI暴露一个/predict接口。from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import pipeline app FastAPI() # 这个classifier在模块加载时初始化避免每次请求都重新加载模型 classifier pipeline( text-classification, model./models/bert-classifier-v1/, device0 if torch.cuda.is_available() else -1 ) class TextRequest(BaseModel): text: str app.post(/predict) def predict(req: TextRequest): result classifier(req.text) return {label: result[0][label], confidence: result[0][score]}这个接口跑通的那一刻我有点激动。模型不再是Notebook里只能自己玩的东西它变成了一个可以被任何系统调用的服务。能用接口调用和能跑通是完全两种体验。3.4 把离线评估和在线监控补齐服务上线前我还做了一件事写了一个离线评估脚本。用之前切分出来的测试集批量调用模型的predict接口或者直接调用模型的批量预测方法算出准确率、F1值、混淆矩阵。这一步是为了确保模型的线上表现和训练时表现是一致的。除了离线评估在线监控也是必须的。我最开始只记录CPU/内存使用率后来发现不够。你更需要监控的是模型的预测结果分布。如果某个标签突然占比猛增或者平均置信度骤降那大概率是输入分布变了模型可能需要重新训练了。我自己加了一个极简监控每处理100条请求记录一次标签分布和平均置信度配合日志一起打出来。这样有问题可以快速发现不至于用户都开始投诉了你还蒙在鼓里。4. 绕不过去的踩坑记录环境、数据和显存的三重考验4.1 依赖地狱如何让环境可复现这是我整个项目中最崩溃的一段。当时我刚把训练好的模型部署到一台新的服务器上按requirements.txt装完依赖后模型推理速度慢了三倍甚至还有随机报错。排查了一整个下午最后发现本地的transformers是4.36服务器上的是4.30模型输出的logits分布有一点点差异导致某些样本的预测结果变了。这让我意识到在我的机器上能跑完全不算数环境必须可复现。后来我做了三件事用conda env export导出完整的环境文件。用pip freeze requirements-lock.txt锁死所有传递依赖的版本。再进一步直接把整个环境打成Docker镜像镜像带标签存到私有仓库里部署时只做镜像拉取。做到第三件事之后环境问题基本绝迹了。Docker在这里的核心价值是把环境的构建过程变成了环境的运行快照。你训练时用的环境和线上跑推理的环境完全一致所有依赖版本、系统库、GPU驱动行为都一模一样。4.2 数据漂移训练时99%准确率上线后崩了这个坑让我對数据漂移产生了生理性敬畏。我的模型在测试集上准确率97%我信心满满地部署上线。结果上线第三天线上的真实数据准确率只有78%而且持续下跌。为什么仔细一查训练数据里有大量以我们开头、格式规整的正式文本但线上用户打出来的反馈短、乱、口语化严重还经常有错别字。模型在训练数据上看到的分布和线上实际遇到的根本不是一个分布。这就是数据漂移Data Drift的典型表现。我当时的应对分成两部分短期收集线上数据人工标注一部分混合到训练集里重新训练让模型尽快见过真实世界的数据。长期把数据采集逻辑修改为持续采集 定期采样人工复核并且增加一个简单的分布监控。比如统计输入文本的平均长度、词汇表覆盖情况一旦发现跟训练集偏差很大就告警。4.3 显存管理一次OOM引发的架构调整训练时显存溢出的经历应该每个做深度学习的人都遇到过吧。我用一张12GB的显卡训练Bert模型batch_size调到32直接OOM程序崩掉。一开始我以为是代码问题后来意识到这是工程问题。显存管理有几个常规手法减小 batch_size配合梯度累积gradient accumulation保证等价效果。使用混合精度训练AMP显存占用能砍掉将近一半。在数据处理阶段把max_length从512降到128对文本分类任务来说足够用了。# 训练配置中混合精度相关设置 training: batch_size: 16 # 显存不够降下来 grad_accum_steps: 2 # 累积两步等价于batch_size32 fp16: true # 混合精度显存减半速度还更快另外还有一个很容易被忽略的点Dataloader的pin_memory和num_workers。这两个参数设置不当不仅影响显存还会严重拖慢训练速度。训练时打开pin_memoryTruenum_workers设为CPU核心数的一半左右是基本操作。4.4 版本管理模型文件、代码、数据三者如何联动代码有Git管模型文件怎么办数据怎么办这三者的版本如果不对应拿到代码也复现不出结果来。我的做法是建立了简单的三方联动规则代码版本定一个Git tag。比如v1.0.0。模型目录命名带版本和实验ID比如bert-classifier-v1-20250120。数据文件用单独的目录每个版本一个子目录并写一个manifest.yaml记录版本信息。# data/processed/manifest.yaml version: 20250120 source: user_feedback_2024Q4 description: 首次清洗后的训练数据已按时间切分 label_map: bug_report: 0 feature_request: 1 complaint: 2 other: 3这样做的核心目的是任何一个时间点你都能找到这套代码 这份数据 这个模型的完整组合回去看当时的实验结果。5. 从能跑到好用AI工程能力的分水岭5.1 性能优化先从瓶颈分析开始当我的服务稳定运行之后我开始关心性能。一开始请求量小不觉得流量起来后发现单个请求平均耗时400ms高峰期还有大量超时。优化之前先做瓶颈分析。我用cProfile和py-spy看了一下CPU时间分布发现大部分时间花在文本预处理重复做的部分比如每次都重新分词。后来把它放进缓存。模型推理无法并发FastAPI的订单化处理。后来改用gunicorn多worker。GPU利用率很低因为单条请求推理时batch只有一个。后来做了简单的动态batching多个请求合并成一个batch再推理。优化项操作效果预处理缓存用lru_cache缓存高频片段耗时降低20%多workergunicorn -w 4 -k uvicorn.workers.UvicornWorker吞吐提升3倍动态batching请求积攒50ms内合并成batch单卡GPU利用率提升到70%有一点值得提醒动态batching是以延迟换吞吐。请求到达后需要等待一点点时间凑batch所以单次请求延迟会略微升高但整体吞吐大幅提高。看你的业务是更关心延迟还是更关心吞吐自己权衡。5.2 CI/CD for ML我所理解的MLOps最小闭环模型上线几次之后我意识到AI项目也需要类似软件工程的CI/CD流程。模型本身就是一个软件组件它需要测试、构建和部署。我搭的最小闭环长这样数据更新触发数据校验脚本。检查数据分布是否异常、数据量是否达标、标签是否完整。训练脚本在干净的环境里跑跑完自动导出模型产物并记录实验指标。离线评估通过阈值比如F1 0.85才允许继续。模型注册把模型产物推送到模型仓库并打上版本号。部署更新线上的服务镜像加载新版本模型。这个流程我大部分用GitHub Actions加Shell脚本拼出来的。你没有看错不一定要上Kubeflow、MLflow那样的大平台哪怕是脚本只要能流程化地把上面这几步跑通就是一个可用的MLOps闭环。核心价值是把手动跑模型、手动部署变成自动化流水线减少人为失误。5.3 成本意识GPU很贵算力要花在刀刃上做AI工程和做学术研究还有一个很大的区别你的每一分钱都要花得值。GPU一个小时就算几块钱如果每次都把训练任务跑一遍又一遍不做复用和断点续训成本会让人肉疼。我学到的两件事训练开始前先在一个小样本上跑一个极短的实验比如1/10的数据、1个epoch确认代码没bug再启动全量训练。不然全量训练跑到第5个epoch才发现数据加载有问题白白浪费时间。使用断点续训。每过几个epoch就保存一个checkpoint万一中间挂了直接从最近的checkpoint恢复而不是从零开始。还有一个小提示在云上训练的时候如果开启了spot实例成本能降一半以上但要做好随时中断的应对。结合断点续训这个方案很适合个人和小团队。5.4 下一步从个人实践到团队协作当我一个人能跑通整个流程之后我逐渐开始思考团队层面的问题。个人的流程和团队的流程有很多不同点个人项目里你可以自己决定一切团队项目里每个环节都需要文档和review。个人项目里代码能跑就行团队项目里代码需要被其他人理解、维护、扩展。个人项目里模型效果不好你自己知道团队项目里需要一个客观的评估机制让所有人对模型当前处于什么状态有一致的认知。这也是为什么MLOps越来越受重视的原因——它不是某个人的事而是让一个团队能协作起来交付机器学习系统的工程方法。如果团队里有人分工协作我的建议是把整个流程拆成清晰的模块数据工程、实验管理、模型服务、监控告警、CI/CD。每个模块都有明确的接口和交付物这样既能并行工作又不会互相干扰。回头看整个ai-engineering-from-scratch项目最大的收获其实不是学会了某个具体工具而是建立了一套完整的思考框架怎么做数据、怎么训练、怎么部署、怎么监控、怎么迭代。这套框架是通用的不会因为框架版本更新而过时。最后分享一个小技巧如果你也准备从零开始不要一上来就瞄准大模型或者复杂的推荐系统就找一个简单的分类任务把整条链路跑通。这条链路本身才是最有价值的东西。链路通了后面换成任何更复杂的模型、更大的数据量都只是在某些节点上增加复杂度而已你的主线不会断。