1. 为什么我从框架热转向了从零构建AI工程这两年有个很有趣的现象身边越来越多人自称AI工程师但真正被问到模型是怎么训练出来的推理时显存到底花在哪了线上效果波动怎么排查这类问题时往往只能答出调了调参、换了换prompt、加了点数据。不是说这些操作没有价值而是它们离工程两个字还有相当距离。我做ai-engineering-from-scratch这个项目的初衷其实挺朴素——我发现自己花了大量时间在各种框架、工具链和模型仓库之间来回跳今天换这个框架跑个demo明天换那个库调到能出图但一旦遇到线上真实问题比如延迟压不下来、显存爆了、效果时好时坏我依然没有一套自己的排查方法论。这个项目既不是又一个30天学会AI的速成课也不是一份工具清单式的收藏夹。它是一套从最底层原理出发、一步步亲手实现AI系统核心环节的完整路线图覆盖了从数据处理、模型训练、推理优化到评估上线的全链路工程实践。如果你是那种不亲手把轮子造一遍就心里不踏实的人或者你已经被各种框架封装搞得有点迷失想回到技术本质重新梳理一遍AI工程的知识体系这份项目应该能帮你把散落的知识点串成一张完整的网。我把这个项目当作自己的一次系统性复盘把过去几年踩过的坑、想明白的道理、以及那些早该知道的经验全部沉淀成一份可以从零一直跟到生产环境的工程实践路线。这篇文章就是对这个项目核心内容的完整梳理。2. 项目整体架构一套从底层到上层的AI工程知识体系2.1 为什么选择从零构建而不是从框架入手先聊聊我为什么坚定地选择从零开始而不是直接上手PyTorch或TensorFlow。过去两年我面试过不少候选人也带过几个新人发现一个共性现象大家用框架用得都很溜但问到反向传播到底是怎么算的Batch Normalization训练和推理时行为有什么不同梯度消失的本质原因是什么这些问题时能讲清楚的人非常少。这不怪任何人因为现代框架的封装程度实在太高了。一行loss.backward()背后是几十个OP的自动微分编排一句model.fit()背后是数据加载、混合精度、梯度累积、学习率调度一大串逻辑。框架把复杂性吞掉了同时也把理解的门槛推高了。从工程角度说不了解底层原理的代价是巨大的模型训练遇到loss震荡不知道是该调学习率还是该查数据分布只能靠试推理时GPU显存不够不知道是激活值占了空间还是权重缓存占了空间只能无脑减batch size上线前要做性能优化不知道瓶颈在数据加载、算子执行还是GPU拷贝只能靠猜所以我在这条路线里特意设计了手动实现核心组件的学习环节。不是让你以后所有项目都从零写而是让你亲手实现一次前向传播、反向传播、一个简单的Transformer Block在这个过程中把黑盒打开看清里面到底发生了什么。这种学习路径和学开车很像。你日常开车不需要懂发动机的工作原理但如果你立志做一名赛车工程师不知道内燃机怎么工作就完全没法调校赛车。AI工程也是一样框架是你的车但如果目标是做AI系统的设计者和调校者底层原理就是必须补上的功课。2.2 知识体系的层级拆解与依赖关系整个项目的知识体系分成了五个层级每一层都建立在前一层的基础之上。我最初在规划这个项目的时候一直在想用什么结构来组织内容最合理最后确定了这条依赖链第一层是数学与机器学习基石。这一层负责解决AI系统为什么能work的问题包括线性代数、概率论、最优化理论等核心数学工具以及机器学习的基本框架——损失函数、梯度下降、正则化、偏差方差权衡这些基础概念。第二层是深度学习核心原理。这一层负责解决神经网络到底是怎么学习的问题从感知机开始逐步深入到多层感知机、卷积网络、循环网络、注意力机制重点理解梯度传播、参数初始化、归一化技术这些决定训练成败的细节。第三层是手写实现与代码能力。这一层负责解决我能不能自己造出来的问题不依赖任何高级深度学习框架用基础数值计算库从零实现神经网络的核心组件包括自动求导引擎、各类网络层、优化器和完整训练流程。第四层是工程化与系统设计。这一层负责解决模型怎么跑到生产环境的问题涵盖数据管道构建、分布式训练、模型压缩、推理优化、服务化部署、监控告警这一整套MLOps实践。第五层是全链路实战落地。这一层负责解决这么多知识怎么串起来的问题以一个完整的AI应用为靶子把前面四层的知识全部串起来形成一个从数据到上线运营的闭环。这个分层的核心思想其实借鉴了计算机系统领域一个经典原则——“如果你不能构建它你就不能真正理解它”。每一层的内容都在为下一层提供认知基础同时也在用上一层的内容来检验自己的理解是否到位。2.3 项目的目标场景与适用人群我整理这个项目的时候反复问自己一个问题哪些人会真正需要这样一条从零开始的路线第一类人是刚入门但不想走弯路的AI学习者。市面上大多数课程的问题不是内容不好而是跳跃性太强。今天学CNN明天就让你用YOLO做目标检测后天让你用LangChain搭Agent。这种学习方式导致知识体系出现大量空洞前期还能靠框架机制弥补后面一旦遇到复杂问题就寸步难行。这条路线帮你把地基打牢前期看起来慢后期反而快。第二类人是有一定经验但感觉遇到瓶颈的工程师。这类人会用框架能跑通模型训练但总觉得自己的理解浮在表面。遇到性能问题不知道从哪里排查遇到训练不收敛只能反复调参靠运气。这套体系专门帮你把那些知其然不知其所以然的部分补齐。第三类人是想转型AI方向的传统软件工程师。你有扎实的工程能力和代码功底但缺少机器学习理论基础。传统软件开发的经验在AI领域有大量可以迁移的地方但也有一些需要补充的新思维方式。这条路线能帮你在AI工程领域建立完整的能力图谱而不是零散地学几个模型怎么调用。总的来说这个项目不适合两类人一类是只想快速出demo做演示的人另一类是只做纯算法研究、不关心工程落地的人。前者会觉得内容太重后者会觉得内容太偏工程。它服务的核心人群始终是想把AI系统真正做出来并跑在生产环境里的人。3. 核心环节实践亲手搭出一条AI工程链路3.1 数据处理与特征工程——被严重低估的起点说到AI工程很多人第一反应是模型结构和训练技巧但我做这个项目最大的感触是数据处理和特征工程才是真正决定项目成败的环节。我见过太多团队在模型上投入大量精力优化精度最后发现效果上不去的原因竟然是训练集和验证集的分布不一致或者数据里存在大量泄漏。在这套路线里我把数据处理拆成几个关键环节每个环节都有自己的注意点。第一个环节是数据采集方案设计。这里最核心的原则是让采集的数据尽可能覆盖真实场景的分布。比如做文本分类模型不能只收集规范化的新闻语料还要考虑到用户输入可能包含错别字、口语化表达、中英文混杂等各种情况。如果数据采集阶段就引入了偏差后面用再好的模型也纠正不回来。第二个环节是数据清洗与质量评估。很多人以为数据清洗就是去重、去空值实际上远不止这些。对于文本数据要处理编码问题、HTML标签残留、广告噪声对于图像数据要处理模糊、过曝、遮挡、标签错误。我习惯在做任何清洗操作之前先随机抽样一批数据人工查看一遍建立对数据质量的直觉这个步骤比任何自动化工具都重要。第三个环节是特征设计与数据增强策略。深度学习确实可以自动从原始数据中学习特征表示但这不代表特征工程就不重要了。在数据量有限的场景下好的特征设计能大幅降低模型的学习难度。比如时间序列预测如果你能把星期几、是否节假日、历史同期值这些先验知识作为特征喂给模型效果通常比让模型自己从纯数值序列中硬学要好得多。数据增强是另一个容易被误用的环节。图像领域常用的随机裁剪、旋转、色彩抖动文本领域的同义词替换、回译增强都要注意增强后的数据不能破坏原始语义。我曾经在一个文本分类项目里用回译做了数据增强结果把很好增强成了十分完美把一般增强成了平平常常导致模型在训练集上效果突然飙升但线上表现毫无变化——原因就是增强后的数据分布和真实分布出现了偏差。3.2 模型训练——从手动实现反向传播到轻量框架过渡训练这部分是我整个项目里篇幅最大的章节因为这里面的坑实在太多了。我先和大家分享一下我为什么坚持从零实现反向传播。早期的AI教育中很多课程这一部分是用公式推导带过去的导致大量学习者只知道loss.backward()完全不知道链式法则在多层网络里是怎么展开的。我从零写了一个微型自动求导引擎支持标量和张量的前向传播、反向传播虽然代码量不大但亲手实现之后对很多问题有了真正的理解。比如梯度消失问题。以前只听说过这个词真正手写了一个五层网络做训练发现前三层的参数几乎不动而最后一层收敛很快我才直观感受到反向传播中梯度逐层衰减的威力。后来再学Batch Normalization、ResNet这些设计时我的理解就从别人说这样效果好变成了这是为了解决梯度的传播路径问题。从零实现之后我设计了一个渐进式的过渡过程。完成纯手写版本后还是建议切换到PyTorch这类框架来做实际项目。因为当你理解了底层原理之后框架就成了你的工具而不是黑盒。你知道torch.nn.Linear底层做的是矩阵乘法加偏置你知道F.cross_entropy内部做了softmax和log的数值稳定处理这时候框架反而帮你省去了大量重复代码的时间。训练环节还有几个我特别想强调的实用经验学习率的选择策略。实操中我很少用固定的学习率一般都是用warmup配合余弦退火或者用cosine annealing with restarts这类调度策略。对于Transformer类的模型warmup特别重要因为模型在初期训练时参数分布很不稳定如果直接上大学习率很容易导致loss爆炸。一般warmup步数设置为总训练步数的1%到5%就能有比较好的效果。Batch Size与学习率的联动关系。有一个经验法则叫做线性缩放规则当batch size增大k倍时学习率也相应增大k倍。但这个规则只是粗略的指导实际上从batch size 32增到512时学习率的缩放系数通常只能取到理论上限的60%左右。我在实际项目中一般是固定一个batch size比如256然后做学习率扫描找到最佳值后再调整。混合精度训练的坑。混合精度训练能把训练速度提升1.5到3倍但使用不当也会带来各种诡异问题。最典型的就是loss scale设置不当导致的梯度溢出或下溢。建议初期训练时不要开启混合精度等模型能够正常收敛后再开启加速这样能减少变量方便排查问题。3.3 推理部署与性能优化——离钱最近的工程环节如果训练决定模型有没有效果那么推理就决定了模型能不能用。我在项目里专门把推理优化作为独立章节来讲因为在实际业务中模型推理的耗时、成本、吞吐往往比训练更直接影响产品的体验和利润。推理优化我总结下来可以分四个层面来做从硬件到软件逐层优化硬件选型层面。GPU型号的选择对推理性能和成本影响巨大。同样是跑一个7B模型A10和A100的差别不只是显存大小还有显存带宽、算子执行效率的差异。我的经验是先量化评估你的算力需求比如每秒请求量、单请求的输入输出长度再反推需要什么样的GPU配置。不要一上来就买最贵的卡很多场景下用多张消费级显卡做并行推理的成本效率反而更高。模型压缩层面。包括量化、剪枝、蒸馏三大类。我做工程实践最常用的是量化尤其是INT8和INT4量化。以INT8量化为例它的原理是把FP16的权重和激活值映射到8位整数表示推理时用INT8矩阵乘法指令替代FP16矩阵乘法这样显存占用降低一半计算速度提升一到两倍而精度损失在大多数场景下可以控制在1%以内。权重量化Weight-only Quantization和全量化PTQ/QAT的区别也要分清楚。对于大模型推理目前比较成熟的是权重量化因为激活值对量化的敏感度远高于权重。做QAT时需要把伪量化操作插入训练图里一起训练工程复杂度会高不少所以我的建议是能PTQ解决的就先不做QAT。推理框架与算子优化层面。同一份模型权重用不同的推理引擎跑性能差别可以达到数倍。这也是为什么我强烈建议不要直接用PyTorch做生产环境推理而是用专门优化过的推理框架。这些框架做了算子的内核融合、显存池化、动态shape优化这些工作。比如把Transpose和MatMul融合成一个算子把LayerNorm展开成一系列elementwise操作合并这些小优化累计起来效果非常明显。服务架构层面。这层的核心是最大化GPU利用率。最容易被人忽略的是动态batching也就是把同一个时刻到达的多个请求合并成一个batch做推理。这个优化往往能带来成倍的吞吐提升因为GPU是SIMT架构处理一个请求和处理八个请求在时间上差别并不大。我在一个对话场景里做过实验加了动态batching之后在保证单请求延迟不超标的前提下吞吐量提升了大几倍。3.4 评估体系的搭建——没有评估就没有优化我在这套项目里专门用一个章节来讲评估体系的搭建是因为我在实际工作中发现大部分AI项目效果不好的原因不是模型不够强而是团队根本不知道该优化什么。一个好的评估体系分三个层次第一层是离线评估指标设计。分类任务看准确率、精准率、召回率、F1生成任务看BLEU、ROUGE、BERTScore但单一指标往往会误导人。比如准确率在样本不平衡时会很具有欺骗性——99:1的正负样本比模型全预测为负类也有99%的准确率。我的建议是核心任务指标至少设计两到三个从不同侧面刻画模型效果并且和业务目标对齐。做一些NLP任务时还要特别注意定义清楚评估粒度是token级别、句子级别还是文档级别。第二层是评估集的构建与管理。评估集要覆盖真实场景的边界情况不能只挑好预测的样本。我常用的做法是把评估集按子场景拆分成多个分组每组独立统计指标这样能看到模型在不同场景下的表现差异而不是被一个平均指标掩盖掉问题。做在线评估系统的时候评估集的版本管理同样要认真对待每次迭代都要固定评估集版本不然指标波动你分不清是模型变化还是评估集变化。第三层是线上监控与反馈闭环。离线评估只能反映模型在历史数据上的表现真实环境的数据永远是会漂移的。模型上线后必须监控输入分布的漂移程度、推理延迟、业务指标的变化。我建议设置分层告警指标轻微波动时记录日志严重波动时触发人工介入达到告警阈值时需要可配置的模型回滚机制。4. 工程实践中的工具链选型与环境搭建4.1 开发环境与依赖管理的最佳实践做AI工程和传统软件工程有个很大不同依赖管理极其痛苦。PyTorch、CUDA、cuDNN、Python版本之间的兼容关系错综复杂一个版本不匹配就可能让你白折腾半天。我在项目里首推的做法是使用容器化环境来锁定整套依赖。具体操作上我推荐把开发环境、训练环境、推理环境拆开管理# 训练环境基础镜像 FROM pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime # 安装额外依赖 RUN pip install transformers datasets accelerate evaluate # 设置工作目录 WORKDIR /workspace这个做法最大的好处是环境可复现。同组的人拉同一个镜像就能跑同样的代码不会出现在我机器上能跑的情况。生产环境部署时也用同一套容器镜像可以最大限度减少环境差异带来的问题。关于Python包管理我强烈建议用uv这类新一代工具替代传统pip原因无他——速度快依赖解析准确。对于AI项目来说随时可能安装大量依赖包传统pip的解析机制在依赖树复杂时效率很低uv基于Rust实现解析和安装速度都能提升一个数量级。4.2 Jupyter Notebook和脚本——两种工作模式的合理分工做AI工程有个很有意思的现象很多人要么只用Notebook要么只写Python脚本其实这两种工作模式各有其适配场景合理混用才是效率最高的方式。Notebook适合做探索性工作比如数据分析、特征工程验证、小规模的模型实验。它的优势是支持交互式执行和可视化输出你能很快看到每一步的结果。但Notebook的劣势也很明显难以做版本管理、跑大规模训练时容易断掉、代码和输出混在一起难以模块化。脚本适合做工程化工作比如数据处理流水线、模型训练、评估、推理服务。它的优势是清晰、可复用、易于自动化部署和监控。我的建议是把Notebook用作探索阶段确认思路可行后再把代码重构为脚本和模块。通过配置文件控制各项参数通过命令行入口触发执行这样整个流程更加规范也便于走CI/CD流程。4.3 实验管理与日志——让你每次都清楚发生了什么AI实验太容易陷入混乱了参数改来改去、结果时好时坏、甚至过了几天连自己都忘了当初用的什么配置。我在这套路线中把实验管理提到了很高的优先级因为它直接影响你的迭代效率。我推荐两个工具的组合使用MLflow用来管理实验的元数据包括参数、指标、模型artifact、tag备注等。它的tracking功能能让你像翻历史记录一样查看每次实验的完整配置和结果。Weights Biases则更偏实时可视化训练过程中的loss曲线、梯度分布、学习率变化都能实时看到。不一定要用这些商业化服务自建一套也可以。关键是养成一个习惯任何一次训练都要记录数据版本、代码版本、参数配置、评估结果、运行时长这五类信息。这样出了任何问题你都能回溯到当时的具体环境而不是靠记忆猜。5. 典型避坑指南那些只有踩过坑才能总结的经验5.1 数据泄漏——评估结果虚高的头号元凶做AI工程最危险的事情不是模型效果差而是模型在评估集上效果很好上线后效果崩掉。这里面最常见的原因就是数据泄漏。我举一个我亲自踩过的例子我在做一个文本分类项目时把原始数据集随机切分为训练集和验证集当时想的是随机切分总不会有问题了吧结果模型在验证集上F1高达0.97上线之后实际场景F1只有0.82。排查了很久才发现原始数据里同一个新闻事件会出现在多篇文章中这些文章虽然文本不完全相同但核心事件和表达方式高度相似随机切分后这些高度相似的样本一部分进了训练集一部分进了验证集模型相当于是见过验证集内容的。从那以后我总结出防泄漏的三个关键操作数据切分前先做实体级别的去重用户维度、文档维度都要考虑涉及时间序列的预测一律按时间切分不能用随机切分做特征工程时严禁使用目标变量的未来信息比如用未来价格的平均值作为当前特征这些经验听起来简单但在实操中稍不注意就会踩雷。每次评估前我都习惯先检查一遍特征和时间戳的对齐关系看看有没有未来信息悄悄进入特征。5.2 训练不收敛——定位问题的系统性排查法Loss不下降或者直接出NaN是每个AI工程师都遇到过的问题。很多人的第一反应是调学习率但实际上导致不收敛的原因有很多不同原因需要不同的处理方式。我在项目里总结了一套系统的排查思路分享给读者第一步先查看数据是否存在问题。数据里有大量NaN值、标签错乱、特征分布极端都会导致训练不稳定。我会用可视化工具检查输入数据的分布确认数据没有问题再开始排查模型。第二步检查模型结构和参数初始化。参数初始化不合理是训练不收敛的高发原因。ReLU网络如果初始化值太大容易引起梯度爆炸tanh激活如果初始化太窄可能让神经元输出饱和在0附近。标准的Xavier/Glorot初始化和Kaiming初始化就是这个道理但很多人直接用了默认初始化没有针对任务调过。第三步观察梯度范数的变化。我习惯在训练时记录梯度的全局范数如果它在某一步突然暴涨到正常值的几百倍那大概率是梯度爆炸了需要加梯度裁剪。如果梯度范数在快速下降后趋于零那可能是梯度消失或者模型容量不足。第四步是降低学习率重试。如果前面几步都没发现问题先把学习率降到原来的十分之一试试确认模型能不能正常收敛。很多时候不收敛只是因为学习率初始值太大了。这套排查法帮我在很多项目里节省了大量时间它的核心思想就是先确认数据可靠再检查模型结构再动态看梯度最后调整超参数按顺序排查而不是一上来就瞎调参。5.3 推理性能优化——先量化瓶颈再动手推理性能优化的原则和训练相似不要凭着感觉去改而是先量化瓶颈在哪里。常见的性能瓶颈我归纳为四类第一类是数据加载瓶颈。GPU在飞速运算但CPU端的预处理和数据搬运跟不上导致GPU利用率持续低迷。排查方法很直接看着GPU利用率曲线如果它是锯齿状的低谷和高峰交替大量时间可能浪费在等数据上。解决方法是开多进程数据加载、预处理交给GPU、数据预取到显存等。第二类是算子执行瓶颈。某个算子在当前GPU架构上执行效率极低比如LayerNorm这类带归约操作在部分硬件上跑的就很慢。解决方式是寻找替代实现或算子融合方式。第三类是显存带宽瓶颈。权重太大每次推理都要从显存里反复读取带宽成为瓶颈。这里能将权重做量化压缩或者把权重裁减到更小的模型。第四类是显存容量瓶颈。模型太大放不进显存推理要频繁换入换出或者要用CPU offload导致性能差。这个只能从模型压缩入手或者换更大显存的卡或者用KV Cache等推理时显存优化手段。我建议每个做AI工程的朋友都养成习惯动手优化之前先用profiling工具采集一份完整的性能数据。用PyTorch的话就是torch.profiler训练时也可以用NVIDIA的Nsight Systems系列工具看清时间到底花在哪再做针对性优化。很多时候你以为的瓶颈和实测值差别非常大凭感觉优化是效率最低的做法。6. 全链路实战从零构建一个可用的文本分类服务前面的章节把每个环节拆开讲了现在我把它们串起来展示一个完整的实战从零构建并部署一个可用的文本分类服务。这个项目案例也是我在整个ai-engineering-from-scratch路线里设计的压轴实战项目。第一步明确业务问题。假设我们要做一个客服工单的自动分类系统把用户提交的工单文本自动归入退换货、物流查询、账户问题、技术故障、投诉建议这几个类别。这个任务的业务价值很清楚减少客服人工分类的时间提升响应效率。评估指标选择上因为工单类别的分布并不均匀投诉建议类可能只占5%物流查询可能占40%所以我选择宏平均F1作为主要评估指标同时参考各类别的精确率和召回率防止模型在少数类上效果差而平均指标掩蔽了问题。第二步数据获取与构建。这类业务场景往往没有公开数据集需要用自己的历史工单。我模拟了一份2万条标注好的工单数据包含工单文本和类别标签按照9:1的比例切分为训练集和验证集。切分时按照工单ID做去重确保同一个用户的多条工单不会被同时切到训练集和验证集里。数据清洗阶段做的工作包括去除HTML标签、URL、提及统一全角半角字符校正常见的错别字过滤超短文本少于5个字符的通常是无效工单。第三步模型选型与训练。任务相对简单、数据量中等我选用了BERT-base作为基础模型在标注数据上做fine-tuning。这里有个工程决策要说一下为什么不直接用大模型做零样本分类因为实测下来大模型在工单分类这个具体任务上虽然泛化能力强但延迟和成本都高出几个量级而且在有标注数据的情况下fine-tune一个小模型精度通常超过大模型的零样本效果。训练配置如下学习率2e-5warmup比例10%batch size 32训练5个epoch优化器用AdamW。训练时开启混合精度加速并利用早停法监控验证集loss在连续两个epoch没有改善时停止训练。第四步评估与错误分析。训练完成后评估结果显示宏平均F1达到了0.91。但我没有止步于此对分错的样本做了错误分析发现了几类典型问题我的东西好几天没到怎么办被分到了物流查询而不是退换货人工判断也很难说绝对正确这类是边界模糊样本你们能不能快点这种短文本信息量不足模型很难准确分类少数类投诉建议的召回率偏低因为训练样本本身较少针对这些发现我做了两个改进一是对少数类做了过采样二是增加了更多短文本样本进行增强。改进后宏平均F1提升到了0.93。第五步推理优化与部署。模型服务化我采用FasterTransformer推理引擎做加速同时把模型做了INT8量化推理延迟从平均15ms降到了7ms左右显存占用从500MB降到了约250MB。服务端启用了动态batching在并发请求达到20的时候吞吐量比单batch模式提升了接近5倍单请求P95延迟依然控制在40ms以内。部署形态上我用了容器化加Kubernetes的方式配置了HPA根据CPU和GPU利用率自动伸缩副本数。加上Prometheus监控推理延迟、错误率、GPU利用率这些指标并在错误率超过阈值时自动告警。第六步线上评估与持续迭代。最后也是最关键的一步在服务稳定运行一周后抽取出线上日志中的1000条样本让标注团队重新标注了一遍然后用这批线上样本评估模型效果。这一步能真实反映模型的线下评估结果与线上效果的gap帮助后续迭代更有方向。这套从零到一的全流程做完之后我建议读者在自己的业务场景里也用同样的链路走一遍你会发现自己对AI工程的每一个环节都有了切身的理解而不是只停留在会调用某个框架API的层面。7. 学习路径因人而异——如何按自己的基础规划进阶每个人的知识储备不一样统一的路线图不可能适合所有人。我在项目里给不同基础的读者设计了三条不同的学习路径你可以根据自己的情况选择。路径一零编程基础但对AI有浓厚兴趣。这种情况我的建议是先用Python编程语言作为切入点把基础语法、数据结构、文件操作这些基本功打扎实再进入数据处理和模型训练环节。不要贪快编程基础不牢后面每一步都会很吃力。这个阶段可以安排2到3个月的时间主要是通过实际练习掌握基本编程能力不需要涉及太复杂的算法。路径二有编程经验但没有机器学习基础。如果你是软件工程师转AI方向编程基础可以帮你节省大量时间。你的重点应该放在机器学习理论和深度学习的核心概念上线性回归、逻辑回归、梯度下降、反向传播、常见网络结构这些内容。我建议做路线里的手动实现神经网络练习这个过程最适合你因为你有代码功底实现起来会很快而难点在于理解数学原理和算法逻辑需要多花时间消化。路径三有机器学习基础但工程能力薄弱。算法背景的读者恰恰和路径二相反你的短板通常在工程一侧数据管道怎么搭建、模型怎么部署、怎么监控、怎么优化推理性能。我建议你把重心放在工程化章节和全链路实战部分尤其是推理优化和服务部署这些部分。这一部分能帮你建立起从模型能做出来到模型能跑在生产环境的完整认知。路径四零基础但目标明确、时间充裕。如果时间和精力都允许我建议完整走一遍整条路线不要跳过任何章节。这条路线设计的顺序就是按依赖关系排好的前面的基石不牢后面会反复回去补课。在我的经验里愿意花3到6个月系统走一遍的人最后对AI工程的理解深度会远超那些只学框架速成的人。无论选择哪条路径我都有一个共同建议每学一个概念尽量在手写代码时亲自验证一遍。从零实现和调用框架的最大区别是你不再是被动的使用者和接受者而是主动的构建者和理解者这种认知方式带来的提升是本质性的。8. 关于项目后续扩展的一些想法ai-engineering-from-scratch项目目前已经覆盖到模型训练、推理优化、评估部署的全链路内容但AI领域变化太快随时都有新的方向值得纳入这套体系。我目前计划扩展的方向有三个第一个方向是大模型应用工程化。这部分的重点不再是如何训练基础模型而是如何围绕大模型构建完整的应用体系包括提示词工程、检索增强生成RAG、Agent设计模式、大模型微调与对齐、多模型协同路由这些内容。这些内容对AI工程师来说是新的能力要求很多传统机器学习技术在这里并不能直接迁移。第二个方向是多模态AI系统构建。文本、图像、音频、视频的联合理解和生成已经成为现实需求多模态数据的对齐、融合、生成在这些场景下有很多新的工程挑战。我正在尝试把多模态模型的结构原理、训练技术、部署优化也纳入体系和实践链条融合在一起。第三个方向是AI系统可靠性工程。包括模型漂移检测、自动回滚、A/B测试框架、安全审计机制等。随着AI系统在越来越多关键业务中承担角色系统的可靠性和可控性会变得越来越重要。这部分的工程实践资料目前还是比较稀缺的我也会持续整理。另外我也会沿着每个核心章节持续补充实操案例和踩坑记录。毕竟AI工程是一个实践驱动的领域通过更多真实案例来表达经验会让整个项目的价值更加完整。 
长河君 · 2026/10/3 5:56:10 · 阅读 1.2k 从零构建AI工程：底层原理到生产部署的全链路实践
1. 为什么我从框架热转向了从零构建AI工程这两年有个很有趣的现象身边越来越多人自称AI工程师但真正被问到模型是怎么训练出来的推理时显存到底花在哪了线上效果波动怎么排查这类问题时往往只能答出调了调参、换了换prompt、加了点数据。不是说这些操作没有价值而是它们离工程两个字还有相当距离。我做ai-engineering-from-scratch这个项目的初衷其实挺朴素——我发现自己花了大量时间在各种框架、工具链和模型仓库之间来回跳今天换这个框架跑个demo明天换那个库调到能出图但一旦遇到线上真实问题比如延迟压不下来、显存爆了、效果时好时坏我依然没有一套自己的排查方法论。这个项目既不是又一个30天学会AI的速成课也不是一份工具清单式的收藏夹。它是一套从最底层原理出发、一步步亲手实现AI系统核心环节的完整路线图覆盖了从数据处理、模型训练、推理优化到评估上线的全链路工程实践。如果你是那种不亲手把轮子造一遍就心里不踏实的人或者你已经被各种框架封装搞得有点迷失想回到技术本质重新梳理一遍AI工程的知识体系这份项目应该能帮你把散落的知识点串成一张完整的网。我把这个项目当作自己的一次系统性复盘把过去几年踩过的坑、想明白的道理、以及那些早该知道的经验全部沉淀成一份可以从零一直跟到生产环境的工程实践路线。这篇文章就是对这个项目核心内容的完整梳理。2. 项目整体架构一套从底层到上层的AI工程知识体系2.1 为什么选择从零构建而不是从框架入手先聊聊我为什么坚定地选择从零开始而不是直接上手PyTorch或TensorFlow。过去两年我面试过不少候选人也带过几个新人发现一个共性现象大家用框架用得都很溜但问到反向传播到底是怎么算的Batch Normalization训练和推理时行为有什么不同梯度消失的本质原因是什么这些问题时能讲清楚的人非常少。这不怪任何人因为现代框架的封装程度实在太高了。一行loss.backward()背后是几十个OP的自动微分编排一句model.fit()背后是数据加载、混合精度、梯度累积、学习率调度一大串逻辑。框架把复杂性吞掉了同时也把理解的门槛推高了。从工程角度说不了解底层原理的代价是巨大的模型训练遇到loss震荡不知道是该调学习率还是该查数据分布只能靠试推理时GPU显存不够不知道是激活值占了空间还是权重缓存占了空间只能无脑减batch size上线前要做性能优化不知道瓶颈在数据加载、算子执行还是GPU拷贝只能靠猜所以我在这条路线里特意设计了手动实现核心组件的学习环节。不是让你以后所有项目都从零写而是让你亲手实现一次前向传播、反向传播、一个简单的Transformer Block在这个过程中把黑盒打开看清里面到底发生了什么。这种学习路径和学开车很像。你日常开车不需要懂发动机的工作原理但如果你立志做一名赛车工程师不知道内燃机怎么工作就完全没法调校赛车。AI工程也是一样框架是你的车但如果目标是做AI系统的设计者和调校者底层原理就是必须补上的功课。2.2 知识体系的层级拆解与依赖关系整个项目的知识体系分成了五个层级每一层都建立在前一层的基础之上。我最初在规划这个项目的时候一直在想用什么结构来组织内容最合理最后确定了这条依赖链第一层是数学与机器学习基石。这一层负责解决AI系统为什么能work的问题包括线性代数、概率论、最优化理论等核心数学工具以及机器学习的基本框架——损失函数、梯度下降、正则化、偏差方差权衡这些基础概念。第二层是深度学习核心原理。这一层负责解决神经网络到底是怎么学习的问题从感知机开始逐步深入到多层感知机、卷积网络、循环网络、注意力机制重点理解梯度传播、参数初始化、归一化技术这些决定训练成败的细节。第三层是手写实现与代码能力。这一层负责解决我能不能自己造出来的问题不依赖任何高级深度学习框架用基础数值计算库从零实现神经网络的核心组件包括自动求导引擎、各类网络层、优化器和完整训练流程。第四层是工程化与系统设计。这一层负责解决模型怎么跑到生产环境的问题涵盖数据管道构建、分布式训练、模型压缩、推理优化、服务化部署、监控告警这一整套MLOps实践。第五层是全链路实战落地。这一层负责解决这么多知识怎么串起来的问题以一个完整的AI应用为靶子把前面四层的知识全部串起来形成一个从数据到上线运营的闭环。这个分层的核心思想其实借鉴了计算机系统领域一个经典原则——“如果你不能构建它你就不能真正理解它”。每一层的内容都在为下一层提供认知基础同时也在用上一层的内容来检验自己的理解是否到位。2.3 项目的目标场景与适用人群我整理这个项目的时候反复问自己一个问题哪些人会真正需要这样一条从零开始的路线第一类人是刚入门但不想走弯路的AI学习者。市面上大多数课程的问题不是内容不好而是跳跃性太强。今天学CNN明天就让你用YOLO做目标检测后天让你用LangChain搭Agent。这种学习方式导致知识体系出现大量空洞前期还能靠框架机制弥补后面一旦遇到复杂问题就寸步难行。这条路线帮你把地基打牢前期看起来慢后期反而快。第二类人是有一定经验但感觉遇到瓶颈的工程师。这类人会用框架能跑通模型训练但总觉得自己的理解浮在表面。遇到性能问题不知道从哪里排查遇到训练不收敛只能反复调参靠运气。这套体系专门帮你把那些知其然不知其所以然的部分补齐。第三类人是想转型AI方向的传统软件工程师。你有扎实的工程能力和代码功底但缺少机器学习理论基础。传统软件开发的经验在AI领域有大量可以迁移的地方但也有一些需要补充的新思维方式。这条路线能帮你在AI工程领域建立完整的能力图谱而不是零散地学几个模型怎么调用。总的来说这个项目不适合两类人一类是只想快速出demo做演示的人另一类是只做纯算法研究、不关心工程落地的人。前者会觉得内容太重后者会觉得内容太偏工程。它服务的核心人群始终是想把AI系统真正做出来并跑在生产环境里的人。3. 核心环节实践亲手搭出一条AI工程链路3.1 数据处理与特征工程——被严重低估的起点说到AI工程很多人第一反应是模型结构和训练技巧但我做这个项目最大的感触是数据处理和特征工程才是真正决定项目成败的环节。我见过太多团队在模型上投入大量精力优化精度最后发现效果上不去的原因竟然是训练集和验证集的分布不一致或者数据里存在大量泄漏。在这套路线里我把数据处理拆成几个关键环节每个环节都有自己的注意点。第一个环节是数据采集方案设计。这里最核心的原则是让采集的数据尽可能覆盖真实场景的分布。比如做文本分类模型不能只收集规范化的新闻语料还要考虑到用户输入可能包含错别字、口语化表达、中英文混杂等各种情况。如果数据采集阶段就引入了偏差后面用再好的模型也纠正不回来。第二个环节是数据清洗与质量评估。很多人以为数据清洗就是去重、去空值实际上远不止这些。对于文本数据要处理编码问题、HTML标签残留、广告噪声对于图像数据要处理模糊、过曝、遮挡、标签错误。我习惯在做任何清洗操作之前先随机抽样一批数据人工查看一遍建立对数据质量的直觉这个步骤比任何自动化工具都重要。第三个环节是特征设计与数据增强策略。深度学习确实可以自动从原始数据中学习特征表示但这不代表特征工程就不重要了。在数据量有限的场景下好的特征设计能大幅降低模型的学习难度。比如时间序列预测如果你能把星期几、是否节假日、历史同期值这些先验知识作为特征喂给模型效果通常比让模型自己从纯数值序列中硬学要好得多。数据增强是另一个容易被误用的环节。图像领域常用的随机裁剪、旋转、色彩抖动文本领域的同义词替换、回译增强都要注意增强后的数据不能破坏原始语义。我曾经在一个文本分类项目里用回译做了数据增强结果把很好增强成了十分完美把一般增强成了平平常常导致模型在训练集上效果突然飙升但线上表现毫无变化——原因就是增强后的数据分布和真实分布出现了偏差。3.2 模型训练——从手动实现反向传播到轻量框架过渡训练这部分是我整个项目里篇幅最大的章节因为这里面的坑实在太多了。我先和大家分享一下我为什么坚持从零实现反向传播。早期的AI教育中很多课程这一部分是用公式推导带过去的导致大量学习者只知道loss.backward()完全不知道链式法则在多层网络里是怎么展开的。我从零写了一个微型自动求导引擎支持标量和张量的前向传播、反向传播虽然代码量不大但亲手实现之后对很多问题有了真正的理解。比如梯度消失问题。以前只听说过这个词真正手写了一个五层网络做训练发现前三层的参数几乎不动而最后一层收敛很快我才直观感受到反向传播中梯度逐层衰减的威力。后来再学Batch Normalization、ResNet这些设计时我的理解就从别人说这样效果好变成了这是为了解决梯度的传播路径问题。从零实现之后我设计了一个渐进式的过渡过程。完成纯手写版本后还是建议切换到PyTorch这类框架来做实际项目。因为当你理解了底层原理之后框架就成了你的工具而不是黑盒。你知道torch.nn.Linear底层做的是矩阵乘法加偏置你知道F.cross_entropy内部做了softmax和log的数值稳定处理这时候框架反而帮你省去了大量重复代码的时间。训练环节还有几个我特别想强调的实用经验学习率的选择策略。实操中我很少用固定的学习率一般都是用warmup配合余弦退火或者用cosine annealing with restarts这类调度策略。对于Transformer类的模型warmup特别重要因为模型在初期训练时参数分布很不稳定如果直接上大学习率很容易导致loss爆炸。一般warmup步数设置为总训练步数的1%到5%就能有比较好的效果。Batch Size与学习率的联动关系。有一个经验法则叫做线性缩放规则当batch size增大k倍时学习率也相应增大k倍。但这个规则只是粗略的指导实际上从batch size 32增到512时学习率的缩放系数通常只能取到理论上限的60%左右。我在实际项目中一般是固定一个batch size比如256然后做学习率扫描找到最佳值后再调整。混合精度训练的坑。混合精度训练能把训练速度提升1.5到3倍但使用不当也会带来各种诡异问题。最典型的就是loss scale设置不当导致的梯度溢出或下溢。建议初期训练时不要开启混合精度等模型能够正常收敛后再开启加速这样能减少变量方便排查问题。3.3 推理部署与性能优化——离钱最近的工程环节如果训练决定模型有没有效果那么推理就决定了模型能不能用。我在项目里专门把推理优化作为独立章节来讲因为在实际业务中模型推理的耗时、成本、吞吐往往比训练更直接影响产品的体验和利润。推理优化我总结下来可以分四个层面来做从硬件到软件逐层优化硬件选型层面。GPU型号的选择对推理性能和成本影响巨大。同样是跑一个7B模型A10和A100的差别不只是显存大小还有显存带宽、算子执行效率的差异。我的经验是先量化评估你的算力需求比如每秒请求量、单请求的输入输出长度再反推需要什么样的GPU配置。不要一上来就买最贵的卡很多场景下用多张消费级显卡做并行推理的成本效率反而更高。模型压缩层面。包括量化、剪枝、蒸馏三大类。我做工程实践最常用的是量化尤其是INT8和INT4量化。以INT8量化为例它的原理是把FP16的权重和激活值映射到8位整数表示推理时用INT8矩阵乘法指令替代FP16矩阵乘法这样显存占用降低一半计算速度提升一到两倍而精度损失在大多数场景下可以控制在1%以内。权重量化Weight-only Quantization和全量化PTQ/QAT的区别也要分清楚。对于大模型推理目前比较成熟的是权重量化因为激活值对量化的敏感度远高于权重。做QAT时需要把伪量化操作插入训练图里一起训练工程复杂度会高不少所以我的建议是能PTQ解决的就先不做QAT。推理框架与算子优化层面。同一份模型权重用不同的推理引擎跑性能差别可以达到数倍。这也是为什么我强烈建议不要直接用PyTorch做生产环境推理而是用专门优化过的推理框架。这些框架做了算子的内核融合、显存池化、动态shape优化这些工作。比如把Transpose和MatMul融合成一个算子把LayerNorm展开成一系列elementwise操作合并这些小优化累计起来效果非常明显。服务架构层面。这层的核心是最大化GPU利用率。最容易被人忽略的是动态batching也就是把同一个时刻到达的多个请求合并成一个batch做推理。这个优化往往能带来成倍的吞吐提升因为GPU是SIMT架构处理一个请求和处理八个请求在时间上差别并不大。我在一个对话场景里做过实验加了动态batching之后在保证单请求延迟不超标的前提下吞吐量提升了大几倍。3.4 评估体系的搭建——没有评估就没有优化我在这套项目里专门用一个章节来讲评估体系的搭建是因为我在实际工作中发现大部分AI项目效果不好的原因不是模型不够强而是团队根本不知道该优化什么。一个好的评估体系分三个层次第一层是离线评估指标设计。分类任务看准确率、精准率、召回率、F1生成任务看BLEU、ROUGE、BERTScore但单一指标往往会误导人。比如准确率在样本不平衡时会很具有欺骗性——99:1的正负样本比模型全预测为负类也有99%的准确率。我的建议是核心任务指标至少设计两到三个从不同侧面刻画模型效果并且和业务目标对齐。做一些NLP任务时还要特别注意定义清楚评估粒度是token级别、句子级别还是文档级别。第二层是评估集的构建与管理。评估集要覆盖真实场景的边界情况不能只挑好预测的样本。我常用的做法是把评估集按子场景拆分成多个分组每组独立统计指标这样能看到模型在不同场景下的表现差异而不是被一个平均指标掩盖掉问题。做在线评估系统的时候评估集的版本管理同样要认真对待每次迭代都要固定评估集版本不然指标波动你分不清是模型变化还是评估集变化。第三层是线上监控与反馈闭环。离线评估只能反映模型在历史数据上的表现真实环境的数据永远是会漂移的。模型上线后必须监控输入分布的漂移程度、推理延迟、业务指标的变化。我建议设置分层告警指标轻微波动时记录日志严重波动时触发人工介入达到告警阈值时需要可配置的模型回滚机制。4. 工程实践中的工具链选型与环境搭建4.1 开发环境与依赖管理的最佳实践做AI工程和传统软件工程有个很大不同依赖管理极其痛苦。PyTorch、CUDA、cuDNN、Python版本之间的兼容关系错综复杂一个版本不匹配就可能让你白折腾半天。我在项目里首推的做法是使用容器化环境来锁定整套依赖。具体操作上我推荐把开发环境、训练环境、推理环境拆开管理# 训练环境基础镜像 FROM pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime # 安装额外依赖 RUN pip install transformers datasets accelerate evaluate # 设置工作目录 WORKDIR /workspace这个做法最大的好处是环境可复现。同组的人拉同一个镜像就能跑同样的代码不会出现在我机器上能跑的情况。生产环境部署时也用同一套容器镜像可以最大限度减少环境差异带来的问题。关于Python包管理我强烈建议用uv这类新一代工具替代传统pip原因无他——速度快依赖解析准确。对于AI项目来说随时可能安装大量依赖包传统pip的解析机制在依赖树复杂时效率很低uv基于Rust实现解析和安装速度都能提升一个数量级。4.2 Jupyter Notebook和脚本——两种工作模式的合理分工做AI工程有个很有意思的现象很多人要么只用Notebook要么只写Python脚本其实这两种工作模式各有其适配场景合理混用才是效率最高的方式。Notebook适合做探索性工作比如数据分析、特征工程验证、小规模的模型实验。它的优势是支持交互式执行和可视化输出你能很快看到每一步的结果。但Notebook的劣势也很明显难以做版本管理、跑大规模训练时容易断掉、代码和输出混在一起难以模块化。脚本适合做工程化工作比如数据处理流水线、模型训练、评估、推理服务。它的优势是清晰、可复用、易于自动化部署和监控。我的建议是把Notebook用作探索阶段确认思路可行后再把代码重构为脚本和模块。通过配置文件控制各项参数通过命令行入口触发执行这样整个流程更加规范也便于走CI/CD流程。4.3 实验管理与日志——让你每次都清楚发生了什么AI实验太容易陷入混乱了参数改来改去、结果时好时坏、甚至过了几天连自己都忘了当初用的什么配置。我在这套路线中把实验管理提到了很高的优先级因为它直接影响你的迭代效率。我推荐两个工具的组合使用MLflow用来管理实验的元数据包括参数、指标、模型artifact、tag备注等。它的tracking功能能让你像翻历史记录一样查看每次实验的完整配置和结果。Weights Biases则更偏实时可视化训练过程中的loss曲线、梯度分布、学习率变化都能实时看到。不一定要用这些商业化服务自建一套也可以。关键是养成一个习惯任何一次训练都要记录数据版本、代码版本、参数配置、评估结果、运行时长这五类信息。这样出了任何问题你都能回溯到当时的具体环境而不是靠记忆猜。5. 典型避坑指南那些只有踩过坑才能总结的经验5.1 数据泄漏——评估结果虚高的头号元凶做AI工程最危险的事情不是模型效果差而是模型在评估集上效果很好上线后效果崩掉。这里面最常见的原因就是数据泄漏。我举一个我亲自踩过的例子我在做一个文本分类项目时把原始数据集随机切分为训练集和验证集当时想的是随机切分总不会有问题了吧结果模型在验证集上F1高达0.97上线之后实际场景F1只有0.82。排查了很久才发现原始数据里同一个新闻事件会出现在多篇文章中这些文章虽然文本不完全相同但核心事件和表达方式高度相似随机切分后这些高度相似的样本一部分进了训练集一部分进了验证集模型相当于是见过验证集内容的。从那以后我总结出防泄漏的三个关键操作数据切分前先做实体级别的去重用户维度、文档维度都要考虑涉及时间序列的预测一律按时间切分不能用随机切分做特征工程时严禁使用目标变量的未来信息比如用未来价格的平均值作为当前特征这些经验听起来简单但在实操中稍不注意就会踩雷。每次评估前我都习惯先检查一遍特征和时间戳的对齐关系看看有没有未来信息悄悄进入特征。5.2 训练不收敛——定位问题的系统性排查法Loss不下降或者直接出NaN是每个AI工程师都遇到过的问题。很多人的第一反应是调学习率但实际上导致不收敛的原因有很多不同原因需要不同的处理方式。我在项目里总结了一套系统的排查思路分享给读者第一步先查看数据是否存在问题。数据里有大量NaN值、标签错乱、特征分布极端都会导致训练不稳定。我会用可视化工具检查输入数据的分布确认数据没有问题再开始排查模型。第二步检查模型结构和参数初始化。参数初始化不合理是训练不收敛的高发原因。ReLU网络如果初始化值太大容易引起梯度爆炸tanh激活如果初始化太窄可能让神经元输出饱和在0附近。标准的Xavier/Glorot初始化和Kaiming初始化就是这个道理但很多人直接用了默认初始化没有针对任务调过。第三步观察梯度范数的变化。我习惯在训练时记录梯度的全局范数如果它在某一步突然暴涨到正常值的几百倍那大概率是梯度爆炸了需要加梯度裁剪。如果梯度范数在快速下降后趋于零那可能是梯度消失或者模型容量不足。第四步是降低学习率重试。如果前面几步都没发现问题先把学习率降到原来的十分之一试试确认模型能不能正常收敛。很多时候不收敛只是因为学习率初始值太大了。这套排查法帮我在很多项目里节省了大量时间它的核心思想就是先确认数据可靠再检查模型结构再动态看梯度最后调整超参数按顺序排查而不是一上来就瞎调参。5.3 推理性能优化——先量化瓶颈再动手推理性能优化的原则和训练相似不要凭着感觉去改而是先量化瓶颈在哪里。常见的性能瓶颈我归纳为四类第一类是数据加载瓶颈。GPU在飞速运算但CPU端的预处理和数据搬运跟不上导致GPU利用率持续低迷。排查方法很直接看着GPU利用率曲线如果它是锯齿状的低谷和高峰交替大量时间可能浪费在等数据上。解决方法是开多进程数据加载、预处理交给GPU、数据预取到显存等。第二类是算子执行瓶颈。某个算子在当前GPU架构上执行效率极低比如LayerNorm这类带归约操作在部分硬件上跑的就很慢。解决方式是寻找替代实现或算子融合方式。第三类是显存带宽瓶颈。权重太大每次推理都要从显存里反复读取带宽成为瓶颈。这里能将权重做量化压缩或者把权重裁减到更小的模型。第四类是显存容量瓶颈。模型太大放不进显存推理要频繁换入换出或者要用CPU offload导致性能差。这个只能从模型压缩入手或者换更大显存的卡或者用KV Cache等推理时显存优化手段。我建议每个做AI工程的朋友都养成习惯动手优化之前先用profiling工具采集一份完整的性能数据。用PyTorch的话就是torch.profiler训练时也可以用NVIDIA的Nsight Systems系列工具看清时间到底花在哪再做针对性优化。很多时候你以为的瓶颈和实测值差别非常大凭感觉优化是效率最低的做法。6. 全链路实战从零构建一个可用的文本分类服务前面的章节把每个环节拆开讲了现在我把它们串起来展示一个完整的实战从零构建并部署一个可用的文本分类服务。这个项目案例也是我在整个ai-engineering-from-scratch路线里设计的压轴实战项目。第一步明确业务问题。假设我们要做一个客服工单的自动分类系统把用户提交的工单文本自动归入退换货、物流查询、账户问题、技术故障、投诉建议这几个类别。这个任务的业务价值很清楚减少客服人工分类的时间提升响应效率。评估指标选择上因为工单类别的分布并不均匀投诉建议类可能只占5%物流查询可能占40%所以我选择宏平均F1作为主要评估指标同时参考各类别的精确率和召回率防止模型在少数类上效果差而平均指标掩蔽了问题。第二步数据获取与构建。这类业务场景往往没有公开数据集需要用自己的历史工单。我模拟了一份2万条标注好的工单数据包含工单文本和类别标签按照9:1的比例切分为训练集和验证集。切分时按照工单ID做去重确保同一个用户的多条工单不会被同时切到训练集和验证集里。数据清洗阶段做的工作包括去除HTML标签、URL、提及统一全角半角字符校正常见的错别字过滤超短文本少于5个字符的通常是无效工单。第三步模型选型与训练。任务相对简单、数据量中等我选用了BERT-base作为基础模型在标注数据上做fine-tuning。这里有个工程决策要说一下为什么不直接用大模型做零样本分类因为实测下来大模型在工单分类这个具体任务上虽然泛化能力强但延迟和成本都高出几个量级而且在有标注数据的情况下fine-tune一个小模型精度通常超过大模型的零样本效果。训练配置如下学习率2e-5warmup比例10%batch size 32训练5个epoch优化器用AdamW。训练时开启混合精度加速并利用早停法监控验证集loss在连续两个epoch没有改善时停止训练。第四步评估与错误分析。训练完成后评估结果显示宏平均F1达到了0.91。但我没有止步于此对分错的样本做了错误分析发现了几类典型问题我的东西好几天没到怎么办被分到了物流查询而不是退换货人工判断也很难说绝对正确这类是边界模糊样本你们能不能快点这种短文本信息量不足模型很难准确分类少数类投诉建议的召回率偏低因为训练样本本身较少针对这些发现我做了两个改进一是对少数类做了过采样二是增加了更多短文本样本进行增强。改进后宏平均F1提升到了0.93。第五步推理优化与部署。模型服务化我采用FasterTransformer推理引擎做加速同时把模型做了INT8量化推理延迟从平均15ms降到了7ms左右显存占用从500MB降到了约250MB。服务端启用了动态batching在并发请求达到20的时候吞吐量比单batch模式提升了接近5倍单请求P95延迟依然控制在40ms以内。部署形态上我用了容器化加Kubernetes的方式配置了HPA根据CPU和GPU利用率自动伸缩副本数。加上Prometheus监控推理延迟、错误率、GPU利用率这些指标并在错误率超过阈值时自动告警。第六步线上评估与持续迭代。最后也是最关键的一步在服务稳定运行一周后抽取出线上日志中的1000条样本让标注团队重新标注了一遍然后用这批线上样本评估模型效果。这一步能真实反映模型的线下评估结果与线上效果的gap帮助后续迭代更有方向。这套从零到一的全流程做完之后我建议读者在自己的业务场景里也用同样的链路走一遍你会发现自己对AI工程的每一个环节都有了切身的理解而不是只停留在会调用某个框架API的层面。7. 学习路径因人而异——如何按自己的基础规划进阶每个人的知识储备不一样统一的路线图不可能适合所有人。我在项目里给不同基础的读者设计了三条不同的学习路径你可以根据自己的情况选择。路径一零编程基础但对AI有浓厚兴趣。这种情况我的建议是先用Python编程语言作为切入点把基础语法、数据结构、文件操作这些基本功打扎实再进入数据处理和模型训练环节。不要贪快编程基础不牢后面每一步都会很吃力。这个阶段可以安排2到3个月的时间主要是通过实际练习掌握基本编程能力不需要涉及太复杂的算法。路径二有编程经验但没有机器学习基础。如果你是软件工程师转AI方向编程基础可以帮你节省大量时间。你的重点应该放在机器学习理论和深度学习的核心概念上线性回归、逻辑回归、梯度下降、反向传播、常见网络结构这些内容。我建议做路线里的手动实现神经网络练习这个过程最适合你因为你有代码功底实现起来会很快而难点在于理解数学原理和算法逻辑需要多花时间消化。路径三有机器学习基础但工程能力薄弱。算法背景的读者恰恰和路径二相反你的短板通常在工程一侧数据管道怎么搭建、模型怎么部署、怎么监控、怎么优化推理性能。我建议你把重心放在工程化章节和全链路实战部分尤其是推理优化和服务部署这些部分。这一部分能帮你建立起从模型能做出来到模型能跑在生产环境的完整认知。路径四零基础但目标明确、时间充裕。如果时间和精力都允许我建议完整走一遍整条路线不要跳过任何章节。这条路线设计的顺序就是按依赖关系排好的前面的基石不牢后面会反复回去补课。在我的经验里愿意花3到6个月系统走一遍的人最后对AI工程的理解深度会远超那些只学框架速成的人。无论选择哪条路径我都有一个共同建议每学一个概念尽量在手写代码时亲自验证一遍。从零实现和调用框架的最大区别是你不再是被动的使用者和接受者而是主动的构建者和理解者这种认知方式带来的提升是本质性的。8. 关于项目后续扩展的一些想法ai-engineering-from-scratch项目目前已经覆盖到模型训练、推理优化、评估部署的全链路内容但AI领域变化太快随时都有新的方向值得纳入这套体系。我目前计划扩展的方向有三个第一个方向是大模型应用工程化。这部分的重点不再是如何训练基础模型而是如何围绕大模型构建完整的应用体系包括提示词工程、检索增强生成RAG、Agent设计模式、大模型微调与对齐、多模型协同路由这些内容。这些内容对AI工程师来说是新的能力要求很多传统机器学习技术在这里并不能直接迁移。第二个方向是多模态AI系统构建。文本、图像、音频、视频的联合理解和生成已经成为现实需求多模态数据的对齐、融合、生成在这些场景下有很多新的工程挑战。我正在尝试把多模态模型的结构原理、训练技术、部署优化也纳入体系和实践链条融合在一起。第三个方向是AI系统可靠性工程。包括模型漂移检测、自动回滚、A/B测试框架、安全审计机制等。随着AI系统在越来越多关键业务中承担角色系统的可靠性和可控性会变得越来越重要。这部分的工程实践资料目前还是比较稀缺的我也会持续整理。另外我也会沿着每个核心章节持续补充实操案例和踩坑记录。毕竟AI工程是一个实践驱动的领域通过更多真实案例来表达经验会让整个项目的价值更加完整。