从刚收到这个项目标题ai-engineering-from-scratch的时候我其实挺有感触的。因为单看这个名字像是一个GitHub仓库的目录名又像是一个人给自己定下的学习路线图。在AI领域待久了你会发现真正卡住大多数人的不是学不会某个模型而是不知道怎么把学到的零散知识点串成一条能落地的工程链路。这篇内容就是想围绕这个标题把我自己走过的那条路——从只会调包、到能独立搭出一套完整AI应用的路径——拆开揉碎了讲清楚。无论你是有编程基础刚开始接触AI还是已经在做算法但总觉得工程化能力不够这篇文章应该都能给你一张还算清晰的地图。1. 重新理解from scratch不是从零实现而是从底层打通1.1 AI工程不等于调模型更不等于写论文先泼一盆冷水。很多人听到AI工程四个字第一反应是我要去训练一个大模型第二反应是那我是不是得先把线性代数、概率论刷一遍。这两个想法都容易把人带偏。我见过太多这样的案例一个人花了几周时间啃完了《机器学习》前五章觉得梯度下降懂了、反向传播懂了结果一上手TensorFlow连数据管道怎么搭都不知道。反过来也有一类人GitHub上收藏了几百个仓库能跑通各种开源项目的README但问他这个模型上线之后怎么监控效果他完全没概念。AI工程的核心是把模型能跑变成系统能用。这里面包含了数据怎么来、特征怎么算、模型怎么训练、怎么评估、怎么部署、怎么监控、怎么迭代。它是一个完整的闭环而大多数人只盯住了训练这一步而且是带着训练就是写个fit()函数的理解去盯的。所以from scratch这个表述我理解的不是从零手写Transformer而是说你要从最底层的数据流和工程机制开始理解把你之前依赖的现成框架、云服务、AutoML工具一层层剥开搞清楚每个环节里到底发生了什么。这个剥开的过程才是真正建立起AI工程能力的过程。1.2 为什么现在特别值得走一遍完整的落地链路一句话因为工具越来越便宜而工程判断力越来越值钱。现在随便一个开源模型推理能力都比三年前的付费API强。你可以在几小时内用现成工具调出一个不错的模型甚至不用写训练代码。这说明什么说明做一个模型的门槛已经被打得很低了。但问题反而变得更难了你的数据质量行不行你的评估指标选对了吗你的上线方案能不能扛住真实流量模型精度掉了你知不知道是怎么掉的这些问题没有任何工具能替你回答。我之前帮一个团队做项目他们的算法工程师花了两周微调模型离线指标涨了三个点兴冲冲要上线。我问了一句你的线上评测集跟训练集的分布差距多大他愣住了因为他的训练数据是从公开数据集拼的实际业务的用户行为数据根本没接进来。结果一上线线上效果肉眼可见地崩了。这不是模型的问题是工程链路的问题——数据流根本没打通。这就是为什么from scratch走一遍这么重要。你需要亲手搭数据管道、亲手写评测脚本、亲手部署一次服务、亲手处理一次线上事故你才能真正理解那些开源工具解决了什么问题也才能在你的业务场景里做出这里该用什么、那里为什么不行的判断。1.3 这条路径适合什么人坦诚地讲不是所有人都需要走这条路。如果你只是想在简历上多写一个熟悉AI的关键词那没必要让自己遭这个罪。但如果你是这几类人我强烈建议你认真把这条路走完有两年以上后端或数据工程经验想往AI方向转型的工程师。刚读完机器学习相关课程但不知道下一步该干什么的学生。已经在用AI API做业务但觉得调接口天花板太低、想做更深入方向的人。小团队里唯一要负责AI能力的全干工程师没人帮你兜底你只能自己把链路打通。如果你是这些人那接下来的内容基本就是为你准备的。2. 打好地基AI工程基础技术栈的搭建顺序2.1 先别急着学框架把Python工程能力补上很多人一上来就PyTorch、TensorFlow、Transformers轮着上学了两个礼拜发现单独看每个API都懂一组合起来就报错。原因不是框架难而是Python工程能力不过关。AI工程的代码和普通后端代码有一个显著区别它混合了IO密集和计算密集的逻辑而且数据离线流程和在线服务的形态差异很大。没有扎实的Python基础你连数据管道里一个简单的generator用不好就可能导致内存炸掉。我个人建议在进入框架之前先把这几块吃透虚拟环境管理venv、conda、uv这些至少得会用一种而且要理解为什么需要隔离依赖。文件IO与路径处理os.path、pathlib、glob这些基础但天天用。数据处理的基本功用纯Python处理结构化数据的常见模式别一上来就用pandas。装饰器、上下文管理器、迭代器生成器这决定了你能不能写出优雅的数据管道代码。日志和异常处理训练跑了两天崩了你要是连日志都不会打就只能干瞪眼。注意这一步不需要达到Python开发专家的水平但至少要能在不查资料的情况下写出一个体面的数据处理脚本。我见过太多人败在这一步后面所有环节都跟着拖累。2.2 Git、Linux和Docker绕不开的工程三件套如果说Python是你的脑子那Git、Linux和Docker就是你的手和脚。AI工程不是单机游戏你要跟数据集打交道、要跑分布式训练、要把模型部署到服务器上这些东西一样都躲不开。Git这一关重点不是背命令而是理解合作模式。你在开发时一定会遇到这种场景你改了一个训练脚本你同事改了另一个你们俩同时commit冲突了怎么办这种问题面试不会问但实际干活儿天天碰到。你需要熟练使用分支管理、cherry-pick、rebase这些操作并且养成每个commit都有清晰信息的习惯。Linux方面至少要做到在服务器上不慌。文件权限搞不定、磁盘满了不知道怎么清、nvidia-smi输出的信息看不懂、日志不会用grep管道去筛——这些看起来很小的问题在实际训练和部署时都会变成大坑。Docker则是个分水岭。能不能写出一个干净的Dockerfile基本决定了你的模型能不能在别人的机器上重现。我见过一个项目算法工程师本地跑得好好的交付给部署团队的时候环境装了两天都没跑起来——就是因为没有容器化。从工程实操的角度我建议你按下面这个顺序来练手先在一台Linux机器上装好Python和GPU驱动然后用Git管理你的第一个代码仓库最后把整个环境打包成一个Docker镜像推到镜像仓库里。这一步做完你才算有了别人能用你代码的基础。2.3 数学知识补到够用就行接着说说数学。这可能是很多人最焦虑的一块但我想给你吃颗定心丸做AI工程数学不需要学到数学系的深度但有几个概念必须扎实到直觉化向量和矩阵运算因为你的数据本质上都是张量理解shape的变化规则能帮你避免大量报错。梯度与反向传播的直觉不需要会手动推导完整的链式法则但你要理解loss下降和参数更新是怎么回事。概率论的基本统计量均值、方差、分布、采样这些在数据处理和评估时天天用。损失函数的几何含义为什么回归任务用MSE分类任务用交叉熵这不是随便选的你要理解背后的概率解释。说白了工程需要的数学是给它一个公式你能大概知道它想干什么的程度。更重要的是你要会做数值验证——当你怀疑某个实现不对你可以拿一个小例子手算一遍再跑代码对比结果。这种验证能力比背公式实用得多。3. 工程化核心技能数据和训练不能只靠跑通3.1 数据管道设计的四段论数据是AI工程的起点但也是最容易被低估的部分。很多新手拿到数据之后第一件事是数据清洗然后直接丢给模型训练。这个流程本身没问题问题在于少了一个关键环节理解数据的来源和语义。我自己的经验是一条好的数据管道应该分成四段第一段数据接入。不管数据在数据库、云存储还是日志文件里都要有一套稳定的方式把它们拉下来并且保证拉取过程可重入——就是说断了可以重来而不是跑了一半数据交叉了。第二段数据校验。这一步很多人跳过但恰恰是最省时间的。你需要检查字段是否有缺失、类型是否符合预期、数值范围是否合理。别小看这一步训练时出现的各种奇怪问题大概率是数据校验没做好。第三段特征工程。把原始数据转换成模型能用的形态。这里有个经验是特征处理逻辑必须在训练和上线时保持一致。如果你在训练时用了一个特征工程的类上线时又为了性能重写了一遍几乎必然会出现线上线下不一致的bug——这可比模型精度低了麻烦得多。第四段样本存取。把处理好的样本存成统一格式。一般建议直接用TFRecord或Parquet这类列式存储而不是CSV。不仅能节省大量存储空间加载速度也是天壤之别。我之前接过一个项目他们一直说模型的效果时好时坏。我一看他们的数据处理代码每次训练前都从原始日志里现做特征结果不同日期的数据分布波动很剧烈。后来我帮他们改成每日批处理生成特征快照 训练时直接读快照的方案问题彻底解决——因为特征分布的可复现性回来了你才知道模型表现变了是数据变了还是模型变了。3.2 训练脚本的正确打开方式训练这块新手最常见的错误是把训练代码和业务逻辑搅在一起或者在一个Jupyter Notebook里又训练又画图又存储结果代码跑完一遍根本没法复现。一个合格的训练工程流程至少要有这些组成部分配置管理。超参数、数据路径、模型结构这些全部外部化用一个配置文件控制而不是把参数硬编码在代码里。即使你是一个人写代码三个月后再来看这个项目你也会感谢当时的自己做了这个决定。可复现性。随机种子固定好了环境依赖记录好了数据版本固定了。做到这一步你才能放心地说我这次训练效果变差了是因为我改了模型结构而不是因为运气不好。实验记录。每一组实验的参数、指标、模型文件、日志都要有地方存下来并且有统一的命名规则。不要把实验记录放在聊天记录或者本地文件名里。哪怕早期用个CSV记录都好但一定要有。训练循环的可视化。loss曲线、学习率变化、梯度范数这些值在训练时要实时能看到。不是说你必须盯着屏幕看而是出了问题你能第一时间发现而不是等两天的训练结束了才知道早就跑偏了。我看到不少开源项目的训练代码其实写得一塌糊涂靠的是框架的默认行为和运气在跑。但你要按工程标准来做该拆的模块拆开该留的日志留好。这样你调模型的效率会高出一个档次——因为你永远知道上一次做对了什么、做错了什么。3.3 评估不只是算个准确率评估这一块我想多说两句因为这是区分调包侠和AI工程师的分水岭。很多人在一两个公开数据集上看到点指标就兴冲冲觉得模型能用了但放到真实场景里完全不是一回事。关键是你的评估方式要对齐你的业务目标。举个例子你做的是一个商品推荐系统离线你算AUC0.75看着还行。但业务上真正关心的是曝光转化率AUC涨了0.01跟转化率之间是什么关系如果回答不了这个问题你的离线评估再严谨业务方也不会认可。评估指标之外更重要的是构建一个维度丰富的评测集。除了标准测试集你至少要分出来这几类正常场景集用来回归验证整体性能没有退化。边界场景集包含各种罕见的但真实可能发生的输入看看模型在极限情况下表现怎么样。噪声场景集故意加入一些脏数据、乱序数据模拟线上真实输入。分群体评估如果你的用户群体有明显的子群按子群分别算指标防止平均指标好看但某些群体全崩。这些工作很繁琐但它是你能在模型上线前发现问题的最后一道防线。花两三天把评测集建好能帮你省下上线后踩坑的一整个月。4. 部署与监控模型上线才是工程真正的开始4.1 模型部署的三种典型形态模型训练完了离线评估也过了接下来就是上线。部署方式没有标准答案取决于你的业务场景但大致可以分为三种形态。第一种是离线批量推理。比如每天的报表预测、批处理打标签。这种场景不需要在线服务跑一个定时任务就行。工程重点在于任务调度和结果可追溯模型输出要落库方便事后分析。第二种是在线API服务。模型作为一个HTTP服务对外提供推理能力。这种形态的技术栈很成熟FastAPI这类工具负担得起大部分场景。重点在于服务的吞吐、延迟和可用性设计模型推理通常要和业务代码分开部署这样模型升级时不用重新发布整个业务应用。第三种是边缘或嵌入式部署。如果模型要跑在手机或IoT设备上你就需要做模型压缩用量化、剪枝、蒸馏这些手段把模型变小变快。这是最考验工程能力的一种因为资源约束极其紧张一个算子一个算子的性能都要抠。我在实际项目里最推荐的做法是一开始就用容器把模型服务包起来通过一个统一接口对外暴露推理能力。这个接口的内部实现是可以替换的——今天用PyTorch明天换ONNX后天换Triton只要接口协议不变对上层业务没有影响。这样一个小的架构决策能让你后续持续优化模型的路径顺畅很多。4.2 性能调优不只是加GPU部署完之后你大概率会遇到性能问题。这时候很多人第一反应是加机器或者上更好的GPU。但你应该先搞清楚瓶颈到底在哪里。按我的排查习惯顺序是这样的第一看数据预处理占了多久。很多模型服务慢不是因为推理慢而是因为请求里的JSON解析、特征拼接这些Python代码太慢了。有时候把这些逻辑优化一下性能能翻倍。第二看推理过程的batch策略。GPU是并行计算设备一次处理一个请求和一次处理八个请求的时间差不了太多。所以有条件的场景可以做动态batching——攒几个请求一起推理——这是提升吞吐最有效的手段之一。第三看模型本身的优化空间。比如推理时关掉梯度计算、用torch.no_grad()、开启cudnn.benchmark、尝试FP16推理、把模型转成ONNX再优化一遍。这些操作都不复杂但很多人根本没想到要去用。如果这几个层面都看过了还是慢这时候再考虑上多实例或者分布式推理也不迟。总之核心原则是先定位瓶颈再谈资源扩容不要一拍脑袋砸钱。4.3 监控必须处理的三类信号模型上线后你的工作才真正开始。因为线上的环境不是静态的今天的数据分布和明天的可能就不一样。不做好监控模型在线上烂了几天你可能都不知道。我建议至少监控三类信号第一类是系统指标。服务QPS、延迟P50/P99、错误率、GPU利用率。这些指标告诉你服务还活着没有。第二类是数据指标。在线输入特征的分布和训练时的分布差异有多大。这是数据漂移的早期信号你可以通过统计每个特征的均值、方差、取值频率来做监控。第三类是业务指标。转化率、点击率、用户满意度这类真实业务指标。这个需要跟业务方配合定义清楚。监控建立起来之后还有一个配套动作模型版本管理。每次上线的模型要有独立的版本号要能快速回滚到上一个版本。模型文件和配套的特征处理代码、评测结果都要绑定在一起。没有这套机制一旦线上出问题你连现在跑的是哪个版本的模型都说不清排查起来就是灾难。5. 一次完整的AI工程实操三阶段路线图5.1 阶段一完成一个带API的端到端小项目很多人会纠结我应该先做个什么项目其实答案很简单先做你日常能用一个小时写出来的、最无聊的AI应用。比如图片分类、文本情感分析或者做一个API调用开源模型做摘要。这个阶段目的不在做着玩而在于打通流程。你需要经历用Python写一个数据下载和预处理的脚本把数据从原始状态变成模型输入。用现成框架训练一个模型或者直接加载一个预训练模型做推理。把推理逻辑封装成一个FastAPI服务。在本地用curl测试接口确认输出符合预期。写一个Dockerfile把整个服务打包跑通容器化部署。完成这一步你就算跨过了AI工程的门槛——因为你已经经历了一次完整的从数据到服务的流转。5.2 阶段二做一个需要自己处理数据的项目第一阶段做完之后你需要找一个数据比较脏的场景来练手。最典型的是爬一些公开的文本数据或者用你工作里真实的数据脱敏后。这个阶段你不再用别人整理好的数据集而是要自己处理数据获取、清洗、质量校验这一整套流程。核心训练目标有三点你会真的遇到数据里全是噪声的情况逼着自己写清楚数据校验逻辑。你会意识到特征工程在真实数据上没那么轻松而且特征逻辑的一致性问题会第一次暴露出来。你会开始考虑数据版本管理因为你会发现自己改了一版清洗逻辑后之前的结果无法复现了。这个阶段可以多花点时间因为数据能力是AI工程区别于纯算法能力的核心差异。5.3 阶段三做一个包含训练、部署、监控的完整系统第三步就是把之前的能力全部串起来做一个完整系统。我的建议是做一个推荐系统或搜索排序类的项目因为这类项目天然包含完整的闭环数据回流、特征更新、模型周期性重训练、在线推理、效果监控。具体来说这个系统至少包含这些模块离线任务管道每天定时拉取数据生成特征快照触发训练或增量微调。模型仓库记录模型版本、训练配置、评测结果。在线服务读取最新模型版本对外提供推理接口。监控与报警定期检查线上特征分布和业务指标发现异常时自动告警。回滚机制当监控发现效果下降时能快速切回前一版模型。做完这个系统你能自信地在简历上写具备从数据到模型到上线监控的完整AI工程实践经验这句话比任何单个模型比赛的获奖都有说服力。5.4 贯穿全程的关键能力代码设计意识最后再补一个贯穿三个阶段的底层能力——代码设计。AI工程代码跟写算法题不一样它是长时间演化、多人协作、不断改动的活系统。如果一开始没有设计好代码结构后面每次改需求都是一次灾难。我给你几个具体的建议把数据读取、特征转换、模型定义、训练循环、评估逻辑拆成独立模块接口尽量清晰。不要全局修改变量所有配置通过传参或者配置对象传递。给自己写一个常用的项目模板每个新项目从模板起步可以在模板基础上快速迭代。关键节点留出日志尤其是数据处理和评估环节方便排查问题。代码设计这件事没有标准答案但有一条红线让未来的人包括你未来的自己在接手代码时不会想要砸掉电脑重写。6. 踩坑实录AI工程路上最常见的五个问题6.1 训练Loss不降反升是怎么回事这是新手最容易懵的问题。模型训练了两千步loss不仅没降还越来越高。我的排查顺序一般是先排除代码bug。最常见的是数据没做归一化或者标签跟特征对不上尤其要注意数据shuffle的时候特征和标签是不是同步的。再排除学习率问题。如果loss直接爆到NaN大概率是学习率太大了可以试着把学习率调小十倍看看反应。然后观察不同阶段的loss。如果前几步降得很快然后突然不降了甚至反弹那可能是模型结构问题或者优化器参数没调好。最后再怀疑模型本身是否能收敛。有时候拿一个很小的样例数据先过拟合一下如果小样例都学不到理想效果那就是模型结构或数据本身有问题不用浪费算力在大数据集上瞎试。6.2 GPU利用率很低核弹显卡用出了集显的效果很多人一看自己的GPU利用率只有20%就慌了。先说结论不是所有场景都适合追求GPU高利用率。NLP里很多操作是逐token处理的本身并行度就有限。但如果你确实觉得需要榨干GPU可以从这几个方面检查DataLoader的num_workers设了没有默认是0意味着主进程在同步加载数据。设成4或8往往有明显改善。训练循环里有没有在GPU和CPU之间频繁来回拷贝数据。是不是模型太小计算量还没数据加载的时间长。Batch size是不是太小GPU没有足够的计算任务来填充。有一个经典的经验是GPU利用率低于50%的时候先不要急着优化模型结构大概率是数据管道拖了后腿。6.3 数据泄漏评估指标虚高的头号嫌疑人数据泄漏是AI工程里最隐蔽的坑之一。表现形式千变万化但本质只有一个模型在评测时看到了它不应该看到的信息。最常见的是时间序列场景的数据泄漏。比如你用某段时间的数据做训练集后面时间的数据做测试集如果特征里包含了未来窗口的统计值那评估结果就是假的。还有一种泄漏发生在数据预处理阶段。如果你在划分数据集之前就做了全局的标准化那测试集的信息已经通过均值方差混进了训练集指标虚高几乎是必然的。对付数据泄漏唯一的办法就是建立一个严格隔离的数据处理流程把数据划分放在所有操作之前一切预处理只基于训练集统计信息。养成这个习惯能帮你避免90%的泄漏问题。6.4 本地能跑通上线就出错这是一个让人血压飙升的场景代码在本地明明跑得好好的一部署到服务器就报错。排除环境问题之后最可能的原因是数据输入的形态不一致。本地文件读出来的参数和线上请求的格式在类型、维度上有细微差别。环境配置硬编码了本地路径。这是最经典的模型加载路径写死成了本地的绝对路径。依赖版本不一致。本地装的是PyTorch 2.1线上还是1.13API行为可能完全不同。解决办法也很直接从一开始就坚持所有路径用相对路径依赖用lock文件管理每次部署前先在一个全新的容器环境里跑一遍测试用例。这个习惯能救你很多次。6.5 模型精度掉线Az***下线时才发现模型上线一段时间后效果逐渐下降这是必然而不是偶然——因为数据分布一定会漂移。关键是你能不能及时发现、能不能定位原因、能不能快速恢复。我的建议是从一开始就要建立定期评估机制。哪怕是一个最简单的每日任务把线上采样的数据打上标签计算指标画趋势图。数据的漂移越早发现代价越小。如果发现指标下降了先核对这些数据源变了吗上游特征逻辑改了吗模型版本有没有被误替换如果这些都没变那就基本确定是环境数据漂移了触发重训练流程。这一套流程的完善程度才是AI工程能力真正高低的体现。7. 工具选型心得与学习资源配置7.1 框架怎么挑从PyTorch出发现在这个阶段如果你不是有特殊的历史包袱我建议直接从PyTorch入手。原因不是PyTorch比TensorFlow更厉害而是它的社区生态、学习资料、模型库都更加匹配当前的实际需求。用一句话概括TensorFlow当年是为了工业部署而设计PyTorch是为了研究而设计。但风水轮流转现在PyTorch的部署生态也赶上来了ONNX、Triton这些工具的成熟让PyTorch模型的落地变得很轻松。在你把PyTorch用得比较顺手之后至少要了解一次ONNX或者TensorRT。不用很深入但要理解模型导出为通用中间表示再优化这件事的存在——它是模型高性能部署的重要一环。7.2 MLOps工具别贪多一个做精就够了现在的MLOps工具琳琅满目MLflow、Weights Biases、Neptune、Kubeflow每个都能说一堆优势。但我的建议很直接前期别贪多选一个能解决核心问题的做精。如果你是一个人在做项目MLflow是个不错的起点。它同时覆盖了实验记录、模型打包、注册管理这几个环节。你在本地先用它跑起来理解实验记录 模型仓库这个概念后面换任何企业级工具底层逻辑都是相通的。关键是自己要会思考这个工具解决了什么问题它留下什么没解决你的流程里还缺什么。工具永远比流程迭代得快但流程能力是你自己的工具不是。7.3 学习资源怎么选官方文档优先于速成课关于学习资源我只有一个核心建议优先看官方文档不要沉浸在短视频和速成课程里。这不是说那些内容没用而是它们有自己的局限——为了让人快速上手它们会省略大量关键细节而这些细节恰恰是工程上区分好坏的要点。我自己的习惯分三步走先快速看看官方Tutorial了解基本概念然后带着自己的问题去读官方API文档不要求全读但相关的页面要精读最后是读一到两个高质量开源项目的源码重点关注数据管道和训练脚本的组织方式这比读一千篇经验帖都管用。当然理论也得补一点基座。如果你有一定的精力最简单的入门书建议一本李航的《统计学习方法》一本书够了。不用题海战术重要的是建立机器学习方法在解决什么问题的框架感。之后你再去看任何新模型新框架都能快速归位到它属于特征提取还是模型优化还是评估策略的哪个环节里。8. 写在最后做AI工程保持从零开始的心态说到这儿我想起来最初这个项目标题ai-engineering-from-scratch其实还有另一层意思。即便你已经做了很多年AI工程每一个新项目依然值得你从零开始审视一遍你的数据从哪来、经过了怎样的变换、模型帮你做了什么决策、这个决策出了错会有什么后果。我自己的体会是AI工程这个领域每一个具体技术都会过时但搭链路、做评估、控风险的底层能力永远不会过时。今天你花时间搭的数据管道、写的可视化脚本、建的监控告警可能在下一个项目里全都重构重写但你在搭建这些过程中建立起的工程直觉和经验判断才是你真正的积累。最后分享一个小技巧无论你正在做什么AI项目都养成写项目日志的习惯。每天在项目日志里记三件事——今天准备解决什么问题、用什么方法、遇到了什么障碍、最终结论如何。坚持下来你会发现三个月后回看这些日志它们比任何代码注释都更能帮助你快速进入状态也更容易找出问题出现的根源。AI工程这条路很长从零开始并不可怕。真正需要担心的是一路走一路丢失去了对系统的整体感知。希望这篇梳理对你有一点点帮助能让你在这条路上走得更踏实一点。