AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


“大模型+知识图谱”双轮驱动的医药数智化转型新范式-OpenKG TOC专家谈
发布日期:2024-07-25 08:42:05 浏览次数: 1732



导读

OpenKG新开设“TOC专家谈”栏目,推送OpenKG TOC(技术监督委员会)专家成员的观点文章。本期邀请到东南大学漆桂林教授、柯基数据CEO吴刚介绍“大模型+知识图谱”方面的一些探索,本文整理自“OpenKG走入通义实验室”Talk上的分享。

本报告介绍将知识图谱与大模型融合的基本方法。一方面,应对大模型目前面临的挑战;另一方面,利用知识图谱技术优化大模型的表现。本文简要介绍了两位TOC专家东南大学漆桂林教授和柯基数据CEO吴刚在此领域开展的初步探索工作。


大模型和知识图谱技术特点及优劣势

上面这个图非常清楚地说明了语言模型和知识图谱均可以作为一种知识库,只不过它们作为知识库的存在形式不一样。我们说知识图谱是以一种显性的图模型结构来对知识进行表示、存储,并方便进行检索查询推理;而语言模型则是以参数的形式对知识进行表示、存储、检索查询。


从上图可以看出,在从知识图谱获取知识的时候,我们一般采用结构化的查询。比如说是一个三元组或者多个三元组的形式,然后去对图谱的节点和边进行匹配,从而把图谱里面的相关知识提取出来。而语言模型则是用提示(Prompt)的方式,以一个自然语言句子的形式去对语言模型进行提问来获取知识。 


从这个角度来看,我们可以从知识工程的角度来看待知识图谱跟语言模型。如果从这个角度去理解他们,我们可以更好地从人工智能的整体观来理解现在以及未来人工智能的发展。语言模型跟知识图谱各自在人工智能的发展过程中可能发挥的作用以及可能的应用。

知识图谱和语言模型这两者的优劣性其实可能很多报告里面都有介绍。比如像语言模型是连接主义,而知识图谱是符号主义。前者是参数化的知识,且是一种概率生成模型,而后者是符号化的知识,且是一种稳定生成模型。他们各自的优势跟劣势相对来说是比较清晰的。

我们知道目前语言模型在很多应用上有非常好的效果,是一个强大的知识库,但如果我们从知识工程的角度来看,在某些任务上面它其实还存在很多的局限性。比如:


1.语言模型输入文本进行训练,那么它会存在一些事实性的错误,即存在幻觉。


因为文本本身可能会有问题,其次就是语言模型从文本学到的知识是通过概率方法实现,那就不可避免会有错误,同时它在定位、存储知识方面可能、、也会有问题。所以我们进行问答的时候,它很可能就会出现偏见、幻觉以及一些溯源能力不强等情况。特别是在领域应用上面,它给出的回答能不能100%的信任,其实是不确定的。


2.专业知识局限性,在专业领域的知识问答方面,我们可以看到很多问题的回答是不准确的。特别是在医药大健康和法律这些领域里面,对于知识的专业性和准确性都是有很高的要求。所以,语言模型在这些领域里面,如果要直接应用是有非常大的局限性的。


3.基于概率的语言模型难以获得高质量的稳定逻辑知识,比如大模型会出现长尾知识的问答和抽取能力不足、逻辑推理能力不稳定等问题。


4.语言模型利用神经网络参数存储知识,如果把语言模型作为一个知识库的时候,它是利用大规模的这种参数来存储知识,这种规模的参数远远超过了知识图谱的规模,这使得它的编辑和更新是非常困难的。


我们把语言模型作为知识库的时候,因为这个知识库不像知识图谱是可视化的,如果要去做查询,返回的结果也不是结构化的回答,而是一句或者一段话。这就很难知道给出来的结果到底是不是准确的。然后,在知识更新的时候也会存在很大的问题,很多时候会把新知识采用外挂的方式去解决一些问题(也就是最近比较流行的RAG,但是这些并不是语言模型本身的知识。人类在学习中会通过知识更新的能力,快速把知识存下来变成人脑知识的一部分,而大模型很难做到这一点。最后,知识的校验也是非常困难的。

我们也做过一些调研和实验,比如在OCR的时候对PDF文件进行版面分析和文字提取,发现提取的准确率并没有我们想象中的那么高,其中包括对Abstract的提取,还有Title的提取和Author的提取等。

我们可能认为现在的多模态大语言模型已经很强大了,但是事实上有些时候对他们能力测试的时候,实验结果并不是我们想象的那么好。比如说,文本的分段提取会有一些问题,而且我们可以看到文本里面做一些关键信息提取的时候,他们可能无法做到非常的精准。还有知识检索,在检索相关的文档片段时,无法确保召回了所有的相关片段,以及对文本片段进行排序也不一定很好。

知识图谱和大模型双轮驱动方法论

接下来,从工程角度来介绍一下我们在医药大健康行业跟企业合作做的一些工作,以及结合知识图谱增强大语言模型在医药行业的一些应用。
这里我们主要是采取了一个双轮驱动的方法,其实我们在很早之前就提出了双轮驱动这么一个框架。那为什么要做双轮驱动这样的应用呢?


我们很多客户自己在刚开始的时候尝试直接用大模型做应用。但是,发现其效果达到一定的准确度后,就很难再提高了。尤其在医药大健康行业,它是个非常专业的领域。所以不少客户在自己尝试之后还是想通过知识图谱来进一步提高它的准确性。


这里的一个核心问题就是企业落地应用,尤其像合规性非常强的行业,比如:医疗行业。他可能会要求回答百分百正确,那怎么解决问题呢?如果说只是通过RAG的方式去提高他的准确性,即使准确性达到99.9%,他都不能去上线。所以这个问题就是你怎么在一个专业领域做到合规、能真正解决他的幻觉问题。还有,我们用的一些大模型它可能会有长度的限制、问答精准度的限制以及知识的冲突,这也是一个专业领域待解决的问题。最后就是要循证溯源,所有答案要很精准地回答到它的源头。从业务角度来看,这些就是我们很多企业客户用RAG的方式做完通用大模型后遇到的问题。所以,我们提出用“知识图谱+大模型”双轮驱动的方式来解决这样的问题。


双轮驱动的核心原理一方面是用大模型来减少图谱构建的成本。比如提高打标签和信息抽取等自动化能力。另一方面是通过知识图谱反过来增强大语言模型来解决它的幻觉问题和循证溯源问题。


但是,我觉得有一个比较重要的部分在于构建知识图谱也是需要成本的。那么,我们怎么在工程领域,在一定的限制的预算范围内将知识图谱和大模型结合起来,发挥出真正的价值这是最大的一个挑战。

上面是去年我们跟工信部标准院一起写的研究报告,介绍的就是知识图谱和大模型的一个双轮驱动。一方面是用大模型半自动化生成知识图谱,另一方面是在大模型中注入知识图谱以增强大语言模型的一些能力。这里我就不展开细讲了,感兴趣的同学可以在网上自行查看。

其实,在企业落地中我们常看到这几种方式。
1.提示工程:通过Prompt得出一些结果,这也是最简单最高效的一种方式。
2.检索增强:目前最主流的一种方式,就是用RAG来做外挂和知识库调用大模型的API


3.微调:就是对一些基础模型进行微调,我们现在市面上看到的一些大模型用的就是这种方式。


4.重构基础模型:这种是成本最高的,比如像文心一言。


目前最主流的方式就是检索增强(RAG),基于外部知识库做检索和内容生成。

它其实是把你的一些文档文献或者一些数据进行向量化,再把你的问题去跟它匹配。这里它是在缺乏上下文的理解,还有领域的业务理解进行的。它在应用上有一定的瓶颈。

针对这个瓶颈,我们希望通过知识图谱方式来增强这个RAG。我们通过离线的方式进行,针对上传的文档做一些向量化的工作。当在线用户提出问题的时候,我们会实时把问题通过知识图谱去做增强。同时,再把问题对应的段落通过知识图谱上下文的语义更精准去定位到它的相关段落。


这里面我们会用到一些传统技术,比如:检索技术、ES技术以及Prompt技术。我们会将这些能力组装成一个部分,再带上我们根据定位的几个段落的文本,还有问题本身的增强,把这些传给大模型去做一个问答。这样,它会回答出更精准的一个答案,是我们现在在做的一个方法。

医药行业数智化

其实,这个方法在医药行业去落地的时候,也遇到不少的挑战。包括图谱的构建也需要成本,专业领域的知识图谱怎么构建,还有运维的能力。知识会动态更新,我们怎么去运维,它才能更好的持续这样一个应用。因为在企业中落地,用户更关注的是每天我的信息过来后,包括用户的反馈等,怎么在一个系统里面以一种高效、低成本的方式去建设和运维更新。
我们回到医药行业,为什么要去做这样的事情,我觉得有两点:


一个是集采就是带量采购,很多药企他的产品过了专利保护期之后,如果他不去开发新药,那它的这个销量可能会减少,可能90%的概率价格要下降。所以,它必须得加速研发新药。


另一个是现在面临的医疗反腐,导致很多代表都进不了医院,所以传统的营销模式也变成了线上的方式去做医生的学术推广和患者教育,这种方式就需要更高效、更自动化。
通过我们在线的一些入口,不管是微信还是其它入口,能为一些内部的医疗销售、医学市场或者外部的医生、患者提供更智能化的服务。这就是目前整个医药行业都在加速做数字化转型,并且加速他的新药研发。


我们在最近几年也做了大量的企业数字化的知识库、Chatbot和各种应用。不管是临床研究情报系统,还是说产品上市之后做学术的推广、患者的教育、面向药店的助手以及销售这种助手等等。

但是,做完之后我们发现是有些问题存在的。一方面是这种传统的系统,虽然我们用了知识图谱、NLP技术去生产内容,仍需要投入大量的人工打标签、构建图谱和生成FAQ等内容,导致成本较高。所以,没有哪个企业能真正构建一个比较全的领域知识图谱。


另一方面是企业级的应用他有非常强的合规性要求,比如医药行业,你做的所有内容都需要再经过人工审核,这也是我们做大模型会面临的一个很大的挑战。幻觉问题在这里可能是不能容忍的,哪怕只有0.1%的幻觉他都不能接受。面对这种强合规性的要求时,也导致它的内容生产相对比较慢,周期比较长。


还有一方面,无论是用知识图谱去做多轮对话,还有个性化推荐和分析,其实没有做到非常好。因为图谱的构建成本比较高,问答应用也需要选大量模板。像我们的KBQA很难在一个工程领域让用户用的很好,他稍微换了一些说法,可能就不一定回答上来,多轮对话能力也是一样。


所以导致整个知识生产效率比较慢,用户体验也不好,智能化程度也不高。做出来的系统很难进行一个非常好的推广。但是,当大模型出来之后,很多客户提到通过大语言模型能否解决这样的一些问题,让内容更加自动生产,还能更智能的交互提升用户的体验

从去年到现在,经过一年半的时间。我们跟几十家药企和其它行业的客户在做各种POC和一些应用落地的时候,打造出来了一套“大模型+知识图谱”的双轮驱动平台。


我们也在通过这样的一个方式,把我们原有的知识库、Chatbot以及情报系统去做一个基于大语言模型的升级,而不是从零开始去做这些应用。


所以我们会基于大语言模型的一些能力结合我们原有的知识图谱平台、Chatbot平台、知识库等服务进行一个整体的升级。目的是用大模型更智能化的生产内容、智能交互以更好的提升用户体验,去帮助企业降本增效,快速搭建一些智能化的应用,真正能给企业客户带来价值。

GraphRAG应用及落地挑战

这是我们在整个企业应用落地的时候的一些驱动力,包括我们之前一些工作上面临的挑战。


那我们怎么去做这个事情呢?其实,我们会把原有的情报系统、知识库和Chatbot,基于“知识图谱+大模型”的能力做到更加自动化的升级。然后,对内对外提供一套统一的多渠道入口,把内部的各种系统也对接起来,帮助他提高整体的服务。这不仅仅是单点做一个算法或者做一个RAG的应用,而是会从端到端提高整体的效率。

我们会搭建一个企业级的知识平台,把原有的FAQ和图谱的能力也结合起来。可能是10%的能力,我们会落到原有的FAQ上面,20%在我们知识图谱的问答,70%GraphRAG上,直接用知识图谱增强大语言模型来生成内容。


但这里面有一个比较重要的点,是用知识图谱协助从原文组装段落出来,再把这个段落当成溯源,形成最终的一个结果。这是完全合规,不会去生成新内容的一种方式。如果直接用大模型去做一些内容生成,很有可能会出现幻觉问题,以及存在一些不合规的挑战。到最后还需要大量人工进行校验,无法提升效率的同时还会增加成本。


所以,我们需要做的是一个端到端的系统,不仅能提高整体效率,还能减少人工的一些工作。同时满足一些合规的要求,再加上我们大模型的一些智能化的能力,比如:写作能力、总结能力还有对接不同私有模型、API的能力。在这里,我们会把知识图谱放在里面,作为整个知识库的一部分。

举个例子,比如用户问:“刚出生的小孩儿可以接种肝炎疫苗吗?”可能知识库里有1000份的指南文献,可能还有很多临床研究的信息,还有可能存在数据库的这种知识。一般理解可能会把这个问题带上一个Prompt直接传给大模型去回答,但是在一些专业的领域,通用大模型是很难回答出准确的结果的。因为,他没有这个行业的知识语料,导致他定位到段落,包括段落召回都没有那么准确。


所以,我们在这样一个场景下,首先要对问题本身用大语言模型做意图识别,再通过知识图谱去增强它,然后用这个增强后符合逻辑的问题,到海量的文献里面定位到它相关的段落,这是一个方向。第二个方向是用向量检索做匹配,就是把增强的问题做向量化,去和之前已经向量化的知识库中的海量文档进行匹配。向量化匹配可能是3个文档的6个段落,那我用知识图谱去做它的ES检索或者段落的召回,可能是5个文档的10个段落。可能中间这两者还有一些重叠的部分,也有可能我这两个方式做出来的是6个文档的15个段落。那这个时候其实我们不会直接在这个15个文档里面去做问答。我们在第一步为了给用户传递一个最合规的答案,会在右下角通过大语言模型对15个段落进行排序,筛选出最相关的10个段落。然后再通过我们的逻进行排序,形成一个由原文组装的答案出来。这个答案可能就是完全基于原文的一些段落重组成的答案。
而大语言模型在里面所扮演角色是筛选我的这些段落做一个理解。此时,它得到的答案是完全符合合规要求的,不会有幻觉的问题。当然,这里它牺牲了一点智能化的能力,不过我们现在也在思考如何把智能化的能力,通过多轮对话的方式加到我们这个平台里面。如果觉得给出的信息比较多,我们可以再做一个总结。这个总结就相当于我们通过15个段落总结出一个相对比较短的文本。但这个短的文本就可能出现一些幻觉问题,针对这个外幻觉肯定就需要我们人工再去校验或者提示用户这个短文本只是作为参考,不能作为最终的一个答案。

我们做生成内容的时候也会有同样的问题,就是我们如果从原文组装内容,再去做它的一个内容的生成,其实它是可以从端到端方式来提高用户的效率。如果是生成的内容,还需要去对比各种原文进行审核,这个过程就会有更多的人工参与。所以,我们也在考虑用大模型做审核,利用“生成+审核”的能力,以端到端的方式来提高整体的效果。

所以,我们会把不同来源的各种数据分层次去建设它。例如我们可以做一些自动的分类,包括用大模型去打标签,结构化我们的数据。同时我们的知识图谱也可以分层次建设,因为不同的知识图谱它的构建成本和应用是不一样的。比如做一个导诊应用,那我可能需要做一个非常精细化的医学知识图谱。如果只是做一个问答系统或者个性推荐,那我可能要把知识图谱做到词级别或者段落级别就可以了。这其实就是我们会根据不同的成本和应用,去考虑做不同层级的知识图谱。

与此同时,我们可以通过大模型去生成FAQ,也可以通过我们刚才说的组装原文段落的方式,或者是总结的方式。我们现在80%内容都可以通过大模型生成,再通过组装原文进行溯源,提供一个最基础的答案,然后在此基础上采用总结的方式。所以,我们面临的专业性、合规性问题,在这里就需要知识图谱的能力更好地体现。

这个平台建立起来之后,我们可以分步去建设整个知识库,用于不同的内容生成。包括我们知识图谱的构建,从FAQ构建我们自动的问答,还有就是我们的标签、图谱的一些能力可以通过这个人机协同的智能平台更好的构建出来。

上面是我们搭建的一个智能信息库的平台,这里面其实会有大量的人机协同的方式,进行自动的打标签,然后构建我们的知识图谱。

我们也可以通过大模型的一些能力,快速构建一个文档级别或者段落级别的知识图谱。

这个是我们从OCR的识别、段落的摘要、段落标签等各个领域方向去更好的构建一些自定义抽取,包括状态里面细粒度知识点的一些抽取。

然后,我们也可以构建一个专业领域的知识图谱,辅助我们完成更精准的问答。

我们前面提到的运维能力也非常重要,因为构建完系统之后,我的数据源需要更新,知识图谱是不是需要更新,大模型的能力是不是需要更新,还有一些Prompt可能也需要更新。所以,我觉得在知识运维方面也需要提供各个层次的知识更新能力,让一般的业务人员也能对知识进行更新。

这就需要一套全流程的方法,让整个系统在不同时间数据更新之后,或者用户的反馈之后,能保证更新的数据质量是可控的,以及将数据更自动化的录入到系统中。

基于这些原理,我们在给客户的各种系统进行一个升级,不管是自动化的内容生成,还有基于语料、ChatBot、知识图谱对大模型做的一个符合合规要求,都能以全流程的方式提高它整体效率。

这是我们跟一些药企合作的案例,他们提供各种内容,我们基于框架快速生成他们需要的一些FAQ,或者一些知识点等内容,从而大幅提高他们整体内容生产的效果。

我们把原有的一些基于FAQ的方式,升级到了基于大模型实时生成并且符合合规要求的一种方式,大大提高了原来整个内容生产和上线的速度。原来可能需要将近一到两个月的时间去生产FAQ,生产之后再审核。而现在我们通过大语言模型不仅能实时组装原有的段落,还能进一步总结。既符合合规要求,又能更加智能化地实时生成内容。

另外,我们针对药企的用户做了一些GraphRAG增强的能力,也对比了基于RAGGraphRAG不同能力的一个效果。我们现在的方法并不是很复杂,有可能根据它的上下位和一些词的级别,就能在一定程度上提高它整体的准确性、理解能力和问答的效果。我们在不同阶段采用了不同的方式去增强大语言模型。

同时,我们也在做一些表格、图片等多模态问答能力的提升。这里面会用到一些图谱的能力,来帮我更好的定位到表格,更好的提升内容去做一些问答。这可能也是我们下一步会重点研究的方向,如何把复杂的一些知识、信息更好的提取出来。

我们还对具有法律法规这种知识的大模型的问答进行一个更好的升级。

总结

近两年,我们做了很多的尝试,不管是从原有的系统升级到现在大模型的方式,还是从大模型再升级到Graph RAG这种方式,都遇到了不少的挑战。其中:


1.企业级的应用,尤其是像医药行业或者一些专业领域,他都具有非常强的合规性要求、循证要求和监管备案的要求。这时候我们就需要考虑采用一些折中方式来应对监管这种合规性的要求。
2.技术限制和我们投入产出的平衡。因为企业应用非常看重投入产出比,不会像做科研课题一样。所以企业投入的钱,到底能产出什么样的价值,能否帮助降本增效,能否真正减轻人工的工作量,这是企业应用在落地的时候一个比较大的挑战
3.知识图谱构建和运维的成本,这也的确是我们在应用落地过程中需要考虑的。因为,有些客户会问,你构建图谱的成本怎么降低?你运维的成本怎么降低?这个时候,我们提出了小图谱大图谱的概念。首先,我们可以冷启动去做一些小图谱,以更好的增强我们的RAG,能更好地帮助它在一定预算范围内看到价值。我相信企业应用,很多客户非常看重应用的价值,如果一下就投入大量的钱去做知识图谱不太现实,所以我们会分层次去建设。

4.就是工程化和可运维的能力,包括OCR的能力、抽取表格的能力,这都是非常关键的。我们也会建议,根据客户的应用场景和预算,在不同情况下怎么从RAGGraph RAG或者用一些开源的框架提升综合投入产出比。另外,我们也可能会先用一些开放的数据,对它的能力进行小成本的验证试错,再进行私有化部署。此外,这里面还有很多合规性的要求,包括需要提前引入业务和法律合格等部门,对外服务需要考虑监管备案的周期和成本。最后,我们一般也是先从内部开始,由内到外这么一个实现路径。以上就是我们近两年工作的一个总结。


53AI,企业落地应用大模型首选服务商

产品:大模型应用平台+智能体定制开发+落地咨询服务

承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询