微信扫码
与创始人交个朋友
我要投稿
OpenKG新开设“TOC专家谈”栏目,推送OpenKG TOC(技术监督委员会)专家成员的观点文章。本期邀请到东南大学漆桂林教授、柯基数据CEO吴刚介绍“大模型+知识图谱”方面的一些探索,本文整理自“OpenKG走入通义实验室”Talk上的分享。
本报告介绍将知识图谱与大模型融合的基本方法。一方面,应对大模型目前面临的挑战;另一方面,利用知识图谱技术优化大模型的表现。本文简要介绍了两位TOC专家东南大学漆桂林教授和柯基数据CEO吴刚在此领域开展的初步探索工作。
大模型和知识图谱技术特点及优劣势
从这个角度来看,我们可以从知识工程的角度来看待知识图谱跟语言模型。如果从这个角度去理解他们,我们可以更好地从人工智能的整体观来理解现在以及未来人工智能的发展。语言模型跟知识图谱各自在人工智能的发展过程中可能发挥的作用以及可能的应用。
知识图谱和语言模型这两者的优劣性其实可能很多报告里面都有介绍。比如像语言模型是连接主义,而知识图谱是符号主义。前者是参数化的知识,且是一种概率生成模型,而后者是符号化的知识,且是一种稳定生成模型。他们各自的优势跟劣势相对来说是比较清晰的。
我们把语言模型作为知识库的时候,因为这个知识库不像知识图谱是可视化的,如果要去做查询,返回的结果也不是结构化的回答,而是一句或者一段话。这就很难知道给出来的结果到底是不是准确的。然后,在知识更新的时候也会存在很大的问题,很多时候会把新知识采用外挂的方式去解决一些问题(也就是最近比较流行的RAG),但是这些并不是语言模型本身的知识。人类在学习中会通过知识更新的能力,快速把知识存下来变成人脑知识的一部分,而大模型很难做到这一点。最后,知识的校验也是非常困难的。
我们也做过一些调研和实验,比如在OCR的时候对PDF文件进行版面分析和文字提取,发现提取的准确率并没有我们想象中的那么高,其中包括对Abstract的提取,还有Title的提取和Author的提取等。
我们可能认为现在的多模态大语言模型已经很强大了,但是事实上有些时候对他们能力测试的时候,实验结果并不是我们想象的那么好。比如说,文本的分段提取会有一些问题,而且我们可以看到文本里面做一些关键信息提取的时候,他们可能无法做到非常的精准。还有知识检索,在检索相关的文档片段时,无法确保召回了所有的相关片段,以及对文本片段进行排序也不一定很好。
知识图谱和大模型双轮驱动方法论
但是,我觉得有一个比较重要的部分在于构建知识图谱也是需要成本的。那么,我们怎么在工程领域,在一定的限制的预算范围内将知识图谱和大模型结合起来,发挥出真正的价值这是最大的一个挑战。
上面是去年我们跟工信部标准院一起写的研究报告,介绍的就是知识图谱和大模型的一个双轮驱动。一方面是用大模型半自动化生成知识图谱,另一方面是在大模型中注入知识图谱以增强大语言模型的一些能力。这里我就不展开细讲了,感兴趣的同学可以在网上自行查看。
目前最主流的方式就是检索增强(RAG),基于外部知识库做检索和内容生成。
它其实是把你的一些文档文献或者一些数据进行向量化,再把你的问题去跟它匹配。这里它是在缺乏上下文的理解,还有领域的业务理解进行的。它在应用上有一定的瓶颈。
这里面我们会用到一些传统技术,比如:检索技术、ES技术以及Prompt技术。我们会将这些能力组装成一个部分,再带上我们根据定位的几个段落的文本,还有问题本身的增强,把这些传给大模型去做一个问答。这样,它会回答出更精准的一个答案,是我们现在在做的一个方法。
医药行业数智化
我们在最近几年也做了大量的企业数字化的知识库、Chatbot和各种应用。不管是临床研究情报系统,还是说产品上市之后做学术的推广、患者的教育、面向药店的助手以及销售这种助手等等。
所以导致整个知识生产效率比较慢,用户体验也不好,智能化程度也不高。做出来的系统很难进行一个非常好的推广。但是,当大模型出来之后,很多客户提到通过大语言模型能否解决这样的一些问题,让内容更加自动化地生产,还能更智能的交互提升用户的体验。
GraphRAG应用及落地挑战
那我们怎么去做这个事情呢?其实,我们会把原有的情报系统、知识库和Chatbot,基于“知识图谱+大模型”的能力做到更加自动化的升级。然后,对内对外提供一套统一的多渠道入口,把内部的各种系统也对接起来,帮助他提高整体的服务。这不仅仅是单点做一个算法或者做一个RAG的应用,而是会从端到端提高整体的效率。
所以,我们需要做的是一个端到端的系统,不仅能提高整体效率,还能减少人工的一些工作。同时满足一些合规的要求,再加上我们大模型的一些智能化的能力,比如:写作能力、总结能力还有对接不同私有模型、API的能力。在这里,我们会把知识图谱放在里面,作为整个知识库的一部分。
我们做生成内容的时候也会有同样的问题,就是我们如果从原文组装内容,再去做它的一个内容的生成,其实它是可以从端到端方式来提高用户的效率。如果是生成的内容,还需要去对比各种原文进行审核,这个过程就会有更多的人工参与。所以,我们也在考虑用大模型做审核,利用“生成+审核”的能力,以端到端的方式来提高整体的效果。
与此同时,我们可以通过大模型去生成FAQ,也可以通过我们刚才说的组装原文段落的方式,或者是总结的方式。我们现在80%内容都可以通过大模型生成,再通过组装原文进行溯源,提供一个最基础的答案,然后在此基础上采用总结的方式。所以,我们面临的专业性、合规性问题,在这里就需要知识图谱的能力更好地体现。
这个平台建立起来之后,我们可以分步去建设整个知识库,用于不同的内容生成。包括我们知识图谱的构建,从FAQ构建我们自动的问答,还有就是我们的标签、图谱的一些能力可以通过这个人机协同的智能平台更好的构建出来。
我们也可以通过大模型的一些能力,快速构建一个文档级别或者段落级别的知识图谱。
这个是我们从OCR的识别、段落的摘要、段落标签等各个领域方向去更好的构建一些自定义抽取,包括状态里面细粒度知识点的一些抽取。
然后,我们也可以构建一个专业领域的知识图谱,辅助我们完成更精准的问答。
我们前面提到的运维能力也非常重要,因为构建完系统之后,我的数据源需要更新,知识图谱是不是需要更新,大模型的能力是不是需要更新,还有一些Prompt可能也需要更新。所以,我觉得在知识运维方面也需要提供各个层次的知识更新能力,让一般的业务人员也能对知识进行更新。
这就需要一套全流程的方法,让整个系统在不同时间数据更新之后,或者用户的反馈之后,能保证更新的数据质量是可控的,以及将数据更自动化的录入到系统中。
基于这些原理,我们在给客户的各种系统进行一个升级,不管是自动化的内容生成,还有基于语料、ChatBot、知识图谱对大模型做的一个符合合规要求,都能以全流程的方式提高它整体效率。
这是我们跟一些药企合作的案例,他们提供各种内容,我们基于框架快速生成他们需要的一些FAQ,或者一些知识点等内容,从而大幅提高他们整体内容生产的效果。
我们把原有的一些基于FAQ的方式,升级到了基于大模型实时生成并且符合合规要求的一种方式,大大提高了原来整个内容生产和上线的速度。原来可能需要将近一到两个月的时间去生产FAQ,生产之后再审核。而现在我们通过大语言模型不仅能实时组装原有的段落,还能进一步总结。既符合合规要求,又能更加智能化地实时生成内容。
另外,我们针对药企的用户做了一些GraphRAG增强的能力,也对比了基于RAG和GraphRAG不同能力的一个效果。我们现在的方法并不是很复杂,有可能根据它的上下位和一些词的级别,就能在一定程度上提高它整体的准确性、理解能力和问答的效果。我们在不同阶段采用了不同的方式去增强大语言模型。
同时,我们也在做一些表格、图片等多模态问答能力的提升。这里面会用到一些图谱的能力,来帮我更好的定位到表格,更好的提升内容去做一些问答。这可能也是我们下一步会重点研究的方向,如何把复杂的一些知识、信息更好的提取出来。
我们还对具有法律法规这种知识的大模型的问答进行一个更好的升级。
总结
4.就是工程化和可运维的能力,包括OCR的能力、抽取表格的能力,这都是非常关键的。我们也会建议,根据客户的应用场景和预算,在不同情况下怎么从RAG到Graph RAG或者用一些开源的框架提升综合投入产出比。另外,我们也可能会先用一些开放的数据,对它的能力进行小成本的验证试错,再进行私有化部署。此外,这里面还有很多合规性的要求,包括需要提前引入业务和法律合格等部门,对外服务需要考虑监管备案的周期和成本。最后,我们一般也是先从内部开始,由内到外这么一个实现路径。以上就是我们近两年工作的一个总结。
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-11-15
利用LLM构建非结构化文本的知识图谱
2024-11-13
GraphRAG:基于PolarDB+通义千问+LangChain的知识图谱+大模型最佳实践
2024-11-13
利用LLM Graph Transformer实现知识图谱的高效构建
2024-11-12
什么是知识图谱和AI多模态推理
2024-11-12
Graph Maker:轻松使用开源大模型将文本转为知识图谱,发现新知识!
2024-11-11
iText2KG:使用LLM构建增量知识图谱(KG)
2024-11-08
NebulaGraph 在中医药领域的应用:构建鼻炎知识图谱
2024-11-07
轻松搭建AI版“谁是卧底”游戏,muAgent框架让知识图谱秒变编排引擎,支持复杂推理+在线协同
2024-07-17
2024-07-11
2024-07-13
2024-08-13
2024-07-08
2024-07-12
2024-07-26
2024-07-04
2024-06-10
2024-06-24
2024-11-04
2024-10-10
2024-10-03
2024-09-27
2024-09-08
2024-09-05
2024-08-27
2024-08-24