★ FEATURED ARTICLE “ai-engineering-from-scratch”——这串英文最早是我给自己那份学习笔记起的仓库名意思很直白从零开始把AI工程做扎实。后来慢慢把它整理成了一个完整的学习路线项目包含从环境搭建、数据处理、模型训练到上线监控的全部内容。这篇文章是这套项目的一个浓缩总结把我知道的、踩过的、验证过的东西都摊开讲希望能给正在找路的人省下几个月的试错时间。这套内容适合两类人一类是刚接触AI、想从工程角度系统入门的新手另一类是写了好几年业务代码、想转向AI方向的后端工程师。如果你已经能熟练训练模型、熟悉分布式训练和容器编排那这篇文章的早期内容会比较基础可以直接跳到后面的工程化部分。我尽量做到说人话把每个选择背后的理由讲清楚不堆概念。1. 先想清楚AI工程到底在解决什么问题1.1 为什么很多人学AI总是半途而废我见过太多人一上来就啃深度学习教材或者直接跟着教程写Transformer结果两周后全都放弃了。问题不是他们不聪明而是切入点错了。AI工程和AI研究是两回事研究关心的是模型精度能不能再涨一个点工程关心的是这个模型能不能稳定上线、能不能低成本维护。大部分人入门时误把自己当成研究者天天盯着损失函数曲线却连数据管道都搭不利索自然越学越虚。更迷惑人的是现在AI框架封装得越来越傻瓜化几行代码就能加载一个大模型让人误以为AI工程门槛很低。可一旦进入真实项目你会发现难点全在工程侧训练数据从哪来、怎么保证线上和线下特征一致、模型怎么部署、线上效果怎么监控、模型要更新了怎么灰度替换。这些才是AI工程每天要面对的问题。从零开始这四个字不是指从数学公式开始推导而是指把整条工程链路的每个环节都亲手走一遍。只有亲手处理过脏数据、亲手部署过一个慢得要死的模型、亲手排查过线上预测和本地预测不一致的诡异bug你才算真正进了AI工程的门。1.2 AI工程全链路包括哪些环节用一句话概括AI工程是把业务问题翻译成数据问题再翻译成模型问题最后用工程手段把模型变成稳定服务的完整过程。我习惯把它拆成六个环节业务理解与问题定义搞清楚到底要解决什么是分类、回归、排序还是生成判断这到底该用AI解决还是简单规则就能搞定。数据获取与处理采集、清洗、标注、切分做出一个可靠的数据集。这一步经常占掉整个项目七成时间。特征工程与实验构建特征、训练模型、离线评估反复迭代直到指标达到预期。服务化与部署把模型封装成接口包进容器规划资源让它能在生产环境稳定运行。监控与迭代跟踪模型在真实环境的表现发现效果衰减后触发重新训练或更新。平台化与自动化把以上流程沉淀成可复用工具和流水线让团队协作更顺畅。这个链路里很多人在第一环和第二环之间就卡住了。比如业务方说“帮我们做个智能推荐”听起来很简单但你要追问清楚基于什么数据推荐新用户没有行为数据怎么办推荐的目标是点击率还是转化率这些问不清楚后面做的全是无用功。我在整理 ai-engineering-from-scratch 这个项目的时候就是把上面六个环节拆成一个个可执行的任务清单每个任务都配有练习数据和小项目。这样学习的路径就很明确不是看完一本书就完事而是每个环节都有产出物。2. 从零开始的学习路线图六个阶段打怪升级2.1 阶段一工程底座先打牢在碰任何AI框架之前先把Python、Linux、Git、Docker这四件事练稳。很多人不理解说学AI为什么要学Docker道理很简单AI项目最讨厌的就是环境不一致。你在自己电脑上跑得好好的代码推到公司的GPU服务器上就报错不是你代码的问题是环境的问题。Docker就是把环境连同代码一起打包让模型在哪个机器上跑行为都一致。Python方面不用追求把语法全背下来重点掌握几个实用板块列表推导式、生成器、装饰器的基础用法类的基本写法类型注解怎么用虚拟环境怎么管理。然后在Pandas和NumPy上花时间把数据加载、清洗、聚合这些操作练到条件反射。Linux方面至少做到不害怕命令行。能熟练用vim改文件、用grep和awk处理文本、用systemd管理服务、看懂基本的内存和磁盘命令。这些技能后面做模型训练、排查线上问题时天天用得上。Git方面别只停留在commit和push。要学会分支管理、code review流程、rebase和merge的区别以及用Git LFS管理大文件。模型文件动辄几百MB直接用Git管理仓库会迅速膨胀到无法使用。Docker方面我建议在阶段一就把Dockerfile和docker-compose写熟练。不用深究底层原理先记住几个核心概念镜像、容器、挂载卷、端口映射。能把自己的Python脚本容器化跑起来就算过关。这个阶段大概需要三到四周每天保证两小时投入。2.2 阶段二数据能力才是AI工程的护城河模型可以换数据才是持续出活的根本。这一阶段的核心目标是能独立完成一个数据项目的全流程从数据库取数、清洗异常值、特征衍生到最后导出训练集和验证集。SQL必须过关。AI工程师不是只会在Notebook里写Pandas真实的训练数据往往需要从数仓里捞。要熟练写出join、窗口函数、group by聚合这些常用操作理解分区表的概念知道怎么在几亿行数据上高效取数而不是把全表拖到本地。Pandas要练到“手比脑子快”。看到一张乱七八糟的表你马上能想到用哪些方法处理缺失值用fillna还是dropna、字符串列怎么规范化、时间列怎么转成timestamp、重复行怎么去重。训练集和测试集的切分也是这个阶段的重点考点不能随便采随机抽样要根据业务时间顺序切分否则容易在不知不觉中造成数据泄漏。特征工程在这个阶段要开始上手。我推荐用Titanic或House Prices这类经典数据集来练。重点不是跑一个多高级的模型而是把特征处理的思路摸透数值特征怎么做归一化和分箱、类别特征怎么做编码、缺失特征怎么补以及为什么不能用全量数据的统计量去填充训练集和测试集。后一个问题特别关键很多新手在这里栽跟头你先计算了整个数据集的均值再填充训练集和测试集看起来没问题但测试集的信息已经悄悄混进了模型。2.3 阶段三模型基本功的训练到了这个阶段很多人的毛病是直接调库。Scikit-learn确实好用但如果你不清楚fit和predict背后到底发生了什么后面出了问题会非常难排查。我建议在调库之前先手动实现几个基础算法线性回归、逻辑回归、K近邻、决策树。不用实现得多高效代码跑得慢也无所谓关键是理解损失函数、梯度下降、过拟合这些基本概念是怎么相互作用的。深度学习方面先别急着用封装好的高层API。用PyTorch把训练循环手写出来定义模型结构、写损失函数、构造dataloader、手动更新参数、记录每个epoch的loss和指标。这个过程虽然繁琐但会让你彻底明白模型训练的数据流。明白之后再看训练加速、混合精度这些进阶话题就自然多了。这个阶段一定要动手做两三个完整的模型实验每个都走通数据加载、预处理、训练、评估、保存这几个步骤。不要只在MNIST上反复跑那个数据集太干净了和真实项目差距太大。我会在文章后面给一个推荐的端到端项目那个项目比单纯跑MNIST有价值得多。2.4 阶段四实验管理和评估体系模型训练出来不算完AI工程的核心之一是可复现。你在一个项目里做过几十次实验如果没有记录清楚两周后你自己也说不清哪个模型更好、哪个超参数是谁跑出来的。所以从阶段四开始我强烈建议接入实验追踪工具而不是用txt文件记日志。评估也不是跑完测试集输出一个accuracy就结束了。你得想清楚业务目标是什么是降低误报率还是提高召回率是追求整体收益还是单品转化业务指标和模型指标经常不是同一个东西工程上要先把它们映射清楚。比如推荐系统里模型离线评估看AUC但线上真正关心的是人均点击量和转化率这两个指标之间有相关性但不是一回事。我自己的习惯是给每个实验建一张卡片记录模型版本、训练数据版本、超参数、关键指标、备注。这张卡片一开始用手工记录后来接入了MLflow效率提升非常明显。这一阶段还应该学会看学习曲线、过拟合迹象、混淆矩阵并理解怎么调整模型容量来缓解偏差和方差的问题。2.5 阶段五部署与上线模型部署是很多人觉得神秘的部分拆开看也不复杂。核心就是把训练好的模型文件和预处理逻辑一起打包成服务对外提供HTTP接口或gRPC接口。从最简单的开始用FastAPI把模型封装成一个POST接口传进去特征数据返回预测结果。然后是模型文件的版本管理、接口的并发与超时控制、用Docker打包整个服务并发布到服务器。等这一套跑顺了再去研究Kubernetes、灰度发布、多模型路由这些更复杂的工程方案。一开始就碰K8s容易劝退先用一台服务器把服务跑稳比什么都重要。我强烈建议在这个阶段做一次压测。用简单工具模拟几百个并发请求打到模型服务上看看接口的吞吐量和延迟是多少CPU和内存会不会被打满。很多人以为模型部署就是把模型文件load进内存然后调predict实际上在大流量下暴露出的是前置预处理逻辑太慢、模型文件逐个加载导致冷启动时间过长、以及没有batch推理导致GPU利用率太低这些工程问题。2.6 阶段六大模型应用工程现在做AI工程绕不开大模型。这个阶段不是让所有人去从头训练一个GPT而是学习怎么把已有的模型能力嵌入到应用里。重点掌握三块提示词工程、检索增强生成、模型微调。提示词工程解决的是怎么把需求准确描述给模型检索增强生成解决的是把外部知识接进来缓解模型一本正经地胡说八道的问题微调解决的是把模型适配到特定领域风格或特定输出格式。把三种手段都做一遍练习对大模型应用工程的理解就能从“调API”晋升到“做系统”。这个阶段还建议研究一下模型评估的新方法。大模型输出是开放式的不像分类模型那样有一个标准答案。怎么评估一个智能问答系统的回答质量本身就是个前沿问题。工程上一开始可以人工抽检规则检查后面再考虑用更强模型来做裁判评估。3. 工具选型与环境搭建的实操心得3.1 Python环境管理venv、conda、uv怎么选环境管理这件事看似小事实际影响巨大。我最早用系统Python直接装包后来被依赖冲突折磨得够呛才老老实实研究环境管理工具。venv是Python自带的虚拟环境工具轻量、简单适合单个项目。conda适合科学计算场景可以对Python版本做精细管理装CUDA相关依赖也方便但它的环境解析速度慢而且如果你只用pip依赖conda的优势就没那么明显。最近两年我主力切换到了uv它是一个用Rust写的Python包管理工具安装依赖速度非常快用起来几乎是秒级。如果你还没听过uv不妨了解一下它对开发体验的提升是实打实的。我的建议是公司项目跟着团队已有的规范走个人项目用uv起步省下的等待时间都很可观。需要注意的是无论用哪个工具一定要养成“为每个项目创建独立环境”的习惯。环境混用带来的依赖地狱问题在AI项目里特别常见因为一个项目可能要同时用PyTorch、NumPy、Pandas、Scikit-learn版本互相踩来踩去一天的时间就这样浪费了。还有个容易忽略的点锁版本。AI依赖的版本迭代太快今天装出来一个版本半年后重装可能就装到新版本行为还不一样。所以项目里一定要有requirements.txt或者uv.lock这类锁文件把关键依赖的版本固定住。我在做 ai-engineering-from-scratch 项目时每次实验都会记下依赖版本这让我后来复查实验时省了很多事。3.2 实验追踪从记事本到MLflow实验追踪工具我一共经历了三个阶段。最早是拿txt文件记实验日志写着“某月某日跑了某个模型AUC 0.82”过了两周自己都看不懂那些缩写。后来用代码里手动记录JSON稍微规范点但还是乱。再后来接了MLflow才感觉实验这件事真正上了轨道。MLflow是Databricks开源的一个实验管理平台核心功能包括实验记录、模型注册、模型仓库。你可以把每个实验的参数、指标、模型文件、代码版本全部记录在一起然后通过可视化界面对比不同实验的效果。实际用起来代码里大概是这样import mlflow with mlflow.start_run(): mlflow.log_param(learning_rate, 1e-3) mlflow.log_metric(val_auc, 0.872) mlflow.log_artifact(model.pkl)用MLflow之后最大的改变是我可以随时回溯到一个月前的某个实验看到当时的参数、数据和模型文件复现实验的成本低了很多。这个能力在我们后来做模型迭代、排查线上问题的时候尤其重要。如果你的公司规模不大不想搭K8s和全套MLOps平台MLflow单机版足够用很久。3.3 数据与模型的版本管理DVC怎么用代码有Git管数据没有版本管理怎么办改了几版清洗规则之后发现基线数据被覆盖了又找不回来——这个问题我踩过不止一次。后来引入了DVCData Version Control专门解决数据和模型的版本管理问题。DVC的思路是让数据文件像代码一样有版本。它不真的把大文件存进Git仓库而是把数据文件放在本地或云端的存储里Git仓库里只记录数据文件的元信息。你需要某个历史版本的数据时用一条命令就能切换过去。实际使用感觉dvc add data/raw/dataset.csv git add data/raw/dataset.csv.dvc .gitignore git commit -m add raw dataset v1对比一下有没有DVC的区别没有DVC你要手动备份整个数据目录命名成dataset_v1、dataset_v2这样的目录用不了多久目录就乱成一团。有了DVC数据和模型版本是跟代码提交绑定的这个实验用的哪份数据、哪个模型一条命令就能说清楚。我个人的体会是DVC的初始学习成本不高但收益在项目中期之后才会显现尤其当你开始协同时它能避免大量“你用的是旧数据”这种低效沟通。4. 一个端到端实战项目从数据到上线的完整拆解4.1 项目选型与目标定义新手做实战项目选什么题目很关键。我推荐做电商用户商品推荐这个方向原因有三个第一推荐系统是AI工程应用的经典场景覆盖数据、特征、模型、部署、监控全链路第二公开数据集很多比如MovieLens或一些电商行为数据获取容易第三业务指标容易理解点击、购买、加购这些行为天然对应着商业价值。定义目标的时候要先把业务问题翻译成模型问题。假设我们的目标是预测用户会不会点击一个商品那就是一个二分类问题。正样本是点击行为负样本是曝光但没点击的行为。注意这个翻译过程里有个坑曝光数据从哪来如果产品没有做曝光埋点你可能只能用点击行为做数据那就变成了一个“给定已点击商品预测多喜欢”的问题本质是召回排序和真正的点击率预估还不一样。这个区别决定了后面整个数据方案怎么做。我在项目里选择用公开的电商行为数据集构造一个简化版的点击率预估任务然后走完整条流程。这样既能保证数据可用又能把AI工程的各个环节暴露出来。4.2 数据准备与特征工程实操数据这一环我把流程拆成四步。第一步是数据探索性分析用Pandas快速看一下数据量、字段类型、缺失率、正负样本比例。第二步是数据清洗处理缺失值、去重、过滤异常时间戳。第三步是特征衍生从原始行为数据里构造用户特征、商品特征、用户与商品交互特征。第四步是数据切分严格按照时间顺序把数据分成训练集、验证集和测试集。特征衍生的思路不复杂但很体现经验。用户特征可以从他的历史行为里统计出来过去7天点击次数、过去30天购买金额、品类偏好向量。商品特征包括商品价格、类目、上架天数、历史点击率。交互特征则是用户和商品之间的关联比如用户在这个商品所属类目上的历史点击率。这些特征多数用SQL或Pandas就能算出来但代码要写得高效避免循环几十万条数据导致跑到天荒地老。切分数据的时候有个要点不能用随机切分。我从项目第一天就按照用户行为时间排序把前70%的交互数据作为训练集后30%作为测试集。这样模拟的是线上场景模型用历史数据训练然后预测未来行为。如果用随机切分数据里会混入未来信息模型评估结果虚高上线后立刻现原形。4.3 模型训练与评估迭代项目里我用PyTorch训练一个简易的DeepFM模型。DeepFM这种结构很适合用户商品推荐它同时做了一阶特征的线性拟合和二阶特征交叉的自动学习效果在中等规模数据上通常不错部署也不复杂。训练的核心代码不复杂但有几个关键点值得注意。数据加载要以batch为单位不能让模型一次性读入全部特征学习率初始值我习惯用5e-4配合warmup策略在训练初期先升后降训练过程里要同时监控训练集loss和验证集AUC两者差距拉大就说明过拟合需要加正则或提前停止。第一个版本跑出来验证集AUC可能在0.75左右勉强能用。但我的习惯是再做一轮特征迭代比如加上用户活跃度分箱特征、商品价格带特征看看AUC有没有明显提升。每个候选特征都用Ablation Study消融实验验证一遍加进去没提升的特征就砍掉。这个验证过程和写业务代码时看代码覆盖率有点类似都是为了确保每部分都有实在价值。到这一步模型文件会保存为一个Pickle或TorchScript格式同时记录好特征列表和预处理参数。这两个文件加一个配置文件就是后面部署服务的全部输入。4.4 服务化部署与监控落地部署阶段我用FastAPI写了一个轻量推理服务接口接收用户ID和商品候选列表返回每个商品的预测点击率。核心逻辑是加载模型文件把请求里的原始数据经过预处理和特征转换变成模型输入然后执行推理返回结果。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() model load_model(model.pt) class PredictRequest(BaseModel): user_id: int item_ids: list[int] app.post(/predict) def predict(req: PredictRequest): features feature_engineer(req.user_id, req.item_ids) scores model.predict(features) return {scores: scores}然后把这个服务包进Docker镜像服务端口暴露出来用docker-compose编排。为了稳定我还加了存活探针和超时设置。监控方面先做两层一层是服务层监控记录接口QPS、延迟、错误率另一层是模型层监控定期统计线上预测分数的分布以及用户反馈数据比如点击率有没有下滑。如果线上预测分数分布明显偏离训练时的分布就触发告警排查是不是数据漂移或者特征缺失。这样一套流程走完你对AI工程的理解就不再是零散的知识点而是一条完整的经验链。5. 实操中踩过的坑排查技巧实录5.1 数据泄漏看起来很棒上线就崩我刚做第一个推荐项目时验证集AUC高达0.92心里美滋滋结果上线后点击率几乎没有提升。查来查去最后发现是数据泄漏问题。我在做特征衍生时统计用户的历史点击次数时用错了窗口本应该统计用户在该时间点之前的行为结果把整个周期内的行为都统计进去了包括测试集时段的行为。相当于模型在考试时提前看到了答案。这个坑的教训有两条。第一条凡是用时间相关的行为做特征一定要在特征计算时保证只用历史数据写代码时就要注意过滤条件。第二条验证集的构造必须模拟线上情况最稳妥的方法是按时间划分而不是随机划分。之后就养成了习惯每次建模先问自己这个特征在预测的那一刻模型真的能拿到吗5.2 训练和推理特征不一致模型输出诡异有一次部署的模型在线上经常返回乱糟糟的预测结果排查了很久才发现问题出在特征处理环节。训练时我对类别特征做了label encoding编码表是模型根据训练数据生成的。部署时我把特征处理逻辑重写了一遍结果编码表的顺序和训练时不一致。模型输入的数字发生错位输出自然乱掉了。这个问题很典型解决办法是把特征处理的代码和模型绑定在一起不单独重写。要么用Pickle保存训练时的特征工程Pipeline要么把特征处理代码作为模型服务的一部分直接打包绝不在部署时复制一份新代码。我在 ai-engineering-from-scratch 项目的教程里反复强调这一点因为这是线上事故的重灾区。5.3 显存不足训练直接OOM用PyTorch训模型时最扫兴的莫过于跑到一半报CUDA out of memory。这个问题的排查思路其实很清晰。先看是不是batch size太大把batch size调小是最直接的应对手段。再看是不是模型参数太多需要简化结构或改用更小的嵌入维度。还有一个常见原因是代码里的显存泄漏比如循环里不断创建新的计算图而没有回收这时候需要检查每一轮的loss、梯度、优化器状态的引用有没有释放。梯度累积是一种常用的技巧显存不够时可以保持batch size不变分成多个小step计算梯度累积之后再做参数更新等效于大的batch size。混合精度训练也值得开起来PyTorch有原生支持scaler torch.cuda.amp.GradScaler() with torch.autocast(device_typecuda): output model(batch) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()开启之后显存占用和训练时间往往都有明显下降尤其在显卡不是很好的个人机器上。5.4 离线指标和线上指标对不上这是AI工程里非常磨人的问题。离线测试的时候AUC、准确率都挺好看上了线之后业务指标几乎没有变化或者变化方向和预期相反。这里面的原因往往是多方面的离线评估的样本和线上真实分布不一致、特征在线上拿到的值和训练时不一致、评估指标和业务指标本身没有强相关。排查的顺序我一般是这样先看输入数据有没有问题对比线上实际收到的请求特征和训练时的特征分布再看模型输出的分数分布有没有偏移如果线上分数集中在很小的区间说明特征差异导致区分度失效最后再回到业务指标看看是不是评估指标选错了。这个排查过程需要日志系统配合线上请求要记录日志出了问题才能回溯。5.5 线上模型效果衰减不只是重新训练那么简单模型上线运行一段时间后预测效果往往慢慢变差这在AI工程里叫模型漂移。原因有很多用户偏好变化了、商品池更新了、季节因素让某些特征不再有效。很多人第一个反应就是重新训练模型但我不建议这么急着动手。先做诊断看看漂移主要来自哪部分数据。用最近的线上日志画出预测分数的分布变化趋势再按用户分群分析每个群体的指标跌幅。有时候问题只出在某个新上架的商品类目上特征构建出了问题重新训练也修不好。如果确认是数据分布变化再触发重训重训时要特别注意新数据的标注或反馈是否准确。还有一种情况是模型本身没变差但业务规则变了比的已经不是同一个东西了这时候要回到业务对齐而不是闷头调模型。6. 最后的实在建议先完成一个最小闭环说了这么多最后分享几条我个人经验里的体会。第一不要追求看完所有理论再动手。AI工程是一门手艺活知识的留存率远低于技能的留存率。我的建议是选一个中等难度的项目比如上面那个推荐系统用两到三个月时间把从数据到上线的完整闭环跑通。过程中遇到什么补什么效率远高于按部就班读书。第二一定要养成记录实验笔记的习惯。记录得越细越好包括数据版本、代码版本、超参数、指标、当时的疑问。很多排查问题的时间其实耗在“我这是哪次实验的结果”上。笔记不光是给未来的自己看也是你向团队展示工作价值的方式。第三尽量在真实比赛或开源项目中练手。公开数据集大多经过清洗真实业务的数据脏得让人怀疑人生但那种混乱才是AI工程师每天面对的现实。竞赛平台和开源社区都会提供相对完整的任务描述和评估标准在上面完成一两个项目比看一堆教程有用得多。我整理 ai-engineering-from-scratch 的时候最大的感受是AI工程里每一个环节都不算难难的是把它们串起来并能在持续迭代中保持稳定。希望这篇经验总结能帮你少走一些弯路。如果你正卡在某个环节上别急那说明你已经走在正确的路上了。
阅读完成 · 觉得有帮助？
