智能客服架构

智能客服系统架构图

智能客服系统的实现多种多样,跟所服务的场景有关,本文总结了一种简单的实现,只保留了最核心的组件,来讲解如何实现一个对话系统的搭建。

Intent & Slot

一个用户的query进来后,首先要进行意图和实体抽取,意图分类用于判断用户的目的,比如是询问怎样下载APP还是询问课程价格,至于询问的是哪个App或者哪个课程,是通过实体抽取来进行的。有了意图和实体信息后,就可以通过一个状态机获取回复了。

DST(Dialogue State Tracing)

DST就是一个有限状态机,定义了在已有状态+某个输入状态下,给出输出+跳转到的状态,可以通过一个简单的规则引擎实现,例如可以定义如下的规则格式:

$$输入状态 & 已有前置条件$$需要不满足的条件$$输出内容 & 执行动作$$跳转到的状态$$规则优先级

该规则可以描述为:

if (输入状态 & 已有前置条件) and not (需要不满足的条件):
    do 输出内容 & 执行动作
    do 跳转到的状态

然后实现一个规则引擎来解析该规则即可。用户的query连同标注id、当前会话状态等信息传入状态机,状态机匹配成功的情况下返回输出给用户的回复内容,并在后台执行相应的动作,比如更新用户的会话状态,以及将有价值的信息更新到CRM系统。一般在DST中添加的规则主要是任务导向的,就是说一些明确的需要完成的任务相关的话术需要在DST进行配置,比如用户询问如何下载APP,引导用户输入姓名手机号,引导用户填写调查问卷等。其他内容比如一些日常聊天相关的内容,或是一些常见的问题回复则放在FAQ里完成。

FAQ

FAQ用于回复一些常见的问题,包括一些日常闲聊的内容,不指向特定用户,属于通用回复。这里常用的方法是问题相似度匹配,如常见的双塔模型+faiss向量召回,同时也需要添加一个规则引擎来处理一些高频或易出错的问题。如果FAQ无法获取置信度高的回复,可以转人工。

在线配置平台

在Intent & Slot、DST、FAQ里都设计到规则引擎的使用,里面的规则需要有动态下发的能力,所以需要有一个在线规则配置平台能实时对规则进行增删改查,这是一个工程问题,需要灵活设计。

定时任务

定时任务模块用于在设定的时间点出发某些动作的执行,比如定期提醒用户上课,定期问候用户等,该模块可以借助消息队列(MQ)实现。

总结

以上就是一个对话系统的核心实现,这个系统可以进行扩展,比如加入分单系统,评价系统等,这些根据需要扩展即可。

推荐阅读更多精彩内容