1. 为什么我把这条学习路线命名为“from scratch”这两年“AI工程”这个词出现的频率越来越夸张。打开任何技术社区铺天盖地都是大模型微调、RAG、Agent、向量数据库、推理加速……看起来门槛很高好像没个几年的算法功底根本玩不转。但我在带团队和做内部技术分享时发现真正能把一个AI项目从想法推到线上稳定运行的往往并不是算法理论最强的那些人而是能把“工程链路”理清楚的人。所以我干脆把自己这些年从零搭AI应用的完整思路整理成一个名叫ai-engineering-from-scratch的项目核心就一句话不靠背诵公式不靠堆模型从工程视角把AI这条链路一步步走通。这个项目不是什么高深论文更像是一张我在实战中反复修正过的路线图。它覆盖的是从需求拆解、数据准备、模型选型、训练调优、部署上线到监控迭代的全流程面向的是想真正动手做AI应用的人——不管是刚转行的后端开发、产品经理还是在校学生只要能写一点Python愿意花时间动手跑实验都能跟着这条路线做出一个有真实价值的小系统。很多人学AI失败不是不努力而是上来就啃《统计学习方法》、刷Linear Algebra学了两周矩阵还没看到模型长什么样热情全被磨没了。我在这个项目里刻意把顺序调了过来先让你用最小成本跑通一个端到端流程看到AI应用“活”起来的样子再回头补原理。你有了全局画面之后再学数学和算法脑子里有锚点效率完全不一样。这条路线到今天我已经完整迭代过三轮带过几批新人按这个路径学习踩坑率比传统“先理论后实践”低很多。接下来我会把整个设计思路、实操步骤、关键参数和踩坑记录完整拆开讲内容是我亲自跑过、验证过的不是网上那种只列书单的收藏夹式路线。2. 学习路线的整体设计与思路拆解2.1 四大支柱数学够用、编程熟练、模型理解、工程落地我设计的整条路线围绕四个能力支柱展开顺序也很有讲究。第一根支柱是数学但我只要求“够用就行”。线性代数重点掌握矩阵乘法、向量空间、特征分解这些和深度学习直接相关的部分概率统计重点掌握贝叶斯思想、分布、期望方差微积分主要理解梯度、导数的含义会算链式法则。我并不推荐你把三本数学书从头啃完而是建议用“用到什么学什么”的方式学到梯度下降时再回头看导数推导。第二根支柱是Python编程这块要求反而比数学高。你要能熟练使用NumPy、Pandas处理数据会写类、装饰器、生成器理解Python的内存模型和GIL机制因为后面做服务化部署时这些知识直接决定你能不能定位性能瓶颈。很多科班出身的人算法很厉害但写出来的代码没法维护、没法测试、没法上线问题就出在编程基本功不够。第三根支柱是模型理解。这里我强调的是“理解”而不是“手推”。你需要搞清楚CNN为什么适合图像、Transformer的注意力机制到底在做什么、RNN为什么在长序列上容易挂而不是把PyTorch文档背下来。你要能做到看到一个新模型架构能说出它解决了什么问题、代价是什么、适合什么场景。第四根支柱才是工程落地包括数据管线、模型训练、模型服务化、性能优化、监控告警。我的经验是如果前三根支柱各占20%的精力第四根工程落地至少要占40%的精力。现在行业里最缺的不是能跑通一个Notebook的人而是能把模型变成稳定服务的人。2.2 为什么先工程后模型再模型后工程这条路线里最反直觉的设计是我把“工程”提前了。传统教学顺序是先数学、再算法、再工程我的顺序是先做一个最小工程项目、再学模型、再反哺工程。这背后的逻辑其实很简单人只有看到目标才有动力去学枯燥的工具。第一轮实操我会让学员做一个小项目用scikit-learn做一个垃圾短信分类器。数据集不大代码不超过150行但整个流程五脏俱全——加载数据、清洗、特征提取、训练、评估、保存模型、写一个简单的API接口。这个流程走完学员脑海里就有了完整的AI应用地图知道每个环节长什么样。有了这个地图再回去学深度学习原理你会自然地问“Word2Vec和TfidfVectorizer的本质区别是什么”“为什么深度学习模型需要归一化”“过拟合到底是怎么发生的”带着问题学理解速度比漫无目的地刷课快好几倍。学完模型再回来看工程你会开始关注超参数怎么管理、模型怎么版本化、推理延迟怎么压下去。这种“工程-模型-工程”的螺旋式结构是我这几年带人总结出来的最有效的路径。直接学工程没有模型底子做出来的东西是空中楼阁直接学模型不懂工程做出来的东西只能在Jupyter Notebook里自嗨。2.3 技术选型背后的取舍整套路线的技术栈我都是按“最小成本跑通、后续平滑升级”的原则选的。编程语言只用Python深度学习框架首选PyTorch数据处理用PandasNumPy模型服务用FastAPI容器化用Docker。这些选择不是跟风而是经过实际对比的。为什么不是TensorFlow1.x时代TensorFlow的静态图机制对新人极其不友好调试一个模型要编译半天现在虽然2.x用了Eager模式但社区重心已经明显偏向PyTorch。学术论文几乎全是PyTorch代码生态上新模型适配也是PyTorch最快这决定了你不论看源码还是找预训练模型PyTorch的摩擦都最小。为什么用FastAPI而不是Flask或Django三个原因自动生成OpenAPI文档前端联调方便基于Pydantic做请求校验类型安全async支持让推理服务的并发能力提升好几个量级。我自己实测过一个简单的模型服务同样4核8G的机器Flask的QPS大概在800左右FastAPI跑到2000以上代码复杂度几乎一样这差距是白捡的。3. 核心细节解析从零搭出一个可用的AI工程小系统3.1 阶段一数据准备与特征工程很多新手拿到数据直接丢进模型训练这是新手最容易犯的错误没有之一。我见过无数次精度上不去、训练发散、线上线下指标对不上根因全是数据没处理好。真正规范的数据管线应该是先做数据探索再设计特征工程然后切分数据集最后才进模型。数据探索阶段你要回答几个问题样本量有多大类别分布是否均衡有没有缺失值和异常值各特征之间有没有明显相关性我习惯用Pandas Profiling快速出一份EDA报告然后重点检查目标列的分布。做分类任务时如果正负样本比超过1:10就要考虑采样策略了。特征工程阶段我的个人经验是“先保证不漏信息再做稀疏化”。文本类特征先做分词、去停用词、TF-IDF向量化数值类特征做归一化或标准化类别特征做目标编码或One-Hot编码。这里要注意一个坑特征工程必须只基于训练集拟合验证集和测试集只能做变换不能参与拟合。很多人图省事对全量数据统一fit结果就是验证指标虚高上线立刻现原形。这个过程在机器学习里叫“数据泄漏”后面5.2我会细讲。数据切分方面我强烈建议留出三个集合训练集、验证集、测试集。训练集用来训练模型权重验证集用来调超参和早停测试集只在最终评估时用一次。比例我惯用70-15-15如果数据量很大可以放宽到98-1-1但测试集必须保证足够样本量否则评估结果方差太大没法判断模型到底行不行。3.2 阶段二训练与评估的闭环训练阶段的核心要求是“每次实验都可复现”。我在项目里从第一天就要求固定随机种子、固定数据顺序、记录所有超参数和实验指标。这里的随机种子包括Python的random、NumPy的random、PyTorch的manual_seed另外如果是GPU训练还要加torch.backends.cudnn.deterministic。不固定的话模型每跑一次结果都不一样你怎么判断这次改动是好是坏训练脚本我建议从一开始就用argparse或配置文件管理超参数不要写死在代码里。学习率、batch size、epoch数、优化器类型、weight decay这些参数要能在命令行覆盖。后续你一定会遇到“昨天跑出来A结果今天怎么变成B结果”的情况没有记录体系排查起来基本靠猜。评估阶段分类任务不要只看Accuracy。我会按任务类型选择指标垃圾邮件这类正负样本不平衡的场景看F1-score和AUC推荐场景看RecallK和NDCG回归场景看MAE和RMSE。每轮实验我都要保存三样东西——模型权重、指标报告、可视化的训练曲线。这三样是排查问题的第一手材料。3.3 阶段三模型服务化部署模型训练好只是开始真正让它产生价值的是部署上线。我推荐的方案是先把PyTorch模型转成TorchScript或用ONNX导出然后用FastAPI封装成一个独立的推理服务。为什么要做格式转换因为直接用PyTorch加载原始模型跑推理有两个问题一是依赖PyTorch整个生态部署镜像太大几百MB起步二是推理性能不行没有经过图优化。用TorchScript导出模型的代码很简单核心就是把模型设置为eval模式然后import torch model MyModel() state_dict torch.load(model.pt, map_locationcpu) model.load_state_dict(state_dict) model.eval() example_input torch.randn(1, 3, 224, 224) traced_model torch.jit.trace(model, example_input) traced_model.save(model_scripted.pt)但这里有个大坑torch.jit.trace只能固化静态计算图如果模型里有条件分支、动态循环或依赖输入长度的操作trace的结果可能是错的。经验做法是先看模型里有没有这类控制流有的话要么改成等价的张量操作要么直接用torch.jit.script而不是trace。我踩过的典型场景是把BERT接分类头输入长度变化导致trace后序列维度被固定住推到线上直接shape mismatch。部署时的模型服务代码也很短FastAPI的写法from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class TextIn(BaseModel): text: str class PredOut(BaseModel): label: int confidence: float app.post(/predict, response_modelPredOut) def predict(data: TextIn): prob predictor.predict(data.text) return {label: int(prob.argmax()), confidence: float(prob.max())}服务写好之后用Docker打包。基础镜像用python:3.10-slim装依赖时有个优化技巧假设依赖变动不频繁把requirements.txt的安装步骤放在COPY代码之前这样镜像构建时能命中缓存层不用每次改代码都重新装包。我在CI里测过按这个顺序构建二次构建时间从3分钟降到20秒。Dockerfile的骨架长这样FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 80]跑起来之后再用docker run -p 8001:80 my-ai-service映射端口。这时你用curl随便发一条测试文本验证一下模型服务的第一个完整版本就算落地了。3.4 阶段四监控与迭代模型上线不代表结束我反而觉得这恰恰是AI工程真正开始的地方。模型在真实环境中会遇到训练时完全没见过的情况用户输入格式变化、数据分布漂移、推理延迟波动。这些不做监控线上出了问题你可能是最后一个知道的人。最小可用的监控方案包含三块日志、指标、告警。日志方面每次推理请求要记录输入摘要、耗时、预测结果日志格式用JSON结构化输出方便后续喂给日志系统查询。指标方面用Prometheus记录QPS、P99延迟、模型置信度分布、特征值分布告警方面P99超过阈值或置信度均值骤降时触发通知。模型迭代的触发器不只是每次上线新功能才做。我会定期对线上请求做抽样回流用最近一周的真实数据重新评估模型如果F1掉了超过2个百分点就要启动重训。这种“用真实数据喂养模型”的闭环才是AI应用长期稳定的根本。很多团队把模型训练当成一次性的活上线后就撒手不管过了三个月模型效果烂到没法用然后再紧急返工其实都是缺少这个环节。4. 实操现场记录与关键参数解析4.1 一个典型的垃圾短信分类小项目为了让这条路线落地我带学员做了一个完整的垃圾短信分类器。数据集用经典的SMS Spam Collection共5574条短信其中spam占比约13.4%。这组数据量不大单机CPU训练完全够用非常适合第一轮实操。数据加载直接用Pandas读csv然后把label列映射成0和1。原始数据里类别是不均衡的spam只有747条ham有4827条我用了两种方案对比一种是不做处理直接训另一种用imbalanced-learn里的RandomUnderSampler把ham采样到和spam同量级两种结果差异非常明显——不做采样模型偏向预测hamF1只有0.82采样后F1到0.93以上。但采样也有代价会损失一部分ham样本信息所以实战中我更推荐用class_weight参数来调整损失权重效果接近但不用丢数据。特征工程第一步是清洗去掉标点符号、统一小写、去掉URL和数字。这里有个小细节垃圾短信经常用“FREE”“WIN”这类全大写词直接做小写化会丢失这个信号所以我单独加了一列“包含全大写单词数”作为手工特征。第二步是TF-IDF向量化用ngram_range(1,2)同时捕捉单词和相邻短语sublinear_tfTrue可以缓解高频词主导的问题。向量化之后特征维度会有几千维对这种稀疏高维特征线性模型效果往往就足够好。我第一版用了Logistic RegressionC设为1.0准确率已经到97.6%。换用Multinomial Naive Bayes后F1反而略高一点原因是朴素贝叶斯对稀疏文本特征有天然的平滑机制。这轮实验最大的收获不是模型多强而是让学员明白小数据集上不要一上来就上深度学习传统机器学习模型通常训练快、可解释性强、部署成本低足够满足90%的业务需求。4.2 训练时的关键参数怎么定训练参数是最容易让人迷茫的地方。很多人跑来问我学习率设多少合适batch size选多大epoch跑几轮我的回答是别背数字要理解每个参数背后的逻辑。学习率决定梯度下降的步长。太大模型震荡不收敛太小收敛速度慢到怀疑人生。我判断学习率是否合适的经验是做一个learning rate finder从小到大批量调整学习率每个值跑几步看loss变化找到loss下降最快的那段区间这个区间中段就是合适学习率。PyTorch里有现成的torch.lr_scheduler配合手动写循环几十行代码就能实现。batch size的影响更微妙。大batch训练稳、梯度准、GPU利用率高但会引入尖锐极小值泛化能力略微下降小batch噪声大反而可能跳出局部最优但训练时间长。我的基线是Bert类模型用16或32CNN/MLP用64或128。这批参数在实际使用中失效很少。epoch数别拍脑袋定用early stopping。规则很简单每个epoch结束用验证集算loss如果连续N个epoch验证loss不再下降就回滚到最优模型权重并停止训练。我一般设patience3到5个epoch。这套机制不仅省时间还能防止过拟合。更关键的是每次改超参必须只改一个变量。同时调学习率和batch size就算效果变好你也不知道是哪个起了作用。拉一个实验记录表把每次的参数组合、评估指标、训练时间都记下来这养成的是一种工程素养而工程素养恰恰决定了你在这个行业能走多远。5. 常见问题与排查技巧实录5.1 过拟合训练集指标很高验证集完蛋我在整个实操过程中最常被问到的就是过拟合。典型症状是训练集loss持续下降、准确率接近满分验证集却停滞甚至上升。本质是模型把训练数据里的噪声一并记住了没有学会泛化规律。排查思路分几步走。第一步确认数据切分没问题没有泄漏如果验证集本身就有问题后面全是白费。第二步检查模型复杂度一个几千样本的数据集用ResNet152这种几十层的网络过拟合几乎是必然的先换成简单模型再对比。第三步看正则化手段有没有到位加weight decay、加Dropout、做数据增强。第四步回看训练曲线如果验证loss在第10个epoch开始翘头那就是最佳停止点。实操里的建议是过拟合不可怕可怕的是不知道自己的模型在过拟合。养成每次训练都把train loss和val loss画在同一个图里的习惯看到两个曲线距离越拉越大就该对模型做减法了。我自己的小技巧是拿测试集上犯错的样本打印出来逐条看很多时候你会发现模型不是“笨”而是被某些无意义的强特征带偏了——比如垃圾短信分类器把“退订”当成spam标志这类case只有人眼看得懂。5.2 数据泄漏模型在验证集上“作弊”了数据泄漏是我认为AI工程里最隐蔽、最致命的问题。它的表现和过拟合很像——训练指标和验证指标都完美但一上线就崩。很多人还会误以为是环境差异其实问题早在数据处理阶段就埋下了。最常见的泄漏来源有三个。第一是特征工程阶段直接在全量数据上fit。比如你写scaler.fit(X_all)再用同一个scaler去transform训练集和验证集验证集的信息已经透进训练过程了。正确做法是scaler.fit(X_train)然后分别transform训练集和验证集。第二是数据切分前就做了全局清洗去重同一原始记录可能在训练集和验证集各出现一次模型已经在训练时“背过答案”。第三是时间序列数据用了随机切分而不是按时间切分未来的信息穿越到历史里去了。排查泄漏的方法是做一个“分组交叉验证”压力测试把数据按用户ID分组确保同一个用户的数据不会同时出现在训练集和验证集。如果分组验证的指标比随机切分的指标明显低一大截你就有理由怀疑存在泄漏。我在项目里专门写了一个章节教这个排查流程每轮实验报告里都要求学员必须写明数据切分方式和是否有分组。5.3 部署后性能比训练时差一大截训练时F1有0.95部署到线上变成0.8这是另一类高发问题。我总结下来原因有四种按频率排序一是线上输入格式和训练时不一致比如训练时做过分词清洗线上接口拿到原始文本直接丢给模型二是特征工程管线没对齐训练时做了TF-IDF线上服务没有加载同一个vectorizer特征空间直接变了三是模型在CPU和GPU上的数值行为有细微差异四是线上并发高导致推理进程被打满模型返回的结果是超时的默认值。解决方案的核心是“管线一致性”。把特征工程和模型推理封装成一个完整的Pipeline对象训练时fit完直接连同向量化器一起dump成joblib文件。部署时只允许加载这同一个artifact杜绝线上用另一套代码逻辑。下面这段代码是我常年使用的模式from sklearn.pipeline import Pipeline pipe Pipeline([ (clean, TextCleaner()), (tfidf, TfidfVectorizer(ngram_range(1,2), sublinear_tfTrue)), (clf, LogisticRegression(C1.0, class_weightbalanced)) ]) pipe.fit(X_train, y_train) import joblib joblib.dump(pipe, spam_pipeline.joblib)上线再处理预测请求时永远只调pipe.predict不单独调特征工程函数。这个约定简单粗暴但能消掉至少一半的线上线下不一致问题。性能层面我还会做一次preload warmup服务启动后先用测试样本跑十几次推理把权重换页、缓存预热做完否则第一个请求的P99能慢三倍。5.4 依赖与版本管理今天能跑明天跑不了新手跑老项目经常遇到“模块不存在”“API变了”“编译报错”的连环问题。本质是环境漂移今天装的包和三个月后装的包版本对不上。我要求项目从一开始就做三层锁定requirements.txt里锁最小版本比如numpy1.24,2.0用pip freeze requirements-lock.txt锁定完整环境版本更进一步用Docker镜像锁操作系统和Python版本。还有一个细节值得提CUDA和PyTorch的版本匹配是重灾区。PyTorch的每个版本对应不同版本的CUDA runtime装错之后最常见的问题是torch.cuda.is_available()返回False但明明有显卡。排查方法是进容器里执行python -c import torch; print(torch.version.cuda)看输出的CUDA版本和nvidia-smi驱动的最高支持版本是否匹配。版本管理的最高优先级是能“一键复现”。不管换电脑还是换同事只要环境定义文件在五分钟以内能拉起来一个一致的环境。我在项目里写了自动构建脚本docker build之前先自动比对镜像标签环境有任何变更就重新构建并打上新标签。这样整条链路的版本状态始终可追溯出了问题能快速定位是哪个依赖引入的。6. 给新手的几条实操建议这条路线我自己走完了三轮每轮都有不一样的收获。第一轮顺利到有点怀疑自己是不是漏了什么第二轮开始带人后才发现原来那些看似理所当然的操作对新手全是沟壑。所以最后想给正在按这条路线学习的朋友几个实在建议。第一个建议是绝对不要跳过第一轮最小项目直接学深度学习。我见过太多人一上来就追求训练BERT结果光是Tokenizer和Attention Mask的报错就卡了三天挫败感直接劝退。先用线性模型跑通全流程这150行代码里包含的工程心智模型是你未来所有AI工作的地基。第二个建议是每做完一个阶段就写一份简短复盘内容包括我做了什么、出现了什么问题、怎么排查的、下次怎么避免。不需要长篇大论100字都行但一定要写。我回看自己第一轮的复盘文档里面记着“特征工程在全量数据上fit导致验证指标虚高”“FastAPI的response_model必须用Pydantic的BaseModel子类”这些细节全是现在教学时最值钱的素材。第三个建议是找一个真实业务场景练手不要用Kaggle上清洗好的现成数据集。真实场景的数据永远是脏的、字段含义模糊的、类别分布离奇的这才会逼你去处理那些调参之外的事而处理这些破事的过程才真正磨出你的工程能力。我自己做过的线上垃圾消息拦截项目数据第一天进来时连label都没有光做数据标注方案就花了整整一周但这一周的收获比之前学一个月都大。最后还想提醒一句AI工程不是一个“看完就懂”的知识体系它是一张“不跑就亏”的地图。你可以把这篇拆解当作起点但更重要的是把路线里每一站都当成需要动手的项目而不是速查的文档。按我自己的经验坚持做完三个完整项目之后你会明显感到那些概念不再是从文章里看到的句子而是你自己踩过的路。