[Bug]: Community report context seems to keep only one edge per node

Aperta
  • Qualcosa non va?
#2,583 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 5 giorni

@nightcityblade ci sta già lavorando.

Dal 1/10/2026.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
73/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
pandas, python
Ambito
data

Direzione di ricerca

Start in summarize_communities/graph_context/context_builder.py, especially _prepare_reports_at_level and the source/target edge aggregation described in the issue. Run the provided triangle-graph reproduction and inspect the context string; done means all three edges are retained before the token budget is applied, with relevant tests passing.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug triage
Do you need to file an issue?
  • I have searched the existing issues and this bug is not already filed.
  • My model is hosted on OpenAI or Azure. If not, please look at the "model providers" issue and don't file a new one here.
  • I believe this is a legitimate bug, not just a question. If this is a question, please use the Discussions area.
Describe the bug

Hi! I may be missing something, but it looks like _prepare_reports_at_level keeps only one edge per node when it builds the report context...

In 3.2.0 (and on main), edges are grouped by source and by target keeping only the first one, and the two results are then merged with combine_first:

# 3.2.0, summarize_communities/graph_context/context_builder.py, on lines 101-125
source_edges = (
    level_edge_df
    .groupby(schemas.EDGE_SOURCE)
    .agg({schemas.EDGE_DETAILS: "first"})
    ...
)
target_edges = (
    level_edge_df
    .groupby(schemas.EDGE_TARGET)
    .agg({schemas.EDGE_DETAILS: "first"})
    ...
)
...
merged_node_df.loc[:, schemas.EDGE_DETAILS] = merged_node_df.loc[
    :, f"{schemas.EDGE_DETAILS}_x"
].combine_first(merged_node_df.loc[:, f"{schemas.EDGE_DETAILS}_y"])

So an edge that is not the first of any node gets dropped, whatever the token budget. Let's see a small exaple, a triangle graph like A->B, A->C and C->B:

import pandas as pd
import graphrag.data_model.schemas as s
from graphrag.index.operations.summarize_communities.graph_context.context_builder import _prepare_reports_at_level

class Tok:
    def encode(self, t): return t.split()
    def num_tokens(self, t): return len(t.split())

nodes = pd.DataFrame({s.TITLE: list("ABC"), s.SHORT_ID: [0, 1, 2], s.DESCRIPTION: ["x"] * 3,
                      s.NODE_DEGREE: [2] * 3, s.COMMUNITY_ID: [0] * 3, s.COMMUNITY_LEVEL: [0] * 3})
nodes[s.NODE_DETAILS] = nodes[[s.SHORT_ID, s.TITLE, s.DESCRIPTION, s.NODE_DEGREE]].to_dict(orient="records")
edges = pd.DataFrame({s.EDGE_SOURCE: list("AAC"), s.EDGE_TARGET: list("BCB"),
                      s.SHORT_ID: [0, 1, 2], s.DESCRIPTION: ["e"] * 3, s.EDGE_DEGREE: [4] * 3})
edges[s.EDGE_DETAILS] = edges[[s.SHORT_ID, s.EDGE_SOURCE, s.EDGE_TARGET, s.DESCRIPTION, s.EDGE_DEGREE]].to_dict(orient="records")

print(_prepare_reports_at_level(nodes, edges, None, Tok(), 0, 10**9).iloc[0][s.CONTEXT_STRING])

Only A->B and C->B are printed. A keeps A->B, C keeps C->B, and B (with no outgoing edges) keeps its first incoming one, A->B again... so A->C is lost.

It caught my attention that up to 0.5.0 this part was different. Every edge was attached to both of its nodes and aggregated into a list, so nothing was dropped before the budget was applied:

# 0.5.0, summarize_communities/prepare_community_reports.py, lines 92-107
# concat all edge details per node
merged_node_df = pd.concat(
    [
        get_edge_details(level_node_df, level_edge_df, edge_source_column),
        get_edge_details(level_node_df, level_edge_df, edge_target_column),
    ],
    axis=0,
)
merged_node_df = (
    merged_node_df.groupby([...])
    .agg({node_details_column: "first", edge_details_column: list})
    .reset_index()
)

The current version appears in 0.9.0 and hasn't changed since. The comment above it still says "aggregate into lists", and in issue 1850 a maintainer said that leaf-level reports include all intra-community edges, so I think the change was unintended. Something like this seems to bring back the 0.5.0 behavior, since the rest of the function already handles lists and sort_context removes duplicates and applies the budget:

source_edges = level_edge_df.loc[:, [schemas.EDGE_SOURCE, schemas.EDGE_DETAILS]].rename(
    columns={schemas.EDGE_SOURCE: schemas.TITLE}
)
target_edges = level_edge_df.loc[:, [schemas.EDGE_TARGET, schemas.EDGE_DETAILS]].rename(
    columns={schemas.EDGE_TARGET: schemas.TITLE}
)
merged_node_df = level_node_df.merge(
    pd.concat([source_edges, target_edges]), on=schemas.TITLE, how="left"
)

Tested with GraphRAG 3.2.0, Python 3.12 on Linux.

It's very possible I'm missing some logic behind this, so apologies if that's the case. Thanks a lot in advance!

Steps to reproduce

No response

Expected Behavior

No response

GraphRAG Config Used
# Paste your config here
Logs and screenshots

No response

Additional Information
  • GraphRAG Version: 3.2.0
  • Operating System: Ubuntu 20.04
  • Python Version: 3.12
  • Related Issues: #1850
Lingua principale
Python
Stelle
36.6k
Fork
3.9k
Merge medio
4g 11h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/graphrag

Tutte le issue di microsoft/graphrag

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.