KG+RAG系列范式对比及KAG框架再思考

摘要：这周，老刘说NLP社区顺利完成第34讲OpenSPG-KAG框架与垂域应用》和第35讲《2024ccks开放知识图谱问答获奖方案分享》，两个分享都是围绕知识图谱与大模型结合，很精彩，也很多收获。

兼看大模型增强KBQA问答竞赛方案

文章转自公众号老刘说NLP

这周，老刘说NLP社区顺利完成第34讲OpenSPG-KAG框架与垂域应用》和第35讲《2024ccks开放知识图谱问答获奖方案分享》，两个分享都是围绕知识图谱与大模型结合，很精彩，也很多收获。

这次感悟较多，尤其是再看大模型与知识图谱结合的KAG框架，与梁磊老师交流后的一些感悟。供大家参考。

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

关于GraphRAG进行问答这种范式，老刘说NLP技术社区已经说过很多了，对于KAG，则在文章(https://mp.weixin.qq.com/s/kYlGAwAFayySnszwZ1g8Og)，里面的思考就是，核心点是，当前阶段无论是Graph，还是KG，应该跟RAG浅结合，把收益最大化（当然，其中有些观点是应该反复思考的）。

关于这块，我后面与蚂蚁集团的KAG负责人梁磊老师聊了不少，并针对KAG这个话题，我觉得兴许存在一些误解，或者我所不掌握的细节，所以我跟梁老师就想着说，是否能够在老刘说NLP技术社区专门讲一次，梁老师欣然答应(特别棒）。

所以就迎来了本周二(2024-11-12)，老刘说NLP社区第34讲《OpenSPG-KAG框架与垂域应用》顺利举行，面向知识图谱增强大模型主题，1.5小时干货分享，1.5小时精彩碰撞，收获很大。

梁磊老师从知识增强路线(检索、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不是一个东西，不是替代关系，而是走了一条极具知识图谱正室血统的特色结合道路，里面有情怀，但也会面临很多挑战，但有个东西需要再次明确，基于蚂蚁政务、医疗等场景打磨的，⾯向私域知识库图谱⾃动构建&问答的解决⽅案。找好合适的场景，才能更好、更快的解决问题？