Incremental update (`graphrag update`) silently ignores removed documents; they stay indexed and retrievable

オープン
  • 何か問題がありますか？
#2,590 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
data

調査の方向性

Start with graphrag/index/update/incremental_index.py and graphrag/index/workflows/load_update_documents.py, then trace how deleted inputs are handled by the update pipeline. Check the update workflow tests for coverage of removal-only changes. Done means removed documents and their derived data are no longer retrievable, or the update clearly warns or fails if removals require a full re-index.

索引モデルが issue の本文から書いたものです。

説明

Describe the bug

In GraphRAG 3.2.0, the incremental update computes which documents were removed from
the input, but never uses that information. The update completes without error, and the
removed documents, together with their text units, entities, relationships and community
reports, stay in the index and remain retrievable by queries.

This was first reported to MSRC (VULN-235383), which confirmed the behavior and classified
it as a functional and data-lifecycle defect rather than a security vulnerability, and
suggested filing it here.

Root cause

  • graphrag/index/update/incremental_index.py: get_delta_docs() returns an InputDelta
    with both new_inputs and deleted_inputs.
  • graphrag/index/workflows/load_update_documents.py: load_update_documents() returns only
    delta_documents.new_inputs; deleted_inputs is not referenced anywhere else in the package.
  • When the only change is a removal, the workflow logs No new update documents found. and
    stops the pipeline normally, so every output table is left unchanged.

Two related effects:

  • Each update writes a copy of the previous index, including the removed documents, to
    update_output/<timestamp>/previous/. A later full re-index does not touch this directory.
  • The LLM cache keeps the responses derived from the removed documents, also after a full re-index.
Steps to reproduce
  1. pip install graphrag==3.2.0, then graphrag init --root ./proj and configure a model.
  2. Put a.txt and b.txt into ./proj/input, where b.txt contains a unique fact,
    e.g. Alice Costa's badge number is Q7F9K2P1XZ3A.
  3. graphrag index --root ./proj
  4. Delete ./proj/input/b.txt and run graphrag update --root ./proj.
    The run succeeds; the log shows No new update documents found.
  5. ./proj/output/documents.parquet still lists b.txt, text_units.parquet still contains
    the badge number, and
    graphrag query --root ./proj --method local --query "What is Alice Costa's badge number?"
    still returns it.
  6. ./proj/update_output/<timestamp>/previous/*.parquet and ./proj/cache/ also contain
    b.txt's content.

In a larger experiment (10 synthetic people, 20 background people, Qwen2.5-7B-Instruct via
vLLM, local search), all removed documents stayed indexed after the incremental update, and
local search recovered 77% of the removed people's unique facts, the same as before the
removal. After a full re-index, local search recovered none of them, but the LLM cache and
the update backups still contained them.

Expected Behavior

Either

  • the incremental update processes deleted_inputs: it removes those documents and their
    text units and recomputes the affected entities, relationships and communities; or
  • at minimum, it warns or fails when the input has lost documents, and the documentation
    states that removing documents requires a full re-index.

It would also help to prune, or document, the update backups and the cache entries that are
derived from removed documents. Operators commonly remove documents to honour data-erasure
requests or to take out incorrect or poisoned content, and a silent success makes them
believe the content is gone.

GraphRAG Config Used

Default settings.yaml from graphrag init, with the completion and embedding models
pointed at local OpenAI-compatible endpoints. The behavior is in the update workflow and
does not depend on the model.

Additional Information
主要言語
Python
スター
36.6k
フォーク
3.9k
平均マージ
4日 11時間
マージ済み PR（30日）
1

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/graphrag のほかの issue

microsoft/graphrag の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。