Difyコミュニティが構造化出力の修正を提案、推論ブロック内のJSONが正式な回答として誤選択される可能性

Difyの構造化出力処理で、ワークフロー開発者が注意すべき解析上の問題が明らかになった。10月13日、あるユーザーは、自身でホストするDify 1.11.2 EnterpriseからLiteLLM経由でvLLMを使って推論モデルを呼び出した際、正式な回答には要求されたtypeとcontentのフィールドが含まれていたにもかかわらず、ノードが推論テキスト内の{"think":"start"}をstructured_outputとして返したと報告した。報告には設定、ストリーミング時のフィールド、出力の比較が添えられており、推論タグの分離を有効にしても問題が確認された。元の報告

技術的な焦点は解析の順序にある。報告の分析によると、プロバイダープラグインが推論内容をまず<think>タグで囲み、その後に回答と結合する場合がある。構造化パーサーは結合されたテキスト全体を受け取り、直接の解析に失敗するとjson_repairに渡して修復する。結果に複数のオブジェクトが含まれる場合、既存の処理では最初の辞書が選ばれるため、推論中の一時オブジェクトを取得してしまう可能性がある。別の参加者は、当時のメインブランチにある関数を部分的にテストし、ブロッキング経路とストリーミング経路の両方で同じ結果を確認した。ただし、テストにはモデル入出力のモックが使われており、実環境での完全な検証ではない。技術的な議論

同日に提案された修正PR #44005は、特定の修復処理で先頭の推論ブロックをスキップし、その後の回答を解析する。提案では元のメッセージとストリーミングの断片を保持し、回答文字列内に正当に含まれる<think>テキストを書き換えないようにしている。作者は、断片をまたぐタグ、大文字・小文字の違い、純粋なJSONなどのテストも挙げている。一方、内容が途中で切れている場合や推論内容しかない場合には、従来の動作が維持される。また、完全なSchema検証も対象外であり、こうした境界条件は引き続きレビューが必要だ。修正案

公式ドキュメントでは、構造化出力はプログラムで利用するデータとして位置づけられ、推論の分離によって思考内容を独立した変数に移せると説明されている。この問題が実務上重要なのはそのためだ。上記の事例から推測すると、下流の処理が解析結果をそのまま採用した場合、分類、フィールド抽出、条件分岐などに誤ったオブジェクトが渡される可能性がある。エンジニアリングチームは「推論と回答にそれぞれ異なるJSONが含まれる」検証ケースを追加し、必須フィールドも確認するとよい。調査時点では提案はまだオープンであり、正式な修正とは見なせず、すべてのモデルやバージョンに影響すると推定することもできない。公式LLMノードドキュメント