“ai-engineering-from-scratch”这个标题我一开始以为是个学习路线图真正做下来才明白它指的是把一个AI项目从零到一完整落地、推到线上并持续维护的全链路过程。训练模型只是其中一小块数据管理、代码组织、评估体系、部署监控、成本计算每一环都能让你头疼好几天。这篇文章把我实践这个项目时的完整思路、关键决策、具体步骤和踩过的坑整理出来适合刚入行的算法工程师、想转AI工程化的后端开发以及准备带AI项目但不知道从哪里下手的同学参考。1. 先盘清楚from scratch 做的到底是什么项目1.1 明确项目边界不是炼丹是交付很多人一看到“from scratch”就以为是写神经网络、从零实现反向传播。我刚开始也差点走偏天天刷论文、看源码研究各种模型结构的细节。做完一个完整项目之后我才意识到真正的AI工程强调的是“交付”你手里的模型能不能被人用起来能不能稳定跑在线上出问题了能不能快速定位并修复。我实践的案例很具体做一个客服工单自动分类系统。输入一段用户反馈文本输出工单类型比如账号问题、支付问题、退款申请、技术故障并且要提供一个HTTP接口让业务系统调用。这个项目看起来简单但涉及到的环节一点不少数据怎么来、标签怎么定、模型怎么选、效果怎么评估、服务怎么部署、延迟怎么控制、模型怎么更新。这些环节串起来的完整链路才是“ai-engineering-from-scratch”真正要解决的问题。从零开始意味着你不能依赖别人已经封装好的一整套推荐系统或者现成的SaaS平台去蒙混过关每一层的技术选型都需要自己判断。这个过程会很吃力但一次走通之后后面再遇到类似项目你会很清楚自己的精力应该花在哪里。1.2 设定目标与成功标准先定义什么叫做“做完了”动手之前我花了一周时间做目标拆解。很多人对这个环节不重视上来就开始写代码结果做到一半发现评估指标没定义、数据分布和线上不一致、模型效果说不清楚返工成本极高。我给自己定的成功标准有五个模型在真实分布的数据上F1值能达到0.85以上我选了宏平均F1因为类别不平衡单次推理P95延迟在300毫秒以内服务支持每秒20个并发请求不崩溃有完整的日志和基础监控接口调用量、错误率、响应时间可查有可复现的实验记录不管谁拿到同样的代码和数据都能重新跑出结果。这些标准不是随便写的。它们分别对应了模型效果、性能、可用性、可观测性和可复现性这五项就是AI工程区别于“做实验”的核心。做实验只要模型效果好就行做工程就必须考虑模型之外的所有因素。1.3 技术栈选型背后的取舍逻辑我的技术栈选择基于一个原则社区活跃度优先其次才是性能。具体选型如下环节选择理由编程语言Python 3.11AI生态最完整团队后续维护成本低深度学习框架PyTorch 2.x调试体验好HuggingFace生态默认支持基础模型BERT-base-Chinese中文文本分类的性价比之选可微调API服务框架FastAPI自带异步支持和请求校验完整文档实验追踪MLflow同时管参数、指标、模型产物部署方便数据版本管理DVC让数据集像代码一样拥有版本历史和回滚能力容器化Docker环境隔离部署一致性有保障CI/CDGitHub Actions仓库托管在同一平台配置方便这里需要解释一下为什么用BERT而不是更时髦的大模型。我这个业务场景是短文本分类类别是固定的几十种BERT这类的预训练模型微调之后完全够用推理成本低部署简单出了问题也好排查。如果一上来就接大模型的API效果确实好但你的项目就变成了一个API调用封装项目失去了“from scratch”的工程训练价值。小模型能解决的不上大模型这是工程克制。2. 打地基数据、代码与环境的准备工作2.1 数据质量验证训练集和测试集从哪里来数据是AI项目的命门。我当时从两个渠道获取工单数据历史工单系统导出以及模拟数据补充。历史数据大概有3万条模拟数据造了5000条用来覆盖冷门类别。拿到数据后第一件事不是清洗而是做分布检查。我统计了每个类别的样本量发现结果严重倾斜账号问题占60%退款申请只有3%。这种分布不处理模型学出来会变成“什么都是账号问题”。我的处理办法是对样本量少的类别做过采样对样本量大的类别做欠采样再配合回译做少量增广。注意增广只能做在训练集上测试集必须保持原始分布否则你的评估结果就是自欺欺人。第二件事是标签一致性校验。工单历史数据的标签是不同客服人员打的同样一个“订单没收到”的情况有人打“物流问题”有人打“订单异常”。我找来三个人分别抽样评审了500条数据算了一下标注一致性发现Kappa值只有0.72属于“中等一致”。这个结果说明标签质量本身有噪音模型上线后的真实效果大概率会低于训练时的评估值这个预期管理要先做。2.2 项目目录结构与配置管理减少心智负担工程化项目最怕代码目录乱。我的项目结构是这样组织的├── configs/ # 所有配置文件的集中地 │ ├── data.yaml │ ├── train.yaml │ └── deploy.yaml ├── src/ │ ├── data/ # 数据下载、清洗、校验 │ ├── features/ # 文本预处理 │ ├── models/ # 模型定义 │ ├── trainers/ # 训练循环 │ ├── api/ # FastAPI服务 │ └── utils/ # 通用工具 ├── tests/ # 单元测试和集成测试 ├── scripts/ # 运维脚本 └── experiments/ # 每个实验的记录目录配置文件全部用YAML管理训练参数、数据路径、模型名称都从配置文件读取代码里不出现任何硬编码。这么做的好处是每次实验只需要复制一份新配置改几个参数就能跑不会把代码改乱。而且后面要复盘“你这个模型当时用的什么学习率”直接看配置文件就行不用翻聊天记录。2.3 可复现环境Docker与依赖锁定环境问题是个大坑。我一开始在自己的机器上训练一切正常后来想把训练脚本丢到另一台服务器上跑结果因为Python版本不一致、CUDA版本不匹配折腾了两天。从那以后我强制自己用Docker管理环境。Dockerfile的核心内容大致是FROM python:3.11-slim RUN apt-get update apt-get install -y git WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . .requirements.txt里的每一个包都锁定了精确版本不做范围匹配。这个动作算是给整个项目上了保险任何人任何时候拉下来都能构建出一样的运行环境。依赖锁定的另一个价值是升级可控某个库发了新版你不会在不知情的时候被卷进去。还有一个细节随机种子。我在数据拆分的代码里固定了随机种子保证每次划分出的训练集和验证集完全一致。没有这一步你的实验对比就没有意义——两次实验的差异可能是数据划分不同导致的不是模型改动导致的。3. 模型训练中的工程方法论3.1 从简单基线起步避免一开始就陷入调参泥潭深度学习项目最忌讳的是一上来就调大模型。我的做法是先跑一个简单的文本分类基线TF-IDF加线性模型几分钟就能出结果宏平均F1大约0.72。这个基线看起来不惊艳但它的价值巨大。基线建立了“最低可接受线”。后续所有复杂模型的改进都要和这个基线对比。如果没有基线你怎么知道BERT的效果提升是因为模型结构好还是仅仅因为训练更久、数据用了更多对比基线还能帮你判断投入产出比如果BERT只比TF-IDF高2个点但推理成本贵20倍那是否值得上线就要打问号了。从TF-IDF切换到BERT时我做了很多工程上的准备工作。首先是分词器的选择中文BERT用的是字级别的WordPiece不需要自己写分词逻辑但要注意模型有最大输入长度限制我设了128个token超过了就会截断。工单文本普遍不长截断影响不大但如果场景是长文档就得考虑滑窗或者分段策略。3.2 实验追踪让每一次改动都有记录我踩过最大的教训之一就是早期训练跑了十几版模型完全靠文件名记效果。过了一周回头看根本说不清哪个版本对应的数据清洗方式是什么、学习率是多少。后来我把实验记录迁到了MLflow每次实验自动记录如下信息模型参数、训练超参数数据版本哈希训练集的loss曲线、验证集的F1曲线模型文件本身备注信息这次改动做了什么。MLflow有一个我看重的能力模型注册表。不同版本的模型可以标注状态比如“Staging”预发、“Production”生产、“Archived”归档。每次评估完我直接点一下更新状态就不用维护一份“哪个模型在用”的Excel了。这一套东西看起来繁琐但它能帮你省下大量“回忆”的时间。3.3 离线评估指标要高但也要合理解读模型训练完我做了三组评估验证集评估、测试集评估、抽样人工复核。光看宏平均F1会掩盖很多问题。F1是0.87听起来不错但逐类分析后我发现“退款申请”这个类别的F1只有0.64很多样本被分到了“账号问题”。这个结果背后的原因不难理解退款相关的文本经常出现“充值”“扣款”“余额”这些词和账号问题的高频词重叠度太高。我针对混淆矩阵做了专门分析发现模型容易混淆的类别主要聚集在“资金相关”和“账号状态”这两组。改进方向也有了给这两类样本做更强的增广或者在模型里加入类别权重。这里要强调一下评估报告里必须包含混淆矩阵和逐类指标不要只看一个平均值。平均值可能好看但线上真正让你被用户投诉的恰恰是那些少数类别。4. 从模型到服务部署与维护的完整闭环4.1 把模型封装成可调用的API服务模型训练好之后还是Jupyter里的一个权重文件对业务系统毫无价值。我需要把预测逻辑封装成一个服务。我用FastAPI写了非常简单的接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class InferRequest(BaseModel): text: str class InferResponse(BaseModel): label: str confidence: float app.post(/predict, response_modelInferResponse) def predict(req: InferRequest): label, confidence predict_single_text(req.text) return InferResponse(labellabel, confidenceconfidence)这个代码看起来简单有几个细节值得注意。第一输入输出都用Pydantic定义FastAPI会自动校验请求格式非法输入直接返回400不会进入模型推理。第二模型加载只在服务启动时做一次不能每个请求都加载一遍权重——这个操作会让P95延迟从几百毫秒飙升到几十秒。第三推理过程封装在独立函数里方便单测。服务部署用的是Docker加一台2核4G的轻量云服务器资源很紧张但我测下来BERT-base模型在这种配置下单次推理大概80毫秒12个并发请求也扛得住。如果你的场景吞吐量更大可以考虑用ONNX Runtime做推理加速或者上GPU但这意味着成本上升需要和数据量、QPS做综合评估。4.2 性能测试与资源消耗的真实算账上线之前我用Locust做了一轮基础压测并发20个用户持续5分钟曲线稳定P95延迟为210毫秒没有请求失败机器CPU在峰值时达到85%内存在2.5G左右。这个结果告诉我现有配置能应付业务初期的量。内存这块有个容易忽略的问题PyTorch加载模型时CPU版本和GPU版本的显存占用完全不同。纯CPU推理时模型占用内存在500M到1G之间如果误装了CUDA版的PyTorch它会在初始化时尝试申请GPU资源虽然没GPU也能回退到CPU但启动时间会变长。我建议部署服务器直接装CPU版本的PyTorch省去不必要的依赖和资源开销。成本计算这部分很多人不重视但它直接决定项目能不能长期跑下去。我做了个粗略估算2核4G云主机加基础存储如果以包年方式购买每个月大概不到二百块钱请求量按每天1万次推断平均每个请求的资源成本完全可以接受。相比调用外部大模型API按token计费的方式自部署小模型在成本上其实是可控的而且数据不出服务器隐私方面更安心。4.3 监控、日志与模型更新的闭环服务上线只是开始不是结束。模型在环境没有跑几天我就发现了一个问题业务方对工单类型的定义随着产品迭代在变化新增了一个“优惠券使用问题”的类别老模型完全不认识。要让系统持续可用就必须有更新机制。我在服务里加了三个日志字段请求文本、预测标签、置信度。每天定时统计各类别的请求分布和平均置信度发现异常时人工抽样。置信度小于0.5的样本会被单独存进一个“待确认”列表人工打标后进入下一个训练周期的数据池。这个流程实际上构建了一个反馈闭环线上数据 → 人工标注 → 增量训练 → 灰度发布 → 全量上线。模型更新不能直接全量替换。我的做法是先部署一个shadow版本让新模型和旧模型同时接收线上请求但新模型的预测结果只写日志不返回给用户累计观察一周。确认新模型在分布漂移明显的类别上效果更好之后才切换流量到新模型。这个灰度过程多花了一点时间但避免了“上线即翻车”的尴尬。5. 实操实录一个客服工单分类项目的完整落地过程5.1 数据准备阶段时长一周代码量不大但杂活极多整个项目最耗时的是数据阶段前后用了一周。准确地说代码量并不大但杂活特别多——导出工具不对、编码格式混乱、字段缺失、标签拼写不统一各种问题都要处理。我先写了数据抽取脚本从历史工单系统导出原始数据统一转成UTF-8编码的CSV。清洗时做了这些处理去重、去掉纯表情符号或纯标点的样本、过滤长度小于2个字符的文本、把标签统一映射为英文ID。这里有个细节中文文本里经常混有全角和半角符号比如“退款#38;充值”和“退款充值”实际上是一个意思我在预处理阶段把所有标点做了全角转半角的规范化。标注质量校验环节是额外花了时间的。我抽了500条数据让人工复核发现原来的标签体系中有一个“其他”类别里面的样本几乎什么都有——投诉、咨询、闲聊、甚至广告。这种混入的噪音会让模型学习时无所适从。处理方案是把“其他”类别的样本拆开重新归类实在无法归入现有类别的少量保留在“其他”中并标注低置信度权重。5.2 训练与验证阶段从第一次训练到最终模型我第一次用BERT训练时效果反而比TF-IDF基线还差F1只有0.68。排查之后发现是学习率设得太高默认的5e-4BERT微调一般需要更小的学习率比如2e-5。这是我印象很深的一次教训预训练模型的微调规律和从零训练不同不是参数越大效果越好学习率、热身步数、权重衰减这些都要跟着调整。调整后的训练配置是epochs设为3batch size为32学习率2e-5warmup比例0.1序列最大长度128。验证集F1到了0.87。但前面提到逐类分析后发现“退款申请”仍然偏低。我又做了两类工作一是针对低资源类别做了回译增广二是把类别权重向量加到损失函数里少样本类别的错误会被惩罚得更重。最终测试集上宏平均F1为0.89逐类指标趋于均衡这个结果才敢拿去演示。训练时还有一个容易掉进去的陷阱早停法要和验证集指标配合使用。我在验证集F1连续两个epoch不提升时保存检查点防止过拟合。但要注意保存检查点的判断标准必须是“验证集指标”不能是训练集loss——后者只会不停下降没有任何参考意义。5.3 上线与后续迭代从技术Demo变成业务工具模型上线后业务方用自己的真实工单跑了一周反馈了几个问题。第一有些用户用方言表达模型识别不准比如“整么退款”应该是“怎么退款”。这类问题在数据增广阶段可以通过加入谐音、方言变体来缓解。第二模型对包含链接的文本处理不佳HTTP链接被截断后语义信息丢失。解决方案是在预处理阶段先提取并移除链接再判断正文内容。第三业务方希望接口能返回前三个候选类别而不是单一类别方便他们在界面上做选择性确认。我根据反馈做了第二轮迭代增广方言变体数据、改进预处理流程、改造API返回结构。这次迭代让我意识到AI项目上线后才是真正的开始线下的指标只是参考线上的真实需求会持续倒逼你调整。一个好的AI工程结构要能低成本地支持这种迭代。如果每次改动都要从环境搭建重新来一遍团队很快就会失去迭代热情。6. 高频问题与排查技巧速查这一部分整理了我实操过程中遇到的典型问题和排查思路做成速查表方便你对照现象可能原因排查方法避坑建议模型训练不收敛学习率过大或数据预处理有误观察loss曲线是否在震荡检查数据标签是否错位先用一行文本走通全流程再上全量数据训练效果好但线上效果差训练数据和线上数据分布不一致对比线上请求文本和训练集的长度、类别分布、用词特征定期统计线上样本及时回注训练集推理延迟高模型太大、机器太弱、批量推理未开用time逐段排查预处理、推理、反序列化各环节耗时考虑ONNX加速或减小输入长度上限服务启动慢每次启动都重新加载模型检查加载逻辑是否在生命周期函数里模型加载只做一次存为全局变量GPU显存不足并发请求太多或模型未释放监控显存曲线观察是否存在泄漏CPU部署时用CPU版PyTorchGPU部署时设置显存上限标签类别有新增业务定义变化老模型未适配模型会持续预测到新类别的文本但置信度低建立置信度阈值和待确认池定期回流标注还有几个经验想单独讲一下文本数据的编码问题容易被忽略。CSV文件用Excel打开再另存编码可能从UTF-8变成GBK。训练脚本读数据时统一用UTF-8并且用errorsreplace兜底避免因为一个非法字符导致整个训练崩溃。模型文件管理要规范化。我见过有人用“model_final_2_new_version.bin”这种命名方式三天之后自己都分不清哪份是最新的。我的建议是模型文件名由算法名加时间戳组成比如bert_zh_20250115_2240.pt配上MLflow的版本号绝不会混淆。接口的异常处理必须有兜底逻辑。如果模型推理抛异常接口不能直接返回500应该返回一个默认标签或者让对方重试。我在接口里加了try-except推理失败时返回“unknown”加置信度0同时在日志中记录错误详情。这个细节看起来小线上救过我好几次。后端的健康检查接口必不可少。我用FastAPI自带的/health返回“ok”配合容器编排工具的探针每秒检查一次服务存活状态。没有健康检查服务假死时监控根本发现不了。最后聊几句整个项目做下来最深的体会是AI工程的复杂度不在于模型本身而在于把模型变成一个稳定、可信、可维护的系统。数据质量、实验管理、部署策略、监控反馈任何一个环节偷懒最后都会在线上以某种微妙的方式报复你。如果你正在犹豫要不要做这样一个“from scratch”的项目我的建议是选一个小而完整的业务场景不要贪多。跑通一遍全链路获得的经验比看十遍教程都扎实。过程中遇到问题不要急着搜“最佳实践”先看日志、看数据、看指标很多问题自己就能定位。工程能力就是在这一次次“自己排查出来的”过程中长出来的。