先说明一下我写的这套东西不是“30分钟上手AI”也不是“带你调个BERT”。ai-engineering from scratch翻译成人话就是不靠现成的AI脚手架不依赖别人帮你搭好的调包流程从零开始把一条完整的AI工程流水线亲手做出来。这个标题我一开始看到也觉得劝退但真把一个从数据到训练再到部署的项目完整走一遍之后我反而觉得这是所有想正经做AI工程的人最该走的一条路。这篇文章要聊的就是这套“从零构建AI工程”的方法论和实操路径包括任务定义、数据管线、训练循环、模型服务化、监控闭环以及我在整个过程中踩过的坑和总结出的排查顺序。适合三类人刚入门但不想只当“调包侠”的工程师、已经在用现成框架但想搞清楚内部机制的开发者以及需要搭建团队级AI基础设施的技术负责人。1. 什么是from-scratch的AI工程以及为什么值得亲手走一遍1.1 它不是一个造轮子项目而是一条完整的工程主线很多人听到“from scratch”就以为是要从零手写神经网络、手写反向传播甚至重写一个深度学习框架。这其实是个误会。真正值得你从零构建的从来不是模型层的那点数学而是模型之外那一整套系统能力数据怎么收集、怎么清洗、怎么切分训练脚本怎么写才能复现模型训练出来怎么评估、怎么部署成服务上线之后怎么监控、怎么发现数据漂移。我建议把“AI工程从零构建”理解成一条流水线而不是一个模型。流水线的起点是业务问题终点是线上稳定运行的服务。中间每一个环节你都要亲手搭一遍哪怕只是一个小而可用的版本。这个过程的重点不是“写得多漂亮”而是让你理解每个环节为什么存在、每个决策会影响什么。以我自己做的文本分类项目为例从头到尾我只用了一个很小的模型但手工写了数据清洗工具、训练循环、评估脚本、FastAPI推理服务以及一个简单的线上日志回传分析模块。规模不大但链路完整。做完之后再看团队里那些包装精美的框架会发现所有抽象的封装都变得透明了因为你已经知道底下是什么。1.2 从零构建一次你能拿回三个被框架掩盖的认知第一数据质量的决定性远超模型结构。用现成框架时数据预处理已经被封装得相当“顺滑”你很难体会到脏数据能带来多大的破坏。亲手做一次数据管线你会发现去掉几条重复样本、修正一批错误标注、调整一次切分方式效果变化比换骨干网络还明显。第二超参数不是“默认值”而是有物理意义的。默认学习率、默认批次大小、默认Epoch数这些数字背后都是梯度更新节奏、损失曲面、显存约束之间的平衡。你不亲手调一次很难理解为什么学习率设成1e-5而不是0.1为什么batch size太大模型反而欠拟合。第三评估指标和线上体验是两回事。线下拿到的准确率、F1值都只是近似线上才有真实反馈。这个落差靠框架学不到必须在“部署一个用模型在线做决策的服务”那一刻才能真实体会。1.3 这事适合谁不适合谁适合的写代码有一定基础、想把AI能力做进产品里的人已经在用PyTorch或transformers但总觉得心里发虚的人想从算法岗过渡到AI工程岗的人。不适合的只想要一个能跑通Demo、快速交差的人以及想研究底层深度学习理论的人——后者应该去看论文而不是看工程博客。2. 地基工程任务定义、数据管线与实验基线2.1 先别碰模型把任务评估指标定对我见过太多项目一上来就加载预训练模型跑个准确率就开始调参最后发现业务方根本不关心准确率。问题就出在任务定义这一步。你首先要想清楚这个模型做的是什么任务错了会产生什么代价什么指标最能反映这个代价。二分类任务常见的就是帮用户识别垃圾文本。准确率在这个场景下很不可靠因为正负样本严重不平衡。假设垃圾文本只占1%你全预测成正常文本准确率也有99%但这个模型毫无用处。应该用精确率、召回率、F1值而且要看具体误判的代价把正常用户评论误判成垃圾比漏掉一条垃圾广告严重得多这时候精确率优先。任务类型推荐指标为什么二分类不均衡Precision/Recall/F1准确率会被多数类欺骗排序/检索NDCG、MAP关注前几位结果的命中质量时序预测MAE、RMSE关注误差大小而非分类正确与否多分类Macro F1兼顾少数类表现指标定完之后还要顺手定一个“基线”。很多项目跳过了基线比较导致后面根本不知道模型改善了多少。最简单的基线比如文本分类里用词频加逻辑回归跑出来往往比很多人精心调参的BERT低不了太多。有了基线你后面的每一个改动才有比较对象。2.2 数据管线里的三个翻车点泄漏、重复、切分数据管线的第一原则是训练集不能携带任何来自测试集或线上未来环境的信息。这一点被叫做标签泄漏实际发生频率远比想象中高。举个例子我在一个时序项目里第一次做特征工程把整个时间段的均值当成特征。离线评估非常漂亮上线后直接崩盘。原因很直白模型在训练时偷偷看到了未来的统计量线下当然表现好真到线上预测时根本没有“未来”可以看。这是最典型的泄漏形式。解决办法是严格按照时间切分前70%的时间段做训练中间15%做验证最后15%做测试。所有特征计算都只能用截止到当前时刻的数据。这一步做完离线评估才有意义。第二个坑是重复数据。很多爬来的数据集里重复率很高如果不做去重训练集和测试集里可能出现完全一样的样本导致指标虚高。做法很简单对文本类型做内容哈希或规范化之后去重不要只是去掉完全重复的行语义上高度近似的样本也要留个心眼。第三个坑是切分方式。分类任务切分时要注意类别分布。直接用train_test_split随机切小类别可能被全部切进训练集测试集里一个都看不见评估结果自然不真实。我用的是分层切分确保每个类别在训练和测试中占比接近原始分布。这一步在sklearn里的参数就是一行代码的事情但很多人根本不知道要这么做。2.3 从零打造训练循环四行代码背后的工程决策只要你用PyTorch训练循环的核心其实就四行loss criterion(model(inputs), labels) loss.backward() optimizer.step() optimizer.zero_grad()看起来简单但工程决策全藏在细节里。一个常见问题是为什么每一步都要调用zero_grad因为PyTorch的梯度是累加的你不手动清零上一个batch的梯度会加到下一个batch上。很多人把它理解成“惯性写法”直到某天梯度消失找不到原因才想起这行代码。更关键的工程决策是梯度累积。当显存装不下大batch时可以用小batch多跑几步再更新一次参数等效出一个大batch的效果accumulation_steps 4 # 等效放大batch size for i, (inputs, labels) in enumerate(train_loader): loss criterion(model(inputs), labels) / accumulation_steps loss.backward() if (i 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()这里除以accumulation_steps是因为PyTorch会把梯度累加如果不除等效batch变大但学习率没变等于隐性地把学习率变大了很容易爆Loss。我刚这么做的时候没除训练直接发散排查了半小时才想起来是这个原因。还有梯度裁剪训练文本模型或者生成模型几乎必开。梯度爆炸在深层网络里太常见了尤其初始学习率偏大或者数据里出现异常样本时。一行代码可以避免大量训练事故torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0)关于学习率我实践下来最靠谱的是先用一个小范围扫描把候选学习率按对数取点各跑几十个step看Loss下降曲线找到下降最快且稳定的区间再在这个区间里精细选值。别一上来就把学习率设成0.001不同任务、不同模型的最佳区间差别很大。2.4 可复现性不是洁癖而是工程底线“我昨天跑出来的F1是0.86今天怎么变成0.81了”这个问题几乎每个人都会遇到。原因通常很简单没固定随机种子或者依赖了某个不确定的库。固定随机种子的标准做法如下import random import numpy as np import torch def set_seed(seed: int): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic True torch.backends.cudnn.benchmark False这里的cudnn.deterministicTrue会让卷积等操作使用确定性算法benchmarkFalse则避免cuDNN在运行时自动选择性能最优算法。代价是速度略微下降但换来的是实验结果可复现。除了种子还要把模型、数据、代码版本都记录下来。我后来习惯在每个实验结果旁边记录三样东西代码commit号、数据集版本、环境依赖快照。没有这三样别人没法复现你的结果三个月后的你自己也没法复现。用MLflow或者简单的CSV记录表都可以关键是养成习惯。3. 从训练到服务模型部署的关键工程决策3.1 超参数不是拍脑袋而是算出来的模型训练完之后最容易忽略的是“部署前的参数确认”。很多人训练时的batch size定32是因为显存刚好够学习率定3e-5是因为BERT默认这么设。这些没有经过计算的参数会在部署阶段加倍还给你。以微调一个预训练模型为例我常用的起点是学习率2e-5到5e-5之间batch size 16或32Epoch数先设3。然后重点看验证集Loss曲线找到模型开始过拟合的那个Epoch用Early Stopping保存最优模型。盲目训练10个Epoch只会得到记忆训练集、线上表现糟糕的模型。如果你的显存装不下想要的batch size优先考虑梯度累积而不是换小模型。比如目标batch size是64显存只能装16条样本那就累积4步更新一次。这比直接开多卡训练简单得多效果也基本等价。多卡分布式训练是后话先把手上的单卡方案用明白。还有一个计算细节如果数据集有1万条batch size是32那一个Epoch就是313个step。梯度累积4步的情况下模型每313/478个step左右更新一次参数。我习惯把这个换算结果写进实验记录因为分析训练日志时Log里显示的step数和实际更新次数对不上容易误判训练进度。3.2 把模型做成服务接口、批处理与延迟预算训练完成不等于项目完成模型只有变成接口才能真正产生价值。部署环节要做的第一件事是定义延迟预算。比如产品方要求接口响应时间在300毫秒以内这个数字决定了你能用什么模型、做不做批处理、要不要上量化。我最常用的推理服务方案是FastAPI加PyTorch。结构非常简单from fastapi import FastAPI from pydantic import BaseModel app FastAPI() model, tokenizer load_model_and_tokenizer() class PredictRequest(BaseModel): text: str app.post(/predict) def predict(req: PredictRequest): inputs tokenizer(req.text, return_tensorspt) with torch.no_grad(): logits model(**inputs).logits pred int(logits.argmax(dim-1)[0]) return {prediction: pred}这个接口能用但线上扛不住高并发。问题在于每次请求都做一次模型推理没有批处理。改进办法有两个方向一是把多个在线请求拼成batch一起推理吞吐能提升好几倍二是并发请求多的时候用队列把请求聚合到固定大小的batch里再统一推理。另一个容易忽略的优化是模型预热。模型第一次推理时CUDA上下文初始化、显存分配都要时间第一次请求往往比后续慢得多。我踩过这个坑第一次请求耗时700毫秒后续只要120毫秒。解决方法是服务启动后立刻用一个哑样本推理一次把模型“热”起来。3.3 模型变轻的路径ONNX导出与量化在资源受限的环境里部署一个几亿参数规模的模型确实不现实。我的实践顺序是先用ONNX Runtime替换PyTorch推理再做INT8量化。这两个步骤能让模型体积和推理延迟同时降下来而且代码改动量不大。ONNX导出示例import torch.onnx dummy_input torch.ones(1, seq_len, dtypetorch.int64) torch.onnx.export( model, dummy_input, model.onnx, input_names[input_ids], output_names[logits], dynamic_axes{input_ids: {0: batch_size}, logits: {0: batch_size}}, opset_version17 )这里dynamic_axes很关键它允许输入batch size动态变化否则模型只能跑固定batch部署时非常难受。我在一个BERT尺寸的文本模型上实测PyTorch的CPU推理单条延迟大约180毫秒导出ONNX之后降到130毫秒再做INT8量化能进一步降到80毫秒以内模型体积也从约400MB压缩到约100MB。这个优化投入产出比很高值得作为部署默认流程。量化有个坑INT8量化后精度可能明显下降。如果下降超过你能接受的范围可以只在少数层上做量化或者先量化到FP16试试。用校准集来做量化比直接动态量化更稳但实现复杂一点。我的习惯是优先动态量化精度损失太大再考虑校准集方案。3.4 上线之后的任务漂移监控与反馈闭环模型部署上线只是开始真正的挑战在线上。最常见的现象是模型上线第一周效果不错一个月后业务方反馈准确率明显下滑。原因基本是数据漂移线上真实数据的分布和训练集不一样了。监控数据漂移最简单的做法是记录线上每个请求的输入特征统计量和训练集的统计量做对比。文本分类场景里可以跟踪输入长度、高频词、类别置信度分布。当置信度普遍下降或者输入长度分布和训练时差异很大就该考虑模型需要重新训练了。更重要的是建立反馈闭环。只记录预测结果没有用必须有少量线上样本经过人工标注回流到训练集里。哪怕每天只回标100条样本积累一个月也有3000条新鲜数据够支持一次增量训练了。没有这个闭环模型只能不断退化再好的系统也撑不住。硬件监控同样不能忽视。用容器部署的模型服务我吃过CPU被打满导致接口超时的亏。给GPU和CPU资源都配上告警CPU使用率超过85%持续5分钟就告警这个阈值在高峰期尤其重要。很多“模型变慢”的问题根源其实不是模型而是机器负载。4. 工具选型哪些必须手写哪些可以偷懒4.1 必须自己手写的三件事第一是训练循环。哪怕你只用PyTorch的API也要把train函数、validate函数、模型保存逻辑亲手写一遍。因为这个过程会逼你搞清楚梯度在哪个位置清零、什么时候切换eval模式、什么时候要用torch.no_grad()。这些细节直接决定了训练的正确性。第二是评估代码。很多框架自带评估函数但你不知道它算的是什么。我遇到过评估脚本global average precision被算成micro precision的情况指标定义不对后面所有比较都失去意义。自己写评估代码至少能确保每个指标的计算方式是你真正想要的。第三是数据管线的核心部分。清洗、去重、切分这些必须自己写。因为只有你最懂业务场景下的脏数据长什么样。垃圾文案清洗、HTML标签剥离、emoji规范化这些逻辑只有业务侧的人才能正确写出来通用框架帮不了你。4.2 可以大胆借力的工具PyTorch本身不用怀疑它就是构建深度学习模型的工业标准手写训练循环也不会和它冲突。transformers库可以放心用预训练模型的加载和分词器处理非常成熟没有必要自己实现。实验跟踪方面我推荐MLflow记录指标、参数、模型产物都很方便本地起一个服务就行不用搞复杂的部署。数据版本控制可以用DVC但要权衡学习成本小团队的话先用文件规范命名也能撑住。FastAPI作为模型服务框架非常合适生态好、性能够用、文档清晰。表格里是几个我常用的工具组合环节推荐工具备注模型训练PyTorch核心框架预训练模型Hugging Face transformers加载和微调省力实验记录MLflow本地部署足够模型推理服务FastAPI自带并发支持模型加速ONNX Runtime导出后推理更快数据版本DVC或文件约定小项目用文件约定更简洁4.3 暂缓引入的“重型设施”很多人一开始就上Kubernetes、MLflow全功能模块、分布式训练框架、复杂的特征存储平台最后发现团队几十个人里只有两个人会维护。我的建议是项目规模没有大到单机支撑不住之前不要引入分布式框架。单机多卡用PyTorch原生的DataParallel或DistributedDataParallel就够了多数模型还没到必须上多机的规模。同理功能完整的大平台不如一个能跑通的流水线有价值。先用脚本加文件的方式串起整个流程等流程稳定了再逐步把各个环节替换成更专业的工具。先跑起来再优化比先设计一个完美架构再动手要实在得多。5. 实战文本分类项目的from-scratch完整路径5.1 数据构建把业务要求变成可执行的数据集这一步是全程最耗时也是最容易被低估的。有一个业务场景是“判断用户评论是否包含负面情绪”原始数据是几万条评论区文本。首先要做的是清洗去掉HTML标签、正则匹配掉URL和多余空格、处理重复评论。清洗代码里最需要小心的是不要把文本里的有效信息也删掉比如过滤表情符号时负面评论里的表情往往也是信号不能一刀切。清洗之后的标注要做一致性检查。我试过让两个人各标500条同样的数据算出来的标注一致率只有78%这意味着数据里的“金标准”本身就带噪。遇到这种情况要回去看分歧样本在标注规范里补充规则。不看标注质量就训练模型等于在错误答案上学习。数据切分上文本分类任务如果有时间戳信息务必按时间切分不要随机切。因为产品是上线后才开始用的模型见到的都是未来数据。按时间切分后还要用分层抽样的方法保证各个类别在训练集和测试集中占比接近。我习惯在切分完成后检查一下类别分布情况做好之后再进入训练阶段。5.2 训练脚本一份可复现的最小训练框架我写训练脚本的习惯是一个入口文件接收模型名、学习率、batch size、epoch数等参数把种子、数据路径、保存路径都固定下来。核心代码概括如下set_seed(config.seed) train_loader DataLoader(train_dataset, batch_sizeconfig.batch_size, shuffleTrue) val_loader DataLoader(val_dataset, batch_sizeconfig.batch_size, shuffleFalse) model AutoModelForSequenceClassification.from_pretrained(config.model_name, num_labels2) optimizer AdamW(model.parameters(), lrconfig.lr) scheduler get_linear_schedule_with_warmup(optimizer, num_warmup_steps, num_training_steps) for epoch in range(config.epochs): train_one_epoch(model, train_loader, optimizer, scheduler) val_loss, val_f1 evaluate(model, val_loader) save_best_model(model, val_f1)训练时用的文本模型是BERT base基线逻辑回归的F1大约在0.76微调后F1能到0.83左右。如果差距大到不合理数据管线可能有问题。训练过程中我最关注的是验证集Loss曲线而不是只盯F1。Loss下降但F1不动大概率是模型在学偏比如把所有样本都预测成多数类。5.3 评估与错误分析报表只是起点跑完测试集拿到了F1值不算评估结束还要做错误分析。我每次都会把模型预测错的样本打印出来看一遍。错误样本通常会暴露三类问题标注本身错了、样本过于模糊人类都难判断、模型真的学错了某种模式。比如我发现模型把“这条消息太假了”预测成负面情绪实际上在特定语境下这句话是调侃不一定是负面。这种错误靠调模型解决不了需要在数据上补上下文或者在特征上加入会话历史。一张混淆矩阵比一段指标报表有价值得多。它直接告诉你模型把哪些类别混在一起。排查错误样本后把典型错误整理成一份清单反馈给数据标注同事下一轮迭代才能闭环。这个过程不需要技术含量但它决定模型质量和运气无关、靠的是流程。5.4 部署与上线一个可用的分类服务按3.2里的FastAPI方案搭好服务之后还用curl做了一次端到端测试确认输入输出字段没搞错。上线的动作包括用ONNX导出一份推理模型、启动时做模型预热、给接口设置超时和重试、接入基础监控并记录每一条推理日志的置信度。上线初期要盯的是置信度分布。如果线上数据大量落在置信度0.5附近说明数据分布和训练集差异不小很可能需要早点重构数据。这个信号比用户反馈来得早。线上日志格式化输出到文件定期用脚本统计置信度均值、类别分布和延迟分位数。整个部署链路没有用任何重型平台一台普通服务器加几个脚本就完成了但该有的反馈闭环都有。6. 常见问题与排查实录这些坑我都踩过6.1 指标好看但线上拉胯采样偏差这是我遇到过最隐蔽的问题。离线测试集F1是0.86上线后业务方反馈效果极差。查了半天才发现原因线下测试集是从评论区里随机抽的但线上实际遇到的大多是活跃用户发布的评论两类数据在文本长度、语气偏好上差异明显。解决思路是重新设计验证集和测试集让它能代表线上真实分布。尽量从线上日志里抽样本做测试集而不是从离线库里抽。另外可以做一些分布对比比较训练集和线上样本的文本长度分布、高频词分布差异大的地方就是需要补数据的部分。采样偏差不修正后续所有模型优化都是在原地打转。6.2 Loss不降或梯度爆炸按这个顺序排查Loss完全不动首先查数据是不是有问题。有一次我把标签做成了从0开始编码但损失函数用了默认的ignore_index等于-100全部标签都被忽略了模型自然什么都学不会。这种底层数据编码问题不看代码根本发现不了。Loss暴涨优先检查学习率和梯度。常见原因是学习率偏大一上来就把参数推到了损失曲面的陡峭区域。另一个就是梯度累积时的累加逻辑错误除以累积步数或者忘记清零梯度。检查顺序应该是数据有没有传对、标签有没有配对、学习率合不合理、梯度有没有累积问题。我整理了一个速查表问题现象优先检查项Loss完全不变标签编码、数据加载是否为纯随机Loss突然暴涨学习率、梯度裁剪是否开启验证Loss不降是否过拟合、是否漏了正则化指标抖动剧烈批次大小是否太小、种子是否固定线上首次请求慢是否有预热、是否初始化了CUDA6.3 推理延迟超标瓶颈往往不在模型接口响应超过500毫秒时第一反应通常是换小模型。但其实先查一下瓶颈在哪里。最常见的问题是模型推理只占100毫秒剩下400毫秒都消耗在数据预处理和网络传输上。每次请求都重新做分词、反复加载tokenizer、甚至在循环里拼接字符串这些低效操作才是大头。我曾把一个Python版本的文本预处理用批量向量化重写延迟立刻从400毫秒降到150毫秒模型权重完全没动。所以排查延迟先用简单的时间统计脚本把各环节耗时打点打出来再决定是优化预处理、上ONNX、还是换模型。图省事直接换模型反而容易错失真正的瓶颈。6.4 显存溢出脏代码比模型大更可怕显存溢出不一定是模型太大。很多时候是训练循环里保存了不必要的中间变量导致显存占用失控。比如整个batch的logits被保存了下来或者对不需要梯度的操作也开了梯度计算。排查办法是把batch size调小看显存占用是否线性下降。如果batch size减半占用却不降八成是代码里有全局Tensor被长期持有。还可以开启PyTorch的梯度检查点功能transformer模型里用它会用计算换显存效果很显著。我的习惯是显存不够先查代码里的Tensor是否被无谓保留再考虑换小模型。写代码的时候随手del掉不再用的大Tensor这个习惯能省掉很多问题。结尾的部分按我的实际经验来说最想提醒后来者的一点是from-scratch这种路线真正带来的不是让你造一个多厉害的模型而是让你在每个环节上都具备判断力。你知道数据哪里会脏知道训练为什么发散知道推理卡点在哪知道上线之后要看什么指标。这套能力不是读文档能获得的必须靠亲手踩坑换回来。如果你身边有想入行AI工程的朋友把这些坑提前讲给他们听能帮他们少走很多弯路。祝你们从零构建的过程顺利也欢迎交流你们踩过的那些更有意思的坑。