Dify、Qdrantの削除範囲を制限する修正を提案　共有添付ファイルIDによる他データセットへの影響を防止

Difyコミュニティは11月4日、Qdrantベクトルストレージインターフェースで発生するデータセット間の誤削除に対処するPR #45586を提出した。提出者の説明によると、2つのデータセットが同じcollectionを共有し、同一の添付ファイルIDを持つ場合、データセットAに対してdelete_by_idsを実行すると、データセットBのベクトルまで削除される可能性があった。修正では、削除条件を指定されたドキュメントIDとデータセットのgroup_idの両方に一致するよう絞り込んでいる。修正提案

技術的なポイントは、アプリケーション層の識別子がどの範囲で有効かという点だ。Qdrantのpointにはベクトルと任意のpayloadが含まれる。公式の削除APIはpoint IDを直接指定できるほか、payloadのフィルター条件でデータを選択できる。データセットがcollectionを共有する場合、アプリケーションは自身のデータ境界を条件に含めなければ、データベースはその範囲に沿って削除できない。Qdrant公式ドキュメント

提出者によると、テストでは公式SDKのローカルエンジンと、バージョンを固定したqdrant-client 1.9.0を使用した。添付ファイルを共有するケースでは、修正前は別のデータセットに属する2件のpointも削除されたが、修正後は他のデータセットのデータと無関係なデータが保持された。providerのテストモジュール全体では16件が成功した。これらは提出者が公開したテスト記録に基づく結果であり、クラウドバックエンドやデプロイ済みAPI全体での検証を示すものではない。また、ドキュメント削除時の添付ファイルのクリーンアップは別の作業だ。検証範囲

RAGチームにとって、上記の再現条件から推測すると、誤削除によって操作対象ではないナレッジベースから検索可能なコンテンツが失われ、回答の根拠が減るおそれがある。エンジニアはまずcollectionの共有方法を確認し、データセット間で添付ファイルが重複するケースを使った削除の回帰テストを作成して、対象データと対象外データがいずれも想定どおりに処理されるか確認するとよい。

確認時点では、Difyの11月5日のコミット一覧にこの修正が掲載されている一方、PRページは引き続きオープンと表示されており、両者の状態は一致していない。現時点で確認できるのは、問題の説明と修正案が公開されたことまでだ。特定の正式バージョンで解決済みとはまだ言えないため、マージ記録、リリースタグ、デプロイ環境でのテストを追跡する必要がある。メインブランチのコミット一覧