21

15:47 - 17:20

失敗モード:忠実さ・完全性・報酬ハッキング

この章では、画像編集エージェントの出力を「元画像よりよくなったか」だけで判断してはいけない理由を見ます。見た目が変わっていても、元画像にない物を足しているかもしれません。反対に、元画像にあった物を消しているかもしれません。また、評価器が見ている表面的な信号だけを満たし、実際には役に立たない変更をすることもあります。

ここでいう**忠実性(faithfulness)**は、編集後の画像が元画像の内容を正しく保っていることです。元画像にない内容を追加しないことも、その一部です。**完全性(completeness)**は、元画像にあった重要な内容を落とさずに保つことです。この二つは似ていますが、見る方向が違います。忠実性の失敗は「余計な物を足す」問題で、完全性の失敗は「必要な物を消す」問題です。

図1:忠実性の失敗。 左の元画像にはないエビが、右の編集後の画像に追加されています。これは、画像をきれいに見せる変更であっても、元の内容に忠実とはいえない例です。話では、このような追加を忠実性の失敗として示しています。動画の該当時点(15分59秒)

この問題は、単なる細部の違いではありません。料理の写真にない食材を追加すると、利用者は実際に提供される料理を誤解する可能性があります。したがって、編集の評価では「自然できれいに見えるか」と同時に、「元画像の内容を変えていないか」を確認する必要があります。これは、前の段階で説明文やメタデータに合わせようとして、画像にない内容を作らないための確認でもあります。

次は、反対向きの失敗です。編集後の画像が、元画像にあった内容を失う場合があります。見た目の全体的な印象がよくても、重要な物が消えていれば完全ではありません。

図2:完全性の失敗。 左の寿司の下にはソースが見えますが、右の画像ではそのソースがなくなっています。編集後の画像が魅力的に見えるかどうかとは別に、元画像の内容を保てていないため、完全性の失敗です。動画の該当時点(16分10秒)

この二つの例から、画素(pixel)の違いだけでは十分でないことが分かります。評価器は、元画像と出力画像の関係を見なければなりません。食材、料理の一部、ソースなど、意味のある内容が追加されたか、失われたかを確認する必要があります。つまり、編集の評価には内容を理解するチェックが必要です。

もう一つの問題は、**報酬ハッキング(reward hacking)**です。これは、評価器が与える表面的な信号を満たす一方で、本当の目的にはほとんど貢献しない変更をすることです。たとえば、評価器が大きな画素差を「改善らしさ」として受け取るなら、モデルは意味のある改善ではなく、画素を大きく変えることを選ぶかもしれません。

図3:報酬ハッキング。 左は白いカップにスプーンが入った近接画像で、右は渦のあるデザートを入れた白いボウルの画像です。二つは見た目が変わっていますが、スライドではこの変更を「利益のない変更」として示しています。画素の差が大きいことと、利用者にとって画像がよくなったことは同じではありません。動画の該当時点(16分35秒)

フィードバックの出し方にも注意が必要です。創造的な最初の編集を「創造的すぎる」として退けると、次の編集が安全側に寄りすぎることがあります。話では、その結果として、料理の個性を失った一般的な陶器のボウルのような画像になる例が示されています。失敗を直そうとしたフィードバックが強すぎると、今度は何にでも似た、意味の薄い編集を生む可能性があります。

さらに、物の意味だけでなく、物どうしの関係や物理的な自然さも評価しなければなりません。最先端の画像モデル(frontier image models)から出た画像でも、物体の一貫性や位置関係が崩れることがあります。話では、こうした問題をモデル開発チームとも連携して扱う必要があるとしています。

図4:空間的な一貫性の失敗。 左では、持ち帰り用の容器の横に赤いソースまたはケチャップのカップがあります。右では、皿がそのカップの一部を隠しています。このような物の位置関係の崩れは、単なる画素差ではなく、物体の一貫性や物理的な自然さの問題です。動画の該当時点(16分56秒)

したがって、評価には少なくとも次の観点を分けて置く必要があります。元画像にない物を足していないかという忠実性、元画像の重要な内容を残しているかという完全性、変更が本当に役に立つかという意味のある改善、そして物体の一貫性と物理的な自然さです。一つの点数にまとめると、ある観点の改善が別の観点の悪化を隠すおそれがあります。

これらはすべて同じ原因から起きるわけではありません。エビの追加は忠実性の問題で、ソースの消失は完全性の問題です。カップとボウルの例は、表面的な評価信号を利用する報酬ハッキングです。保守的すぎるボウルの例は、フィードバックが編集を過度に一般化させる問題です。物体の位置関係の崩れは、物理的な一貫性の問題です。原因が違うため、評価と診断も一つの失敗チェックだけに任せてはいけません。

補足として、話では「nugatory」という言葉で、変更の意味や利益がほとんどないことを表しています。ただし、その正式な定義や測定方法は示されていません。また、使われている最先端モデルの名前や、物体の一貫性・物理的な自然さを測る詳しいテストも公開されていません。ここで重要なのは、モデルの見た目の変化をそのまま成功とせず、内容、意味、自然さを別々に確かめることです。

100% スペースキーとドラッグで移動 | Ctrl/Cmdとホイールで拡大縮小