作者简介

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

一、引文

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

在数据积累、算法、算力都取得巨大进步的前提下，人工智能爆发；伴随着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

【推荐阅读】

HyperLedger Fabric在携程区块链服务平台的应用实战

配置中心，让微服务『智能』

React模块懒加载初探

携程用户中心接口自动化实践

携程Redis海外机房数据同步实践