1. 从零开始做AI工程化真正要解决的是什么很多人看到ai-engineering-from-scratch这个标题第一反应是又要从Python语法开始讲一遍。但真正在业务里摸爬滚打过的人会明白AI工程化最难的从来不是模型代码本身而是那条从能跑通到稳定上线再到可持续迭代的路。我见过太多团队Demo演示时效果惊艳一上生产就崩——不是模型不行而是工程化环节全线失守。这个项目的核心就是把我自己从零搭建一套AI应用体系的完整过程和踩坑记录做了一个系统梳理。它不是一个单一的工具或者框架而是一整套方法论和工程实践的集合覆盖了从环境搭建、数据管线、模型训练、服务化部署到监控迭代的完整生命周期。我强调from-scratch不是说要你拒绝现成的轮子而是说你要理解每个轮子为什么存在、在什么场景下该用哪个、出了问题从哪里排查。如果你是一个想真正把一个AI想法落地成可用服务的开发者或者团队里正打算从零建设AI基础设施但是不知从何下手这篇文章适合你。即使是新手只要跟着做一遍也能建立起对AI工程全貌的认知而不是只会调用现成接口的黑盒使用者。2. 整体设计思路为什么我选择全链路自建而不是直接用云平台2.1 自建与托管平台的真实对比先聊一个选题问题。现在云平台提供的AI服务已经非常成熟从训练到部署都能一键托管那为什么还要自己从零搞一套我的答案很直接为了可控性和长期成本。托管平台在小流量、原型验证阶段确实香开箱即用不用操心GPU调度和运维。但一旦业务量上来你会发现几个非常难受的问题单次推理的单价降不下去模型版本更新受平台限制数据字段想加一个都得走平台改造流程。更关键的是模型和推理逻辑绑定在别人的平台上后期想切框架或者迁到自有环境迁移成本高到能让你怀疑人生。所以我在这个项目里选了全链路自建、按需引入开源组件的路线。本地训练环境用Docker管理依赖推理服务自己写接口监控埋点在应用层完成。这样做的好处非常明显每一层的行为都在控制范围内出问题可以扒开看底层细节而且成本曲线是完全线性的而不是一个越用越贵的月付费账单。2.2 贯穿全流程的示例项目客服工单自动分类系统技术文章如果只讲概念读者很难带入实际操作。为了让整套流程不悬空我选了一个非常典型的业务场景贯穿全文——客服工单自动分类系统。这个系统的任务是接收用户的反馈文本自动判断工单属于退换货物流咨询产品故障价格疑问中的哪一类并打上对应的紧急等级。选这个场景是因为它几乎覆盖了AI工程化的所有核心要素非结构化文本数据需要清洗和标注、类别分布不平衡需要采样策略、模型需要满足低延迟在线推理、线上数据分布会随时间漂移。做完这一个项目相当于把所有关键链路都摸了一遍。之后你无论做什么方向的AI应用核心骨架都是一样的。整个系统的技术栈是Python 3.10 PyTorch 2.x做模型训练HuggingFace Transformers做预训练模型管理MLflow做实验跟踪FastAPI做推理服务封装Docker Compose编排整个环境Prometheus Grafana做运维监控。这套选型是经过反复对比后定下来的下面我逐个解释为什么是它们。3. 环境与基础设施搭建管线稳定的第一道关卡3.1 开发环境与硬件选型的关键细节很多人会在环境搭建这一步随便糊弄直接在一台机器上pip install完就开始干活然后过了两个月所有依赖都乱了没人能复现当时的结果。我在这个项目里从一开始就坚持环境即代码用Docker固化整个开发环境。基础镜像我选了pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime为什么不用官方Python镜像自己装PyTorch因为PyTorch的CUDA依赖版本组合非常敏感自己装很容易装出运行时报错而官方镜像里的依赖组合是测试过的。另外开发环境和生产环境必须用同一份Dockerfile构建这样在我机器上能跑这句话就直接失效了。GPU选型上如果是做文本分类这个规模的任务一张RTX 3090或者4090就足够了。不一定要上A100但显存至少要有24G因为加载BERT类模型做训练时输入批次越大会明显影响训练速度显存太小就得削减batch size反而浪费时间。这里有一个值得记录的经验CUDA版本和显卡驱动版本的关系经常被人忽略。很多人跑起来发现CUDA error: no kernel image is available for execution on the device其实就是镜像里的CUDA版本和宿主机的NVIDIA驱动版本不匹配。宿主机驱动的兼容规则是向下兼容的所以我的建议是宿主机驱动尽量装新的稳定版镜像里的CUDA版本控制在12.x这一代就能避开绝大多数坑。3.2 项目结构与依赖管理策略工程化项目最忌讳把所有脚本平铺在一个目录里。我用的项目结构长这样├── configs/ # 所有配置文件的集中地 │ ├── data_config.yaml │ ├── train_config.yaml │ └── deploy_config.yaml ├── src/ │ ├── data/ # 数据加载、清洗、增强脚本 │ ├── features/ # 特征处理代码 │ ├── models/ # 模型定义与训练逻辑 │ ├── serving/ # 推理服务代码 │ └── monitoring/ # 监控指标暴露逻辑 ├── tests/ # 单元测试与集成测试 ├── scripts/ # 一键执行的shell脚本 ├── Dockerfile └── docker-compose.yml目录隔离的意义不只是好看。当项目膨胀到几万行代码时清晰的边界能避免很多意外——比如训练脚本不小心import了服务端的依赖生产环境装了一堆没用的包导致镜像体积变大、攻击面增加。依赖管理我用的是requirements.txtpip-tools的方式。不直接用requirements.txt手写版本号而是先写一份requirements.in声明顶层依赖再用pip-compile生成带完整传递依赖锁定的requirements.txt。这样既保证了可复现性又不需要像Poetry那样引入一套全新的包管理心智。Docker部署时我用了两阶段构建。第一阶段装全量依赖并跑测试第二阶段只copy真正需要跑服务的Python环境把最终镜像控制在2GB以内。这个体积对于内网部署来说已经算友好了。4. 数据工程决定模型效果上限的隐形战场4.1 数据采集与清洗的实操细节很多人以为机器学习项目最花时间的是调模型实际上真正做过项目的都知道数据工程通常要占掉整个项目60%以上的时间。我在客服工单分类这个项目里用的是脱敏后的历史工单数据大约5万条真实文本初始标签两类后来又扩展成四类。拿到原始数据的第一件事不是急着清洗而是先做摸底。我会写一个脚本统计几个关键指标字段缺失率、文本长度分布、类别占比、重复记录比例。这一步非常关键因为它决定了后续清洗策略的方向。比如我之前遇到过一个数据集看起来有10万条结果去掉完全重复的网页爬虫采集真正有效的只有3万条如果不做去重模型就是在重复学习同一批文本。清洗环节有几个容易忽略的细节统一文本编码。不同来源的数据可能混着GBK、UTF-8甚至Latin-1编码的文件加载时不指定正确的编码方式就是一片乱码。我的做法是统一用utf-8读取遇到解码失败就尝试gbk和latin-1再不行就丢弃该条记录。全半角字符统一。客服工单里经常出现全角括号、引号、逗号混半角的情况这会在后续的分词阶段制造大量无效字符。用unicodedata.normalize配合正则表达式把全角字符统一转半角。业务层面的脏数据。文本里夹杂的身份证号、手机号、邮箱地址这种个人敏感信息要在采集阶段直接打码这样后续谁拿到数据都不会有合规问题。清洗完成后我还做了一步人工抽检随机抽200条清洗后的文本看有没有误删关键内容的。这个抽检环节让我阻止过两次误伤场景——有一次正则表达式把v2.0版本里的2.0当版本号干掉了但那个字段是产品型号的一部分删了之后文本就失去了关键信息。4.2 弱监督标注与标注一致性评估标注是AI工程里最容易被低估成本的一环。我这次没有选择全部人工标注因为5万条数据逐条标下来工作量太大了。实际做法是规则初标 人工修正的弱监督方案先用一组关键词和正则规则把明显属于某类的工单自动标上比如包含退货字样的先归到退换货类包含快递和几号到归到物流咨询类剩下规则无法确定的全部留给人工。这样做的好处是快速拿到了大部分有标签数据风险在于规则标注有错误。所以数据集的质检环节必不可少。我在这个项目里做了一套标注质量评估用到了两个核心指标标注信度Cohens Kappa和标注漂移率。信度评估的做法是让两位标注员独立标注同一批200条数据然后算他们的一致性Kappa值大于0.8才算通过。漂移率则是每周抽50条已标注数据和当时的标注规则对比看有没有因为常识变化导致的标签漂移。这个环节做完最终得到的标注数据集是规则初标4万条、人工精标1万条其中人工精标的那部分作为验证集的唯一来源。这样做是为了防止规则标注的系统性偏差污染评估结果。4.3 特征工程的取舍从手工特征到Embedding对于文本分类任务特征工程的选择空间其实非常大。刚开始做基线时我用的是TF-IDF 逻辑回归特征是n-gram的权重矩阵。这样做的意图是先拿到一个性能底线用来校准后面复杂模型的提升空间。TF-IDF虽然在深度学习面前显得朴素但它有一套天然优势可解释性极强。比如我可以直接打印出退换货类别下权重最高的Top 20词快速判断数据质量还能给规则标注提供修正依据。模型效果也要看实际情况——在这个工单数据集上TF-IDF 逻辑回归能跑到约82%的F1分数而微调BERT-base只提升到91%左右。没有基线模型的参照你可能都不会意识到中间这9个点的提升有多值得。真正到了深度模型阶段特征工程的重心就转移到了文本预处理和输入构造上。我使用的是HuggingFace的BertTokenizer关键参数是max_length128——超过这个长度直接截断短文本补零到固定长度。这里有一个细节截断方向一般人用默认的右截断但客服文本往往是前面是客套开场后面才是真实问题描述所以我改成了左截断保留文本后段。这个小改动在验证集上直接涨了约1.2个点的F1。当你能观察到这类细颗粒度特征的影响时才算真正理解了模型输入的语义结构。5. 模型训练与调优从基线到最优的进阶之路5.1 基线与进阶模型的双轨策略模型选型上我没有一上来就上最贵的大模型而是走了双轨制一轨是轻量级的TF-IDF 逻辑回归作为基线另一轨是预训练语言模型微调。为什么一定要有基线因为深度学习模型训练耗时而且存在随机性如果没有一个确定性高、训练便宜的基线模型做参照你很难判断深度学习模型提升的究竟是真的学到了数据规律还是纯粹因为模型容量大而拟合了噪声。从工程角度看基线模型更大的价值是当线上深度学习模型出现异常波动时可以立刻切到基线模型顶上保住系统的基本可用性。进阶模型侧我尝试了三种热门的文本表示方案BERT-base-chinese、RoBERTa-wwm-ext和MacBERT。这里不建议直接盲目选择而是做了小规模对比实验同样在1万条精标数据上训练3个epoch观察验证集的F1。结果RoBERTa和BERT的差距不到0.5个点但训练时间多了40%。最终在生产环境选了BERT-base-chinese因为它更成熟、社区资料更多、部署生态更好而性能差距完全可以通过后续的优化策略补回来。5.2 训练脚本设计与超参选择背后的逻辑训练脚本是这个项目里最容易被反复改动的地方所以我从一开始就做了配置与代码解耦。训练超参数全部放在configs/train_config.yaml里代码不写死任何超参值。这样每次调参只需要改配置文件还能通过MLflow自动记录每一次实验的完整参数组合和结果。model: pretrained_model: bert-base-chinese max_length: 128 num_labels: 4 training: learning_rate: 2e-5 batch_size: 16 epochs: 3 warmup_ratio: 0.1 weight_decay: 0.01 gradient_accumulation_steps: 2 evaluation_strategy: epoch save_strategy: epoch load_best_model_at_end: true metric_for_best_model: f1几个关键参数的选择逻辑值得展开说说。学习率2e-5是针对BERT微调的经典默认值它的逻辑是预训练模型已经学到了通用的语言表示微调阶段只需要做很小的权重扰动学习率太大容易灾难性遗忘掉预训练阶段学到的知识。warmup_ratio设为0.1意思是前10%的训练步数让学习率从0线性增长到目标值这个设计是为了避免训练初期的大步长导致loss剧烈震荡。weight_decay0.01这一点在PyTorch的AdamW实现里尤其需要注意。我之前踩过一个坑直接用PyTorch自带的AdamW优化器没设置correct_biasTrue结果训练和验证的loss一直在乱跳后来发现是参数里把bias和LayerNorm权重也做了权重衰减正确的做法是把这两类参数排除在权重衰减之外。HuggingFace的Trainer内部其实已经处理了这点但如果自己手写训练循环这是最容易埋坑的地方。训练过程中的一个有效技巧是梯度累积。由于单卡显存有限batch_size16是上限但实验中发现更大的batch能提高稳定性。方案是设batch_size16、gradient_accumulation_steps2等效于一个batch为32的更新步。这个做法并不会带来额外的显存消耗只是训练时间稍微变长性价比极高。5.3 MLflow实验跟踪的落地实践实验记录这件事很多人觉得记在脑子就行实际上项目做到第五天你就分不清上次跑出来的0.89是什么参数组合了。MLflow在这个项目里承担了三个职责实验跟踪、模型注册、模型对比。用法非常简单在训练代码里加入自动记录import mlflow mlflow.set_experiment(ticket_classification) with mlflow.start_run(): mlflow.log_params(params) mlflow.log_metrics({f1: f1_value, precision: precision_value}) mlflow.log_artifact(configs/train_config.yaml) mlflow.pytorch.log_model(model, model)之后你可以在MLflow UI的表格里对比每一次run的F1、精确率、召回率还能直接看到每组超参数的组合。我在这个流程里养成了一个习惯每次训练跑完不管结果好坏都顺手记一段Notes写清楚这次改了什么、预期是什么、实际效果如何。这些带注释的实验记录在项目复盘时价值远大于纯数字指标。6. 服务化部署把模型真正变成可用接口6.1 推理服务架构设计与接口规范模型训练完毕只是开始真正交付的是接口。我选型FastAPI而不是Flask或Django核心原因是FastAPI原生支持异步请求和Pydantic参数校验在高并发推理场景下性能更好生成的OpenAPI文档还能直接给前端或者调用方做联调。服务架构本身是一个轻量级的Python进程接收JSON请求把文本传入模型返回类别和概率分布。用Docker把服务封装后通过docker-compose统一编排服务、监控组件和依赖组件。核心代码在src/serving/app.py里from fastapi import FastAPI, HTTPException from pydantic import BaseModel import torch import onnxruntime as ort app FastAPI(titleTicket Classification Service) class InferenceRequest(BaseModel): text: str request_id: str class InferenceResponse(BaseModel): label: str confidence: float logits: list[float] session None app.on_event(startup) async def load_model(): global session session ort.InferenceSession(/models/model.onnx) app.post(/predict) async def predict(req: InferenceRequest): if not req.text.strip(): raise HTTPException(status_code400, detailtext cannot be empty) # 预处理逻辑 encoded tokenizer(req.text, truncationTrue, max_length128, return_tensorsnp) outputs session.run(None, dict(encoded)) label_idx outputs[0].argmax() confidence float(torch.softmax(torch.tensor(outputs[0]), dim-1).max()) return InferenceResponse(labelid2label[label_idx], confidenceconfidence, logitsoutputs[0])接口设计上有几个细心的地方一是每个请求都带一个request_id调用方可以用它索引日志排查问题时能精确追踪到某一条文本二是返回里包含logits向量而不是只返回标签这样下游系统可以根据业务规则自主决定置信度阈值不受模型硬编码影响。6.2 模型转换从PyTorch到ONNX的性能优化如果直接把PyTorch模型扔进服务进程推理速度还是偏慢。PyTorch默认是动态图模式每次前向传播都需要重新构建计算图而生产环境里输入的长度和形状通常是固定的这种灵活性其实是在浪费推理时间。因此我在部署前将模型转成了ONNX格式。转换的命令很简单import torch from transformers import BertForSequenceClassification model BertForSequenceClassification.from_pretrained(./best_model) model.eval() dummy_input { input_ids: torch.randint(0, 30522, (1, 128)), attention_mask: torch.ones(1, 128, dtypetorch.long), token_type_ids: torch.zeros(1, 128, dtypetorch.long), } torch.onnx.export( model, dummy_input, model.onnx, input_names[input_ids, attention_mask, token_type_ids], output_names[logits], dynamic_axes{input_ids: {0: batch_size}}, opset_version17 )ONNX转换后在CPU上跑的话推理速度能有2到3倍的提升。在GPU上收益没那么夸张但也能节省约30%的延迟。部署时我用onnxruntime-gpu而不是onnxruntime这样GPU版本的推理引擎才能真正利用CUDA加速。推理服务上线后我还专门做过一次压测用locust模拟100个并发用户持续打5分钟观察P99延迟。结果从最初的450ms降到转换后的180ms左右这个结果让我坚定了上线前必须先做ONNX转换这个流程在项目中的地位。6.3 容器化部署与资源限制的细节Docker部署时我特意设置了一些资源限额在docker-compose.yml里体现services: inference-service: build: . ports: - 8000:8000 deploy: resources: limits: cpus: 2.0 memory: 4g reservations: cpus: 0.5 memory: 1g environment: - CUDA_VISIBLE_DEVICES0 - OMP_NUM_THREADS2这个配置里最容易被忽略的是OMP_NUM_THREADS。PyTorch和ONNX Runtime都依赖OpenMP做并行计算如果不设置这个环境变量它们会尝试拿满宿主机所有CPU核心不仅造成计算资源的浪费还会在容器和高并发场景下引发线程争抢。我一开始没设这个变量压测时发现延迟极其不稳定排查半天才发现是CPU核心数被拉满导致上下文切换频繁。加上这个约束后延迟曲线立刻平滑了。7. 监控与持续迭代模型上线后的生死线7.1 从系统指标到业务指标的监控体系很多AI项目上线时很热闹过了一个月就进入了无人维护的状态。直到某天用户投诉准确率不行了才发现模型早就因为线上数据分布漂移变成了废物。为了避免这个尴尬我从第一天就给系统加了两层监控系统指标和业务指标。系统指标用Prometheus采集Grafana画图。主要看三个东西推理延迟、请求QPS、内存和显存占用。这些指标可以帮我判断是机器资源不够还是服务代码有bug。比如延迟突然飙高先看是不是显存被打满再看是不是有慢请求阻塞了事件循环。业务指标才是AI系统特有的核心。我暴露了一个自定义的Metrics接口统计在线请求的类别分布、平均置信度、拒绝服务的请求比例。逻辑是这样的from prometheus_client import Counter, Histogram PREDICTION_COUNTER Counter( prediction_total, Total prediction count, [predicted_label] ) CONFIDENCE_HIST Histogram( confidence_score, Confidence score distribution, buckets[0.5, 0.7, 0.8, 0.9, 0.95, 1.0] )平均置信度这个指标尤其值得关注。如果模型预测的置信度整体在持续下降很可能说明线上数据出现了训练时没见过的模式。比如一段时间内用户开始集中反馈某个新产品的质量问题但模型没见过这个产品的词表只能靠上下文猜置信度自然就低了。这类情况靠定期离线评估很难及时发现但监控指标能在几天内就露出苗头。7.2 模型漂移检测与自动重训机制聊到数据漂移就不能不提自动重训机制。我在这个项目里落地了一个简单的漂移检测流程核心是监控线上预测分布和训练集分布的差距。用的是KL散度做度量每周跑一次任务把这一周所有线上工单的预测标签分布算出来和上周、以及和训练集的标注分布对比。当分布差异超过预设阈值时就自动触发一次重训任务。重训的流程完全是跑的固定Pipeline拉取最新的人工精标数据 → 合并上周新增的标注数据 → 重新训练 → MLflow评估 → 如果F1高于当前生产模型则注册为新版本 → 手动确认后发到预发环境验证 → 最终切换线上流量。这套机制最大的意义不是全自动本身而是它提供了一条人工确认链路。模型重训不像代码发布质量无法通过编译检查保障机器永远会有误判的风险。因此我坚持所有自动生成的模型版本都必须经过人工审核确认才能上线。我不会让一个模型在没有人工把关的情况下自己上生产。8. 常见问题与排查技巧实录8.1 我踩过的高频坑与解决方案整个项目从零搭完踩过的坑装了一大箩。我把最有代表性的几个列成了一张速查表可能对你也有用。现象根因解决方案训练时loss乱跳不收敛AdamW权重衰减作用于bias与LayerNorm参数手写训练循环时排除bias与LayerNorm参数不参与权重衰减CPU推理极慢延迟波动大未设置OMP_NUM_THREADS导致线程争抢容器或进程环境变量中明确设置线程数加载模型时报CUDA error镜像CUDA版本与宿主机驱动不兼容统一镜像CUDA为12.x宿主机驱动保持较新稳定版验证集指标高但线上效果差验证集存在数据泄漏或标注漂移验证集必须来自独立的人工精标数据并定期抽检标注一致性文本截断方向错误尾部信息重要却被默认右截断截掉BertTokenizer设置truncation_sideleft标准停用词被过度清洗某些停用词恰恰是业务关键词如不行停用词表必须结合业务场景定制不要直接用通用库有一条经验值得单独拿出来说类别不平衡永远比你想的更严重。客服工单场景里退换货类可能占了70%产品故障只有8%。如果不做处理模型会学会把所有东西都往大类塞F1照样很高但业务上等于废了。我的方案是训练集中对小类做简单过采样再用weighted sampler配合focal loss。最终小类的F1从42%提升到了76%大类的F1只下降了2个点。这个收益比是极其划算的。8.2 排查复杂问题的方法论沉淀排查问题的时候我自己的经验是坚持分层排查的思路。当线上推理突然出错先判断是网络层、服务层还是模型层的问题。具体做法是先看Grafana面板有没有系统指标异常再翻服务日志看有没有堆栈报错最后才轮到模型推理层面。有一次线上服务P99延迟从180ms飙升到3秒我第一反应以为是GPU资源问题结果一看显存使用率正常CPU也不高。翻日志发现是某条请求写出了特别长的文本tokenizer做了超长截断但推理阶段还是走了极端路径。这种问题如果直接从模型层下手可能半天都查不到根因。数据、算力、框架、业务逻辑每一个层面都可能藏着问题排查顺序比排查手段更重要。9. 写在最后的个人体验与建议把这个项目从头到尾搭了一遍之后我最深的体会是AI工程化的复杂度不在于某个单独环节而在于所有环节的连接处。模型效果不好可以调参接口性能差可以做缓存和加速真正磨人的是那些模型在A环境训练在B环境推理数据在C环境存储的边界问题。每当你觉得系统应该没问题了总有某个边界处的隐性假设被打破然后就是新一轮排查。所以如果让我给准备从零开始做AI工程化的朋友一个建议那就是请留足数据工程的时间然后尽早把监控体系搭起来。模型总会优化到位基础设施才是你真正的底气。这个项目本身也还在持续迭代中我后续可能会补充OCR能力进来让工单里的图片截图也能参与自动分类这样整个系统的覆盖面会更完整。