HybGRAG：Hit@1 的平均相对提升率达到 51%的新思路

发布时间：2024 年 12 月 20 日

RAG

HybGRAG: Hybrid Retrieval-Augmented Generation on Textual and Relational Knowledge Bases

给定一个半结构化知识库（SKB），其中文本文档通过关系相互连接，怎样才能有效地检索相关信息来回答用户的问题呢？检索增强生成（RAG）会检索文档来辅助大型语言模型（LLM）回答问题；而图 RAG（GRAG）则以结构化知识库作为知识源。然而，很多问题都需要 SKB 中的文本和关系信息，即所谓的“混合”问题，这让检索过程变得复杂，也凸显出需要一种能利用这两种信息的混合检索方法。在本文中，通过实证分析，我们得出了关键见解，说明了为何现有方法在处理 SKB 上的混合问答（HQA）时可能会遇到难题。基于这些见解，我们提出了用于 HQA 的 HybGRAG，它由检索器组和评论模块构成，具有以下优点：（1）具有智能性，能结合评论模块的反馈自动优化输出；（2）具有适应性，能通过检索器组解决需要文本和关系信息的混合问题；（3）具有可解释性，能通过直观的优化路径为决策提供依据；（4）具有有效性，在 HQA 基准测试中超越了所有基线。在 STaRK 基准测试的实验中，HybGRAG 取得了显著的性能提升，Hit@1 的平均相对提升率达到 51%。

https://arxiv.org/abs/2412.16311

picture.image

如遇无法添加，请+ vx: iamxxn886

添加请注明：RAG

传统RAG存在的问题

检索增强生成（Retrieval-Augmented Generation ,RAG）能让大型语言模型（LLMs）从非结构化文档数据库 获取信息，使得LLMs 就能处理未知事实，并借助额外的文本信息解决开放域问答（Open-Domain Question Answering，ODQA）问题。

图检索增强生成（Graph RAG，GRAG）从结构化知识库中检索信息，其中的文档通过关系相互关联。现有的 GRAG 方法主要集中在两个方向：

• 从知识图谱（Knowledge Graphs，KGs）中提取关系信息，并利用 LLMs 进行知识库问答，以及在数据库中的文档间建立关系以提升 ODQA 性能。
• “混合”问答（Hybrid Question Answering，HQA）：给定一个半结构化知识库（Semi-structured Knowledge Base，SKB），通过结构化数据和文本数据共同完成一个问题的答案。SKB 由知识图谱（也就是结构化数据库）和非结构化文本文档构成，其中文本文档与 KG 的实体相关联。

picture.image

但是，通过现有分析表明，现有的RAG或者GRAG都无法有效解决HQA问题：

• 其一，这两种方法只专注于检索文本或关系信息。
• 其二，在混合问题中，检索不同类型信息所需的方面可能难以区分。如上图，通过问题路由识别问题。但在不成功的路由中，文本方面“纳米流体传热论文”和关系方面“由 John Smith 撰写”之间的混淆会导致不正确的检索。

什么是HYB GRAG?

为解决 SKB 中的 HQA，我们提出 HYB GRAG（HYBrid Graph RAG）。HYB GRAG 利用检索器库处理混合问题，同时利用文本和关系信息。总体上，HYB GRAG有以下特点：

• 智能体（Agentic）：通过自我反思自动优化问题路由；
• 自适应（Adaptive）：通过统一框架解决文本、关系和混合问题；
• 可解释（Interpretable）：通过直观的优化路径证明决策的合理性；
• 有效（Effective）：在真实世界的 HQA 基准测试中优于所有基线。

2.1 HQA面临的两个问题：

2.1.1 C1: 混合来源问题（Hybrid-Sourcing Question）

作者通过一系列实验，证明了HQA需要同时借助文本和关系信息来回答混合问题，表明文本文档和知识图谱（KG）包含有用但不重合的信息。

结果表明：

• 向量相似度搜索（Vector Similarity Search，VSS）作为仅使用文本信息的检索器，通过在嵌入空间中对比问题与文档来进行检索和排序；
• 个性化 PageRank（PPR）：作为仅使用关系信息的检索器，从 LLM 识别出的实体出发进行随机游走，并依据它们在 SKB 的 KG 中的连通性对相邻实体进行排名。

picture.image

如上图，文本和关系检索器的性能不相上下。如果最优路由总是选择能给出正确结果的检索器，性能会大幅提升，这表明文本和图形检索器的优势几乎不存在重叠。表明通过协同这两个检索器来同时利用文本和关系信息的解决方案的重要性。

2.1.2 C2：需要改进的问题

KBQA 的成功往往依赖于这样一个假设：目标实体处于从知识图谱（KG）中抽取的子图内。同样，在 HQA 中回答问题需要从 SKB 里的 KG 抽取子图。

由于混合问题兼具文本和关系两方面，因此作者测试 LLM 能否从 KG 中抽取包含目标实体的子图 。

1. 通过提示词识别问题中的关系层面，即实体和用于抽取子图的有用关系。
1. 若目标实体不在子图中，则利用一个通过提示词进行带有反馈的额外迭代。

picture.image

如上表：

• （第二行）若结果有误，单纯提示 LLM 重新抽取会获得更高的命中率。
• （第三行）如果 LLM 收到指出抽取错误部分的反馈（比如，抽取的主题实体有误），结果会显著提升。这是因为在包含文本和关系方面的混合问题中，LLM 可能会误将文本方面当作关系方面。

所以第二个挑战：在 HQA 中，LLM 首次尝试时难以区分问题的文本和关系方面，故而需要进一步完善。

2.2 针对C1提出的新的检索库架构

HYB GRAG的检索模块由多个检索模块和一个路由器构成的检索器库。

设计了两个检索模块，分别是文本检索模块 和混合检索模块 ，用于从文本文档和 SKB 中获取信息。每个检索模块均包含一个检索器和一个排序器，用来应对各类问题提供了灵活性。

• 文本检索模块 ：通过针对给定问题 Q 的相似性搜索来检索文档，比如密集检索，直接在文本文档中找到答案。
• 混合检索模块 ：将识别出的实体 E 和有用关系 R 作为输入。使用图形检索器提取由 R 连接的 E 的自环图中的实体。
• 路由器 ：给定一个问题 Q，LLM 路由器执行问题路由来确定检索模块的选择和使用。路由器首先依据实体类型和关系类型，借助少量示例识别关系方面，即实体 E 和有用关系 R 。然后路由器做出选择，决定采用文本检索模块还是混合检索模块。

2.3 针对C2提出的评论模块

给定一个混合问题 Q，路由器需执行问题路由，包括识别实体和有用关系。但在首次迭代中它们可能会被错误识别。

为解决此问题，提出评论模块，能提供反馈以助力路由器更好地执行问题路由。作者没有直接采用单个 LLM 完成这一复杂任务，而是将其分为两部分：

• 即 LLM 验证器用于验证检索结果的正确性
• LLM 评论员用于在检索有误时提供反馈

这种分治策略，具有两大关键优势：

• 1.将难题分解为两个较易处理的任务，能借助 LLM 来解决，同时保持良好性能。
•

1. 由于验证和评论的任务相互独立，各自可有专属上下文，避免包含无关信息及“Lost in the Middle”的现象。

2.3.1 验证器 LLM

验证器的目的是验证检索到的顶级参考文献是否符合问题 Q 的要求，属于二分类任务。为提高准确性，为验证器提供额外的验证上下文。将主题实体与提取的自我图中实体间的推理路径用作验证上下文，用于检验输出是否满足问题中的某些要求。

2.3.2 评论员 LLM

picture.image

评论员旨在提供反馈以协助路由器优化问题路由。为有效引导路由器，构建易于理解的纠正性反馈。会指出每个动作中的错误，如实体的错误识别（上表展示了识别错误的分类）。

与可能因使用的 LLM 而导致不确定性或不一致的自然语言反馈不同，纠正性反馈为如何优化问题路由提供了明确指引。此外，它借助上下文学习（ICL）提供精细的反馈。

效果评估

3.1 HYB GRAG 在现实世界的 GRAG 基准测试中的表现怎样？

picture.image

如上表，HYB GRAG 在 STARK 的两个数据集中均显著优于所有基准方法。大多数基准方法是为处理 ODQA 和 KBQA 而设计的，结果表明它们无法有效处理 HQA。

混合检索模块表现位居第二，表明能同时运用文本和关系信息的协同检索模块的重要性。

HYB GRAG 的表现明显优于混合检索模块，意味着在首次迭代中提取的实体和关系常常有误。

通过分别利用HYB GRAG检索器库和评论模块应对挑战 1 和 2，HYB GRAG 的性能有了显著提升。

3.2 消融研究：HYB GRAG 的所有设计选择是否必要？

3.2.1 评论模块

把 HYB GRAG 变体与没有验证上下文的验证器、仅有五次示例的评论者的情况进行对比。

picture.image

从上图可以看出，在所有的设计选择下，HYB GRAG 表现最佳，接近标准性能。

3.2.2 自我反思

picture.image

从上图可以看出，随着更多的自我反思迭代，HYB GRAG 的性能进一步提升。当迭代次数从 1 增加到 2 时，性能显著提高，其中第 1 次迭代未进行自我反思。同时表明，几次迭代就已足够，因为随着迭代次数增多，改进逐渐减小。

3.3 可解释性：HYB GRAG 如何依据反馈优化其问题路由？

picture.image

上图展示了 STARK-MAG 中检索器库的路由器与评论模块相互作用的实例。

上图左侧的首轮迭代中，路由器误将“电子电路中的光学 TALU 实现”认定为代表研究领域的主题实体（关系方面）。由于基于此实体提取的图和基于“Netaji Subhash 工程学院”提取的图无交集，评论模块判定前一实体更可能是文本方面。于是，它向路由器反馈，路由器也相应地进行处理。HYBGRAG 的这种优化路径类似 CoT，具有可解释性，方便用户理解。

3.4 端到端评估

picture.image

上表中，HYB GRAG 在 CRAG 中的表现优于所有基线。

• 具有单个检索模块的 RAG 无法应对两种类型的问题。
• 具有连接参考的 RAG 也会因长参考中的无关内容而分心。
• 即便提供了相同的检索库，自反思基线仍难以优化自身行动。
• 由于 ReAct 依赖于 LLM 的思考能力并提供自然语言反馈，它往往缺少改进行动的明确指引。
• 没有经过微调的检索评估器，Corrective RAG 无法有效识别参考的有用性。这体现了带有纠正反馈的评论模块的优越性。

3.5 模型成本分析

picture.image

上面两个表分别汇总了 STARK 和 CRAG 中 HYB GRAG 迭代各步骤的 API 调用次数和令牌消耗。

尽管大部分令牌消耗源于用于 ICL 的示例，但提示本身所需令牌极少。而且，由于 HYB GRAG 把聊天 LLM 当作路由器，ICL 的示例仅需提供一次。

相较于 STARK 中的最先进基线 AVATAR，其训练时至少需 500 次 API 调用，混合检索模块仅 2 次 API 调用，在 Hit@1 上就实现了 24％的相对提升，而 HYB GRAG 最多 14 次 API 调用就能达成 51％的提升，二者均无需训练。

• 论文原文: https://arxiv.org/abs/2412.16311
• 获取更多最新 Arxiv 论文更新: https://github.com/HuggingAGI/HuggingArxiv!
• 加入社群，+v: iamxxn886
• 点击公众号菜单加入讨论

picture.image