从零搭建AI工程：短文本情绪识别模型的完整落地实践

做了这么久的东西，我一直觉得“AI工程师”这个头衔被市场叫烂了。打开招聘软件一看，十个岗位里有八个是“AI工程师”，干的事却是调参、洗数据、调API、润色Prompt。不是说不重要，而是这些只是冰山一角。真正让我觉得有底气拿“AI工程”来命名的工作，是从零开始，把一个模型从无到有地搬进生产环境。这个项目我起名叫 ai-engineering-from-scratch，就是想用一次完整实操，把“AI工程”里那些非玄学、可复制、要流汗的部分，切成一块块拼图摆出来。

这个项目最适合两类人：一类是已经会用PyTorch或TensorFlow训练模型，但没正经上过线，不知道gradle和gunicorn怎么和模型沾上边的人；另一类是后端工程师，写接口很熟，但对训练曲线、过拟合、数据漂移这些概念只有模糊印象，想把AI这头大象完整摸一遍。

我把整件事拆成了五个阶段：系统边界与数据封闭、基线模型与训练策略、评估体系与迭代取舍、服务化与统一接口、可观测性与持续自动化。每一块都会结合一份我自己做过的“短文本情绪识别+主题聚合”项目来讲，工程细节全部可落地，参数给的是能直接进notebook跑通的那种。

1. 系统设计与数据闭环

1.1 先画边界：AI项目不是从模型开始的

很多新手一上来就抄模型结构，或者先决定“我要用BERT”。但我的习惯是：先回答三个问题——处理什么输入、产出什么结果、跑在什么环境里。

以我的短文本情绪识别为例，输入是APP内用户反馈文本，平均长度不超过50个字符；输出是“正向/负向/中性”三分类；环境是CPU密集型容器，内存上限2GB，时延容忍度是单条200ms以内。有了这些数字约束，很多选择就被锁死了：BERT-base会被淘汰，因为108ms的P99延迟在纯CPU上冲到250ms太常见；DistilBERT会成为主选，因为同样条件下能跑到60ms。选型不是凭感觉，是拿约束条件当筛子。

边界画完之后，立刻动笔写一条数据契约。不用写复杂文档，一个schema文件就够：

# schema.py from pydantic import BaseModel, Field class Sample(BaseModel): text: str = Field(..., min_length=1, max_length=200) label: int = Field(..., ge=0, le=2) source: str = Field(..., pattern="^(app|web|api)$")

这个文件的价值是让你在第一天、第100天回到项目时，序列化逻辑不出偏差。数据从源头到模型、再到落库，全部过这一个schema，脏数据在入口就会被拦掉。

1.2 数据采集与标注：封闭数据集才是底线

模型的效果上限，不是模型结构决定的，是你手里的数据决定的。我这次的采集策略有两条路并行：

• 现有用户评价库：取近12个月数据，按时间分层抽样，防止只取到某次营销活动后的极端情绪样本。
• 冷启动补采：在反馈入口埋了一个轻量打点，只多了一个字段“这条反馈让你觉得处理得怎么样”，用户点击即成为弱监督样本。

标注环节我踩过不少坑，最后定下的流程是：先由两个标注员独立标注同一批300条数据，计算一致性系数，低于阈值就拉到一起讨论分歧点，直到统一标准后再铺量标注。这样看着多花了两天，实际上避免了后期“重新标注一万条”这种地狱工作量。

最终我拿到2.8万条标注数据，其中负向占比46%，正向39%，中性15%。这里有个容易忽略的点：类别不平衡不一定要采样平衡。我处理的场景是“情绪识别”，负向比例高恰恰是产品事实，所以我保留自然分布，只在损失函数里加重了多数类的惩罚陷阱规避，具体做法是后续改用带类别权重的交叉熵。

1.3 数据清洗的策略要保守还是激进

数据清洗有一个铁律：能靠模型学到的，不靠规则硬删；靠规则删的，一定是你确信它不是语言而是噪声。

具体到我的文本数据，我做了三步处理：

1. 去掉HTML实体和短链，但保留URL本身——因为URL在反馈里往往意味着“用户附了截图链接”，这在情绪分析里有信号意义。
2. 统一中英文标点和半全角，但对表情符号保留原样。😡和😂对情绪分类是强特征，绝不能无脑过滤。
3. 不删重复样本，而是引入“同文本多次出现”作为一个计数特征传给后续模型——这在反馈场景下本身就是“大量用户共同遇到同一问题”的信号。

这套清洗逻辑做完，我得出的五折交叉验证F1是0.83，比“激进清洗版”（去掉所有符号、小写化、去停用词）的0.79高出一截。激进清洗适合传统机器学习，对深度学习反而有害，因为符号语境是特征不是噪音。

2. 采样策略与训练流水线

2.1 负样本挖掘：从沙堆里挑真正的垃圾

纯随机采样的负样本，会让模型学习到“哪些句子看起来正常”而不是“哪些句子语义真实”。我做过对比实验：随机负样本训练出的模型，在测试集上会轻易把“非常满意”识别为“中性”，因为训练时没见过太多强正向表达。

所以我改成了“困难负样本挖掘”策略：

• 先用当前模型跑一遍未标注池，取出预测概率大于0.6但实际非目标类别的样本。
• 将这些样本人工复核后并入训练集。
• 每训练一个里程碑版本，重新挖一次。

这个策略在第二轮迭代后，把中性类别的召回率从0.68拉到了0.74。虽然听起来不多，但放在线上就是每周少错判几千条用户反馈。

2.2 基线模型到底怎么选：从逻辑回归到DistilBERT

我不建议一上来就上大模型，先跑一个词频+逻辑回归作为基线。它的意义不只是给后续模型“垫底”，而是让你理解数据最基本的可分性。如果逻辑回归就能拿F1 0.72，说明特征空间里存在明显的线性信号；如果只有0.55，那说明语义信息远大于表面词汇信息，必须用表示学习。

我的逻辑回归基线是F1 0.72，TF-IDF特征维度限制在5万。这让我判断：词汇层面的信号很强，但“买回来发现是坏的，但是客服很好”这种转折句，逻辑回归会分错。这正是要上预训练语言模型的原因，而不是因为“大家都在用”。

最终训练用的是DistilBERT-base多语言版作为初始化权重，序列长度卡到64。因为中文短文本95%以上不超过64字符，再长就是浪费计算量。学习率用的是3e-5，batch size 32，warmup比例0.1，梯度裁剪到1.0。这个组合在多次不同数据集上都很稳，是标准的起步配方。

2.3 训练流程的编排与断点续训

训练永远不要在一个裸脚本里跑裸for循环。我用的是Ray Train做编排，它在断点续训上的表现比在notebook里自循环强一大截。

from ray.train import CheckpointConfig, RunConfig, ScalingConfig from ray.train.torch import TorchTrainer def train_func(config): # 模型初始化、DataLoader、optimizer等 pass scaling_config = ScalingConfig(num_workers=1, use_gpu=False) run_config = RunConfig( checkpoint_config=CheckpointConfig( num_to_keep=3, checkpoint_frequency=1, ), storage_path="/mnt/checkpoints", ) trainer = TorchTrainer( train_func=train_func, scaling_config=scaling_config, run_config=run_config, ) result = trainer.fit()

断点续训这件事，我吃过一次亏——训练到第3个小时，K8s节点重置，全部日志没同步，从头再来。后来我做了两件事：checkpoint每一轮都落盘，同时把原始数据放在对象存储上而不是训练机本地磁盘，保证任何一个新节点都能无缝接入训练任务。

2.4 收敛标准的判据不是“loss降了”

很多人看到loss从0.6降到0.3就觉得模型变好了。其实要分开看——训练loss降、验证loss不降，这是过拟合；两者同降，但业务指标F1不升，这说明loss下降和你的目标函数不对齐。

我这次项目的收敛判据是复合的：验证F1不再提升连续3个epoch，同时验证loss不再下降超过0.005，才触发早停。早停不是终点，早停后我会把历史上最好的checkpoint找出来，而不是默认最后一个。经验值：最后一个checkpoint往往已经过拟合0.5-1个点。

3. 评估体系与迭代取舍

3.1 不止是F1：要建一张评估清单

评估体系的建立原则是“先定好赛道再跑模型”。我建了一张多维评估表，每次实验输出都往这张表里填：

表格里的每一项都对应一个线上担忧：负向样本召回低会漏掉用户投诉，中性精确率低会把中立反馈误伤成负面，吞吐率决定要不要加机器。指标字段不是给论文看的，是给监控看板和告警阈值用的。

3.2 错误分析：看错例比看loss有价值

我最烦的一种汇报是“我的模型F1达到0.85”，问一句“错在哪里”答不上来。你必须做错误分析，我自己的固定动作是：从测试集抽100条错例，人工归类。一次典型的错误归因结果如下：

• 32%是标签噪声：标注员把“快递太慢了，但东西本身还行”标成“负向”，因为看到了“太慢”。
• 28%是语义转折：模型没学会“虽然...但...”结构。
• 18%是领域专名：产品名、版本号干扰。
• 22%是标注标准分歧：两个标注员给的标签本身不一致。

看到归因以后，我的下一步动作就不是“调超参”了，而是：第一，修订标注指南，明确“转折后态度优先”；第二，针对“虽然但”句式扩充同义改写数据；第三，把无法达成共识的样本从训练集剔除。

3.3 迭代取舍：不是每个指标都要拉满

很多人做迭代，喜欢把所有指标都往上顶。但工程现实是：中性类别的精确率每提升1个百分点，可能需要牺牲负向召回2到3个百分点。这种取舍只有结合业务才能定。

我这次的做法，是给三类错误定了一个业务代价矩阵：将负向误判为中性（漏掉投诉）的代价最高，等价于召回失败；将中性误判为负向的代价次之，可能是客服点开一条普通反馈；将正向误判为中性的代价最小，因为用户即使收到确认也不会有太大反应。

基于这个代价矩阵，我在最后一次迭代时，选择了一个在测试集上“宏F1不是最高、但加权业务代价最低”的checkpoint。这个模型宏F1是0.82，但相比宏F1最高的版本，漏投诉率下降了13%。AI工程不是打榜，是给业务方程求最优解。

4. 服务化与统一接口

4.1 用一个标准接口包装所有模型

服务化这里，我只认一条原则：任何模型，都暴露成同一个HTTP接口。输入一律是{text: str, request_id: str}，输出一律是{label: int, prob: float, version: str}。这样上游只对接一次，后续模型升级、回滚、灰度都不动业务代码。

我用FastAPI来做这个服务层，原因很朴素：异步支持好，Pydantic原生集成，文档页自动生成，省掉一版手写API文档。

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class PredictRequest(BaseModel): text: str request_id: str = "" class PredictResponse(BaseModel): label: int prob: float version: str @app.post("/v1/predict", response_model=PredictResponse) async def predict(req: PredictRequest): out = model_service.predict(req.text) return PredictResponse(**out)

这个接口上线以后，前后端联调只花了半小时。对比之前见过的一个项目，模型团队自己定了一套socket协议，前端接不了，后端又要多写一层适配，完全是自找麻烦。

4.2 模型推理优化：CPU上如何省出3倍算力

CPU推理的优化，第一步永远是量化感知训练，不是事后ONNX。我把DistilBERT先做量化感知训练（QAT），再导出成ONNX Runtime的int8格式。QAT比训练后量化（PTQ）多了两三个epoch的事，但精度损失能控制在1%以内，PTQ则常掉到3%以上。

导出和推理的核心简化版如下：

import onnxruntime as ort import numpy as np sess_options = ort.SessionOptions() sess_options.intra_op_num_threads = 4 sess_options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL session = ort.InferenceSession("model_int8.onnx", sess_options) def predict(text: str): inputs = tokenizer(text, return_tensors="np", max_length=64, truncation=True) probs = session.run( None, { "input_ids": inputs["input_ids"], "attention_mask": inputs["attention_mask"], } )[0] return softmax(probs[0])

做了QAT+int8之后，单条P99时延从74ms降到了31ms，吞吐提升了快3倍。有人会问，为什么不直接换更小的模型？因为换模型等于重做一遍业务验收，而量化只是部署优化，流程不变、效果偏差在1分以内，风险完全不是一个量级。

4.3 批处理与缓存设计：削峰填谷

线上反馈量不是匀速的，晚高峰往往是白天的5倍。如果每一条都单独实时推理，峰值时CPU直接爆。我的做法是两条腿走路：

• 实时推理走同步接口，超时阈值200ms，负责高优场景。
• 大批量清洗类反馈走离线批处理，用Celery挂在RabbitMQ上，消费端一次拉200条做动态padding和batch推理。

动态padding值得多说一句：同一batch内部按最大长度补齐，而不是全batch都到64。只这一项，离线批处理的吞吐就提升了一倍多，因为90%的句子实际只有30个token左右。这是那种看起来不起眼、实际影响很大的工程细节。

缓存方面，我做了两层：第一层是Redis短缓存，相同文本5分钟内不重复推理；第二层是“高置信度直接落库”——只要概率大于0.99且版本号没变，就不再进人工复核队列。这套组合在高峰期帮我们拦截了约22%的重复请求。

5. 可观测性与持续自动化

5.1 记录一切：从推理日志到灰度标记

服务上线只是开始，真正的工程体现在你能不能在凌晨两点回答“昨晚10点模型为什么把这批全分错”。我要求所有推理日志带上五个字段：request_id、模型版本、输入文本、输出标签、各标签概率。每一条都落盘到数仓的日志表，方便事后回放。

这里有个实战做法：不回传原始文本到日志系统时的脱敏困惑。但我们的场景是接收用户文本，隐私合规要求高，所以日志里记录的是文本的hash值，以及一个“是否转人工”标记。正经做线上模型，敏感信息处理比任何优化都优先。

灰度标记也很关键：同一个接口后面可能跑着v1和v2两版模型。我在响应里固定返回version字段，就是方便监控按版本拆指标。否则黑盒上线一个新模型，出问题你连错误面都圈不出来。

5.2 数据漂移监控：模型会默默变蠢

一个常见的线上事故是：模型上线时好好的，三个月后指标悄悄掉了5个点。原因通常是数据漂移——用户表达方式变了、产品改版带来新词、运营活动催生了大量新句式。

我的监控方案是在线预测分布与训练分布做对比：

• 每小时统计线上预测的三分类概率分布。
• 与训练集的三分类分布做KL散度对比。
• 超过阈值就触发告警，并自动攒一批漂移区间内的样本进人工复核区。

这套触发过两次，一次是因为产品上线了新用户引导语，大量的“我不会用这个”出现在反馈里，模型把它归为负向，但工程上这属于“求助类”而非情绪负向。第二次是客服改版后，用户开始大量提到“工单号”，这个词汇在训练集里出现极少。两次都被及时拦下，没有造成声誉上的事故。

监控不是锦上添花，对AI服务来说，它就是刹车系统。

5.3 CI/CD：模型版本不是一个文件，是一组资产

模型版本管理，必须和代码版本管理一样严格。Git LFS只适合存小模型，项目到了上百MB，我会用DVC管理数据和模型文件，每次训练的代码、数据版本、超参、评估结果、模型权重完整绑定成一个不可变快照。

CI流水线大致分四步：

• Lint和schema检验：跑一遍pytest和Pydantic数据契约的单测。
• 训练冒烟测试：用1%的数据跑1个epoch，确保训练脚本不炸。
• 评估门禁：在固定验证集上跑评估，F1低于当前在线版本0.5个百分点则直接拦截。
• 镜像构建：把模型权重、tokenizer配置、推理代码打成OCI镜像，推送到私有仓库，然后K8s滚动发布。

这个门禁很重要。有次我改了一版预处理逻辑，F1涨了1.2个点，但推理P99时延多了40ms，门禁判定“整体代价超标”，把版本打了回去。没有这种自动化的限制，线上质量就是靠自觉，靠自觉的工程系统注定会腐烂。

6. 工具链选型与常见坑位

6.1 为什么这套组合：选型逻辑一览

经常有人问“这个项目用XX框架行不行”。我一般回一句：框架只是约束条件，你先想清楚你要的组织架构和时间尺度。

我这次的选型最终是：

这套组合的特点是“不追新、看稳”。每个组件都是各自领域的top级别选手，组合在一起不打架，文档能覆盖90%的坑。如果你要换，先问自己为什么换：性能瓶颈在哪个环节，换完带来的复杂度是否可控，这才是选型该有的姿势。

6.2 实操期翻车最多的五个坑

给后来者列几个我踩过的、让人觉得“不应该但确实发生了”的坑：

1. 多卡训练时数据没用DistributedSampler：重复采样或漏采样悄无声息发生，训练出来的模型比单卡还差。所有DataLoader在DP/DDP下都要检查分布式采样器。

2. checkpoint只落一台机器：看似写了checkpoint文件，实际只存在本地盘上，容器一删就没了。解决方案就是落对象存储或共享存储卷。

3. tokenizer没跟着模型版本走：旧tokenizer和新模型混用导致解码乱码，输出概率异常。tokenizer的版本必须和模型一起做快照绑定。

4. 时延优化后忘了重新做压测：int8量化模型功能正确，但并发一上来就超时。量化不只是看精度和时延，还要做并发压测，看response时间的分位点是否稳定。

5. 日志字段加了版本号但监控面板没拆维度：数据是有了，但Grafana面板还按整体聚合，版本间差异还是看不到。监控设计要和日志设计同步做，不然又变成“数据收集了但没法用”。

6.3 一个关于工程思维的收尾

最后聊点纯经验。做这趟项目我最大的感受是：AI工程拼的不是谁的模型更炫，而是谁的系统更不容易坏。训练出好模型的人很多，能让模型在线上稳定跑三个月不烂掉的人，才是团队抢着要的。

我给自己的实践总结是三条：数据诚实，评估多维，部署留痕。所谓数据诚实，是不美化也不掩盖数据分布的缺点；评估多维，是永远用一张表而不是一个数字说话；部署留痕，是所有动静都落版本、有记录、能回滚。这三条做到，你的AI项目就不太会在某个深夜里给你“惊喜”了。

如果你准备自己开一个from-scratch项目，我建议不要从零手写BERT，也不要把时间花在刷SOTA上。挑一个真实的小场景，哪怕是一个内部的文本分类，走完数据清洗、训练、评估、部署、监控全流程，比你在网上看二十篇教程都值。从零到一才是AI工程真正的地基。