背景痛点:流量来了,系统'懵'了
我们最初上线的客服机器人,在常规流量下表现尚可。但问题在几次营销活动中暴露无遗:
- 响应延迟飙升:平时 200ms 内响应的接口,在并发用户数超过 500 时,TP99(99% 的请求耗时)直接飙升到 2 秒以上,部分请求甚至超时。用户等待时间过长,直接导致对话中断或用户流失。
- 意图识别准确率下降:核心的 NLP 意图分类服务,在低负载时准确率有 92%,但在高负载下,由于请求排队、计算资源争抢,模型推理效率下降,连带影响了识别准确率,跌到了 85% 左右,经常答非所问。
- 上下文管理混乱:为了维持多轮对话,我们用了简单的 Session 存储。高并发下,Session 读写冲突、缓存失效,导致用户上一句刚问完'手机价格',下一句说'那黑色的呢',机器人就不知道'那'指的是什么了,对话连贯性被破坏。
这些问题归根结底,是架构设计时没有充分考虑弹性和解耦。所有逻辑(接收、NLP 处理、业务查询、回复生成)都挤在同步调用链里,一个环节慢了,整个链子就堵住了。
技术选型:为什么是 BERT + 自建微服务?
面对这些问题,我们首先评估了解决方案。在 NLP 核心引擎上,主要考虑过三个方向:
- Rasa 开源框架:优点是开箱即用,对话管理功能强。但在我们的场景下,其内置的 DIET 分类器在复杂业务意图(超过 50 种)和领域特定表述上,准确率达不到要求,且性能优化深度不够。
- Dialogflow 等云服务:开发快,但存在数据隐私顾虑、长期成本高、定制化能力弱(特别是需要与企业内部系统深度集成时)以及网络延迟等问题。
- 自建 NLP 服务(BERT 微调):虽然初期投入大,但能获得最好的领域适配性、数据自主可控性,并且性能优化可以做到极致。结合我们的 Java 技术栈,最终选择了 Python (PyTorch/FastAPI) 微调 BERT + Spring Cloud 微服务 的混合架构。Python 擅长 AI 模型服务,Java 擅长构建稳健的企业级后台,两者通过轻量级 HTTP API 或消息队列通信,各取所长。
核心实现:拆解高并发处理流水线
整个方案的核心思路是 '异步化、缓存化、状态化'。
1. 领域适配的 BERT 微调与高性能服务
意图识别是智能客服的大脑。我们使用 BERT-Base-Chinese 模型在业务对话数据上进行微调。
数据增强:为了提升模型泛化能力,防止过拟合,我们对训练数据进行了增强。
import jieba
import random
def text_augmentation(text, augmentation_rate=0.3):
"""简单的文本数据增强:同义词替换、随机删除"""
words = list(jieba.cut(text))
new_words = words.copy()
num_to_modify = max(1, int(len(words) * augmentation_rate))
for _ in range(num_to_modify):
random_idx = random.randint(0, len(new_words)-)
(new_words) > random.random() > :
new_words.pop(random_idx)
.join(new_words)

