写在前面主要是为了考研复试回忆以前做过的比赛项目。当时做的时候就对这块知识囫囵吞枣找了篇综述看但是看得云里雾里。试图对该知识建立起一个初步的体系并且复盘当时项目的做法与合理性。项目来源第十五届服务外包国赛A类【A11】——基于课程教学数据的实时内容推荐和个性化智能问答系统设计。当时看理解是基于给的数据建模知识图谱设计智能问答系统。但是现在回过头看还需要推荐系统、分布式调用意味着需要C-S架构提供服务器端这个确实是很有难度了。Part1 知识图谱概述知识图谱涉及很多知识点涉及的学科也很多学起来很乱。但最基本的概念是实体、属性和关系。因此从知识图谱的研究内容入手可以分为以下部分。知识图谱表示用什么东西来表示知识图谱。知识图谱根据使用场景和应用需求的不同可以采用有向图、有向标记图、本体描述语言等方式在逻辑层面进行表示。物理层面研究上述逻辑表示的数据模型主要包含属性图、RDF 图模型、OWL 本体语言等。而随着神经网络研究的兴起基于向量的表示方法因为计算高效等特点也被广泛使用。知识图谱存储如何存下知识图谱的表示用什么来存在知识图谱表示的基础上可以利用传统关系型数据库和原生图数据库实现知识图谱存储和检索。知识图谱构建怎么从数据中构建知识图谱知识广泛存在于自然语言文本、半结构化以及结构化的数据中知识图谱构建主要目标就是研究如何利用实体识别、关系抽取等信息抽取技术从自然语言文本中抽取实体、属性、关系、事件等知识图谱要素的方法以及属性补全、实体链接、实体对齐等知识图谱扩展和融合方法。知识图谱推理知识图谱的作用之推理。知识图谱不仅可以提供知识的存储和检索更重要的是可以根据构建的已知知识进行归纳、推断和预测未知的事实。知识图谱推理的研究主要基于符号逻辑和表示学习实现演绎、归纳、溯因、类比等类型推理。知识图谱应用知识图谱可以用来干什么在构建了大规模高质量知识图谱后可以将知识与不同的自然语言处理任务进行深度融合构建基于知识图谱的智能推荐系统、基于知识图谱的智能问答以及知识增强的自然语言处理算法。一、知识图谱表示知识图谱表示方法分为符号表示和向量表示。符号表示中有属性图、RDF图、OWL本体语言等。而向量表示的方法有很多比如TransE、TransR等方法。1.1 符号表示属性图是一种有向的带标记的图包含三个元素节点对应实体、边对应关系、属性。这里的绿色圆圈如员工是概念而到具体的属性图中会用比如说姓名等来替代。就好比类和对象。基于该属性图工业界常用图数据库Neo4j来实现存储。资源描述框架RDF、RDFS、OWL资源描述框架RDF是由国际万维网联盟 W3C 制定用于描述实体/资源的数据模型。RDF 的基本组成单元为一个 SPO三元组 主体Subject谓词Predicate客体Object用来表示一条客观世界的逻辑描述或客观事实比如梅西是足球运动员。。然后多个三元组首尾相接就形成了一个图。但这个图的弊端是无法分清楚概念和对象的区别。资源描述框架模式 RDFS定义了Class用来描述类Domain表示属性属于何种类别Range用来限制属性的取值subClassOf用作描述类的父类subProperty则描述属性的父属性。是对 RDF 图的扩展。OWL语言则是对RDFS的拓展。1.2 向量表示随着文本向量化的发展深度学习模型将文本映射为低维稠密向量那么这种方法就是将知识图谱中的知识也用向量表示。简单介绍下 TransE 模型。TransE从 CBOW 和 Skip-Gram 的文本向量化模型中发现了词向量空间存在平移不变现象。模型可以捕捉一些词的相对关系。比如 man 的词向量减去 woman 的词向量约等于 king 的词向量减去 queen 的词向量。该模型将关系看做是表示空间的平移就是说一个向量实体加上一个关系会等于另一个向量实体。那么这样就组成了三元组很多的三元组就会合成一个知识图谱。二、知识图谱存储知识图谱存储到计算机上一般有两种方式表方式和图方式对应的就是用关系型数据库MySQL等和图数据库Neo4j等。2.1 基于表的存储用表的形式存储也即用关系型数据库存储至于如何存储主要分为四种存储方式。基于三元组顾名思义按三元组为一条记录进行存储。比如一条记录为 梅西是足球运动员 。这是最简单的存储方式但是当用到复杂的查询时需要大量的Join操作代价十分昂贵。基于属性表对实体进行分类并将属性进行归类。简单来说就是按照实体把相关的放到一张表去。感觉和日常设计数据库是差不多的但是这样的缺陷是一张表可能存在很多空值造成存储稀疏。基于垂直表属性表是按照实体分类那么垂直表示按照谓词分类将属性归类。缺陷是不太好查询。基于全索引将一个三元组里的实体和谓词全都映射为数字然后对三元组的全排列分别存储A336A_3^36A33​6种。映射因为存储数字比字符串空间更小而全存储相比三元组表存储显然更有优势但是维护起来成本比较高。2.2 基于图的存储用图存储的知识图谱更加直观。工业界一般使用 Neo4j 来进行存储。关系型数据库如果要进行多跳查询那么会有大量的连接操作这样的效率是很低的。图数据库与关系型数据库的不同就是它的存储就是按照实体和关系进行存储连接的。可以创建不同的概念即不同的类别对于每个概念可以创建许多实体实体又可以给予它相应的属性。对于下图的 neo4j 数据库来说“《上邪》”就是概念“著作”的实体描述、时间、评价就是该类别的属性。其类似于关系型数据库的属性表存储不同的是你可以用关系将不同的实体进行连接而关系型数据库无所谓实体连接只有查询时表与表的连接。用图数据库存储只需要找到所需的实体再用连接的关系进行查找即可找到答案相比关系型数据库更加直观也更加方便。Neo4j 数据库的简单介绍Neo4j 由节点和边组成相应的代表知识图谱中的实体和关系。该数据库支持为节点打上标签即给实体添加属性。并且显然组成的图是有向图也可以从图中看出三元组的形式。Neo4j的查询是Cypher语言这是一种描述性语言用户只需要声明“查什么”而不用关心“怎么查”。Cypher语言与SQL很相似但是Cypher关键字不区分大小写属性值、标签、关系类型和变量则区分大小写。当然用起来的时候其实用不着写Cypher用相应的高级语言与查询语言映射库就可以了项目里用的是py2neo。三、知识图谱构建该部分关心的是知识图谱的数据来源并且如何构建知识图谱。并且构建途中还存在着属性抽取、实体链接和实体对齐的问题。3.1 数据来源构建知识图谱最简单的方法是人工构建用不同的专家知识进行构建。数据的来源可以分为以下三种结构化数据来自于关系型数据库可以直接将某些字段解析为实体和属性。半结构化数据有一部分可以根据规则解析。比如维基百科的网页右边的部分就包含了大部分可以直接使用的实体和属性。非结构化数据即纯文本数据。而大部分遇到的都是这样的数据。因此需要获得实体关系和属性。需要运用NLP中的命名实体识别NER关系抽取RE属性抽取AE等技术。3.2 属性抽取类似于命名实体识别将任务转换为序列标注任务。不过还需要考虑标签数量巨大以及非封闭世界假设的问题。该任务的解决方案有基于属性理解的属性抽取方法AVEPT。3.3 实体链接主要考虑两个问题实体的歧义性比如“苹果”可能指水果也可能指苹果公司和实体的多样性同一实体的不同表述比如一个人的名字可以是全名、小名、英文名、缩写这些都指同一个人。解决方案有端到端的实体链接方法ENEL同时建模实体识别和语义消歧的任务避免了分别建模的错误传播。3.4 实体对齐主要研究表示相同含义的实体之间的对齐比如几种不同语言表示的知识图谱的对齐。解决方案有基于平移的实体对齐方法MTransE基于图神经网络的实体对齐方法GCNAlign等。四、知识图谱推理基于知识图谱的知识推理旨在从图谱中已存在的关联关系或事实推断出未知的关系或事实。推理得到的知识又可以反过来丰富知识图谱为下游的应用提供更好的支持。由于我现在了解到的知识图谱经常与大模型结合而大模型具备了推理能力因此这一部分仅简单了解了一下。主要方法有基于符号逻辑的知识图谱推理。该方案中主要有本体推理、Datalog推理、产生式规则推理。有部分其实和离散数学中的逻辑谓词可以进行的推理是相同的。基于表示学习的知识图谱推理。该方案中主要有基于神经张量网络NTN进行知识图谱推理的方法、基于复空间关系旋转的知识图谱推理。五、知识图谱应用知识图谱的应用主要是问答主要分为语义解析和信息检索的方法。5.1 基于语义解析的知识图谱问答将自然语言组织的问句转化为知识库可以识别的结构化查询语句然后在知识库中查询得到答案。而这个问句到结构化查询的映射可以通过规则定义的模板或者训练过的自然语言解析器来完成。语义解析可以分为短语检索、资源映射、语义组合和逻辑表达式生成这四个步骤。短语检索用于识别出问句中的实体、关系等各种短语。资源映射的目标是建立问句和知识图谱之间的映射这包括实体链接、概念匹配和关系分类。将问句中实体、关系和知识图谱中概念相匹配后还需要做句法分析、组合模型训练等工作。最终组合生成一个可执行的逻辑表达式比如SQL语句然后在知识图谱中获取最终答案。5.2 基于信息检索的知识图谱问答通过对问句中的实体和关系识别锁定问题的主题实体然后根据主题实体得到知识图谱中的候选实体最后对候选进行排序得到最终答案。随着深度学习技术的成熟深度学习技术也开始在知识图谱问答中广泛应用用来提升语义解析和检索排序方法的效果。这里主要介绍一下信息检索的方法深度学习的方法有多列卷积神经网络的知识图谱问答与EmbedQGKA算法。信息检索主要有四个步骤问题图构建、主题图构建、特征生成、关系映射。问题图构建这一步将自然语言问题转换为结构化的图表示捕捉问题的语义结构。个人理解有点像意图识别。比如问题“What is the name of Justin Bieber’s brother?” 则可以将其建模为下图可以表示依存关系。主题图构建这一步是从知识图谱中检索与问题相关的子图。设计特定算法来找到知识图谱中的特定子图。比如找到了如下的图特征生成该步骤目的是为问题图和主题图生成对比特征用于关系映射。通常需要构建人工特征用于表示问题与答案之间的关系。对于该例通过问题图中边 prep_of(qfocusname,brother) 可以提取以下特征qfocusnamebrotherqfocusname|brotherqfocusname|prep_of|brother。源节点目标节点源节点|目标节点源节点|关系|目标节点候选答案特征一个节点的关系和属性对区分答案非常重要对于一个问题对应的主题图提取每个节点的所有关系和属性作为特征。然后将问题的一个特征和候选答案的一个特征组合在一起这样可以捕捉问题模式和答案节点之间的关系。例如问题-答案组合特征qfocusname|node_typeperson。关系映射该步骤是将问题中的关系映射到知识图谱中的具体关系路径得到最有可能为答案的路径。即构建知识图谱中的关系与自然语言单词之间的映射发现问题所对应的关系。Part2 项目相关复盘回忆一下当时的情景没学过机器学习、自然语言处理对知识图谱的知识为零仅有一些零碎的对算法和模型的了解对问答系统的了解基本为零。一开始是不知道怎么做的指导老师指导过后也是云里雾里不知道从哪里着手。做项目的过程中也是不断优化思路推倒重来了两三版设计路线。设计思路整个系统的完成很宏大当时也不知道知识图谱有啥用和问答的关系是什么。但是比赛明确提出的技术指标来看一个重点是知识图谱构建一个重点是问答系统反倒是推荐系统没有强调。正如前文所说不太清楚知识图谱的用途但经过调研之后得出的一个显然的结论是可以作为知识库。至少可以根据给出的数据集建立起知识图谱。那么串起的一条线就是构建知识图谱根据知识图谱提供的信息来对用户进行回答由于已经碰到足够的问题了所以在下意识里接下来的思路都是基于单轮对话的。确定了大致思路那么就可以细分问题了。当时没有现在这么清晰很多都是做到那一步了才发现问题然后回过头来重新调整用什么表示和存储知识图谱怎么构建知识图谱用什么样的规则构建用户提出问题后怎么进行意图识别怎么根据问题来进行查询查询获得答案后仅回答答案吗要不要用自然语言生成如果要怎么生成下图是几乎最后一版思路接下来根据每个问题进行具体分析与实现。问题1知识图谱表示和存储当时不甚了解知识图谱还能用关系型数据库存储但是想着既然是图谱那么可视化之后的图应该很重要一定要体现出实体、关系和属性之间的联系。简单调研之后发现用的比较多的是 Neo4j既然用的多那么讨论和资料就相对多遇到问题有办法去查。冷门的技术如果遇到问题都不一定能解决。Neo4j 作为一个数据库具备增删改查的功能查询-回答的基本问题已经可以解决那么要解决的就是如何设计数据库内容了。问题2知识图谱构建 问题3查询意图对应该赛题的主题是中华传统文化不可避免的会碰到文言文之类的东西。如果一些大众的领域可以去 OpenKG 上一些开源的知识图谱寻找。这个主题当时团队找了一会发现不太容易找到所以直接从零开始了。数据初步清洗要构建图谱首先需要明确给出的数据集。该数据集很杂乱内容里包含 html 标签无法直接使用。字段也包含很多目录、题目类型、题干、答案、解析、难度、选项等。可以明确的是除了数据清洗数据中还包含很多空值需要进行舍弃字段或者知识补充。当时也没有具体的思路只知道先把数据清洗出来。团队讨论后分工进行清洗。html 标签清洗很容易写正则表达式就可以解决。获得文本数据后清洗过程中遇到很多问题题目类型不同导致无法用一个pyhton程序进行清洗。而考虑到如果对于一个知识要问的话不一定是仅考虑数据集里的填空题形式的比如说第五行填空题“己欲立而立人___ ”到时候问的时候完全可能是 “ ___己欲达而达人”。但这两种必定是同一种知识因此索性清洗的时候就直接将答案填充到题干里去把问句全部变成陈述句到时候再根据相关规则进行建图谱。经过清洗后数据大概会长这样规则建立探索最初的想法是一切从简按照流程问啥从知识图谱里找啥但怎么找是个问题首要的就是意图识别。比如说用户问一个“床前明月光”的下一句就不能给这一句进行翻译而是要给出后一句。其次是怎么找的问题给出自然语言文本怎么定位到知识图谱里去。这两个问题按照理论里对应着上文的短语检索和资源映射。因此大致的问答方法应该是对应着基于语义解析的知识图谱问答。按照流程需要对问句进行命名实体识别、属性抽取和关系抽取然后对应到建立的知识图谱上。但问题是当时的命名实体识别模型就算有也处理不了古文的内容。这意味着需要自主标注数据并训练模型使得可以处理古文的内容。而且谁也说不好到底怎么识别好比如“学而时习之”这里有两个文言虚词如果按照单字进行识别工作量大不说效果也未必见得好。先找出可能会包含哪些类型的问题。人工初筛后大概获悉有问古诗词的来源、前后句、作者、翻译、默写对传统文化知识的提问比如对《史记》的评价孔子是哪一派别的人物之类的问题。从命名实体识别的角度来看客观事实类的就用得上常见模型比如说可以建模出“人名”“著作”之类的实体而文言整句就无从下手了。因此将这些问题分为两类一类是难以建模的文言类另一类是客观事实类。这一步其实是建立不同的子图过程。基于该思路制作的demo中问答根据规则而对应到不同的问题类别中去从而实现系统功能。实体关系构建前面提到将问题分类就是因为实体不好一劳永逸因此每类问题的实体和关系以及属性需要自行探索并且为了训练模型团队还需要进行人工标注。首先确立一个概念“题目类型”里面存在两个实体文言类和事实类。再按照两个类型进行实体细分其他实体与该实体之间的关系为“题型”。文言类按照上图题目类型包含上下句、来源、作者、翻译、原文填空。每个类别的实体和关系不相同但是属性可以相同属性均含有 [作者、来源、注释、翻译] 注释是对其的评价等内容因此有很大一部分实体该属性为空值实体[分句、全句] 关系[上一句、下一句、部分] 。该类问题思前想后单个字或者像大模型那样token拿出来组合并不合适因此直接按照句子建模即完整的句子作为一个概念其中的每一个分句作为另一个概念。那么显然句子之间的关系有前一句和后一句的关系分句属于整句因此有“部分”的关系。而每个实体均有 [作者、来源、注释、翻译] 的属性可以用来解决来源、作者、翻译的问题。而天然的就能解决上一句下一句的问题。还剩一个句中填空的问题如果可以对应到具体知识的分句那么按照这样规定的实体也可以解决问题。事实类事实类问题的特点就是杂概念繁多。经过了解数据以及常见的实体识别“人名”、“地点”之类的实体很轻易就可以得到而经过对数据的讨论和标注后下图中除了文言类之外的实体和关系均属于事实类。为了得到上图的结果接下里的工作就是对数据进行标注。团队用的标注工具为 Label Studio。下载python库即可标注。知识图谱构建标注完成后获取到数据集稍加调整获得相对规格化的数据。接下来能做的工作是训练命名实体识别、关系抽取模型以及构建知识图谱。该过程中如果仅利用 neo4j 提供的可视化平台 Neo4j Browser 来写 Cypher 语言存储数据就有点效率太低了。因此同样借助于 python 虽然 py2neo 库在21年已经停止维护不过对简单的需求应该问题不大。团队使用py2neo 构建知识图谱。有了规格化数据这一步便不难。当然中间的摸索过程和 demo 运行免不了一番功夫。练模型做优化训练命名实体识别和关系抽取模型便于在用户给出的问题中提取相关的实体和关系。但事实情况是这一过程异常艰难并且时间有限。最后只训练出了命名实体识别模型使用模型为 RoBERTa 。说实话效果其实一般般。但是当时已经过去好久了距离比赛结束已经没有很充裕的时间了。没有办法回到数据构建重新考虑。因此必须考虑一种保底的算法来获取实体和关系。由于已经对问题进行分类因此想到按照关键字匹配来对应问题。这样考虑其实已经省去了关系的查找只需要获得实体并对应到图谱中就可以了。打个比方说如果问题是作者问题那么问句中会不可避免包含一些关键词“作者”、“谁写的”、“作家”等那么到这里就可以建立出几种问题的关键词。然后根据检索到的关键词分类问题制定回答的制定模板就可以实现问答。接下来只需要获取实体。最简单的方法获取一个实体列表存在内存里里面包含了所有的实体。对问句进行循环查询实体是否在问句中出现。但这种方法的弊端显而易见循环的次数很多耗费的时间几乎不能忍受。因此想到了字符串匹配算法用 AC 自动机进行模式匹配。Python 中也包含了实现AC 自动机的库团队用的是 ahocorasick。以下代码给出了一个简单的例子。importahocorasickdefmake_AC(word_set):ACahocorasick.Automaton()foridx,wordinenumerate(word_set):AC.add_word(word,(idx,word))#第二个参数为击中返回的结果AC.make_automaton()returnACdefac_entity(word_list,sentence): ahocosick自动机的意思 可实现自动批量匹配字符串的作用即可一次返回该条字符串中命中的所有关键词 AC_KEYmake_AC(word_list)name_listset()foriteminAC_KEY.iter(sentence):#将AC_KEY中的每一项与content内容作对比若匹配则返回name_list.add(item[1][1])name_listlist(name_list)name_list.sort(keyword_list.index)#if len(name_list) 0:#print(sentence, ---命中的关键词有, \t.join(name_list))returnname_list sentence夫运筹帷幄之中决胜千里外吾不如子房填国家抚百姓给饷馈绝粮道萧何连万众战必攻取韩信这句话出自哪里wordac_entity(fenju,sentence)#fenju是对应的实体列表 输出结果为[夫运筹帷幄之中, 决胜千里外吾不如子房, 填国家抚百姓给饷馈绝粮道萧何连万众战必攻取韩信] 运用该算法可以较快获得句子中想要的实体还剩下最后一小类问题就是句内填空如何根据“__而实习之”获取“学而时习之”呢既然都用了模式匹配了那联想到字符串的匹配用模糊匹配解决。团队使用 python 库 fuzzywuzzy 解决该类问题。再对各类问题建立各种规则就基本解决了问答。问题4自然语言生成如果仅做到上述这一步虽然也不容易但最后的回答问题就和查表一样简直是个笨蛋机器人团队并不满足于这一点。当然也想过设计多种回答模板每次回答随机取一种回答应对了那句“越人工越智能”。正当无从下手时指导老师发力给出了提示学习的方向团队调研尝试理清逻辑后几乎是对上述思路进行了大改。重新理解问答提示学习是大语言模型兴起之后的一种方式用 prompt 的方式规格化统一了 NLP 任务。当时的 T5 模型比较著名也在论文中提出了 Text-to-Text 的想法。既然都是输入文本输出文本那么问答其实也可以用这样的模型解决。而由于预训练的关系模型本身就具备输出自然语言的能力这样就完美解决了自然语言生成的问题。而且也无须进行模式匹配来进行意图识别模型可以在训练中识别用户的意图更加灵活。同时如果按照上述流程解决该问题那么显然是一个封闭世界假设的问题对于没有在知识图谱里的知识就回答不了。但大模型是预训练微调范式由于预训练的知识领域很广也一定程度上能缓解这样的局面。那么接下来的思路就是制作新的问答数据集对 Flan-T5 模型进行微调。不过又出现了新的问题如果仅仅这样那建立知识图谱的目的是什么整个流程仅需要大语言模型的输入输出而无须经过知识图谱。重新思考后团队将问答系统理解为一个阅读理解的 NLP 任务。完整的来说前一套流程依旧适用只不过目的由直接提供答案变成了提供相应的知识而大模型的任务就是根据给出的知识和问题进行解答。比如说如果问到“学而时习之”的下一句是什么那么经过知识图谱可以检索到的知识为“学而时习之不亦说乎。出自《论语》翻译为…”随后将这些知识贴到问题前将知识和问题一起作为大模型的输入然后由大模型做出最后的解答。流程回溯优化至此系统的总体思路已经完善不过暴露出的许多小问题仍未解决。并且其实做的时候并没有列出来这么清晰上述流程很多都是到这一步才发现并实施的。如何保证问句中识别的实体对应到图谱中相应的实体如何确保主题图构造正确大模型需要微调成本不低数据集需要重新制作。经过大模型后整体等待的问答时长稍微有些长如何尽量缩短等待时间优化策略如下AC自动机所用的实体列表由知识图谱的实体得来其中有许多重复值这降低了效率同时导致有些重复实体没有正确连接也就是没有正确添加关系。因此需要回到制作数据集那一步进行精细去重。这样之后才得到2800个实体。同时在内存中建立字典哈希表存储简单的实体关系从而减少知识图谱的查询。考虑到进行了问题大类的分类建立起两个大类的字典这样能有效减少查询时长。此时如果有些实体在两个大类的问题中均出现那么均取将各自的知识都贴上交给大模型处理。这样就解决了实体链接的问题。模型训练调优由于 Flan-T5 仅支持英语因此团队在 huggingface 社区上寻找变体即mt5支持多语言的T5。有了预训练模型接下来就是准备数据集了。之前的数据需要重新处理由于将任务设置为阅读理解需要先将问题过一遍知识图谱获得知识然后将知识贴到问题前面。获得知识问题答案这样形式的数据。而如何处理问题是根据不同类型的问题经过chatgpt生成获得不同的问法再将所有问题分布到不同的问法中去。最后获得总的数据。至于微调部分基于 transformers 库。但当时并没有了解到 PEFT 高效微调以及 Lora 微调因此是基于预训练模型的基础上进行继续训练的这就要求有足够的显存去存下整个模型。因此最后仅使用了 Large 规模的模型印象里似乎参数数量是 780M。Web应用实现最后一步就是搭建前后端和可视化界面。由于知识图谱和大模型端都是Python因此 Web 端也基于 Python 实现。选择不多Django 比较常用因此基于 Django 实现。需要实现的功能至少是登录注册以及首页推荐的样式起码要有、问答界面、知识图谱展示界面以及数据分析界面。首页登录注册框基础的导航栏加上主体轮播图最后是推荐传统文化样式。问答界面时间有限当时仅做了能够实现一问一答的功能历史记录仅是个样式无法链接。借助了Ajax异步刷新实现。这里的缺陷比较大流式输出也没能实现。知识图谱展示界面主要是将建立的图谱在网页进行可视化其实 Neo4j 自带的会更好。但是移植不过来。因此基于百度开源的 Echarts 做了知识图谱可视化以及实体查询功能。值得一说的是这一步需要实体不重复如果重复就会渲染失败还好前面做了高度去重这一步没花多少时间就调试好了。赛后评委给出了如果换成立体图会更好的建议。数据分析界面主要是词云图以及一些数据的展示。同样使用 Echarts词云图部分使用 python 库 opencv 和 wordcloud。赛后复盘诚然在当时的水平下做成这样已经是非常不错了团队也已经尽了全力。首先按照赛题技术要求对比一下。数据收集与清洗。这个可太完成了超额巨额完成。清洗整理结构化花了非常多的时间在数据上。知识图谱构建。同样完美完成从表示到存储上都完全符合赛题要求。问题匹配与答案生成。从结果上看应该也是完成的比较好。语义匹配和理解技术应该可以包含规则化的理解这一步做到了。对问题进行解析和匹配找到知识完成基于实体找到子图获取所有知识。答案以亲用户形式展示完成并不仅仅包含答案。交互和追问。可以说基本没完成。仅有基本的交互无法进行追问和深入。验证和优化。略这个评估必定是完成了的不完成也得说自己完成了。然而赛题上还给出了任务清单。推荐系统一点没做首页给出了四个推荐框技术文档以及 ppt 中没有一点提到推荐系统。仿佛团队和指导老师都没有看到这一点一样。问答系统问答有了但是未必推理性未必智能。可以作为独立功能运行也可作为服务运行支持分布式任务调用基本没完成。仅有独立功能服务器的负担也不小更谈不上分布式了。总结评价作为复试简单介绍这样进行总结完成了一个基于知识图谱和大模型的智能问答系统主题为中华传统文化。该项目以知识图谱为知识库用 T5 模型作为输出大模型。首先用户提出问题系统会进行命名实体识别和语义解析抽取出相关的实体随后对应到知识图谱中获取相应子图的知识。获取知识后将其传递给大模型大模型依据给出的知识进行具体问答。这样基本可以说到所有的点复试老师如果对其中某一点问起来也可以对应到上文的细节。用现在的眼光来看 对该项目进行评价或者说复试老师提问你这个有什么可以改进的地方从赛题要求上看企业偏向的技术手段为推荐系统RAG生成式大模型。T5 模型虽然在 NLP 任务上表现优异但是并不擅长生成自然语言文本与对话因此从模型选择上就可以进行改进。而知识图谱的作用在项目中作为知识库而知识库就可以使用 RAG 技术将知识进行向量化之后再进行对应比直接字符串查找可能会更好一点同时 RAG 要求的材料也不用建立知识图谱那么苛刻虽然是赛题要求的。至于推荐系统至今还没有进行调研。再者需要进行压力测试等方式优化 Web 端现在粗糙的系统肯定是不能承受很多访问的问答系统的实现也有待提高。深度QAQ1RoBERTa模型训练效果一般是如何一般有没有做量化指标原因是具体是数据量不足、标注质量、还是模型参数或训练策略问题有没有进行过简单的错误分析A1验证的准确率和 f1 值为86.6%和85.1%对于要求很高的企业级项目来说是比较一般的有些数据难免会出现错误。原因可能是因为对古文做命名实体识别我们也不确定思路是不是正确的有些划分可能有争议。而roberta模型应该是在现代预料下做预训练的对古文的效果可能受限。可以尝试用古文对模型做预训练来提高效果。Q2引入AC自动机后系统的准确率和召回率大概是多少怎么做的测评测评的粒度是怎么样的只是看答案是否相关还是逐字核对生成的文本是否严格基于检索到的子图、没有引入外部知识模糊匹配的阈值如何设定的A2当时做过整个系统获取知识的准确率一共几乎5000数据最后有120条左右的数据有误这个准确率可以接受。测评的时候我们对所有数据进行问题的评测然后统计T5回答错误的问题。接下来人工进入数据中查看原因如果是知识没贴好导致的错误那和标答的差别会很大就显然是资源映射的问题。模糊匹配没有设置阈值返回5条有匹配分数的实体取分数最高的那一条。Q3微调mt5时构造的数据集规模有多大微调后有没有在测试集上评估过BLEU或ROUGE指标直观感受上模型“编造”答案的情况多吗A3大概五千条数据评估的BLEU-4指标大概是30rouge-1有50左右。对开放领域生成来说这样的指标还可以但对于文本摘要任务来说稍微有些偏高。直观感受的话模型几乎没怎么编造答案回答的比较准确不过可能对自身内在的知识利用率不大。Q4用AC自动机做实体匹配主要是为了解决NER模型效果不好的问题。但AC自动机只能做“完全匹配”对于“同义词”如“孔子”和“仲尼”或“上位词”如“诗仙”和“李白”就无能为力了。如果当时时间更充裕你们会怎么优化这个问题A4在知识图谱实体定义的时候有定义过“别名”这样的实体在一定程度上有部分缓解作用。但是以现在的思路可以做短文本语义相似度计算用sentence-BERT做向量相似度比较。Q5你提到“流式输出也没能实现”。如果现在要优化这个体验让大模型的回答一个字一个字地显示出来在前端和后端分别需要做什么A5后端需要将HTTP协议从普通的短连接改为SSEServer-Sent Events服务器推送事件 或WebSocket让Django视图可以逐字地Yield模型的输出结果。前端JavaScript则需要通过EventSource API或WebSocket客户端接收这些流式数据并动态地追加到页面上。Q6数据标注过程中知识图谱Schema是怎么样的如何确保数据标注的质量A6实体类型有分句、全句、事件、人名、思想、思想内容、派别、著作、地点等关系类型有上一句、下一句、部分、提出者、著有、内容、来源、事件等。数据标注由两个人完成但只做了初期的一致性检测。从数据集里随机抽了少部分样本大概50条的样子然后做了一致性检测Fleiss’ Kappa为0.8左右就让他们继续做了。然后遇到不确定的或者标注不一致的就交给团队统一处理了。Q7基于NER和AC自动机共同进行短语检索与资源映射是如何共同进行的A7AC自动机可以完全获取预先定义的实体大部分情况下都是与NER的识别结果一致的少部分NER识别结果有遗漏它可以进行补充。但也有些情况是指向同一个东西的不同表述AC自动机无法获得但NER有泛化能力可以识别出这样也可以对应到知识图谱李白李太白。当然还有一种情况NER是获得的实体在知识图谱中无法找到这要不就是知识图谱的数据不够充分要不是NER出现了错误就最后实际使用来看出现这样的情况是比较少的5000条数据120条有误。Q8你这个系统是搭在本地还是在云端的如果在云端有没有做过并发测试A8当时我们还不太清楚上云的流程并且在本地端用cpu推理就比较缓慢了上云之后如果没有gpu实例可能会效果更差因此只有本地部署。不过我认为在云端搭建系统是比较合理的可以基于阿里云或者腾讯云来租借实例和服务器把模型部署在云端前端通过API访问。那么如果搭载云端肯定是要考虑并发性的问题。因此打算对架构进行拆分整体功能选取两个服务器一个搭建web系统用Django支持另一个专门负责大模型推理可以用fastapi封装接口也可以用vllm等方法加速推理。两个服务器之间通过内网http调用通信web端开放公网接口。并且可以考虑加入消息队列的异步处理使用redis和Celery用户请求进来之后先存入redis队列然后worker从队列中拉取任务获得结果后存入数据库前端可以用后端返回的task_id进行轮询或者websocket来获取信息。做完之后考虑用Jmeter进行压力测试然后获得吞吐量和响应时间等指标。Q9怎么保证问答对知识图谱的依赖是必要的而不是模型直接背答案为什么微调的时候是以知识问题答案的形式而不是直接问题答案呢A9当时有做过简单的测试直接用预训练版本的去进行回答基本是答非所问的状态。这说明预训练的时候模型在这方面的知识是很欠缺的。并且从图谱中获取的知识并不是直接可输出的答案而是包括相关的知识这就要求模型理解所问然后简单推理再回答而不是机械回答。另一个简单的小测试是在给模型贴了错误的知识之后它回答的问题也是错误的这能说明模型是依赖知识图谱的知识。两种方法的要求不一样前者是阅读理解任务或者说基于知识的生成任务后者是开放领域生成任务。这两者问题的难度是不一样的由于只能使用相对小参数的模型因此首先考虑的是降低任务难度使得模型可以准确生成答案。其次如果是后者那么知识图谱的构建就难以发挥作用了。最后考虑到解耦的问题如果是后者那么如果训练到了一条错误数据就面临着重新训练模型的问题而且更新知识起来很不方便但如果是前者的话模型只需要学到根据知识回答的推理能力这个能力在不同领域直接可以迁移。并且对于系统来说可以方便地更新知识。