1. 先看清AI工程这件事的本质1.1 AI工程到底在解决什么问题很多人第一次看到ai-engineering-from-scratch这个项目名时第一反应是这又是一个教你怎么调大模型的仓库吧。实际上真正做下来之后你会发现AI工程和调模型之间差了整整一个世界。模型调用只是AI工程链条上最末端的一个环节前面还有数据治理、特征设计、实验管理、评估体系、服务化部署、线上监控后面还有反馈闭环、持续迭代、成本控制。任何一个环节断了模型在离线指标上再好看上线之后也会被打回原形。我见过太多团队砸了几十万GPU算力把模型指标从88%刷到92%结果上线第一天就发现线上请求分布和训练分布完全对不上用户根本不按你数据集里的方式说话。这类问题不会出现在任何一篇模型论文里但会真实地出现在每一个AI工程项目的第二天。所以ai-engineering-from-scratch真正想做的事情不是教你背几个模型的API而是帮你建立一套从问题定义到线上稳定运行的完整工程能力。1.2 从零开始的合理预期先会跑再会飞我建议所有从零开始接触AI工程的人先放弃一个幻想以为AI工程就是搭一个环境、跑通一个notebook、然后调参刷分。真正从零开始的路径比这件事要枯燥得多也扎实得多。合理的预期应该分成三个阶段。第一个阶段你能在本地把一个小规模数据集跑通理解数据、模型、损失函数、评估指标之间的基本关系第二个阶段你能把一个模型做成接口部署到服务器上让它稳定响应真实的请求第三个阶段你才能去谈优化——优化延迟、优化成本、优化效果、优化迭代效率。这个项目标题里有一个关键词特别重要from scratch。它强调的不是用现成的AI平台拖拽几个组件而是自己把整条链路走一遍。这个过程非常笨重但对建立工程直觉极其有用。比如只有你自己从零写过一次数据预处理管线你才会明白为什么网上那些公开数据集跑出来的结果换到真实业务数据上就失效了只有你自己从零部署过一次模型服务你才会理解为什么推理延迟不只是模型计算时间的问题还有网络传输、序列化、批处理策略的影响。好预期设定了接下来我们聊点实际的到底应该怎么设计这条从零开始的路径才能不踩进教程看了一堆、代码一行没写的坑里。2. 从零构建AI工程能力的完整设计路径2.1 先把干活和造轮子分开你需要的最小技能集我见过不少初学者一上来就要自己从零写Transformer说是要打牢基础。我尊重这种想法但你扪心自问你的目标是理解人工智能的原理还是解决工程问题如果是前者那你确实应该从反向传播推起甚至把注意力机制的矩阵运算手写一遍如果是后者你的目标应该是能用合适的工具解决合适的问题并且知道工具在什么情况下会失效。对于一个从零开始做AI工程的人我建议的最小技能集包含这几块缺一不可Python编程能力不是会写脚本而是能写出结构清晰、可维护的模块化代码懂得用类型注解、异常处理、日志记录。数据处理能力熟练操作结构化数据Pandas、SQL和非结构化数据文本、图像、音频理解数据清洗、标注、切分的基本方法。机器学习基础理解监督学习、无监督学习的基本框架知道过拟合、偏差方差权衡、交叉验证的核心逻辑。工程化意识懂得用虚拟环境管理依赖、用Git管理代码、用Docker打包环境、用CI/CD跑自动化测试。部署能力至少掌握一种模型服务化方案比如FastAPI配合ONNX Runtime或者Triton Inference Server。你仔细看这个清单会发现它里面没有任何一项要求你精通深度学习论文。因为AI工程的重点不是发明新算法而是把已有的算法稳定、可靠、低成本地应用到真实场景中。就像你不会要求一个建筑工程师自己发明钢筋混凝土但你一定要求他懂得钢筋混凝土在什么条件下会开裂。2.2 第一个可落地的项目选什么一个参考框架很多从零开始的人卡在第一步学了一堆理论不知道做什么项目。我给出一个参考框架你的第一个项目最好满足三个条件——数据容易获取、任务边界清晰、效果好评估。拿文本分类来说它完美符合这三个条件。你可以用公开的中文新闻数据集做新闻主题分类也可以用电商评论数据做情感分析。数据不需要太多几千条标注样本就能跑起来一个像样的基线。任务边界非常清晰输入是一段文本输出是一个类别。效果评估也很直接准确率、F1分数一目了然。对比一下就知道为什么不要选那些看起来炫酷的项目。比如你一开始就做一个端到端的语音对话机器人数据怎么采集对话质量怎么评估多轮对话的状态怎么管理这些问题任何一个都能让你卡一个月。而文本分类项目从准备数据到部署上线一个周末就能跑通整个闭环。这个闭环带给你的信心和经验远比一个半成品对话机器人有价值。2.3 工程化落地必备的核心环节训练、评估、部署、反馈当你选定第一个项目之后就要开始按工程化的标准来组织整条链路。这条链路看似简单但每一步都有大量的工程细节。训练环节重点在于实验的可复现性。我要求自己的每个实验都记录三个东西代码版本、数据版本、参数配置。如果你只用上次那个模型来指代某个实验那你的实验管理方式一定出了问题。最简单的做法是给每个实验一个编号把对应的Git commit、数据文件哈希、超参数JSON一起存档。别嫌麻烦你在调参两周后会感谢当时的自己。评估环节重点在于评估口径的严谨性。这里最容易犯的错误是只看单一指标。比如二分类问题只看准确率如果正负样本比例是9:1你全预测成负样本也能有90%的准确率但这显然不是一个好模型。所以一定要结合业务场景选择评估指标并且做细粒度的错误分析而不是只盯着一个数字。部署环节重点在于稳定性和延迟。模型文件本身只是部署的一部分你还要考虑输入数据的预处理逻辑、推理逻辑、结果后处理逻辑这些都要封装在服务里。更关键的是你要给服务设置超时、限流、熔断机制防止模型推理异常把整个服务拖垮。反馈环节重点在于数据回流。模型上线之后你要把线上真实请求的数据记录下来定期做抽样分析和重新标注这些数据是下一次模型迭代最宝贵的资产。如果没有反馈闭环你的模型就是一次性用品上线即巅峰然后随着线上数据分布漂移逐渐失效。3. 实操过程一个从零开始的AI工程样例项目3.1 定义问题与数据准备别小看这一步我以一个电商平台评论情感分类项目为例完整走一遍从零开始的流程。这个例子我亲身做过踩过的坑都有代表性。首先是定义问题。业务方告诉你帮我们把用户评论分一下正面负面。如果你直接开始标注数据那就跳进了第一个坑。你得继续追问几个关键问题这个分类结果用来干什么是给运营看趋势还是给用户展示评分还是用于客服工单自动分类不同用途对错误类型的要求完全不一样。给用户展示评分你要严格控制误判负面评论的风险给运营看趋势你只要整体分布大致准确就行了。我当时的做法是先和业务方对齐了一个简单标准用户明确表达不满如质量差、物流慢、客服态度差的评论为负面单纯描述中性事实如收到了包装还行为中性明确表达满意的为正面。这个标准虽然朴素但至少让标注工作有了米。数据准备阶段我从业务后台导出了近一年的用户评论总共约10万条。但这里有个隐藏的深坑线上真实数据的标签分布是极其不均衡的大约80%的评论是正面或者中性只有20%左右是负面而这还是乐观估计。如果直接用全部数据训练模型很容易偏向多数类。我的做法是先随机抽样2000条做人工标注看一下真实的分布情况然后再决定要不要做类别平衡处理。注意这个抽样必须是随机抽样不能只挑那些看起来典型的评论否则你的训练分布就带上了人工筛选的偏差。3.2 训练基线模型别一上来就追大模型数据准备完之后我强烈建议不要直接上预训练大模型。原因很简单你需要先建立一个衡量后续所有改进的基准线。当时我先用TF-IDF特征加上逻辑回归模型跑了一个基线。这个模型看似简单但它至少能帮你回答几个关键问题数据够不够标签质量如何类别是否可分逻辑回归在这种高维稀疏特征上的表现一定程度上反映了数据本身的信号强度。如果TF-IDF加逻辑回归在验证集上能有85%以上的F1说明数据质量尚可后续用BERT族模型还能有显著提升如果连60%都到不了那问题大概率不在模型能力而在数据质量或者标签一致性上。我的经验是一个扎实的基线模型带来的信息量比十个花哨的精调实验都大。基于这个基线我还能快速做错误分析——把预测错的样本捞出来看发现很多错误其实来自数据本身的问题。比如评论这个价格也就这样了被标注为中性但模型预测为负面评论比我想象中小被标注为中性但模型预测为负面。这种模糊标签问题在真实数据中非常普遍而基线的简单决策边界会把这些矛盾暴露得更明显。3.3 评估与调优用错误分析驱动迭代基线模型确认之后我开始上预训练语言模型。这里选择的思路是先用一个中小规模的预训练模型试水比如BERT-base或者RoBERTa-base的中文版本跑通整个精调流程再考虑是否换成更大的模型。精调阶段的几个关键参数我直接分享我的经验值。学习率我一般从2e-5开始如果loss在训练初期出现震荡降到1e-5或者5e-6batch size单卡显存允许的情况下尽量用16或者32太小容易出现梯度噪声epoch数我通常设置3到5个配合早停机制在验证集loss连续两个epoch不再下降时停止训练。这些参数没有绝对最优但它们是一个经过了大量实测检验的起始点。精调之后的提升通常是比较明显的比如F1从85%涨到92%左右。但我更想强调的是真正让模型从92%提升到94%甚至更高的往往不是换更大的模型而是细致的错误分析。我把开发集里预测错误的样本分成了几类逐类分析原因。发现其中一类错误非常典型含有反讽语义的评论比如真棒等了十天终于送到了。模型把真棒当作正面信号但上下文明确是负面体验。这种语义现象单纯堆模型容量很难解决因为反讽依赖的是常识和语境。我的做法是收集历史上已知的反讽表达模式做了一组少量数据增强同时调整了标注指南让标注人员对这类表达有统一的处理标准。还有一类错误来自行业特定的简称和黑话。比如某个电商平台上用户经常说假一赔十刚收到货就降价这些表达包含大量商品属性和平台规则背景。模型没有这类先验知识很难准确判断。对此我专门补充了一批领域相关的中文语料做继续预训练domain-adaptive pretraining虽然只训练了很少的步数但确实带来了可感知的收益。整个过程下来模型最终的F1稳定在94%左右。看起来只涨了9个百分点但每一步都是靠数据和特征上的深耕换来的不是靠无止境地堆模型参数。3.4 部署与服务化把模型变成可用的接口模型训练完成只是开始真正的工程挑战在部署环节。我们的线上服务要求单条评论的处理延迟在200毫秒以内而且要支持高峰期的QPS波动。这里我先做了一个关键决策不使用PyTorch原生的模型服务方式而是把模型导出为ONNX格式用ONNX Runtime做推理。这么做的原因有三层第一ONNX Runtime的推理性能在CPU上通常比PyTorch原生快两到三倍第二ONNX的部署依赖更轻不需要安装完整的深度学习框架第三模型被冻结为计算图之后不容易因为误操作导致推理行为改变。导出过程本身就有不少坑。最典型的是动态维度问题。文本分类模型的输入是token序列而token数量是不固定的。如果导出时过度优化固定了序列长度推理时一遇到超过长度的文本就会报错。我当时的做法是动态轴设置为序列长度维度同时给输入加上一些padding保证batch内的数据维度对齐。封装服务时我用FastAPI搭建了一个轻量的HTTP接口。请求进来之后先做文本预处理分词、转token、截断、padding然后交给ONNX Runtime做推理最后把logits转成类别和置信度返回。这个流程看起来简单但必须把预处理和后处理的逻辑从训练代码中完全复制一份并放到服务代码里再写几个集成测试用例确保训练时的预处理和服务时的预处理输出完全一致。这一步不做线上效果几乎必然会和离线评估有偏差而且你连偏差原因都很难定位。部署上线之后我加了三层保障。第一层是超时控制单次请求超过500毫秒直接返回一个兜底结果不允许拖垮服务线程第二层是限流超过预设QPS的请求直接排队或者拒绝保护下游存储系统第三层是监控记录请求量、延迟分位数、预测置信度分布、类别分布变化这些指标能帮助你尽早发现线上数据漂移。4. 常见问题与排查技巧实录4.1 数据质量翻车最隐蔽的坑数据质量问题是AI工程中占比最高、也最容易被低估的问题。我遇到过很多次模型离线指标看起来不错但上线后效果一塌糊涂最后排查下来往往不是模型的问题而是训练数据本身带着系统性偏差。举一个最典型的例子。训练数据来自业务系统而业务系统本身是有偏的——比如只有购买了商品并且主动留评的用户才会进入数据池那么沉默用户、退货用户、不活跃用户的声音从一开始就缺失了。你的模型被训练成预测留评用户的情感而不是预测所有用户的情感。要识别这类问题唯一的办法是回到数据源头确认数据采集逻辑是否覆盖了你真正关心的对象范围。另外标签噪声也是高频问题。标注员之间的标注不一致率如果超过10%那模型的上限就已经被锁死了再怎么调模型都没用。我遇到过最极端的情况是标注指南里没有定义哪些情况算物流慢导致同一个评论一个标注员认为是负面另一个认为是中性。解决方法是定期抽检标注一致性计算Kappa系数发现低于阈值就回头修订标注指南并重新培训标注人员。4.2 训练复现性差随机种子不是万能的很多初学者以为设置了随机种子就能复现实验结果实际上这是远远不够的。GPU上的某些操作在浮点数运算上存在非确定性即使种子相同两次训练出来的模型权重也可能有微小差异最终导致指标上下浮动0.5个百分点。更隐蔽的问题来自数据混洗。如果你在训练过程中对数据做随机的shuffle但shuffle的顺序没有被种子完全控制那么两次实验的批次组成不同训练过程自然不可能完全一致。我的做法是每次实验固定三个随机种子Python随机种子、NumPy随机种子、PyTorch随机种子并且对数据加载器也设置相同的种子参数同时尽量避免在训练过程中引入依赖系统时间的操作。不过我也要说一句实话工程实践中我们并不总是需要严格可复现更重要的是理解指标波动的范围。如果你的模型在相同配置下跑三次F1在91.5%到92.5%之间波动那你在比较两个实验时就要留出这个波动余量而不是因为一次跑高了0.3个百分点就断定新方法更好。为此我建议重要的实验用多个种子跑平均结果而不是单次运行的结果。4.3 线上效果和线下指标不一致评估口径问题这是AI工程最让人头疼的问题之一而且它的成因多种多样。最常见的成因是特征分布漂移。训练数据是历史数据而线上的用户行为、商品内容、文本表达习惯都在随时间变化。比如我做的评论情感分类模型在年初训练时用户的表达方式还比较传统到了年底平台上开始流行一种新的吐槽句式模型完全没有见过就会大面积误判。应对这类问题的核心手段是持续监控和定期重训。我上线了一套简单的数据漂移检测机制对每日新增的线上文本数据做特征分布统计与训练集的特征分布做对比计算分布距离指标。一旦发现明显漂移就把最新数据加入训练集重新精调。还有一大类线下线上不一致的原因来自评测集和线上分布的错位。很多人习惯把历史数据随机切分成训练集和测试集但这个做法默认了一个假设历史数据的分布和未来数据的分布是一致的。现实中这个假设经常不成立比如某些商品在半年内经历了从冷门到爆款的变化相关评论的主题分布也和早期完全不同。所以我建议用时间切分代替随机切分用某时间点之前的数据做训练用之后的数据做评估这样评估结果更接近真实的线上表现。4.4 资源瓶颈单卡也能做的大事很多做AI工程的人会陷入一个焦虑没有多卡集群是不是就做不了什么有价值的事我明确告诉你不是。绝大多数业务场景下的AI项目数据量在几万到几十万级别这个规模单卡完全可以覆盖。但单卡环境确实需要你在工程上做取舍。第一模型规模要克制。别一上来就用几十亿参数的模型中小规模的预训练模型加上充足的数据迭代已经可以解决大部分问题。第二训练效率要优化。利用混合精度训练显存占用可以减少接近一半训练速度提升一到两倍。第三推理阶段要压缩。量化是一个有效的方案比如把模型从FP32量化到INT8推理速度提升明显精度损失通常可以控制在可接受范围内。我这里特别想强调一点工程上的最优解不一定是技术上的最优解。在单卡环境下如果你的显存只够跑batch size 8那就老老实实跑batch size 8适当降低学习率和训练步数而不是强行把batch size加到32然后频繁OOM。实践已经证明了小batch size配小学习率在很多任务上都能得到稳定的表现。5. 从第一个项目迈向长期的工程能力5.1 建立自己的工程模板库当第一个项目完整跑通之后最重要的并不是立刻投入下一个更复杂的项目而是回头把整个过程中的通用部分沉淀下来形成一套自己的工程模板。我的模板库里现在有几样东西每一件都是从真实的项目里提炼出来的。第一件是数据处理模板包含通用的数据加载、清洗、切分、采样逻辑以及标准的训练集验证集测试集划分流程第二件是训练模板包含实验配置管理、随机种子设置、混合精度训练、早停机制、日志记录的完整代码第三件是评估模板包含分类任务全流程的错误分析脚本能自动把预测错误样本按特征聚类并生成报告第四件是服务模板包含FastAPI应用骨架、ONNX Runtime推理封装、健康检查、限流熔断的完整实现。有了这套模板你新接一个项目时不需要从零开始写代码只需要把业务相关的部分替换掉几天内就能跑通完整流程。模板的意义不在于省那些写代码的时间而在于把你踩过的坑固定成规范避免每个新项目都重新踩一遍。5.2 持续跟进开源生态的正确姿势AI领域更新换代极快但这不意味着你需要每天都追热点。我的做法是给自己设定一个固定的节奏比如每两周花一个下午浏览一遍主流开源社区的更新动态重点关注三类内容自己正在使用的框架发布的新版本升级日志、与业务场景相关的新模型和新方法、社区里讨论度高的工程实践问题。这里有一个比较实用的进阶建议不要只关注有什么新模型更要多关注用什么方式把模型变得好用。比如同样都是做文本分类有的仓库会分享一套完整的prompt模板和few-shot策略有的仓库会分享一个推理加速的工程方案。后者的工程价值往往比单纯换一个新模型更大。另外我强烈建议每个做AI工程的人养成写技术笔记的习惯。不用长篇大论每次记录一个问题、一次排查过程、一组实验结论半年之后回头看这些笔记就是最有价值的参考资料。5.3 避坑清单汇总最后把我在真实项目中反复踩过的坑整理成一个清单给你一个即查即用的自查表虽然不全面但每一条背后都有真实的教训数据泄露问题特别是特征构造时引入了未来信息比如用全量数据的统计值做归一化后再切分训练集这会让评估结果虚高。类别不平衡不处理对比基线时容易被整体准确率迷惑应该结合混淆矩阵和各类别F1一起判断。超参数调试缺乏记录同一条数据被反复试过不同参数最后不知道哪个结果对应哪个配置。线上推理时预处理逻辑和训练不一致这是我最常踩的坑要求必须用同一套代码逻辑处理训练和推理数据。模型文件管理混乱缺少版本号回滚困难建议训练产物统一命名并归档到模型仓库。没有监控线上指标模型悄悄退化而不自知至少要保住请求量、延迟、置信度和类别分布四个指标。6. 写在最后的个人体会我从零开始做AI工程到现在最大的体会是这个领域的门槛不在知识量而在耐心和系统化。知识量靠阅读和动手能很快补上但耐心——愿意花时间把数据看透、把评估做扎实、把部署流程理顺——才是让模型真正发挥价值的分水岭。如果你也在走ai-engineering-from-scratch这条路我的建议很简单先花一个周末把最小闭环跑通再花一个月把它打磨到工程可用。别急着追求新的技术先把手上已有的东西做到稳定可靠。很多年后你会意识到AI工程的核心竞争力不是会用多新的模型而是能把一件看似简单的事情在复杂的现实环境中反复做对。