あなたは、ミステリーを解決するための究極の「探偵ボット」を構築しようとしていると想像してください。このボットは、現場の写真と、事実（温度、時刻、名前など）が記載されたスプレッドシートという2種類のヒントを見る必要があります。このボットを賢くするために、それぞれのヒントの種類に合わせて、ボットが理解できる言語に変換する特別な「翻訳機」が必要です。

写真については、素晴らしい翻訳機（有名なViTモデルのようなもの）があります。しかし、スプレッドシートについてはどうでしょう？何年もの間、科学者たちはMLP（単純で浅いニューラルネットワーク）と呼ばれる、非常に単純で基本的な翻訳機を使用してきました。それは、まるでピザを届けるために、スポーツカーの艦隊が利用可能であるにもかかわらず、自転車を使っているようなものです。この論文は、配送ルートの問題ではなく、その自転車こそがピザを冷めた状態で届けている原因かもしれない、と主張しています。

大きな発見： 「翻訳機」はあなたが考えている以上に重要である

この研究の著者たちは、この理論を検証することにしました。彼らは、退屈な自転車（単純なMLP）を、スプレッドシート用に用意された最も先進的で最先端の「スポーツカー」に入れ替えました。これらの新しい翻訳機は、インコンテキスト学習型テーブル・ファウンデーション・モデル（長すぎるので、ICLスーパー翻訳機と呼びましょう）と呼ばれます。

ここで、彼らが見つけたひねりは、どの探偵ボットが「最高」であるかというランキングが、使用する翻訳機によって完全に変わってしまうということです。

もし、弱い翻訳機を使ってボットをテストすれば、非常に複雑で豪華な探偵の手法が天才のように見えるかもしれません。しかし、強力な翻訳機に切り替えると、その同じ豪華な手法が平凡に見え、逆にシンプルで退屈な手法が突然スーパーヒーローのように見えることがあります。この論文は、私たちは単に悪い翻訳機を使っていたために、長年、間違った手法を称賛してきた可能性があることを示唆しています。

「機械の中の幽霊」問題

これらの新しいICLスーパー翻訳機には、大きな障害がありました。これらのモデルは、「コンテキスト」（答えが付いている解決済み事例のリスト）を見て、「クエリ」（答えがない謎）の答えを推測することで機能します。

著者たちは、不気かなグリッチを発見しました。モデルは、ある情報が「コンテキスト」にあるのか、それとも「クエリ」にあるのかによって、その情報を全く異なるものとして捉えてしまうのです。

例えば、あなたのお気に入りの映画を友人に説明している場面を想像してください。

• コンテキスト・モード： あなたは結末を見た「後」に、その映画について説明しています。あなたはプロットのひねりを知っています。
• クエリ・モード： あなたは結末を見る「前」に、その映画について説明しています。あなたは次に何が起こるかを予想しています。

たとえ同じ映画であっても、あなたの知識の状態が異なるため、あなたの説明（埋め込み／エンベディング）は全く異なるものになります。論文では、モデルがトレーニングデータを「コンテキスト」の役割として使い、テストデータを「クエリ」の役割として使うとき、コンピュータのメモリ内で、これらは2つの異なる「近所（ネバーフッド）」に存在してしまうことが分かりました。それは、ニューヨークの地図とロンドンの地図を照らし合わせようとしているようなもので、モデルがどちらの街を見ているのか混乱してしまっている状態です。

論文が否定したもの：
著者たちは、この違いが単にデータが異なっていることによるものだという説を、明示的にテストし、否定しました。たとえ全く同じデータポイントが両方の役割で使用されたとしても、モデルはそれらを別々に扱ったことを彼らは示しました。これは、データの問題ではなく、これらのモデルの仕組みにおける構造的な欠陥なのです。

「バニラ」の罠

このグリッチがあるため、著者たちはデータをモデルに投入する方法として、以下の3つの方法をテストしました。

1. バニラ（「ナイーブ」な方法）： トレーニングデータをコンテキストとして、テストデータをクエリとしてそのまま投入する。
2. LOFO（Leave-One-Fold-Out）： すべてのデータがクエリとしての役割を経験できるように、データをシャッフルする複雑な方法。
3. NP（Non-Partitioned）： トレーニングデータを、コンテキストとクエリの両方の役割として同時にモデルに見せる巧妙なトリック。

結論： 「バニラ」な方法は悲惨です。論文は、ナイーブな方法を使用すると一貫してパフォーマンスが低下することを示しています。それは、まるでサイドブレーキを引いたままスポーツカーを運転しようとしているようなものです。著者たちは、この方法を完全に避けることを強く推奨しています。代わりに、**NP（非分割）**メソッドが、これらのモデルの全能力を解き放つための推奨される「鍵」です。

豪華な融合（フュージョン）は必要なのか？

長い間、研究者たちは、写真とスプレッドシートを組み合わせるために、非常に複雑で高価なシステムが必要だと考えてきました。これらのシステムは、数百万のパラメータを持ち、特別な事前学習を必要とします。

この論文は、驚くべき発見をしました。写真とスプレッドシートの両方が有用なデータセットにおいて、シンプルな「バイリニア融合（双線形融合）」（基本的な数学的トリック）を強力な翻訳機と組み合わせるだけで、超複雑なシステムと同等の性能を発揮するのです。

実際、使用されている豪華で複雑なシステムは、平均して、シンプルなベースラインよりも13.2倍も多くのパラメータを持っています。著者らは、もし十分に強力な翻訳機を使用するのであれば、高価でオーバーエンジニアリングされた融合手法は必要ないと考えています。シンプルなアプローチの方が同等に優れており、かつはるかに安上がりなのです。

「単一モダリティ」への警告

論文はまた、一方のヒントが役に立たないデータセットについても警告しています。

• スプレッドシートが単なるノイズであるデータセット（CCDデータセットなど）の場合、写真にスプレッドシートを加えると、実際にボットのパフォーマンスを低下させます。
• 写真が役に立たない場合（スプレッドシートが主役であるPetfinderなど）、写真を加えるとパフォーマンスが低下します。

著者らは、融合モジュールが役に立たないヒントを魔法のように「無視」することを学習するわけではないことを発見しました。むしろ、融合によって混乱が生じ、片方のヒントだけを使った場合よりも性能が悪化してしまいます。これは、単にデータを組み合わせればよいというわけではなく、時には正しいヒントを選ぶ必要があることを示唆しています。

私たちはどの程度確信しているのか？

著者たちは単に推測したのではなく、7つの異なる実世界のデータセット（皮膚の画像から美術品オークション、車のリスティングまで）にわたって広範な実験を行いました。

• 彼らは、精度を測定するためにF1スコア（標準的な精度指標）を使用しました。
• 彼らは、翻訳機が向上するにつれて、データの「リフト（向上分）」が減少することを証明するために、統計ツール（OLS回帰やスペアマン相関）を使用しました。
• 彼らは、**MMD（最大平均偏差）**を用いて、「コンテキストとクエリのシフト」を確認しました。これは、2つのグループがどれほど離れているかを測定する数学的な手法です。

論文は、翻訳機の選択は「決定的な交絡因子（クリティカル・コンファウンド）」であると結論付けています。これは、適切な翻訳機を選ばなければ、実験全体が誤解を招くものになる可能性があることを意味します。これらの知見は、シミュレーションではなく、測定されたデータに基づいています。そして、著者らは「バニラ」な抽出方法は避けるべきであり、「NP」メソッドこそがほとんどのケースにおいて進むべき道であると確信しています。

ですから、次にあなたが探偵ボットを作る時は、これを覚えておいてください。探偵だけに集中しないでください。その翻訳機が目隠しをしていないか確認してください。