尧图网站建设 
GraphRAG Bring Your Own GraphBYOG实践指南把自有图谱接入社区总结与全局检索【免费下载链接】graphragA modular graph-based Retrieval-Augmented Generation (RAG) system项目地址: https://gitcode.com/GitHub_Trending/gr/graphrag本指南介绍 GraphRAG 的 Bring Your Own GraphBYOG自带图谱工作流在已有实体—关系图数据的前提下跳过文本分块、实体抽取与关系抽取等 LLM 重负载阶段直接基于你自备的entities.parquet、relationships.parquet可选text_units.parquet跑通社区发现、社区报告生成与 GraphRAG 查询。读完本文你将掌握 BYOG 所需的最小输入表结构、如何在settings.yaml中声明 workflow 子集、如何选择标准描述驱动与 FastGraphRAG文本驱动两种报告变体以及完整的上手步骤。对应官方说明见仓库内 docs/index/byog.md。适用场景与核心思想默认的 GraphRAG 索引管线是一条从原始文档到知识图谱 社区报告的全链路流水线涉及 TextUnit 分块、LLM 实体抽取、关系抽取、描述总结等大量且昂贵的模型调用。然而很多用户手里已经有了一张现成的知识图谱例如来自 Neo4j、自有 NER/NLP 流程或历史项目只希望借助 GraphRAG 的社区层级聚类与社区报告总结能力把这张图变成可支撑 Global Search 的记忆层。BYOG 的思路非常简单将已经抽取好的实体与关系表以及可选文本块表直接放进 GraphRAG 的output目录再通过配置只运行最小的 workflow 子集让管线跳过分块与图抽取阶段从社区发现开始工作。GraphRAG 官方将这种模式描述为运行一条自定义 workflow pipeline并假定文本分块、实体抽取与关系抽取均已完成。输入表与最小字段集要覆盖 GraphRAG 查询的基本场景你至少需要从自己的数据中整理出两张或三张表表角色必要性entities.parquet数据集中发现的实体列表即图的节点必须relationships.parquet实体间关系列表即图的边必须text_units.parquet抽取图谱所用的源文本块视查询方法而定见下文可选配置各表的完整官方 schema 见 docs/index/outputs.md 中entities、relationships、text_units三节。从源码视角看这三张表对应 packages/graphrag/graphrag/data_model/schemas.py 所定义知识模型该模型概览见 docs/index/default_dataflow.md。为便于理解下表整理了与图总结直接相关的字段entities只读需要id、title、description、text_unit_ids字段类型说明idstr全局唯一的 UUID由 GraphRAG 生成的短引用依赖它human_readable_idint每次运行递增的短 ID用于与生成摘要中的引用交叉对照titlestr实体名称图的节点标签typestr实体类型默认语境下通常是 organization / person / geo / eventdescriptionstr对实体的文本化描述跨多个 TextUnit 的 LLM 汇总text_unit_idsstr[]包含该实体的文本单元 ID 列表frequencyint实体出现的文本单元数量degreeint实体在图中连接的节点度relationships只读需要id、source、target、description、weight、text_unit_ids字段类型说明idstr关系行的 UUIDsourcestr源实体名targetstr目标实体名descriptionstr关系描述在 create_community_reports 中被送入 LLM 提示词weightfloat图中边的权重combined_degreeint源与目标节点度之和text_unit_idsstr[]关系出现的文本单元 ID 列表官方文档特别强调weight字段非常重要因为它被用于正确计算 Leiden 社区为什么weight如此关键从实现上看create_communities工作流直接读取关系表并把它交给底层聚类函数处理。看 packages/graphrag/graphrag/index/operations/cluster_graph.py 的_compute_leiden_communities关系表先按source/target归一化方向并去重无向图语义若use_lcc开启先裁剪到最大连通分量读取edge_df[weight]并转为float作为(source, target, weight)三元组边列表送入hierarchical_leiden(...)——该层级聚类调用实现在 packages/graphrag/graphrag/graphs/hierarchical_leiden.py。也就是说如果你的关系表缺少weight列聚类将退化为每条边权重等于1.0的等权图见 cluster_graph.py 的兜底逻辑社区划分质量会明显受影响。因此 BYOG 场景下务必保留真实的边权重通常用源文本中关系实例的强度/频率累加得到。text_units可选供 Local/DRIFT/Basic Search 使用字段类型说明textstr文本块原文n_tokensint块内 token 数一般应与配置的chunk_size一致末块通常更短document_idstr文本块来源文档的 IDentity_idsstr[]文本块中发现的实体 IDrelationship_idsstr[]文本块中发现的关系 IDTextUnit 本质上是按模型上下文窗口大小切好的文档块。部分查询方法如 Local Search依赖原始文本证据因此只有当你打算跑这些查询时才需要提供该表。最小 workflow 配置仅社区发现 报告总结GraphRAG 允许你在settings.yaml中只声明需要的 workflow 步骤。对于最基本的图总结 查询只需workflows: [create_communities, create_community_reports]这样管线只会执行支持 Global Search 所需的最小 workflow 集合。配置为何能只跑部分workflows 覆盖机制这一机制在源码中有明确支撑。GraphRagConfig中的workflows字段定义如下见 packages/graphrag/graphrag/config/models/graph_rag_config.pyList of workflows to run, in execution order. This always overrides any built-in workflow methods.按执行顺序列出要运行的工作流它总是覆盖内置的 workflow method。而在 pipeline 构建处packages/graphrag/graphrag/index/workflows/factory.pydef create_pipeline(cls, config, methodIndexingMethod.Standard): workflows config.workflows or cls.pipelines.get(method, []) return Pipeline([(name, cls.workflows[name]) for name in workflows])即一旦在配置中显式给出workflows列表它就会整体替换按--method standard/--method fast注册的内置管线内置清单也在同一文件的 factory.py 中standard 为load_input_documents → create_base_text_units → ... → create_communities → create_community_reports → generate_text_embeddingsfast 则用extract_graph_nlp、prune_graph与create_community_reports_text替换对应环节。值得注意内置管线会先执行load_input_documents把 input 目录中的原始文档读入并分块而 BYOG 场景的 workflow 列表并不包含该步骤——因为你要提供的entities.parquet/relationships.parquet已位于 output 目录中create_communities会通过DataReader直接从输出表读取它们见 create_communities.py。两个 workflow 各自做了什么create_communities读取entities与relationships表对关系边执行层级 Leiden 聚类输出communities表含community、parent、children、level、title、entity_ids、relationship_ids、text_unit_ids等列。其具体实现在 create_communities.py先cluster_graph(...)得到(level, community, parent, title)簇再把社区内的实体 ID、社区内完全包含的关系 ID、以及社区对应的 text_unit_ids 聚合并写表。create_community_reports读取entities、relationships、communities若开启 claim 抽取且存在covariates表还会并入 claims把社区内实体的title/description/degree与关系的description组织为上下文调用 LLM 生成每个社区的总结报告写出community_reports表。源码见 create_community_reports.py其中_prep_nodes/_prep_edges同文件 L143-L180明确依赖实体的DESCRIPTION、节点度以及关系的DESCRIPTION字段——这正解释了 BYOG 中为什么实体与关系表需要提供描述文本。只要把这两步跑完output 中就有了community_reports表足以驱动仅依赖社区报告的 Global Search。可选扩展配置如果你还需要 Local Search、DRIFT Search 或 Basic Search就必须提供text_units并生成一部分向量嵌入。需要文本单元Text UnitsLocal/DRIFT/Basic 等检索方法会按向量相似度召回原始文本块作为证据因此需要text_units.parquet。它应与你的实体/关系保持有效关联实体的text_unit_ids和关系的text_unit_ids必须能正确指向文本单元这也是后续 FastGraphRAG 文本变体的硬性前提。扩展配置加入嵌入 workflow为了让以上检索可用把嵌入 workflow 追加到列表即可workflows: [create_communities, create_community_reports, generate_text_embeddings]generate_text_embeddings会为需要向量检索的内容生成嵌入并写入配置的向量存储。默认配置下被嵌入的内容包括实体描述、文本单元文本与社区报告内容详见 docs/index/default_dataflow.md 的 Phase 6: Text Embedding。是否配置与 LLM 模型对应的 embedding 相关参数可参考 docs/config/models.md 与 docs/config/yaml.md。再次强调generate_text_embeddings只有在跑 Global Search之外的检索时才需要。FastGraphRAG 文本变体create_community_reports_textFastGraphRAG 索引方法见 docs/index/methods.md与标准方法的最大差异在于它用 NLP 名词短语抽取替代 LLM 实体/关系抽取因此实体与关系通常没有描述文本社区报告改由文本单元内容直接生成。如果你的图谱来源恰恰是没有描述的例如只含节点名与共现边的纯 NLP 图可以改用报告生成的文本变体 workflowworkflows: [create_communities, create_community_reports_text, generate_text_embeddings]对比两条实现路径即可看清差异标准版create_community_reports的本地上下文构建导入的是summarize_communities.graph_context.context_buildercreate_community_reports.py即图谱上下文——喂给 LLM 的是实体的描述与节点/边的细节文本版create_community_reports_text导入的是summarize_communities.text_unit_context.context_buildercreate_community_reports_text.py即文本单元上下文——喂给 LLM 的是包含各实体名词短语的原始文本块内容由工作流读取entities、communities、text_units三张表后直接构建create_community_reports_text.py。注意两个前提条件该文本变体要求你的entities与relationships表都持有指向 text_unit_ids 列表的有效链接否则无法取回对应的源文本generate_text_embeddings依然只在需要跑 Global Search 之外的检索时才加入。端到端 Setup把方案落地综合前面的全部要点完整的 BYOG 落地步骤为初始化项目若尚未初始化graphrag init --root your_project_root该命令会在项目根目录生成settings.yaml、.env与默认prompts/目录详见 docs/config/init.md。放置自备图谱表创建 output 目录把你的entities.parquet与relationships.parquet需要 Local/DRIFT/Basic 检索时再加上text_units.parquet放进其中。使用默认文件存储时output 目录的基名是output见 defaults.py因此这些 parquet 默认落在your_project_root/output/下。修改配置在项目根的settings.yaml中按需求声明 workflows 子集仅 Global Search最简workflows: [create_communities, create_community_reports]还需要 Local/DRIFT/Basic Searchworkflows: [create_communities, create_community_reports, generate_text_embeddings]图谱无实体/关系描述、改用 FastGraphRAG 文本变体workflows: [create_communities, create_community_reports_text, generate_text_embeddings]运行索引graphrag index --root your_project_root完成后output目录中会生成communities与community_reports视配置还包括text_units相关的嵌入数据这些产物即可交给 GraphRAG Query 使用仅跑前两个 workflow 时可直接进行 Global Search带上了text_units与嵌入后可进行 Local、DRIFT 与 Basic Search。小结与进一步阅读BYOG 是 GraphRAG 的插拔式接入方式它复用管线的社区发现与社区报告环节把昂贵的文本分块/图抽取步骤换成你自己的图谱数据从而把 GraphRAG 的索引成本大幅前置降为一次性的图总结开销。最简配置只需entitiesrelationships两张表与两个 workflow扩展检索能力则需要补text_units与嵌入 workflow没有描述的图则改用create_community_reports_text的 FastGraphRAG 文本变体。相关资源官方原文档docs/index/byog.md输出表完整 schemadocs/index/outputs.md索引数据流总览docs/index/default_dataflow.md标准方法与 FastGraphRAG 对比docs/index/methods.md查询能力总览docs/query/overview.md、Global Search、Local Search、DRIFT Search配置说明docs/config/init.md、docs/config/yaml.md【免费下载链接】graphragA modular graph-based Retrieval-Augmented Generation (RAG) system项目地址: https://gitcode.com/GitHub_Trending/gr/graphrag创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GraphRAG Bring Your Own Graph（BYOG）实践指南：把自有图谱接入社区总结与全局检索
GraphRAG Bring Your Own GraphBYOG实践指南把自有图谱接入社区总结与全局检索【免费下载链接】graphragA modular graph-based Retrieval-Augmented Generation (RAG) system项目地址: https://gitcode.com/GitHub_Trending/gr/graphrag本指南介绍 GraphRAG 的 Bring Your Own GraphBYOG自带图谱工作流在已有实体—关系图数据的前提下跳过文本分块、实体抽取与关系抽取等 LLM 重负载阶段直接基于你自备的entities.parquet、relationships.parquet可选text_units.parquet跑通社区发现、社区报告生成与 GraphRAG 查询。读完本文你将掌握 BYOG 所需的最小输入表结构、如何在settings.yaml中声明 workflow 子集、如何选择标准描述驱动与 FastGraphRAG文本驱动两种报告变体以及完整的上手步骤。对应官方说明见仓库内 docs/index/byog.md。适用场景与核心思想默认的 GraphRAG 索引管线是一条从原始文档到知识图谱 社区报告的全链路流水线涉及 TextUnit 分块、LLM 实体抽取、关系抽取、描述总结等大量且昂贵的模型调用。然而很多用户手里已经有了一张现成的知识图谱例如来自 Neo4j、自有 NER/NLP 流程或历史项目只希望借助 GraphRAG 的社区层级聚类与社区报告总结能力把这张图变成可支撑 Global Search 的记忆层。BYOG 的思路非常简单将已经抽取好的实体与关系表以及可选文本块表直接放进 GraphRAG 的output目录再通过配置只运行最小的 workflow 子集让管线跳过分块与图抽取阶段从社区发现开始工作。GraphRAG 官方将这种模式描述为运行一条自定义 workflow pipeline并假定文本分块、实体抽取与关系抽取均已完成。输入表与最小字段集要覆盖 GraphRAG 查询的基本场景你至少需要从自己的数据中整理出两张或三张表表角色必要性entities.parquet数据集中发现的实体列表即图的节点必须relationships.parquet实体间关系列表即图的边必须text_units.parquet抽取图谱所用的源文本块视查询方法而定见下文可选配置各表的完整官方 schema 见 docs/index/outputs.md 中entities、relationships、text_units三节。从源码视角看这三张表对应 packages/graphrag/graphrag/data_model/schemas.py 所定义知识模型该模型概览见 docs/index/default_dataflow.md。为便于理解下表整理了与图总结直接相关的字段entities只读需要id、title、description、text_unit_ids字段类型说明idstr全局唯一的 UUID由 GraphRAG 生成的短引用依赖它human_readable_idint每次运行递增的短 ID用于与生成摘要中的引用交叉对照titlestr实体名称图的节点标签typestr实体类型默认语境下通常是 organization / person / geo / eventdescriptionstr对实体的文本化描述跨多个 TextUnit 的 LLM 汇总text_unit_idsstr[]包含该实体的文本单元 ID 列表frequencyint实体出现的文本单元数量degreeint实体在图中连接的节点度relationships只读需要id、source、target、description、weight、text_unit_ids字段类型说明idstr关系行的 UUIDsourcestr源实体名targetstr目标实体名descriptionstr关系描述在 create_community_reports 中被送入 LLM 提示词weightfloat图中边的权重combined_degreeint源与目标节点度之和text_unit_idsstr[]关系出现的文本单元 ID 列表官方文档特别强调weight字段非常重要因为它被用于正确计算 Leiden 社区为什么weight如此关键从实现上看create_communities工作流直接读取关系表并把它交给底层聚类函数处理。看 packages/graphrag/graphrag/index/operations/cluster_graph.py 的_compute_leiden_communities关系表先按source/target归一化方向并去重无向图语义若use_lcc开启先裁剪到最大连通分量读取edge_df[weight]并转为float作为(source, target, weight)三元组边列表送入hierarchical_leiden(...)——该层级聚类调用实现在 packages/graphrag/graphrag/graphs/hierarchical_leiden.py。也就是说如果你的关系表缺少weight列聚类将退化为每条边权重等于1.0的等权图见 cluster_graph.py 的兜底逻辑社区划分质量会明显受影响。因此 BYOG 场景下务必保留真实的边权重通常用源文本中关系实例的强度/频率累加得到。text_units可选供 Local/DRIFT/Basic Search 使用字段类型说明textstr文本块原文n_tokensint块内 token 数一般应与配置的chunk_size一致末块通常更短document_idstr文本块来源文档的 IDentity_idsstr[]文本块中发现的实体 IDrelationship_idsstr[]文本块中发现的关系 IDTextUnit 本质上是按模型上下文窗口大小切好的文档块。部分查询方法如 Local Search依赖原始文本证据因此只有当你打算跑这些查询时才需要提供该表。最小 workflow 配置仅社区发现 报告总结GraphRAG 允许你在settings.yaml中只声明需要的 workflow 步骤。对于最基本的图总结 查询只需workflows: [create_communities, create_community_reports]这样管线只会执行支持 Global Search 所需的最小 workflow 集合。配置为何能只跑部分workflows 覆盖机制这一机制在源码中有明确支撑。GraphRagConfig中的workflows字段定义如下见 packages/graphrag/graphrag/config/models/graph_rag_config.pyList of workflows to run, in execution order. This always overrides any built-in workflow methods.按执行顺序列出要运行的工作流它总是覆盖内置的 workflow method。而在 pipeline 构建处packages/graphrag/graphrag/index/workflows/factory.pydef create_pipeline(cls, config, methodIndexingMethod.Standard): workflows config.workflows or cls.pipelines.get(method, []) return Pipeline([(name, cls.workflows[name]) for name in workflows])即一旦在配置中显式给出workflows列表它就会整体替换按--method standard/--method fast注册的内置管线内置清单也在同一文件的 factory.py 中standard 为load_input_documents → create_base_text_units → ... → create_communities → create_community_reports → generate_text_embeddingsfast 则用extract_graph_nlp、prune_graph与create_community_reports_text替换对应环节。值得注意内置管线会先执行load_input_documents把 input 目录中的原始文档读入并分块而 BYOG 场景的 workflow 列表并不包含该步骤——因为你要提供的entities.parquet/relationships.parquet已位于 output 目录中create_communities会通过DataReader直接从输出表读取它们见 create_communities.py。两个 workflow 各自做了什么create_communities读取entities与relationships表对关系边执行层级 Leiden 聚类输出communities表含community、parent、children、level、title、entity_ids、relationship_ids、text_unit_ids等列。其具体实现在 create_communities.py先cluster_graph(...)得到(level, community, parent, title)簇再把社区内的实体 ID、社区内完全包含的关系 ID、以及社区对应的 text_unit_ids 聚合并写表。create_community_reports读取entities、relationships、communities若开启 claim 抽取且存在covariates表还会并入 claims把社区内实体的title/description/degree与关系的description组织为上下文调用 LLM 生成每个社区的总结报告写出community_reports表。源码见 create_community_reports.py其中_prep_nodes/_prep_edges同文件 L143-L180明确依赖实体的DESCRIPTION、节点度以及关系的DESCRIPTION字段——这正解释了 BYOG 中为什么实体与关系表需要提供描述文本。只要把这两步跑完output 中就有了community_reports表足以驱动仅依赖社区报告的 Global Search。可选扩展配置如果你还需要 Local Search、DRIFT Search 或 Basic Search就必须提供text_units并生成一部分向量嵌入。需要文本单元Text UnitsLocal/DRIFT/Basic 等检索方法会按向量相似度召回原始文本块作为证据因此需要text_units.parquet。它应与你的实体/关系保持有效关联实体的text_unit_ids和关系的text_unit_ids必须能正确指向文本单元这也是后续 FastGraphRAG 文本变体的硬性前提。扩展配置加入嵌入 workflow为了让以上检索可用把嵌入 workflow 追加到列表即可workflows: [create_communities, create_community_reports, generate_text_embeddings]generate_text_embeddings会为需要向量检索的内容生成嵌入并写入配置的向量存储。默认配置下被嵌入的内容包括实体描述、文本单元文本与社区报告内容详见 docs/index/default_dataflow.md 的 Phase 6: Text Embedding。是否配置与 LLM 模型对应的 embedding 相关参数可参考 docs/config/models.md 与 docs/config/yaml.md。再次强调generate_text_embeddings只有在跑 Global Search之外的检索时才需要。FastGraphRAG 文本变体create_community_reports_textFastGraphRAG 索引方法见 docs/index/methods.md与标准方法的最大差异在于它用 NLP 名词短语抽取替代 LLM 实体/关系抽取因此实体与关系通常没有描述文本社区报告改由文本单元内容直接生成。如果你的图谱来源恰恰是没有描述的例如只含节点名与共现边的纯 NLP 图可以改用报告生成的文本变体 workflowworkflows: [create_communities, create_community_reports_text, generate_text_embeddings]对比两条实现路径即可看清差异标准版create_community_reports的本地上下文构建导入的是summarize_communities.graph_context.context_buildercreate_community_reports.py即图谱上下文——喂给 LLM 的是实体的描述与节点/边的细节文本版create_community_reports_text导入的是summarize_communities.text_unit_context.context_buildercreate_community_reports_text.py即文本单元上下文——喂给 LLM 的是包含各实体名词短语的原始文本块内容由工作流读取entities、communities、text_units三张表后直接构建create_community_reports_text.py。注意两个前提条件该文本变体要求你的entities与relationships表都持有指向 text_unit_ids 列表的有效链接否则无法取回对应的源文本generate_text_embeddings依然只在需要跑 Global Search 之外的检索时才加入。端到端 Setup把方案落地综合前面的全部要点完整的 BYOG 落地步骤为初始化项目若尚未初始化graphrag init --root your_project_root该命令会在项目根目录生成settings.yaml、.env与默认prompts/目录详见 docs/config/init.md。放置自备图谱表创建 output 目录把你的entities.parquet与relationships.parquet需要 Local/DRIFT/Basic 检索时再加上text_units.parquet放进其中。使用默认文件存储时output 目录的基名是output见 defaults.py因此这些 parquet 默认落在your_project_root/output/下。修改配置在项目根的settings.yaml中按需求声明 workflows 子集仅 Global Search最简workflows: [create_communities, create_community_reports]还需要 Local/DRIFT/Basic Searchworkflows: [create_communities, create_community_reports, generate_text_embeddings]图谱无实体/关系描述、改用 FastGraphRAG 文本变体workflows: [create_communities, create_community_reports_text, generate_text_embeddings]运行索引graphrag index --root your_project_root完成后output目录中会生成communities与community_reports视配置还包括text_units相关的嵌入数据这些产物即可交给 GraphRAG Query 使用仅跑前两个 workflow 时可直接进行 Global Search带上了text_units与嵌入后可进行 Local、DRIFT 与 Basic Search。小结与进一步阅读BYOG 是 GraphRAG 的插拔式接入方式它复用管线的社区发现与社区报告环节把昂贵的文本分块/图抽取步骤换成你自己的图谱数据从而把 GraphRAG 的索引成本大幅前置降为一次性的图总结开销。最简配置只需entitiesrelationships两张表与两个 workflow扩展检索能力则需要补text_units与嵌入 workflow没有描述的图则改用create_community_reports_text的 FastGraphRAG 文本变体。相关资源官方原文档docs/index/byog.md输出表完整 schemadocs/index/outputs.md索引数据流总览docs/index/default_dataflow.md标准方法与 FastGraphRAG 对比docs/index/methods.md查询能力总览docs/query/overview.md、Global Search、Local Search、DRIFT Search配置说明docs/config/init.md、docs/config/yaml.md【免费下载链接】graphragA modular graph-based Retrieval-Augmented Generation (RAG) system项目地址: https://gitcode.com/GitHub_Trending/gr/graphrag创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考