sharin

Appearance

Gemini(ネイティブマルチモーダル) ​

GPT や Claude がテキストで生まれ後から画像を足したのに対し、Gemini は最初から画像・音声・動画・テキストを同じトークン列として扱う設計で作られた。この設計が成り立つのは、どんな入力もトークン列にしてしまえば Transformer が種類を区別しないからだ。この章ではその「全部をトークンにして混ぜる」設計思想と、超長コンテキストという Gemini のもう 1 つの軸を追う。

この章で読むもの ​

GPT系譜 の GPT-4V も Claudeの系譜 の Claude 3 も画像を扱えるが、その多くはテキストで学習したモデルに画像入力を後付けした構成だ。Google の Gemini(2023〜)は出発点が違い、最初から複数のモダリティを一体で学習する native multimodal を掲げた。この違いが何を意味するのかを、Transformer全体像 の構造に立ち返って読むのがこの章だ。

後付け(bolt-on)                ネイティブ(Gemini)
テキストLLM ← [橋] ← 画像エンコーダ   画像 → パッチ → トークン ┐
   別々に学習し接続部だけ合わせる      音声 → 符号 → トークン ─┼→ 1つの系列
                                    テキスト → BPE → トークン ┘
                                       最初から混ぜて一体で学習
後付けマルチモーダルとネイティブの対比。前者は画像エンコーダの出力をテキストモデルに橋渡しする。後者は最初から全モダリティを共通のトークン列として一体で学習する

順に見ていく。

  1. 全部をトークンにする: 画像はパッチ、音声は符号、テキストは BPE。種類が違っても、トークン列にしてしまえば Transformer には同じ系列に見える
  2. ネイティブ vs 後付け: 最初から混ぜて学習すると、モダリティをまたぐ関係(図とキャプション、音と口の動き)を接続部の制約なしに学べる
  3. もう 1 つの軸は長さ: Gemini 1.5 の 100 万トークン超のコンテキストウィンドウは、動画 1 時間や巨大コードベースを丸ごと入力する用途を開いた

① なぜトークンにすれば混ざるのか ​

Transformer全体像 で見たとおり、Transformer が受け取るのはトークンの埋め込みベクトルの列でしかない。そのベクトルがどこから来たか(単語なのか画像の一部なのか)を、attention の計算は気にしない。ここにマルチモーダルの原理がある。どんな入力も「切ってベクトルにする」工程さえ用意すれば、あとは同じ 1 つの系列として流せる。

  • テキスト: BPE でサブワードに切る(既に見た)
  • 画像: 16×16 ピクセルのパッチに格子状に切り、各パッチを 1 トークンに(ViT の方式)。224×224 の画像なら 196 トークン。マルチモーダル入口で実装したのがこれ
  • 音声: 短い時間窓ごとに符号(離散トークン)へ量子化する
  • 動画: フレームを画像として切り、時間方向にも並べる

こうして混在した系列を流すと、attention は「キャプションの単語」と「その物体が写ったパッチ」の間に直接の注目を張れる。テキストと画像が別モデルに分かれていれば橋渡しの接続部を通すしかないが、同じ系列なら距離 1 で結べる。RoPE で見た位置エンコーディングも、2 次元の画像や時間軸を持つ動画に合わせて拡張される。

② ネイティブと後付けの違い ​

技術的には後付けでもマルチモーダルは成立する。画像エンコーダ(CLIP など)の出力を、小さな接続層でテキストモデルの埋め込み空間に写せばよい。多くの初期 VLM(視覚言語モデル)はこの構成で、学習も安く済む。

ネイティブが狙うのはその接続部が持つ制約の解消だ。後付けでは画像側とテキスト側が別々に事前学習され、接続層だけを後で合わせる。すると画像エンコーダが「テキストと結びつける前提で見ていなかった」情報は、接続部で落ちうる。最初から混ぜて学習すれば、モダリティをまたぐ対応(グラフの数値と本文の主張、話者の声色と発言内容)を、学習の最初から一体で獲得できる。

Gemini 1.0(2023)はこの native multimodal を掲げ、テキスト・画像・音声・動画を同じモデルで入力できることを示した。出力もテキストに限らず、後の世代では画像生成や音声出力へ広がっている。この設計は Google が持つ YouTube 規模の動画・音声データと噛み合っており、データ資産が設計思想を支える例にもなっている。

③ もう 1 つの軸: 超長コンテキスト ​

Gemini のもう 1 つの特徴はコンテキストウィンドウの長さだ。Gemini 1.5(2024)は 100 万トークン、実験的には 1000 万トークンの窓を示した。Claudeの系譜 の 100k や GPT系譜 の水準を 1 桁上回る。

この長さはマルチモーダルと相乗する。1 時間の動画はフレームを切ると数十万トークンになり、短い窓には収まらない。100 万トークンの窓は、動画 1 本・コードベース 1 つ・書籍数冊を丸ごと入力に置いたまま質問することを可能にする。推論高速化 で見たとおり長コンテキストは attention の n² コストと KV キャッシュのメモリを押し上げるが、attention変種の GQA や、MoE による計算削減(Gemini 1.5 は MoE と報告)がその代償を支えている。部品編で作った改良が、この長さを成立させる土台になっている。

長コンテキストは RAG(検索して必要な断片だけ渡す)と競合する。窓に全部入るなら検索は要らないという主張と、費用と精度では検索の方が有利という主張があり、用途で使い分ける段階にある。

動かす ​

下のデモは 2 つの見方を用意した。「トークン化」は 1 枚の画像・音声・テキストが、それぞれパッチ・符号・サブワードを経て 1 つの共通トークン列に合流する様子を追う。「コンテキストウィンドウの比較」は Gemini の窓が他モデルや、動画・コードベースといった入力サイズに対してどの桁にあるかを対数スケールで見る。

デモGemini(マルチモーダルと長コンテキスト)生の入力
トークン化コンテキストウィンドウの比較
画像224×224 の写真
音声3 秒の波形
テキスト「猫が鳴いた」

種類の違う 3 つの入力。このままでは Transformer に流せない。それぞれを「切ってトークンにする」工程に通す

1 / 3

どんな入力も「切ってトークンにする」工程さえ用意すれば、Transformer 本体は共通のまま 1 つの系列として処理できる。Gemini はこれを最初から一体で学習し(ネイティブ)、 さらに 100 万トークン級の窓で動画やコードベースを丸ごと入力に置く設計を取った。

設計の観点 ​

  • モダリティ非依存の設計: 「切ってトークンにする」工程さえモダリティごとに用意すれば、Transformer 本体は共通。新しいモダリティの追加が、本体の作り直しでなくトークナイザの追加で済む
  • ネイティブの代償: 一体学習は、全モダリティのデータを揃え、バランスを取る学習設計が要る。後付けより高価で、データ資産(YouTube 等)を持つ組織に有利という構造がある
  • トークン数の会計: 画像 1 枚が数百トークン、動画 1 分が数千トークンを消費する。マルチモーダルの費用は「何トークンになるか」で決まり、キャパシティ見積もり と同じ見積もりがそのまま効く
  • 長コンテキスト vs RAG: 窓に全部入れる方式は実装が単純だが、毎回全トークンを処理する費用がかかる。検索は安いが取りこぼしうる。どちらが得かは入力の再利用頻度と精度要求で決まる
  • 位置エンコーディングの拡張: 2 次元の画像、時間軸を持つ動画では RoPE の 1 次元前提を拡張する必要がある。部品編の技術がモダリティに合わせて変形される実例

対照と実例 ​

方式学習モダリティ間の結合実例
後付け(接続層)安い(別々 + 接続)接続部で制約初期の LLaVA、多くのオープン VLM
ネイティブ一体学習高い(データ・設計)学習初期から一体Gemini、GPT-4o(omni)
超長コンテキスト長い窓の学習と推論費全入力を 1 窓にGemini 1.5(100万〜)

裏どり:

簡略化したこと ​

  • 各モダリティのトークナイザ詳細は概略: 音声の量子化(残差ベクトル量子化など)や動画のフレーム間引きの具体は踏み込まない
  • 出力側マルチモーダルは軽く: 画像・音声の生成は入力側と対称だが、拡散モデル等の別技術が絡むため概説に留めた
  • 数値・ベンチマークは書かない: 世代交代で陳腐化するため、設計思想と桁の比較だけを扱う
  • Gemini 内部構成は公開範囲: 詳細な層数・パラメータは非公開で、報告された MoE 採用等に留めた

参考資料 ​