Dify、ストリーミング出力の送信前審査案を提出　逐次コンテンツ審査の防護範囲を明らかに

Difyコミュニティは11月4日、ストリーミング出力の審査に関する草案を提出した。テキストが先にユーザーへ届き、後からバックグラウンド審査で置き換えられるまでの時間差を縮めることを目指す。確認時点でPR #45536はまだ草案であり、設定名や、デプロイ全体と個々のアプリのどちらの単位で適用すべきかは、メンテナーの判断に委ねられている。提案の説明

Difyの既存ツールボックスでは、入力、出力、またはその両方を審査でき、審査モデル、キーワード、カスタムエンドポイントに対応している。今回の提案が変更するのは、コンテンツを配信するタイミングだ。MODERATION_OUTPUT_MODE=blockingを設定すると、対象アプリはテキストをいったんバッファリングし、蓄積した回答を審査サービスに渡す。審査を通過した後に、その部分が送信される。デフォルトは引き続き非同期モードとなる。公式ツールボックスドキュメント、草案

この設計は、レイテンシとサービスコストに直接影響する。最初のテキストが届くまでには、バッファがしきい値に達するか回答が終わるのを待ち、さらに審査の呼び出しが1回必要になる。その後の各部分も、審査が終わるまで待たなければならない。送信のたびに蓄積した回答を審査に渡すため、回答が長いほど審査対象の入力も増える。提案では、後続の文章によって、それ以前に審査を通過したテキストが違反コンテンツとなる可能性も明記されている。そのため、送信済みのテキストが置き換えられる事態はなお起こり得る。最終的に問題ありと判定される回答が、まったくユーザーの目に触れないという保証はない。レイテンシと制限

防護範囲も限られている。この草案が遮断するのはmessageテキストイベントのみで、Agentアプリには従来の動作が適用される。音声、推論チャンク、ファイル、一部のワークフローイベントは対象外だ。また、応答ストリームを停止しても、サーバー上のモデル呼び出しやワークフローはキャンセルされない。そのため、アプリのインテグレーターは実際の出力経路を一つずつ確認する必要がある。草案の制限

外部審査サービスへの接続方法も検証が必要だ。Alibaba Cloudの既存のDify連携例では、長い出力の末尾2,000文字を切り出して審査に送る。この例からは、Difyが蓄積した回答を送信しても、エンドポイントが完全なコンテキストを審査するとは限らないと推測できる。エンジニアリングチームは今後、審査範囲、複数の出力部分にまたがる検出、サービス障害時の挙動に注目し、メンテナーによる設計とリリースバージョンの確定を待つ必要がある。Alibaba Cloudの連携ドキュメント