KG+RAG 系列范式对比及 KAG 框架再思考：兼看大模型增强 KBQA 问答竞赛方案

2024-12-02
浙江
本文字数：6574 字
阅读完需：约 22 分钟

作者简介：刘焕勇，360 人工智能研究院资深算法专家，知识图谱及文档理解算法方向负责人，曾就职于中国科学院。

近年来主持或参与研制全行业事理图谱、360 百科图谱、知识图谱平台、文档理解大模型、360 智脑自研大模型等项目。

申请发明专利十余项、核心论文数篇，开源项目 60 余项。在国际 OGB-Wikikg2 实体链接以及国内 CCKS 多模态实体匹配等 KG/NLP/文档智能领域评测中获得冠亚军名次。

创立“老刘说 NLP”社区，具有广泛影响力。

一、再看大模型与知识图谱结合的 KAG 框架

关于 GraphRAG 进行问答这种范式，老刘说 NLP 技术社区已经说过很多了，对于 KAG，则在文章《GraphRAG系列范式冷思考：GraphRAG、KAG框架思考及E2E-AFG自适应过滤端到端思路》里面的思考核心点是，当前阶段无论是 Graph，还是 KG，应该跟 RAG 浅结合，把收益最大化（当然，其中有些观点是应该反复思考的）。

KAG

KAG 是一个基于 OpenSPG 引擎和大语言模型（LLMs）的推理问答框架，用于构建垂直领域知识库推理问答方案。KAG 可有效克服传统 RAG 向量相似计算的模糊性及 GraphRAG 开放信息抽取的噪声问题，支持逻辑推理和多跳事实问答等，效果显著优于当前 SOTA 方法：

https://github.com/OpenSPG/KAG 欢迎大家 Star 关注~

关于这块，我后面与蚂蚁集团的 KAG 负责人梁磊老师聊了不少，并针对 KAG 这个话题，我觉得兴许存在一些误解，或者存在我所没掌握的细节，所以我跟梁老师商量，是否能够在老刘说 NLP 技术社区专门讲一次，梁老师欣然答应(特别棒）。因此迎来了老刘说 NLP 社区第 34 讲《OpenSPG-KAG 框架与垂域应用》顺利举行，面向知识图谱增强大模型主题，1.5 小时干货分享，1.5 小时精彩碰撞，收获很大。

http://weixin.qq.com/r/7EiYgEnEHRRirQ3j9x3_ (二维码自动识别)

梁磊老师从知识增强路线(检索、Graph、KG 等)、垂域典型问题(逻辑、事实、语义等)、KAG 框架设计(语义对齐、逻辑推理等)以及 KAG 业务应用(医疗、政务、黑产、通用等)展开分享。先说一个结论：基于蚂蚁政务、医疗等场景打磨的，⾯向私域知识库图谱⾃动构建 &问答的解决⽅案！！需要对这个站位有个清晰的认识。我们可以看看其中几个重要的点。

1、当前知识图谱 KG 或者图 Graph 解决大模型问答场景的几种模式

一种是以文档检索为基础演进，Docs=>R+G，以检索(DocsRetrieval)为始、以 LLM 生成(Generation)为终，但其缺点在于，信息缺失，没有充分利用文档中的例如图像、表格等多模态数据，向量检索在面对复杂问题面临挑战，例如需要多跳、复杂逻辑。LLMs 推理能力有限，依赖文本的语义相似度，只能确定文档之间的相似的，无法捕获不同之间的具体关系，以及为什么相关，检索到错误。噪声的信息后生成错误答案，仍然可能存在幻觉；

一种是 GraphRAG,KG 增强文档索引，Docs=>G-CIndex=>R+G，以检索(DocsRetrieval)为始、以 LLM 生成(Generation)为终。其缺点在于，依赖开放信息抽取方法，引入了大量的数据噪声，知识精准度差。使用图结构实现跨文档的信息传播，缓解了向量召回的不足。例如需要多跳、复杂逻辑依然存在不足。LLMs 推理能力有限，检索到错误。噪声的信息后生成错误答案，仍然可能存在幻觉。

一种是以 KBQA 为原型演进，KGs=>R+G，以检索(GraphRetrieval)为始、以 LLM 生成(Generation)为终。依赖高质量的知识图谱，图谱构建门槛高，高质量的知识图谱需要大量人力。信息损失大，知识图谱中只包含了实体、关系、属性等，相对信息丰富的原始文本，信息损失较大可阅读性差，生成的答案包含关键事实，上下文信息较少

2、KAG 到底是什么，出发点是什么？

KG 构建门槛高、知识稀疏，RAG 缺少语义、逻辑关联，GraphRAG 中 OpenIE 信息抽取，引入大量噪声；LLM 存在幻觉问题，这是 KAG 想解决的问题。那么，针对 KG 构建门槛高、知识稀疏的问题怎么办？

思路就是，尽可能地让孤岛的两个实体之间构建一条路径出来，这个路径可以是直接拉一条边，可以是一个多跳的层级路径（这个是有趣的，KAG 中使用概念对齐的方式来解决问题，小红和小李可能没有直接关联，但通过这种方式，可以共享一个 person 的节点而存在一条路径，很自然，这样的确可以提高召回，因为只要两个实体之间存在这条边，就总能召回。但随之的风险是，概念对齐后的关联我认为是弱关联，概念和实体语义是两回事儿，维度不同，召回来可能噪声大，此外对齐上也存在对齐错误的情况，因为其中还是通过大模型进行概念生成和匹配，这这个在长尾场景上缺点更明显。所以梁老师的解决方案是兼容开放 schema，这算是个 adapter）。

针对 RAG 缺少语义、逻辑关联的问题，怎么办，那就拉边嘛。chunk 之间抽取实体，chunk 和实体之间可以关联，也可以通过实体之间的关系实现 chunk 之间的关联，或者 chunk 之间也可以直接形成关联(也是一种实现手段)，这也是微软 GraphRAG 等采用方案。

针对 OpenIE 信息抽取，引入大量噪声的问题，那解决方法就是洗了，那就上传统的实体链接、对齐、歧义来解决，约束到语义概念上，这一块其实就开始很重了，链接、对齐、消歧本身是比对过程，时耗是需要考虑的，即便有有很多工程方法。

对于 LLM 的幻觉问题，则针对具体的任务做处理，例如，针对逻辑推理类方案 logicform 来执行推理，这也是 KAG 的另一个”重点“。因此，我们按照这个初衷，就可以找到梁磊老师的出发点，即 KBQA+RAG=>KAG；KGs+Docs=>R&R+G，KBQA 与 HippoRAG 的启发和借鉴以推理(Reasoning&Retrieval)为始、LLM 生成(Generation)为终。

所以，核心点出来了，是以推理(Reasoning&Retrieval)为始，务必要注意这一点，这个跟 RAG 是不同，跟 GraphRAG 也是不同的。所以，kAG 最开始的定位其实就是逻辑推理（推理后可以做问答），所以，基于这个点，就可以再进一步地去看去其对应的技术支撑逻辑。

3、KAG 到底是如何做的？

KAG 的方案是用知识抽取的方法弥补推理阶段知识稀疏性问题，通过知识问答提升逻辑推理能力，通过信息抽取来弥补知识稀疏性，通过开放抽取来降低落地的门槛。

但一旦涉及到逻辑推理，那么就必定会有逻辑推理的形式化表达，可以是本体 ontology，也可以是另一种表示体系，其可以存储可用于执行的节点、关系表达、逻辑运算符号，因此，为了解决这个问题，KAG 是使用了其早些年提出的 SPG 来做支撑，这是这套框架自己的语义表示逻辑。

升级 SPG 为面向大模型友好的知识表示 LLMFriSPG，兼容强 Schema 专业知识和弱 Schema 开放信息，图结构知识与文本知识的互索引结构，这也是区别于微软 GraphRAG 或者 LightRAG 的点，后两者是没有语义信息的。

而做过知识图谱的朋友这时就很有感觉，KAG 本质其实是知识图谱面向问答的一种自适应变体，处处有知识图谱的影子，所以一旦构建好这种知识表示形式之后，随之而来的知识图谱各阶段就自然就出来了。

这也是我在《 GraphRAG 系列范式冷思考：GraphRAG、KAG 框架思考及 E2E-AFG 自适应过滤端到端思路》中说说的，它把 KG 的流程都带过来了，所以可以看到后续有结构化构建与开放信息抽取 (利用 oneke，执行要素结构化，首先获得目标实体、概念的结构化表达；映射与关联:将结构化数据映射到目标 property 上并关联算子；要素标准化: 概念挂载、属性标化、实体链指以及归一与融合: 实体链指 &归一，关系、属性合并等)，这个确实很重，很有误差传播。再说回到语义对齐的问题，执行的是基于概念图的语义对齐、KAG 开放信息抽取阶段知识对齐，如下图所示。

语义对齐，其实解决的更多的是稀疏的问题，并在一定程度上缓解早生的问题，使得构建的图谱更加完备、连通性更好，更为标准化。这个目的有两个：一个是后面进行召回时能够召回的更为全面(找到的更多了)；另一个是后面进行 logicform 推理时，执行的成功率会更大(在更标准化的 graph 做检索和执行会更顺利)。建图在此就结束了，而下一步，就是用图，通过检索的方式进行问答了，KAG 的问答方式跟其他的确还不一样，其走的是 logicform 推理，如下图所示：

给定一个问题 query 和背后建好的知识图谱 KB，首先需要通过 planning 阶段，进行问题建模，生成一个 logicform 的多 step 推理步骤，每个推理步骤都对应一些操作，如 retriveal 和对应的 slot 参数信息。但这块的风险点在于，

planning 的拆解是否能够正确，拆成几步才够，如何控制？retriveal 和对应的 slot 参数信息获取本身是一个抽取和链接任务，准确性如何？整个执行的跌打爱终止条件如何判定，是否存在死环的情况？整个执行步骤，其实都高度依赖于大模型本身的能力，虽然可以通过微调、强化的方式来优化，但对于用户 query 很模糊的情况下，是否能够奏效？

也就是说，Logical form 的问题拆解其实会有错误累加问题，这个在垂域的场景下会有好转，但放在通用，用户问题不受控的情况下，效果是较难保证的。但这块梁老师表示，这块的技术其实是可以逐步迭代优化的，的确是可以的。

4、启发之一：没有最好，只有谁更合适

其实关于 KAG，或者 GraphRAG，异或是朴素 RAG，现在无论是一些自媒体，还是一些技术论文，都存在一个较大的问题，就是在一个并不清晰的大面上的任务上，单纯地对比识图谱 KG 或者图 Graph 解决大模型问答场景的效果。这些其实并不严谨的，需要找到合适的场景、任务并选择与之对应的技术方案。大模型问答有很多细分任务，摘要类、百科类、数值计算类、多跳推理类等，近年来出现的很多方案其实是针对某一类问题进行的优化，所以正确的评估很重要。进入到知识图谱和大模型结合这个领域，应该进一步分析每个技术点的优缺点以及对应的技术路线，例如，这个是梁老师对上面几个路线的对比：

而在应用场景下，也很自然的有了一下对比。

GraphRAG(MS) 通过层次聚类实现段落摘要的逐级生成，更关注答案生成的可理解性、完整性、多视角多跳问答等评测集量化指标较差，未提供逻辑符号推理的能力，适用摘要生成类任务；LightRAG 通过 rdf 五元组（带类型）抽取完成图谱构建。问答阶段，通过对 query 中所包含实体、实体归属的概念实现 Chunk 召回，未利用语义、逻辑、符号等图谱技术栈，适合摘要生成类任务。HippoRAG 通过 rdf 抽取+语义相似拉边，完成图谱构建，问答阶段，通过 dpr+ppr 实现 Chunk 召回。未利用语义、逻辑、符号等图谱技术栈。适合事实问答类任务。OpenSPG-KAG (V0.5)基于知识抽取、语义对齐、文本 &图互索引等完成图谱知识库构建，基于逻辑符号引导的混合推理, 实现事实问答 &逻辑推理类任务。适合事实问答类任务+逻辑推理类任务。

5、启发二：关于 KAG 的情怀和老 KG 人的技术信仰坚守

实际上，任何技术的发展，都是百花齐放的，大家所属的技术背景不同，所在的技术岗位，所解决的问题，直接就会造就不同的思路。在这次分享中，与梁磊老师的交流中，的确可以看到 KAG 的情怀和老 KG 人的技术信仰坚守。首先，KAG 来源于蚂蚁这类很垂直的金融/医疗场景（在去年 ccks 上，也碰 SPG 发布，用事理图谱进行灰黑产识别），例如，银行风险报告中的错误定性或错误逻辑、事实性错误或无依据、政务问答中知识精准性问题、知识完备性问题，以及时间、数值不敏感扽问题。

所以，如分享中所看到的，KAG 在蚂蚁业务中的应用，用于热点事件解读、银行分享分析、政务办事问答、医疗健康问答、黑产图谱，通过提升黑产特征挖掘、完善黑产团伙刻画、推送线索助力司法部门线下打击等手段，降低体系内赌博电诈风险这些，这些都是垂直场景的。

所以 KAG 的站位应该是私域私域私域，抱紧私域这个限定词，垂域就是专家系统。有一个精致的（少但规范）的 schema /本体，垂域知识结构化标准化程度高，天然有多跳场景。如医疗，法律，甚至双十一打折规则这种。而开放域，比如搜索/新闻事件，真的主要就是发挥增强知识联通的索引构建/召回问题了。只要能搜到，让大模型理解去吧。开放域无法很好做到 schema 的规范化，不确定性会增长，可能瞎答；

其次，抽象到知识图谱这一层，即，知识图谱发展那么多年，的确不太好，本质上就是 ROI 太低，从大面上来说的确如此，但对于知识图谱而言，其实本质上是因为没有太多知识图谱的场景。对于通用搜索而言，知识图谱就是一个具备关联关系的大词表，这个是实话。而对于 2B 需求，则很多都是上来就说要建一个百万、千万、上亿节点的图谱，然后解决实体抽取、关系抽取、更新的问题，但实际上，很多时候是其实是不知道用图谱做什么，很多时候，草草做了，其实并没有用起来。

其实现在 RAG 也是一样的风向，一周出 demo，半年用不好，本质上是因为其不是解决现有真实场景的根本解（也是目前大模型落地也没有太多真实的落地场景，昨天碰到一个老朋友，一个观点，大模型对 C 端几乎是无收益的，对于 B 端，只是让之前难做到事好做了一丢丢），总是打补丁，但大家都在讲，所以都在用，都在上马，Graph 很火，那就上，上了发现，token 和时延都上去了，ROI 下去了，然后就不了了，转下一个火的点，比如 agent。可能其中的焦虑情绪应该往后放放，而是因地制宜地好好分析自己的应用场景，任务应该如何建模，选择最好的方式来做，这才是根本解。

前天，作为嘉宾，参加 CSDN 举办的全球机器学习技术大会圆桌论坛，台下其中有个问题很有趣，问如何收集用户的反馈数据，用户要么不点反馈(up or down)，要么就点 down，无法做算法优化。但实际上，这个问题根本逻辑在于，如果你的用户量没起来，没多少个人用，那么收集也无从谈起，这种情况纯属自我焦虑，而应该做算法侧的评估闭环。其实也是一样的，大家在找方案，找出口，现在假设性太强，然后丢掉了原本那些技术根本逻辑的思考，这其实是舍本逐末的。

说回到情怀那一层，我从 14 年开始做图谱，今年是已有 10 个年头，梁磊老师是 18 年(没记错的话)，都是 KG 的老人了，我俩都是有技术情怀的，难能可贵。个人目标很重要，大家也在为这个事情用自己的方式在做一些事情和推进，应该保持这种不变，但外部环境在变化，此消彼长、三十年河东三十年河西的例子比比皆是，所以根据外部环境来调整策略，这很重要。有个例子，问过梁老师，就是上面的需求是否为高频需求，在通用场景下是否为长尾需求， 其实，大家也一样，工业界解决问题，都是赢通吃；如果我们做的事情是长尾，我们收到的挑战的就会很大。这个部分就写到此了，KAG 是富含知识图谱影子的一个产物，跟 RAG、GraphRAG 不是一个东西，不是替代关系，而是走了一条极具知识图谱正室血统的特色结合道路，里面有情怀，但也会面临很多挑战，但有个东西需要再次明确，基于蚂蚁政务、医疗等场景打磨的，⾯向私域知识库图谱⾃动构建 &问答的解决⽅案。找好合适的场景，才能更好、更快的解决问题？

二、关于知识图谱用于知识图谱问答

接着上面说，其中提到 KBQA，也可以采用知识图谱增强大模型的范式来做，所以老刘说 NLP 技术社区第 35 讲《 2024ccks 开放知识图谱问答获奖方案分享，基于大模型多跳感知的知识图谱问答解决方案：ccks2024 开放领域知识图谱问答评测第二名、科技创新奖》顺利结束。

其核心在于，提出了多跳感知大模型，结合知识图谱探索图谱问答，提升查询效率和准确性，尽管大模型在知识图谱问答中存在一些问题，但它们仍然是未来知识图谱问答技术发展的趋势。同时，也强调了实体链接在大模型中的重要性，以及如何通过优化模型和数据处理来提高知识图谱问答的准确性。老刘认为，这种方案的重点就三个：