Geminiは巨大コンテキストを信じすぎたのかもしれない

最近のGeminiが全然だめな理由は、マルチモーダルに注力しすぎたから、という説がある。

マルチモーダルに注力したせいでテキスト系の性能が落ちた、みたいな。でもGoogleならばマンパワーも資金力もあるんだから、それ以外にも十分なリソースを当てることができるだろうし、それだけでここまでだめにならなくない？と思っていた。

ただ、マルチモーダルに注力、をもう少し別の言葉にすると、巨大コンテキストで解決する設計に寄せすぎた、と考えればまあまあ納得感がある。

マルチモーダルは映像や動画などの巨大なデータを取り扱う。となると、どうしても巨大なコンテキストに対応せざるを得ない。ならば巨大コンテキストに関連するテキスト系のデータも全部ぶっこめば、性能が上がるはずだ。会話履歴も、資料も、リポジトリも、全部持ったまま考えられるAIにしよう。そういう方向に寄せすぎたのではないか。

でも最近、他の高性能モデルの実用例を考えると、1Mコンテキストすら使い切ると性能が劣化するから、できるだけコンパクトなコンテキストに分割して、必要な情報だけを渡したほうが実用性能が高い、ということが体感できるようになってきている。

コーディングエージェントでも、リポジトリ全体と長い会話履歴と設計資料を全部抱えさせたまま一つの仕事をさせるより、作業を細かく割って、それぞれに必要なファイルだけ読ませたほうがまともに動く。作業をサブエージェントに分割すると、トークン消費量が削減できるだけでなく、結果まで賢くなっているように見える。

巨大コンテキストは、必要そうな情報を全部入れられるという能力であって、全部入れたほうが賢いという意味ではなかった。現時点では、テキストに関してはそのへんがだいぶ分かってきた気がする。

そしてGeminiは、今さら根本的な設計方針を変えることができていない。というか、マルチモーダルを続けるには巨大コンテキストを捨てることもできない。動画を読ませるために巨大コンテキストを作ったのに、テキストの実用作業ではそれが足を引っ張る。そういうことになっているのではないか。

さらに言うと、AIエージェントは一つの巨大なモデルへ全部をやらせるより、三層くらいに分けたほうがよさそうに見える。

最初にルーティング用のモデルが、これは動画を見る仕事、これはコードを直す仕事、これは資料を探す仕事、と仕事を振り分ける。その次にマルチモーダルモデルが動画や画像を読む。そしてテキスト推論モデルが、必要なファイルと前の作業結果だけを渡されて考える。

ルーターは最終回答まで賢く出す必要がない。中間結果を受けて、ここで回答を出すのか、追加で資料を探すのか、別の推論を回すのか決めればよい。単純な仕事は一人で済ませ、複雑な仕事だけを分ける。そういう係まで含めて分業したほうが、エージェント全体としては強くなりそうである。

Geminiの中身は知らないのでただの想像だが、「マルチモーダルに注力しすぎた」よりは「マルチモーダルを起点に巨大コンテキストを信じすぎた」という感じなのではないか。さらにいうと、全部できる万能のAIを作ろうとしすぎた。そう考えると、なんとなく納得感がある。

flowchart TD
  A[依頼 / タスク] --> R[ルーティングモデル]
  R --> Q{次に何をするか}
  Q -->|動画・画像を読む| M[マルチモーダルモデル]
  Q -->|テキスト・コードを考える| T[テキスト推論モデル]
  M --> T
  T --> R2[ルーティングモデル]
  R2 -->|ここで回答できる| E[回答 / 実行]
  R2 -->|追加で調べる・考える| Q