收到一个很有意思的项目命名ai-engineering-from-scratch。直译过来是从零开始做AI工程。这个名字不花哨但分量很重——它不是让你去调别人的现成接口而是要求你把AI落地的完整链路亲手走一遍数据怎么处理、模型怎么训、怎么评估、怎么上线、线上出了问题怎么排查。这两年想进AI领域的人太多了。我身边有刚毕业的校招生有写了好几年后端准备转方向的老同事也有做数据分析想更进一步的同行。大家普遍卡在同一个点上资料囤了一大堆道理都懂了可真拿到一个需求时不知道第一步该干什么。这篇文章把我自己趟出来的路径完整讲一遍适合打算系统性入行AI工程的人也适合已经在做但想回头补短板的人。说明一下我默认你有基础编码能力但不需要机器学习和深度学习背景。文中涉及的数学概念我会尽量用大白话解释你暂时不求甚解也能跟着做一遍但长期来看前面的基础课还是得自己补上后面我会讲到补到什么时候算够。1. AI工程的核心范围六个环节一次拆透1.1 会调接口和会做工程差的不只是一个API很多人把AI工程理解成会调大模型接口。拿个API key拼一段prompt把返回结果贴给用户就完事了。这种体验离真实工程差着十万八千里——调API是消费一个成熟产品做工程是生产一个产品。我习惯用一个类比调API像点外卖AI工程像开餐厅。点外卖你只关心好不好吃、送得快不快开餐厅你得处理供应链、后厨排班、口味标准化、食客差评怎么复盘出餐高峰期怎么保证不崩。数据的上下游、模型服务、评估反馈、运维监控这些全部要管。真实项目里模型的训练或者调用往往是整个链条里最轻松的一环。真正吞噬时间的是业务需求说不清楚数据又脏又乱效果没法定量评估上线之后bad case源源不断冒出来。这些都是工程问题不是算法问题。换句话说AI工程的核心是一种把不确定性慢慢磨成确定性的能力。1.2 AI工程链路六段每一段都不能跳过我把自己做过的项目抽象成一条六段链路也正好构成了ai-engineering-from-scratch的主线需求定义把业务问题翻译成技术问题。老板说提高客服效率你要翻译成工单自动分类准确率达到多少、人工复核率降到多少。数据工程采集、清洗、标注、切分。这是决定模型上限的地方也是大多数人最忽视的地方。模型开发选基座模型、做提示工程、微调、蒸馏产出候选模型。评估与调优离线指标评测、bad case分析、反复迭代直到达标。部署上线服务化封装、推理优化、成本控制、灰度放量。监控迭代线上指标、数据漂移、效果衰减、按需重新训练。这六段不是线性走完就收工而是螺旋式循环。网上大部分教程只讲第3段所以很多人学完才发现只看到了冰山一角。而from scratch的深层含义就是让你从头到尾把六段都经历一遍。每一段都亲手做过后面不管接手什么项目心里都会有张完整地图不会被某个环节的意外卡死。1.3 为什么坚持从零开始三点理由和一条边界有同学问过我现在工具那么多跑通一个demo不就行了何必从底层开始我的观点是工具能让你飞起来也能让你摔得很惨。你完全不懂内部机制时出了问题只能到处碰运气。从零开始学有三个实实在在的好处。第一不容易被某个平台锁定。今天用这家的向量库明天换那家的模型底层逻辑如果你清楚迁移成本很低。第二排查问题能一路追到底层。线上效果突然暴跌到底是数据变了、模型被回滚了、还是推理环境的依赖出了问题这些都得靠底层理解来定位。第三面试和协作时能讲清楚为什么。只讲得出我调了这个参数所以好了的人和能讲出这个参数影响了什么机制的人在同一个团队里干两个月差距会非常明显。当然要说明一点边界from scratch不是让你从手写反向传播开始。我的建议是学原理但不必重复造轮子。自己动手实现过一个小规模训练循环、一条RAG流程理解就到位了没必要连优化器都自己重写。把精力花在真正影响项目成败的地方才是一个工程人该有的判断。2. 从零开始的技能地图按工程优先级排学习顺序2.1 数学学到什么程度够读懂训练日志就够一听到数学很多人先慌了。其实AI工程需要的数学比想象中少得多也具体得多。线性代数核心是向量、矩阵、矩阵乘法。神经网络本质上就是一堆矩阵运算理解shape怎么变换很多报错一眼就能定位。你不需要独立推导奇异值分解但至少得知道两个矩阵能不能相乘、乘出来是几维。概率统计核心是条件概率、分布、期望和方差。分类任务的输出就是一个概率分布评估指标里的精确率和召回率也是概率视角。微积分核心是导数、链式法则、梯度。梯度下降是训练一切模型的引擎你不需要手算复杂导数但要知道学习率为什么存在、梯度到底指向哪里。我的结论是能达到看懂训练日志、理解框架文档里的公式的程度就够用了。学习顺序建议看3Blue1Brown的线性代数和微积分系列动画配合一本入门书每天半小时两个月基本够用。别一上来就啃大部头那只会把兴趣磨光。等真遇到需要更深入数学的场景你自然会有动力回头补。2.2 编程与工程工具最低门槛要过这几关AI工程首先是工程编程能力是地基。这里说的不只是会写脚本而是要有能力维护一套持续演进的代码。Python功底要扎实到装饰器、生成器、上下文管理器能看懂会写类型注解知道什么时候该拆模块。然后Git得熟练一个人做项目也需要版本回退和分支管理。再就是Linux命令和Shell脚本至少要能独立操作一台不带界面的服务器——AI任务通常要跑GPU机器而GPU机器绝大多数是Linux。Docker我建议尽早学。它解决的核心问题是环境一致性把代码和依赖一起打包成镜像在任何机器上跑结果都一样。本地跑得好好的上服务器就跑不起来大概率是环境问题Docker基本能填平这个坑。实操上有个小技巧建一个自己的项目模板包含requirements.txt、Dockerfile、README和config目录每开新项目直接抄模板改。这个习惯帮我省了大量时间。2.3 机器学习和深度学习动手跑通一个小模型再谈其他在碰大模型之前先把经典机器学习的基本盘打牢。不是让你当算法研究员而是至少要理解这些术语背后的场景训练集、验证集、测试集为什么必须分开过拟合是什么现象精确率、召回率、F1、AUC各在什么时候用类别不均衡会对指标造成什么影响。深度学习这块核心概念包括层是什么、激活函数为什么存在、损失函数在衡量什么、优化器大概在做什么、batch size和epoch对训练的影响。然后上手PyTorch训练一个最经典的模型比如手写数字识别把训练曲线画出来亲眼看一次过拟合长什么样。我实测下来这一步的价值比读十篇文章都大。你亲自经历过loss下降又反弹、验证准确率停在某个值上不去后面看大模型训练的各种日志才不会慌。这个阶段完成后你就有最基本的模型判断力效果不好时能分辨是欠拟合还是过拟合是学习率问题还是数据问题。这个能力在后面非常值钱。2.4 大模型新增技能提示、RAG、微调与评估经典基础打完后就是当下最热的大模型工程技能。这块变化很快但有几条主线是稳定的。提示工程理解 system、few-shot、思想链这些基本手法核心是知道怎么把任务描述清楚、怎么给示例。提示词不用玩得花里胡哨先掌握可复用的模板化写法。检索增强生成RAG要理解离线切块、embedding入库、在线检索、把检索结果和问题一起喂给模型的完整链路。关键点在于切块策略、embedding选型、检索结果怎么排序以及怎么单独评估检索环节的质量。微调Fine-tuning至少要会用LoRA这类参数高效微调。要懂训练数据的组织格式、超参怎么设、微调后会不会破坏通用能力。我建议先在小数据集上把流程跑通再上规模。大模型评估则是最容易被忽略的一块怎么构建黄金测试集怎么用规则、语义相似度或另一个模型来打分怎么人工抽检。不做评估的AI项目都是空中楼阁后面我会专门展开。还有一个被低估的能力推理成本意识。同样的效果小模型加提示工程能解决就不要上大模型能批量处理就不要在线逐条调用。这些都是落地时实打实的价值。3. 完整实操流程把一个AI项目从需求跑到上线理论说再多不如完整走一遍。我拿一个非常经典的场景——客服工单自动分类来演示。这个场景门槛低、效果可量化、业务价值明显特别适合作为from scratch练习的载体。3.1 先把要什么翻译成技术指标拿到需求的第一件事不是选模型而是和业务方把目标对齐。我每次都会追着问三个问题。输入是什么工单的标题、正文还是附带截图只有文本还是有结构化字段输出是什么要分到预设的几十个类别还是要抽取关键信息还是要生成自动回复成功标准是什么准确率多高算达标愿意接受多少人工复核处理速度要求是多少最容易踩的坑是什么都想要。我见过一个项目既要分类、又要抽取、还要生成回复结果模型很臃肿每项都一般。正确做法是先定一个最小可行版本首期只做分类把链路跑通后面再加能力。同时一定要把成功标准量化并写进文档。否则每次迭代业务方都可能凭感觉说好像好了一点或好像没变化项目就没办法推进了。3.2 数据准备这里吃掉60%的工期这个环节通常要花掉我60%的时间。不是因为它难而是因为琐碎且每一步错误都会传导到后面。第一步采集与探查先写脚本做统计看总量、类别分布、文本长度分布、空值和缺失情况。类别如果严重不均衡比如90%都是咨询类那评估指标就不能只看准确率否则你把所有样本都判成咨询准确率也有90%。第二步清洗工单数据里常见的脏东西包括HTML标签、全角半角不统一、重复工单、隐私信息需要脱敏。清洗规则要逐条验证并保留清洗前后的对照日志。第三步标注如果没有现成标签就制定标注规范。两个标注员对同一批数据的一致性很重要一致性低说明任务定义本身不清晰。第四步划分数据集训练、验证、测试按比例切分。注意数据泄漏是评估虚高最常见的原因。如果数据带有时间属性不能随机切分要按时间切分重复或高度相似的样本不能同时出现在训练集和测试集里。否则离线指标会严重失实上线立刻打回原形。3.3 基线、选型与微调一次讲清判断逻辑选模型之前先做一个最简单的基线。比如标题里出现某关键词就归到对应类别的手写规则或者一个词频加逻辑回归。基线的意义是给后面所有复杂模型一个对比锚点如果大模型只比规则高两个点你要仔细掂量值不值得上。基线上来之后再决定用哪个方案。我通常对着这个判断框架选型方案适用场景典型成本效果上限规则/关键词类别少、区分度高极低中等传统机器学习数据几千到几万条、特征明确低中等偏上模型微调数据充足、任务边界清晰中高大模型提示工程类别多变、冷启动快按调用量计高RAG需要引用外部知识中高高没有绝对最优的方案只有当下最合适的。如果调用大模型接口的成本可控提示工程和RAG是冷启动最快的路径如果要求毫秒级响应、数据要私有化那微调一个本地小模型更合适。实际走微调路线时我建议先用小规模数据验证流程。以LoRA为例常用的起始配置长这样# LoRA 微调起始配置以 PEFT 库为例 peft_config { r: 8, # 秩越大容量越高过拟合风险也越高 lora_alpha: 16, # 缩放系数和 r 配合调节 target_modules: [q_proj, v_proj], # 只作用部分注意力层 learning_rate: 1e-4, batch_size: 8, epochs: 3, warmup_ratio: 0.1, weight_decay: 0.01, }训练时重点盯两条曲线训练损失和验证指标。训练损失降得很快但验证指标不涨是过拟合信号两个都不动先检查学习率和数据再看loss有没有数值异常。这个判断套路那个阶段都一样。3.4 评估体系没有评分就没有迭代评估是AI工程和AI玩具最大的分水岭。玩具只看跑通没工程要看多好多稳。离线评估的核心是黄金测试集从真实数据里留出一批标注充分的样本任何模型上线前都要在这批样本上评分。分类任务不能只看总体准确率还要看每个类别的精确率和召回率尤其是样本少的类别。光看总体指标你完全发现不了某些类别一个都没分对。比指标更重要的是bad case分析。我每轮迭代都会随机抽100个错误样本逐个看到底错在哪是标注错了还是类别定义模糊还是文本里出现了训练时没见过的写法。很多时候答案不是换模型而是补数据或者修清洗规则。我印象最深的一次客服数据里退款和退货两个类别定义重叠人工标注都经常分不清。后来跟业务方重新划清定义准确率直接涨了十几个点跟模型一毛钱关系都没有。大模型场景下评估更麻烦生成结果没有标准答案。我的做法是先定义维度比如信息完整度、准确性、格式合规再构建评分prompt让一个表现稳定的模型当评委同时定期人工抽检做对齐。要记住机器评分和人工评分的一致性需要持续验证否则自动评估会变成一个自欺欺人的摆设。3.5 部署、监控与迭代上线才是真正的开始模型训完只是中场部署上线后才会暴露真正的工程问题。服务化封装最简单是FastAPI包一个推理接口。但一个关键点是不能每次请求都现场加载模型要启动时预加载大模型推理不能同步硬扛要做排队或异步处理。上线初期建议只放内部流量灰度再放全量。推理优化方面如果延迟超标除了换小模型还可以做量化把模型参数从FP16压到INT8可以做批处理把多个请求攒一起推理还可以加缓存相同或相似的请求直接返回历史结果。我实测过量化在多数任务上能提速2到4倍效果损失往往可以接受。监控至少要看三个层面。服务层面看响应时间、错误率、并发数据层面看输入分布有没有变化比如用户话术突然换了风格效果层面做抽检或看线上指标比如人工复核率。监控的目的不只是有事报警更是让你能及时发现模型何时开始失效。迭代上每次模型更新都要记录训练数据版本、代码版本、配置版本这样线上出问题能快速回滚——这是工程底线不是可选项。4. 高频问题与排查经验这些坑我替你踩过了4.1 模型效果差先查数据再查训练效果不好是常态真正的问题是很多人一上来就换更大的模型完全跳过了排查。我给自己定了一条铁律先质疑数据再质疑模型。排查顺序固定如下先查数据。标注对不对类别定义清不清楚有没有脏数据有没有数据泄漏数据问题通常占bad case的一半以上。再查评估方式。测试集是从真实分布抽出来的吗指标选对了吗是不是样本不均衡导致指标虚高然后查训练过程。是欠拟合训练集上也很差还是过拟合训练集好、测试集差batch size和学习率有没有问题最后才考虑换模型架构或者加数据。这条顺序我踩过无数次。最蠢的一次我花了一周微调一个模型效果始终不达标最后发现是上次清理数据时不小心把标签和文本错位了。那一周的时间完全白费。从那以后每次训练前我都会抽20条样本人工核对一遍数据对齐情况这个习惯帮我挡掉了大量低级事故。4.2 训练崩溃三件套OOM、NaN和不收敛训练阶段最常见的三类问题我放到一起说。显存溢出也就是CUDA Out of Memory。处理方法按优先级排序调小batch size、开梯度累积、用混合精度、必要时开梯度检查点。有个容易被忽略的事实不只模型参数占显存中间激活值也占所以batch size减半往往立竿见影。loss不降或者出现NaN。先看学习率是不是过大大模型微调的学习率一般不要超过2e-4再看数据里有没有NaN或无穷值再加梯度裁剪默认设1.0能挡住大多数训练发散。模型不收敛。先确认损失函数选对了分类任务用交叉熵而不是MSE再确认标签和数据是对齐的最后把学习率拉回一个合理范围。注意小批量下loss波动是正常的别因为曲线跳来跳去就乱调参。我见过有人隔几分钟改一次学习率最后整个训练完全失控。4.3 从原型到生产落差在哪里怎么补在Jupyter里跑通一个流程和把模型丢进生产环境中间隔了好几座山。首先是延迟和吞吐。原型阶段没人管推理耗时生产环境你得在几百毫秒内返回还得扛住并发。解决办法通常是换小模型、量化、批量推理、加缓存。我处理过一个文本分类服务在GPU上推理只要2毫秒在CPU上大概40毫秒按业务量完全够用最后整个服务直接跑CPU成本省了一大截。其次是降级方案。任何AI服务都可能挂要提前设计兜底模型服务挂了就返回规则结果规则也挂了就返回默认模板。用户拿到稍差的结果好过服务直接报错。第三是输入输出约束。用户输入任何文本你都要做长度截断和格式校验模型输出要加schema约束和后处理。大模型输出尤其要小心可能带格式、带偏见、甚至带幻觉上线前必须设计好护栏逻辑。4.4 工程规范个人项目也要有纪律一个人干活可以随意但只要涉及长期维护规范就是生产力。实验追踪每次训练都要记录数据版本、模型版本、超参、指标结果。用MLflow这类工具也好用Excel也好关键是可复现。两个月后有人问你上次那个87.5%的模型是怎么训出来的如果翻不出记录等于白干。代码评审即使是小团队也建议走review。很多坑当时发现不了过几周回看才会暴露。模型代码的坑特别隐蔽一个数据预处理函数在不同脚本里版本不一致就能让你白跑两天实验。文档方面项目背景、成功标准、数据schema、模型卡包括训练数据、适用场景、已知局限都应该写。写文档不是给领导看是给三个月后的自己看。我吃过太多这代码当时明明能用的亏后来才意识到不是我记忆差是我根本没留记录。5. 三条实操体会写在项目最后这个项目做到现在我最想留下的不是技术清单而是三条朴素的经验。第一条数据永远值得花最多时间。模型迭代快数据迭代慢。你花一周整理出来的干净数据会让后面每一次实验都受益而你花一周调出来的参数换一批数据可能就失效了。第二条先做端到端最小闭环再做优化。不要一开始就想着把系统做到完美先把一个请求进来经过处理返回结果的完整链路跑通哪怕用的是最简单的规则。闭环通了之后再逐个环节升级。没有闭环之前所有优化都是空中楼阁因为你根本不知道瓶颈在哪。第三条实验记录是你最重要的资产。凭感觉调参调好了不知道为什么好调坏了也不知道为什么坏这是新手最大的浪费。养成随手记录的习惯之后你的进步速度会明显不一样。ai-engineering-from-scratch这个项目名字一直没改但它承载的内容从一开始的我要学会AI慢慢变成了我要搭建一个可靠、可迭代、可解释的AI系统。如果这篇文章能帮你少走一小段弯路我就觉得很值了。说到底AI工程的核心不是追新而是把每一件朴素的小事做到位。