Open WebUIコミュニティがQdrantの書き込み競合を報告、ナレッジベースで文書チャンクが欠落する可能性

Open WebUIの文書インポート処理で、RAGエンジニアが注意すべきデータ完全性に関する報告があった。10月6日に作成されたissueによると、Qdrantをバックエンドに使用した場合、文書がcompletedと表示され、APIも成功を返しているにもかかわらず、ナレッジベースには一部のチャンクしか登録されないことがある。報告者はv0.11.4で問題を実際に確認し、コードを読んで当時の開発ブランチにも同じ処理経路が残っていることを確認したが、開発版での再現は試していない。コミュニティの報告

問題は、2段階のデータ移送に関係している。システムはまずチャンクを文書コレクションに書き込み、その後読み戻してナレッジベースに格納する。報告者によると、upload_pointsの呼び出しで待機パラメーターが指定されておらず、1バッチあたり64ポイント、wait=Falseというデフォルト値が使われていた。そのため、すべてのバッチが適用される前に後続処理が読み取りを始める可能性がある。ログの例では、文書には86個のチャンクがあったが、読み戻せたのは64個だけだった。処理フローとログ

Qdrantの公式ドキュメントは、このAPIの動作を確認している。wait=falseでの応答はリクエストを受け付けたことを示すもので、データはバックグラウンドで処理中の可能性があり、直ちに読み取り可能であることを保証しない。操作の完了後に処理を続ける必要があるアプリケーションでは、wait=trueを使用できる。この仕様は報告で示された競合の仕組みを裏付けるが、Open WebUIの実際の不具合を独立に検証したものではない。Qdrantのドキュメント

RAGでは、この種の欠落により、検索段階で一部の証拠をそもそも取得できなくなる可能性がある。これはデータフローから導かれるリスクであり、現時点で回答品質の評価は行われていない。エンジニアは、文書の処理状態とナレッジベースの内容の完全性を分けて検証する必要がある。特に、文書更新後すぐに同期する場合や、バッチでインポートする場合に注意が必要だ。

報告者は書き込みの完了を待ち、元の文書とナレッジベース内のコピーのチャンク内容を照合するよう提案している。ただし、再分割によってチャンク数が変わることがあるため、件数の差だけで欠落を判断することはできない。確認時点でissueは未解決で、修正PRも記載されていなかった。今後は、修正が2種類のQdrantクライアントの両方を対象にしているか、また書き込み完了を待つことでインポートの遅延がどの程度増えるかを確認する必要がある。対応案と状況