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

Đang mở
  • Có gì không ổn?
#2,583 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

@nightcityblade đang làm issue này rồi.

Từ ngày 1/10/2026.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
73/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
pandas, python
Lĩnh vực
data

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
Python
Star
36.6k
Fork
3.9k
Merge trung bình
4 ngày 11 giờ
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/graphrag

Tất cả issue của microsoft/graphrag

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.