GitHub Repo
Difyコミュニティ、日付形式の不一致を報告 ナレッジベースの時間フィルターでクエリ全体が失敗する可能性
10月16日のDifyコミュニティの報告によると、組み込みメタデータの書き込み形式が統一されておらず、時間フィルターの失敗やソースフィルターによる文書の取りこぼしにつながる可能性がある。修正案は提出済みだが、まだマージされておらず、既存データの移行も含まれていない。

Difyコミュニティは10月16日、ナレッジベースの組み込みメタデータに形式の不一致があるとして、問題報告と修正案を提出した。フィールドを有効化した際に既存データへ書き込まれる日付は数値のタイムスタンプだが、その後に追加された文書には日付文字列が書き込まれるという。報告はセルフホスト版1.17.1を対象とし、当時のメインブランチにも同じコードパスが残っていたと指摘している。検証はPostgreSQL 15でのSQLテストに限られ、完全なデプロイ環境での再現ではない。問題報告
報告によると、組み込みフィールドの有効化と一括編集の処理では、upload_dateとlast_update_dateがepoch秒で書き込まれる。一方、通常の文書作成とナレッジパイプラインでは、年月日時分秒の文字列が使われる。時間条件ではフィールドをFLOATに変換するため、日付文字列が1件でも混在すると、検索クエリ全体の型変換に失敗する可能性がある。ソースフィールドにもfile_uploadとupload_fileの違いがあり、完全一致フィルターで文書が気づかれないまま漏れるおそれがある。技術的な詳細
この問題は、日付で対象データを絞るRAGアプリケーションに影響する。Difyの公式設計では、ナレッジ検索ノードで手動または自動のメタデータ条件を使い、時間フィールドで文書のバージョンを区別できる。技術的な観点からは、この層で形式の問題が発生している場合、埋め込みモデルやリランキングモデルを変更してもクエリの失敗は解消しない。まずデータ型とフィルター条件を確認する必要がある。公式機能説明
修正案では、3つの書き込み経路を共通関数に集約し、タイムスタンプとソースラベルを統一するほか、時間変換がプロセスのタイムゾーンに依存する問題にも対処する。作者によると、関連する単体テスト2,318件はすべて成功した。ただし、これは提出者が報告した結果だ。確認時点でPRは審査待ちで、既存レコードの移行も含まれていない。エンジニアは今後、マージとリリースのバージョン、ならびに既存データを正式に修復する方法を注視すべきだ。デプロイ時の検証では、新旧両方の文書、日付比較、ソースの完全一致フィルターを対象にする必要がある。修正案