「右上のブロックを動かして」と頼んだ相手が、別のブロックを指したとします。「それではなく、その左のブロック」と返すとき、話し手は相手の選択を見て、最初の指示が伝わらなかった部分を訂正しています。

Third Position Repair（第三位置修復、TPR）は、最初の話し手が、相手の応答に現れた誤解を後続の発話で訂正する会話の構造です。BLOCKWORLD-REPAIRSを報告した論文は、仮想のブロック移動課題で、この訂正を盤面の画像やシステムの示した候補と結び付けて扱います。データ収集時のシステムは、実験の設定に従って応答するため、実際にAIが内部で「誤解した」事例とは区別が必要です。

論文と、修復が起こる四つの位置

正式な論文名はRepairs in a Block World: A New Benchmark for Handling User Corrections with Multi-Modal Language Models。著者はJavier Chiyah-Garcia、Alessandro Suglia、Arash Eshghiの3人で、2024年のEMNLPで発表されました。データセットは論文中でBLOCKWORLD-REPAIRS、略してBW-Rと表記されます。著者のGitHubではBlockWorld-Repairsという表記が使われています。

1. T1：人がブロックの移動を依頼する。
2. T2：応答者が移動するブロックや置く位置の候補を示す。その応答から解釈のずれが分かる。
3. T3：最初に依頼した人が、示された候補を受けて訂正する。ここが第三位置修復に当たる。
4. T4：訂正を受けた応答者が、新たに対象または位置を示す。

修復を含む予測課題では、T1・T2・T3を踏まえたT4の対象や位置を、モデルが画像上の範囲として答えます。したがって「三つの発話」はモデルへの入力となる修復系列の説明であり、四番目は予測する応答です。相手から聞き返されたことへの回答や、相手の応答を待たずに自分の発話を直す場合とは区別します。

仮想の盤面で、移動元と移動先を伝える

研究は既存のBlock Worldのブロック配置と、ブロックを拾って別の場所に置く課題を利用しました。盤面には候補となるブロックが10個あり、参加者は一つの指示でどのブロックを動かし、どこへ置くかを自然言語で伝えます。位置の違いだけで対象を言い分けなければならない盤面では、一つの指示だけでは参照先を確定しにくい場合があります。

対話は論文の第3.1節と付録B.1によれば、Amazon Mechanical Turk上の画面で集められました。左にチャットとテキスト入力欄、右に完成時の配置が示され、参加者は仮想のロボット役システムへ文章を入力します。システムはブロックや位置を指し示して自分の候補を確かめ、参加者はその応答が合っているかをYes／Noで選んだ上で、必要な場合は自由記述で訂正しました。これは物理ロボットとの実地会話ではありません。

システムの動きや指さしは収集用の仕組みで制御され、参加者ごとに提示される出来事の列が変わりました。論文が記す収集時の設定は、システムが70％の割合で正しい動作を行うというものです。移動元と移動先について別々の確率は提示されていません。修復の後は、訂正の内容の良し悪しにかかわらず、システムが正しいブロックまたは位置を選ぶ設定でした。一つの対話には、最初の指示に続き、移動元と移動先についてそれぞれ最大一回の修復が生じます。

付録B.1は、募集対象を米国に限定し、178人の作業者が2021年5～9月に参加したと報告しています。1件の作業には、練習用を含む4対話が設けられました。Yes／Noの回答が想定と何度も合わない作業者には警告を出し、以後の提出を制限する仕組みも記されています。収集側の制御と、参加者が書いた訂正発話は分けて捉える必要があります。

795対話から2,059事例を数える

品質上の問題がある対話を除いた後の収集結果は、本文第3.1節・付録表6で次のように報告されています。

795＋629＋635＝2,059です。一つの対話から、最初の指示に加えて移動元と移動先の修復を別の予測事例として取り出せるため、対話数と事例数は一致しません。付録表7では、この2,059事例を学習用1,210、開発用0、評価用849とし、既存のBlock Worldの事例と合わせた実験用の総数は5,632です。配置が学習用と評価用で重ならないよう分けています。

画像と応答をどう対応付け、何を評価したか

訂正が「その左」のような表現だけなら、直前にシステムが示した場所と盤面がなければ指示先を判断しにくくなります。論文の評価では、モデルに画像と対話を与え、移動元のブロック、または移動先の位置を表すバウンディングボックスの四つの座標を予測させました。移動元は出力範囲と正解ブロックの重なりから正答率を算出し、移動元・移動先それぞれは正解との距離でも評価します。物理的にブロックを再実行して成功した割合ではありません。

公開コードのデータ読み込み部分では、事例ID、発話列、画像の参照、ブロックの座標、正解の対象・位置、提示候補の情報を扱う構造が確認できます。一方、著者のREADMEがある公開リポジトリのメインブランチには、論文の集計に対応する対話JSONLや盤面画像の実ファイルは見当たりません。ここで挙げた項目は、配布データの列名を確認した結果ではなく、コードが読み込む情報です。

対面評価の68％と75％は何を比べた値か

著者らは、収集済みの対話の一部を使い、別に募った22人による対面実験を行いました。参加者は盤面画像とチャット欄の内容を見て、移動元のブロックと移動先を画面上で選びます。各事例を少なくとも2人が判定し、品質上の問題がある61件を除いた991件の行動注釈を分析しました。内訳は指示343件、移動元の修復327件、移動先の修復321件です。

論文第3.2節・表3・付録B.2によると、移動元ブロックの正答率は指示事例で68％、修復事例で75％でした。これは同じ事例を同じ人が修復前後に解いた前後比較ではなく、異なる種類の事例に対する成績です。移動先については位置のずれを距離で比べ、修復事例の平均は人が2.77、GPT-4oが2.58で、値が小さいほど正解に近い指標でした。

同じ人間評価付きの事例に対する移動元の修復後の正答率は、人が0.75、微調整したLLaVAが0.60、Idefics2が0.43、ゼロショットのGPT-4oが0.50です。モデルごとに学習条件が異なり、移動先ではGPT-4oが人の平均距離を上回る結果もあるため、「どのモデルも、すべての指標で人より低い」とはまとめられません。

修復対話を設計するときに読み取れること

この研究は、盤面とシステムの候補を制御し、参加者に指示の対象と位置を言葉で伝えてもらいました。そのため、訂正発話を単独で扱わず、最初の指示、相手が示した候補、訂正時の盤面をつないで評価できます。一方、収集は制御された課題上の入力であり、日常の自然会話で偶然起きた誤解をそのまま記録したものではありません。

日本語で同様の課題を設計するなら、修復を自己修正や聞き返しへの回答と区別し、指示・候補提示・訂正の順序を記録する方法が考えられます。「違う」だけの発話を一律に除くのではなく、直前に示された位置と結び付けて解釈できるかを、設問ごとに検討することになります。