今天是2024年12月30日，星期一，北京，天气晴。
今天是2024年的倒数第二天。年终近了。
今天我们来看看两个知识图谱与RAG结合的思路。
关注技术，并关注应用落地，把技术学扎实，总会有更多的收获。
供各位参考，多思考，多总结，多实践；
一、知识图谱本体与RAG结合OG-RAG
关于RAG和Graph的结合工作，我们已经讲了许多，例如，GraphRAG 在语义聚类方面表现出色，通过组织实体和关系，使得处理复杂查询更加高效。RAPTOR采用分层结构进行多层次抽象，提高对大型文档的上下文理解。
而正儿八经谈知识图谱本体与RAG相结合的工作，我们可以看看最近的《OG-RAG: ONTOLOGY-GROUNDED RETRIEVAL-AUGMENTED GENERATION FOR LARGE LANGUAGE MODELS》(https://arxiv.org/pdf/2412.15235)，这个工作可以看看，提出了OG-RAG（本体引导的检索增强生成）通过将领域特定的本体集成到LLM检索过程中，如下图所示。
其包括两个核心，将数据映射的本体形式化为超图，然后使用基于优化的超图检索提取与领域特定查询精确对齐的事实簇，从而生成更准确的上下文响应。
可以看其中细分的几个步骤：
一个是超图构建，首先将领域特定的文档映射到给定的本体，并将可用信息转换为可检索的格式。本体是领域内关键实体及其关系的正式表示。
例如，在农业领域，定义了作物、土壤和天气条件等实体，以及“作物在某个地区种植”或“土壤有湿度水平”等关系。通过定义这些实体和关系，本体为组织领域知识提供了一个一致且清晰的框架。不同于分类学或分类，本体允许实体之间存在更丰富的关系，这些关系不必是层次式的。
因此，这个本体的定义比较重要，可以让大模型来做，如使用这些prompt：
具像化一下，看几个例子：
比如，新闻的本体：
又如，农业的一个本体：
一个是超图转换，由于事实块的嵌套结构，直接处理这些信息并不太友好，所以更好的方式是通过将每个事实块【fact block】转换为一组扁平化的事实块，将信息简化为更容易处理的形式。
所以，这里又有个新概念，定义每个扁平化的事实块为一个超边，超边连接多个超节点。
这里需要明确下：
其中，一个超图H:=(N,E)由超节点N和超边E组成，使得每条超边e∈E是具有任意长度的节点集。
从本体映射文档I中提取的所有扁平化事实块集合可以被视为一个超图，可将其简称为H(I)。根据这个定义，一个超节点本质上是一个键值对，一条超边是扎根于特定领域数据的真实事实。
而这个事实是两个实体(主体和客体)之间通过一个功能属性进行逻辑断言，该断言可以通过证据验证为真或假。形式上可以被表达为一个逻辑断言，能够验证其值为True或False。
例如，考虑断言：hasCropYield(农场A)=500吨，其中hasCropYield是一个功能属性，它将一个农场（主体）映射到一个作物产量（值），并且可以通过证据验证为真或假。
因此，在OG-RAG中，超边可以被看作是复杂事实的表示。不失一般性，考虑两个超节点，n1(s1⊕a1,v1)=(作物有名称，大豆)和n2(p2∈⨁P(S×A),v2)=(作物有生长区，生长区名称为西北方)，形成一条超边e=((作物有名称，大豆（作物具有名为西北的生长区CropGrowingZone）可以表示为一个简化的事实：具有生长区的大豆（作物名称）=西北，这个事实可以被验证为真或假。
一个是基于超图的检索，利用构建的超图，根据用户查询检索相关上下文。通过贪心算法选择覆盖最多未覆盖节点的超边，形成紧凑的上下文。
在具体实现上：
首先，识别与给定查询相关的超节点集合。一个超节点n∈N可以表示为来自集合S,A,V的键值对。如果满足以下条件之一，则可以将超节点视为与查询相关：(1)查询涉及项s的属性a；(2)查询关注具有特定值v的对象。
换句话说，如果键（代表连接的实体和属性）与查询Q的相似度高，或者值v与查询Q的相似度高，则超节点是相关的。
OG-RAG找出两组与查询相关的超节点：NS(Q)和NV(Q)，分别代表这两组节点。NS(Q)表示在向量空间Z中，其属性术语，即s⊕a与查询Q之间相似度最高的k个超节点；NV(Q)表示在向量空间Z中，其值v与查询Q之间相似度最高的k个超节点。因此，对于每个查询，提取2⋅k个相关超节点.
其次，相关超边作为上下文。将相关上下文构建为最小覆盖相关超节点集合N(Q)=NS(Q)∪NV(Q)的超边集合CH(Q)⊂E。这里是一个优化问题，并以贪婪方式解决。具体来说，维护一个字典，将每个超节点n∈N映射到它所属的超边集合，即E(n)，其中e∈E(n)⟹n∈e。在每次迭代中，将覆盖最多未覆盖节点的超边添加到上下文中，并从进一步考虑中移除这些节点。这个过程重复进行，直到有L条超边或所有相关节点都被覆盖。
通过这种方式，上下文被构建为一系列最多L条代表与给定查询相关的超边的集合。通过将信息组织成超边，OG-RAG能够将相关事实分组在一起，确保检索到的上下文既紧凑又全面，捕获所有必要的事实以支持准确的LLM（大型语言模型）回应，同时优化效率。
一个是检索增强生成，最后，给定用户查询和相关上下文，提示LLM使用这些上下文生成答案。
最后看下效果对比。
RAG通过将查询相关文档块嵌入到向量空间中，然后基于最大块-查询相似度找到上下文。RAPTOR将文档块聚类成层次结构，并使用大型语言模型（LLM）总结这些簇作为额外上下文。GraphRAG从使用大型语言模型构建的知识图中检索信息，通过提取实体和关系并将它们聚类成语义社区。对比结果看，效果都更好。
二、引入反馈的HYBGRAG方案
接下来第二篇，现有的RAG方法通常只关注文本或关系信息的检索，无法有效结合两种信息；在混合问题中，不同类型信息的检索边界可能不明显，导致检索错误。
所以可以看下面这个图，
(a) RAG忽略了文档之间的相互联系，无法满足关系方面所指定的要求。
(b) GRAG仅依赖关系方面，并将文本方面错误地识别为关系方面的一部分。
因此可以看看这个工作，《HYBGRAG: Hybrid Retrieval-Augmented Generation on Textual and Relational Knowledge Bases》(https://arxiv.org/pdf/2412.16311)，提出HyBGRAG用于解决混合问答问题，通过自我反思优化问题路由，从而缓解这个问题。
可以看看具体思路：
为了解决混合问题，HyBGRAG设计了一个检索器，包括多个检索模块和一个路由器。每个检索模块可以是文本检索模块或混合检索模块，分别用于从文本文档和知识库中检索信息。
文本检索模块使用向量相似性搜索（VSS）从文本文档中检索信息，而混合检索模块则利用图检索器从知识库中提取实体和关系。路由器根据问题的类型选择合适的检索模块。
具体来说，路由器首先识别问题中的关系实体和有用关系，然后决定使用文本检索模块还是混合检索模块。
这块首先会启动第一次检索，对应prompt如下：
批评反思模块（Critic Module）提供反馈以帮助路由器更好地进行问题路由，分LLM验证器（Cval）和LLM评论器（Ccom）两个部分，验证器检查检索结果的准确性，评论器提供纠正性反馈以改进问题路由。
LLM验证器负责检查检索结果的准确性，判断检索到的文档是否满足问题的要求。
如果检索结果不正确，LLM评论器会提供纠正性反馈，帮助路由器改进问题路由。
也就是，LLM评论器会指出检索结果中的错误或遗漏，并给出具体的修改建议，如替换错误的实体或关系、补充缺失的实体等。
HyBGRAG通过自我反思迭代改进其问题路由。每次迭代中，路由器根据评论者的反馈调整其选择和使用的检索模块，从而逐步提高检索结果的准确性。但这个明显会很慢。
下面是一个具体的例子，每个Action都有一个selection，用来表示问题路由所选择的检索模块：
总结
本文主要介绍了关于RAG的两个进展，都是知识图谱跟RAG之间的结合思路。第二个工作其实本质也是引入了一个Refine反思模块，对检索到的内容进行修正，但这个对于修正模块的要求很高。
参考文献
1、https://arxiv.org/pdf/2412.16311
2、https://arxiv.org/pdf/2412.15235
关于我们
老刘，NLP开源爱好者与践行者，主页：https://liuhuanyong.github.io。
对大模型&知识图谱&RAG&文档理解感兴趣，并对每日早报、老刘说NLP历史线上分享、心得交流等感兴趣的，欢迎加入社区，社区持续纳新。
加入会员方式：关注公众号，在后台菜单栏中点击会员社区->会员入群加入
