最近我把一个自己跟了很久的项目收了个尾名字就叫ai-engineering-from-scratch。这名字听起来有点中二说白了就是一件事不依赖现成的 AI 平台或封装好的 SDK纯粹靠开源模型、公开数据集和基础工具把一个能用的 AI 应用从零搭起来。这个过程中踩过的坑、总结出的方法以及我对“AI 工程”这四个字的理解值得单独拎出来写一篇给正在走这条路的人一个参考。这个项目解决的痛点很实际。现在市面上讲 AI 的教程铺天盖地但大多数是“调包侠”路线——装个库、跑通 demo、调用 OpenAI 接口就完事了。一旦要落地到真实业务面对数据清洗、模型调优、算力限制、推理延迟这些问题很多人直接懵掉。ai-engineering-from-scratch这个项目想做的就是把这些被跳过的“中间地带”补齐。适合的人群也很明确有一定 Python 基础、想深入理解 AI 应用背后原理的开发者以及正在做技术选型、需要评估“自建 vs 调用现成服务”的工程师。我把这个项目的完整经验整理成下面四个部分先讲整体设计和思路再拆解核心细节然后给出一条可落地的实操路径最后聊聊我真实遇到的坑和排查方法。1. 整体设计思路为什么选择“从零构建”这条路子1.1 “调包”与“自建”之间的真实差距很多人会问2025 年了开源生态这么成熟何必还要从零开始直接from transformers import pipeline三行代码跑个模型不香吗这个观点没错但它掩盖了一个关键事实从零构建的价值不在“造轮子”而在“拆轮子”。我用一个真实的对比数据来说明。同样是做一个中文文本分类任务调用 Hugging Face 上的现成 fine-tune 模型十分钟就能跑通。但当我尝试把这个模型部署到生产环境时问题接连出现模型体积 400MB 导致首包延迟高达 3 秒CPU 推理单次耗时 2.5 秒遇到特殊标点和网络用语时分类结果几乎随机。这些问题的根源在于我只用了模型却不了解模型内部的工作机制更不知道如何针对自己的业务数据做适配。而ai-engineering-from-scratch项目的核心设计思路就是把整套 AI 工程链路完整走一遍。这条路分成五层数据层采集、清洗、增强、训练层模型选型、训练策略、调优、评估层指标设计、badcase 分析、部署层模型转换、推理优化、服务化、迭代层数据回流、模型再训练。五层缺一环都会导致项目烂尾。1.2 技术路线的选型逻辑在技术选型上我纠结过几个方案最终确定的组合是PyTorch 作为深度学习框架动态图机制方便调试生态最成熟、HuggingFace Transformers 做模型和 tokenizer 管理但不直接用 Trainer自己写训练循环以便控制细节、FastAPI 做推理服务、Docker 做容器化部署。这个组合的选型理由很具体。PyTorch 的动态计算图在调试的时候几乎是降维打击你能在任何一行代码处打印中间张量的形状和值Transformers 提供了统一的模型接口和 tokenizer省去了处理词汇表映射的麻烦我自己写训练循环是为了能精细控制梯度累积、学习率调度和混合精度这些细节在标准 Trainer 里被封装成参数出了问题很难排查。另外我还刻意避开了重量级平台工具比如云厂商的 AI 平台理由有二一是这些平台的抽象层级太高用户的代码变成了配置文件出了问题只能提工单二是从学习成长的角度自己搭一套能跑通全链路的系统对理解 AI 工程的标准结构有不可替代的作用。这个决定让我后期排查问题的效率高了很多因为每个环节都是我亲手搭的哪里可能出现问题心里有数。2. 核心细节拆解数据、模型与训练的关键实操2.1 数据工程的“脏活累活”决定了项目的天花板任何 AI 项目数据工程所占的时间和精力大概在 60% 以上。ai-engineering-from-scratch项目里我用的是公开的中文评论数据集最初拿到的原始数据有多离谱编码混乱、HTML 标签残留、大量重复样本甚至夹杂着无意义的字符刷屏。如果不去管这些直接训练模型精度大概率停留在 70% 上下而且无法收敛。数据清洗这个环节我的具体做法是建立了三级处理流水线。第一级是规则清洗用正则把 HTML 标签、URL、多余空白去掉第二级是语义去重基于 Jaccard 相似度先粗筛一遍再用 MinHash 处理大规模近似去重这步把训练集从 12 万条降到 8.9 万条去重率高得惊人——重复数据对模型训练的影响比噪声数据更严重会让模型对高频句子过拟合第三级是标签校验随机抽检 1000 条样本人工核对标签准确率低于 95% 就返工重新标注。这里有个很多人容易忽略的细节类别平衡性处理必须放在划分训练/验证集之前。我用了分层抽样保证类别比例在三个集合里保持一致。如果先切分再平衡会导致验证集分布与训练集不一致评估出来的指标完全没有参考意义。这套流水线跑完之后训练数据干净了很多后续模型收敛速度和最终效果都明显改善。2.2 模型选型与“小而精”的调优目标模型选型方面我并没有一开始就上 7B、13B 的大模型。原因很简单这项目要验证的是“从零构建”的工程链路而不是堆算力。一个中文场景的分类任务BERT 系列足以胜任。我选了相对轻量的模型参数量 1 亿出头单卡能够轻松训练。但这不意味着任务简单。我给自己设定的调优目标是模型体积压缩到原始大小的 25%推理耗时降低 70%同时精度下降不超过 2 个百分点。为此我做了三步优化知识蒸馏用参数量更大的模型当 teacher把知识蒸馏到小模型上精度损失比直接用小模型从头训练低 50% 左右。动态量化把权重从 FP32 压缩到 INT8模型体积直接减到四分之一CPU 推理速度提升约 3 倍。量化后精度轻微下降但结合蒸馏补偿后效果可以接受。批处理优化在推理服务层实现动态 batching把单条请求的 GPU 推理转变为多请求合并推理吞吐量提升了四倍多。我发现很多人做 AI 项目容易走进一个误区模型越大越好。真实场景里推理延迟、部署成本和功耗往往比精度更重要。这个项目里确定的“小而精”路线本质上是把工程约束纳入模型选型的考虑这是 AI 工程和 AI 研究最明显的区别之一。2.3 训练过程中的“玄学”与科学训练过程中的细节决定了模型能不能收敛。我用了几组对项目影响极大的配置值得记下来学习率调度选用带 warmup 的线性衰减warmup 步数设为总步数的 6%。这能避免训练初期 loss 剧烈震荡。如果不设 warmup前几百步 loss 会出现明显尖峰收敛速度变慢。混合精度AMP自动混合精度在单卡训练中提速明显显存占用下降了约 30%。关键点在于 loss scaling 的配置初始 scale 设大容易溢出设小又可能欠拟合。我按官方推荐 1024 起步遇到 overflow 后会自动调整。梯度累积这个小 batch 模拟大 batch 的技巧实际使用时要注意同步 BN 统计量否则模型效果会有微妙的影响。训练中期出现过一个有意思的现象loss 在稳步下降但验证集上的 F1 值却停滞不动了。排查之后发现问题出在优化器状态和模型状态不同步——由于某个钩子写错了模型在验证时没有切换到 eval 模式Dropout 层还在工作导致验证指标失真。这类“玄学”问题多数是工程细节没做到位而不是模型本身有问题。3. 实操过程从数据准备到推理服务的完整落地3.1 环境搭建与关键依赖版本锁定环境搭建这个环节容易出问题的地方在依赖兼容性。PyTorch、CUDA、Transformers 三个大件版本不匹配会导致各种奇怪的报错比如CUDA error: no kernel image is available for execution on the device这通常就是 CUDA 版本和 PyTorch 编译时的 CUDA 版本不一致。我最终锁定的核心版本组合是Python 3.10、PyTorch 2.1.0CUDA 11.8 版、Transformers 4.36.0。这几个版本经过实测兼容性较好。用requirements.txt锁死版本比用pip install latest稳妥得多。训练代码的结构我用最直白的方式组织# 核心训练循环简化版 for epoch in range(epochs): for batch in train_dataloader: # 把 batch 搬运到 GPU batch {k: v.to(device) for k, v in batch.items()} # 前向传播 outputs model(**batch) loss outputs.loss # 反向传播 梯度累积 loss.backward() if (step 1) % accumulation_steps 0: optimizer.step() scheduler.step() optimizer.zero_grad()这里有个关键操作optimizer.zero_grad()一定要放在梯度累积的完整周期之后执行而不是每个 batch 都清零。如果每个 batch 都清零梯度累积就失效了效果等同于小 batch 训练模型性能会下降。3.2 模型训练与评估闭环训练时我使用了一个全量的评估策略每训练 500 步就做一次验证集评估记录 F1、精确率、召回率三个核心指标。这一步的意图很明确——监控指标曲线的变化趋势比看单点数值更有价值。曲线能告诉你模型是否过拟合、学习率是否设置合理、训练是否陷入停滞。模型训练过程中的 loss 曲线如果出现“断崖式下跌”不用高兴很可能是数据问题比如某类样本特别多导致模型快速偏向该类。如果出现“loss 平台期”先尝试调整学习率再考虑加大数据增强力度。我实际遇到的情况更隐蔽loss 正常下降但验证集 F1 在第十七万个 step 附近突然涨了十个百分点。后来查日志发现是数据预处理时 Tokenizer 的截断策略在中途被不小心改掉了导致训练数据前后分布不一致。这不是模型“突然变聪明”而是数据“突然变简单”。这提醒我任何环节的改动都要留下记录否则排查起来感觉在读天书。3.3 模型转换、压缩与服务化部署训练完成后进入部署环节。这个环节的流程是模型导出 → 量化压缩 → 编写推理服务 → 容器化打包。模型导出这里有个大坑直接torch.save(model.state_dict())保存的是权重但部署时需要完整的模型结构。正确做法是导出为 ONNX 格式或者保持 Transformers 的save_pretrained格式。我选择 ONNX 导出因为 ONNX Runtime 在 CPU 上的推理优化做得更好而且部署环境不用装 PyTorch依赖大幅减少。量化这步我用了动态量化代码大概长这样import torch quantized_model torch.quantization.quantize_dynamic( model, # 原始模型 {torch.nn.Linear}, # 只量化 Linear 层 dtypetorch.qint8 )注意量化时如果模型里有 LayerNorm 这类对数值敏感的层要格外小心动态量化后精度波动最明显的往往不是 Linear 层本身而是它后面的激活分布变化。我加了几个代表性样本做校准帮助模型适应量化后的数值分布。推理服务我用 FastAPI 写了一个极简接口接收文本、返回分类结果和置信度app.post(/predict) async def predict(text: str): inputs tokenizer(text, return_tensorspt, truncationTrue, max_length128) with torch.no_grad(): outputs model(**inputs) probs torch.softmax(outputs.logits, dim-1) confidence, label probs.max(dim-1) return {label: id2label[label.item()], confidence: float(confidence.item())}部署成 Docker 容器时镜像体积的控制是个技巧活。基础镜像选择python:3.10-slim比全量版小了近 1GB安装依赖时顺手清理 pip 缓存。最终镜像体积控制在 900MB 左右其中模型文件就占了 300MB。如果想进一步压缩可以考虑挂在外部存储卷上而不是打进镜像。4. 常见问题与排查技巧实录4.1 训练不收敛的排查思路训练 loss 一点都不降是每个 AI 工程师都遇到过的问题。我的排查顺序是先看数据、再看模型、最后看训练配置。数据问题检查标签是否错乱、文本是否被错误截断、类别分布是否过于失衡。有一次我的 loss 一直降不下去查到最后发现是标签映射文件编码错了导致所有样本的标签都是同一个类别。模型问题换一个极小的数据集100 条跑过拟合测试如果小数据都过拟合不了那大概率是模型结构有 bug。训练配置问题检查学习率是否过大或过小。学习率过大容易导致 loss 爆炸过小则龟速收敛。4.2 推理服务的内存泄漏服务上线后跑了大概两天内存占用从 200MB 逐步涨到 1.2GB最后触发 OOM 重启。这个问题的根源在于 PyTorch 的推理模式没有正确使用。我最初在预测接口里写的是model(inputs)这会构建完整的计算图导致内存不断累积。修复方式很简单——加torch.no_grad()装饰器或者进入torch.inference_mode()上下文。但最容易被忽视的是 tokenizer 端的缓存问题。如果每次请求都重新加载词表内存自然扛不住。正确做法是在服务启动时一次性加载到内存后续请求复用。4.3 量化后效果崩塌的抢救方案动态量化后我遇到过一个精度崩塌的问题F1 从 0.87 掉到 0.65。排查发现问题出在模型里有一层自定义的注意力掩码实现这层实现没有注册为量化可忽略的模块导致量化器尝试量化它时产生了灾难性的数值误差。解决办法是对特定模块设置白名单禁止量化该模块torch.quantization.quantize_dynamic( model, {torch.nn.Linear}, # 只量化指定层类型 dtypetorch.qint8 )然后手动把不稳定层保持为 FP32。经过逐步排查最终量化和未量化的模型精度差距控制在了 1.5 个百分点以内符合预期的“不超过 2%”的目标。4.4 服务启动慢和并发瓶颈服务刚上线时冷启动需要 5 秒以上其中大部分时间花在模型权重加载上。解决办法有两个一是把模型序列化格式从pytorch_model.bin转换为更轻量的 safetensors 格式加载速度提升了 30%二是在 Docker 启动脚本里增加预热请求——服务起来后自动发送一条预测请求把模型真正加载到显存/内存里避免第一个用户请求撞上冷启动。并发处理上FastAPI 默认线程池在 GPU 推理场景下容易把显存打满。最终采用了异步队列方案请求进来先入队推理线程从队列里批量取数据合并成一个 batch 做推理结果再按顺序返回。这个方式和第 2.2 节提到的动态 batching 是同一个思路在真实业务里效果非常明显。5. 沿着这条路还能走多远项目主体已经收尾但我自己的探索没有停。目前的版本解决了文本分类这个经典场景的全链路构建而接下来的扩展方向也清晰——把同样的方法平移到其他任务如文本相似度匹配、命名实体识别上在不同任务中验证这套工程流程的通用性。另一个让我感兴趣的方向是把向量检索纳入系统做成一个小规模的 RAG 应用这是目前从零构建 AI 应用最实用的路径之一。关于ai-engineering-from-scratch这个项目我个人的体会是AI 工程的能力不是靠看文档和调参学会的必须完整地经历一遍“从数据到产品”的闭环。这个过程里的每一个 bug 都在教你理解系统的运行逻辑而不仅仅是模型的行为。这条路不轻松但它带给你的是任何现成工具都给不了的东西——对系统的整体掌控感。最后分享一个实操中总结的小技巧每完成一个里程碑把当时的依赖版本、关键配置、踩过的坑整理成一个NOTES.md放在项目根目录。三个月后再回来看这份记录的价值比任何文档都高。因为 AI 工程迭代太快记忆不可靠而笔记是最忠实的技术合伙人。