知识图谱与大模型相结合的3种方法,1+1>2
本文分享自华为云社区《知识图谱与大模型结合方法概述》,作者: DevAI 。
《Unifying Large Language Models and Knowledge Graphs: A Roadmap》总结了大语言模型和知识图谱融合的三种路线:1)KG增强的LLM,可在LLMs的预训练和推理阶段引入KGs;2)LLM增强KG,LLM可用于KG构建、KG embedding、KG补全、基于KG的文本生成、KBQA(基于图谱的问答)等多种场景;3)LLM+KG协同使用,主要用于知识表示和推理两个方面。该文综述了以上三个路线的代表性研究,探讨了未来可能的研究方向。
知识图谱(KG)和大语言模型(LLM)都是知识的表示形式。 KG是符号化的知识库,具备一定推理能力,且结果可解释性较好。但存在构建成本高、泛化能力不足、更新难等不足。LLM是参数化的概率知识库,具备较强语义理解和泛化能力,但它是黑盒模型,可能编造子虚乌有的内容,结果的可解释性较差。可见,将LLM和KG协同使用,同时利用它们的优势,是一种互补的做法。
LLM和KG的融合路线,可分为以下类型:
第一种融合路线是KG增强LLM,可在LLM预训练、推理阶段引入KG。以KG增强LLM预训练为例,一个代表工作是百度的ERNIE 3.0将图谱三元组转换成一段token文本作为输入,并遮盖其实体或者关系来进行预训练,使模型在预训练阶段直接学习KG蕴含的知识。
第二种融合路线是LLM增强KG。LLM可用于KG构建、KG embedding、KG补全、基于KG的文本生成、KBQA(基于图谱的问答)等多种场景。以KG构建为例,这是一项成本很高的工作,一般包含1) entity discovery 实体挖掘 2) coreference resolution 指代消解 3) relation extraction 关系抽取任务。LLM本身蕴含知识,且具备较强的语义理解能力,因此,可利用LLM从原始数据中抽取实体、关系,进而构建知识图谱。
第三种融合路线是KG+LLM协同使用,主要用于知识表示和推理两个方面。以知识表示为例,文本语料库和知识图谱都蕴含了大量的知识,文本中的知识通常是非结构化的,图谱里的知识则是结构化的,针对一些下游任务,需要将其对齐进行统一的表示。比如,KEPLER是一个统一的模型来进行统一表示,它将文本通过LLM转成embedding表示,然后把KG embedding的优化目标和语言模型的优化目标结合起来,一起作为KEPLER模型的优化目标,最后得到一个能联合表示文本语料和图谱的模型。示意图如下:
小结:上述方法都在尝试打破LLM和KG两类不同知识表示的边界,促使LLM这种概率模型能利用KG静态的、符号化的知识;促使KG能利用LLM参数化的概率知识。从现有落地案例来看,大模型对知识的抽象程度高,泛化能力强,用户开箱即用,体验更好。且如果采用大模型+搜索的方案,用户更新知识的成本也较低,往知识库加文档即可。在实际业务场景落地时,如果条件允许,优先考虑使用大模型。当前chatGPT火爆,也印证了其可用性更好。如遇到以下场景时,可以考虑将LLM和KG结合使用:
• 对知识可信度和可解释性要求高的场景,比如医疗、法律等,可以考虑再建设知识图谱来降低大模型回答错误知识的概率,提高回答的可信度和可解释性。
• 已经有一个蕴含丰富知识的图谱,再做大模型建设时。可以参考KG增强LLM的方法,将其知识融合到LLM中。
• 涉及基于图谱的多跳推理能力的场景。
• 涉及基于图谱可视化展示的场景,比如企查查、天眼查等。
文章来自:PaaS技术创新Lab,PaaS技术创新Lab隶属于华为云,致力于综合利用软件分析、数据挖掘、机器学习等技术,为软件研发人员提供下一代智能研发工具服务的核心引擎和智慧大脑。我们将聚焦软件工程领域硬核能力,不断构筑研发利器,持续交付高价值商业特性!加入我们,一起开创研发新“境界”!
PaaS技术创新Lab主页链接:https://www.huaweicloud.com/lab/paas/home.html
参考文献:
Unifying Large Language Models and Knowledge Graphs: A Roadmap https://arxiv.org/abs/2306.08302

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
深秋 寒露:是时候和 Zadig 说再见了
阅读原文/Zadig 在 Github/Zadig 在 Gitee 推荐阅读:是时候和 Jenkins 说再见了/Zadig vs. Jenkins 详细比对:时代的选择与开发者之选/平台工程和 AI 时代的新 10 亿开发者 2023 年 11 月 1 日 秋风起,露成霜,正是一年最美时 Zadig 团队踏入了 创业的第五个年头 开源的第 888 天 然而今天 我们要向 Zadig 说再见了 深秋外象趋冷 实则万物蛰伏 在孕育着新的生机 今天,我们向 Zadig 1.0 告别 迎来全新的 Zadig 2.0! 回顾开源的这两年多时间里 Zadig 1.0 已完成了 2 万 6 千多次的企业下载 发布了 21 个开源版本,10 个企业版本 在 2 千多家企业和团队深度使用 我们创作了 157 篇原创技术和产品文章 制作了 52 个独创的短视频 与 100 多位国内外商业、技术和产品领域的同仁伙伴建立了深厚的链接 今天,Zadig 已不再是婴儿 是一个坚定自信的少年 走进数千家企业和团队的日常工作中 让他们的工作更加高效愉悦 这段旅程,Zadig 背后的团队和社区一起 合作共创 ...
- 下一篇
十年业务开发总结,如何做好高效高质量的价值交付
背景 转眼间已经做了十年的业务开发,这十年大部分时间都是在承接各种各样的业务需求和项目,在需求评审环节,我们有些东西误以为双方达成共识了,上线后发现和PD想的不一样;代码发布后,总会出现一些问题,有些问题看着很简单,但是上线前我们就是没考虑到,甚至上线前我们不知道原来系统中还存在这样一个逻辑;代码运行一段时间后,还会出现一些意料之外的问题,有可能我们写的代码只考虑了当时的逻辑,未来别人改了一行,别人的需求满足了,原来的需求满足不了,原来需求没满足我们可能还没法及时发现,因为是不同的开发做的需求,等发现的时候已经产生了资损或者对客影响。 另外,组织和业务是多变且复杂的,组织调整也是个常态,今天A团队a同学负责这个模块或者系统,由于组织变化,明天B团队b同学会接手,我们通常会组织交接(据我观察好像还有不交接的直接给过去的),如果有些逻辑没有交接好的话,新团队承接需求的过程中才能发现,甚至发现的时候已经造成了资损或者对客的影响。最近也是在忙于分析和解决各种线上问题,也引起了自己的思考,作为一名开发同学,有没有一些方法论来保障我们做高效高质量的交付呢?我自己也在不断分析思考这些问题,结合自己的...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19