Preview

从 RAG 到 GraphRAG

在信息爆炸的时代，如何快速、准确地从海量数据中定位所需内容至关重要。对于法律领域而言，这一点尤为突出，因为法律条文、案例等信息复杂且关联性强。传统检索方法往往难以满足这一需求，而 检索增强生成（Retrieval-Augmented Generation, RAG）技术为此提供了新的思路。本文将深入探讨 RAG 的整体流程，并分析传统分块方法在构建法律知识库时的局限性。随后，我们将引入知识图谱的概念，展示如何通过 GraphRAG 方法提升法律知识库的检索准确率。

RAG 流程简介

RAG 是一种结合检索和生成的技术，旨在利用外部知识来增强大型语言模型（LLM）的生成能力。其基本流程如下：

1. 检索（Retrieval）： 当用户提出问题时，RAG 系统首先会根据问题从外部知识库中检索相关文档或信息片段。
2. 增强（Augmentation）： 将检索到的信息与用户的问题一起输入到 LLM 中。
3. 生成（Generation）： LLM 基于问题和检索到的信息生成最终答案或文本。

RAG 的优势在于能够利用外部知识弥补 LLM 自身知识的不足，从而大幅提高生成内容的准确性和可靠性。

传统分块方法的局限性

在构建法律知识库时，一种常见的做法是将法律文档分割成若干较小的文本块（chunks），并将这些文本块存储在向量数据库中。这种方法虽然简单易行，但也存在一些明显的局限：

• 语义丢失： 文档分割会削弱整体语义的连续性，导致检索时难以准确定位用户问题的上下文。
• 关联性缺失： 法律文档中的信息往往相互关联，而分块方式易忽略这种紧密的交叉引用，对检索的完整性和准确性造成不利影响。
• 长文本处理困难： 对于长篇幅的法律文档，分块后会产生大量碎片化文本，进而影响检索效率。

如何优化

自动分块策略

以下列举了实践中能有效解决上述“语义丢失”和“长文本”问题的常用增效方法：

1. 数据清洗

   • 不要直接使用 PDF 文件进行自动化分块，而是先通过 MinerU + 手工校对结构的方式，在本地导出为 markdown 文件，再以 markdown 文档为最小单位开启知识库构建。
   • 对图片型 PDF 保持警惕：从外表看似纯文本，实际上可能无法被自动分块（识别出的分块数为 0），需要带 OCR 功能的工作流（如 MinerU）进行处理。
   • 对表格型 PDF 保持警惕：当 PDF 内仅含一个复杂表格且内容极长（tokens 超过 1 万），需要手动拆分。可将表格转换为“类 YAML”格式，使每一行成为一个独立分块。

2. 分块策略

   • 窗口长度优先： 对于不超过嵌入模型最大窗口长度的法规文件，不建议分块，整份文档可视为一个块。

   • 补全子块的上下文语义： 当一个法规文件的 total_tokens 远超模型最大窗口时，需要分块。先将各文档统一为 markdown 或 txt 格式，方便校对。每个子块应完整保留文件名称、章节名（若有）、条款序号和条款正文，最后使用 XML 标签封装。例如：

     已复制!

     <doc source-of-law="《部门规章——证券期货投资者适当性管理办法》">
     第十二条 普通投资者申请成为专业投资者应当以书面形式向经营机构提出申请并确认……
     </doc>

   • 子块独立性： 按照上述规则切分的分块应满足 overload=0 的条件。对于一则法条，通常很难超过 8192 tokens（约 7K 汉字）这一门槛。

3. 模型选择（2024-12-31）

   • 使用上下文窗口为 8192 的 embedding 模型，如：jina-embedding-v3，bge-m3。
   • 避免使用分数虽高但极度消耗资源的模型，如 gte-Qwen。

场景切换

对于少量文档或单篇文档的场景，可选用如 gemini-2.0-flash-exp 这类支持 1M tokens 上下文窗口的模型，将文档内容以系统提示词的方式融入请求，实现基于文档的问答。此方法将 RAG 检索式问答转换为“Chat with files”的对话式问答，有助于显著提升召回率。然而，当文档数量增加至 30 篇以上，形成文档集合规模，总 tokens 数达到数十万级别时，“全量上下文”的输入方式将严重影响推理效率，且大模型的回答质量亦会出现明显波动。

知识检索阶段

向量相似度与关键词的配比，0~1，调着看，没有固定结论。

对话阶段

将 Temperature（温度）设为 0。

增效有限的改动

前述方法尽力保证每个块的语义完整性，并能在“临时问答”和“长文本”场景中灵活切换。

在文本分块 RAG 方法中，对于一次“法律查询”，如果检索能够正确召回最相关的分块，那么这些分块通常已包含回答该查询所需的信息，不会出现法条条款缺失或法条被拆散的情形。

那么，法律知识 RAG 的真正难点在哪里呢？一句话总结：找得到，但是找不对也找不全。

在 RAG 为大模型提供对话上下文时，实际只会选取知识库中最相关的若干内容，而非整个知识库。如果在第一步 Retrieval 阶段无法通过语义匹配获取回答问题所需的全部关键信息，那么后续的问答流程质量将大大受限。

对于法律知识库而言，文本通常具有极高的语义复杂度。仅依赖字面相似度进行检索，往往无法准确召回所有关键细节。举例来说，一项法条可能会引用另一部法律的具体条款，或者使用别名来指代当前后文的部分内容。基于连续文本分块+分块向量相似度的检索方式，难以捕捉此类跨文档引用或字面别名索引等复杂场景。

无解的环

举个例子，以下是 《私募投资基金募集行为管理办法》 第三十七条，主要内容是违反前文法条的处罚规定。从条款序号和“行文距离”来看，这些前文条款距离“37”都非常远（内容比较多的规章制度会按章节编排内容，处罚条款通常集中在文档尾部），按照连续文本分块方法（无论是设定多少比例的 overlap，还是根据语义分块）绝无可能将关联信息绑定到一起。

如果系统输入与《管理办法》「第二十四条」语义匹配，系统通常能成功召回相关文本块；然而，相关的处罚规定「第三十七条」仅以索引（如“条款序号”）关联前述内容，而非语义上的直接关联，在基于相似度的检索中，该条内容极易被忽略，导致最终生成结果缺失关键的上下文信息。

举几个分分钟把现有 RAG 系统干宕机的问题，有助理解现阶段构建法律知识库的难点所在：

• 我在微信号短视频看到一个金融机构的同学在推广他家的私募产品，但看起来仅我可见，这不合适吧，他这个行为违规吗？
• 我有一个朋友，不小心把推介用的宣传材料发到一个微信群里了，这群里除了客户好像还有客户家属，这合规吗？
• 我想举报一个小红书博主，他在平台宣传推广某只私募基金产品，还晒了收益。这应该违规了吧，相关的处罚条款我可以在哪里找到？具体怎么罚？但是如果他不属于金融行业的从业人员，只是个客户，是不是啥事没有？
• 微博上有个自称是某某金融机构员工的人发了一条帖子，里面有几张截图出现了私募排排网制作的图片，并且关键收益信息未打码。这个行为合规吗？

想要回答以上给出的问题，你可能需要全面了解基金业的法规条款才能给出完整的解。

再举一个比较生活化的案例：

用户询问“开车玩手机会扣多少分？”这个问题，如果所有答案都集中在一个chunk里，例如“玩手机扣两分”，那么基于现有LLM+RAG的技术，模型可以轻松给出正确答案。但是，如果信息分散在不同的chunk中，比如chunk:1只提到“驾驶时不应玩手机”，而chunk:2在很远的位置才提到“违反chunk:1规定将扣两分”，问题就来了。模型很可能知道不能玩手机，但在被问到扣分时，要么会编造一个分数，要么会含糊其辞，表示规定中没有明确说明扣分情况。

再看一个 数据孤岛 案例：

以下是 《私募投资基金募集行为管理办法》 的文末，使用“本办法”来指代《管理办法》。按照 RAG 的算法流程，这个分块会烂在知识库里，它几乎不会被正常的 query 召回，一旦被检出必定污染模型的上下文。

结论

在 RAG 系统中，分块策略是影响检索效果的关键因素。无论是通过 overlap 来保证相邻分块间的上下文连贯性，还是采用语义分块来获取更自然的切分边界，其核心目标都在于解决 连续文本 的分块问题。 这些方法有效地提升了局部上下文的捕捉能力。然而，当面对那些结构复杂、前后呼应，甚至全文紧密相连的文档，比如一篇深度研报、一本结构精巧的小说，甚至是逻辑严密的论证文章时，这些线性分块策略就显得力不从心了。这些高维度、非线性的信息依赖于全局结构和上下文，而基于顺序的分块方法，无论如何优化，都难以有效地捕获这些跨分块的依赖关系，这揭示了现有分块方法的局限性。

这种“字面索引”式的文本表达，虽然蕴含回答问题所需的关键信息，却常因语义相似度评分不足而无法被直接召回，从而导致检索和后续回答生成的准确度受限。

因此，在构建知识库的阶段引入知识图谱，正是为了解决这类“字面索引”的检索需求。简单来说，通过大模型与图搜索算法，将海量实体信息及背景知识加入库中；在检索时再“按图索骥”，精确定位所有与“字面索引”相关的文本分块，从而更完整、准确地支撑后续的回答生成。

引入知识图谱

为克服传统文本分块方法在处理复杂法律文本时语义理解和关联性不足的缺陷，可考虑利用知识图谱构建结构化、语义关联性更强的法律知识库。

What: 什么是知识图谱？

知识图谱是一种有向加权图，由以下要素构成：

• 实体节点 (Entity Nodes)： 代表法律文本中提取的关键实体，例如：当事人、法律条款、案件类型等。每个节点都附带有丰富的描述性文本，包含实体名称、类型、摘要等信息。这些描述性文本由大型语言模型（LLM）生成，旨在保留原文本的语义信息，同时提供适合模型推理的表达形式。
• 关系边 (Relationship Edges)： 表示实体之间的关系，例如：法律条款之间的引用关系、当事人与案件的关联关系等。关系边同样附带有描述性文本，详细说明实体之间的具体联系，这也有助于LLM更好地理解实体间的交互。边的权重则反映了关系出现的频次，经归一化处理。
• 属性 (Covariates)： 与实体或关系相关联的额外信息，例如：法律条款的生效日期、案件的判决结果等。属性信息以键值对形式存储，可作为辅助信息参与后续的检索和推理。

此知识图谱的构建过程并非人工标注，而是通过一系列定制化的 LLM 提示词完成。LLM首先从原始法律文本中提取实体、关系和属性，然后生成对应的文本描述，最后将信息整理为图结构。此过程旨在自动化知识图谱构建，并使其具备一定的领域自适应性

Why: 为什么知识图谱可以提升检索准确率？

知识图谱方法在检索准确率上的优势，源于其以下几个关键特性：

1. 显式的语义关联： 知识图谱通过关系边显式地表达了法律文本中实体之间的语义关联，这有助于LLM理解复杂的法律关系，例如：因果关系、包含关系等。传统的文本分块方法往往将文本分割成独立的片段，忽略了片段之间的上下文联系，而知识图谱则可以有效弥补这一缺陷。

2. 模块化结构： 知识图谱会进一步使用社区检测算法（例如：Leiden算法）将其划分为模块化的社区结构。每个社区代表一组紧密相关的实体和关系，并会由 LLM 生成社区摘要。这种层次化结构允许在检索时首先定位到相关的社区，然后再在社区内部检索具体的答案，有效地缩小了检索范围，提高了检索效率和精确度。

3. 支持全局推理： 由于知识图谱以结构化的形式组织了整个法律知识库，而非独立的文本片段，这使得 LLM 可以进行跨文档的全局推理。例如，当用户提问“某项法律条款在不同案件中的应用情况”时，基于知识图谱的检索方法可以有效地汇总不同案件的相关信息，提供更全面、准确的答案，而传统的 RAG 方法难以实现此类全局分析。

4. 适应复杂查询： 传统的关键词检索在处理复杂查询（例如涉及多实体、多关系的查询）时效果不佳，而知识图谱可以通过结构化的查询语言（例如：Cypher）来表达此类查询，这有助于精确匹配用户的意图。

GraphRAG 核心概念

全局问题

在理解 GraphRAG 完整流程之前，我们需要知道 GraphRAG 到底在解决什么问题。

局部问题 (Local Problem):

• 定义： 局部问题指的是那些可以通过在文档集合的局部区域检索信息来回答的问题。换句话说，答案通常包含在文档的某个特定部分，通过传统的检索方法（如基于关键词或语义相似度的检索）可以找到包含答案的文本片段。
• RAG 的能力： 论文指出，传统的检索增强生成 (RAG) 方法在处理局部问题上是有效的。RAG 的设计初衷就是为了解决这类问题，它能够检索到相关的文本片段，并利用这些信息来生成答案。
• 例子（推断）： 虽然论文没有明确给出局部问题的例子，但我们可以推断，像 “X 公司 CEO 是谁？” 或者 “Y 事件发生在什么时候？” 这样的问题，如果答案在文档的某个特定段落中明确提及，就可以被认为是局部问题。

全局问题 (Global Problem):

• 定义： 全局问题指的是那些需要理解整个文档集合才能回答的问题。这类问题无法通过简单的局部检索来解决，因为答案不是明确地存在于某个单一的文本片段中，而是需要对整个语料库进行综合理解和推理。
• RAG 的局限性： 论文明确指出，传统的 RAG 方法在处理全局问题上是失败的。这是因为全局问题本质上是一个query-focused summarization (QFS) 任务，而不是一个简单的检索任务。
• 论文中的例子： 论文给出了一个明确的全局问题的例子：“What are the main themes in the dataset?” (数据集的主要主题是什么？) 要回答这个问题，需要理解整个数据集的内容，提取出主要的讨论方向和概念，而不仅仅是检索某个包含 “theme” 关键词的句子。

总结来说：

• 局部问题 关注的是文档中的具体事实和细节，可以通过局部检索找到答案。
• 全局问题 关注的是文档集合的整体理解和概括，需要对整个语料库进行分析和总结。

完整流程

GraphRAG 的完整流程可以分为三个主要阶段：索引构建阶段（Indexing Time）、流水线处理阶段（Pipeline Stage）和查询阶段（Query Time）。

索引构建阶段 (Indexing Time):

1. 源文档 (Source Documents) -> 文本块 (Text Chunks): 首先，从源文档中提取文本，并将其分割成更小的文本块。论文中提到，文本块的大小会影响实体识别的效果。
2. 文本块 (Text Chunks) -> 元素实例 (Element Instances): 利用大型语言模型 (LLM) 从每个文本块中提取实体、关系和属性等信息，形成元素实例。这个过程可以通过定制 LLM 的提示词来实现，例如提供少量的示例进行上下文学习。
3. 元素实例 (Element Instances) -> 元素摘要 (Element Summaries): 对同一元素（例如同一个实体）的不同实例进行摘要，生成该元素的统一描述。这是对 LLM 提取信息的进一步抽象和整合。
4. 元素摘要 (Element Summaries) -> 图社区 (Graph Communities): 将元素实例构建成图结构，其中节点代表实体，边代表关系。然后使用社区检测算法（例如 Leiden 算法）将图划分为不同的社区，每个社区包含紧密相关的实体。

流水线处理阶段 (Pipeline Stage):

这个阶段主要是社区检测的过程，将图索引划分为不同的社区。

查询阶段 (Query Time):

1. 图社区 (Graph Communities) -> 社区摘要 (Community Summaries): 针对每个图社区，利用 LLM 生成该社区的摘要信息。论文中提出了两种生成社区摘要的方式：
   • 叶子级别社区 (Leaf-level communities): 优先考虑社区内元素的摘要，并迭代地添加到 LLM 的上下文窗口中，直到达到 token 限制。
   • 更高层级社区 (Higher-level communities): 如果所有元素摘要都能放入上下文窗口，则直接进行摘要。否则，对子社区进行排序，并用子社区的摘要替换其包含的元素摘要，直到满足上下文窗口的限制。
2. 社区摘要 (Community Summaries) -> 社区答案 (Community Answers): 当接收到用户查询时，针对每个相关的社区摘要，利用 LLM 生成一个针对该查询的局部答案。LLM 还会为每个答案生成一个 0-100 的评分，表示该答案对回答用户问题的帮助程度。
3. 社区答案 (Community Answers) -> 全局答案 (Global Answer): 将所有评分不为 0 的社区答案按照评分降序排列，并迭代地添加到 LLM 的上下文窗口中，直到达到 token 限制。最后，利用 LLM 对这些局部答案进行总结，生成最终的全局答案。

原子细节

当人类与一个具备知识库检索能力的 Agent 对话时，从人类发送查询到 Agent 开始生成回答，这期间究竟发生了什么？

原子步骤详解：

1. 用户输入问题: 用户向 Agent 输入自然语言问题。
2. 判断问题类型：局部或全局？: Agent 需要判断用户的问题是针对整个知识库的全局性问题，还是针对特定信息的局部性问题。这可能涉及到一些自然语言理解技术。
3. 全局问题处理分支：
   • 根据问题，选择相关的社区摘要: Agent 根据用户的问题，判断哪些图社区可能包含相关的知识。这可能涉及到对问题和社区摘要进行语义匹配。
   • 并行处理每个社区摘要: 为了提高效率，Agent 会并行地处理每个相关的社区摘要。
     • LLM 基于社区摘要和问题生成局部答案: 对于每个社区摘要，Agent 调用 LLM，将社区摘要和用户问题作为输入，让 LLM 生成一个针对该社区的局部答案。
     • LLM 为局部答案评分: Agent 调用 LLM，为每个生成的局部答案打分，评估其与用户问题的相关性和回答质量。
   • 过滤掉评分过低的局部答案: Agent 会根据设定的阈值，过滤掉那些评分过低的局部答案，认为它们对最终答案的贡献不大。
   • 将剩余的局部答案按评分排序: Agent 将剩余的局部答案按照评分从高到低进行排序。
   • 构建包含排序后局部答案的上下文: Agent 将排序后的局部答案放入 LLM 的上下文窗口中。如果答案过多导致超出上下文窗口限制，则会根据评分高低进行截取。
   • LLM 基于上下文生成最终的全局答案: Agent 再次调用 LLM，将包含排序后局部答案的上下文作为输入，让 LLM 对这些局部答案进行总结和整合，生成最终的全局答案。
   • Agent 响应全局答案: Agent 将生成的全局答案返回给用户。
4. 局部问题处理分支：
   • 对用户问题进行向量化: Agent 将用户输入的自然语言问题转换成向量表示。
   • 在图索引中进行向量相似度搜索: Agent 利用问题的向量表示，在图索引（可能是元素摘要的向量表示）中进行相似度搜索，找到与问题最相关的节点或边。
   • 检索到相关的文本块或元素: 根据相似度搜索的结果，Agent 检索到相关的原始文本块或元素实例。
   • 构建包含检索到的信息的上下文: Agent 将检索到的文本块或元素实例放入 LLM 的上下文窗口中。
   • LLM 基于上下文生成答案: Agent 调用 LLM，将构建好的上下文作为输入，让 LLM 生成针对局部问题的答案。
   • Agent 响应答案: Agent 将生成的答案返回给用户。

GraphRAG 工作原理

在知识图谱中，“实体类型”是对实体所进行的分类，例如“法律条文”、“案例”、“法官”、“律师”等。对实体进行类型划分有助于更好地理解和管理图谱信息，其工作原理包括：

1. 分类： 每个实体都会被分配一个或多个类型标签，用于描述其本质属性或角色。
2. 约束： 实体类型对关系具有约束作用。举例而言，“法官”实体只能与“案例”建立“判决”关系。
3. 推理： 借助实体类型，我们能够推断潜在的关联，例如“法律条文”与“案例”存在“引用”关系等。

理解图

为了更好地理解“类GraphRAG”方法，我们可以参考 Response 示例

分块的 content：Entities，Original Content，Community Report

首先，让我们来看看 Knowledge Pipeline 的响应是如何构成的。可以把它想象成一个精心打包的信息盒子，里面装着我们回答问题所需的各种原料。当我们向系统提问时，它会返回一个包含多个信息块的响应。为了更好地理解，你可以参考一个名为 “Response” 的示例文件 (Response)，它展示了典型的 “类 GraphRAG” 方法的基本响应结构。

其中，检索块 (Retrieval Chunks) 是一个关键部分，它是一个列表 (List)，列表中包含多个字典 (dict) 对象。为了兼容传统的 RAG (Retrieval-Augmented Generation) 接口，这个列表通常包含三个固定的分块对象，它们分别是：

• Entities (实体): 这个分块包含了从问题中识别出的关键实体。你可以把它想象成问题中的 “主角”。例如，如果问题是 “苹果公司的 CEO 是谁？"，那么 “苹果公司” 就是一个实体。
• Original Content (原始内容): 这个分块包含了从知识库中检索到的原始文本片段。这些文本片段与问题相关，并可能包含答案。这就好比我们为了回答问题去翻阅书籍，找到了一些相关的段落。
• Community Report (社区报告): 这是 GraphRAG 方法中一个特殊的组成部分，我们将在下一节详细介绍。简单来说，它提供了一种超越原始文本的、更深层次的知识关联。

通过这三个分块，Knowledge Pipeline 能够提供丰富的信息，为生成高质量的答案奠定基础。

关键要素

在 GraphRAG 中，“社区报告” 扮演着一个非常重要的角色。那么，它究竟是什么呢？

简单来说，社区报告是一种浓缩的、结构化的知识表示，它汇总了与查询相关的实体在知识图谱中的邻近信息。 我们可以把它想象成一个小型知识网络的摘要，这个网络围绕着问题中的关键实体构建。例如在图数据库Neo4j中，每个实体是一个节点，而社区报告就是与实体节点直接或间接相连的节点的聚合信息。

那么，社区报告是如何得到的呢？

在 GraphRAG 中，当系统识别出问题中的实体后，它会利用知识图谱 (Knowledge Graph) 的结构，找出这些实体在图谱中的邻居节点。知识图谱是由节点和边组成的网络，节点代表实体，边代表实体之间的关系。

具体而言，GraphRAG 会进行以下步骤：

1. 识别实体: 首先，从用户查询中提取出关键实体。
2. 图谱遍历: 然后，在知识图谱中，从这些实体节点出发，进行一定步数的遍历 (例如，广度优先搜索)，探索与它们相连的其他节点和关系。
3. 信息聚合: 最后，将遍历得到的节点和关系信息进行聚合和整理，形成社区报告。这一步通常会用到一些图算法，例如社区发现算法，来识别出紧密相关的节点群。

社区报告如何提升检索质量？

社区报告的引入，使得 GraphRAG 能够超越传统的基于文本匹配的检索方法，从而提升检索质量。主要体现在以下几个方面：

• 捕捉隐式关联: 知识图谱中的关系可以揭示实体之间潜在的、隐含的关联，而这些关联可能无法通过简单的文本匹配发现。社区报告将这些关联信息显式化，从而帮助系统找到更相关的答案。
• 提供上下文信息: 社区报告提供了实体周围的上下文信息，有助于系统更好地理解查询的意图和背景。例如，如果问题是关于某个人的，社区报告可能会包含这个人的职业、所属机构等信息，从而帮助系统缩小搜索范围。
• 增强结果多样性: 通过探索知识图谱中的不同路径，社区报告可以发现与查询相关的多个方面的信息，从而提供更全面、更多样化的检索结果。

总而言之，社区报告就像是一个 “知识雷达”，帮助 GraphRAG 在知识图谱中更精准地定位与查询相关的信息，从而提升检索质量和问答效果。

临门一脚

在对话中，这三个分块的内容（content）都会以纯文本的形式直接插入到聊天历史记录中。那么问题在于，如何引导大模型有效地使用这些数据？或者更进一步地说，在没有明确提示的情况下，大模型是如何利用这三个分块的数据，从而实现高质量回答的？

如果假设正确答案已经包含在 Original Content 中，那么将这三个分块全部复制进上下文，与仅复制 Original Content 进上下文相比，会带来什么样的差异？对回答质量是否会产生显著影响？

这个问题直击了 RAG 系统如何有效利用检索信息的关键。即使将 Entities、Original Content 和 Community Report 这三个分块的文本内容都放入对话历史 (chat history) 中，大模型 (LLM) 也不一定能完美地利用它们，甚至可能出现与仅使用 Original Content 类似或更差的效果。

让我们先来分析一下将三个分块都放入上下文和仅放入 Original Content 的区别，以及对回答质量的潜在影响：

1. 仅放入 Original Content：

• 优点：

  • 直接相关： Original Content 通常是与问题最直接相关的文本段落，如果答案就在其中，LLM 有可能直接从中提取。
  • 简洁： 上下文较短，减少了 LLM 处理的负担，也降低了产生无关信息的风险。

• 缺点：

  • 信息孤立： 缺乏上下文和关联信息，LLM 难以深入理解文本的含义和背景，尤其是在面对复杂问题时。
  • 依赖检索质量： 如果检索到的 Original Content 质量不高，例如与问题相关性弱或包含错误信息，则 LLM 的回答质量也会受到影响。

2. 放入三个分块 (Entities, Original Content, Community Report)：

• 潜在优点：
  • 信息丰富： 提供了更全面的信息，包括实体信息和知识图谱中的关联信息，理论上可以帮助 LLM 更好地理解问题和组织答案。
  • 支持推理： Community Report 可以提供额外的背景知识和关联信息，有助于 LLM 进行推理和推断，从而得到更准确的答案。
• 潜在缺点：
  • 噪音干扰： 如果 Entities 或 Community Report 的质量不高，或者与问题的相关性不强，它们可能会成为噪音，干扰 LLM 对 Original Content 的理解和利用。
  • 上下文过长： 过多的信息可能会超出 LLM 的上下文窗口限制，或者增加其处理负担，导致性能下降或产生幻觉(hallucination)。
  • 利用效率低： LLM 缺乏明确的指导，可能无法有效地利用 Entities 和 Community Report 中的信息，或者错误地将它们与 Original Content 混淆。
  • 信息冗余: Entities, Original Content, Community Report 三者之间可能存在信息重叠，导致重复的信息被多次输入到 LLM。

那么，如何提示大模型更有效地使用这三个分块的数据呢？

以下是一些常用的提示 (prompting) 策略：

• 明确指示： 在 prompt 中明确告诉 LLM 每个分块的含义和作用，并指导它如何利用这些信息来回答问题。例如：

  已复制!

  你将获得一些关于问题的背景信息，包括：
  1. Entities：从问题中提取的关键实体。
  2. Original Content：从知识库中检索到的相关文本片段。
  3. Community Report：与实体相关的知识图谱信息摘要。
  
  请仔细阅读这些信息，并结合 Original Content 中的内容来回答以下问题：[问题]

• 结构化 Prompt： 使用特定的格式来组织 prompt，例如使用 Markdown 的标题、列表等，将不同的分块清晰地分隔开，并添加必要的解释说明。

• 基于角色的 Prompt： 将 LLM 设定为某个角色，例如 “知识库管理员” 或 “问答专家”，并赋予它相应的职责，例如 “根据提供的背景信息回答用户的问题”。

• 思维链 (Chain-of-Thought) Prompting： 引导 LLM 逐步思考，例如先总结每个分块的主要内容，然后分析它们之间的关系，最后根据这些信息生成答案。例如：

  已复制!

  请分步思考：
  1. 列出 Original Content 中的关键信息。
  2. 总结 Community Report 中与问题相关的实体和关系。
  3. 结合 Original Content 和 Community Report 中的信息，思考问题的答案。
  4. 给出你的答案，并解释你的推理过程。
  
  [问题]

• 特定任务指令: 针对特定的任务设计 prompt, 例如针对实体链接任务，可以指示 LLM “请将 Original Content 中出现的实体链接到 Community Report 中提供的实体”。

• Zero-shot, Few-shot, or Chain-of-thought: 可以根据实际情况选择合适的 prompting 方式，例如：

  • Zero-shot: 不提供任何示例，直接指示 LLM 根据提供的分块信息回答问题。
  • Few-shot: 提供几个示例，展示如何利用分块信息回答问题。
  • Chain-of-thought: 引导 LLM 一步步思考，并解释推理过程。

大模型到底是如何利用这三个分块的数据的？

在不进行特殊提示的情况下，LLM 主要依赖于其预训练阶段学到的知识和模式来理解和利用这些分块数据。

• 注意力机制 (Attention Mechanism)： LLM 的核心机制之一是注意力机制，它可以帮助模型关注输入序列中最重要的部分。在处理三个分块时，注意力机制会根据它们与问题的相关性分配不同的权重。如果 Original Content 与问题最相关，LLM 可能会将更多的注意力放在它上面。
• 语义理解： LLM 经过大规模文本数据的训练，具备一定的语义理解能力。它可以理解文本的含义，并识别实体、关系等信息。这使得它能够在一定程度上理解 Entities、Original Content 和 Community Report 中的内容。
• 隐式推理： 虽然没有明确的指导，LLM 仍然可以进行一定程度的隐式推理。例如，它可以根据 Original Content 中的信息和 Community Report 中的关联信息推断出答案。

总结：

将三个分块都放入上下文，理论上可以提供更丰富的信息，有助于 LLM 更好地回答问题。但实际上，LLM 是否能够有效利用这些信息，以及是否比仅使用 Original Content 更好，取决于多种因素，包括：

• 检索质量： Entities、Original Content 和 Community Report 的质量和相关性。
• LLM 的能力： LLM 的上下文窗口大小、语义理解能力和推理能力。
• Prompt 的设计： 是否使用了有效的 prompt 策略来指导 LLM 利用这些信息。

因此，仅仅将三个分块放入上下文并不足以保证回答质量的提升，还需要精心设计 prompt，并根据实际情况进行调整和优化。 通过巧妙地引导和提示，才能真正发挥出 Knowledge Pipeline 和 GraphRAG 的优势，让 LLM 成为我们强大的知识助手。

GraphRAG 查询阶段

朴素 RAG 的局限性

在了解 Graph RAG 之前，我们先回顾一下朴素 RAG 的查询流程。它的核心思路非常直接：

1. Query Embedding： 将用户查询转换为向量表示。
2. 向量检索： 将查询向量与向量数据库中的文本块向量进行匹配，检索出最相关的文本块。
3. 重排序（可选）： 使用一个重排序器 (Reranker) 对检索出的文本块进行排序，提高相关性。
4. LLM 生成： 将检索到的文本块作为上下文提供给 LLM，生成最终答案。

这个过程的特点在于，文本块的召回过程几乎没有 LLM 的直接参与，主要依赖向量相似度匹配。这种方式在某些场景下是高效的，但当需要理解更复杂的上下文或进行推理时，就显得有些力不从心了。

LLM 的深度参与

在前文 原子细节 部分我们知道 GraphRAG 在查询阶段的核心流程如下：

流程拆解:

1. 准备社区摘要 (Prepare Community Summaries):
   • 分块 (Chunking): 将预先生成的社区摘要随机打乱并按指定 token 长度进行分块。
   • 目的： 确保相关信息均匀分布在不同文本块中，防止信息丢失。
2. LLM 生成中间答案 & 评分 (Map Community Answers):
   • 中间答案生成: LLM 并行处理每个文本块，基于社区摘要生成针对用户查询的中间答案。
   • 评分： LLM 为每个中间答案生成一个 0-100 的评分，表示该答案与查询的相关程度。
   • LLM 的角色: 在此步骤中，LLM 不仅仅是生成文本，更是进行理解和推理。
3. 过滤低分答案 (Filter Low Score Answers):
   • 将评分低于一定阈值（例如为0分）的中间答案过滤掉，只保留高质量的答案。
4. 中间答案排序 & 上下文构建 (Reduce to Global Answer):
   • 按照帮助程度评分，对中间答案进行降序排序。
   • 将排序后的中间答案迭代添加到新的上下文窗口中，直到达到 token 限制。
   • 目的： 确保最相关的中间答案优先进入上下文。
5. LLM 生成全局答案 (Generate Global Answer):
   • 利用构建好的上下文窗口，LLM 生成最终的全局答案，并返回给用户。

关键差异

• LLM 的召回参与: 这是 Graph RAG 最核心的创新。朴素 RAG 依赖向量检索，而 Graph RAG 则让 LLM 基于社区摘要进行推理和答案生成，从而实现召回。
• 分层摘要： Graph RAG 使用预生成的社区摘要，而非直接检索原始文本块。这种分层结构能更好地捕捉文档集合的全局信息。
• 多步骤处理： Graph RAG 的查询流程是多步骤的，每一个步骤都使用 LLM 进行语义理解和处理。而朴素 RAG 流程相对简单，通常只包含向量检索和最终生成。
• 更强的推理能力： Graph RAG 的查询流程使得 LLM 不仅是生成文本，而且是推理文本之间的关系，从而生成更相关、更全面的答案。

LLM 在 Graph RAG 中的角色

• 语义理解： 理解社区摘要的语义内容，并根据用户查询生成对应的中间答案。
• 相关性评估： 对生成的中间答案进行评分，筛选高质量答案。
• 答案整合： 将不同的中间答案整合，生成最终的全局答案。
• 信息推理： 基于结构化的社区摘要，进行推理，生成更准确和深入的答案。

KG Pipeline

# Best Practices 2024-12-31
语言模型: DeepSeek-V3
块token数: 1024
分段标识符: "\n!?;。；！？"
解析方法: "Knowledge Graph"
嵌入模型: "jina-embeddings-v3"
实体类型: ["法律法规文件", "法条条款", "监管主体", "被监管主体", "核心定语与术语", "义务与禁止行为", "法律责任与处罚", "外部引用与关联"]

• 为了避免模型在生成社区报告时过度发散，建议将每张图的实体类型数量限制在 6 到 8 个。
• 实体类型可以使用中文或英文，但出于规范性考虑，建议在同一张图中统一使用一种语言。

Conclusion

本文介绍了 RAG 流程，并指出传统分块方法在构建法律知识库时存在的局限性。随后，我们引入知识图谱的概念，阐述了如何通过 GraphRAG 将知识图谱与 RAG 流程结合，从而实现更高效、更准确的法律知识检索。未来，我们可以进一步探索知识图谱的推理能力，以及与其他技术的结合方式，以进一步提升法律知识库的性能与智能化水平。

References

• LazyGraphRAG: Setting a new standard for quality and cost
• Moving to GraphRAG 1.0 – Streamlining ergonomics for developers and users
• GraphRAG documentation
• GraphRAG Arxiv
• GraphRAG Research Blog Post