本文主要是DST在贝壳咨询助手的探索，主要介绍了业务背景、咨询助手架构图、DST服务架构、以及我们对DST的一些探索，包括DST的迭代路径、模型选择、模型优化。

1.业务介绍

咨询助手是通过分析亿级经纪人与客户的沟通记录，挖掘客户的常见问题与优秀经纪人的沟通技巧，整合用户画像、楼盘字典、房产知识图谱、NLP（自然语言处理）、个性化推荐等能力，在IM场景中加入的经纪人侧的智能助手。旨在帮助经纪人在会话前快速建立对客户的了解；会话中更好解答客户问题，并主动发掘、匹配客户需求；会话后保持有效的商机维护。为经纪人沟通赋能提效，提升商机转化。

咨询助手整体对经纪人的渗透，以及对经纪人提供的帮助，通过以下指标衡量。

1. 周渗透率 : 衡量联网经纪人群体中有多少使用了小贝助手推送的任务和建议；

2. 采纳率 : 衡量我们推送的任务和建议有多少给经纪人提供了帮助；

3. 转委托率: 衡量对经纪人商机转委托能力的提升。

2.咨询助手系统

咨询助手通过分析用户和经纪人的聊天消息，给出回答、引导、推荐等相关卡片，在经纪人侧提示，经纪人可以自主选择是否采纳相关卡片。示例如下，我们给出了用户的偏好，帮助经纪人更好的理解用户，以及对用户问题的回复和引导，在需要推荐的时候，会基于知识图谱、搜索、推荐等技术给出合适房源供经纪人参考，同时如果用户的需求不太明确时，我们还会给出相应的询问需求等卡片。

咨询助手的整体架构如下图所示，主要围绕客-房-人展开，顶层是这三者之间的交互方式，咨询助手通过消费端（也叫适配器）的方式接入用户和经纪人的聊天消息。对话中控主要负责状态的存储，比如对话发送的房源、历史消息、执行的动作以及各个子微服务之间的协作等，最后将生成的卡片发送给适配器，适配器再通过大中控回调接口，发送给大中控，大中控最后通过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）提供状态的追踪，提高对用户的理解

一个好的状态追踪对整个咨询助手（其他助手也会使用）的准确率、使用体验都至关重要，帮助经纪人更准的理解用户。

3.与任务型DST的区别

咨询助手的IM场景（人机辅助场景）逻辑复杂，槽位类型、槽位值的类型种类繁多，指代消解情况复杂，涉及多种内容推理、运算等场景，各种背景知识、常识、习惯等因素的设立，而且对话轮数偏长，如果在对话过程中对槽位值的置信分布产生歧义（无法通过澄清解决），会对后面继续追踪状态及其他依赖状态而执行的操作产生很大影响。我总结了以下几个区别，以下的问题在我们这个场景如果不能处理好，都将是致命的打击。

1. 系统识别错误；
2. 无法通过澄清话术；
3. 如果没有识别，如何召回；
4. 如果识别错误，如何修正；
5. 在用户没有明说的情况下，已经表现偏好，如何识别；
6. 槽位之间的关联，有时候一个槽位值就决定了另外一个槽位的取值；
7. 槽位的取值不再是一个，可能是多个，用户可能即喜欢精装修的也喜欢毛坯的；
8. 槽位之间的冲突问题，有时候用户说的槽位可能冲突，对应多种需求；
9. 槽位的取值无限，比如价格、地理位置，该如何处理等；
10. 没有必填槽位。

4.DST服务架构

我们整体服务架构如下，底层的数据源主要来自楼盘字典、DMP用户画像、经纪人的画像、NLU的识别结果（主要是意图和槽位），最后就是保存的历史状态和对话消息。我们的状态并不是按照任务型的对话来的，主要包括两部分，一部分是用户在聊天消息中明确或未明确表达过的，一部分是我们通过推理、外部行为获取的状态。

从会话聊天消息中，主要以NLU的结果作为输入，抽取NLU识别的槽位，然后经过基础的槽位修正、规则过滤、模型过滤后，得出当前的对话状态。通过对会话里面发送的房源和来自DMP的数据，对其预处理和数据对齐之后，我们需要知道这部分数据的准确性，目前是通过先验概率计算的，动态计算目前还不太好控制。先验我们通过标注完整的会话，比较对话的槽位和dmp以及房源差异，最终统计频数当做先验概率。

我们得出了这两部分的状态分布后，需要融合这两部分的状态，当然这里我们会先用房源和来自DMP数据等的分布去验证会话的状态，达到一个纠错的功能。目前我们有两种合并的方式，基于规则和基于模型。规则目前是把top1状态设置阈值，低于阈值不更新到状态里面。模型方面在下面来介绍。最终我们会呈现当前状态分布、合并状态分布、推理状态分布，分这三个主要是由业务决定的。

5.模型部分

这里我们根据实际情况（NLU识别的问题和实际的业务）对槽位进行如下划分。

模型方面，根据上一篇的介绍，根据我们的业务场景选择了SUMBT这个模型的框架，由于BERT的巨大成功（根据我们的尝试，ALBERT部署服务基本上能在23ms内返回，目前对我们来说还可以接受），由于我们的场景标注数据获取困难等原因，模型结构如下，这个只是上面服务中的模型过滤部分。

对上述模型优化如下，当然整个标注数据（训练数据）还是很匮乏的：

上面属于DST的第二次迭代，也没有很好的解决上面提到的我们遇到的DST困难。以下是我针对我们这个场景的特殊性，设计的模型，目前还在探索中，该模型结合了会话状态，dmp&房源&意图等。

结合之前所有的对话历史，通过参数控制不同时刻的重要性，是我们的一个衰减因子，可以表示为：

之后取概率大于0.5的槽值对出来更新当前的状态值，没有的话就依然保留上一时刻的值。

6.总结

本文介绍了DST在咨询助手的应用，主要介绍了业务背景、咨询助手架构图、DST服务架构、以及我们对DST的一些探索，里面还有很多需要细化的工作以及对模型的进一步探索，一个好的DST肯定能为智能助手提供强有力的保障。

作者介绍

王文彬，2018年毕业于中国科学院大学。毕业后加入贝壳找房人工智能中心业务智能部，主要从事NLP、强化学习和搜索推荐相关工作。