GitHub Repo
Difyコミュニティがインデックス削除時の競合状態を報告、孤立項目がRAG検索枠を消費する可能性
10月19日のDifyコミュニティの報告によると、インデックス書き込み中にドキュメントを削除すると、孤立項目が残り、検索結果が設定件数を下回る可能性があります。修正案にはテストが追加されていますが、まだマージされておらず、既存の残留データも削除されません。

Difyコミュニティは10月19日、ナレッジベースのインデックス処理に関する競合状態を報告しました。ドキュメントのインデックス作成中にそのドキュメントが削除されると、バックグラウンドジョブが後から、対応するドキュメントを失ったインデックス項目を書き込む可能性があります。これらの項目はクエリにヒットしてtop_kの候補枠を消費する一方、ドキュメントのチャンクを読み込む際に破棄されるため、アプリケーションが取得する参照コンテンツが減少します。報告者は、自身で構築したDify 1.17.1のDocker環境でこの現象を再現しました。問題報告
報告の分析によると、クリーンアップ処理はまずドキュメントチャンクのインデックス識別子を取得して削除を実行します。しかし、その時点ではインデックスへの書き込みが完了しておらず、削除対象のデータがありませんでした。その後、バックグラウンド書き込みが完了し、インデックス処理がドキュメントの削除済みを検知します。従来の処理はメッセージを記録するだけで、直前に書き込まれた項目を取り消しませんでした。報告者はタイミングを制御するため、キーワードの書き込みを意図的に一時停止し、3件の孤立項目を確認しました。同じ内容を再アップロードした後、top_k=3のクエリで返されたチャンクは2件だけでした。ベクトル検索経路については、コードの確認と単体テストのみで検証されており、実際の埋め込みサービスを使った一連のテストはまだ行われていません。再現方法と制約
同日に提出された修正案では、インデックス処理が書き込みバックエンドに渡したチャンクを記憶します。書き込み後にドキュメントが削除済みであることを示す例外が発生した場合、新たに追加されたdiscardクリーンアップインターフェースを呼び出します。高品質インデックスでは識別子を使って本文または親子ドキュメントの子チャンクのベクトルを削除し、経済モードでは既存のロック機構のもとでキーワード項目を削除します。作者は、実際のインデックス処理とクリーンアップのタイミングを網羅する競合状態テストも追加しました。ただし、この提案はまだレビュー待ちであり、マルチモーダル添付ファイルのベクトルは対象外です。また、変更前に生成された孤立データも回収しません。修正案
RAGの運用において、検索されるチャンクの減少は、インデックスとドキュメントデータの整合性に関係している可能性があります。エンジニアリング上の推論として、削除後に同じドキュメントを再アップロードしたときに問題が集中するなら、インデックスでヒットした識別子と実際に読み込み可能なチャンクを比較するとよいでしょう。Difyの公式ドキュメントによると、検索テストと通常の検索では同じAPIエンドポイントが使われ、テストページでクエリを比較できます。ただし、変更した設定はそのテストに限って有効です。今後は修正のマージ状況、正式リリース、既存の孤立項目をクリーンアップする方法を追う必要があります。現時点では、すべてのベクトルバックエンドが影響を受けるとは断定できません。公式の検索テストドキュメント
出典
- Reduce avoidable overhead in knowledge retrieval scoring and citation assembly #43664
- Knowledge Retrieval
- Test Knowledge Retrieval
- Deleting a document while it is being indexed leaves orphaned index entries that shrink retrieval results below top_k
- fix(api): discard index entries of documents deleted during indexing