从RAG到GraphRAG的应用落地揭秘

在讨论RAG和GraphRAG之前

ChatGPT带来的变革，其深远程度已经足以被称作第三次工业革命。如今，连老一辈都在用ChatGPT查问题——各个年龄段、各行各业，使用面还在不断扩大。

为什么能这么普及？核心在于它能精准地抓住用户想要什么。在这个信息爆炸的时代，能有选择性地给出“必要”的信息，本身就是一种稀缺能力。

但话说回来，目前的进展虽然亮眼，问题也不少。最典型的就是“幻觉”——模型一本正经地给出错误信息。原因五花八门，其中一个关键因素是模型错误理解了用户意图，从而提取到了不相关的内容。

围绕这个目标，业界主流有四种改进路径：

• 1. 从零开始构建大模型
  ，数据背景一开始就清晰，但成本高得吓人。

• 2. 用现成的大模型，在特定领域继续训练
  ，成本可控、准确度也不错，但难点在于平衡模型的通用知识和领域特定知识。

• 3. 用大模型，但在用户提问时额外添加上下文
  ，成本低，不过有主观性和潜在偏见的风险。

• 4. 保留大模型，在生成回答时提供“相关信息”作为额外上下文
  ，响应及时、成本友好，但挑战在于如何识别和整合相关文档。

这四种方法可以从五个维度来比较：

。

详细对比可以参考这篇文章：https://deci.ai/blog/fine-tuning-peft-prompt-engineering-and-rag-which-one-is-right-for-you/。

对RAG的简要介绍

RAG，全称是检索增强生成。说白了，就是一种能够“很好地”理解用户查询、检索“相关”信息、将其加工成上下文，然后把这些有用的信息整合到回答里的技术。

投入产出比相当可观——成本低、准确度不错、能提供领域特定语境、能反映最新信息，还能追踪信息来源，透明性和可解释性都很好。

图1，RAG操作流程

关键在于：正确解析查询、获取相关信息、并把它处理成可用的上下文。

如图1所示，从用户查询到生成响应、再到把响应传回给用户，这个链路上多了一个关键的步骤——检索模型提取查询的相关信息。上述三个元素都在这个新增的检索模块里完成。

为了把这三个任务执行好，整个流程被拆分为四个阶段来实施和优化：

预检索

数据粒度，指的是RAG模型在检索时搜索数据的精细程度，在正式检索之前就需要做预处理。

RAG模型结合了大语言模型和检索组件的优势，通过搜索文本片段（句子、段落或整篇文档）来获取相关信息，进而生成回答。

数据粒度可以是句子级别（比如某个事实、一句话、一小段），也可以是段落级别（整篇文章或整份文档）。粒度的选择直接影响模型的性能和生成文本的准确度与上下文相关性。

精细的数据能为生成任务提供更具体、更详细的信息；粗粒度的数据则能提供更广阔的上下文或通用知识。

选择合适的粒度是优化RAG模型的关键——需要在“提供足够详细的相关信息”和“避免数据过载或过于泛化导致无用”之间找到平衡。

切块

这一步是把源数据处理成适合大模型输入的格式。因为大模型能处理的token数量是有限的，所以正确地分割和输入信息非常重要。

可以用对话来理解：假设有两个人聊天，理想状态下对话时间均匀分配。如果一个人说了59分钟，另一个人只说1分钟，这就不叫对话，而是信息灌输。反过来，如果每人各说30分钟，信息均衡交换，才算高效沟通。

给大模型喂“好”信息，关键就是要提供“适当”的上下文。既然长度（token数）有限，那就要在给定的上下文限制内，保留信息之间的有机关系。这也就引出了一个问题：在处理相关数据时，

始终是个绕不开的坎。

检索

这个阶段的任务，是在文档或文本片段库里搜索与用户查询相关的内容。包括理解查询的意图和上下文，根据这些理解从数据库里挑出最相关的文档或文本。

举个例子，用户问的是“绿茶的健康益处”，模型就会去找提到绿茶健康好处的文档，然后根据相似度指标把它们选出来。

检索后

这个阶段是对检索到的信息进行深加工，以便有效整合到生成过程中。可能包括对搜索文本做概述、筛选出最相关的事实、对信息做精炼，使其更贴合用户的问题。

比如，分析了关于绿茶健康益处的几份文档之后，可以总结出核心要点：“绿茶富含抗氧化剂，能降低某些慢性病风险，改善脑功能”——这样就能给用户一个全面又有信息量的回答。

RAG 的限制

RAG在成本、时效性和领域适应性上确实高效，但它也有自己的硬伤。下面的这张图把RAG过程中的痛点梳理得很清楚，我们就围绕它来分析几个代表性的限制。

1. 缺少内容：
   第一个限制——相关文档根本没被索引到，因此无法提供上下文。数据明明认真预处理过、也正确存进了数据库，但就是用不上，这无疑是重大缺陷。

2. 错过排名靠前的文档：
   第二个问题——相关文档确实被检索到了，但相关性排名太低，导致最终答案无法满足用户期望。问题根源在于“到底检索多少个文档”这个k值设定带有主观性，需要通过反复实验来确定。

3. 不在上下文中——合并策略的限制：
   包含答案的文档被检索到了，却没有被放到生成答案的上下文里。当返回的文档数量过大时，就需要做合并处理来筛选最相关的信息。

4. 未提取：
   这是大模型的一个根本性限制——它倾向于检索“近似值”而非“精确值”。获取“近似”或“相似”的值，很容易引入不相关信息，对后续回答质量造成重大影响。

5. 错误格式：
   与指令调优密切相关。指令调优是通过使用指令数据集对大模型进行微调来提升零样本性能的方法。但如果额外指令在提示词中格式不对，就会导致模型误解或错误解释，最终给出错误答案。

6. 准确性不足：
   第六个问题——要么没有充分利用用户查询信息，要么过度使用，在权衡查询重要性时出了问题。这通常发生在输入和检索输出的组合不当的情况下。

7. 不完整：
   第七个限制——虽然可以用上下文来生成答案，但因为信息缺失，导致对用户查询的回答不完整。

1. 索引化——能否检索到与用户查询相关的文档；
2. 在生成答案之前，能否提供正确信息；
3. 输入与检索前/后的组合是否恰当。

这三个因素，恰恰是RAG的核心所在，也提出了一个根本问题：如何改进？

什么时候用GraphRAG

GraphRAG可以从预检索、检索后和提示压缩的角度，结合知识图谱的检索和推理能力，来应对RAG的一些短板。

图谱检索专注于通过获取相关信息来增强上下文；图谱推理则适用于RAG中的信息遍历和搜索——比如切块和上下文输入。

可以借助知识图谱索引来获取相关文档。通过在知识图谱的节点和边上对文档进行语义索引，可以直接检索到语义相关的文档。

这个过程涉及一个选择：是提取节点，还是提取子图？

提取节点，就是把用户查询和分块后的节点做比较，找到最相似的节点，然后把它们的连接路径作为查询语法。

但这种方法需要指定要获取多少个路径内的节点，而且高度依赖用于创建知识图谱的信息提取模型——模型性能至关重要。

此外，Variable Length Edges（VLE）也可以用来获取相关信息，这需要对数据库做优化以实现高效检索。数据库设计和优化的讨论，需要数据库管理员和机器学习工程师共同参与。

提取子图，则是获取与相关节点相连的自我图，可以嵌入多个相关的自我图，与用户查询做整体上下文比较。这种方法需要做各种图嵌入实验，因为不同的嵌入技术性能差异很大。

涉及重排序的过程，和GraphRAG的值结合使用来生成上下文。通过利用GraphRAG的语义搜索值和RAG的相似性搜索值，可以生成上下文。GraphRAG的值能够验证检索的语义基础，提高信息获取的准确性。

在同一数据库中同时使用vectorDB和GraphDB，可以同时实现语义（GraphRAG）和向量（RAG）索引，方便验证检索准确性、修正不准确之处。

在提示工程中受益于图信息，比如决定哪些分块信息应该注入到提示词中。

图谱使得检索后只返回相关信息成为可能——基于查询上下文和文档之间的关系。这样就可以追踪无关信息的来源，持续改进。

举个例子，如果生成了不合适的回答，可以用图查询回溯到问题所在，立即进行修正。

GraphRAG 架构

执行GraphRAG时有4个模块：查询重写、增强、检索，以及语义搜索和相似性搜索。

查询重写

这个过程是对用户查询进行重新实现。如果用户向引擎写了一条指令，可以在其查询提示格式中添加额外有用的上下文。在这个过程中，重新定义这些事情，以澄清用户的意图。

检索前 & 检索后

这个阶段主要考虑两件事：要检索什么信息，以及检索后怎么处理这些信息。

在预检索阶段，重点集中在决定分块大小、如何进行索引、确保数据清洁，以及检测和删除任何不相关数据（如果有的话）。

在检索后阶段，挑战在于如何有效地协调数据。主要涉及两个过程：

。在提示压缩中，查询结果（特别是图路径）被用作上下文+提示的一部分来生成答案。重排序利用图嵌入和大模型嵌入的结果，以提高排名的多样性和准确性。

这种方法在提高生成答案的性能和相关性方面具有战略意义——确保过程不仅获取了相关信息，还能有效整合信息，产生连贯且上下文准确的响应。

让GraphRAG就绪的关键因素

要有效存储、管理和检索图谱数据，需要具有反映数据独特特性的软件。就像关系数据库管理系统（RDBMS）能高效管理表形数据一样，图数据库管理系统（GDBMS）就是用来处理图形数据的。尤其在知识图谱推理的背景下，如果数据库没有针对图形结构做优化，通过连接操作逆转相关性的成本会显著增加，可能导致瓶颈。

因此，在GraphRAG中，GDBMS在管理所有这些方面时，效率至关重要。为了检索图谱，还需要一个能生成图谱查询的模型。虽然可能清楚哪些数据相关，但自动获取特定数据点的关联数据，这个过程至关重要。这需要专门用于生成图谱查询的自然语言处理模型。

遗憾的是，目前缺乏用于图谱查询生成的数据集，数据获取的紧迫性显而易见。Neo4j已经通过启动数据众包计划迈出了一步，有兴趣参与的人可以通过提供的链接进一步了解。

关于提取信息以创建图谱形式，需要一个信息抽取模型来推断精心分块的文档之间的关系。

可以考虑两种主要方法：使用自然语言处理（NLP）的命名实体识别（NER），或使用基于知识图谱的基础模型。每种方法差异显著。

NLP的重点是从文本角度提取语义，严重依赖于词语之间的预定义依赖关系。而由基于知识库的基础模型构成的知识图谱，则侧重于节点，并且可以调节边缘之间传输的信息量。

为了嵌入图谱数据，需要使用模型向Reranker添加额外的上下文——通过图嵌入提供整体视角。这与大模型侧重于时间关系的序列视角有所不同。图嵌入使得结构特征得以灌输，补充了侧重于时间关系的序列视角，同时确保所有块（节点）都得到平衡的图谱视角代表，从而填补可能遗漏的信息。

GraphRAG 的限制

GraphRAG和RAG一样，也有明显的局限性：如何形成图谱，如何生成用于查询这些图形的查询，以及最终根据这些查询决定检索多少信息。

主要挑战是“查询生成”“推理边界”和“信息提取”。特别是“推理边界”提出了重大限制——优化相关信息的数量可能会导致信息检索期间负荷过大，反而对GraphRAG的核心——答案生成产生负面影响。

应用GraphRAG

GraphRAG利用GNN（图神经网络）结果的图嵌入来增强文本嵌入，以用户查询回应推理为主。这种方法被称为软提示，是提示工程的一种。提示工程可以分为硬提示和软提示两类。

需要明确提供提示，也就是手动把提示添加到用户查询中。这种方法实现起来很直接，但缺点是提示的创建有主观性。

相反，

是隐式提供提示——通过将额外的嵌入信息添加到模型的现有文本嵌入中，从而得到类似的推理结果。这种方法通过使用“学习到”的上下文嵌入来确保客观性，并且可以优化权重值。但代价是，它需要直接进行模型的设计和实现，更加复杂。

何时使用GraphRAG

• GraphRAG并非万能解药。
  在没有明确需求的情况下，不建议用GraphRAG这样的高级技术，尤其是传统RAG表现良好时。引入GraphRAG应该以事实为依据，特别是当检索阶段获取的信息与用户查询意图不匹配时。这本质上就是向量搜索的根本局限——基于“近似”值而非“精确”值来检索信息，容易导致不准确。
• 当引入BM25进行精确搜索、改进排名过程或对嵌入质量进行微调等努力，都没有明显提升RAG性能时，或许才值得考虑GraphRAG。

总结

这篇文章从RAG讲到了GraphRAG，覆盖了微调、从零构建、提示工程和RAG等方法，以及如何提升响应质量。RAG因为能以相对较低的成本高效获取相关文档来回答查询而备受推崇，但在检索过程中也面临若干限制。

GraphRAG作为RAG的进阶版本，通过利用“语义”推理和检索来克服这些限制，成为一个有效的解决方案。有效利用GraphRAG的关键考虑因素包括：信息提取技术（用于推断和生成分块数据之间的连接）、知识索引（用于存储和检索），以及用于生成图查询的模型（如Cypher生成模型）。

新技术层出不穷，希望这篇文章能成为关于GraphRAG的一份参考资源，帮助你更熟悉这种先进的方法。感谢阅读。

引用

• https://medium.com/@bijit211987/top-rag-pain-points-and-solutions-108d348b4e5d
• https://luv-bansal.medium.com/advance-rag-improve-rag-performance-208ffad5bb6a
• Barnett, Scott, et al. “Seven failure points when engineering a retrieval augmented generation system.” arXiv preprint arXiv:2401.05856 (2024).
• https://deci.ai/blog/fine-tuning-peft-prompt-engineering-and-rag-which-one-is-right-for-you/
• Luo, Linhao, et al. “Reasoning on graphs: Faithful and interpretable large language model reasoning.” arXiv preprint arXiv:2310.01061 (2023).
• https://towardsdatascience.com/advanced-retrieval-augmented-generation-from-theory-to-llamaindex-implementation-4de1464a9930