CN106991284B - 智能育儿知识服务方法及*** - Google Patents

智能育儿知识服务方法及*** Download PDF

Info

Publication number
CN106991284B
CN106991284B CN201710210882.8A CN201710210882A CN106991284B CN 106991284 B CN106991284 B CN 106991284B CN 201710210882 A CN201710210882 A CN 201710210882A CN 106991284 B CN106991284 B CN 106991284B
Authority
CN
China
Prior art keywords
disease
user
symptom
module
knowledge
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710210882.8A
Other languages
English (en)
Other versions
CN106991284A (zh
Inventor
欧阳纯萍
刘永彬
赵龙
颜波
万亚平
刘志明
阳小华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
University of South China
Original Assignee
University of South China
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by University of South China filed Critical University of South China
Priority to CN201710210882.8A priority Critical patent/CN106991284B/zh
Publication of CN106991284A publication Critical patent/CN106991284A/zh
Application granted granted Critical
Publication of CN106991284B publication Critical patent/CN106991284B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2452Query translation
    • G06F16/24522Translation of natural language queries to structured queries
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Public Health (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Artificial Intelligence (AREA)
  • Computational Linguistics (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)

Abstract

本发明公开了一种智能育儿知识服务方法及***,包括信息采集:利用爬虫程序定时下载、解析最新的儿童疾病数据信息,并储存在mysql数据库中;专家机器人知识库构建:包括疾病咨询、疾病预测、医生推荐三个步骤;个人机器人知识库构建:用户不断的向个人机器人输入自己的知识,个人机器人以一个问题对应一个答案的形式存储在mysql数据库中,并以知识社区的形式为不同用户提供过程式的育儿知识服务;***交互实现:通过PC端和移动端实现用户交互。解决了现有育儿知识服务方法不能完整的展现一种儿科疾病从发病到治疗,再到治愈的全过程,缺乏人性化智能的展现方式,展现形式单一的问题。

Description

智能育儿知识服务方法及***
技术领域
本发明属于育儿保健技术领域,涉及一种智能育儿知识服务方法及***。
背景技术
随着互联网的快速发展,计算机技术已经在各行各业方便着人们的生活。在医疗领域也不例外。在网络上潜藏着大量的儿科疾病的专业数据和用户的问诊记录,这些信息对于儿科疾病问题的解决,就像黄金一样零零散散的隐没在沙子里。虽然很有用,但是不够***、不够完整,缺乏灵活智能的组织和人性化的展现方式,最终不能很好的发挥作用。如何开发出一款育儿保健的机器人***,来搜集整理信息,为育儿父母服务,刻不容缓。
经过调查,目前市场上存在着“寻医问药网”,“中国健康网”等一系列医疗网站,还有各大医院的门户网站,他们大都提供儿童疾病查询和在线医生问诊的服务。但是经过使用后发现,他们的疾病查询服务大都局限于疾病信息的检索,并没有对疾病信息进行有效的构建和整理,以形成知识库从而为用户更好地服务。另外他们对于信息的展示形式,大多过于单一,都只是文字的阐述和罗列。当患儿的父母,心急如焚的查找有用信息时,往往会被淹没在浩如烟海的文字里,最终所获甚少。这种忽略用户心理的交互,并不能在关健时刻及时有效的给用户提供服务。其次,他们大而全的疾病检索,当然能够包涵儿科疾病,但是精力的分散注定了其不能专注于儿童疾病。
另外,这些网站所提供的在线医生问诊服务,并不能做到真正的全天24小时在线,有些甚至得提前预约。可是患儿的发病时间是无规律可循的,当夜半三更,孩子发病而医生又恰巧不在时,这些***不但不能为用户服务,有甚者甚至延误了患儿的治疗时机。
其次,这些网站的疾病信息来源于后台专业人士的手动录入,往往有一定的滞后性。当一种儿科流行病迅速爆发时,信息录入滞后的网站,往往并不能及时更新网站信息,这样,用户就不能及时知情,及时预防,防患于未然。
市场上也存在着“育儿网”、“babytree”、“YY”网”等育儿平台,他们更加关注于儿童,因此对于育儿而言也更加专业。但是,他们只是关注于保健以及育儿知识的普及,对于孩子疾病的查询和诊治方面,并不能给出权威的服务。况且,他们所针对的儿童,是大多数儿童的普遍症状,但其实儿童的成长过程是千差万别的,在育儿过程中的经验也是各有千秋的。因此关注每一个孩子的成长,为每一个孩子量身打造一个属于自己知识经验库是十分必要的。这个经验库可以用来分享,但是并不能完全复用。
目前国内外,针对成人疾病问诊及预防的应用软件数量繁多,并且大多数都收到显著的欢迎和成效。但是这类软件应用当中,成人健康咨询综合类居多,单科类疾病问诊领域显著偏少,而趋向于儿科疾病的问诊和咨询更是寥寥无几。例如国内的综合类健康咨询应用软件“春雨医生”、“好大夫”、“青苹果健康”、“掌上医生”等等,虽广受欢迎但却是针对成人综合疾病问诊的;而育儿类软件如“育儿指南”、“育儿问答”、“天天育儿”、“春雨育儿医生”,尽管以问答形式提供了许多育儿经验及在线医生问诊服务,但仍存在以下不足:
(1)上述***疾病查询服务大都局限于疾病信息的检索,并没有对疾病信息进行有效的构建和整理,以知识库的形式呈现给用户,以致于用户还是要从繁杂的网络数据中搜寻、判别有用的信息,无法精确的获取自己想要的育儿知识。另外他们对于信息的展示形式,大多过于单一,都只是文字的阐述和罗列。当患儿的父母,心急如焚的查找有用信息时,往往会被淹没在浩如烟海的文字里,最终所获甚少。这种忽略用户心理的交互,很难在关健时刻及时有效的给用户提供服务。
(2)上述***大部分是基于论坛形式的问答服务,这种论坛形式的问答服务提供的是一种零散式的知识服务,并不能完整的展现一种儿科疾病从发病到治疗,再到治愈的全过程。而且随着孩子年龄的增长,育儿过程中会出现不同问题,每位家长都需要对比问题所发生的前因后果,而不仅仅是通过当前的表征状态来获取结论。不能为家长们提供一种基于过程式的育儿知识服务。
发明内容
本发明所要解决的技术问题,提供一种智能育儿知识服务方法,对疾病信息进行有效的构建和整理,以知识库的形式呈现给用户,解决了现有育儿知识服务方法不能完整的展现一种儿科疾病从发病到治疗,再到治愈的全过程,缺乏人性化智能的展现方式,展现形式单一的问题。
本发明的另一目的是,提供一种智能育儿知识服务***,构建了一个基于过程的儿科知识服务社交***。
本发明所采用的技术方案是,一种智能育儿知识服务方法,具体按照以下步骤进行:
步骤1,信息采集:利用爬虫程序定时下载、解析最新的儿童疾病数据信息,并储存在mysql数据库中;
步骤2,专家机器人知识库构建:包括疾病咨询、疾病预测、医生推荐三个步骤;
所述疾病咨询:将用户提供的疾病名称直接传递至疾病预测模块;或者通过与用户不断的交流获取症状词,采用分词器切分用户输入的口语症状词,利用mysql数据库中的疾病症状词表识别切分后的症状词,获得症状词列表,并传递至疾病预测模块;
所述疾病预测:包括疾病名称预测和症状词列表预测;所述疾病名称预测是根据疾病咨询中获得的疾病名称在mysql数据库中检索,以知识图谱的形式为用户展示疾病预测结果;所述症状词列表预测是将疾病咨询中获得的症状词列表与mysql数据库中每一种疾病的症状进行匹配,根据匹配程度以知识图谱的形式为用户展示疾病预测结果;
所述医生推荐:基于用户先前的疾病咨询记录和疾病预测结果的点击记录,为用户推荐与用户所患疾病相关的医生信息;
步骤3,个人机器人知识库构建:用户不断的向个人机器人输入自己的知识,个人机器人以一个问题对应一个答案的形式存储在mysql数据库中,并以知识社区的形式为不同用户提供过程式的育儿知识服务;
步骤4,***交互实现:通过PC端和移动端实现用户交互。
本发明的特征还在于,进一步的,所述步骤2中根据疾病咨询中获得的疾病名称为用户进行疾病预测的方法是:基于疾病名称的检索,采用开源的全文搜索框架luence,分别对mysql数据库中疾病数据的“名称”、“概述”“详细资料”字段提前建立索引,建立索引时赋予不同的权重,“名称”的权重最大,根据用户提供的疾病名称与mysql数据库中的疾病名称的吻合程度,对每个检索结果进行打分,将得分高的疾病预测结果反馈给用户。
进一步的,所述步骤2中将疾病咨询中获得的症状词列表与mysql数据库中每一种疾病的症状进行匹配,根据匹配程度为用户进行疾病预测的方法是:采用tf-idf的余弦相似度匹配算法,具体按照以下步骤进行:
首先要对mysql数据库中所有的疾病症状排序,而后根据疾病症状的序列,为mysql数据库中每一种疾病构建一条向量P,同时根据疾病咨询中获得的症状词列表构建一条假想疾病向量Pˊ;两条疾病向量构建完成后,计算两条疾病向量的余弦值,计算公式如下:
当每条疾病向量P与假想疾病向量Pˊ的余弦值计算完成后,余弦值按照从大到小排序,选择前十个余弦值对应的疾病信息,将该疾病预测结果反馈给用户。
进一步的,所述构建疾病向量的方法:倘若某疾病相应的位置确实出现某种症状,这个位置的向量因子就是此症状相对于此疾病的tf-idf值,倘若没有出现某种症状,这个位置的向量因子取0值;
tf-idf值的计算方式如下:
tf-idf(wij)=tf(wij)×idf(wi)
tf值,表示一个症状词在当前疾病数据中出现的频率,其计算公式为:
其中,n(wij)表示第i个症状词在第j种疾病数据中出现的次数,D(j)表示第j种疾病数据分词后的总词数;
Idf值,表示一个症状的稀有程度,其计算公式为:
其中,A表示当前的疾病总数,a(wi)表示出现第i个症状词的疾病总数。
进一步的,所述步骤2还包括以下步骤:倘若用户在疾病咨询模块给出的症状词过少,不足以够构建假想疾病向量时,疾病预测方法为:当用户给出一个症状词时,在mysql数据库中查找,遍历每一个疾病的症状列表,假如搜索到某一个疾病的症状列表中包含当前症状词,而当前症状词的tf-idf值与搜索到的疾病症状列表中所有症状词的tf-idf总和结果比率接近于1,然后取出此疾病症状列表中第二大tf-idf值的症状词去询问用户是否满足,倘若满足,则继续询问第三大tf-idf值的症状,依次类推,当已经确定的症状词数与此疾病症状词总数的比例达到65%时,将该疾病预测结果反馈给用户;如果已经确定的症状词数与此疾病症状词总数的比例不足65%时,再按照上述方法依次对其它包含当前症状词的疾病症状列表进行预测。
进一步的,所述步骤2中医生推荐的方法是:使用luence框架为医生的信息建立索引,医生的信息包括姓名、科室、所属医院、简介、主治、擅长、联系方式,不同的信息赋予不同的权重,主治和擅长的权重均大于其他信息,简介的权重次之;选取排名前十的医生推荐给用户;在整个过程结束之后,***还会讯问用户对于本次问诊是否满意,将本次问诊的记录添加到个人机器人模块。
进一步的,所述步骤3中,对用户提问进行答案检索的方法:首先对存储在mysql数据库中的所有问题和答案数据分域建立索引,当用户问题提出时,对用户问题进行分词处理,然后去掉停用词和虚词,以主要实词和用户名建立一个嵌套查询在索引中查找。
本发明所采用的另一技术方案是,一种智能育儿知识服务***,包括信息采集模块、专家机器人模块、个人机器人模块和***交互模块;
所述信息采集模块与mysql数据库连接,用于通过爬虫程序定时获取最新的儿童疾病数据信息;
所述专家机器人模块,用于以知识图谱的形式直观的为用户提供儿科疾病相关的各类知识服务;专家机器人模块包括疾病咨询模块、疾病预测模块、医生推荐模块;
所述疾病咨询模块与疾病预测模块连接,用于获取用户提供的疾病名称或症状词,并将疾病名称、症状词列表传递至疾病预测模块;
所述疾病预测模块,用于将疾病名称在mysql数据库中检索,以知识图谱的形式为用户展示疾病预测结果;以及将症状词列表与mysql数据库中每一种疾病的症状进行匹配,根据匹配程度以知识图谱的形式为用户展示疾病预测结果;
所述医生推荐模块分别与疾病咨询模块、疾病预测模块连接,基于疾病咨询模块的咨询记录和疾病预测结果的点击记录,为用户推荐与用户所患疾病相关的医生;
所述个人机器人模块,用于将用户输入的知识以一个问题对应一个答案的形式存储在mysql数据库中,并以知识社区的形式为不同用户提供过程式的育儿知识服务;
所述***交互模块,包括PC端和移动端。
进一步的,所述疾病咨询模块包括mmseg4J分词器和疾病症状词表,mmseg4J分词器用于切分用户输入的口语症状词;疾病症状词表包括mysql数据库中的疾病症状和临床表现中的词语、及其同义词,疾病症状词表用于识别经过mmseg4J分词器切分的症状词。
进一步的,所述PC端和移动端,采用语音技术让***具有人的声音,采用数据可视化技术使得数据的展示更加形象生动,包括多种说法的提示语。
本发明的有益效果是:本发明构建了一个基于过程的儿科知识服务社交***,能够为用户提供更多育儿过程中的完整记录,帮助用户更全面的分析已有的育儿知识;充分利用自然语言处理和数据相关算法,对获取的最新儿科医疗数据进行分析和建模,分别构建专家机器人模块和个人机器人模块,专家机器人模块以知识图谱的形式更直观的为用户提供儿科疾病相关的各类知识服务;个人机器人模块以知识社区的形式为不同用户提供过程式的育儿知识服务。本发明还具有以下优点:
(1)本发明建立了专门针对儿科疾病相关数据的知识库,以知识图谱的方式展示了疾病名称、疾病症状、治疗方法、儿科医生、就诊途径等信息,以及各信息之间的关联关系。疾病预测模块能够根据用户提供的症状名词,智能分析用户患儿可能属于的疾病类型,并提供相应的护理知识服务,同时提供相应专家及就诊信息。尽管目前有一些类似的育儿论坛和网站,但是并没有对这些论坛和网站的信息进行知识分析,无法为用户提供完整的育儿知识图谱。本发明的智能育儿知识服务***能够提供给用户一个完整的儿科疾病知识图谱,在一张图谱中就能为用户展示所查询症状的所有关联数据。无论是查询效果还是用户体验均优于传统的论坛和网站中的关键字查询。
(2)本发明中个人机器人服务是本***的独创功能,在育儿过程中,每位父母都有自己的经验及体会,这些已有经验将会为以后本人育儿和他人育儿过程中碰到的问题提供知识服务;通过从小培养一个属于自己的育儿机器人,记录自己在育儿过程中的点滴经验,在以后的育儿过程中,可随时翻查已有的育儿知识,包括症状、治疗方法、用药等各种信息,实现了知识的重复利用。同时个人机器人的知识可以通过育儿社区向其他用户开放,其他用户可以完整的获取每个个人机器人共享的育儿知识,能够帮助用户全面了解育儿过程中碰到的疾病诊疗问题,比传统论坛式的问答服务提供的零散化育儿知识更全面,更具参考价值。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明专家机器人服务流程图。
图2是本发明个人机器人服务流程图。
具体实施方式
下面将结合本发明实施例中,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
一种智能育儿知识服务方法,具体按照以下步骤进行:
步骤1,信息采集:利用爬虫程序定时下载、解析最新的儿童疾病数据信息,并储存在mysql数据库中;信息采集是***在后台默默运行的第一道程序,虽然用户无法直接看到,但是其为知识构建模块提供素材。因此,作为整个***的基础,其重要性不言而喻。信息采集的流程是:首先选择几个比较权威的网站,然后定时的爬取其数据,然后解析,去除无用标签、广告,最后持久化到本地mysql数据库中。
定时爬取:为保证***的数据能够在一定时间段内更新,从而获得当前新发的一些流行性疾病信息,必须让***定时的采集数据。而采集的频率又不能太高,因为采集速度过快,会造成服务器负载过大,影响其他功能的流畅性。
这里我们实现tomcat服务器的上下文***类来作为守护进程,并在其中调用java6.0以后新添加的concurrent包所提供的定时器,然后在定时器中调用自己写好的定制化爬虫程序。最终,只需要在web.xml文件中配置好***,就能够在启动服务器后,一边处理前端来的业务逻辑请求,一边定时的爬取我们所指定网站的数据,并做相应的解析工作。可以设置爬取时间在每天晚上的24点到3点,此时一般访问服务器的人比较少,不会给服务器造成很大的压力,有利于***的平稳运行。
定制化爬虫:
为了满足自身的需要,我们自己设计爬虫程序。要做定制化爬虫,爬取特定网站的特定数据,我们必须对这些网站的结构进行研究,然后总结一套通用的方案。要写一个定制化爬虫程序,获取特定内容,我们先模拟人在浏览此网站时所执行的操作。例如打开某一个医疗信息网站后,因为我们做的是关于儿童的***,所以先点击“儿科”,然后点击“儿科”下的一个科室“小儿感染科”,右侧会列出所有“小儿疾病科”的所有疾病。最后要做的就是,点击“疾病详细资料”,浏览疾病详情。
分析整个访问过程,我们的爬虫程序大致可以分为两个步骤。第一步采集疾病详情页面的URL,放入“疾病详情URL队列”;第二步多线程遍历“疾病详情URL队列”采集疾病详情数据。
要拿到疾病详情的URL,我们必须遍历“儿科”下的所有小科室,然后获得每一个小科室下疾病的总数量,根据总数量算出当前小科室下的疾病分为几页,由页码构建出疾病列表页的URL,并放入“疾病列表URL列表”中。最终所有科室下每一页的内容结构都是一样的,只需遍历“疾病列表URL列表”,一个个解析,获得疾病详情URL,并放入“疾病详情URL队列”中。
采用多线程去“疾病详情URL队列”中取出URL,下载,并解析即可。应该注意的是,这里的URL可能很多,必须进行标注,哪些爬取成功,哪些尚未爬取,哪些爬取失败。对于爬取失败的,可能是网络原因,需要进行再次爬取。对于新添加URL,还应进行判断,此URL是否已经在队列中。当队列里URL足够多时,这个判断可能会很耗时,优化方法是:计算URL的MD5值,然后放于一个hash表中,每次用这个hash表进行判断,将会省时许多。
整个爬取过程中,包括两个操作:下载,解析。下载html文本我们会用到apache的开源项目httpClient包发送请求;而解析文本,则会用到正则表达式和Jsoup。Jsoup用来获取HTML节点中需要的内容,正则表达式用来匹配那些没有节点限制的内容,例如匹配疾病总数等。
当数据采集下来以后,就要持久化到本地数据库,以供知识构建模块使用。本***采用mysql关系型数据库,持久化过程使用javaee标准的jpa框架,这样可以免去直接操作sql语句的繁琐,从而以面向对象的方式访问数据,有利于***的扩展和维护。
步骤2,专家机器人知识库构建:以知识图谱的形式直观的为用户提供儿科疾病相关的各类知识服务;专家机器人模块主要是模拟病人看病的过程,通过不断与用户进行交流,逐渐衍生出了疾病咨询、疾病预测、医生推荐这三个子模块。这三个子模块围绕着现实生活中问诊的流程展开,因此也会有一定的次序。而其知识库的构建,也将因为各自具体情况的不同,而有所不同。
(1)疾病咨询:
疾病咨询主要是尽量模拟医生的口吻与病人进行有效的交流。交流的目的是获取疾病症状词,从而为疾病预测模块提供原料。而咨询的方式,又会因为用户情况的不同而分为两种:其一是用户知道疾病名称,这样直接将疾病名称输出到疫病预测模块即可;第二种是用户不知道疾病名称,那么只能通过与用户不断的交流,来获取症状词,将症状词列表传递给疾病预测模块。因为第一种情况很简单,根据疾病咨询中获得的疾病名称在mysql数据库中检索,以知识图谱的形式为用户展示疾病预测结果;下面详细阐述第二种情况。
首先应该明确,与用户交流的目的是获取症状词。而用户输出的是自然语言,如何从用户输入的口语中获取到比较专业的症状词:
我们首先构建了一张疾病症状词表。症状词表来源于数据采集模块爬取到的疾病数据。其疾病数据中的疾病症状和临床表现中的词语,可以作为症状词,因此对这些词语进行了进一步处理,并放入了症状词表中。
另外由于用户输入的口语症状词可能不在疾病症状词表中,也或许有些症状词有多种说法,但是他们都表示同一个意思。例如:“发烧”的口语表示为“发烫”,其他说法甚至还有“发热”等。当用户输入其中一种时,即表示用户有此种症状。因此,还需要为症状词表补充同义词。为了数据的准确性,我们写自动化程序,首先将同义词表中的同义词自动添加到各个症状词后面。自动化程序的思路是,模拟人查同义词表的过程,以每一个症状词为原本词去查同义词表,查到同义词即补充到症状词表后面。考虑到同义词可能不够齐全和一些口语症状词可能不在其列,我们需要人为的为这些症状词补充了同义词。最终经过程序和人的双重补充,达到的症状词有2455条,其中每个症状词后面的同义词可能有4到5个,当然不排除有的症状词没有同义词的可能。
最后要对用户输入的自然语句进行切分,需要一个全而新的词库。这里我们采用mmseg4J分词器,采用搜狗输入法提供的最新词典,在加入我们自己构建的一些口语症状描述词作为分词的大词典。这样,只要用户的输入语句中包含我们构建好的症状词或者症状词的同义词,甚至是口语描述,我们都能够识别出来。
例如,当用户输入:“我的孩子最近老流清鼻,有时候头还发烫,该怎么办呢?”,我们的分词结果是:“我的|孩子|最近|老|流清鼻|,|有时候|头|还|发烫|,|该|怎么办|呢|?|”。然后将分出的词与症状词表匹配,首先与症状词表的主词匹配,倘若不匹配,则再次与症状词的同义词匹配,如果匹配则表明:用户的本次描述捕获到了症状词。例如此次用户的输入,我们一一将分词结果去匹配,最后发现,“流清鼻”虽然与症状词表的主词“流鼻涕”不相匹配,但是与我们手动添加的通俗说法“流清鼻”匹配;而“发烫”也与主词“发烧”不相匹配,但是却匹配于程序构建的源于同义词表的词语“发烫”。
为了疾病预测的准确性,我们尽量匹配足够多的症状,才去结束疾病咨询的过程。可是有些疾病症状确实不够多,让用户一味的输出非典型症状,有时候反而不利于疾病的预测。因此我们疾病咨询遵循的机制是:“尽量但不勉强”。当咨询后用户输入的速度减慢,或者不再输入新症状时,表明用户症状的描述完全,则结束本次问询。
(2)疾病预测:
包括疾病名称预测和症状词列表预测;疾病名称预测是根据疾病咨询中获得的疾病名称在mysql数据库中检索,以知识图谱的形式为用户展示疾病预测结果;症状词列表预测是将疾病咨询中获得的症状词列表与mysql数据库中每一种疾病的症状进行匹配,根据匹配程度以知识图谱的形式为用户展示疾病预测结果;
当用户知道疾病名称时,疾病的预测也就是基于疾病名的一个检索;我们采用开源的全文搜索框架luence,分别对mysql数据库中准备好的疾病数据的“名称”、“概述”、“详细资料”等字段提前建立好索引;建立索引时赋予不同的权重,“名称”的权重最大,根据用户提供的疾病名称与mysql数据库中的疾病名称的吻合程度,对每个检索结果进行打分,这样当用户提供的疾病名称与疾病库中的疾病名称吻合时,检索后输出的分值就大,将得分高的疾病预测结果反馈给用户。每个检索结果都带有一个分值,***并不能保证用户输入的疾病名称完全准确,这样基于一个分值的输出就更加具有客观性。当用户输入的疾病名称不在我们***时,计算结果的分值会小的接近于0,用户就可以不必以***的预测为参考,也不会延误用户寻找其他途径的咨询方式。
症状词列表预测的主要方法是,将“疾病咨询”模块获得的症状词列表与mysql数据库中每一种疾病的症状进行匹配,倘若匹配度高,则将其对应的疾病预测给用户。当然,这里的匹配不能简单的用有和无的匹配方式进行。因为,有的疾病症状多,有的疾病症状少,有的疾病症状突出,往往一种症状就能左右这种疾病。而流行感冒这种疾病,则症状相对而言就比较多了。所以我们应该采取一种算法,可以综合考虑以上综合因素。
我们采取综合了tf-idf的余弦相似度匹配算法,来进行疾病与症状的匹配。首先要对mysql数据库中所有的疾病症状排序,而后根据疾病症状的序列,为mysql数据库中每一种疾病构建一条向量P,同时根据疾病咨询中获得的症状词列表构建一条假想的疾病向量Pˊ。
构建疾病向量的方法:倘若某疾病相应的位置确实出现某种症状,这个位置的向量因子就是此症状相对于此疾病的tf-idf值,倘若没有出现某种症状,这个位置的向量因子取0值;
tf-idf值的计算方式如下:
tf-idf(wij)=tf(wij)×idf(wi)
tf(Term Frequency)值,表示一个症状词在当前疾病数据中出现的频率,频率越大表明此症状与此疾病越相关。疾病数据包括疾病描述、临床表现、症状等我们所采集到的数据;其计算公式为:
其中,n(wij)表示第i个症状词在第j种疾病数据中出现的次数,D(j)表示第j种疾病数据分词后的总词数;例如,“打喷嚏”在“流行性感冒”的数据中出现了4次,而“流行性感冒”的数据总词数有500个,那么其tf(wij)值便为0.008。
Idf(Inverse Document Frequency)值,表示一个症状的稀有程度,越稀有的症状预测一种疾病的能力往往越强。其计算公式为:
其中,A表示当前的疾病总数,a(wi)表示出现第i个症状词的疾病总数;例如“流鼻涕”出现在了35种疾病中,而我们的疾病总数有7000个,那么其idf值便为:log(7000/35)≈2.30。
由上可知,一个症状对一种疾病的预测性取决于两个因素:tf值,即当前症状在此疾病中出现的频率,多则强;idf值,即此症状的稀有程度,越稀有的症状出现在一种疾病中时,越能够预测此疾病。
按照上述方法,两条疾病向量构建完成后,计算两条疾病向量的余弦值,计算公式如下:
构建疾病向量的具体操作方法:
首先将所有的疾病症状排好序。假设当前疾病库中的疾病症状有10个:
表1 症状词向量序列
1 2 3 4 5 6 7 8 9 10
发烧 黄疸 溃疡 流鼻涕 呕吐 鼻出血 水肿 血尿 打喷嚏 贫血
假设流行感冒的疾病症状有“发烧”、“流鼻涕”、“呕吐”、“打喷嚏”,而这些症状相对于此疾病的tf-idf值分别为:0.0022,0.0184,0.0053,0.0242;那么最终构建的流行性感冒的向量为:P(0.0022,0,0,0.0184,0.0053,0,0,0,0.0242,0)。
构建好每一种疾病的向量后,就可以进行疾病预测了。当疾病咨询模块传来症状列表以后,我们会为当前用户构建一条假想疾病的向量。构建方法与疾病向量的方法相同。假设在疾病咨询模块所捕获到的用户症状为:“发烧”、“流鼻涕”、“打喷嚏”,那么为预期疾病构建的向量为:Pˊ(0.0022,0,0,0.0184,0,0,0,0,0.0242,0)。
等到两条向量就绪,就可以进行计算两条向量之间的余弦值了。计算公式如下:
其中分子为两条向量的内积,分母为两条向量模的乘积;
我们还以上面的例子进行计算,则计算结果为cos(PPˊ)≈0.9852,可以看到余弦值接近于1,说明两条向量非常相似,由此证明用户患有流行感冒的概率是比较大的,我们可以将此疾病信息预测给用户。
采取tf-idf值可以保证某种疾病的关键症状能够获得比较大的权重,从而在进行余弦相似度计算时,可以算出比较大的结果。这样当用户出现这些关键症状时,我们***的预测就能够尽可能的靠拢那些拥有关键症状词的疾病。当每条疾病向量P与假想疾病向量Pˊ的余弦值计算完成后,余弦值按照从大到小排序,选择前十个余弦值对应的疾病信息,返还给前端做可视化展示,将该疾病预测结果反馈给用户。
余弦值越大越接近于1,就说明这个假想向量与相应疾病向量越相似,用户的患儿就越有可能患有此种疾病。当然,之所以不将余弦值最大的一个结果返回给用户,是因为此***毕竟不是真人医生,并不能确诊,因此返回前十个供用户参考。不过这也印证了此模块的名字“疾病预测”,预测的结果当然不只一个了。
倘若用户在疾病咨询模块给出的症状词过少,在疾病预测模块不足以够构建向量时,***提供另一种预测疾病方法。当用户给出一个症状词时,在mysql数据库中查找,遍历每一个疾病的症状列表,假如搜索到某一个疾病的症状列表中包含当前症状词,而当前症状词的tf-idf值与搜索到的疾病症状列表中所有症状词的tf-idf总和结果比率接近于1,说明用户患有此种疾病的可能性越大;然后取出此疾病症状列表中第二大tf-idf值的症状词去询问用户是否满足,倘若满足,则继续询问第三大tf-idf值的症状,依次类推,当已经确定的症状词数与此疾病症状词总数的比例达到65%时,将该疾病预测结果反馈给用户;如果已经确定的症状词数与此疾病症状词总数的比例不足65%时,再按照上述方法依次对其它包含当前症状词的疾病症状列表进行预测。
(3)医生推荐:
医生推荐模块主要功能是基于用户先前的疾病咨询记录和疾病预测结果的点击记录,为用户推荐与用户所患疾病相关的医生信息;医生信息包括医生的姓名、科室、所属医院、简介、主治、擅长、联系方式等。
为了能够高速有效的给用户推荐到合适的医生,***依然使用luence框架为医生的信息建立索引。且不同的信息赋予不同的权重,主治和擅长的权重均大于其他信息,简介的权重次之;如主治和擅长的权重都为3,简介的权重为1。这样当用户的检索信息中包含的某种疾病症状或者疾病名称在医生的主治和擅长中出现时,当前医生所获得的检索排名分数就高,说明此医生越是擅长此种疾病,同时此医生被推荐的可能性就越大。选取排名前十的医生推荐给用户。让用户自己去选择点击查看医生的详细信息,并确定是否选择此医生去实地就医。
在整个过程结束之后,***还会讯问用户对于本次问诊是否满意,这将作为***的一种反馈,将本次问诊的记录添加到个人机器人模块。当在个人机器人模块中用户选择公开自己机器人时,将会有可能获得***机器人的问题解答,而问题解答的信息来源便是本次用户点赞的问诊记录。
步骤3,个人机器人知识库构建:
个人机器人是用户自行创建的在***中的虚拟代理。用户可以将自己在育儿的过程中,所积累的经验和知识通过培养的方式不断的向个人机器人输入自己的知识,这样就实现了机器人的成长;个人机器人以一个问题对应一个答案的形式存储在mysql数据库中,并以知识社区的形式为不同用户提供过程式的育儿知识服务;个人机器人知识库的构建过程,就是用户不断的输入自己的知识让机器人记住的过程。
首先,每一个用户登录***后,都可以创建一个自己的机器人。机器人要有昵称、年龄、外表、称呼语等数据,用户将在***的引导下一步步完善这些数据。而后,用户每次进入个人机器人模块时,已经创建好的机器人就会给用户打招呼,并开始服务。***服务的主要模式是问答,问答的难点在于如何实现知识的增长和基于用户的问题寻找答案。
知识的增长主要来源于用户的培养。当用户讯问自己的机器人一个问题时,倘若***以前从用户那里获取过这个问题的答案,***便会直接给出答案。倘若***的知识库检索不到答案,机器人则会要求学习这个知识,于是用户将会在***的引导下教会机器人这个知识点。相应的这个知识点也会存储在***的知识库中,作为下一次对用户提问进行答案检索的依据。***中用户的问题和答案,采取一对一的存储方式,一个问题对应一个答案存储在mysql数据库的表中。
答案的寻找依旧依靠于luence全文检索引擎。***首先对所有的用户问题和答案数据分域建立索引,当用户问题提出时,首先对用户问题进行分词处理,然后去掉停用词和虚词,以主要实词和用户名建立一个嵌套查询去索引中查找。之所以叫嵌套查询,是因为luence中有一套查询机制,他可以组合“与”、“或”、”非”的嵌套,使得查询更加灵活。这里我们嵌套的查询是:(用户id)and(实词1or实词2or实词n),这样就能够查找指定用户知识库中的特定问题。查找结果也是基于分数的返回,我们选择分数最高问题的答案作为结果用来给用户回答。用户可能会对问题的答案不甚满意,这说明当前问题与用户的问题有差异,于是***机器人将提醒用户重新记住此新问题。不慎满意的另一种可能是,用户提问的方式有所改变,虽然是同一个问题,可能因为时间太过久远而用户用新的语句提出了此问题,由此导致***不能够识别这个问题。对于这种状况,***的优化方法是在实现luence建立索引时,添加同义词词典,这样可以解决由于句子中词语改变而造成的识别错误。例如用户提问“孩子发烧怎么办?”和用户提问“孩子发热怎么办?”会检索到一样的答案。但是这样只能解决由于用词不同而产生的问题检索失败,对于因为句法等原因导致的不识别问题,牵扯到更深层次的研究,本***暂时没有涉及。
另外,在个人机器人积累到10个问题以上时,用户可以选择公开自己的机器人,这样当用户再次提出一个问题时,或许在自己的知识库中检索失败,导致自己的机器人不能回答,而此时因为公开了数据,所以可以获得其他用户机器人的答案。与此同时,也将意味着自己的机器人也会为他人服务。通过这种模式,可以实现用户之间交流和分享育儿经验。
步骤4,***交互实现:
我们也充分人性化的考虑了用户的使用习惯,通过PC端和移动端实现用户交互;作为一个机器人***,首先应当考虑的就是如何让***更加人性化。而人性化不仅体现在算法上面,更加体现在交互上。为了让***更加具有人的品质,我们不但使用语音技术让***具有人的声音,而且还使用了一些数据可视化技术,使得数据的展示更加形象生动。这样,***不仅从视觉还是从听觉上,都会带给用户耳目一新的体验。
在安卓手机端,语音合成技术和语音识别技术都比较成熟,***可以完全实现服务器数据的读和听,因此用户和***的交互是纯语音交互。当***构建好需要机器人说出的话以后,通过http协议传输json数据到手机端,手机直接解析后调用语音接口合成音频文件,让手机朗读出来即实现了机器人的“说”。而用户回答机器人问题时,也只是说出来,安卓端将调用语音***API将用户语音转化为文字,并构建json字符串传给***服务器,从而实现了机器人的“听”。浏览器端的语音技术相对较弱,不过也可以实现语音的合成,这机器人只会“说”,而识别就需要用户手动输入文字了。不过,PC键盘的文字输入也是非常方便的,只要用户拥有一般人的打字速度,交互还是非常流畅的。
当然,在听与说的同时,视觉上还需要让用户感受到机器人的动作。安卓端将使用帧动画的形式,机器人在说与听的同时,播放机器人交互动作动画,让用户体验到是在与机器进行交流,而不是手机。浏览器端将使用js实现图片的轮播,从而也会拥有动画的效果。
从服务器端传来的还有一些展示数据,例如疾病预测的结果、疾病详情、医生推荐结果、医生详情等,这些数据安卓端将在webViewr控件中调用JS,采用Echars展现。浏览器端嵌入Echars早已经非常成熟,所以也没有什么技术难度。Echars动态图标展示,将使得数据形象生动,而不再只像文字一般单调。
对于***中机器人表达的一些提示性语句,为了不让用户感到呆板,我们趣味性的设置了许多种表达。在***运行一个流程节点时,***会遍历当前提示语的所有说法,随机选取一个给用户提示。这样,在用户连续多次使用***后,每次都基本会遇到不同的表达,将会增加体验的新奇性。
本发明采用上述智能育儿知识服务方法的智能育儿知识服务***,包括信息采集模块、专家机器人模块、个人机器人模块和***交互模块;
信息采集模块与mysql数据库连接,用于通过爬虫程序定时获取最新的儿童疾病数据信息;
专家机器人模块,用于以知识图谱的形式直观的为用户提供儿科疾病相关的各类知识服务;专家机器人模块包括疾病咨询模块、疾病预测模块、医生推荐模块;
疾病咨询模块与疾病预测模块连接,用于获取用户提供的疾病名称或症状词,并将疾病名称、症状词列表传递至疾病预测模块;疾病咨询模块包括mmseg4J分词器和疾病症状词表,mmseg4J分词器用于切分用户输入的口语症状词;疾病症状词表包括mysql数据库中的疾病症状和临床表现中的词语、及其同义词,疾病症状词表用于识别经过mmseg4J分词器切分的症状词。
疾病预测模块,用于将疾病名称在mysql数据库中检索,以知识图谱的形式为用户展示疾病预测结果;以及将症状词列表与mysql数据库中每一种疾病的症状进行匹配,根据匹配程度以知识图谱的形式为用户展示疾病预测结果;
医生推荐模块分别与疾病咨询模块、疾病预测模块连接,基于疾病咨询模块的咨询记录和疾病预测结果的点击记录,为用户推荐与用户所患疾病相关的医生;
个人机器人模块,用于将用户输入的知识以一个问题对应一个答案的形式存储在mysql数据库中,并以知识社区的形式为不同用户提供过程式的育儿知识服务;
***交互模块,包括PC端和移动端,采用语音技术让***具有人的声音,采用数据可视化技术使得数据的展示更加形象生动,包括多种说法的提示语。
本***经过从设计到实现的一系列研究,最终可以平稳运行。其定时定向的数据采集,全面严谨的知识库构建,友好动态的语音交互将会缓解无数育儿父母育儿过程中的烦恼,甚至于带给他们育儿的乐趣,从而填补了儿童医疗知识智能服务在移动互联网时代的空白。
以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本发明的保护范围内。

Claims (8)

1.一种智能育儿知识服务方法,其特征在于,具体按照以下步骤进行:
步骤1,信息采集:利用爬虫程序定时下载、解析最新的儿童疾病数据信息,并储存在mysql数据库中;
步骤2,专家机器人知识库构建:包括疾病咨询、疾病预测、医生推荐三个步骤;
所述疾病咨询:将用户提供的疾病名称直接传递至疾病预测模块;或者通过与用户不断的交流获取症状词,采用分词器切分用户输入的口语症状词,利用mysql数据库中的疾病症状词表识别切分后的症状词,获得症状词列表,并传递至疾病预测模块;
所述疾病预测:包括疾病名称预测和症状词列表预测;所述疾病名称预测是根据疾病咨询中获得的疾病名称在mysql数据库中检索,以知识图谱的形式为用户展示疾病预测结果;所述症状词列表预测是将疾病咨询中获得的症状词列表与mysql数据库中每一种疾病的症状进行匹配,根据匹配程度以知识图谱的形式为用户展示疾病预测结果;
所述医生推荐:基于用户先前的疾病咨询记录和疾病预测结果的点击记录,为用户推荐与用户所患疾病相关的医生信息;
步骤3,个人机器人知识库构建:用户不断的向个人机器人输入自己的知识,个人机器人以一个问题对应一个答案的形式存储在mysql数据库中,并以知识社区的形式为不同用户提供过程式的育儿知识服务;
步骤4,***交互实现:通过PC端和移动端实现用户交互;
所述步骤2中将疾病咨询中获得的症状词列表与mysql数据库中每一种疾病的症状进行匹配,根据匹配程度为用户进行疾病预测的方法是:采用tf-idf的余弦相似度匹配算法,具体按照以下步骤进行:
首先要对mysql数据库中所有的疾病症状排序,而后根据疾病症状的序列,为mysql数据库中每一种疾病构建一条向量P,同时根据疾病咨询中获得的症状词列表构建一条假想疾病向量Pˊ;两条疾病向量构建完成后,计算两条疾病向量的余弦值,计算公式如下:
当每条疾病向量P与假想疾病向量Pˊ的余弦值计算完成后,余弦值按照从大到小排序,选择前十个余弦值对应的疾病信息,将该疾病预测结果反馈给用户;
所述步骤2还包括以下步骤:倘若用户在疾病咨询模块给出的症状词过少,不足以够构建假想疾病向量时,疾病预测方法为:当用户给出一个症状词时,在mysql数据库中查找,遍历每一个疾病的症状列表,假如搜索到某一个疾病的症状列表中包含当前症状词,而当前症状词的tf-idf值与搜索到的疾病症状列表中所有症状词的tf-idf总和结果为确定值0.9852,然后取出此疾病症状列表中第二大tf-idf值的症状词去询问用户是否满足,倘若满足,则继续询问第三大tf-idf值的症状,依次类推,当已经确定的症状词数与此疾病症状词总数的比例达到65%时,将该疾病预测结果反馈给用户;如果已经确定的症状词数与此疾病症状词总数的比例不足65%时,再按照上述方法依次对其它包含当前症状词的疾病症状列表进行预测。
2.根据权利要求1所述的一种智能育儿知识服务方法,其特征在于,所述步骤2中根据疾病咨询中获得的疾病名称为用户进行疾病预测的方法是:基于疾病名称的检索,采用开源的全文搜索框架luence,分别对mysql数据库中疾病数据的“名称”、“概述”“详细资料”字段提前建立索引,建立索引时赋予不同的权重,“名称”的权重最大,根据用户提供的疾病名称与mysql数据库中的疾病名称的吻合程度,对每个检索结果进行打分,将得分高的疾病预测结果反馈给用户。
3.根据权利要求1所述的一种智能育儿知识服务方法,其特征在于,所述构建疾病向量的方法:倘若某疾病相应的位置确实出现某种症状,这个位置的向量因子就是此症状相对于此疾病的tf-idf值,倘若没有出现某种症状,这个位置的向量因子取0值;
tf-idf值的计算方式如下:
tf-idf(wij)=tf(wij)×idf(wi)
tf值,表示一个症状词在当前疾病数据中出现的频率,其计算公式为:
其中,n(wij)表示第i个症状词在第j种疾病数据中出现的次数,D(j)表示第j种疾病数据分词后的总词数;
Idf值,表示一个症状的稀有程度,其计算公式为:
其中,A表示当前的疾病总数,a(wi)表示出现第i个症状词的疾病总数。
4.根据权利要求1所述的一种智能育儿知识服务方法,其特征在于,所述步骤2中医生推荐的方法是:使用luence框架为医生的信息建立索引,医生的信息包括姓名、科室、所属医院、简介、主治、擅长、联系方式,不同的信息赋予不同的权重,主治和擅长的权重均大于其他信息,简介的权重次之;选取排名前十的医生推荐给用户;在整个过程结束之后,***还会讯问用户对于本次问诊是否满意,将本次问诊的记录添加到个人机器人模块。
5.根据权利要求1所述的一种智能育儿知识服务方法,其特征在于,所述步骤3中,对用户提问进行答案检索的方法:首先对存储在mysql数据库中的所有问题和答案数据分域建立索引,当用户问题提出时,对用户问题进行分词处理,然后去掉停用词和虚词,以主要实词和用户名建立一个嵌套查询在索引中查找。
6.一种智能育儿知识服务***,其特征在于,包括信息采集模块、专家机器人模块、个人机器人模块和***交互模块;
所述信息采集模块与mysql数据库连接,用于通过爬虫程序定时获取最新的儿童疾病数据信息;
所述专家机器人模块,用于以知识图谱的形式直观的为用户提供儿科疾病相关的各类知识服务;专家机器人模块包括疾病咨询模块、疾病预测模块、医生推荐模块;
所述疾病咨询模块与疾病预测模块连接,用于获取用户提供的疾病名称或症状词,并将疾病名称、症状词列表传递至疾病预测模块;
所述疾病预测模块,用于将疾病名称在mysql数据库中检索,以知识图谱的形式为用户展示疾病预测结果;以及将症状词列表与mysql数据库中每一种疾病的症状进行匹配,根据匹配程度以知识图谱的形式为用户展示疾病预测结果;
所述医生推荐模块分别与疾病咨询模块、疾病预测模块连接,基于疾病咨询模块的咨询记录和疾病预测结果的点击记录,为用户推荐与用户所患疾病相关的医生;
所述个人机器人模块,用于将用户输入的知识以一个问题对应一个答案的形式存储在mysql数据库中,并以知识社区的形式为不同用户提供过程式的育儿知识服务;
所述***交互模块包括PC端和移动端。
7.根据权利要求6所述的一种智能育儿知识服务***,其特征在于,所述疾病咨询模块包括mmseg4J分词器和疾病症状词表,mmseg4J分词器用于切分用户输入的口语症状词;疾病症状词表包括mysql数据库中的疾病症状和临床表现中的词语、及其同义词,疾病症状词表用于识别经过mmseg4J分词器切分的症状词。
8.根据权利要求6所述的一种智能育儿知识服务***,其特征在于,所述PC端和移动端,采用语音技术让***具有人的声音,采用数据可视化技术使得数据的展示更加形象生动,包括多种说法的提示语。
CN201710210882.8A 2017-03-31 2017-03-31 智能育儿知识服务方法及*** Active CN106991284B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710210882.8A CN106991284B (zh) 2017-03-31 2017-03-31 智能育儿知识服务方法及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710210882.8A CN106991284B (zh) 2017-03-31 2017-03-31 智能育儿知识服务方法及***

Publications (2)

Publication Number Publication Date
CN106991284A CN106991284A (zh) 2017-07-28
CN106991284B true CN106991284B (zh) 2019-12-31

Family

ID=59414799

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710210882.8A Active CN106991284B (zh) 2017-03-31 2017-03-31 智能育儿知识服务方法及***

Country Status (1)

Country Link
CN (1) CN106991284B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108764280A (zh) * 2018-04-17 2018-11-06 中国科学院计算技术研究所 一种基于症状向量的医学数据处理方法和***

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107545148A (zh) * 2017-09-30 2018-01-05 旗瀚科技有限公司 一种智能机器人诊断问答交互***
CN108182262B (zh) * 2018-01-04 2022-03-04 华侨大学 基于深度学习和知识图谱的智能问答***构建方法和***
CN108109694B (zh) * 2018-01-05 2023-06-30 李向坤 事件判定方法及装置、存储介质、电子设备
CN108984647A (zh) * 2018-06-26 2018-12-11 北京工业大学 一种基于中文文本的水务领域知识图谱构建方法
TWI688969B (zh) * 2018-10-24 2020-03-21 大仁科技大學 藥品選擇對話系統
CN109492080A (zh) * 2018-10-25 2019-03-19 杭州任你说智能科技有限公司 一种基于语音问答机器人的医疗保健***及其实现方法
CN109582777A (zh) * 2018-12-06 2019-04-05 中国银行股份有限公司 一种人机智能处理方法及***
CN110033851B (zh) * 2019-04-02 2022-07-26 腾讯科技(深圳)有限公司 信息推荐方法、装置、存储介质及服务器
CN110335674A (zh) * 2019-06-10 2019-10-15 旗瀚科技有限公司 一种用于助老助残机器人的疾病初步诊断方法
CN110415818A (zh) * 2019-08-05 2019-11-05 儿康智能科技(苏州)有限公司 一种基于可观察病症的智能儿科疾病问诊***及方法
CN110867255A (zh) * 2019-10-24 2020-03-06 开望(杭州)科技有限公司 一种智能母婴知识服务方法及***
CN111079021B (zh) * 2019-12-20 2023-09-19 腾讯科技(深圳)有限公司 推荐医疗资讯内容的方法、装置、服务器和存储介质
CN111414393B (zh) * 2020-03-26 2021-02-23 湖南科创信息技术股份有限公司 一种基于医学知识图谱的语义相似病例检索方法及设备
CN111191051B (zh) * 2020-04-09 2020-07-28 速度时空信息科技股份有限公司 一种基于中文分词技术的应急知识图谱的构建方法及***
CN112231537A (zh) * 2020-11-09 2021-01-15 张印祺 基于深度学习和网络爬虫的智能阅读***
CN112445872B (zh) * 2020-11-25 2023-04-07 开望(杭州)科技有限公司 一种基于亲子空间的家庭画像构建方法
CN113077898A (zh) * 2021-03-08 2021-07-06 南京紫金山智慧城市研究院有限公司 基于大数据挖掘的智慧健康管理大脑***

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101477566A (zh) * 2009-01-19 2009-07-08 腾讯科技(深圳)有限公司 一种用于候选主题词广告投放的方法及装置
CN103049641A (zh) * 2012-11-13 2013-04-17 张宝永 一种导医诊断显示方法及***
CN104102816A (zh) * 2014-06-20 2014-10-15 周晋 基于症状匹配和机器学习的自动诊断***和方法
CN104484845A (zh) * 2014-12-30 2015-04-01 天津迈沃医药技术有限公司 基于医学信息本体数据库的疾病自我分析方法
CN104680458A (zh) * 2015-02-09 2015-06-03 李宏强 一种基于海量处方给大众推荐就医科室、医院或医生的方法
CN104915446A (zh) * 2015-06-29 2015-09-16 华南理工大学 基于新闻的事件演化关系自动提取方法及其***
CN105139237A (zh) * 2015-09-25 2015-12-09 百度在线网络技术(北京)有限公司 信息推送的方法和装置
CN106096283A (zh) * 2016-06-16 2016-11-09 贵阳朗玛信息技术股份有限公司 远程问诊助理服务平台、***及方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101477566A (zh) * 2009-01-19 2009-07-08 腾讯科技(深圳)有限公司 一种用于候选主题词广告投放的方法及装置
CN103049641A (zh) * 2012-11-13 2013-04-17 张宝永 一种导医诊断显示方法及***
CN104102816A (zh) * 2014-06-20 2014-10-15 周晋 基于症状匹配和机器学习的自动诊断***和方法
CN104484845A (zh) * 2014-12-30 2015-04-01 天津迈沃医药技术有限公司 基于医学信息本体数据库的疾病自我分析方法
CN104680458A (zh) * 2015-02-09 2015-06-03 李宏强 一种基于海量处方给大众推荐就医科室、医院或医生的方法
CN104915446A (zh) * 2015-06-29 2015-09-16 华南理工大学 基于新闻的事件演化关系自动提取方法及其***
CN105139237A (zh) * 2015-09-25 2015-12-09 百度在线网络技术(北京)有限公司 信息推送的方法和装置
CN106096283A (zh) * 2016-06-16 2016-11-09 贵阳朗玛信息技术股份有限公司 远程问诊助理服务平台、***及方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
基于Solr实现农业信息扩展检索的研究;于静一;《中国优秀硕士学位论文全文数据库信息科技辑》;20140315(第03期);第I138-1204页 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108764280A (zh) * 2018-04-17 2018-11-06 中国科学院计算技术研究所 一种基于症状向量的医学数据处理方法和***

Also Published As

Publication number Publication date
CN106991284A (zh) 2017-07-28

Similar Documents

Publication Publication Date Title
CN106991284B (zh) 智能育儿知识服务方法及***
Luo et al. A critical review of state‐of‐the‐art chatbot designs and applications
CN109478205B (zh) 用于计算机学习和理解的体系结构和方法
White et al. Exploratory search: Beyond the query-response paradigm
Sahib et al. A comparative analysis of the information‐seeking behavior of visually impaired and sighted searchers
US20160132789A1 (en) Streams of Attention Method, System, and Apparatus
US20110125734A1 (en) Questions and answers generation
CN112667799B (zh) 一种基于语言模型和实体匹配的医疗问答***构建方法
CN103917968A (zh) 用于管理具有交互式评论流的评论网络的***和方法
US20220139535A1 (en) Efficient determination of a data entity storing healthcare data through mapped entry and/or traversal of a semantic data structure
WO2019116253A1 (en) Supporting evidence retrieval for complex answers
US20140186818A1 (en) Computer based system and method for assisting an interviewee in remembering and recounting information about a prior event using a cognitive interview and natural language processing
Liu et al. Search interface design and evaluation
US20180158010A1 (en) User Operation Selection and/or Modification Based on Determined User Skills/Skill Limitations
US11188844B2 (en) Game-based training for cognitive computing systems
Barifah et al. Emotions associated with failed searches in a digital library
King et al. Finding the concept, not just the word: a librarian’s guide to ontologies and semantics
Aghaei et al. Interactive search on the web: The story so far
Hui et al. Extracting conceptual relationships from specialized documents
Lieto et al. Degari 2.0: A diversity-seeking, knowledge-based, explainalable, and affective art recommender for social inclusion
IL293916A (en) Resource recommendations in online chat conversations are based on text sequences
Neji et al. Real-time affective learner profile analysis using an EMASPEL framework
Liu et al. An Emotion-fused Medical Knowledge Graph and its Application in Decision Support
Borman et al. PicNet: Augmenting Semantic Resources with Pictorial Representations.
Chang et al. Interactive Healthcare Robot using Attention-based Question-Answer Retrieval and Medical Entity Extraction Models

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant