写点什么

行业智能客服构建探索

  • 2020-02-19
  • 本文字数:4129 字

    阅读完需:约 14 分钟

行业智能客服构建探索

一、引文

近年来科技产业蓬勃发展。一方面,随着互联网的普及和发展,用户在使用互联网产品过程中产生了海量的数据;另一方面,硬件设备和算法也取得重大突破。


在数据积累、算法、算力都取得巨大进步的前提下,人工智能爆发;伴随着 AlphaGo 战胜人类冠军,这个概念也开始进入了普罗大众的视野。


谈到人工智能,我们首先要了解一个重要概念:图灵测试


下面引用其在百度百科中的解释:图灵测试是指测试者与被测试者(一个人和一台机器)隔开的情况下,通过一些装置(如键盘)向被测试者随意提问。进行多次测试后,如果有超过 30%的测试者不能确定出被测试者是人还是机器,那么这台机器就通过了测试,并被认为具有人类智能。


图灵测试在上世纪 50 年代提出,从图灵测试的解释中可以看到,人机对话系统是衡量人工智能的重要场景,也是随后人工智能研究的重点方向。


在本轮的人工智能热潮中,人机对话系统依然是重点方向之一,并且以智能客服或智能助手的方式落地,多数用以解决企业在线服务中人工服务成本高,响应速度受限和服务时间受限等业务问题。


本文重点聊一聊在医疗行业智能助手探索中遇到的问题,以及为此尝试的方法。把 客服类项目中需要的对数据构建、用户问题分析及理解的思考过程 分享给各位读者,希望对同类项目的思考有所帮助。

二、问题背景

我们面对的是一个在线医疗服务场景:患者在线上通过网站或者 app 提出问题,医生在线做出回答,服务的过程会产生多轮的问答交互。


在这个场景中,业务上有两个突出的问题;第一,在线医生资源不足;第二,医生响应回复不及时。这两个问题影响用户的产品体验,平台信任度,进而影响用户留存,用户转化等业务指标。


在这个背景下,我们提出利用 AI 技术,构建一个可对话的医疗智能助手,用来缓解以上业务问题。


最终,我们花费四个月的时间开发和迭代了一个智能助手,它可以在医生没有响应时给予用户及时的反馈,并通过与用户对话来收集用户的信息,还会自动计算用户的高概率疾病,用于医生参考。(注:系统是由具有医学背景的客服人员使用,不会出现机器人直接回答用户问题的情况)


由于行业的特殊性,系统对技术指标的要求是非常严格的,即,在高精确度的前提下,尽最大可能提升召回率。


下面我们就来看看智能助手的整体思路。

三、解决思路

整体方案分为两部分:


1)行业物料构建;


2)智能助手搭建;

3.1、行业物料构建

3.1.1 数据获取

理想的情况是拿到标准的电子病历;一方面,从<用户提问,确诊疾病>数据对中学习疾病分类和预测模型,用于对用户的病情自述做科室和疾病预测;另一方面,从问诊记录中统计疾病与症状(含体征)的关联关系,并计算转移概率,从而可以在问诊过程中动态计算下一步需要问询的状态。


实际情况是,电子病历是医院、医疗机构的机密数据,我们无从获取,因此需要寻找此类数据的替代品。


从目标需求出发,我们最终锁定了两类公开的替代数据源。一类是在线医疗网站上的多轮问答数据,从这些数据中可以标注出问题与最终疾病的 pair 对。另一类是医学书籍,从中我们可以抽取整理出疾病-症状的关联关系。



互联网上的医疗对话数据示例

3.1.2 数据处理

3.1.2.1 数据结构化

无论是对话数据还是书籍数据,都有多个来源和版本。我们首先将其转换为统一的数据格式,再从中抽取出关键字段信息,最后辅助专家标注审核,给数据附上标签信息。例如,对话数据中关于结论疾病的部分,需要医学专家审核确认,缺少的给予补充。

3.1.2.2 数据归一化

数据归一化重点针对核心医学概念,疾病及症状。由于语言描述的丰富性,一个概念通常会有多种表达方式,例如:一个疾病叫小儿腹泻病,又叫婴儿腹泻病,小儿消化功能紊乱等。我们参考医学系统命名法 SNOMED CT[1],将其中一个选为标准名,其它作为别名,并建立映射关系。

3.2、智能助手搭建

3.2.1 整体框架


智能助手相关的服务逻辑如上,出于业务敏感性考虑,隐去了部分模块和细节,整体流程简要概述如下。


在经过科室判断和用户意图识别后,被甄别为真正有多轮问诊诉求的用户被引至问诊服务,知识满足类需求由自动问答服务来满足,而精神/感情咨询类直接由人工服务。


问诊服务核心的功能是:通过与用户进行多轮问答,询问和收集用户的信息,并预测用户最可能的疾病范围。在与用户对话过程中,问诊助手提出的问题要符合一定的条件:1) 符合客观逻辑,如:不应该向男性患者询问妇科问题,不应该把仅适合儿童的问题提给成年人。2)使得对话过程尽快收敛,即每轮的提问应该在当前状态下最有利于疾病范围确定;或者最有利于确定 bot 无法满足。


下面,我们就问诊模块中几个关键任务点展开,阐述面对的问题和技术方案。

3.2.2 关键任务

本节介绍框架下的几个关键任务。

3.2.2.1 疾病范围预测

疾病有几万个之多,如果让问诊模块直接判断所有的用户问题,每次对话的搜索空间太大,而对话轮次必然是有限的,现实中 Bot 不可能跟用户询问太多轮次;因此,必须减小会话过程的搜索空间。


我们采用逐层分解的办法;第一层;科室划分;第二层,需求意图判断;第三层,静态疾病范围预测(发生在用户提问的第一轮);第四层,动态疾病范围预测(发生在除第一轮后的每一轮回话中);通过逐层划分,保证问诊模块每次会话时的搜索空间是可控的。第三层和第四层区别在于处理的输入特征不同,采用的模型是一致的。


下面就介绍用于疾病范围预测的模型,我们将其定义为一个多分类问题,采用 Dynamic Convolutional Neural Network(DCNN)[2]模型来实现。



上图描述了 DCNN 算法的运行过程;其中,以长度为 7 的句子为例,embedding size 为 4;网络有 2 层卷积,卷积宽度分别为 3 和 2;卷积后的 k-max pooling 中 k 的取值分别为 5 和 3。


DCNN 与一般 CNN 的区别在于,max-pooling 的维度取值是动态计算的,有利于特征提取;另一个区别是多了一个 feature folding 层,用于特征叠加。正因为该模型的特点决定了其可以更好地提取特征,符合业务场景中存在多个特征片段的特点,我们才选取其作为预测模型;从项目效果表现上看,DCCN 也超出了同层数 CNN 模型、及 FastText 模型的表现。


利用 DCNN 计算用户输入在科室下目标疾病范围上的概率分布,可以容易的得到 Top-k 个目标疾病,并通过医疗 Knowledge Graph 中症状-疾病间的关联关系排除部分非目标疾病,进一步缩小搜索范围。

3.2.2.2 对话过程中的信息抽取

对话过程中,智能助手需要不停的从用户的反馈中获取关键信息,例如:患者性别,患者年龄,过往病史等基本信息,以及最重要的症状表现;表现包括出现和未出现,在症状上来说就是有出现该症状或者没有出现该症状。


逐步积累的用户信息用于决策后续的搜索空间,因此,对话过程中的信息抽取成为另一个关键任务。信息抽取是一个非常有挑战的任务,鉴于业务对抽取结果的高要求,我们采取了 2 种方法组合的形式来解决片段抽取问题,采用分类模型来解决正负语义判定问题。


下面就介绍解决信息抽取的主要方法。


1)语义解析


通过对数据的分析我们发现,部分症状描述是由一定规律的,例如符合动宾关系,例如发烧,打喷嚏,拉肚子等。因此,我们通过句法分析获得句子结构,通过定义句法模板提取后续片段。


例如,对于用户的问题:“宝宝拉绿色的便便,还有泡泡。”,句法结构如下:



通过获取句法结构,可以抽取候选症状;例如,我们提取以 VOB 为核心的内容块,可以得到:拉绿色的便便、便便还有泡泡这样的症状描述;然后再对症状片段进行语义归一。


2)Bi-lstm+CRF


句法解析能解决一部分抽取问题,但会话中普遍存在口语化表达,导致基于句法解析的方式召回不全,因此我们必须寻找新的办法。


我们将症状抽取定义为一个标注任务,即从句子中识别什么位置是一个症状的开始,什么位置是症状的结束。下面是一个句子的标记,O 代表其他,B 代表症状开始,I 代表症状内部。


宝宝嗓子有痰,腹泻并伴有拉水的症状。……

O O B I I I O B I O O O B I O O OO ……


在这个任务中,我们引入了 Bi-lstm+CRF 来解决序列标注任务,该模型将考虑双向的信息作为输入,使用 LSTM 提取序列特征,而 CRF 有效利用句子层面的标记信息;可以获取整体更好的标签序列。


下图是模型的示意图,引用于模型的经典论文[3]。


3.2.2.3 问题生成

问题生成指,在对话系统经过计算确定下一个要提问的问题点后,系统生成自然语言问题,用于向用户提问。问题生成涉及两个点,一个是选择问题生成点(这也是对话管理的一部分),另一个问题是话术构建及拼接。下面简单介绍一下提问点计算和模板选择时的一些考量。


1)提问点计算


a、深度:症状-> 症状子属性


b、广度:该疾病下并列的其它症状


因为部分症状存在子属性,例如症状的轻重缓急,症状的持续时间等维度。某一症状被选取为下一个提问点时,需要考虑两个维度上的选择,选择的依据是根据历史数据计算那个维度更利于对话收敛。


例如,疾病“咳嗽变异性哮喘”的主要症状包含咳嗽,而且是夜间或凌晨咳嗽特别厉害,其它时间几乎没有咳嗽发生,那么当会话获取到该疾病的几个关键症状且包含咳嗽时,只有往前判断一步判断咳嗽发生时间,即可以大概率判断用户是否感染该疾病。


2)生成内容


从对话数据中总结话术模板,基于模板生成问题。在模板选择时,同类问题尽量随机选择候选模板,避免用户认为是跟机器人在交互。

四、技术延伸

在该技术系统实现的基础上,以医学对话系统构建为目标,在基础系统上引入强化学习技术,并在第三方标注的独立数据集上进行了实验和验证,效果与传统的方法相比获得明显提升,我们的成果在自然语言处理会议 ACL 2018 上发表,具体参见相关的论文[4]。


引用


[1] https://www.nlm.nih.gov/healthit/snomedct/


[2] A Convolutional Neural Network for ModellingSentences


http://www.aclweb.org/anthology/P14-1062


[3] Neural Architectures for Named EntityRecognition;


https://www.aclweb.org/anthology/N16-1030


[4] Task-oriented Dialogue System forAutomatic Diagnosis


http://www.aclweb.org/anthology/P18-2033


作者介绍


戴祥鹰,就职于携程数据智能部。此前先后供职于腾讯、百度,主要从事搜索、推荐、知识图谱、自动问答等相关工作。硕士毕业于哈尔滨工业大学。本文为作者加入携程前所做项目工作的经验总结。


本文转载自公众号携程技术(ID:ctriptech)。


原文链接


https://mp.weixin.qq.com/s/LFmZMcunhJ-9ey9_igrTZA


2020-02-19 20:311278

评论

发布
暂无评论
发现更多内容

彻底搞懂React-hook链表构建原理

夏天的味道123

React

没想到!我在简历上写了“精通MySQL”,阿里面试官跟我死磕后就给我发了高薪offer

程序知音

Java MySQL 数据库 后端技术

CTO技术共享整理出来的十个Python自动化脚本

CTO技术共享

Python 个人成长 10月月更

SAP | 详解abap数据类型

暮春零贰

SAP abap 10月月更

小程序技术可助力智慧医疗企业破茧突围?

Speedoooo

小程序 小程序容器 小程序化

什么是无代码?企业为什么要用无代码进行数字化转型?

优秀

数字化转型 无代码

大数据开发培训怎么选?

小谷哥

CTO技术共享整理九个shell脚本

CTO技术共享

个人成长 DDoS 10月月更

细说React组件性能优化

xiaofeng

React

React组件设计模式-纯组件,函数组件,高阶组件

xiaofeng

React

前端开发的程序员还有前途吗

小谷哥

极客时间运维进阶训练营第一周作业

好吃不贵

一文详解如何用MySQL/Redis/ZooKeeper实现分布式锁

一灯架构

Java 10月月更

react-Suspense工作原理分析

夏天的味道123

React

方舟数据中台,打造企业数据能力组件中心

元年技术洞察

数据中台 低代码 数字化转型 企业自驱力

TCP:当初取代NCP,如今害怕被取代

C++后台开发

后台开发 网络协议 TCP/IP 后端开发 TCP协议

研发分享 | StoneDB 如何给 Tianmu 引擎增加 delete 功能 #1 调研之旅

StoneDB

数据库 HTAP StoneDB 10月月更 企业号十月PK榜

TiKV 源码阅读三部曲(一)重要模块

PingCAP

TiKV 源码解读

PaaS平台应用趋势

元年技术洞察

AI 数据湖 PaaS 容器服务 微服务化

Confidential Containers:云原生机密计算基础设施

OpenAnolis小助手

开源 cncf 龙蜥 机密计算 沙箱

大数据开发培训学习哪家机构好

小谷哥

化解企业云端协同难题,英特尔超能云终端2.0版本为市场注入全新活力

科技之家

CEF | CEF浏览器客户端功能详解

YOLO.

qt 10月月更 C++

大厂被裁,疫情之下,一个offer都没,测试人如何破局?

千锋IT教育

web前端开发课程培训哪家好

小谷哥

升级到React-Router-v6

xiaofeng

React

React组件通信

xiaofeng

React

详解React的Transition工作原理原理

夏天的味道123

React

java开发技术培训费用是多少

小谷哥

技术分享| 消息队列Kafka群集部署

anyRTC开发者

nginx kafka zookeeper 分布式 消息

渲染行业的未来发展趋势

Finovy Cloud

渲染 云渲染 本地渲染

行业智能客服构建探索_文化 & 方法_戴祥鹰_InfoQ精选文章