ai-engineering-from-scratch这条路我走了整整两年期间踩过的坑比学到的东西还多但回头看恰恰是那些坑让我真正理解了AI工程是怎么回事。今天这篇文章我想把这两年的路线、踩坑和复盘一次性写清楚给同样打算从零开始、不靠现成API拼装方案的人一份可以直接照做的地图。我先说清楚“from-scratch”指的是什么。不是让你自己从线性代数开始推导Transformer也不是让你手写GPU驱动而是不依赖那些封装好的“AI黑盒平台”从开源模型、公开数据、基础工具链出发把一个AI项目完整地做出来并让它跑在生产环境里。这个过程中你会写数据清洗代码、训练脚本、接口服务会调显存、调并发、调超参数会踩到外网模型下载、依赖冲突、预训练权重对不上这类真实问题。这条路适合谁适合那些不想只当“调包侠”、想搞清楚系统里每个环节为什么这么设计的开发者也适合团队里没有专职AI工程师、但需要自己扛起AI功能的后端或全栈工程师。我会按照入门准备、技术栈、完整实操、进阶方向、避坑指南这几块来讲尽量让新手跟得上也让有基础的人能拿到一些有用的细节。1. 整体设计思路为什么我选择“从零”而不是“调API”1.1 我理解的AI工程到底是什么AI工程不等于训练模型更不等于写Prompt调大模型。它是一条完整的链路需求定义、数据收集与清洗、模型选型与训练、评测、部署、监控和持续迭代。很多人觉得“AI做了个功能”就可以了但真正跑起来你会发现训练出一个不错的效果只是开始后面还有一多半工作量在运维和数据回流上。我用一个具体例子解释。你的业务是做一个文本审核系统目标是识别用户发帖里的违规内容。一开始你调用第三方大模型APIPrompt写得够好效果确实不错。但上线之后会遇到单条请求延迟不可控、费用按量增长、遇到敏感数据不能外传、API升级导致输出格式变化。这时候如果你懂AI工程你会知道解决方案不是继续调API而是用一个小模型在本地做初筛把大部分正常内容挡住只有疑似违规的才交给大模型或者直接用开源的检测模型微调一版部署到自己的服务器上。这就是工程思维和“试用思维”的区别。前者把AI当作一个软件系统来设计考虑成本、延迟、稳定性、数据安全后者只是把AI当作一个远程函数调一调。1.2 从零路线和直接调API路线的本质区别直接调API你获得的是“效果”失去的是“控制权”。从零做起反过来你付出的是“成本”收获的是“理解和自由度”。我打个比方。调API就像是去餐厅点菜好吃但贵而且不能换厨师。从零路线就像是自己买菜做饭前期要学切菜、掌握火候、采购食材但一旦你掌握了你可以随时出新品、调口味、控制成本甚至针对家人口味定制。做AI系统一辈子要依赖别人的API吗短期可以但长期总有些场景不允许数据不能出域、延迟要求极高、单次调用成本超过业务承受力、或者就是需要把一个模型深度定制到特定领域。从零路线还有一个隐性收益调试能力。只调API的人遇到效果不对时能做的只有改Prompt、换模型、加示例一旦这都不行就束手无策。而懂底层的人可以看数据分布、看loss曲线、看attention权重、看中间层输出能定位到是数据问题、模型结构问题还是训练策略问题。前者是在猜后者是在诊断。1.3 我认为这条路线最难的地方不是数学也不是写代码而是“同时处理太多没想到的环节”。训练一个文本分类模型你原以为核心是模型结构实际做下来才发现数据清洗花的时间最多标签不一致导致模型学错测试集和训练集分布不一致导致评测虚高部署时模型格式转换搞了一整天。从零做AI工程本质是同时掌握数据工程师、算法工程师、后端工程师三份技能你不需要每个都精通但每个都要懂到“能自己动手解决常见问题”的程度。这一点我在后面的实操部分会用真实案例展开。2. 入门前的技术栈分层把地基打牢再盖楼2.1 数学其实只需要三样很多人一听AI就害怕数学觉得要学完高等数学、线性代数、概率论才能动手。以我的经验做AI工程而不是AI研究真正高频用到的数学就三块线性代数主要是矩阵乘法、维度变换。你训练时数据都是一个batch一个batch过模型的每个batch就是shape为[batch_size, seq_len, hidden_size]的张量不理解维度变换很多报错你根本看不懂。概率论主要是分布、期望、最大似然估计。损失函数你天天见cross-entropy本质上就是最大似然理解了这点你就明白为什么分类问题用它而不是MSE。微积分主要是反向传播的链式法则但实践中你不用手推梯度只需要知道学习率太大loss会震荡、太小收敛太慢这就够了。我不建议专门花三个月补习数学再开始正确姿势是先跑通一个最简单的模型遇到不懂的数学概念再回头补带着问题学效率高十倍。2.2 Python之外的工程能力Python只是基础AI工程用到的东西远超语言本身。我认为优先级排序是这样的第一是Linux操作。训练和部署基本都在Linux服务器上跑你得会看磁盘空间、装驱动、管理进程、查看GPU状态。不会nvidia-smi看显存你连“显存不够”这个报错都排查不了。第二是Docker容器化。AI项目依赖极其脆弱昨天还能跑的代码今天更新了一个依赖库就崩了容器化是唯一能锁住环境的方案。第三是Git和代码管理。听起来简单但做实验的人经常搞成“最终版v3_改改_final”这种文件名地狱用Git管理实验代码和配置是基本功。这些技能单独看都不难但组合起来就是工程能力的门槛。很多人模型训得出来却部署不到生产差的就是这一层。2.3 一套可以抄作业的工具链清单直接给一个我目前用下来的顺手公式训练框架用PyTorch生态最全、遇到问题搜得到答案新学的人不要一上来就碰分布式训练框架先跑通单机单卡再说。模型仓库用HuggingFace Transformers加载开源模型和数据集最方便但注意国内网络环境的下载问题。数据处理用Pandas加Datasets库前者处理小规模数据顺手后者处理大数据集更高效。实验追踪用WandB或MLflow记录loss、参数、模型版本否则你跑了几十组实验后根本分不清哪个配置最好。部署层面模型转换用ONNX推理加速用vLLM或者Triton Inference Server服务框架用FastAPI。我后面实操部分会详细展开从训练到部署的完整链路。3. 核心实操从零搭一个可用的AI服务这一部分是全文重点。我会用一个实际案例串起完整流程从零训练一个文本主题分类模型并部署成一个可以调用的HTTP服务。为了不让大家觉得“我不做文本分类这个案例没用”我会在每个环节强调通用原则无论你做图像、音频还是其他任务都适用。3.1 选第一个项目的原则为什么不选大模型而是小模型新手入门我强烈建议第一个项目做一个“窄而深”的小任务而不是一上来就搞大模型应用。文本主题分类、图像二分类、目标检测这些就是好项目。原因有三个小模型训练快迭代周期短。你改一个参数几分钟就能看到效果反馈快才能学到东西。大模型微调一次几小时出错了排查成本高对新手非常不友好。小模型部署门槛低。一个BERT-base级别的模型CPU也能跑不需要昂贵的GPU服务器。等你能在小项目上跑通全链路——数据、训练、评测、部署、监控——再去做大模型项目只是把模型组件换一下其他环节的经验完全复用。我第一个完整项目就是垃圾评论分类。需求很明确用户在评论区发的内容要自动判断是正常评论还是垃圾广告。数据用开源的中文评论数据集模型用BERT中文预训练版本最终部署成了FastAPI服务。整个项目两周完成但这两周让我把AI工程的链路彻底走通了。3.2 数据准备与清洗真正花时间的地方很多人入门时会把90%的精力放在模型上但实际做下来会发现数据才是决定项目生死的关键。我的经验是数据准备要占整个项目至少50%的时间这不是浪费时间。第一是数据来源。我不会用网上乱七八糟的所谓“现成数据集”而是主动去找公开的、有说明文档的数据集。HuggingFace Datasets平台可以直接用一行代码下载对新手最友好。比如我做评论分类用的就是THUCNews的一个子集和自采的评论数据整合而来。第二是清洗。爬来的文本数据什么问题都有HTML标签、特殊符号、过长文本、空行、表情符。我写了一套清洗函数按顺序处理去HTML标签、去URL、去emoji或选择保留取决于任务、去重复空格、截断超长文本。这里有个细节清洗规则要统一应用在训练集和测试集上否则训练时模型见的是一种数据分布上线时见的是另一种效果必然崩。第三是标签一致性。最容易出问题的地方两个标注员对同一段文本可能给不同的标签。我处理办法是先做一轮预标注然后人工抽检把不一致的样本拎出来讨论标准。数据量大时至少保证训练集和验证集的分布一致。3.3 模型训练与关键参数调整我用Google的BERT-base-chinese模型做基础模型。为什么用这个不用更新的模型因为它在中文任务上表现稳定、可用的资料多、权重下载也方便作为入门足够了。模型选型原则就一句话在你熟悉、社区讨论多、文档全的模型里选不要追新。训练代码的框架流程很固定加载数据集和分词器、定义数据加载器、加载预训练模型、定义优化器和学习率调度器、训练循环。我在这里补充几个真实调参经验第一学习率。全量微调BERT学习率我见过最常用的范围是2e-5到5e-5我实测下来3e-5比较稳。学习率太小loss降得慢太大模型在几个epoch内就发散或者过拟合。判断方法很简单看训练集loss有没有稳步下降验证集loss有没有同步变化。第二batch size。显存不够就调小一般16或32足够。batch size还影响收敛速度我习惯先用小batch size跑通流程再加大跑正式实验。第三epoch数。不要死等loss降到最低要用验证集判断。每训练完一个epoch就在验证集上跑一次保存验证指标最好的那次参数。我用的是Early Stopping连续3个epoch验证集指标没提升就停下来。第四混合精度。如果你的GPU支持FP16训练速度能快一倍左右。PyTorch里一行代码就能开启新手容易忽略这个优化。3.4 从训练模型到部署成HTTP服务全流程回放模型训练好了你拿到的是一个PyTorch的.bin权重文件这还不能直接被生产环境使用。部署链路有四个环节模型导出、服务封装、容器化、性能优化。模型导出PyTorch动态图模型直接部署性能差、依赖重所以先转成ONNX格式。我用torch.onnx.export导出踩过最大的坑是动态输入长度问题如果不指定动态维度导出后模型只能接受固定长度输入而实际使用时用户文本长短不一。解决办法是设置dynamic_axes参数让序列长度维度变成动态。服务封装我用FastAPI写接口。核心就两个接口/health用于健康检查/predict用于接收文本返回分类结果。注意模型要放在全局加载一次不能每次请求都加载一遍否则延迟会高到离谱。容器化Dockerfile里把Python依赖、ONNX模型文件、服务代码打包进去。这里有个坑ONNX Runtime的CPU版本和GPU版本不能混用写requirements时要把onnxruntime-gpu和onnxruntime二选一。我当时没注意装了两个版本结果推理一直走CPU速度上不去。性能优化如果使用CPU推理可以用ONNX Runtime自带的图优化和int8量化延迟能降一半。如果使用GPU推理可以上vLLM或Triton做并发优化。不过对于第一个项目先把流程跑通性能优化放在第二步。3.5 上线后的监控没有监控就等于盲跑部署完不是结束是开始。模型上线后我需要回答几个问题请求量多少、延迟多少、失败率多少、预测结果分布是否异常。最简单的监控方案是日志加定时统计。我在FastAPI里给每个请求记录时间戳、输入长度、预测类别、耗时每天跑一个脚本统计指标。后来我接了Prometheus加Grafana数据可视化后更容易发现异常。模型效果也会漂移。比如垃圾评论的形式是慢慢演化的去年能识别的模式今年可能就不适用了。解决办法是定期抽样线上数据人工判断模型预测错误的比例一旦超过阈值就重新收集数据、重新训练。这个机制叫“反馈闭环”是AI工程和普通软件工程最大的区别之一普通软件只要不坏就一直跑AI系统会慢慢变笨。4. 进阶方向RAG、微调与评估体系建设跑通一个小模型的完整链路后你就可以往更复杂的方向走。我把进阶路径按性价比排序。4.1 什么时候开始碰RAG以及怎么理解它RAG检索增强生成是这两年大模型应用里最火的方向。核心思想很简单大模型训练数据是静态的不知道你公司最新的业务知识。RAG的做法是先把文档切块、向量化存入向量数据库用户提问时先检索出最相关的文档片段再把片段和问题一起交给大模型生成回答。为什么RAG比微调更适合大多数业务场景因为它是“外挂知识库”知识可以随时增删改不需要重新训练模型。成本低、见效快而且可以追溯答案来源用户能看到“答案是基于哪份文档生成的”可信度更高。新手做RAG我推荐的技术栈是嵌入模型用BAAI/bge-small-zh或m3e-small向量数据库用Chroma或Milvus生成模型用开源的中文大模型。踩过最大的坑有两个。一个是切块策略块大小直接影响检索质量。块太大检索到的内容包含太多无关信息块太小语义不完整。我用的是500到800字符滑动切块重叠50字符实测下来效果比较稳。另一个是召回排序简单向量检索召回效果不够时加上重排序模型reranker能明显提升准确率代价是多一次推理延迟。4.2 微调不是魔法是驯化RAG能解决“知识更新”的问题但解决不了“行为风格”的问题。比如你希望模型用特定的格式输出结果、按照特定的话术风格回答或者变成一个擅长特定领域任务的专家这时候才需要微调。微调的本质是继续训练让模型在更多特定样本上调整参数。它的适用条件是你有足够多的高质量数据至少几千条且任务模式比较固定。我自己的实践经验是微调小参数模型如7B以下用LoRA就够了。LoRA是冻结原模型参数只训练一小部分低秩矩阵显存占用小、训练速度快、效果也不差。具体操作不展开推荐一个稳定的方案用peft库配合transformers库配置文件里设定r8, alpha16, dropout0.05一般可以跑通。但我要提醒一句微调数据质量比数量重要。一干条高质量数据的效果可能好过一万条噪声多的数据。我见过太多人把爬来的语料直接丢进去训练结果模型学到一堆胡说八道的格式这叫“垃圾进垃圾出”。4.3 评测指标怎么知道你做的AI到底行不行不做评测的AI工程就是自我感觉良好。评测体系要分两层离线评测和在线评测。离线评测在开发阶段用针对任务类型选择合适的指标。文本分类用准确率、精确率、召回率、F1检索用召回率、MRR、NDCG生成任务用BLEU、ROUGE但这些指标对生成质量的衡量其实很有限需要人工抽样评估。在线评测在部署后用核心指标是预测分布监控和人工反馈收集。我通常会每天抽样100条预测结果扔到群里让业务同事打分然后统计“可接受比例”和“错误类型分布”。一个原则评测指标要和业务目标对齐。如果你的业务目标是减少漏判违规评论那你要看的就是“审核漏过率”而不是“准确率”。准确率高不等于业务效果好因为类别不平衡时大部分预测正确可能只是“全预测成多数类”而已。4.4 持续迭代让AI系统越用越准的闭环机制AI系统的价值在于迭代。我维护的项目都有一个固定的迭代节奏每周固定时间从线上日志抽取预测置信度中低区间的样本让业务人员标注标注结果进入新一批训练数据每个月用新数据微调或重新训练一版模型A/B测试新模型与线上模型的效果对比业务核心指标通过后平滑上线并持续监控。这套机制听起来简单坚持做下去的人没几个。多数团队的模型上线后就没人管了效果衰减被当成“AI本来就不靠谱”。实际上它会衰减是正常的你需要的是建立一套让它不断变好的机制而不是指望一次训练就一劳永逸。5. 常见问题与避坑指南两年里踩过的真实深坑5.1 显存不够不全是失败信号“CUDA out of memory”是新手最常见的报错之一。很多人一看到这个报错就以为要换更大的GPU其实很多时候只是你的代码写法有问题。排查顺序有三个第一确认模型真的转移到GPU上了用print(next(model.parameters()).device)看输出第二确认数据加载到设备上inputs {k: v.to(device) for k, v in inputs.items()}第三减少batch size直到能跑起来如果256个样本只占4条就能跑问题就不在显存本身。另一个我以前经常忽略的测试阶段也要记得开torch.no_grad()否则会额外计算梯度显存峰值轻松翻倍。5.2 数据不平衡别直接拿原始数据开训做分类任务时如果正负样本比例是9比1直接训练出来的模型大概率会“全军覆没”式地预测多数类。这个问题我遇到过太多次。解决办法优先级我按见效程度排换评估指标不要看准确率改成看F1或AUC先承认问题存在再解决给少数类加权PyTorch的CrossEntropyLoss可以直接传weight参数用类别频率的反比加权过采样少数类或欠采样多数类简单有效但注意不要造成重复样本过拟合数据增强对少数类做同义替换、随机删除等操作增加多样性。5.3 训练效果好但线上效果差数据分布不一致这个坑极具迷惑性我的亲身体会是模型在测试集上F1达到0.9上线后效果却差得离谱。后来排查发现测试集是我从总数据里随机切出来的但我清洗数据时做了一件错事用了全局的统计信息做归一化测试集的信息被“泄漏”到了训练过程。正确的做法是先切分数据集再在训练集上计算统计信息应用到验证集和测试集。另一个常见原因是训练数据来源和真实用户数据存在分布差异。比如训练数据是爬来的历史数据比较规范真实用户输入是图片带OCR、语音转文字夹杂口头语噪声多。所以生产环境一定要做预测分布监控发现偏差再回流数据训练。5.4 工具链的坑三个容易踩的细节依赖版本地狱transformers和tokenizers版本不匹配时加载模型经常报错。解决方法是锁版本号我在requirements.txt里精确到小版本并用Docker固定环境。模型权重文件损坏下载中断导致的权重文件损坏会让你加载时报一个莫名其妙的shape错误。重新下载时校验文件大小和SHA256不要重复使用损坏文件。训练不收敛loss从一开始就不下降先别调学习率检查数据是否预处理错误比如文本是否全部变成了空字符串、标签是否越界。从零到一我的最终体会两年走下来我对“ai-engineering-from-scratch”最大的感悟是这条路不是用来炫技的而是用来建立“不慌”的能力。当业务上遇到AI需求时不慌是因为我知道每一步怎么排查、怎么做、要花多少资源当模型效果不好时不慌是因为我知道有问题就按数据、训练、评测、部署四条线去定位。最后分享一个小建议不要列一个宏大的计划再开始选一个特别小的任务用一个月做完它。做完之后你会发现自己已经站在一个完全不同的层次上之前看不懂的资料、听不懂的讨论突然都变得清晰了。剩下的路就是顺着项目需求一步步往前滚。