★ FEATURED ARTICLE 1. 从一个GitHub仓库名字说起“ai-engineering-from-scratch”单看这个名字有点像那种烂大街的“XX从入门到放弃”系列。但真正点进去你会发现它压根不是教程更像是一份“AI工程师的成长地图”——从底层原理到工程落地从数学基础到系统设计几乎把AI工程化这条路上要踩的坑、要补的课全列了一遍。我先说结论如果你想入行AI工程或者已经在做相关开发但总觉得知识体系零散这个仓库值得你花一个周末认真过一遍。它不是给你现成的代码抄而是告诉你“该往哪个方向使劲”“为什么这个方向重要”。我自己最初看到这个标题时以为是又一份“PythonTensorFlow入门笔记”。实际翻完目录才发现它覆盖的范围比我预想的大得多——从线性代数、概率论这些数学地基到Transformer架构、分布式训练、模型部署、MLOps甚至包括GPU编程和推理优化。这是一条完整的AI工程师能力链路。这篇文章我就以“从零构建AI工程能力”为主线把这份仓库里最有价值的内容拆开揉碎结合我自己的实践经验和踩坑记录聊聊一名合格的AI工程师到底需要掌握什么以及每一块能力在实际工作中是怎么用的。1.1 这个仓库到底解决什么问题市面上讲AI的资料多如牛毛但绝大多数走两个极端一是纯理论从反向传播推导到注意力机制数学公式铺满屏幕看完还是不会用二是纯调包调一下transformers、调一下LangChain能跑通demo就觉得自己会了AI。“ai-engineering-from-scratch”想解决的就是这两者之间的断层——它试图建立一座桥让理论能落成工程让工程能回溯到理论。仓库里的内容组织方式很有意思不是按“深度学习”“机器学习”这种教科书式分类而是按“一个AI工程师实际工作流”来组织。也就是说它关注的是拿到一个业务问题你怎么把它定义成AI问题怎么选方案怎么训练模型怎么部署上线怎么维护迭代。这个视角和大学课程完全不同更贴近真实研发环境。而且它的标题里那个“from-scratch”很关键。这不是说所有代码都要从零手写而是强调“理解底层”。比如你用PyTorch写的每一行代码背后对应什么张量运算、什么梯度流向这些如果心里没数出了问题就完全无从排查。我一直认为AI工程和传统软件开发最大的区别就是调试的难度维度完全不同——传统开发调试的是逻辑AI开发调试的是“统计行为”。2. 数学基础不是让你推导一切而是让你“有感觉”仓库第一部分就是数学基础线性代数、概率论、最优化。很多科班出身的人看到这里会觉得“这不就是大一的课吗”但非科班转行的同学往往在这块栽跟头。我见过不少同事调模型一把好手但遇到要自定义损失函数、要改训练策略时就抓瞎根源就是数学直觉不够。2.1 线性代数一切深度学习的“语法”深度学习里处处是矩阵运算。一个batch的输入是张量权重是矩阵前向传播本质就是一系列矩阵乘法。如果你对矩阵乘法的维度变换没有感觉看到(batch_size, seq_len, hidden_size)这种形状就头大那别说改模型了连debug都会要命。我自己的经验是线性代数不需要你掌握所有定理证明但有几样东西必须有直觉矩阵乘法的几何意义——它是线性变换的组合理解了这一点你就会明白为什么深层网络能表达更复杂的函数。特征值和奇异值——在模型压缩、谱归一化这些场景里概念是绕不开的。范数的含义——L1、L2范数不只是正则化公式它们的不同几何性质决定了正则化的行为差异。我还记得第一次手写反向传播时对着三层网络的链式法则推导了一下午。虽然现在用自动微分框架根本不需要手动算梯度但那次推导让我真正理解了“梯度累积”和“梯度消失”的成因后面调学习率、改初始化方案时心里就特别有底。2.2 概率与统计模型不确定性的一切源头机器学习本质上是概率建模——我们用数据估计分布用损失函数衡量分布之间的差距。这里我强烈建议重点理解三件事极大似然估计、贝叶斯思维、概率分布族。极大似然是深度学习的“元思想”。你训练分类模型时用的交叉熵损失本质就是负的对数似然回归任务里的MSE隐含的假设是高斯噪声。理解了这一层你就不会被“各种花哨的损失函数”迷惑因为它们的底层逻辑是相通的。贝叶斯思维是理解正则化、dropout、数据增强这些“玄学操作”的钥匙。它们本质都是在引入先验让模型不过度自信于训练数据的表象。概率分布族这块至少要看得懂高斯分布、伯努利分布、类别分布之间的区别。做生成模型时你会频繁接触分布之间的度量比如KL散度、JS散度不理解这些VAE和GAN的核心逻辑永远隔着一层纱。2.3 最优化训练过程背后的“方向盘”SGD、Momentum、Adam这些优化器名字大家都听过但它们的区别到底是什么、什么时候该换优化器很多人其实没细想。我当初也是直接无脑用Adam直到有一次模型收敛特别慢换成SGDmomentum之后好了很多才真正意识到优化器的选择是有讲究的。Adam的自适应学习率让它很“省心”适合大多数情况但在某些需要精细调优的CV任务上SGD配warmup和momentum往往能达到更好的泛化效果。后来我去看了一下Adam原论文理解了它对每个参数单独调整学习率的机制也明白了为什么它对学习率不敏感、为什么在某些问题上不如SGD收敛得好。这些看起来“理论”的内容在真实项目中就是你能不能被称作“工程师”的分水岭。调包谁都会但问题出现时你是只能换参数瞎试还是能通过原理定位问题方向这是两个段位。3. 从单机训练到工程化一个模型要走上生产远不止训练那么简单接下来这层是仓库里最有含金量的部分。大多数人从“跑通一个Notebook”到“上线一个服务”之间横着一道巨大的鸿沟。训练一个能跑的模型最多算完成了20%的工作剩下80%是工程活。3.1 数据管线的搭建与治理真实业务里的数据绝不会像MNIST那样干净整洁。我在第一个工业项目里就吃了大亏——数据来自多个上游系统字段缺失、单位混乱、时间戳不一致几乎什么都没干光清洗数据就花了两周。这里有几条血泪经验数据验证一定要自动化。别靠人肉看CSV写一个pydantic或Great Expectations的校验层字段类型、取值范围、唯一性全部用代码卡死。训练集和离线评估集的切分要谨慎。时序数据绝对不能随机切必须按时间切否则就是典型的数据泄漏。线上和离线的特征逻辑要保持完全一致。很多团队“离线效果好、线上效果差”的根因就是这两套代码不一致一个用了log1p另一个忘了。仓库里也提到了数据版本管理这个观念在国内团队里还是偏弱。数据这种东西是模型行为的输入数据变了模型就变了。像DVC这类工具能把数据和代码放在同一套版本控制体系下一旦线上效果回退你至少能精确复现“当时用的是哪份数据”。3.2 模型训练从单卡到多卡的关键跨越训练单卡模型和分布式训练完全是两个世界。你如果只在单卡上训练过第一次做多卡训练时大概率会遇到显存溢出、通信瓶颈、梯度同步出错等一系列问题。分布式训练的三种模式做AI工程必须心里有数数据并行每张卡拿一个batch的切片各自前向反向通过梯度同步来更新同一份参数。最常见但通信开销随卡数增长明显。模型并行把模型的不同层放到不同卡上适合超大模型放不进单卡显存的场景。张量并行把单层内的张量运算拆分到多卡框架内部自动完成通信适合超大规模Transformer。我自己第一次跑多卡训练用的是PyTorch的DataParallel感觉很顺手。但后来一上大模型就发现DP的主卡通信瓶颈严重换成DistributedDataParallel之后训练速度提升肉眼可见。后来搞懂了DDP在启动时会做一次模型广播后续各个进程独立计算梯度再通过Ring-AllReduce做梯度同步才算真正理解了里面在发生什么。仓库里还特别提到混合精度训练这个在实际工程里是常态了。FP16让显存占用减半、训练速度翻倍但精度溢出问题非常隐蔽。如果你发现Loss出现NaN第一个检查点就应该是精度溢出然后果断换成BF16或者加入Loss Scaling。这里我想特别强调——很多新人对AMP的理解只停留在“开一个开关”实际上它涉及精度比例因子、梯度裁剪时机等一堆细节建议去看一下Apex的源码实现。3.3 模型评估不能只看一个指标很多人在项目里只看AUC或者准确率这在业务场景里往往不够。我自己的习惯是建一张评估清单至少包含分阈值敏感度分析换不同阈值看精确率和召回率的变化曲线。样本切片分析按用户群、按时段、按品类分别看效果全局指标好看不代表每个切片都好。置信度校准分析模型给出的概率是否有参考意义在风控、医疗这种高决策成本场景里尤其重要。仓库里有一套“评估不该混淆的几件事”的说法我觉得非常有启发——模型泛化能力、数据质量、业务效果是三个层面的问题。你线上效果不好不一定是模型不行可能是数据分布变了也可能是业务规则本身有问题。切分清楚是哪个层面的问题才能找到正确的解法。3.4 部署与推理优化最后一公里的性能冲刺模型训练完了不等于事情结束了。部署阶段才是让模型真正产生价值的环节也是工程血泪最多的地方。推理优化是我近年来关注最多的方向它跟训练优化是完全不同的技术栈。训练关注吞吐推理更关注延迟训练吃到饱和显存是好事推理则希望单样本延迟越低越好。常用的推理优化手段仓库里基本都提到了模型量化把FP32/FP16的权重压缩成INT8甚至INT4。精度损失可以通过校准集来缓解。我实测在GPT类模型上INT8量化后精度损失控制在0.5%以内但速度提升接近2倍。剪枝与蒸馏大模型蒸馏成小模型适合对延迟要求高的场景。批量推理优化用动态batching把多个请求聚合成一个batch提高GPU利用率。缓存机制当用户输入和请求存在大量重复时对中间结果做缓存。我做过一个相似度检索系统加了缓存后P99延迟从80ms降到了15ms。推理引擎的选择方面NVIDIA的TensorRT在GPU上几乎是最优的。但我特别提醒一句TensorRT的图优化对动态shape支持不算好如果你的输入形状变化很大优化效果会打折扣。工程上比较稳的方案是先做ONNX导出再用TensorRT做FP16/INT8的Engine构建最后通过Triton Inference Server做服务化。4. MLOps与大模型单独聊聊这两个绕不开的话题仓库里专门将MLOps列为一部分这个在国内工程团队里的重视程度这两年才算上来。另外2023年以来大模型横扫一切仓库也同步加入了LLM推理、微调这些内容。这两块我想展开聊一聊。4.1 MLOps把“炼丹”变成“工程流水线”如果你的团队还在用“一个人跑实验-手动记录结果-手动部署”的方式做AI那规模一大你一定扛不住。MLOps的核心是让整个AI开发流程具备软件工程的标准可复现、可追踪、可回滚。我目前项目里的标准配置是这么一套组合流水线编排用Airflow或Argo把数据清洗、特征工程、训练、评估、部署串成一个可编排的流水线。哪个环节出错能立刻定位也支持回跑。实验跟踪用MLflow或Weights Biases每一次训练的代码版本、数据版本、超参数、评估指标都会自动记录。这一点帮我解决过一个大问题——有一次线上效果变差了翻实验记录发现就是数据里某个字段的清洗逻辑改了导致分布偏移。如果没有实验跟踪这种问题基本不可能定位。模型注册与版本管理每个模型带元信息进注册中心上线时指明确切的模型版本。我见过因为“乱上线”导致的事故——一个同事直接覆盖了线上模型文件没有意识到客户端还在用旧协议调用结果全线报错。有了模型注册表至少能锁住版本。还有一点值得强调MLOps不是买一套工具就完事它是流程文化的建设。小团队可以只用GitWeightsBiases一个简单的部署脚本只要能满足“追溯和回滚”这两个底线就是有效的最小MLOps。4.2 大模型的工程化挑战推理成本是第一道关大模型时代AI工程的核心挑战从“怎么训”变成了“怎么用得起”。一个70B参数的模型如果直接用FP32推理光权重就要280GB显存A100 80G也得4张卡才塞得下。做一次前向推理电费和卡组成本都相当可观。仓库里对大模型工程化的建议我挑几条实操性最强的第一尽量小模型解决问题。不是所有任务都需要大模型。一个意图分类任务用BERT级别的小模型微调延迟低、成本低、可控性强。大模型适合开放域生成和复杂推理但把它用在一个简单分类上是严重的资源浪费。第二微调优于从头训练。我自己第一次接触大模型时也动过“自己去训练一个”的念头后来发现数据、算力、时间三项全不现实。成熟的路径是基座模型LoRA或QLoRA微调。LoRA用低秩矩阵近似权重更新可训练参数量只有原模型的0.1%到1%在单张消费级显卡上就能完成微调性价比极高。第三Prompt工程和上下文工程的投入产出比极高。在很多场景里不微调模型只优化Prompt结构就能显著提升效果。把Few-shot示例选好、把Instructions写清楚、把输出格式约束好效果往往立竿见影。很多团队一上来就微调成本高效果还不稳定反而先做Prompt调优性价比高。第四RAG是现阶段最务实的大模型落地范式。让模型接入你的私有知识库用检索结果作为上下文可以在不微调的情况下让模型“知道”你的领域知识。这中间涉及向量化、检索排序、上下文裁剪和引用溯源等一堆工程细节我自己在这块踩过的坑是最多的——不是检索结果太相关导致上下文太长就是向量化模型选得太差召回率很低。后面我把文本切块的策略改成了按语义边界切分再用混合检索BM25向量召回做两路召回效果才稳定下来。4.3 Agent与AI应用的未来方向仓库里还涉及了一些Agent方向的探索。当前阶段的Agent本质上是大模型工具调用规划能力。模型决定“下一步干什么”工具负责“执行具体动作”整个循环靠一个控制逻辑来驱动。这块的工程挑战在于可靠性和可观测性。Agent跑一次可能要调用多个工具、经历多轮循环任何一个环节出错都可能让整个任务偏离预期。我现在做Agent系统时最看重的是每一步都有结构化日志能把工具参数、模型输出、决策原因记录下来。预留人工干预接口高风险动作一定要有确认环节。给Agent设“退出条件”防止它在错误决策上无限循环烧掉大量token。这些经验看起来不那么“AI”但决定了一个Agent系统能不能从demo走进生产。5. 常见问题与排查技巧实录这一节我把自己踩过且身边人频繁踩的坑统一列出来做成一份速查表希望你能少走弯路。5.1 训练Loss变成NaN十有八九是数值溢出。排查顺序建议是先看学习率是不是过大再看是否用了FP16但没加Loss Scaling最后看数据里有没有NaN或无穷值。我自己之前遇到过一种隐蔽情况Adam的二阶动量极端小的时候更新步长计算会得到一个很大的值导致梯度爆炸。后来用了梯度裁剪和更小的学习率才稳住。5.2 离线评估效果好线上效果差优先怀疑特征不一致。离线代码里用了未来信息或者线上少做了一个字段的归一化都是常见根源。建议做一次“特征一致性审计”把离线管线的输入和线上抓到的真实请求拿去对比逐一字段核对。5.3 推理延迟高得离谱从这几个维度排查模型是否做了量化、请求是否聚合了batch、缓存命中率如何、CPU/GPU切换是否频繁。我见过一个很极端的例子同事把模型部署在GPU但预处理逻辑写在CPU上而且每次请求都重新加载一次模型权重。延迟高到爆炸。整个排查下来的根因非常简单工程上最重要的往往是这些“不起眼”的细节。5.4 微调大模型效果不升反降这种情况我觉得最可能的原因是学习率太大训了没几步就把基座模型学好的表征冲掉了。大模型微调学习率普遍要比训练小模型低一两个数量级LoRA通常1e-4到1e-5之间。另外数据质量比数据量更重要。我有段时间拼命加了大量低质数据效果不升反降后来清理到一小部分高质量数据效果立刻回来了。大模型微调是一个非常典型的“宁缺毋滥”场景。5.5 分布式训练GPU利用率上不去多半是数据加载跟不上。检查DataLoader的num_workers、prefetch_factor或者直接用TFRecord/LMDB做数据预读取。也可以看一眼是不是GPU间通信的耗时占比太大如果是考虑梯度累积或者梯度压缩来减少通信频次。6. 这套技能树应该按什么顺序爬上面讲了很多模块如果你是一个刚入行的人肯定想问“那我到底该从哪开始”仓库本身没有给出一条固定的学习路径但根据我自己带新人的经验我推荐下面这样的顺序第一步搞懂基础。线性代数和Python是底线。不要求数学多深但至少张量运算、矩阵形状变化要秒懂。第二步把经典模型复现一遍。用PyTorch从零手写一个简单的MLP、CNN再写一个Transformer把训练循环、反向传播、优化器这些环节亲手跑通。这个过程会让你真正体验“训练一个模型”的感觉而不是只调用现成接口。第三步做端到端的项目。找一个真实数据集自己完成数据清洗、特征工程、模型选择、训练调优、部署上线整个流程。这个过程中遇到的问题才是你成长的加速器。第四步补工程化能力。Docker、Kubernetes、CI/CD这些基础工程工具在大厂几乎是基本功。你可以试着把第三步的项目容器化用K8s部署再加一个监控面板。完成了这一步你就具备了“AI工程师”的完整能力闭环。第五步按需深入。如果做业务模型多研究特征工程和MLOps。如果做LLM应用多研究RAG、微调、Agent和推理优化。不要贪多按你当前的项目需求学习效率最高。我自己带过不少刚入行的人发现最影响成长速度的因素不是智商而是“能不能快速定位未知”。看到一个报错你是直接复制去搜还是能先用自己的知识推断“这个报错最可能来自哪个环节”后者这种能力是长期“from scratch”训练出来的。7. 一点个人的经验收尾看完“ai-engineering-from-scratch”这个仓库我最大的感受是它做的不是知识罗列而是把碎片化内容重新组装成一套能力体系。很多人在AI这条路上最焦虑的时刻是面对海量资讯不知道学什么。今天刷到一篇讲LangChain明天收藏一篇讲量化好像懂很多但又觉得什么都不会。仓库里这个“从零重建”的框架恰好就是一个应对这种信息洪水的锚点——它告诉你真正的核心能力从来不在那些热点里而在基础上、在原理里、在工程实践里。我的建议也很简单别急着追热点先把基础垒扎实。大模型的热潮还会变但AI工程师的基本功——数学直觉、工程能力、排查问题的思路——永远值钱。这条路没有捷径但也没有想象中那么长只要你走的每一步都确实是在搭下一块砖。这套知识体系里最有价值的一点我觉得是“连贯性”。你从数据理解、到模型设计、到训练调优、到部署监控每一个环节都亲自做过那你就拥有了AI项目的全局视图。一个能从全局出发看问题的人在任何团队里都不会是可替代的角色。
阅读完成 · 觉得有帮助？
