模型研发阶段，我们针对文本、语音两个模态分别选型落地，文本端使用BERT、MacBERT模型做情感识别，语音端依托Whisper、Wav2Vec2完成音频特征提取与识别。经过多轮调参迭代，单模型效果基本达标，再通过多模态融合方案，解决了单一模态识别精度不足、场景适配性差的问题。在实验环境中，整套模型的各项指标均达到预期，能够稳定正常运行。

        但在实际推进项目落地的过程中，我们深刻意识到一个核心问题：模型可以正常训练、跑出效果，绝不代表整套系统能够稳定上线落地。

        其实前期的数据处理和模型训练，都只是算法层面的实验验证和效果迭代，核心工作无非就是反复调参、优化模型识别精度，整体难点集中在算法效果打磨上。但落地项目后才切实发现，熙瑾会悟离线转记项目的真正瓶颈，不在于算法优化，而在于后续的工程化落地。该离线场景对整体系统的稳定性、运行速度、设备兼容性以及内存资源占用都有很高的硬性要求。模型适配适配、推理性能提速、本地化离线部署、运行异常容错等一系列工程问题，远比实验室调参复杂，也是贴合实际业务的核心痛点，是我们后续版本迭代需要重点攻克的方向。

十八、完整工程实践：从训练到上线的系统链路

我们最终上线的系统，其实是一个标准的多层架构：

1️⃣ 模块拆分原则

整个系统我们拆成了五个核心服务：

模块	作用
ASR服务	Whisper语音转文本
清洗服务	文本标准化处理
NLP服务	MacBERT情感分类
音频服务	Wav2Vec2特征提取
融合服务	多模态决策

2️⃣ 为什么必须拆分？

一开始我们是“单体推理服务”，结果很快就遇到问题：

①推理延迟过高

②GPU资源抢占严重

③模型无法独立升级

④ASR和NLP耦合太重

拆分之后：

👉 每个模块可以独立扩容

👉 每个模型可以单独升级

👉 故障不会全链路崩溃

十九、性能优化：工程上线最真实的挑战

在离线转记场景中，性能要求其实比模型精度更苛刻：

用户不能接受“等10秒才出结果”

1️⃣ 延迟优化（Latency Optimization）

我们最终目标：

指标	要求
单句延迟	< 300ms
会议流处理	实时级
批处理吞吐	> 200 req/s

优化手段一：模型量化

我们对 MacBERT 做了：

①FP32 → FP16

②ONNX Runtime 加速

效果：

👉 推理速度提升约 1.8x

优化手段二：缓存机制

对于重复文本：

这个方案可以推进

直接缓存结果：

情感：积极（cached）

优化手段三：异步流水线

2️⃣ GPU优化策略

我们做了三点优化：

①batch inference

②动态batch合并

③GPU显存复用

效果：

👉 GPU利用率从 45% → 82%

3️⃣ 并发控制

使用线程池 + 消息队列：

①Kafka / RabbitMQ

②ThreadPoolExecutor

③请求限流（RateLimiter）

二十、工程踩坑总结（非常真实的一部分）

这一阶段我们踩过几个典型坑：

坑1：ASR和NLP同步阻塞

👉 导致整体延迟翻倍

✔ 解决：改为异步流水线

坑2：模型版本混乱

不同服务加载不同版本 MacBERT

✔ 解决：统一模型注册中心

坑3：音频特征计算过慢

Wav2Vec2拖慢整体流程

✔ 解决：只在关键片段触发音频分析

二十一、这件事真正难在哪里？

如果用一句话总结这个项目：

情感识别不是NLP问题，而是“数据 + 语音 + 工程系统”的复合问题。

三个关键结论

① 数据决定上限

再强的模型也救不了脏数据。

② 模型只是中间层

BERT / MacBERT / Whisper 都只是组件。

真正核心是：

多模态融合策略

③ 工程决定能不能上线

离线训练 95% 准确率

上线可能只剩 80%原因不是模型退化，而是：

①延迟

②并发

③噪声

④数据漂移

二十二、最终系统中文架构图

二十三、系统效果（上线后）

最终上线后的效果：

指标	优化前	优化后
情感准确率	84%	93%
响应延迟	900ms	280ms
并发能力	50/s	220/s
稳定性	一般	高

二十四、结束语

这个项目做到最后，其实感触比较深的一点是：

AI系统不是“模型比赛”，而是“工程系统建设”。

很多时候不是模型不够强，而是：

①数据不干净

②标签不统一

③服务没拆好

④流程不合理

当这些问题逐步解决之后，模型反而只是“顺带变好”。