赞
踩
注:
① 整个项目可作为本科阶段的课程设计或毕业设计,建议收藏。
② 若还未查看该项目的综述篇,请首先跳转查看:基于知识图谱的古诗词问答系统(全网首篇+包复现)
近年来,在大力倡导“文化自信”的时代背景下,“文以载道”,“以文化人”的理念渐渐走进了人们的视野,伴随着《经典咏流传》,《中国诗词大会》,《千秋诗颂》等优秀文化节目和动画的出现,在很大程度上掀起了一股国人对中国古典诗词的学习热潮。但在古诗词领域,线上学习方式仍旧以搜索引擎为主,无论是企业还是研究团队对于该领域的问答系统缺乏研究、缺乏应用,因此本文提出并实现了基于知识图谱的古诗词问答系统。
本篇是项目——基于知识图谱的古诗词问答系统的理论篇,主要从理论的层面分析和讲解整个系统,也即是讲解如何分析系统的功能和设计系统的各个模块。
在古诗词知识图谱模块,本文利用Python网络爬虫技术从各个与古诗词相关的网站中获取了原始数据,结合实体抽取、关系抽取等技术构建了古诗词领域的知识图谱,并将其存储于图数据库Neo4j。
在问答交互模块,本文使用前后端技术完成用户与系统的交互,用户在前端输入问句,问答系统会对该问句进行理解和解答,最后将最佳答案通过接口返回给用户。
在问句解析模块,问答系统在理解用户的问句时,首先借助Jieba分词工具完成问句的分词任务,然后使用FastText意图识别与问句分类模型,完成问句的意图识别和问句分类,从而为答案生成提供基础;在生成答案前,还需要得到问句中的命名实体,本文采用BERT模型实现NER任务,并将识别出来的命名实体传输到答案生成模块。
在答案生成模块,结合意图和问句分类标签,将命名实体填充到Cypher语句,并从知识图谱中获取知识,最后完成话术包装返回问句答案。
在系统处理模块,负责前后端数据的交互,各模块数据的交流,使得整个问答系统能够正常工作。
本问答系统的架构设计如下图所示,整个系统由5个模块组成,分别是系统处理模块、古诗词知识图谱模块、问答交互模块、问句解析模块、答案生成模块。
从上图可知各个模块内高聚合,而模块之间低耦合。首先介绍一下整个系统的运行流程,用户在前端输入问句,问句会经过系统处理模块传递给问句解析模块,该模块将问句的意图和分类标签以及问句中的命名实体集传递给答案生成模块,答案生成模块会根据不同的标签将命名实体填充到Cypher语句中,并将该语句传递到古诗词知识图谱模块,从Neo4j中获取对应的知识并再返回给答案生成模块,在答案生成模块将知识形成初步答案再进行话术包装后传递给系统处理模块,最后返回给问答交互模块呈现给用户。
系统各类数据的交互支撑着系统的运行流程,5大模块之间都提供了数据流的接口,而在模块内部的各项流程也存在数据的交互,下表给出了各类数据的交互格式。
系统架构图已经尽可能地描述了整个系统各模块之间的交互、数据的来源、模型训练的流程和知识图谱的构建。整个流程看起来十分复杂但其实一点也不简单,需要完成的工作很多,对用户来说就是一个黑盒操作,是端到端的。下面逐一介绍5个模块的设计。
系统处理模块,基于Web微框架Flask,是整个系统运行的“大脑”,决定了系统数据流、I/O控制以及模块之间的交互,是不可或缺的一个模块,智能机器人“小诗”是该模块的高度抽象。
就目前互联网的发展情况而言,大多数APP、网页的系统注册与登录,都涉及用户的个人信息,本系统同样采用该种模式完成此功能,借助此功能可以搜集各个用户的各类数据,从而为生成用户画像、用户个性化推荐等奠基础。
在注册阶段,注册账户仅支持邮箱注册,暂不支持手机号注册,除此之外,用户需要填写系统给注册邮箱发送的验证码、用户名以及密码;在登录阶段,用户只需输入已经注册的邮箱和对应的密码即可登录。其各项表单输入字段的设计和要求,如下表所示。
当用户在本系统完成正确注册后,就可以进入系统登录界面,而在登录时需要比对用户在登录界面输入的用户名和密码是否符合系统数据库存储的用户名和密码。密码是验证用户非常重要的手段,所以存储在数据库中的信息不能完全是用户输入的密码明文,而要使用一定的手段对密码加密,例如当用户输入的密码为“123456”,但数据库中存储的却是该密码经过技术处理后的字符信息。在本系统,直接使用Flask框架中的werkzeug.security模块提供的Hash加密和解密方法,完成数据库中的密码保护。用户注册的信息存储在系统依赖的MySql数据库,其数据库中的用户信息表的设计如下表所示。
在一个问答系统中,系统处理模块是运行流程中的“大脑”,其它各模块是“骨架”,而数据则是“血液”,要想所有血液在整个系统的各模块之间流动,离不开一个具有全局处理能力的大脑。针对本系统,系统处理模块主要处理完成了前端模板的渲染、问句在问答交互模块与问句解析模块的流动以及答案在问答交互模块与答案生成模块的流动。
(1)本系统Web开发环节采用前后端不分离的开发方式,在Flask框架下,所有的HTML都要符合Jinja2模板,框架自动完成渲染。
(2)当用户从前端输入问句并点击发送后,经过系统处理模块将问句传递给问句解析模块,完成对应的功能并将其存储到数据库。
(3)当用户意图、问句类型标签和命名实体传递给答案生成模块后,会通过一系列的流程完成问题到答案的映射,同时也会通过接口将答案提交给系统处理模块,这时系统处理模块也会以最大交付能力将答案返回到前端展示给用户。
如何使得本系统在古诗词领域知识问答上表现得更加智能,非常关键的一点在于构建一个知识更加充盈、更加专业的知识图谱,构建古诗词知识图谱不可缺少的是领域数据。行业知识图谱的本体来源于专家经验和领域专业文档,数据来源丰富,形态多样,有结构化数据、半结构化数据和非结构化数据。本系统的数据来源主要聚焦于结构化的开源数据集和半结构化的网页数据。
如今网络上存在大量的古诗词数据,其呈现的形式包括文本、图像以及视频,而本系统主要从文本数据着手,通过网络爬虫技术完成整个系统所需数据的获取和处理。得到古诗词领域的相关数据后,根据构建知识图谱的整体技术体系——知识表示与建模、知识抽取与挖掘、知识存储与融合以及知识推理与检索,完成本系统依赖的知识图谱。
获取哪些数据以及对获取的数据进行何种处理,并非随意为之,而是应该根据系统依赖的知识图谱对应的知识模型(Schema)完成相应的工作。针对古诗词领域的知识,系统所需的数据包括各朝代、朝代包含的作者、作者的基本信息、作者的合称以及作者创作的作品和名句。得到这些数据后,再从中进行知识抽取,包括实体、属性和关系的抽取。
构建知识图谱离不开知识,知识是知识图谱的基石。而知识的来源往往是从非结构化、半结构化的数据抽取和结构化的数据映射得到。本系统的少部分数据来源于GitHub开源数据集,而大部分数据来源于特定的古诗文网站(https://www.gushiwen.cn/、https://www.shicimingju.com/)。
所选择的开源数据集是目前最丰富的中华古典文集数据库,包含5.5万首唐诗、26万首宋诗、2.1万首宋词和其他古典文集等,但由于其中的数据与本系统设计的知识图谱的知识模型存在不契合的地方,所以仅仅选取了其中少部分数据作为知识图谱补全使用。
根据本系统的数据模型,需要手写网络爬虫爬取大量的数据。这些数据包括从先秦到清朝的古诗词作者(姓名、性别、朝代等)、作者的作品(标题、作者、朝代、内容等)、作者的名句(标题、作者、内容等)、作者的合称、作品类型等。
通过网络爬虫得到这些数据后,需要对这些数据进行清洗,包括数据去重、缺失数据补全、异常数据移除,并对处理完成后的数据进行挖掘,得到隐藏在数据背后的实体、关系等,为知识图谱的构建奠定基础。
数据爬取和处理是一个非常耗时的工作,因为针对不同网站需要制定不同的爬取策略、需要将不同来源的数据进行整合、网络原因等异常需要对地址进行重访等其它复杂的工作,如果针对系统没有一个全局性、十分清晰的数据模式,很难完成此阶段的功能。
在完成前序步骤的同时,也要考虑如何存储数据。由于本系统所需的数据都是文本类型的,所以所有的数据主要使用了Txt、Json类型的格式存储在磁盘,所有数据大小之和近750MB。
开源数据集的所有数据都以Json格式存储,这些数据仅仅包含了古诗词领域的部分内容,在处理数据上较为简单。而系统所需的绝大部分数据都通过网络爬虫获取,以下将从三个方面介绍系统网络爬虫体系的设计。
(1)网络爬虫工作流程
网络爬虫(又被称为网络蜘蛛、网络机器人),可以按照指定的规则(网络爬虫算法)自动浏览或抓取网络中的信息,网络爬虫属于人们日用而不觉的一种技术,因为人们常常知道搜索引擎的存在,而不知道搜索引擎离不开网络爬虫,而从网络爬虫实现的技术和结构,可以将其分为通用网络爬虫、聚焦网络爬虫(也称主题网络爬虫)、增量式网络爬虫。
使用网络爬虫技术,必不可少地需要了解Web前端的一系列规范和技术,例如HTTP协议、HTML语言、CSS层叠样式表以及JavaScript动态脚本语言;而网络爬虫的核心技术包括网页解析方法、动态渲染信息的抓取、多线程与多进程爬虫、分布式爬虫等等;当数据从网络中获取回来后,还需要利用数据处理技术对爬取回来的数据清洗和加工,从而存储为结构化的数据并对这些数据进行分析和挖掘。
在网络爬虫工作前,首先需要深度分析待爬网站的结构、数据的布局以及抓取的限制,下图给出了古诗词网站的整体布局,古诗词作品数据从诗文板块抓取、各类作者的名句从名句板块抓取而作者的相关信息从作者板块抓取,其中,作品的类型存在于诗文和名句两个板块,抓取后需要进行整合。
完成网站各网页的整体分析后,就可以针对其特征进行网络爬虫的工作流程设计,由于系统数据的来源不止一个网站,且针对同一个网站的各板块数据的抓取流程基本相同,所以本部分只给出了作者信息抓取的流程设计图,如下图所示。
作者数据爬取流程中,首先会给定各个作者对应的URL种子队列,然后遍历整个队列;遍历的过程中,会对每一个作者对应的网页进行解析,解析的方法包括正则表达式解析、Beautiful Soup解析和Xpath解析,但针对作者网页实现解析的方法主要采用Xpath;解析完网页数据后,就可以得到作者对应的数据,例如作者的简介、作者诗文的数量、作者的名句数量等等,同时也会将这些数据以Json、Txt文件格式存储到磁盘以待后续使用;最后判断种子队列是否为空,是则结束爬取,否则重复上述过程。
(2)数据抓取策略
网络爬虫是一种从网络中批量获取数据的技术,对此很多网站会有禁抓协议和反爬措施,为了能够使本系统的网络爬虫更加高效,需要设计相应的抓取策略。
由于待抓取的网站较为友好,所以本系统爬虫仅使用添加请求头修改User-Agent,伪装成浏览器向网站发起数据请求的方式完成了数据的爬取。
在完成各类数据抓取任务中,针对不同的网站架构本系统的网络爬虫主要采取了深度优先抓取和广度优先抓取两种抓取策略。深度优先抓取适合网页架构较为简单的网站,例如针对古诗文网,其网页布局较为简单,并且每个网页中关键的超链接都有规律可循,即抓取作者信息的同时,能够获取作者作品的链接,所以基于此就可以采用深度优先的策略完成从作者到作者作品这一数据流水线的爬取任务。
广度优先抓取则适合网页布局复杂的情况,例如在抓取类型对应的作品时,从种子URL开始,不同类型对应的网页布局不尽相同,如果这时仍旧采用深度优先抓取,那么必定增加处理特殊情况的难度,从而增加了开发的时间成本。所以,这时就应该采取广度优先抓取,先把各个类型对应的网页放入队列或者存储到文件,然后再针对队列里的链接进行爬取,在爬取的过程中,将对应的超链接放入新的队列或者文件,逐步爬取所有类型对应的作品。
衡量一个网络爬虫的质量,爬取速度是一个很重要的指标,提高网络爬虫爬取速度的策略常见于——多线程爬虫、多进程爬虫以及分布式爬虫。尽管多线程是可以实现并发执行程序的,但是多个线程之间是只能共享当前进程的内存,所以线程申请到的资源是有限的。而针对本系统所需的数据量,并没有使用分布式爬虫的必要,故而在网络爬虫的设计和使用时,主要在基于算法优化的基础上使用进程池实现了多进程爬虫。在实现近1.8万作者及作品数据的抓取中,使用了8个进程对象并行抓取,尽管如此,整个任务也花费了约5个小时之久才完成。
(3)数据处理
数据获取和数据处理往往不是同步进行的,即在通过网络爬虫抓取原始数据时仅将其以初步数据格式存储到文件或者数据库,针对这些数据的缺失、异常、重复等并未做出反应,而将此任务留到了数据处理阶段。
在本系统中,作者以及作品来源两个网站,所以需要对其去重、作者信息对齐;在数据获取阶段,数据的存储格式大多都使用的是Txt格式,而后续构建知识图谱利用Json格式创建,所以在此阶段需要将Txt格式存储的数据转为Json格式的数据;某些作者的信息并不完整,例如作者的名字、作者的朝代、女性诗词作家等,那么就要针对这些特殊情况做特殊处理,不知晓作品的作者名使用“佚名”代替、不知晓作者朝代的使用“未知”代替。
构建古诗词知识图谱的基础和前提就是对古诗词领域的知识进行表示和建模,知识表示和建模的方法和技术有多种。根据W3C标准,通常使用资源描述框架(Resource Description Framework,RDF)及网络本体语言(OWL)对知识进行描述,且两者都使用可扩展标记语言(Extensible Markup Language, XML)作为核心语法。由于本系统依赖的知识图谱的构建采用的是自顶向下的构建方法,以及古诗词领域的知识与知识之间并没有特别复杂的关系,所以使用RDF对古诗词知识进行描述,这些知识都以三元组(主语,谓词,宾语)的形式编码,主语宾语可以是实体和属性,谓词是描述关系,而整个知识模型如下图所示。
在上图中,最外层是古诗词知识的最高抽象——类,如朝代类、作品类型类等等;中间层是古诗词知识的实体层,如李白、唐代等等,实体又包含属性;实体与实体之间通过关系连接,如合称、创作等等。
整个知识模型定义了知识的表示和含义,使用Neo4j存储整个知识图谱就是基于以上知识模型,而整个知识图谱的定义包括实体的定义、属性的定义以及关系的定义。下面两个表分别给出待构建的知识图谱的实体和关系的详细定义,在上图中的白色方框给出了各实体的属性定义。
完成古诗词领域知识图谱的知识模型定义后,就可以在完成数据处理后的数据中进行整个系统的知识抽取和挖掘工作。知识抽取包括三个子任务:实体抽取即命名实体识别、关系抽取即三元组抽取、事件抽取相当于一种多元关系的抽取,由于在数据处理阶段已经将原始古诗词领域的数据进行了初步的清洗和存储,那么知识抽取就相对更容易一些。
如前所述,本系统依赖的知识图谱的知识主要来源于结构化的开源数据集和半结构化的网页数据,针对前者的数据,包含作者姓名、作者朝代以及作品等知识,可利用的知识相对较少,故只需要将其转变成RDF三元组即可。
实体抽取,指的是抽取文本中的原子信息,形成实体节点。从上表可以看出,古诗词知识图谱的实体一共包含8个类别,而这些类别对应的知识都已经在网页中显现地表示了,所以完成实体抽取并不需要利用一些抽取模型而仅使用数据处理技术就可以完成实体抽取工作。
本系统依赖的知识库比较庞大,数据获取和处理阶段花费了大量的时间,而且仅仅完成了实体和关系的抽取,由于时间原因,作者、作品以及名句的很多属性抽取工作并没有进行,并且知识挖掘的工作也没有深入进行,后续可以针对此继续进行知识挖掘工作。
知识存储的本质是一个信息存储的问题,属于数据库范畴,本系统的知识图谱存储采用的是图数据库——Neo4j,其仍旧按照实体-关系(Entity-Relationship)模式存储知识。Neo4j是一个使用Java实现的开源NoSQL图数据库,与普通的图处理不同它提供了完整的数据库特性,针对本系统的知识能够有效的存储和查询,查询语言是Cypher,与SQL语言有一定的相似度,操作简单易上手。
在完成数据挖掘工作后,整个知识图谱的知识在本地磁盘都以三元组的形式存储,而在知识存储阶段就是将所有的知识导入到Neo4j的过程,本地存储的三元组,都以节点和关系的形式存入数据库,由于整个知识图谱庞大,在知识的导入过程中会采用多进程并行的模式完成节点和关系的导入。
知识融合是将不同知识源的知识通过一定技术手段和步骤形成一个高质量的知识库,分为概念层知识融合和数据层知识融合,由于知识模型的定义和开发时间问题,此步骤并未进行。
知识检索作为知识图谱最简单的应用之一,主要目的是根据某些条件或关键词,通过对知识图谱进行查询,返回信息。在本系统中,知识检索主要依赖于Neo4j专用的查询语言Cypher完成一系列的知识检索任务,这些任务主要包括在知识图谱构建过程中使用知识检索检验导入知识的效果、在答案生成模块中使用槽值填充后的Cypher语句完成相关知识的检索。
知识推理则是基于知识图谱各个子图中的实体链完成推理,例如,在查询某句诗写于某一朝代时,可以首先查询该句诗的作者信息,然后获取该作者的朝代知识,则可以完成诗句到朝代的推理。
问答交互模块就是系统前端展示模块,是与用户最贴近的一个模块,该模块以Web网页的形式完成用户与本系统的交互。问答交互模块包含系统注册与登录、知识图谱展示和问句答案展示这3个子模块,在项目的综述篇以及展现了后两者的设计,这里仅展示注册与登录的设计。
用户注册系统而系统验证用户登录。系统注册界面的设计如下图所示,系统登录界面的设计与其相似。值得注意的是,该界面相对于目前互联网的模式并不是很美观,而且采用的Bootstrap前端框架也相对落伍了,学过vue框架的可以在此基础上设计或者更改,从而使其更加完善和美观。
为了能够使用户在注册过程中快捷、正确地输入相关信息,那么系统需要在交互的过程中提供一系列的反馈。例如当用户输入的邮箱不符合格式时显示出错信息、当用户输入错误的验证码时提示验证码错误信息、当用户注册的密码不符合字段要求时提醒正确的格式等等,最后用户完成注册就可以选择登录系统进行问答。
自然语言处理(NLP)主要包括自然语言理解(Natural Language Understanding, NLU)和自然语言生成(Natural Language Generation, NLG)两个部分,在本系统中,问句解析模块主要是完成NLU部分的任务。对于自然语言输入的问题,需要理解问题问的是什么,是在问一个词语的含义,在问查询某项智力知识,在问检索身边的生活信息,还是在问某一些事的发生原因等等,而在本系统中就是要理解用户输入的问题到底是关于古诗词领域哪一个方面的知识,是关于作者信息、作品内容还是名句关系等等。
本系统的问句解析模块包含两个子模块——意图识别与问句分类和命名实体识别,将用户的问题传递到这两个子模块,会输出类型标签和命名实体,而这两个内容对答案生成模块又十分重要,以下对这两个子模块的构建流程、设计和功能进行详细阐述。
在问答系统这一具体应用中,NLU的主要任务是识别用户真实问答意图、问答信息词抽取以及一些基础的NLP特征抽取,从而为后续的模块提供服务,用户意图识别和问句分类主要是完成NLU部分的功能。系统处理模块将用户的问句传递给该模块进行解析,从而得到用户的意图和该问句的类型,而用户的意图可以是询问事实型问题、是非型问题、对比型问题以及闲聊型问题,每个意图都会对应知识图谱中的不同知识,详细对应下图所示。
当识别出用户的意图后,会继续解析出该问句属于哪一种类型,例如在本系统中,需要分析出用户是在咨询作者的信息还是在咨询作者的作品,在回答这些问题时就需要设计不同的问句类型,其中事实型问句设计如下面第一幅图所示,是非型、对比型和闲聊型问句的设计如下面第二幅图所示。问句的类型一共分为43类,涵盖上图的四个意图类型对应的问句,例如问句类型author_1、work_1和fs_1都是询问事实问题,问句类型中的后缀1-4代表了以上4种意图,而前缀则代表了每一种问句所属的类型。
意图识别和问句分类可以看成一个多分类任务,本系统的问句类型达到了43种,可以采用分类模型来实现问句分类。随着神经网络研究的不断成熟,一些基于神经网络提取文本特征的方法涌现出来,例如使用CNN、RNN等网络结构自动获取特征表达能力,去掉繁杂的人工特征工程,从而端到端地解决分类问题。
在问句分类任务中,本系统采用具有代表性的分类模型FastText,其核心采用层次Sorfmax方法以快速地进行模型的训练和预测,在多分类任务中表现优秀。FastText模型本质上是对word2vec中的词袋模型(CBOW)的改进,并配合一个预训练好的线性分类器使用。使用FastText模型,首先需要准备针对古诗词领域设计的43类问题的原始数据,并经过一系列流程生成模型数据集,最后完成模型的训练。完成模型的训练后,就可以利用FastText意图识别与问句分类模型对输入的问句预测其分类标签,并传入到问句生成模块完成后续的操作,整个FastText问题分类模型流水线如下图所示。
(1)模型数据准备
FastText具有两种工作模式:监督模式和非监督模式,在监督模型下,FastText可以通过对已标注语料的训练和学习来执行情感分析等文本分类任务。在本模块内,使用有监督的模式训练FastText问句分类模型,训练的第一步就是准备训练数据。
由于缺乏古诗词领域的开源问句语料库,在问句语料的设计上,采用了国内的语言大模型生成——讯飞星火、文心一言以及通义千问。43类问句,每一种类型的训练数据量均在700条左右,整个训练语料库的数据量为近4万条。
从上图可以看出,当对大模型生成的数据进行数据清洗后,需要对所有问句完成分词。分词几乎是每一个中文NLP任务的必经阶段,将句子拆分成词粒度的语义单元,供后续的NLP使用,主流的分词工具有jieba分词、哈工大的pyltp、Hanlp、清华的THULAC分词、中科院的ICTCLAS等,针对本系统在模型训练阶段和模型预测阶段使用的分词工具都是Jieba分词。
由于原始的Jieba分词字典并没有包含古诗词领域的名词,所以必须根据一定的策略生成用户自定义词典。例如,根据诗词作家的作品数量由多至少排序,生成topN个作者名字的词典;根据作者的诗词热度排序,生成topN个作品标题的字典;将所有的作品类型都加入自定义词典中。完成自定义字典后,就可以对古诗词领域的问句以更加准确的粒度完成问句的分词,但值得注意的是,在问句分词阶段,由于问句的长度比较短,如果采用去掉停用词后再进行模型训练的话,会导致模型的预测效果下降。因为去掉停用词后问句针对模型的潜在特征会有所减少,所以所有的问句均以未过滤停用词的模式完成分词任务。
待分词任务完成后,需要将语料库中的所有语句转换成FastText类型的文本格式,其格式如图下图所示,然后再将这些数据按比例生成训练集、验证集和测试集,其中训练集近3.2万条,验证集近3500条,测试集近4000条。
(2)模型训练与预测
完成前序步骤后,就可以着手进行模型训练了,而此阶段最重要的任务就是完成模型参数的确定,下表给出了使用有监督的模式训练FaxtText模型的参数解析和参数设置。
命名实体识别(NER)是指从非结构化的文本中识别出符合定义的实体,并将其分类到某个恰当实体类型中。在基于知识图谱的问答系统中,命名实体识别在构建知识图谱的实体抽取环节和问答的问句解析环节处于同等重要的位置,目的是从文本数据中抽取出目标实体,这些实体的类型包括人物、机构、地点等等。
命名实体识别是NLP任务中典型的序列标注问题,本环节的命名实体识别任务采用预训练模型BERT完成,其整个任务的流程如下图所示,总体任务经历数据准备、模型训练和模型识别三个步骤。
(1)模型数据准备
系统架构可以看出,BERT命名实体识别模型的数据来源与FastText意图识别和问句分类模型数据来源相同,均来自语言大模型生成,而完成本问答系统的命名实体识别任务需要确定命名实体的类型和数量,下表给出了本系统中古诗词领域的命名实体设计。
确定好命名实体后,需要完成训练数据标注后才能够进行模型微调,在前一个子模块使用了近4万条训练数据,而在命名实体识别子模块仅对古诗词领域相关的近2.7万条数据做了标注,标注工作在开源平台label-studio完成,标注过程如下图所示。
(2)模型训练与实体识别
模型训练任务在云服务器上完成(后续会在实践篇详细讲解),训练完成后将模型参数保存到本地,在实体识别过程中调用预测接口,将用户问句中的命名实体识别出来后,以字典的形式传递到答案生成模块。
从技术研究的角度,问答系统的答案生成往往是指使用自然语言生成,将检索出来的知识生成一段对人们友好的语言文字,最好能够根据用户意图和知识内容生成情感丰富、表现能力强的文字片段。答案生成模块,属于自然语言处理(NLP)领域的自然语言生成(NLG)部分,该模块的功能就是生成用户的问句在知识图谱中对应的答案。
知识图谱问答的关键在于把用户的自然语言问题转化为机器可以理解的形式查询,意图识别与问题分类模块将用户的意图和识别出的命名实体一并传递给答案生成模块,在本模块就可以利用以上两类信息,将用户的问题转换成机器可以理解的查询并生成对应的答案。由前所述可知,整个古诗词知识图谱领域的知识都存储在Neo4j中,在本阶段就需要使用图查询语言Cypher完成知识查询。
Cypher查询属于知识检索的应用,如上文所示,本系统一共设计了43种问句类型,涵盖面涉及作者、作品、名句和合称等等。为了能够在古诗词知识图谱中查找问题的答案,就必须利用问题中的命名实体填充Cypher语句,并将其传送到Neo4j获得对应的知识,由于问题的种类比较多,仅展示部分Cypher语句模板,如下所示:
(1)作者类问题
“match (a: Author{name: ‘%s’}) return a.dynasty, a.gender, a.work_cnt ” % author
(2)作品类问题
“match (wc: WorkContent{title: ‘%s’}) return wc.author, wc.dynasty, wc.content ” % title
(3)作者的作品类问题
“match (a: Author{name: ‘%s’}) - [r: create] -> (w: WorkContent) return a.work_cnt, w.title, w.content ” % author
(4)作品的类型类问题
“match (wt: WorkType{name: ‘%s’}) <- [r: type_is]- (wc: WorkContent) return wc.title, wc.author, wc.content, wc.dynasty” % work_type
(5)某朝代的某作品类问题
“match (wc: WorkContent{dyansty: ‘%s’}) - [r: type_is]- > (wt: WorkType{name: ’%s’}) return wc.author, wc.title, wc.content” % (dyansty, work_type)
对于一个问答系统,根据用户问句获取数据库中的结果之后,需要对结果进行一定的改写,让回复更加自然,由于问答系统依赖的知识库仅仅来自古诗词领域,所以针对其它领域的问题知识图谱无法返回对应的知识,这时仅返回兜底回答即可;当能够返回“正确”的知识时,需要提取问句的特征,然后结合返回的知识和问句特征对答案进行话术包装,最后才将话术包装的答案返回给用户,使得整个问答更加生动化、智能化。其中,最基础的是在返回给用户的答案中添加回复前缀,本系统使用了32个答案前缀,然后结合具体问题返回具体的答案,答案前缀的设计如下图所示。
本篇章主要围绕基于知识图谱的古诗词问答系统的设计,展开了详细的分析和论述,在本章的各个小节分析了整个系统的架构以及5个模块的具体设计。其中,在给出系统架构的同时也对各个模块之间的数据交互进行了模式设计;在系统处理模块中,主要给出了系统注册与登录的后端设计,而前端设计在问答交互模块做了详细的阐述,同时在模块中也给出了知识图谱和问句答案展示的设计;古诗词知识图谱是问答系统的“大脑”,在该模块中,主要围绕着知识图谱的技术体系和构建流程作了充分的设计;问句解析模块主要完成两个任务,一是意图识别与问句分类,二是命名实体识别,两个任务都涉及模型流水线的一系列工作,在该小节对其做了模型训练流程的设计;在最后答案生成模块,主要提出了Cypher语句槽值填充的设计与答案话术包装的设计。
由于个人能力和精力有限,在系统设计中难免存在诸多不足之处,例如,前端实现框架落伍、古诗词知识量较少、模型效果欠佳等,所以有兴趣复现的同学、朋友们可以基于此发挥自己的想象,从不足点继续完善系统。
最后,欢迎对该项目感兴趣的同学、朋友们,就本文系统设计的内容与我交流、探讨,就本文的不足之处不吝赐教,同时也欢迎在本文的基础上继续扩展和创新。
① 邵浩,张凯,李方圆等. 从零构建知识图谱: 技术、方法与案例[M]. 北京:机械工业出版社,2021.
② 李志明,孙艳,何宜昊等. 融合类别特征扩展与N-gram子词过滤的fastText短文本分类[J].小型微型计算机系统,2022,43(8):1596-1601.
③罗柏荣. 基于改进fasttext的中文在线评论情感分类研究[D]. 华侨大学,2023.
④蔡维奕. 基于BERT-BiLSTM-CRF古籍文献命名实体识别[J].湖北科技学院学报,2024,44(03):151-156.
注:由于参考的文献较多,不再逐一列举,若有侵权,联系立删。
其余篇章
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。