本文主要是DST在贝壳咨询助手的探索,主要介绍了业务背景、咨询助手架构图、DST服务架构、以及我们对DST的一些探索,包括DST的迭代路径、模型选择、模型优化。
咨询助手是通过分析亿级经纪人与客户的沟通记录,挖掘客户的常见问题与优秀经纪人的沟通技巧,整合用户画像、楼盘字典、房产知识图谱、NLP(自然语言处理)、个性化推荐等能力,在IM场景中加入的经纪人侧的智能助手。旨在帮助经纪人在会话前快速建立对客户的了解;会话中更好解答客户问题,并主动发掘、匹配客户需求;会话后保持有效的商机维护。为经纪人沟通赋能提效,提升商机转化。
咨询助手整体对经纪人的渗透,以及对经纪人提供的帮助,通过以下指标衡量。
周渗透率 : 衡量联网经纪人群体中有多少使用了小贝助手推送的任务和建议;
采纳率 : 衡量我们推送的任务和建议有多少给经纪人提供了帮助;
转委托率: 衡量对经纪人商机转委托能力的提升。
咨询助手通过分析用户和经纪人的聊天消息,给出回答、引导、推荐等相关卡片,在经纪人侧提示,经纪人可以自主选择是否采纳相关卡片。示例如下,我们给出了用户的偏好,帮助经纪人更好的理解用户,以及对用户问题的回复和引导,在需要推荐的时候,会基于知识图谱、搜索、推荐等技术给出合适房源供经纪人参考,同时如果用户的需求不太明确时,我们还会给出相应的询问需求等卡片。
咨询助手的整体架构如下图所示,主要围绕客-房-人展开,顶层是这三者之间的交互方式,咨询助手通过消费端(也叫适配器)的方式接入用户和经纪人的聊天消息。对话中控主要负责状态的存储,比如对话发送的房源、历史消息、执行的动作以及各个子微服务之间的协作等,最后将生成的卡片发送给适配器,适配器再通过大中控回调接口,发送给大中控,大中控最后通过IM提供的回调接口发送的经纪人侧展示。咨询助手主要包括NLU(Natural Language Understanding)、DM(Dialog Management)、QBot(房源详情问答机器人)、SBot(交互式搜索机器人)等子微服务,首先对一条消息通过简单的过滤(不是所有的消息都要处理),然后调用NLU,主要负责对消息的理解,包括句法分析+情感/句式识别+意图识别+槽位识别,最重要的就是意图识别和槽位抽取,然后将识别的结果给到下游的服务,下游服务基于此再进一步分析。DST会根据NLU的结果进一步的追踪状态,进行判断和历史状态的合并。然后DM使用NLU和DST的结果做为输入,基于对话策略决策出相应的动作,然后选择相应的动作集合返回给对话中控。现在目前主要的两个比较大的动作就是QBOT和SBOT,QBOT主要服务对用户的问题给出相关的解答供经纪人参考,这里不但要提供回答,还需要考虑到回答的质量以及经纪人回答的习惯。Qbot会基于句式和槽位信息,判断问题类型,查询知识图谱、获取意图对应的回答模板信息,然后基于查询到的三元组和模板拼接生成回答返回给经纪人,然后由经纪人点击选择发送用户。SBOT主要提供交互式搜索的功能,当用户想要推荐房源,该模块会根据用户偏好、经纪人的偏好、房源等情况判断是否满足推荐房源的条件,如果不满足会去询问用户更具体的需求。
总结下我们这款经纪人咨询助手特点,有如下四个方面:
1)全方位理解用户意图
基于NLU,建立起对用户消息的全面抽取理解,为下一步精准分析决策提供坚实基础;
2)打平经纪人服务方差
学习优秀经纪人的回答话术来生成回答,能帮助水平中等偏下的经纪人提升服务水平,减小经纪人服务方差;
3)提升经纪人作业效率
基于机器的辅助回答,经纪人可以快速地回复用户消息,提升自身工作效率同时,也提升用户体验;
4)提供状态的追踪,提高对用户的理解
一个好的状态追踪对整个咨询助手(其他助手也会使用)的准确率、使用体验都至关重要,帮助经纪人更准的理解用户。
咨询助手的IM场景(人机辅助场景)逻辑复杂,槽位类型、槽位值的类型种类繁多,指代消解情况复杂,涉及多种内容推理、运算等场景,各种背景知识、常识、习惯等因素的设立,而且对话轮数偏长,如果在对话过程中对槽位值的置信分布产生歧义(无法通过澄清解决),会对后面继续追踪状态及其他依赖状态而执行的操作产生很大影响。我总结了以下几个区别,以下的问题在我们这个场景如果不能处理好,都将是致命的打击。
我们整体服务架构如下,底层的数据源主要来自楼盘字典、DMP用户画像、经纪人的画像、NLU的识别结果(主要是意图和槽位),最后就是保存的历史状态和对话消息。我们的状态并不是按照任务型的对话来的,主要包括两部分,一部分是用户在聊天消息中明确或未明确表达过的,一部分是我们通过推理、外部行为获取的状态。
从会话聊天消息中,主要以NLU的结果作为输入,抽取NLU识别的槽位,然后经过基础的槽位修正、规则过滤、模型过滤后,得出当前的对话状态。通过对会话里面发送的房源和来自DMP的数据,对其预处理和数据对齐之后,我们需要知道这部分数据的准确性,目前是通过先验概率计算的,动态计算目前还不太好控制。先验我们通过标注完整的会话,比较对话的槽位和dmp以及房源差异,最终统计频数当做先验概率。
我们得出了这两部分的状态分布后,需要融合这两部分的状态,当然这里我们会先用房源和来自DMP数据等的分布去验证会话的状态,达到一个纠错的功能。目前我们有两种合并的方式,基于规则和基于模型。规则目前是把top1状态设置阈值,低于阈值不更新到状态里面。模型方面在下面来介绍。最终我们会呈现当前状态分布、合并状态分布、推理状态分布,分这三个主要是由业务决定的。
这里我们根据实际情况(NLU识别的问题和实际的业务)对槽位进行如下划分。
分类 | 说明 | 实例 | 说明 | 英文名 |
---|---|---|---|---|
表达槽位 | 用户表达的自己的需求,或陈述自己的状态,比如老人、结婚、小孩等 | 我想要五百万的房子 | 如果根据上下文看不出类别,都默认是表达槽位例如:五百万 | express_slot |
询问槽位 | 用户询问房源或者其他的的信息 | 这个房子是五百万吗?请问龙泉景苑对应的学区是哪? | ask_slot | |
指代槽位 | 用户说具体房源或者其他的信息 | 五百万的那套是精装修吗?请问龙泉景苑对应的学校是哪? | refer_slot | |
相关槽位 | 有槽位信息,但是只是陈述一个事实 | 二楼的,自己装修的,算下来不值啊 | 这里的装修这是既不是表达询问指代,只是用户的陈述 | relate_slot |
非槽位 | 不是槽位信息,与房源用户状态等无关的 | 我在科园路那边 | not_slot | |
其他 | 不属于上述几类的都归为这类 | 10月份 | other |
模型方面,根据上一篇的介绍,根据我们的业务场景选择了SUMBT这个模型的框架,由于BERT的巨大成功(根据我们的尝试,ALBERT部署服务基本上能在23ms内返回,目前对我们来说还可以接受),由于我们的场景标注数据获取困难等原因,模型结构如下,这个只是上面服务中的模型过滤部分。
对上述模型优化如下,当然整个标注数据(训练数据)还是很匮乏的:
优化 | 说明 | 效果 |
---|---|---|
数据分析-地理位置识别问题大 | 模型添加槽位的类别信息 | 暂无 |
长度限制 | 目前只是增加了一条上文,综合考虑性能和效果增加上下文信息 | 暂无 |
区分不同消息 | 根据发送方的不同区分消息,如果发送方是相同的,设置相同的来源 | 0.742->0.779 |
修改模型超过长度删除字符的方式 | 当前方式,都是删除两句话,修改后,优先删除上一句话 | 0.742->0.767 |
修改模型结构 | 去掉最后归一化层 | 0.742->0.756 |
数据整理 | 对标注数据过滤一遍 | 0.742->0.813 |
数据增强 | 通过写模板的方式,填充房源数据 | 0.742->0.762 |
上面属于DST的第二次迭代,也没有很好的解决上面提到的我们遇到的DST困难。以下是我针对我们这个场景的特殊性,设计的模型,目前还在探索中,该模型结合了会话状态,dmp&房源&意图等。
结合之前所有的对话历史,通过参数控制不同时刻的重要性,是我们的一个衰减因子,可以表示为:
之后取概率大于0.5的槽值对出来更新当前的状态值,没有的话就依然保留上一时刻的值。
本文介绍了DST在咨询助手的应用,主要介绍了业务背景、咨询助手架构图、DST服务架构、以及我们对DST的一些探索,里面还有很多需要细化的工作以及对模型的进一步探索,一个好的DST肯定能为智能助手提供强有力的保障。
王文彬,2018年毕业于中国科学院大学。毕业后加入贝壳找房人工智能中心业务智能部,主要从事NLP、强化学习和搜索推荐相关工作。