Difyコミュニティがワークフローの修正を提案、SnippetノードIDによりドキュメント変数がそのままモデルに送られる可能性

Difyコミュニティは10月10日、ワークフロー変数の解析不具合を報告した。セルフホスト版Docker 1.17.0で、Snippetを使ってドキュメント検索ノードとLLMノードを挿入し、変数セレクターで検索結果をプロンプトに追加すると、モデルに元のプレースホルダーが渡され、内容を読み取れないと回答される可能性がある。報告には操作手順と、バックエンドの正規表現に関する最小再現ケースが添えられている。不具合報告

報告では、フロントエンドとバックエンドで形式が一致していないことが原因として挙げられている。Snippetの挿入処理は、元のノードID、タイムスタンプ、インデックスを組み合わせて新しいIDを生成し、その中間にハイフンを含める。一方、バックエンドのプロンプトパーサーがノードIDに許容する文字は、英字、数字、アンダースコアに限られる。そのため、画面上で選択したドキュメント変数が実行時に照合されず、プロンプトの文字列としてそのまま残ることがある。類似したフローでも、ノードの作成方法によって挙動が異なる理由もここにある。再現手順と解析の経路

Difyの公式ドキュメントによると、プロンプト内のワークフロー変数はモデルに送信する前に実際の値へ置換される。エンジニアリング上の推論として、この種の不具合はドキュメント検索の失敗やモデルの能力不足と誤認される可能性がある。ドキュメントQAフローを調査する際は、上流ノードの出力に加え、実際に送信されるプロンプトに変数マーカーが残っていないかも確認すべきだ。LLMノードのドキュメント

同日に提出されたPR #43838は、数字のタイムスタンプを使ってノードIDを生成し、IDが衝突した場合は値を増やす方式に変更する。また、グラフ参照の再マッピングも維持する。作者によると、追加された回帰テストは修正前には失敗し、修正後には関連する27件のテストがすべて通過した。テストには、同じタイムスタンプでの重複挿入、プロンプト参照、接続端点が含まれる。ただし、デプロイ環境でのエンドツーエンドテストや実際のモデルを使った検証は行われていない。修正提案

確認時点で、提案は未クローズで、レビュー待ちとなっている。対象範囲は、新たに挿入されるノードで互換性のないIDが生成されるのを防ぐことに限られ、保存済みの既存ワークフローが自動修復されることはない。エンジニアリングチームは、マージとリリースの状況に加え、旧ワークフローの移行が必要かどうかを追跡する必要がある。また、この事例をすべてのDifyデプロイ環境に影響する問題へ一般化することはできない。修正の範囲と状況