去年我接到一个内部知识库问答的需求要在一个完全没有AI基础的团队里从零搭一套可用的工程链路。当时很多人劝我直接调大模型API但实际跑了两个月之后我发现真正的“ai-engineering-from-scratch”根本不是调接口而是把数据、训练、评估、部署每个环节都吃透才能在一个受限环境里把模型稳定跑到线上。这篇文章就是我那段时间的完整记录。我会讲清楚为什么我选择从零开始搭建一条完整链路而不是做“调包侠”也会把环境配置、数据清洗、模型训练、部署上线、问题排查的每一段实操细节摊开讲。适合三类人看刚入行想搞懂AI工程全貌的工程师、被业务逼着上模型但不知道从哪里下手的团队负责人以及那些已经在调API但总感觉心里没底、想补上底层原理的人。1. 内容整体设计与思路拆解1.1 调包与从零之间差的是工程的掌控力很多人一听到“from-scratch”就以为是要从矩阵乘法开始手写神经网络。真没必要除非你是做科研或者教学。我的理解是所谓的从零是面对一个具体业务问题时你能从数据采集、清洗、标注、模型选型、训练调参、评估、部署、监控整条链路都捋得清楚而不是只会拿现成模型跑一下。举个例子你让一个只会调模型接口的人去解决“垃圾评论识别”问题他能给出一个还过得去的方案。但如果这个模型的精度在线上下降了两个点他可能连从哪里开始排查都不知道——是因为数据分布变了还是特征工程出了问题还是模型服务的内存泄漏导致推理延迟升高这些问题背后全是工程能力。我踩过一个很典型的坑。有一版模型用BERT微调效果明明很好线上准确率却一直上不去。后来排查发现是服务端每次推理都把tokenizer重新加载了一遍导致请求延迟超过3秒网关直接把大部分请求判成了超时。那种“模型效果不错但工程没跟上”的情况只有走一遍完整链路的人才能敏锐地嗅出来。1.2 为什么我建议你走一遍完整链路在我看来走一遍从零开始的AI工程化链路最大的收益不是做出了一个模型而是建立了一种“掌控感”。你知道每个参数为什么这样设你知道数据里哪些噪声会影响训练你也知道模型部署时哪些环节会拖慢延迟。这条链路通常包含四个核心环节环境与数据、模型训练、模型评估、部署与服务化。这四个环节里的任何一个单独拿出来都有极深的坑但真正把它们串起来的时候你会发现它们之间其实互相制约。比如数据处理的好坏直接决定模型收敛速度而模型推理的延迟又反过来要求你压缩数据预处理的时间。你如果只学其中一个环节永远都是局部最优解决不了整体问题。2. 前期准备与基础模型选型2.1 一套能跑起来的最小环境正式开始前先把环境搞定。不要一上来就装最新版本的CUDA和PyTorch因为最新版往往意味着生态里的第三方库还没适配。我当时用的组合是Python 3.10不要用3.11以上有些CUDA相关的编译库还不支持。PyTorch 2.1.0配CUDA 11.8实测Pytorch 2.x的动态shape和编译优化比较稳。transformers 4.36.2这个版本对应的是比较成熟一代的模型库API。如果要做CPU推理需要给torch配MKL或OpenBLAS否则速度会慢到怀疑人生。提示虚拟环境一定用conda不要直接pip install到系统环境。AI项目里的依赖版本地狱问题只有经历过才懂。我见过有人把系统Python搞崩之后整整花了一个周末才恢复环境。安装验证很简单跑一条命令看CUDA是否可用python -c import torch; print(torch.cuda.is_available())如果输出True说明GPU环境没问题。如果是False先不要急着去装驱动多半是PyTorch版本和CUDA版本不匹配。2.2 用“分类”这个场景做练习选一个最简单、最经典的问题来走通全链路——文本分类。为什么是分类因为它是最容易理解的任务类型输入一段文本输出一个标签整个链路跑完你能非常直观地看到每个环节在做什么。我建议你用自己的业务数据来练哪怕数据量不大。我当时用了大概3万条客服工单数据标签分成“咨询”“投诉”“售后”“其他”四类。这种数据量做深度学习文本分类刚刚好够用如果少于5000条就别指望模型能学出太多东西。数据格式长这样label,text 咨询,我想问一下我的订单什么时候发货 投诉,已经等了三天你们到底发不发 售后,收到货是坏的怎么办CSV就够了别搞什么JSONL真实工程里最通用的格式是CSV因为业务方导数据最方便。2.3 从零理解softmax和交叉熵训练一个分类模型之前先把两个最核心的概念搞清楚softmax和交叉熵。不理解它们你调参就是在乱撞。softmax把模型输出的logits转换成概率分布转换后的每个类别概率介于0到1之间并且所有概率加起来等于1。它的公式简洁到让人怀疑是不是漏了什么[ p_i \frac{e^{z_i}}{\sum_j e^{z_j}} ]为什么要用指数因为指数函数能拉开差距让模型对“哪个类别更可能”做出更明确的判断。交叉熵则是衡量模型预测分布和真实标签分布之间的差异。真实标签是1其余是0模型预测得越接近这个分布损失越低。公式是这样的[ L -\sum_i y_i \log(p_i) ]注意一句话就够了softmax负责把输出变成概率交叉熵负责把概率和真实标签做比较。模型训练的过程就是在不断调整参数让交叉熵变小。实操心得训练初期如果loss不降先别急着调学习率先去看数据。多数情况下是标签给错了。3. 数据工程最容易翻车的环节3.1 数据清洗的细节数据质量决定模型上限这句话第一次听觉得是废话踩过坑之后才明白是真理。清洗文本数据时我建议按这个顺序来统一的文本编码全部转成UTF-8否则后续分词会出现乱码。去重同一用户重复提交的工单直接删除避免模型在同样的数据上反复过拟合。处理噪声客服工单里有很多类似“”、“呼叫转移中”之类的无意义内容清洗掉。统一标签口径比如“退款”有的标注成“售后”有的标注成“投诉”这种不一致会直接导致模型学偏。我当时清洗的时候还遇到一个很隐蔽的问题——分号导致的编码故障。数据里有形如这个的符号直接把整条工单截断了。这种问题用肉眼很难发现最好在清洗后加一条规则检查每条记录是否只有一个标签。3.2 数据划分与泄漏问题很多新手在划分数据集时直接随机切这是个埋伏。如果用户的一个订单关联了多条工单随机切分时同一订单的工单会被同时分到训练集和验证集。模型在训练时其实已经“见过”了验证集里的内容线下评估虚高线上实际表现又差了一截这就是典型的数据泄漏。正确的做法是先按订单ID分组再在订单维度上做切分确保同一订单的所有工单都在同一个集合里。我当时按8:1:1切分训练集、验证集、测试集。训练集用来更新模型参数验证集用来选超参和做早停测试集只能在最后评估时用一次不能反复用它调参否则它会逐渐失真。4. 模型训练与调优实操4.1 训练代码结构训练代码不需要花里胡哨保持清晰就好。我习惯把一条完整的训练脚本松散分段不要全塞进一个类里。最小可用结构如下拆成几个逻辑块# 1. 读取数据 from datasets import load_dataset dataset load_dataset(csv, data_filestrain.csv) # 2. 初始化分词器和模型 from transformers import AutoTokenizer, AutoModelForSequenceClassification tokenizer AutoTokenizer.from_pretrained(bert-base-chinese) model AutoModelForSequenceClassification.from_pretrained(bert-base-chinese, num_labels4) # 3. 定义训练参数 from transformers import TrainingArguments training_args TrainingArguments( output_dir./results, learning_rate2e-5, per_device_train_batch_size16, per_device_eval_batch_size64, num_train_epochs5, evaluation_strategyepoch, save_strategyepoch, load_best_model_at_endTrue, metric_for_best_modeleval_loss ) # 4. 开始训练 import numpy as np from transformers import Trainer trainer Trainer( modelmodel, argstraining_args, train_datasetencoded_dataset[train], eval_datasetencoded_dataset[validation], tokenizertokenizer, compute_metricscompute_metrics ) trainer.train()这段代码用Hugging Face的Trainer封装了很多训练细节不需要自己写循环。任务越小、数据量越少越不需要过度设计。4.2 超参数怎么定超参数没有标准答案但有几条基本的基线可以参考它们都是经历过大量任务验证的经验值参数建议值说明学习率2e-5微调BERT这个量级最稳妥调大到5e-5容易震荡Batch Size16~32显存不够时优先降低批次大小不用硬扛Epochs3~5数据量小的话3轮基本够多了容易过拟合Warmup训练步数的10%用法先小学习率预热再切正常学习率Weight Decay0.01做个正则化防止权重太大导致过拟合Warmup是一个细节但很重要的参数。直接用预设学习率开始训练模型前期参数会很不安定loss会上下跳。加了warmup让学习率从接近0开始前10%的步数慢慢升到预设值模型进入平稳状态后再开始真正学习。我当时的一个实验就明显体现这一点。不加warmup验证集loss一直抖动加10%步数warmup之后loss曲线变得平滑精确率也稳定提升了2%左右。4.3 过拟合与调优信号训练过程中最需要关心两个信号训练集loss持续下降而验证集loss回升说明模型开始死记硬背过拟合出现了。应对方案按优先级排列减小模型容量、增加数据量、加dropout、调大weight decay、降低学习率并且提前早停。另一个常见问题是loss在某个区间反复横跳降不下去。如果训练到后期还在大幅震荡多半是学习率太大已经进入了“数值在谷底附近来回弹”的状态。把学习率降到原来的1/5或者等比例在末尾减小一般能稳定下来。把每个epoch的loss打点记录下来画成曲线能直观看到模式和异常。务必在训练脚本里把loss、eval_loss、learning_rate都记录进tensorboard或wandb不要等到跑完了才发现没有日志可看。注意早停要用验证集指标不要在训练集上看效果。5. 部署服务化从离线模型到在线服务5.1 模型导出与推理优化模型训练完毕后直接加载PyTorch权重做线上推理是不合适的——太重、太慢而且对服务端的内存占用不友好。常规的做法是把模型转成ONNX格式或者TorchScript格式。我导出的核心代码长这样import torch from transformers import BertForSequenceClassification model BertForSequenceClassification.from_pretrained(./checkpoint) model.eval() dummy_input torch.randint(0, 1000, (1, 128)) torch.onnx.export( model, dummy_input, model.onnx, input_names[input_ids, attention_mask], opset_version12 )导出ONNX之后推理速度能快不少。如果还想进一步压延迟可以再叠加上INT8量化。实测下来我的线上任务BERT模型在纯PyTorch模式下平均推理耗时约35ms。改成ONNX之后降到约22ms。再做一轮INT8量化继续降到12ms左右。不过量化口诀要记住收益和风险并存小模型量化容易掉点需要验证精度下降能否接受。5.2 服务化接口导出之后就需要把模型封装成一个标准HTTP接口。我用的是FastAPI它比Flask更适合AI场景因为自带异步支持、类型校验和自动文档调试起来太舒服了。from fastapi import FastAPI from pydantic import BaseModel import onnxruntime as ort import numpy as np app FastAPI() session ort.InferenceSession(model.onnx) class Payload(BaseModel): text: str app.post(/predict) def predict(payload: Payload): encoding tokenizer( payload.text, max_length128, paddingmax_length, truncationTrue, return_tensorsnp ) outputs session.run( None, { input_ids: encoding[input_ids], attention_mask: encoding[attention_mask] } ) label_id np.argmax(outputs[0]) return {label: label_id}这里有个很多新手都会踩的坑在接口函数里反复加载tokenizer和模型。正确做法是把模型和tokenizer在模块加载时初始化一次全局复用。否则每一次请求都在重新加载模型延迟会爆炸我的第一版线上服务就是这么翻车的。5.3 部署到K8s的关键配置如果你的服务要部署到Kubernetes环境有几个细节建议按这个模板来做resources: requests: memory: 2Gi cpu: 500m limits: memory: 4Gi cpu: 2AI服务的特点是内存占用高但CPU消耗波动大。如果limits设置得太紧推理突发高负载时Pod会直接被OOMKilled如果requests设置得太大又会导致节点资源利用率很低调度不过来。还有一个关键细节必须设置存活探针和就绪探针建议读/health端点。模型服务启动的时候需要几十秒时间加载权重如果探针没配好一扩容就不断重启服务永远达不到Ready状态。我的建议是initialDelaySeconds设置成60秒给模型加载留足时间。6. 常见问题与排查技巧实录6.1 问题速查表我把实际运行中遇到的最典型问题整理了一张表方便大家对照排查问题现象可能原因排查思路训练时显存不足OOMBatch size过大或序列过长减半batch size、开启gradient checkpointing、缩小max_lengthLoss不降且波动大学习率过高、数据标注噪声大降学习率、抽查数据标签、增加warmup验证集效果好线上效果差数据泄漏或训练/线上分布不一致检查切分逻辑、重新推到线上观察数据分布推理延迟太高模型每次请求重新加载、序列过长模型全局加载、缩短max_length、转为ONNX服务启动后不断重启探针配置不当、内存limit过小增大initialDelaySeconds、调大内存limit6.2 我的避坑清单整理几条最值得反复强调的避坑心得第一任何实验结果都记录下来。我当时维护了一个实验记录表包含数据集版本、模型名称、学习率、batch size、精确率、召回率、F1值、训练耗时。后面调参根本不用凭感觉翻表就够了。第二数据变更后重新评估模型。有一次业务方新增了几种标签写法我没有同步清洗规则模型线上效果直接掉了一个点。记住模型不变数据在变效果必然波动只有持续监控才能尽早发现。第三容器镜像要让体积可控。基础镜像尽量用python:3.10-slim推理镜像可以不安装编译工具链。一开始图省事直接装全量CUDA镜像镜像体积超过了3GB每次发布都要等上几分钟后来换成了更精简的runtime镜像体积降到了500MB发布时间快了一个数量级。第四不要盲目上最新的深度学习框架版本。AI生态的兼容性链条其实很脆弱PyTorch、CUDA、cuDNN、transformer版本的组合需要一起匹配。最优解是选一套“经过多人验证”的稳定版本组合锁定版本号而不是天天升级。第五推理服务的metric监控一定要做。每一个请求的延迟、模型推理耗时、token数量、返回的标签分布都要计数。我后来能快速发现线上异常都是靠这些基础指标一旦标签分布出现偏移模型大概率需要重新训练。7. 从一次完整实践得到的最后一课做完了这整条链路之后我最大的感受是AI工程里真正的壁垒不在模型而在数据质量和工程兜底能力。一个从零搭起来的系统运行三个月后模型效果还能稳定保持不是因为模型结构有多先进而是因为数据管线稳定、监控指标齐全、部署环节可控。如果你也在走这条路我的建议很简单别被网络上一堆“AI工程实战”课程带偏自己找一份真实业务数据哪怕只有1万条把从清洗到部署的完整闭环跑通一次。跑完之后你会发现那些网上说得玄乎的概念其实都是自己手里可以掌控的普通工具。最后再分享一个小技巧每完成一个环节写一个15分钟能讲完的文档说清楚当时为什么这样设计、踩过什么坑、如何验证效果。这些文档不仅是团队复盘的基础更是你下一次做更大AI项目的宝贵底料。