★ FEATURED ARTICLE 1. 从零手搓AI工程为什么我不建议你直接调包很多人一听到“AI工程”这四个字第一反应就是打开某个云平台调一个现成的大模型接口写几行胶水代码然后对外宣称自己做了个AI应用。我承认这条路确实能在半天内跑通一个Demo但如果你真的想在这个领域站稳脚跟靠这种“调包式开发”是走不远的。ai-engineering-from-scratch这个标题背后的核心诉求其实不是让你去重复造轮子而是让你具备一种“拆解轮子”的能力——知道一个AI系统从数据进来到结果出去中间到底发生了什么哪些环节是脆弱的哪些参数是牵一发动全身的。我自己带过不少刚入行的朋友发现一个很普遍的现象他们能熟练使用各种框架但一旦模型效果不好就完全不知道从哪里下手排查。是数据的问题是特征工程没做好是模型结构选错了还是超参数没调对一问三不知。这就是典型的“只会开车不会修车”。而ai-engineering-from-scratch要解决的恰恰是让你从“会开车”变成“会修车”甚至“会造车”。这篇文章适合谁看如果你是刚转行做AI的开发者想搞清楚一个完整的AI工程链路到底包含哪些环节如果你是在校学生课本上只讲了算法公式没讲过工程落地如果你已经工作了一两年但一直停留在调包层面想往深水区走一走——那这篇内容就是为你准备的。我会用从业者的视角把从零搭建一个AI工程体系的关键节点、常见坑、以及那些文档里不会写的经验全部摊开来讲。2. 数据管道的搭建别让你的模型输在起跑线上2.1 数据采集阶段的“脏活累活”任何AI工程的第一步永远都是数据。但很多人对“数据”的理解太窄了以为就是找一堆图片或者文本丢进模型里。实际上数据管道的搭建是一个系统工程它包含采集、清洗、标注、存储、版本管理五个核心环节。我见过太多项目模型结构设计得很漂亮结果因为数据管道没搭好训练出来的东西完全不能用。先说采集。如果你是从公开数据集入手那相对简单但要注意数据集的许可证和分布偏差。比如你做一个情感分析模型公开数据集里可能大部分是英文影评直接拿来训练中文电商评论效果肯定崩。这时候你需要自己写爬虫或者用API去采集目标领域的数据。采集的时候一定要记录元数据来源、时间、采集方式、原始格式。这些信息在后面排查数据问题时非常关键。清洗环节是最容易被低估的。我个人的经验是一个中等规模的项目数据清洗的时间应该占到整个项目周期的40%以上。清洗包括去重、去噪、格式统一、异常值处理。举个例子你做文本分类原始数据里可能混入了大量HTML标签、特殊符号、甚至乱码。如果你不处理模型学到的就是这些噪声。我通常会用一套组合拳先用正则表达式做粗筛再用规则引擎做细筛最后人工抽检。抽检比例至少5%如果发现某类问题占比超过1%就要回头修改清洗规则。2.2 标注质量决定模型上限标注是另一个重灾区。很多团队为了赶进度找一批外包人员随便标一通结果模型训练出来效果差回头查半天才发现是标注数据里错误率太高。我的建议是标注规范一定要写得极其细致最好配上正例和反例。比如做命名实体识别你要明确告诉标注人员“北京”是地名但“北京烤鸭”里的“北京”算不算这种边界情况必须在规范里写清楚。另外标注一致性检验是必须做的。通常我会让至少两个人独立标注同一批数据然后计算Kappa系数。如果Kappa低于0.8说明标注规范有歧义需要重新培训。这个环节虽然费时间但能帮你省下后面反复调模型的巨大成本。我踩过最惨的一次坑是一个项目做了三个月模型F1值死活上不去最后发现是标注数据里30%的样本标错了。重新标注花了两周模型效果直接提升了15个点。这个教训告诉我数据质量就是模型的天花板。2.3 数据版本管理别让“数据漂移”毁了你的模型数据版本管理是很多小团队完全忽略的环节。你想想今天用A版本数据训练了一个模型明天数据更新了你重新训练发现效果波动很大但你根本不知道是数据变了还是代码变了。这时候如果没有版本管理排查起来就是噩梦。我的做法是每次数据更新都打一个版本号记录变更内容、变更原因、变更人。同时训练脚本里要固定数据版本确保实验可复现。工具方面DVCData Version Control是个不错的选择它能和Git无缝集成把大数据文件存在远程存储上本地只保留元数据。如果你不想引入额外工具至少也要用文件命名规范来管理比如train_v1.2_20240501.csv这种格式虽然土但有效。3. 模型选型与训练在效果和成本之间找平衡3.1 不要一上来就上大模型现在大模型很火很多人一上来就想微调一个百亿参数的模型。但我要泼一盆冷水对于大多数业务场景你根本不需要那么大的模型。一个精心调优的小模型在特定任务上完全可以媲美大模型而且推理成本低一个数量级。我通常会根据任务复杂度、数据量、延迟要求、成本预算四个维度来做选型。如果任务简单、数据量小、延迟要求高那就用轻量级模型比如逻辑回归、SVM、或者小型的Transformer。如果任务复杂、数据量大、延迟要求宽松再考虑大模型。这里有个经验公式参数量每增加10倍推理成本大约增加8到10倍但效果提升可能只有几个百分点。所以边际效益递减非常明显。3.2 训练过程中的“玄学”与科学训练模型的时候很多人喜欢凭感觉调参今天调学习率明天调batch size调来调去也不知道哪个参数起了作用。我的建议是一定要做消融实验。每次只改一个变量记录结果这样才能知道每个参数的真实影响。学习率是最关键的参数没有之一。我通常会用学习率扫描的方式先在一个较大的范围内比如1e-5到1e-1跑几个epoch画出loss曲线找到下降最快的那个区间然后再在这个区间内精细搜索。另外warmup策略对Transformer类模型非常重要通常设置总步数的10%作为warmup步数能有效避免训练初期的震荡。Batch size的选择也有讲究。大batch size训练稳定但可能泛化性稍差小batch size泛化性好但训练慢且容易震荡。我的经验是在显存允许的情况下尽量用较大的batch size然后配合适当的学习率缩放。如果显存不够可以用梯度累积来模拟大batch size。3.3 过拟合与欠拟合的实战判断过拟合和欠拟合是训练中最常见的两个问题但很多人分不清。简单来说如果训练集loss很低验证集loss很高那就是过拟合如果训练集loss和验证集loss都很高那就是欠拟合。过拟合的解决方案包括增加数据量、数据增强、正则化L1/L2/Dropout、早停、模型简化。欠拟合的解决方案包括增加模型复杂度、减少正则化、增加特征、延长训练时间。但我要提醒一点不要一看到过拟合就立刻加Dropout有时候问题出在数据分布上加再多正则化也没用。我遇到过一个案例模型在验证集上表现很差排查了半天发现是验证集和训练集的数据分布不一致重新划分数据集后问题就解决了。4. 部署与监控模型上线只是开始4.1 推理服务的性能优化模型训练好了接下来就是部署。很多人以为部署就是把模型文件丢到服务器上写个Flask接口就完事了。但实际生产环境中推理服务的性能优化是一个专门的课题。首先是模型量化。把FP32的模型转成FP16或者INT8推理速度能提升2到4倍精度损失通常控制在1%以内。对于大多数业务场景这个 trade-off 是完全值得的。其次是算子融合把多个连续的操作合并成一个减少内存访问开销。再就是批处理把多个请求攒在一起推理能显著提升GPU利用率。但批处理会引入延迟所以要根据业务场景设置合适的批处理窗口比如10毫秒。还有一个容易被忽略的点是模型预热。服务刚启动的时候第一次推理往往特别慢因为要加载模型、初始化CUDA上下文。我的做法是服务启动后先跑几次 dummy 推理把缓存预热好再接入流量。4.2 监控指标别等用户投诉了才发现问题模型上线后你必须建立一套监控体系。最基础的指标包括请求量、延迟、错误率、GPU利用率、内存占用。但这些还不够你还需要监控模型层面的指标预测分布、置信度分布、特征漂移。预测分布监控能帮你发现数据漂移。比如你的模型是个二分类器训练时正样本占比50%上线后突然变成80%那说明输入数据的分布变了模型效果很可能下降。置信度分布监控能帮你发现异常输入。如果大量请求的置信度都很低说明模型遇到了没见过的数据模式。我通常会设置三级告警黄色告警表示指标偏离正常范围但还不严重需要关注橙色告警表示指标持续偏离需要排查红色告警表示指标严重异常需要立即介入。告警渠道可以用邮件、短信或者企业通讯工具关键是确保有人能看到并响应。4.3 模型迭代与回滚机制模型上线不是终点而是一个新的起点。你需要建立一套模型迭代机制定期用新数据重新训练评估效果然后决定是否上线。这里的关键是A/B测试。新模型上线前先切一小部分流量比如5%做灰度对比新旧模型的核心指标。如果新模型在统计上显著优于旧模型再逐步扩大流量。同时回滚机制必须提前准备好。一旦新模型出现严重问题要能在几分钟内切回旧模型。我见过一个团队新模型上线后效果暴跌结果发现旧模型的文件已经被覆盖了花了半天才从备份里恢复。这种低级错误一次就够你喝一壶的。5. 那些文档里不会写的踩坑经验5.1 环境依赖版本冲突是永恒的痛AI工程的环境依赖是个大坑。PyTorch、CUDA、cuDNN、Python版本之间的兼容性矩阵能让你调到怀疑人生。我的建议是永远用Docker来管理环境。把依赖写进Dockerfile构建成镜像这样无论换多少台机器环境都是一致的。如果不用Docker那至少要用conda创建一个独立环境并且把依赖版本全部固定下来。千万不要用pip install torch这种不指定版本的方式今天装的是2.0明天可能就是2.1行为可能完全不一样。我习惯在requirements.txt里写死版本号比如torch2.0.1并且定期更新和测试。5.2 随机种子可复现性的基石做实验的时候随机种子一定要固定。Python的random、numpy的random、框架的random都要设置。否则你每次跑出来的结果都不一样根本没法对比。我通常会在代码开头写一个set_seed(42)函数把所有能设的种子都设上。但要注意即使设了种子在某些情况下结果仍然可能不同比如多GPU训练、某些CUDA算子。所以对于关键实验我建议跑至少三次取平均值和标准差这样结论更可靠。5.3 日志与实验管理别让好结果溜走最后说一个看似琐碎但极其重要的事日志和实验管理。我见过太多人跑了一个实验效果很好但过两天想复现的时候发现忘了当时用的什么参数、什么数据版本。这时候如果没日志就只能拍大腿。我的做法是每个实验都用一个独立的目录里面包含配置文件、训练日志、验证结果、模型文件。同时用一个表格记录所有实验的关键信息实验ID、日期、数据版本、模型结构、超参数、评估指标。工具方面TensorBoard、Weights Biases、MLflow都是不错的选择。如果你不想用工具至少也要用Markdown文件手动记录。这个习惯能让你在几个月后回头看时依然能清晰地知道当时做了什么。我个人在实际操作中的体会是AI工程和纯算法研究最大的区别在于工程更注重系统性、可复现性和稳定性。一个模型效果再好如果部署不上去、监控不到位、迭代跟不上那它的价值就是零。所以如果你真的想在这个领域深耕不要只盯着模型结构看多花点时间在数据管道、部署架构、监控体系上这些才是决定一个AI项目能否真正落地的关键。
阅读完成 · 觉得有帮助？
