江苏大学附属医院 沈安娜

针对互联网医院线上诊疗服务，缓解医疗机构大量人力投入的压力，解决线上诊疗过程中患者服务非标准化的问题。构建医疗领域语料库，采用语义识别、意图识别、问答匹配等技术，并对接业务数据库，利用大数据相关技术，搭建智能语音交互系统，实现对患者基本问题的答复，扩充线上诊疗的应用场景。针对患者，在线上就诊时可减少排队时间，获得标准化的实时反馈；针对医护，在线上接诊前减少无效对话，精准获得更多患者信息。面向互联网医院的智能语音交互系统的应用，可有效提高医护患协同程度，提升医院智慧服务水平。

1 面向互联网医院的智能语音交互系统的可行性

近年来，人工智能技术已在各行各业被广泛应用，其中智能语音技术作为人工智能应用最成熟的技术之一，在家居、车载、可穿戴设备等领域有了迅猛的发展。反观医疗行业，智能语音技术的应用起步较晚，还没有具备医疗领域知识基础和开发技术的智能语音产品。

根据国家卫健委发布的《公立医院高质量发展促进行动（2021-2025年）》，要建设电子病历、智慧服务、智慧管理“三位一体”的智慧医院信息系统，要提高医疗服务的智慧化、个性化水平。目前大部分三甲医院已经建设了互联网医院，打通覆盖了诊前、诊中、诊后的线上线下一体化医疗服务全流程，成为线下医疗的有效补充。在疫情防控期间，慢病复诊、在线续方、药师咨询、护理咨询等线上诊疗新功能的用户使用量日趋增加，医疗机构随之投入的人力也成倍增加。而智能语音交互系统的应用，能在线上就诊全流程有效缓解人力投入，同时解决线上诊疗中患者服务非标准化的问题。

通过构建面向互联网医院的医疗领域语料库，利用语义识别、意图识别、问答匹配等技术，智能语音交互系统能够快速学习相关内容，并在短时间内具备一线分诊人员的业务素养，实现对患者基本问题的答复。不仅如此，通过结合数据库对接、查询语句解析等技术和开源构架，系统能够扩充线上就诊的应用场景，提升整体医护患协同水平，提高患者在互联网医院的就诊满意度。

2 面向互联网医院的智能语音交互系统的总体设计

2.1 系统技术架构

面向互联网医院的智能语音交互系统对多数据源进行数据处理和数据存储，通过构建医疗领域的对话规则和知识体系，将人机语音交互应用于语音咨询、语音分诊、语音导医等互联网医院线上诊疗场景，其技术架构如图1所示。

图1 系统技术架构图Fig.1 System technical architecture

（1）数据源对接实时对话、HIS数据库、LIS数据库、EMR数据库等独立数据库，支持实时数据、边缘数据、设备数据、业务数据的独立运行，并通过标准API开发兼容多种数据库数据的交互与存储。

（2）数据层首先将问答库与语料库分类，确保单句、节点、属性、关系等资源的分布式存储，在语料处理分析阶段进行分词、分类、词性标注、词法分析工作，同时经过语料库的不断建立，提升数据的清洗能力，增强语音识别错误的检查能力；数据处理时会通资源调度实现计算资源的统筹，并对语义识别及模糊匹配提供运算支持，保障并发量。

（3）技术层主要包含了规则体系、知识推理、知识体系、答案合成四大引擎。规则体系实现对患者数据访问的隔离以及规则的分发服务，并对现有规则进行逻辑校验和学习补全；知识推理负责对患者提问的实体识别以及意图识别；知识体系涵盖了语料库、规则库、知识库等多样化知识数据，通过每天的训练发现现有系统的不足，并通过人工审核后完成发布；答案合成负责大量数据的处理以及答案的语音合成，支持医护与患者交互的最后一个环节。

（4）应用层为患者提供包括语音咨询、语音分诊、语音导医在内的多类标准操作页面、标准API接口及SDK，满足患者对互联网医院线上诊疗的多样化需求。

2.2 系统应答逻辑

患者在互联网医院发起应答需求后，系统需要经过终端身份、语音处理、自然语言处理、对话管理、答案生成等5级计算引擎的循环才可完成应答，如图2所示。

图2 系统应答逻辑图Fig.2 System response logic diagram

其中终端身份模块用以进行安全控制，语音处理模块负责语音的分解与合成，自然语言处理模块完成实体识别和意图识别，对话管理模块通过规则设置支持单轮/多轮两类对话模式的切换，答案生成模块集成大数据组件分析功能，并最大化优化用户使用性能，缩短应答等待时间。

（1）权限安全校验：识别患者身份，进行权限分配，指定连接数据库对象、离线数据加载包、本地计算规则库等。

（2）语音识别ASR：收集语音信息，完成分词、向量转化。

（3）语言理解NLU：完成实体和意图识别，向量匹配。

（4）状态跟踪DST：在对话的每一轮次对患者的目标进行预估，管理每个回合的输入和对话历史，输出当前对话状态。

（5）分布式计算：对离线数据和离线规则的组合直接反馈；支持少量存储资源占用的问答本地化，降低对传输、云计算的占用；对大数据分析组件进行调用，支持弹性存储和计算。

（6）对话规则Policy：针对每一轮的场景以及综合对话状态设置不同的对话策略，从而提高系统的问答效果。

（7）语言生成NLG：将结构化数据转化为自然语言。

（8）语音合成TTS：将文本信息合成为可播放的语音内容。

（9）分发确认处理：将语音内容发送给对应的患者，并等待患者下一次提问。

3 系统主要业务流程

面向互联网医院的智能语音交互系统在实现语音咨询、语音分诊、语音导医等线上诊疗功能时，每一次人机对话都需经过身份识别、语义理解、对话管理、答案生成、答案分发等五大主要业务流程。

3.1 身份识别

通过对患者的登录名以及密码进行初步校验，向患者授权唯一Token值，确定患者所在的服务器集群，并依据账户类型分配不同类型的数据库节点，将实时数据库与离线数据库剥离，增强对数据的利用能力。通过离线日志分析手段，依据患者历史提问习惯，对每个患者形成一份知识库，记录患者常问问题以及使用习惯，从而为每个患者载入部分重要历史数据，减少应答过程中产生的延迟以及计算损耗。身份识别流程如图3所示。

图3 身份识别流程Fig.3 Identification process

3.2 语义理解

通过对系统常用语料库及医疗语料库的深度学习，实现启发式规则算法的优化以及用于快速检索的字典树搭建，将实体与规则及字典树进行相关性检验并将初步检验结果作为模型匹配的输入值，与现有模板进行比对从而判定本轮对话患者的真实意图。当某种词向量频繁出现且无法匹配到规则/字典树时，系统的机器学习函数会被激活，收集过去一段时间的词向量与规则匹配的情况，并适当扩充当前规则及字典树包含的模型库，从而提升规则及字典树的匹配能力。语义理解流程如图4所示。

图4 语义理解流程Fig.4 Semantic comprehension process

3.3 对话管理

通过系统的对话管理机制，帮助患者完善需求内容，澄清/确认需求中不明确的内容，实现对患者对话全生命周期的管理。当患者首次问题的实体识别、意图识别结果能够较好的匹配当前的答案库模型，则标记当前对话状态为结束，同时返回答案内容。如果首轮提问无法匹配到合适的结果，则记录当前对话状态为进行中，结合当前场景与患者意图自动生成引导性结果进入下一轮对话，直到系统发现答案结束当前会话。由于多轮对话可能存在某一轮患者口误、表述有误等导致的异常情况。为了保证系统不会直接结束对话过程，系统拥有自检机制，对出现缺失等异常的对话进行场景恢复和患者意图复盘，充分保证对话的有序流畅。对话管理流程如图5所示。

图5 对话管理流程Fig.5 Dialogue management process

3.4 答案生成

上级结果作为本级输入，系统会对输入进行分词处理和意图识别，通过知识库转化生成对应查询表达式并从本地数据优先遴选资源，依据数据和表达式的相关性来决定是否调用大数据组件进行服务器端的计算。对计算结果进行有效性检验，无效答案则寻求临近匹配问题，直至符合有效性目标，返回最优解。答案生成流程如图6所示。

图6 答案生成流程Fig.6 Answer generating process

3.5 答案分发

为保证并发情况下的系统效能，患者提问得到的结果会通过分发器分发到用户终端，如果分发失败则间隔一段时间进行轮询并检测患者当前状态，若患者存在设备/账户/网络等各种异常情况，则将问题以及结果数据缓存至本地或云端，当患者下一次登录时恢复，避免了异常情况导致的数据丢失。若任意一轮询检测患者状态恢复正常，则开始断点续传，保证结果的送达率。答案分发流程如图7所示。

图7 答案分发流程Fig.7 Answer distribution process

4 系统关键技术

4.1 有医疗特征的语料库学习模型

传统语料库具有无特定语料收集规则、原生语料资源多等特征，单个语料库的大小均在1GB以上，包含上百万中文字符和数十万种语句，能够充分发挥机器学习、深度学习模型的可扩展能力，大规模训练结果可靠性更高。

相比于传统语料库，面向互联网医院的语料库具有明显的医疗特征，且缺乏开源、广泛的资源基础，无法实现海量数据训练的算法要求，需要找到一种适合小型语料库的预处理学习模型。医疗语料库的学习模型集成了语音识别和学习领域现有的处理框架和模型，从意图识别和知识理解两个角度出发，完成了对NLP领域Word2vec/GloVe/ELMo/BERT等工具技术的集成应用。建立对话样本集，并在样本集中通过新建、标注、导入等操作来完成对话样本的管理。

4.2 大数据分析模型的嵌入技术

为了提高互联网医院患者端的交互体验，智能语音交互系统将“反应速度”作为最核心的指标之一，由底层大数据处理能力支撑，通过服务分段，从读取、计算、转换、渠道、环境等角度提高综合效能。

（1）在读取层，使用行业领先的语音转化和分词技术，达到5字每秒的语音转化速度和50ms每次的分词效能。

（2）在计算层，除了应用Hadoop中MapReduce模型提高计算性能等大数据领域措施外，系统还对常见计算的处理结果做本地化，达到500MB的离线模型、数据、计算结果缓存。

（3）在转换层，对常用语料库进行本地化，在互联网医院的不同患者端，通过不同节点对常用语料的节点分布式存储，提高答案的组合效率。

（4）在渠道层，侧重在微信开发平台上搭载后的性能优化和App端的优化。互联网医院小程序端部分功能采用组件化的开发方式，通过对常规功能的组件化开发，优化小程序的响应参数；H5页面的加载速度是影响整体响应速度的关键因素，该系统利用预加载的技术，在用户点击进入页面前提前加载下一个页面的内容，减少页面响应时间。互联网医院App端采用数据包压缩技术，减少与服务器通信所占用的带宽，提高App性能。

（5）在环境层，系统可以自动监测当前用户的网络状况，对输出数据采用不同的压缩选项和格式，当用户所处网络信号较弱时，系统支持2种以上的缓存方式，在网络恢复时完成断点续传。

4.3 服务的组件化开发技术

为进一步提升本系统的迁移能力，拓展智能语音交互系统在医疗行业的更多应用场景。系统可兼容多种数据来源，如不同数据库类型、不同结构数据等，同时对不同用户终端进行适配测试，保证对市面上80%的设备兼容。

系统将开源公有语料库作为主库，各独立语料库如医疗语料库的临时性内容扩充并不会直接影响到主库，而是采用系统自动化检验显著性的方式，对各独立语料库中的新增语料进行显著性校验，只有具备明显普适性特征的语料才会更新并同步到主库，采用自动审核、定时发布的形式对外提供公有语料库最新内容。

为保证各服务组件的稳定性，系统将搭载安全态势感知平台，对高频次、非常规IP地址的请求进行隔离，并触发报警机制，防止异常请求对系统稳定性的影响。

4.4 分布式存储提升应用效能方面

通过对不同问题的类型进行分类，将无需调用数据库并经过大数据计算的常规问答类资源存储到离线数据库中，将需要调用数据库经过计算并给出答案的数据问答类资源存储到实时计算资源库中。通过对数据问答类资源的实时计算与维护，降低患者提出数据类问题的响应时间，保证并发时的用户体验以及整个系统的计算能力不受到严重影响。

5 系统推广及应用

5.1 打造医护患协同的语音交互入口级产品

互联网医院现存的人工分诊模式存在患者服务水平参差不齐、单人培养成本高、处理效率低等固有缺陷。以一次存在纠纷的患者投诉为例，传统患者投诉服务流程需要经过患者电话投诉→患者识别→查找患者就诊记录/来院监控→查找接诊医护记录→识别患者意图→寻找解决方案等多个环节，其中患者识别、就诊记录定位以及患者意图识别会耗费投诉处理人员大量的时间，一方面由于手机号码和固定号码的可变性，导致识别患者身份的准确率很低；另一方面，对于一个成熟的公立医疗机构，面向患者的投诉解决方案可能存在成百上千种，投诉处理人员在识别患者身份、患者意图的同时还需要找到最佳的解决方案，存在较大难度。

通过搭建面向互联网医院的智能语音交互系统，不仅降低了医疗机构人工客服在识别用户身份、意图以及找寻解决方案的难度，还可以通过标准的QA库提升患者服务水平。借助于大数据技术以及机器学习算法，让智能语音交互系统拥有一线人工客服的业务素养的同时，还可以不断学习，并且具备数据分析与计算的能力。

5.2 通过服务封装提高语音交互系统的可复用能力

经过系统的不断学习和语料库的扩充，将不同类别的问题进行归类总结，利用统一的封装技术与标准，编写成为各自独立的语料库，并提供标准的API接口对外开放，让该系统的能力不仅适用于医疗机构内部，还能够辐射到医联体内的更多成员，借助大用户量的使用，系统可供分析的问题也会变得越来越多，从而达到对接-收集-反馈的开源生态系统，为患者提供更多的服务场景。以患者咨询问诊为例，在患者向语音系统提问的过程中，可以让系统捕捉到患者意图，并适当的做指引操作，如线上预约、挂号、缴费、送药到家、用药指导等均可在语音交互中完成，提升患者问题的解决效率，从而提高患者就诊满意度。