经典 RAG 专注于找到正确的段落而 GraphRAG 帮助你看到段落、实体和主题在整个文档集合中是如何连接的。原始 GraphRAG 论文指出标准 RAG 常常在处理宽泛问题时遇到困难比如这个数据集中的主要主题是什么为了解决这个问题GraphRAG 从你的文档创建实体图并生成其中各组的摘要。这意味着你的语料库质量同时影响检索和图的结构。在处理分块器或嵌入模型之前先决定你的系统需要回答哪些类型的问题。Microsoft 的文档将 GraphRAG 分为 Local Search、Global Search、DRIFT Search 和 Basic Search。Local Search 同时使用图数据和原始文本块来回答关注特定实体的问题。Global Search 使用社区报告以 map-reduce 方法回答更宽泛的问题。DRIFT 在 local search 基础上增加社区上下文。Basic Search 类似标准的向量 RAG。因此你可能需要根据用户是对特定实体感兴趣、对跨文档模式感兴趣、还是对两者都感兴趣来不同地准备数据集。一个好的 GraphRAG 项目从语料库清单开始而不是仅仅上传文件。列出文档来源、所有者、语言、变更频率以及已有哪些可用的元数据。默认情况下GraphRAG 支持纯文本、CSV 和 JSON将它们加载到带有 id、text、title、creation_date 和可选元数据等字段的共享表中。如果你的数据在数据库或自定义平台中你可以使用 pandas DataFrame 或自定义输入读取器只要它匹配预期格式。这很重要因为大多数现实世界的数据集不只是干净的 .txt、.csv 或 .json 文件。PDF、幻灯片、Office 文档和 HTML 页面通常包含有用的结构如标题、章节分隔、说明文字和表格。Azure 关于结构感知分块的指导说明保留这种布局是有帮助的按标题、段落或有意义的章节分割通常比将所有内容展平为纯文本产生更好的块。在实践中最好在开始 GraphRAG 索引之前将富文件转换为带有元数据的规范化文本。清理数据是下一步的关键。Azure 的富集指导建议规范化文本以改善后续匹配。这包括在适当情况下使用小写、纠正拼写、清理 Unicode、展开缩写以及谨慎处理多语言内容。保留原始文本以防以后需要展示未修改版本也是好主意。一个重要的安全提示如果语言模型索引你的仓库永远不要将仓库文本视为指令因为有害或意外的 prompt 注入内容可能最终出现在你的数据中。去重同样重要但经常被忽视。GraphRAG 跟踪实体出现的频率并在匹配的连接上累加关系权重。这意味着重复或几乎相同的文件会使某些人、产品、问题或主题看起来比实际更重要。对于知识发现最好在索引之前删除重复的样板、重复的 PDF、镜像的 wiki 页面和模板密集的文档。元数据在 GraphRAG 中比在许多普通 RAG 管道中值得更多关注。GraphRAG 允许你在文档级元数据字段中保留选定的 CSV 或 JSON 列并且它可以在分块期间将选定的元数据值预置到每个块中。当文档前几行包含关键上下文如标题、作者、案件编号、司法管辖区、产品版本或事件日期时这是一个大问题。如果没有元数据预置该共享上下文可能只存在于第一个块中从后续块中消失即使这些后续块仍然被检索、总结和用于图提取。一个常见的错误是将分块仅仅视为嵌入问题。在 GraphRAG 中分块影响哪些实体一起出现、发现了哪些关系、形成了哪些社区以及 local search 可用的证据。Microsoft 的 GraphRAG 文档说默认块大小是 1200 token。更大的块处理更快但可能丢失细节。你可以按 token 或句子设置分块调整重叠并根据需要添加元数据。Azure 的通用 RAG 指导建议从 512-token 的块和约 25% 的重叠开始用于向量检索。它还指出按标题和段落分割可以使块更连贯。最近的研究表明语义分块并不总是值得额外成本最佳块大小取决于数据的结构和密度。主要收获在你自己的数据上测试不同的分块设置而不是依赖流行的默认值。实体质量是数据准备对图变得特别重要的地方。GraphRAG 从每个文本单元提取小子图然后如果标题和类型匹配则合并实体如果来源和目标匹配则合并关系。知识图研究表明这具有挑战性因为文档很少对概念使用相同的名称所以实体链接、共指消解和规范化是关键。简单来说你的准备过程应该决定如何处理别名和变体如IBM和International Business Machines、“NYC和New York City”、产品昵称、法律缩写以及包含大量代词的文本。这些提及越一致和标准化你的图就越不会碎片化。如果你已经有结构化数据有一个有用的中间选项。GraphRAG 可以在自带图模式下运行你提供实体、关系以及可选的文本单元GraphRAG 在此基础上构建社区、报告和嵌入。如果你的组织已经有整理好的本体、案件图、产品图或事件图而你不想用 LLM 提取从头重建它这是一个好选择。你的准备步骤应该适合你想支持的查询模式。Local Search 将图实体、关系、社区报告和相关文本块组合在一起。Global Search 在 map-reduce 过程中使用社区报告作为上下文。DRIFT 在 local search 中添加更广泛的社区上下文。索引后GraphRAG 为向量搜索创建嵌入默认包括文本单元、实体描述和社区报告文本。这意味着你的源语料库支持多种检索类型所以糟糕的准备会影响整个系统。最好单独规划声明提取而不是默认开启。GraphRAG 将声明定义为带有状态和时间限制的正面事实陈述将它们导出为协变量并默认关闭声明提取因为它通常需要 prompt 调优才能良好工作。文档还指出默认声明框架通常用于欺诈或恶意行为等领域所以许多通用知识数据集起初不会从中受益。如果你的数据涉及调查、合规、事件或风险声明提取可以有帮助。否则通常最好首先专注于使实体、关系和社区报告正确。Prompt 调优不仅仅是最后一步它是数据准备的一部分。Microsoft 的文档强烈建议为你的特定数据调优 prompt自动调优工作流被高度鼓励因为它在加载和分割输入后创建适合你领域的 prompt。这很重要因为 GraphRAG 的默认实体类型很广泛如组织、人、地理位置和事件除非你更改它们或使用自动调优。对于法律、生物医学、金融、工程、科学或企业数据集这些默认值通常过于通用。最好在运行完整索引过程之前决定哪些实体和关系对你重要。多语言和多模态数据集需要额外注意。Azure 建议在文档级本地化分别处理每种语言避免未验证的翻译并确保你的嵌入模型支持多种语言。FastGraphRAG 可以通过使用 NLP 而非 LLM 推理来降低成本但 Microsoft 说其默认的 NLTK-plus-regex 方法主要适用于英语也有基于 spaCy 的选项可用。对于 PDF、扫描件、演示文稿和混合格式在提取期间保留布局和章节结构否则你可能在 GraphRAG 甚至开始构建图之前就得到混乱的块。一个好的团队不会从完整索引开始。相反先构建质量检查。从样本开始并审查 GraphRAG 输出文档、文本单元、实体、关系、社区、社区报告和任何可选的协变量。检查重要元数据是否仍然存在、同一实体是否以不同名称出现、高度节点是否有意义而不仅仅是通用术语、以及社区报告对专家是否有意义。由于 GraphRAG 将文档链接到文本单元和图对象你可以在扩展之前使用这些表检查数据来源。一个实用的预索引工作流通常是这样的清点来源将它们转换为稳定的 schema清理和去重文本标准化元数据和别名在样本上基准测试两三种分块策略检查生成的图工件然后在扩展之前进行 prompt 调优和重新索引。这个序列不是从单一来源复制粘贴的规则它是当前 GraphRAG 文档、Azure 的 RAG 准备指导以及最近的分块和知识图文献的最可靠综合。常见问题GraphRAG 的最佳块大小是多少没有通用的最佳块大小。GraphRAG 的默认值是 1200 tokenAzure 建议 512 token 加约 25% 的重叠作为向量检索的合理起点最近的研究表明语义分块并不自动更好最佳粒度取决于语料库结构和信息密度。最安全的答案是在你的实际文档和问题集上测试几个设置。如果文本已经可搜索我真的需要元数据吗通常是的。GraphRAG 可以保留文档元数据并将选定的元数据预置到每个块这有助于后续块保留否则在分割后会丢失的上下文。标题、作者、日期、案件 ID、章节标题、司法管辖区、产品名称和文档版本在随块一起传输时都可以改善图提取和检索质量。我应该在索引前删除重复文档吗在大多数情况下是的。因为 GraphRAG 跟踪实体频率并在文本单元上累加关系权重重复或近似重复的文档可能夸大重复想法或实体的突出性。对于发现、分析和综合工作负载去重通常改善图的信噪比。GraphRAG 能处理 PDF 和 Office 文件吗不能直接开箱即用就像它支持纯文本、CSV 和 JSON 那样。通常的模式是将 PDF、幻灯片、HTML 和其他富文件预处理为规范化文本加元数据或将自定义 DataFrame 或输入读取器传递给 GraphRAG。当需要在分块之前保持标题、表格和章节边界完整时结构感知提取特别有帮助。结论为 GraphRAG 准备语料库不仅仅是一个设置任务。这是你决定图将捕获什么、社区将代表什么、搜索模式能找到什么以及你能多容易追溯答案到来源的时候。一个好的 GraphRAG 语料库是干净的、去重的、元数据丰富的、仔细分块的、支持实体规范化的并在完整索引前在小样本上测试过的。有了这个坚实的基础GraphRAG 管道的其余部分更有可能给你比基本片段检索更丰富和更可靠的答案。原文链接为 GraphRAG 准备语料库 - 汇智网