拓冰网站定制 
GraphRAG Global Search 如何启用动态社区选择以减少 LLM 调用【免费下载链接】graphragA modular graph-based Retrieval-Augmented Generation (RAG) system项目地址: https://gitcode.com/GitHub_Trending/gr/graphrag如果你用 GraphRAG 的 Global Search 回答需要跨整个数据集汇总的问题例如“数据中的前 5 大主题是什么”会发现每次查询都要对索引出的全部community report 做 map-reducereport 越多map 阶段的 LLM 调用和 token 消耗就越大。动态社区选择dynamic community selection就是官方给出的减省手段它利用索引产出的社区层级结构先让 LLM 对 level 0 的社区报告做相关性评分只有相关的社区才继续向下遍历子社区从而让 map-reduce 只处理被判定相关的报告子集。本文给出一条可以照着跑通的路径基于索引产物 parquet 表通过 Python API 启用动态社区选择执行一次 global search并按仓库示例的方式核对各阶段的 LLM 调用次数与 token 数。前提条件已经用 GraphRAG 索引流水线跑过一次索引输出目录中有三张表示例中位于./inputs/operation dulce/见 global_search_with_dynamic_community_selection.ipynbcommunities.parquet社区层级结构动态选择用它重建社区图community_reports.parquet各社区报告map-reduce 的上下文来源entities.parquet实体表用于计算社区权重做上下文排序可选见下文说明。环境变量GRAPHRAG_API_KEY已设置为可用的 LLM API key示例中通过 litellm 调用gpt-4.1。已安装仓库内的graphrag与graphrag-llm包README 说明了安装方式。动态社区选择的工作方式依据 docs/query/global_search.mdglobal search 用指定层级社区报告作为上下文按 map-reduce 方式生成回答map 阶段把报告切成文本块逐块生成带评分的中间响应reduce 阶段对筛选后的要点做聚合生成最终回答。文档同时指出层级越低的报告越详细、回答越充分但所需时间和 LLM 资源也越多——这正是动态选择要解决的成本问题。示例 notebook 对机制的描述是动态选择不固定某个 community level而是借助索引数据集的层级结构先让 LLM 给每个 level 0 社区与查询的相关性打分当前社区报告相关时才继续遍历其子节点目标是减少进入 map-reduce 的社区报告数量。注意文档给出的适用性说明示例数据集很小仅 2 个层级共 20 个社区动态社区选择在可过滤的内容量较大时才更有效。启用步骤Python API 路径1. 配置 LLM 与 tokenizerimport os from graphrag.tokenizer.get_tokenizer import get_tokenizer from graphrag_llm.completion import create_completion from graphrag_llm.config import ModelConfig api_key os.environ[GRAPHRAG_API_KEY] config ModelConfig( typelitellm, model_provideropenai, modelgpt-4.1, api_keyapi_key, ) model create_completion(config) tokenizer get_tokenizer(config)这里的model与tokenizer会同时用于查询生成和动态选择的相关性评分。2. 读取索引产物开启动态选择关键变化有两处COMMUNITY_LEVEL置为None不固定层级read_indexer_reports传入dynamic_community_selectionTrue。INPUT_DIR需要替换为你自己索引产物的输出目录import pandas as pd from graphrag.query.indexer_adapters import ( read_indexer_communities, read_indexer_entities, read_indexer_reports, ) # 替换为你的索引输出目录仓库示例中为 ./inputs/operation dulce INPUT_DIR ./inputs/operation dulce COMMUNITY_TABLE communities COMMUNITY_REPORT_TABLE community_reports ENTITY_TABLE entities # 不固定 community level而是让动态选择在所有报告上检索相关性 COMMUNITY_LEVEL None community_df pd.read_parquet(f{INPUT_DIR}/{COMMUNITY_TABLE}.parquet) entity_df pd.read_parquet(f{INPUT_DIR}/{ENTITY_TABLE}.parquet) report_df pd.read_parquet(f{INPUT_DIR}/{COMMUNITY_REPORT_TABLE}.parquet) communities read_indexer_communities(community_df, report_df) reports read_indexer_reports( report_df, community_df, community_levelCOMMUNITY_LEVEL, dynamic_community_selectionTrue, ) entities read_indexer_entities( entity_df, community_df, community_levelCOMMUNITY_LEVEL ) print(fTotal report count: {len(report_df)}) print( fReport count after filtering by community level {COMMUNITY_LEVEL}: {len(reports)} )entities是可选的如果不提供实体表就不计算社区权重只用community_reports表中的 rank 属性做上下文排序。你也可以保留一个COMMUNITY_LEVEL来先过滤掉低层级报告再对剩下的报告做动态选择。3. 构建带动态选择的上下文构造器from graphrag.query.structured_search.global_search.community_context import ( GlobalCommunityContext, ) context_builder GlobalCommunityContext( community_reportsreports, communitiescommunities, entitiesentities, # 不想用社区权重排序时可省略 tokenizertokenizer, dynamic_community_selectionTrue, dynamic_community_selection_kwargs{ model: model, tokenizer: tokenizer, }, )4. 组装 GlobalSearch 并执行查询from graphrag.query.structured_search.global_search.search import GlobalSearch context_builder_params { use_community_summary: False, # False 用完整报告True 用社区短摘要 shuffle_data: True, include_community_rank: True, min_community_rank: 0, community_rank_name: rank, include_community_weight: True, community_weight_name: occurrence weight, normalize_community_weight: True, max_tokens: 12_000, # 按你的模型上下文上限调整8k 模型可设 5000 context_name: Reports, } map_llm_params {max_tokens: 1000, temperature: 0.0} reduce_llm_params {max_tokens: 2000, temperature: 0.0} # 8k 模型可设 1000-1500 search_engine GlobalSearch( modelmodel, context_buildercontext_builder, tokenizertokenizer, max_data_tokens12_000, # 与 max_tokens 同理按模型上限调整 map_llm_paramsdict(map_llm_params), reduce_llm_paramsdict(reduce_llm_params), allow_general_knowledgeFalse, json_modeFalse, context_builder_paramscontext_builder_params, concurrent_coroutines32, response_typemultiple paragraphs, ) result await search_engine.search(What is operation dulce?) print(result.response)response_type是自由文本描述期望的回答类型与格式如prioritized list、single paragraph、multi-page report。验证核对 LLM 调用与 token 消耗示例 notebook 给出的核对方式是把消耗按类别拆开build_context是动态选择做相关性评分阶段的调用量mapreduce是主回答流程的调用量。# 动态社区选择build context阶段的调用与 token llm_calls result.llm_calls_categories[build_context] prompt_tokens result.prompt_tokens_categories[build_context] output_tokens result.output_tokens_categories[build_context] print( fBuild context LLM calls: {llm_calls}. Prompt tokens: {prompt_tokens}. Output tokens: {output_tokens}. ) # map-reduce 阶段的调用与 token llm_calls result.llm_calls_categories[map] result.llm_calls_categories[reduce] prompt_tokens ( result.prompt_tokens_categories[map] result.prompt_tokens_categories[reduce] ) output_tokens ( result.output_tokens_categories[map] result.output_tokens_categories[reduce] ) print( fMap-reduce LLM calls: {llm_calls}. Prompt tokens: {prompt_tokens}. Output tokens: {output_tokens}. )同时可以检查实际进入 LLM 上下文的报告result.context_data[reports]判断动态选择是否生效的方式就是对照这两类数据build_context阶段只评分了被访问的社区而map/reduce阶段处理的报告数量应少于全量报告数Total report count。示例 notebook 未给出固定输出数值具体调用量取决于数据集规模与查询相关性。配置文件中的相关参数如果走的是仓库默认的settings.yml配置模式见 docs/config/yaml.md 的global_search小节dynamic_search_*字段控制动态选择的行为默认值来自 defaults.pyglobal_search: dynamic_search_threshold: 1 # 相关度评分阈值达到才纳入社区报告 dynamic_search_keep_parent: false # 子社区相关时是否保留父社区 dynamic_search_num_repeats: 1 # 同一社区报告的重复评分次数 dynamic_search_use_summary: false # 评分时用社区摘要而非 full_context dynamic_search_max_level: 2 # 已处理社区均不相关时考虑的最大层级这些参数在查询引擎工厂中会传给动态选择上下文见 query/factory.py 中get_global_search_engine对dynamic_community_selection的处理并在dynamic_community_selectionTrue时随model、tokenizer一起注入。限制与适用边界数据集较小时收益有限示例文档明确说明其数据集仅 20 个社区、2 个层级动态选择更适合内容量大、需要过滤大量无关报告的场景。dynamic_search_max_level控制“已处理社区都不相关时向上考虑的最大层级”默认 2如果你的社区层级超过这个深度相关报告可能不会被纳入可按需调整。动态选择本身在build_context阶段也会产生 LLM 调用相关性评分它省的是 map-reduce 阶段的开销而非把总调用数降到零。进一步阅读普通固定层级的 global search 用法见 docs/examples_notebooks/global_search.ipynb全局搜索的方法与参数说明见 docs/query/global_search.md。【免费下载链接】graphragA modular graph-based Retrieval-Augmented Generation (RAG) system项目地址: https://gitcode.com/GitHub_Trending/gr/graphrag创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GraphRAG Global Search 如何启用动态社区选择以减少 LLM 调用？
GraphRAG Global Search 如何启用动态社区选择以减少 LLM 调用【免费下载链接】graphragA modular graph-based Retrieval-Augmented Generation (RAG) system项目地址: https://gitcode.com/GitHub_Trending/gr/graphrag如果你用 GraphRAG 的 Global Search 回答需要跨整个数据集汇总的问题例如“数据中的前 5 大主题是什么”会发现每次查询都要对索引出的全部community report 做 map-reducereport 越多map 阶段的 LLM 调用和 token 消耗就越大。动态社区选择dynamic community selection就是官方给出的减省手段它利用索引产出的社区层级结构先让 LLM 对 level 0 的社区报告做相关性评分只有相关的社区才继续向下遍历子社区从而让 map-reduce 只处理被判定相关的报告子集。本文给出一条可以照着跑通的路径基于索引产物 parquet 表通过 Python API 启用动态社区选择执行一次 global search并按仓库示例的方式核对各阶段的 LLM 调用次数与 token 数。前提条件已经用 GraphRAG 索引流水线跑过一次索引输出目录中有三张表示例中位于./inputs/operation dulce/见 global_search_with_dynamic_community_selection.ipynbcommunities.parquet社区层级结构动态选择用它重建社区图community_reports.parquet各社区报告map-reduce 的上下文来源entities.parquet实体表用于计算社区权重做上下文排序可选见下文说明。环境变量GRAPHRAG_API_KEY已设置为可用的 LLM API key示例中通过 litellm 调用gpt-4.1。已安装仓库内的graphrag与graphrag-llm包README 说明了安装方式。动态社区选择的工作方式依据 docs/query/global_search.mdglobal search 用指定层级社区报告作为上下文按 map-reduce 方式生成回答map 阶段把报告切成文本块逐块生成带评分的中间响应reduce 阶段对筛选后的要点做聚合生成最终回答。文档同时指出层级越低的报告越详细、回答越充分但所需时间和 LLM 资源也越多——这正是动态选择要解决的成本问题。示例 notebook 对机制的描述是动态选择不固定某个 community level而是借助索引数据集的层级结构先让 LLM 给每个 level 0 社区与查询的相关性打分当前社区报告相关时才继续遍历其子节点目标是减少进入 map-reduce 的社区报告数量。注意文档给出的适用性说明示例数据集很小仅 2 个层级共 20 个社区动态社区选择在可过滤的内容量较大时才更有效。启用步骤Python API 路径1. 配置 LLM 与 tokenizerimport os from graphrag.tokenizer.get_tokenizer import get_tokenizer from graphrag_llm.completion import create_completion from graphrag_llm.config import ModelConfig api_key os.environ[GRAPHRAG_API_KEY] config ModelConfig( typelitellm, model_provideropenai, modelgpt-4.1, api_keyapi_key, ) model create_completion(config) tokenizer get_tokenizer(config)这里的model与tokenizer会同时用于查询生成和动态选择的相关性评分。2. 读取索引产物开启动态选择关键变化有两处COMMUNITY_LEVEL置为None不固定层级read_indexer_reports传入dynamic_community_selectionTrue。INPUT_DIR需要替换为你自己索引产物的输出目录import pandas as pd from graphrag.query.indexer_adapters import ( read_indexer_communities, read_indexer_entities, read_indexer_reports, ) # 替换为你的索引输出目录仓库示例中为 ./inputs/operation dulce INPUT_DIR ./inputs/operation dulce COMMUNITY_TABLE communities COMMUNITY_REPORT_TABLE community_reports ENTITY_TABLE entities # 不固定 community level而是让动态选择在所有报告上检索相关性 COMMUNITY_LEVEL None community_df pd.read_parquet(f{INPUT_DIR}/{COMMUNITY_TABLE}.parquet) entity_df pd.read_parquet(f{INPUT_DIR}/{ENTITY_TABLE}.parquet) report_df pd.read_parquet(f{INPUT_DIR}/{COMMUNITY_REPORT_TABLE}.parquet) communities read_indexer_communities(community_df, report_df) reports read_indexer_reports( report_df, community_df, community_levelCOMMUNITY_LEVEL, dynamic_community_selectionTrue, ) entities read_indexer_entities( entity_df, community_df, community_levelCOMMUNITY_LEVEL ) print(fTotal report count: {len(report_df)}) print( fReport count after filtering by community level {COMMUNITY_LEVEL}: {len(reports)} )entities是可选的如果不提供实体表就不计算社区权重只用community_reports表中的 rank 属性做上下文排序。你也可以保留一个COMMUNITY_LEVEL来先过滤掉低层级报告再对剩下的报告做动态选择。3. 构建带动态选择的上下文构造器from graphrag.query.structured_search.global_search.community_context import ( GlobalCommunityContext, ) context_builder GlobalCommunityContext( community_reportsreports, communitiescommunities, entitiesentities, # 不想用社区权重排序时可省略 tokenizertokenizer, dynamic_community_selectionTrue, dynamic_community_selection_kwargs{ model: model, tokenizer: tokenizer, }, )4. 组装 GlobalSearch 并执行查询from graphrag.query.structured_search.global_search.search import GlobalSearch context_builder_params { use_community_summary: False, # False 用完整报告True 用社区短摘要 shuffle_data: True, include_community_rank: True, min_community_rank: 0, community_rank_name: rank, include_community_weight: True, community_weight_name: occurrence weight, normalize_community_weight: True, max_tokens: 12_000, # 按你的模型上下文上限调整8k 模型可设 5000 context_name: Reports, } map_llm_params {max_tokens: 1000, temperature: 0.0} reduce_llm_params {max_tokens: 2000, temperature: 0.0} # 8k 模型可设 1000-1500 search_engine GlobalSearch( modelmodel, context_buildercontext_builder, tokenizertokenizer, max_data_tokens12_000, # 与 max_tokens 同理按模型上限调整 map_llm_paramsdict(map_llm_params), reduce_llm_paramsdict(reduce_llm_params), allow_general_knowledgeFalse, json_modeFalse, context_builder_paramscontext_builder_params, concurrent_coroutines32, response_typemultiple paragraphs, ) result await search_engine.search(What is operation dulce?) print(result.response)response_type是自由文本描述期望的回答类型与格式如prioritized list、single paragraph、multi-page report。验证核对 LLM 调用与 token 消耗示例 notebook 给出的核对方式是把消耗按类别拆开build_context是动态选择做相关性评分阶段的调用量mapreduce是主回答流程的调用量。# 动态社区选择build context阶段的调用与 token llm_calls result.llm_calls_categories[build_context] prompt_tokens result.prompt_tokens_categories[build_context] output_tokens result.output_tokens_categories[build_context] print( fBuild context LLM calls: {llm_calls}. Prompt tokens: {prompt_tokens}. Output tokens: {output_tokens}. ) # map-reduce 阶段的调用与 token llm_calls result.llm_calls_categories[map] result.llm_calls_categories[reduce] prompt_tokens ( result.prompt_tokens_categories[map] result.prompt_tokens_categories[reduce] ) output_tokens ( result.output_tokens_categories[map] result.output_tokens_categories[reduce] ) print( fMap-reduce LLM calls: {llm_calls}. Prompt tokens: {prompt_tokens}. Output tokens: {output_tokens}. )同时可以检查实际进入 LLM 上下文的报告result.context_data[reports]判断动态选择是否生效的方式就是对照这两类数据build_context阶段只评分了被访问的社区而map/reduce阶段处理的报告数量应少于全量报告数Total report count。示例 notebook 未给出固定输出数值具体调用量取决于数据集规模与查询相关性。配置文件中的相关参数如果走的是仓库默认的settings.yml配置模式见 docs/config/yaml.md 的global_search小节dynamic_search_*字段控制动态选择的行为默认值来自 defaults.pyglobal_search: dynamic_search_threshold: 1 # 相关度评分阈值达到才纳入社区报告 dynamic_search_keep_parent: false # 子社区相关时是否保留父社区 dynamic_search_num_repeats: 1 # 同一社区报告的重复评分次数 dynamic_search_use_summary: false # 评分时用社区摘要而非 full_context dynamic_search_max_level: 2 # 已处理社区均不相关时考虑的最大层级这些参数在查询引擎工厂中会传给动态选择上下文见 query/factory.py 中get_global_search_engine对dynamic_community_selection的处理并在dynamic_community_selectionTrue时随model、tokenizer一起注入。限制与适用边界数据集较小时收益有限示例文档明确说明其数据集仅 20 个社区、2 个层级动态选择更适合内容量大、需要过滤大量无关报告的场景。dynamic_search_max_level控制“已处理社区都不相关时向上考虑的最大层级”默认 2如果你的社区层级超过这个深度相关报告可能不会被纳入可按需调整。动态选择本身在build_context阶段也会产生 LLM 调用相关性评分它省的是 map-reduce 阶段的开销而非把总调用数降到零。进一步阅读普通固定层级的 global search 用法见 docs/examples_notebooks/global_search.ipynb全局搜索的方法与参数说明见 docs/query/global_search.md。【免费下载链接】graphragA modular graph-based Retrieval-Augmented Generation (RAG) system项目地址: https://gitcode.com/GitHub_Trending/gr/graphrag创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考