一、まずデータフロー全体を俯瞰する

視覚言語モデルに初めて触れた人は、これを「画像を読める対話モデル」だと想像しがちです。この第一印象は便利であると同時に、厄介でもあります。便利なのは、対外的なインターフェースが実際上同じだからです。厄介なのは、この印象がパイプライン全体でいちばん障害の起きやすい三つの地点を覆い隠してしまうからです。つまり、画像がどのように token になるのか、token が言語モデルにどう「単語」として読み込まれるのか、そして学習時に実際にどのパラメータが動くのか、という三つです。本稿ではこのパイプラインを順番に追い、各節で専門用語を並べるのではなく、明確なエンジニアリング上の判断を一つずつ示します。

1 回の完全な推論はおおよそ次のようにつながります。画像のピクセルがまず視覚エンコーダーを通り、ひとつのベクトルの集合になります。このベクトル群は射影層(projection layer)（projector、connector、resampler とも呼ばれます）を通って言語モデルの埋め込み空間へ写像されます。次にこれらのベクトルは視覚 token として扱われ、テキスト token と同一のシーケンスに連結されて自己回帰デコーダーへ渡されます。デコーダーは通常の単語と同じ扱いで token を 1 つずつ生成しながら回答を作ります。この一連の過程に、いわゆる「画像側の分岐」「言語側の分岐」のような切り替えは存在せず、あるのは視覚座標系から言語座標系への 1 回の運搬だけです。

このパイプラインで本当に設計判断を下す必要があるのは、三つのインターフェースです。第 1 は視覚エンコーダーがどんな形のベクトルを出力するか、すなわち解像度、patch サイズ、階層特徴を残すかどうか、そして視覚塔自体が画像テキストの対比学習による事前学習済みかどうかです。第 2 は射影層(projection layer)が何個の token を残すか、つまり情報ボトルネックをどれだけ広げるかです。第 3 は学習時に何が動くかであり、これはモデルが何を学べて、何を失うかを直接に決定します。

ただし、この三つはそれぞれ独立に調整できるものではありません。入力解像度を 224 から 672 へ引き上げた場合、token 数はほぼ 9 倍に増え、射影層の計算量と活性化値のメモリもそれに追随して増え、学習時の有効シーケンス長も伸びます。この段階では射影層の構造とデータ配比を同時に見直す必要があり、さもなければ「学習時の loss は完全に正常なのに、推論では 1 文が数千個の視覚 token を抱えて長すぎる、あるいはメモリが枯渇する」という落差ができあがります。

もう 1 つ、よくある誤解があります。視覚エンコーダーを純粋な特徴抽出器として扱い、ベクトルを吐き出すだけの役割だと考えることです。実際には、もし視覚塔自体が画像テキストのアライメント事前学習を経ていなければ、その出力空間は純視覚のものであり、意味軸と言語モデルの意味軸はほとんど無関係です。このとき射影層をどう大きくしても、できることは限定的な運搬であり翻訳ではありません。学習データに存在しない対応関係を凭空に作り出すことはできないのです。これは以降のすべての学習段階を理解するための前提です。

本稿では、判断の根拠をできるだけ明示することを意識し、用語の対照表を並べることはしません。具体的な論文番号、具体的なスコア、具体的な ablation の数値に触れる部分では、メカニズムそのものを説明します。これらの細部は実装ごとに差が大きく、あえて固定して書く方が読者を誤解させやすいからです。

二、視覚エンコーダーの選定:CNN と ViT は何で競っているのか

視覚エンコーダーの歴史は大規模言語モデルよりずっと長いものです。画像分類の時代、主流は CNN でした。初期のネットワークから残差系を経て、EfficientNet や ConvNeXt といった近代的な畳み込み設計へと進みました。ViT はその途中に割り込み、patch 分割と全体自己注意力によって畳み込みを置き換え、一時は畳み込みを飲み込むという理論的な見方も出ました。しかし視覚言語モデルというシーンでは、単純な勝敗ではなく、階層型とフラット型がそれぞれ生態系の一席を占めるとう結論になります。

2.1 畳み込みバックボーンの有効領域

畳み込みの強みは局所性と効率です。畳み込みカーネルはパラメータを共有するため高周波のディテールに非常に敏感で、小さな文字、細い線、テクスチャといった signal をしっかり拾い取れます。パラメータ数が少なく、メモリ使用量が小さく、推論も速い。エッジデバイスへのデプロイ、リアルタイムの映像ストリーミング、極低レイテンシを要するシーンでは、畳み込みバックボーンはいまでも最も費用対効果の良い選択です。これは純粋に経済学的判断であって、技術的に後退という話ではありません。

畳み込みの短所も明確です。受容野の拡大は層の積み重ねに依存し、深い意味特徴の抽出効率は自己注意力に劣ります。より重要なのは、畳み込みが本質的にマルチスケールの階層特徴を出力する一方、言語モデルの入力はフラットな token の列であるという点です。階層特徴を token シーケンスへ写像するのは自然ではなく、たいてい追加の融合モジュールが必要になります。

実際のプロジェクトで純粋な畳み込みだけで構成された視覚塔を見ることは少なく、もっと一般的なのはハイブリッド構成です。前段のディテール検出を畳み込みバックボーンが担当し、後段に 1 〜 2 層の自己注意力を置いて全体の融合を行います。この構成はドキュメント、表、UI スクリーンショットのような入力に特に多く採用されます。固定 patch 分割の自己注意力と比べて、畳み込みのほうが細粒度な文字の輪郭に対してより鋭く反応するためです。

2.2 自己注意系の 4 つの改造方向

1 番目の改造方向は、全体自己注意を窓 attention もしくは近似線形 attention に置き換えることで、計算量を 2 乗からほぼ線形まで下げ、大解像度をメモリ上でも実現可能にすることです。2 番目の方向は patch embedding の方式を変えることです。たとえば畳み込みで patch を切り出す、あるいはバックボーンに入る前に一度だけピクセルの並べ替え集約を行って、入力を「数は少ないがチャネルの厚い token」に変えるのです。3 番目の方向は位置エンコーディングの適応です。補間式の絶対位置エンコーディングは解像度が大きく変わるとき失効しやすく、通常は補間可能な相対位置バイアスや 2 次元回転エンコーディングで受け持ちます。4 番目の方向は学習解像度と利用解像度の分離、すなわち比較的低い解像度で主に事前学習を行い、目標の高解像度で継続学習を行うことです。

この 4 方向はエンジニアリング上はほぼ直交しており、実践では 2 つから 3 つを同時に導入することがよくあります。低解像度での事前学習とクロップ型のファインチューニングを組み合わせる方法は、現在、単一の視覚塔を多様な入力形態に対応させる最も手っ取り早い手段です。

視覚塔に階層特徴を残すかどうかについては、しばしば見落とされるものの、大きな影響を及ぼす論点があります。最後の層だけを取る場合、特徴の意味化度は高く、token も少なく、オーバーヘッドも小さい一方で、空間ディテールが大きく失われ、文字、座標、小さな物体がぐちゃぐちゃに潰れます。最後の層に加えて中間層を数層取る場合、ディテールは一部取り戻せますが、token 数が倍増し、しかも層ごとに特徴の意味粒度が揃っていないため、それぞれ射影してから連結するか重み付けで融合する必要があります。

2.3 階層特徴と単層特徴の分岐点

私の経験に基づく判断はこうです。入力が自然なシーン中心、つまり認識、記述、汎用 QA であれば、単層特徴に十分な解像度を組み合わせれば通常は足ります。階層特徴がもたらす利得は、token 倍増の代償に届かないからです。入力が文字密度の高い画像中心、つまり伝票、論文、スクリーンショット、表、UI なら、ほぼ確実に多層特徴の経路を辿る必要があります。最後の層の特徴では既に筆画情報が消えているため、射影層をどれだけ強化しても解像度を高くしても戻ってこないからです。多層特徴とは、後から二度と取得できない情報を残したまま保持する手段です。

視覚塔の形態利点代償より適した用途
畳み込みバックボーン＋後段の attentionディテールが鋭く、スループットが高く、メモリも節約できる全体のモデルングが弱く、追加の融合モジュールが要るエッジ、リアルタイム、ドキュメントの細部
純粋な自己 attention・単層特徴全体のモデルングが強く、token が少なく、拡張性が高いディテールは弱く、高解像度のコストが急騰する自然なシーン、汎用 QA
自己 attention・多層特徴の融合ディテールと意味の両方を両立できるtoken 数が倍増し、射影構造も複雑になるドキュメント、表、グラフ、位置特定
低解像度事前学習＋高解像度継続学習一組の重みで多様な入力に対応できる継続学習のデータと計算コストが発生する多形態入力に対応する汎用システム

2.4 選定の早見表

4 文にまとめるとこうなります。汎用の視覚 QA と安定したスループットが欲しいなら、成熟したオープンソースの画像テキスト・アライメント済み重みで視覚塔を初期化するのが最も気が楽で、構造的な誤りも起こりにくいです。ドキュメントや UI の理解が欲しいなら、OCR 教師データを強く重んじて継続学習済みの視覚塔を選び、必ず多層特徴を通してください。リアルタイムまたはエッジ向けなら畳み込み系へ戻り、token 数の増加を受け入れます。究極の精度が欲しく、かつ十分な計算資源があるなら、高解像度の自己 attention に多層特徴をそのまま載せ、より高価な serving 方式の準備もあわせて進めてください。

もう 1 点、触れておきたいことがあります。視覚塔の重みの出どころは、アーキテクチャの細部よりも最終的な効果への影響が大きくなります。同じ自己 attention のバックボーンでも、汎用の画像テキスト・アライメント重みで初期化する場合と、純粋な画像自己教師重みで初期化する場合とでは、最終的な収束速度とアライメントの難度がまったく異なります。計算資源が乏しいときは、より良い視覚塔の初期化重みに予算を使うほうが、言語モデルを大きくするより通常は得策です。

2.5 視覚塔の解像度適応

視覚塔が学習された際の入力サイズと、実際の利用時のサイズが異なることは、多形態入力システムでは必ず対処すべき問題です。最も一般的なのは、2 次元回転エンコーディングのように解像度に応じて補間できる方式を使い、固定グリッドの絶対位置エンコーディングを避けることです。前者は再学習なしで正方形以外の入力を受け付けられるのに対し、後者は解像度が変化すると位置エンコーディングがずれ、モデルは静かに「それ自体は正常に見えるが、位置がまったく違う」結果を吐きます。

見落とされがちなのが、受容野とサイズの結びつきです。自己 attention のバックボーンの有効受容野は入力が大きくなるにつれて相対的に縮小します。同じ窓 attention の設定でも、低解像度なら画像全体をカバーできるのに対し、高解像度では局所しか見えません。窓サイズや attention 層数をそれに合わせて調整しなければ、高解像度入力での全体の理解は明らかに退化します。そしてその退化の現れ方は、回答の範囲が狭くなったり領域横断的な推論をしなくなったりするため、データの問題やモデル能力の問題と誤診されやすいのです。

もう 1 つ、覚えておく価値のある妥協経路があります。視覚塔の内部では低解像度を保ち計算量を抑え、視覚塔の出力が終わった後、言語モデルに入る直前に一度だけ空間上のアップサンプリングを行う方法です。これは高解像度のコストを「言語モデルに入る前のごく短い経路」に限定するという意味で、計算資源が乏しい状況でも実用的な効果を得る現実的な手段です。ただし代償として戻ってくるディテールは非常に限定的で、文字密度の高い入力には効きにくく、自然なシーンにのみ適しています。

三、解像度、視覚 token 数と情報ボトルネック

解像度判断の本質は、よく見せることと計算資源が収まることのあいだでバランスを取ることです。視覚 token 数はおおむね、画像の縦横を patch の面積で割った値をさらに空間ダウンサンプリング倍率で割ったものになります。一方を 2 倍すれば token 数は 4 倍になり、自己回帰デコーダー内のシーケンス長も 4 倍になります。attention のコストと KV キャッシュのメモリ使用量も一段と重くなり、長文コンテキストのシーンでは、この代償はモデル自体の計算量を上回ることがよくあります。

より厄介なのは、文字密度の高いシーンでは解像度の必要度がきわめて大きく変わることです。風景写真は比較的低い解像度でも十分に記述できますが、密に詰められた見開き文書のスキャン画像は、同じ解像度ではぐちゃぐちゃです。固定解像度の方式は、両端で必ず無駄を生じます。一方の端では計算資源を無駄にし、もう一方の端ではそもそも見分けられません。

そのため、現在の主流の考え方は「解像度をいくらに設定するか」ではなく「この画像にいくらの token 予算を与えるか」になりました。以後、その予算をどう配分するかは、後段の戦略群が判断します。この変化は言葉上の書き換えにしか聞こえませんが、設計問題をアーキテクチャ層から戦略層へ動かしており、以後のあらゆる動的解像度の手法はこの枠組みの中で展開されています。

予算配分の代表的な戦略は 3 つあります。1 つめは「固定予算＋サムネイル」です。全体をダウンサンプリングして小さい画像 1 枚にし全体の意味と物体の配置を保ち、次に高解像度の部分画像 1 枚をつなぎ合わせてディテールを保ちます。この 2 枚は予算を共有します。2 つめは「動的タイル分割」です。まず軽量な内容判定を 1 度行い、有効領域に沿って画像を切り、空白や単色の領域には token を少なく、あるいは一切与えません。3 つめは「ネイティブ動的解像度」です。画像をアスペクト比のまま複数の帯に分割し、各帯の高さを一定、幅を変えられるようにします。すると各帯の token 数は高さだけで決まります。次に 2 次元位置エンコーディングで帯の位置を符号化し直し、この帯が元画像の中のどこに置かれているかをモデルに伝えます。

  • サムネイル＋部分画像：実装が最も簡単で、挙動を予測しやすく、デバッグにも親切で、まずシステムを通しで動かすのに適しています。
  • 動的タイル分割：token の節約率は最も高く、複雑なレイアウトの文書や UI に対して最も有効ですが、タイル分割戦略そのものが独立した品質ボトルネックになります。
  • ネイティブ動的解像度：表現力は最も強く、余分なサムネイルの無駄がありませんが、位置エンコーディングと学習データのカバレッジ的要求が高く、実装にも学習にもより慎重な対応が要ります。

解像度と文字認識について、必ず説明しておくべき判断があります。画像内の文字の高さが何ピクセルを切ったあたりから認識が不安定になるか。この経験的な閾値はモデルごとにばらつきますが、大枠の傾向は安定しています。8 ピクセル以下ではほぼ認識できず、12 から 16 ピクセルが実用上の下限です。この基準で振り返ると、A4 の見開き文書を丸ごと数百ピクセルの入力に押し込んだ場合、各文字が受け取るピクセル数は数ピクセルにしかなりません。この状態ではどんな構成でも取り戻せません。問題は構成にあるのではなく、あなたが十分なピクセルを与えていないことにあります。

対策は 2 つしかありません。1 つはタイル分割して読み、1 文字ずつを使用可能なピクセル範囲に収まるようにする方法です。もう 1 つは、いっそ先に OCR を 1 度通して、認識できたテキストを原画像と一緒にモデルへ送り、文字情報はテキスト経路を通すようにする方法です。ピクセルでこじ開けるのではなくテキスト経路に乗せるという後者は、実践では解像度を無限に積み上げるよりも划算で、しかも安定しています。

# 视觉 token 预算与实际字高估算（工程里上线前先算这个）
def estimate_tokens(h, w, patch=14, merge=2, extra_patches=0):
    gh, gw = h // patch, w // patch
    n = (gh * gw) // (merge * merge)
    return n + extra_patches          # extra_patches 用于缩略图等附加 token

def estimate_text_pixels(h, w, lines=45, chars_per_line=38):
    # 满页密排文档的粗略字高估算
    return h / lines

for res in (224, 336, 448, 672, 896):
    side = res * res
    n = estimate_tokens(res, res)
    px = estimate_text_pixels(res, res)
    print(f"res={res} tokens={n} text_h={px:.1f}px")

# 结论：整页密排文档想直接靠像素读，
# 输入边长至少要 1120 以上才勉强进可用区间，
# 这时 token 已经上万，必须切块。

さらに、しばしば見落とされている性能上の事実があります。視覚 token 数と学習スループットの関係は線形ではありません。言語モデル側のシーケンスが長くなると、学習時のメモリピークは急激に上昇する一方、視覚塔側の計算量の占比はむしろ下がっていきます。解像度を上げた結果として視覚塔がボトルネックでなくなった時点は、実際には純粋な言語モデルのメモリ問題に入ったということです。この時点での最適化方向は、シーケンス並列化、gradient checkpointing、KV キャッシュの量子化であり、視覚塔を作り変えることではありません。

四、射影層:視覚空間から言語空間へ

射影層(projection layer)が担うのは、座標系の変換です。視覚エンコーダーが出力するベクトルの次元は通常 1000 前後で、局所性が強く意味軸も視覚に寄っています。一方、言語モデルの隠れ次元は 2,000 から 3,000、あるいは 1 万に達することも多く、意味軸はまったく異なります。射影層の役割は、単純に次元を伸ばすことではなく、前者の空間の意味構造を後者の空間の意味構造へ組み替えることです。この 1 歩を失敗させたら、以降のモデルがどれだけ大きくても取り戻せません。

現在の主要な設計は 3 通りです。線形層とはそのものの行列演算で、パラメータ数が最も少なく、情報忠実度が最も高く、ほとんど過学習しませんが、表現力は制限されます。MLP は全結合 2 層に活性化を足したもので、もっとも一般的な折衷案です。query-based な設計は、学習可能な query の集合を交差 attention によって視覚特徴から一定個数のベクトルを抽出する方法で、出力 token 数と入力 token 数が切り離されます。構造としては resampler や Q-Former 系のものとも呼ばれます。

4.1 三つの構造のトレードオフ

線形層が適するのは、特定の場合です。視覚特徴そのものがすでに高度にアライメントしている場合です。たとえば視覚塔を大量の高品質な画像テキストデータでアライメント学習済みなら、射影層は 1 回の座標変換を行うだけで足ります。この場合に非線形層を足しても利得はなく、むしろ過学習のリスクが増えます。規模の大きくない実用システムの多くは 2 層の線形層で止まっていて、それで効果が悪いわけではありません。

MLP はほとんどの生産システムが選ぶ構成です。線形層よりも非線形変換が 1 回増えるだけで表現力が一段上がり、パラメータの増加量も完全に制御可能です。唯一注意すべきは中間層の幅を盲目的に広げないことです。活性化値のメモリは視覚 token 数に線形して増えるため、中間次元を 2 倍すればこの部分のメモリも 2 倍になります。

query-based の核心的な価値は、切り離しと圧縮です。入力が数千の視覚 token でも出力が固定の数百個になり、メモリと推論コストが大きく下がり、出力長が固定されることでシステム層のバッチ処理とキャッシュもやりやすくなります。代償は情報ボトルネックです。圧縮比が一定の閾値を超えると、精密なアライメントが必要なタスクではスコアが明らかに落ちます。計数、座標の位置特定、小さい文字の読み取りがその例です。もう 1 つの問題は、query ベクトルが学習中に退化して全体の意味だけを引き、局所的なディテールを無視することです。症状は、モデル全体の記述は滑らかである一方、特定の位置にある細かな点に触れると答えられなくなる、というものになります。

射影層の種類パラメータ量情報忠実度過学習リスク適用範囲
単層の線形極小最高最低視覚塔が既に強力にアライメント済み、小規模モデル
2 層 MLP中程度高中程度生産システムのデフォルト選択
多層 MLP比較的大きい高やや高い利得が急速に飽和するため、デフォルトでの有効化は推奨しない
query resampler中程度圧縮比によって制約される高高解像度、長コンテキスト、メモリに敏感な環境

4.2 パラメータ数の落とし穴

ここには踏みやすい落とし穴があります。射影層のパラメータ量は視覚特徴の次元に対してしか線形に増えないため、量は少なく見えるので過小評価されがちです。しかし計算量と活性化値のメモリは視覚 token 数とともに増えます。4,000 次元から 8,000 次元の行列自体はそれほど大きくなくても、4,000 個の視覚 token がこの行列を順に通った場合、活性化値のメモリが相当な量を占めてしまいます。したがって動的な高解像度システムでは、射影層の設計は token 予算と連動して考える必要があり、構造を決めてから解像度を重ねる、という順序にしてはいけません。

もう 1 つ、深度の問題を個別に述べる価値があります。初期の実践には深い射影層と浅い射影層の区別がありました。深い射影層は非線形変換を数層積み重ねたもの、浅い射影層は 1 層の線形です。再現性のある結論はかなり一致していて、2 から 3 層を超えると利得は急速に減衰する一方で、浅い射影層は学習初期の収束が速く、メモリも節約されます。そのため現在のより一般的なのは、1 から 2 層の浅いから中程度の深度を維持し、浮いた計算量を高解像度と多層特徴にすべて注ぎ込むことです。この帳尻合わせは、射影層を深めるよりもずっと有利です。

import torch
import torch.nn as nn

class VisionProjector(nn.Module):
    def __init__(self, vis_dim=1280, llm_dim=4096, n_layer=2):
        super().__init__()
        self.pre_norm = nn.LayerNorm(vis_dim)          # 抑制异常大维度
        layers, d = [], vis_dim
        for _ in range(n_layer):
            layers += [nn.Linear(d, llm_dim), nn.GELU()]
            d = llm_dim
        self.mlp = nn.Sequential(*layers)
        self.post_norm = nn.LayerNorm(llm_dim)

    def forward(self, feats):
        # feats: [B, T, vis_dim]，T 为视觉 token 数
        x = self.pre_norm(feats)
        x = self.mlp(x)
        return self.post_norm(x)                       # 输出维度对齐 LLM 词嵌入空间

# 高分辨率动态切块时的预算分配
def merge_budget(feature_list, budget=576):
    # 多层特征按层号加权拼接，超预算时从最深层开始降采样
    merged = torch.cat(feature_list, dim=-1)
    if merged.shape[1] <= budget:
        return merged
    keep = budget // len(feature_list)
    return torch.cat([f[:, :keep] for f in feature_list], dim=-1)

4.3 正規化という細部の話

視覚特徴を射影する前に正規化するか、射影した後にさらに 1 層の正規化を積むかは、学習の安定性を大きく左右します。とくに半精度学習ではその通りです。正規化していない視覚特徴には、しばしば 1 つや 2 つの次元が異常に大きな値を含んでいます。その次元は attention の内積をそのままオーバーフロー寸前まで拡大させます。現れ方は、学習の最初の数百ステップで loss が急に非数になることです。確実な方法は、射影の前に 1 層の正規化を、射影の後に 1 層の正規化を置くことです。どちらもコストは微量ですが、原因究明に費やされる時間は大幅に減らせます。

4.4 射影層のよく使われる構造バリエーション

実際の開発では、いくつかのバリエーションに遭遇します。もっともよく見られるのは、MLP の後ろに視覚 token の種別埋め込みと、時間または画像番号の埋め込みを付ける方法です。これは各 token がどの画像、どのフレームに属するかをモデルに伝えるためのものです。この工程は単一画像タスクなら完全に省略できますが、複数画像や動画タスクでは、モデルが画像間およびフレーム間の指示関係を正しく扱えるようにはなりません。

2 つめは MLP と query resampler を組み合わせる方式です。まず MLP で次元を言語空間へ写像し、続いて一組の query で交差 attention による抽出を一度行い、一定個数の token を出力します。この組み合わせの利点は、両端の問題を分離して解決できることです。欠点は経路が長くなることでデバッグが難しくなり、問題が起きたときに「次元の写像が間違っているのか、圧縮が間違っているのか」を判別しにくいことです。

3 つめは、位置ごとの写像をグループごとの写像へ変える方式です。空間領域ごとにブロックで分け、それぞれ別の小さな射影層で処理し、スケール違いで生じる特徴を扱います。この方法は多層特徴の融合時には比較的自然です。層ごとに特徴の統計分布はもともと異なるため、同一の射影パラメータで処理すると、学習初期に長い warm-up を要することがよくあるからです。

一般的な提案はこうです。射影層の構造はプロジェクトの初期に決めて固定し、後期になってからの構造変更で効果を救うことを期待しないでください。射影層の構造が変わると、視覚塔の事前学習済み重みも、デコーダーのファインチューニング状態も再適応が必要になります。そのコストは、最初から若干、目立つほどではないとしても妥当な構造を選んでおく場合とは比べものになりません。

五、3 段階の学習:各段階で実際に何を学んでいるのか

現在もっとも一般的なレシピは 3 段階構成です。視覚アライメント事前学習、指示文ファインチューニング、選好最適化。どの段階も目的、解凍範囲、データの種類に各自のこだわりがあり、これらをまとめてまとめて行うことが、性能損失のもっとも一般的な原因になります。

5.1 段階 1:視覚アライメント事前学習

この段階では射影層だけを学習し、視覚塔と言語モデルは凍結します。目的は非常に単一です。射影層に視覚空間を言語空間へ写像する方法を学ばせ、視覚 token が言語モデルの目では読み取れるようにすることです。データは通常、超大規模で粗いラベルの画像テキストペアです。

なぜ射影層だけを学習するのか。この時点の言語モデルは次の単語の予測能力がすでに完成しており、大規模な画像テキストペアのテキスト側の教師信号は弱くノイズも大きいためです。ここでモデル全体を解放すると、勾配の大部分はテキスト側から来ます。言語モデルはまず大量の粗いテキストに引っ張られてしまい、視覚側は何かを学び終える前に埋もれてしまいます。両端を凍結して中央の接合部だけを学ばせるのは、コストと安定性の両面で最良の折衷であり、このパイプライン全体で費用対効果が最も高い 1 歩でもあります。

ただし、純粋な凍結にも代償があります。視覚塔が汎用の対比学習重みなら、その特徴空間は文字密度の高い画像や細粒度な関係に敏感ではありません。射影層がそのような情報を凭空で作り出すはずもありません。そのため比較的成熟した方法は、この段階の後半で視覚塔の最後の数個の block を徐々に解凍し、はっきり小さい学習率で特徴の適応を行うことです。並行して、アライメント事前学習で使う画像テキストペアの中で、高解像度で文字を含む画像の割合を適切に引き上げます。判断基準は単純で、解凍した後に検証セットの文字関連タスクのスコアが上がらないどころか下がったなら、適応しすぎたということです。戻して projector だけ解凍し直します。

5.2 段階 2:指示文ファインチューニング

この段階では言語モデル（通常は全パラメータ）を解凍し、射影層は学習を継続し、視覚塔は凍結のまま、あるいはごく小さい学習率でファインチューニングします。データは粗いラベルの説明文から、構造化された指示文へと入れ替わります。多輪対話、視覚 QA、推論問題、文字認識、位置特定、拒答サンプルなどです。

この段階で最も問題を起こしやすいのは収束ではなく、データの書式が不統一であることです。同じデータセットの中でも、画像をユーザーターンに置いたサンプルも、システムプロンプトに置いたサンプルも、テキストの途中にプレースホルダを差し込んだサンプルもあります。複数画像サンプルにおける順序と区切り文字の規則もばらばらです。書式が統一されていなければ、モデルが学ぶのは画像を見る能力ではなく位置バイアスになります。その兆候は、質問の言い方を変えるだけでスコアが明らかに落ちることです。対策は、すべてのデータを 1 本の事前処理テンプレートに通し、画像はユーザーターンの冒頭に統一して入れるか、あるいはプレースホルダで統一して埋め込み、学習前にサンプリングして数百件を目視確認することです。

2 つめの問題はデータ配比です。指示文ファインチューニングでは視覚データと純テキストデータの比率が非常に敏感です。純テキストの比率が低すぎると言語能力が崩れ、モデルは意味の通らない文を出し始めます。高すぎると、モデルは「画像を見て短く答える」モードへ過学習し、複雑な推論や長い回答の力が落ちます。経験上は視覚関連サンプルの比率が数十パーセントのあたりが安定していますが、タスクごとに調整します。垂直領域の QA をするなら比率を上げ、汎用アシスタントにするなら下げて、純テキストサンプルを多めに残して下限を保険がけしてください。

3 つめの問題は長シーケンスとパッキング学習です。複数サンプルを 1 本の長シーケンスに連結して効率的に学習するのは標準的な手法ですが、視覚 token の比率が高いと問題が起きます。視覚 token の位置番号は連結のたびに必ず連続した番号へ振り直す必要があり、単一サンプル内部の番号をそのまま引き継いではいけません。また attention mask の実装がテキスト長だけで切り詰めると、視覚 token を遮蔽してしまったりパディング位置が漏れたりします。この 2 つの bug の症状はいずれも、学習時の loss は正常に見えるのに推論効果が妙に悪い、というものです。loss の曲線を見ていても発見が極めて困難です。

# 三阶段训练的解冻范围与数据来源（伪代码）
STAGES = [
    dict(name="align_pretrain",
         trainable=["projector"],              # 只训接头
         data="web_captions_pretrain",          # 大规模粗标注
         lr_proj=1e-4, lr_vision=0.0, lr_llm=0.0),
    dict(name="vision_adapt",
         trainable=["projector", "vision_top_blocks"],
         data="highres_text_captions",          # 提高含文字高分辨率样本比例
         lr_proj=1e-5, lr_vision=1e-6, lr_llm=0.0),
    dict(name="sft",
         trainable=["projector", "llm"],        # 全参解冻语言模型
         data="instruction_tuning_mix",         # 多轮/推理/OCR/定位/拒答
         lr_proj=1e-5, lr_vision=0.0,   lr_llm=2e-5),
    dict(name="preference",
         trainable=["llm"],
         data="vision_pref_pairs",              # 幻觉对比 + 拒答 + 不确定性
         lr_proj=0.0,   lr_vision=0.0,   lr_llm=2e-6),   # 学习率压到 SFT 的十分之一
]

for st in STAGES:
    for name, p in zip(["proj", "vis", "llm"], ["projector", "vision", "llm"]):
        p.requires_grad_(name in st["trainable"])
        set_lr(opt, p, st[f"lr_{name}"])
    run(st["data"])
段階解凍範囲主なデータ本当に学んでいるもの
アライメント事前学習射影層のみ大量の粗いラベルの画像テキストペア視覚空間から言語空間への座標写像
視覚適応射影層＋視覚塔の最終段高解像度で文字を含む画像ディテール特徴の利用可能性の補完
指示文ファインチューニング言語モデルの全パラメータ構造化されたマルチモーダル指示文タスク形式、ターンの挙動、回答スタイルと境界
選好最適化言語モデル視覚選好ペア幻覚の抑制、拒答と不確実性表現の校正

5.3 段階 3:選好最適化

この段階では選好データを用いて DPO、あるいはその変種を行います。同じプロンプトに対して好的な回答と悪い回答を提示し、モデルに確率の質を好的な側へ移動させます。視覚選好データの構築はテキストより難しいです。視覚タスクではどちらの回答がより良いかについて意見が分かれやすく、自動構築の比率を高めすぎるとノイズラベルが生じます。

視覚選好データの中で最も価値が高いのは、幻覚コントラストです。視覚的に存在しない細部を作り出し、モデルに明確に拒絶させ、あるいは訂正させます。これが直接抑止するのは幻覚、すなわち画像側の証拠が不足しているのに言語の事前知識で補完し、見かけ上はもっともらしいながら事実としては存在しない説明を作り出す傾向です。この現象は視覚言語モデルのもっとも根強い欠陥のひとつであり、しかも短い回答形式ではとくに顕著に現れます。

もう 1 つの高利回りな方法は拒答と不確実性の学習です。画像がぼやけているとき、解像度が足りないとき、質問が画像の内容を超えているときに、モデルが「見えない」「画像にない」と言えるように学習させます。無理にでっち上げるのではなく、そのまま「見えない」と返すことです。この能力は第 3 節で議論した token 予算の設計と強く関係しています。予算が少ないなら、そもそも見えないのであり、見えないときに何を言えばよいかをモデルに教えていないと、モデルは自信満々に誤った細部を出力してしまいます。したがって予算が制約されたシステムでは、拒答学習は錦上花ではなく、必須の前提条件です。

注意しておきたいのは、選好最適化が視覚タスクで得られる利得は通常、テキストタスクほど大きくないことです。しかも過度な拒答が導入されやすく、モデルはあらゆることに対して「断定できません」と言い出すようになり、「何がありますか」と尋ねても石橋を叩き始めます。比較的安定した方法は、学習率を指示文ファインチューニングの 10 分の 1 から 5 分の 1 にまで圧縮し、証拠が十分で確定的な回答を求められるサンプルを意図的に一部残してバランスを取り、並行して検証セットで過度な拒答という指標の曲線だけを監視することです。

5.4 データ:上限を本当に決める半分

アーキテクチャは天井を決め、データは実際にどこまで到達できるを決めます。非常に直感に反する経験があります。アライメント事前学習段階のデータ量は巨大でもよく、品質は粗くて構いません。一方、指示文ファインチューニング段階のデータ量はたいてい 2 桁小さくなりますが、1 件ごとの書式の正しさがそのまま成否を決めます。同じ規模の計算予算のもとで、指示文ファインチューニングのデータを 10 万件から 30 万件の粗い生成データへ増やしたときの利得は、通常、10 万件のデータの書式を統一して人手で抜き取り検査する利得よりも遥かに小さいのです。

データの出所はおおよそ 3 つに分かれます。1 つめはウェブページや動画フレームから取得した弱いラベルのデータで、自動キャプションや既存の字幕から指示文を生成します。量は多くノイズも高く、主にアライメント事前学習を支えるために使います。2 つめは人手で構築した高品質な指示文で、多輪対話、推論、位置特定、拒答などのシーンをカバーします。量は少ないものの 1 件ごとに明確な行動目標があり、指示文ファインチューニング的主力になります。3 つめは合成データで、強力なモデルが質問、回答、選好ペアをまとめて生成します。前 2 つの間に位置します。

合成データは 2026 年でもっとも変化の大きい部分です。強力なモデルで 1 枚の画像に対して 10 個以上の異なる視点の質問を作り、別の強力なモデルに好的回答と悪い回答を生成させる。この構成で得た選好ペアは幻覚抑制に対して非常に強い効果を示します。悪い回答には、存在しない物体をあえて断定的に述べる、といった典型的な幻覚パターンを人手で注入できるからです。ただし合成データにはスタイルの同質化という致命的なリスクがあります。数万件をすべて同じモデルが生成すると、回答の文型、長さ、迷う程度が非常に似てしまい、モデルが学ぶのはその生成器のスタイルであって、本当の多様性ではないからです。対策は複数の生成器を混ぜて使い、合成データの中に一定比率の人手サンプルと書式の異常なサンプルを意図的に注入することです。

データ処理の段階で、個別に強調したい細部が 3 つあります。1 つは重複除去、特に画像テキストペアの意味的な重複除去です。ウェブ上の画像テキストペアの重複率は非常に高く、重複サンプルはモデルの特定の発言に対して異常なほど強い偏りを作ります。2 つは配比のバランスで、ある種のタスクがデータの中で圧倒的多数を占めてはいけません。とくに多輪対話と単輪问答の比率は、モデルが多輪のときにさらに質問を続けるのか直接答えるのかに直結します。3 つは長さの分布で、長い回答サンプルと短い回答サンプルの比率がモデルの既定の出力長を決めます。答えが冗長すぎたり短すぎたりするモデルの根本原因は、モデルではなくここにあるのです。

最後はデータとアーキテクチャの連動です。具体例を挙げると、システムがタイル分割戦略を大量に使う場合、学習データにも同じタイル分割ロジックが出力する複数画像サンプルが含まれていなければなりません。そうしないと推論時にモデルが見る分布と学習時に見る分布が食い違い、結果として単一画像タスクは良く、複数画像タスクは悪くなります。同様に、推論で OCR の二重チャネルを使っているなら、学習時にも相当比率の「OCR テキスト＋画像」サンプルを含めるべきです。アーキテクチャの判断とデータパイプラインは一緒に変更しないと、変更の半分が生きません。

六、特殊な入力形態:複数画像、動画、文字密度の高い画像

ここまで議論したのは単一画像の標準的なパイプラインです。実際の業務でもっとも問題になりやすいのは、むしろ以下のいずれかの入力形態です。難点はモデル自体ではなく、シーケンスの組み立て方にあります。

6.1 複数画像入力

複数画像入力の実装は、見かけよりもずっと細々したものです。解くべき問題が 3 つあります。第 1 は画像 token をシーケンスのどこにどう配置するかです。すべてをテキストの前に置き換えるのか、対応するターンにプレースホルダを差し込むのか、この 2 つの方式では挙動が明確に異なります。前置きの方式はモデルが画像順序に敏感になり、プレースホルダの方式は画像とテキストが交互に並ぶ指示文の扱いは良好ですが、前処理はより複雑になります。第 2 は位置エンコーディングの連続性です。複数の画像を同じシーケンスに連結したとき、位置番号は全体として連続していなければなりません。連続していなければ、モデルは画像どうしの境界を意味的な断裂とみなします。現れ方は、画像横断的な推論（2 枚の画像を比べる）が単一画像タスクより明らかに弱い、というものです。第 3 は画像順序への感度です。実装によっては順序に非常に敏感で、2 枚の順序を入れ替えると答えが変わります。画像とテキストを対照させる種のタスクではこれが致命的になるため、学習データに順序を明示的に揺らしたサンプルを加えてロバスト性を高める必要があります。

複数画像には容量の問題もあります。N 枚の画像は N 倍の token を意味し、予算はすぐ逼迫します。一般的な対処は、主画像に十分な予算を割り当て、従属する画像は圧縮する、さらに踏み込んで、質問の中で明示的に参照されている画像だけに十分な予算を割り当て、残りにはサムネイルを使う、というものです。この戦略の本質は、言語側の指示表現情報を用いて視覚側の予算配分を導くことにあり、均等に配分するより多くの場合に高い効果が得られます。

6.2 動画入力

動画入力でもっとも楽な実装は、フレームを抽出して擬似的な画像列にし、フレームレートは毎秒 1 から 4 フレーム程度，然后把全体を画像側の経路に通すことです。この経路の最大の利点は、画像側の事前学習と既存のエンジニアリング一式をそのまま再利用できることです。欠点はフレーム間の連続性と本来の時間順序情報を失うことで、モデルが見ているのは実はまったく無関係な写真の数枚にすぎません。

真の改善の方向は、視覚塔に 3 次元位置エンコーディングを導入し、attention を時空間分離の形式に変えることです。たとえば時間次元には局所窓 attention、空間次元には全体 attention を割り当てる、あるいは逆に軸方向 attention を行う、という具合です。この設計によって、モデルは単一フレームの記述だけでなく、動きの順序、状態の変化、フレームをまたぐ一貫性についての質問に答えられます。代償はメモリと実装の複雑さが明らかに増えることで、しかも学習データの要件が画像テキストペアから「動画＋高品質な字幕」へと変わり、供給量が 1 桁減ります。

6.3 文字密度の高い画像:文書、表、UI

文書、表、グラフ、UI のスクリーンショットは、モデル間の差がもっともつきやすいシーンであり、同時にもっとも失敗しやすいシーンでもあります。典型的な失敗モードは次のようなものです。解像度が足りず筆画が色塊に潰れる。段組のレイアウトが 1 段として扱われ、連結された読み順序が間違う。表の行と列の整合が崩れて、モデルが隣り合うセルの内容を続けて読んでしまう。グラフの凡例や軸の文字が背景ノイズとして無視される。回転したテキスト、アーティスティックなフォント、手書き文字がそもそも認識されない。

それに対応するエンジニアリング上の対策は 4 系統あります。1 つ目は実効解像度を上げる、すなわちタイル分割して読み進めることです。これは物理的な必要条件であり、文字の高さの閾値はすでに計算しました。2 つ目は OCR で抽出したテキストを補助入力として原画像と一緒にモデルへ送り、文字情報がテキスト経路を通るようにすることです。ピクセルでこじ開けるのではなくテキスト経路に乗せるので、token を節約しつつ精度も高くなります。3 つ目はモデルに座標を出力させる、すなわち grounding です。検出的な中間教師によって文字ブロックと位置を結びつけて学習させ、後の表の抽出にはほとんど必須です。4 番目はもっとも素朴でもっとも有効な方法で、まず既存ツールで画像を構造化テキストにレンダリングし、その構造化テキストをモデルに読ませることです。

表や数値の抽出のようなタスクは、とくに強調しておきたいです。目的がすべてのセルの数値を正確に取得することであるなら、モデルにセルレベルの位置情報を出力させなければなりません。表の内容を読ませるだけでは、必ず行の連結とずれが生じます。文書系モデルの学習データで、座標教師がテキストだけの教師よりはるかに価値が高いのも、この理由です。座標教師は本質的に、視覚証拠に必ず整合せねばならないという強い制約をモデルに与えます。

6.4 高次元出力タスク

1 文の回答だけでなく、視覚言語モデルはセグメンテーションのマスク、深度マップ、人体の姿勢、検出ボックスも出力できます。これは視覚タスクを判別型から稠密予測へ変えるもので、対応する出力ヘッドの設計はまったく異なります。言語側のうしろにデコーダを付けるか、逆に視覚 token を query として下流のセグメンテーションネットワークを駆動するか、あるいはテキスト側で正規化座標列を生成して解析するか。最初の 2 つは通常より正確で、3 つ目は柔軟ですが追加の座標デコードと後処理が必要です。

コスト管理の鍵は、高解像度の特徴を必要とする場合に限って後続のネットワークへ通すことです。セグメンテーションヘッドがフル解像度を必要とするなら、その経路でのみ高解像度を使い、テキスト生成の経路は圧縮済みの token を使い続けます。2 本の経路は視覚塔を共有しますが、特徴の解像度は共有しません。ほとんどすべてのマルチタスク視覚言語システムで標準的に使われている手法です。

七、2026 年に見えてきた新しい動向

7.1 ネイティブマルチモーダルと統一 token 空間

この方向の中核的な主張は、後に射影層を付けるのをやめて、学習の最初から画像、テキスト、音声で 1 つの token 空間と 1 組のモデル重みを共有させる、というものです。利点は直接的です。モダリティどうしが互いに補完でき、画像とテキストが交錯する長文書類の理解能力が明らかに強くなり、言語側の推論も視覚証拠によってより強く拘束されます。代償は学習コストが非常に高く、データ配比の調整が非常に難しく、どのモダリティか 1 つでもデータの品質が足りないと全体を弱めてしまいます。

2026 年の時点で、この方向は論文の段階を過ぎ、実際にシステムを落地させる段階に入っています。ただし中小規模のチームにとって全量の事前学習はもう現実的ではありません。より現実的な道は、オープンソースの統合モデルの重みの上に領域の継続学習を行うこと、自分のシーンでもっとも欠けているモダリティを重点的に補うことです。たとえば大規模な専門グラフや、特定形式の文書です。ゼロから統合モデルを学習しようとはしないことです。この道で実務的な判断はこうです。領域の継続学習ではデータの質のほうがデータ量より重要で、数万件の高品質な領域サンプルは通常、数百万件の汎用サンプルより大きな利得をもたらします。

7.2 動画と時空間モデリング

動画理解の重点は、フレーム抽出による QA から時空間推論へと移っています。動きの順序、状態の変化、フレームをまたぐ一貫性、長時間の出来事です。これは、モデルをフレームを独立した画像として扱うだけでは不十分とし、明示的な時間位置エンコーディングと時間次元の attention 構造を持たせることを要求します。あるシステムが本当に時空間モデリングを行っているかを判断するには、非常に簡単なテストがあります。入力フレームの順序をシャッフルし、答えがまったく変わらないなら、そのシステムはほとんど時間モデリングをしておらず、複数画像の記述をしているだけです。

7.3 視覚 token の極限圧縮

視覚 token を減らすことは、現在もっともエンジニアリング価値の高い方向のひとつです。利得分が直接的だからです。シーケンスが短くなり、メモリが下がり、スループットが上がり、同じカードで捌ける同時実行数が増えます。主たる手段には、類似 token の統合、空間プーリング、query resampler、そして内容に適応した token 数の割当があります。リスクは圧縮比と細部タスクの精度とのトレードオフであり、圧縮戦略が学習不可能なハードルールである場合、モデルがそれに適応するための追加の学習量が必要になります。私の判断は、圧縮を視覚塔の後段、言語モデルの前に置くことが利得と損失のもっとも釣り合う位置だというものです。言語モデルの内部で動的な token 数を行うのはより攻めた選択で、現時点ではまだ脆いです。

7.4 視覚側の疎密化と疎な専門家の活用

言語側の疎な専門家の考え方を視覚側へ移すことは、高解像度をコストの上限から選択可能な項目に変えるための鍵です。高解像度の特徴を、選ばれた少数の専門家の中だけで重く計算し、他の token は共有の軽量な経路を通します。2026 年でもっとも成熟した方法は、疎な選択を塔全体ではなく視覚塔の後段に置くことで、前段は密のまま保ち、低層のディテールを失うことを防ぐことです。この判断の直接の根拠は、低層特徴が担うのはエッジとテクスチャの抽出であり、この種の情報は疎な選択には不向きで、高層の意味だけが疎な化に適しているからです。

7.5 見ることから、ツールを使うことへ

アーキテクチャの層では、モデルが外部の視覚ツールを呼び出すことを学び始めるという明確な動向があります。拡大と切り出し、OCR の呼び出し、検出器の呼び出し、レンダラーの呼び出しです。これは本質的に、解像度予算の問題をアーキテクチャ層から推論戦略層へ移すもので、1 回のフォワードにすべてのピクセルを押し込むのではなく、モデル自身にどこを見るか、何回見るか、何周するかを決めさせるということです。この方向の価値は大きい一方、それに追随する学習上の難問も小さくない。ツールを先に呼び出してから答える軌跡のデータを構築する必要があり、教師信号は通常の指示文データよりも遥かに疎で、しかも推論時に複数回の呼び出しが発生する遅延コストを業務側が許容できる必要があります。これはすでに純粋なアーキテクチャの問題ではなく、エージェントの学習パラダイムに近づいています。

7.6 評価と診断:どの段階の問題かの切り分け

マルチモーダルシステムの評価には特殊な難しさがあります。効果が悪いとき、視覚塔が見ていないのか、射影層が潰してしまったのか、言語モデルが使い方を覚えていないのかを判別しにくいことです。場当たり的にあ手を尽くして回すのがもっとも効率の悪い診断方法です。実行可能な診断順序は、まず視覚塔の特徴品質を測り、次に射影層の情報忠実度を測り、最後になってようやく言語モデルを疑う、というものです。

第 1 歩は、入力画像を単独で視覚塔へ送り、特徴マップが文字領域で明確な応答を示すかを見ます。応答自体が弱ければ、問題は視覚塔か解像度にあるので、すぐに解像度を上げるか塔を交換し、ほかを見る必要はありません。第 2 歩は射影の前後で特徴の類似度を確認します。射影のあと、異なる領域の token がほぼ区別できなくなっているなら、問題は射影層の圧縮比か正規化にあるので、より浅い射影に替えて測り直します。第 3 歩で初めて言語モデルの挙動を見ます。質問を理解しているか、単に画像を見ずに言語の事前知識で当て推量していないか、ということです。

非常に実用的な対照実験が 1 つあります。画像を真っ白な画像やランダムノイズの画像に差し替えて、同じ問いを繰り返します。モデルの回答内容が本物の画像を見たときとほとんど同じなら、視覚情報をまったく使っていないということで、問題は必ず前 2 つの段階にあります。テストのコストはきわめて低く、それでもっとも誤診されやすい段階を一発で除外できます。標準の切り分け手順としてデバッグの流れに書き込んでおく価値があります。

評価セットの構成方法も重要です。タスク種別で層に分けるほうが、データ出所で層に分けるより診断価値があります。自然なシーンの QA、文字の読み取り、計数、空間位置特定、細粒度の認識、拒答のキャリブレーション、それぞれの層を単独で採点します。あいまいな総合点が上がったとしても文字読み取りの層が落ちているなら、この変化は総合点の中ではまったく判別できません。本番で問題发生后では手遅れです。

八、実装選定のチェックリストとよくある落とし穴

これまでの判断を実行可能なチェックリストに圧縮し、順番に一つずつ確認していくことは、アーキテクチャの総説を 10 篇読むより有用です。

  • まず token 予算を計算してから解像度を決めます。実業務で扱う画像から文字の高さと token 数を見積もり、まず純粋なピクセル方式が物理的に足りるかを確かめます。
  • 視覚塔は、まずアライメント済みの成熟した重みを優先し、必要なら最終段の数個の block だけ解凍します。しかも文字タスクで実際にスコアが上がるかを検証してからにします。
  • 射影層はデフォルトで 2 層 MLP。浅いから中程度の深度を優先し、浮いた計算量は解像度と多層特徴に使います。
  • 射影の前後に 1 層ずつ正規化を加え、半精度学習の初期における非数の崩壊を防ぎます。
  • 指示文ファインチューニングの前にデータ書式のテンプレートを統一し、サンプリングして人手で確認し、位置番号は連結のたびに連続番号へ振り直します。
  • 視覚サンプルと純テキストサンプルの比率は、視覚側が数十パーセントのあたりから出発し、タスクに応じて上げていきます。
  • 拒答と幻覚に関する選好データは必ず用意します。そうでなければ高解像度が制約されると、モデルは自信満々に細部をでっち上げます。
  • 選好最適化の学習率は指示文ファインチューニングの 10 分の 1 の程度まで圧縮し、過度な拒答の指標は単独で監視します。
  • 文字密度の高いシーンでは、解像度を無限に積み上げるのではなく、OCR テキストと画像の二重チャネルを優先して考えます。
  • 表や数値の抽出タスクには必ず座標教師を加えます。テキストだけの教師では、行の連結とずれが必ず発生します。

頻度の高い落とし穴をいくつか個別に強調します。1 つめは、アライメント事前学習と指示文ファインチューニングを混ぜてやってしまうことです。ベースラインも取らずにデータ配比を調整しようとすると、得られた改善は原因を帰属できません。2 つめは、解像度を上げた後に長シーケンスの学習設定を同期的に調整しなかったことで、学習時は正常なのに推論時に長超出ます。3 つめは、複数画像サンプルの位置番号を連続番号へ振り直していないことで、画像横断的な推論が理由の分からないまま弱くなります。4 つめは、視覚塔の解凍しすぎで、もともと整っていたアライメント済みの特徴空間を壊し、汎用能力が逆に退化したことです。

もう 1 つ、デプロイに関する現実的な判断があります。視覚 token が多いことは効果が必ず良いことを意味しませんが、より高い推論コストをほぼ確実に意味します。提案書を書くときは、効果の比較だけでなく、token 数、リクエスト 1 件あたりのメモリ使用量、推定スループットの 3 つの数字を併せて出すべきです。この 3 つが、業務側が意思決定をするための材料になります。

シーン推奨する視覚塔解像度戦略射影層
汎用的な画像 QA成熟した自己 attention 重み中程度の固定解像度2 層 MLP
文書と表多層特徴、文字教師を重視動的タイル分割＋OCR の二重チャネル浅い射影でディテールを保持
リアルタイム映像ストリーム畳み込みバックボーン＋ attention のハイブリッド低解像度でのフレーム抽出線形から浅い MLP
長時間の動画理解3 次元位置エンコーディング付きの自己 attention時系列窓＋空間圧縮query resampler
高解像度画像編集階層的なディテール保持を行う自己 attention最高解像度多層特徴の融合射影

8.1 メモリとスループットの本当のボトルネック

解像度を上げたあと、ボトルネックは几乎必ず視覚塔から言語側のシーケンス長へ移ります。このとき有効な最適化順序は、まず gradient checkpointing と視覚塔の凍結キャッシュ、次にシーケンス並列化あるいはバケット分けによる padding の削減、最後に初めて量子化を考える、というものです。各ステップの利得は逓減しますが、最初の 1 ステップで通常は大半の問題が解決します。アライメント事前学習と指示文ファインチューニングの 2 段階ではメモリピークの発生源がまったく異なるためで、前者は射影層の大バッチ・高解像度によって決まり、後者は長シーケンスの全パラメータ言語モデルによって決まります。

8.2 推論・デプロイ側での視覚 token の管理

学習時に決めた token 予算は、デプロイ時にさらに 1 回増幅されてコスト問題になります。理由は単純で、本番のリクエストの画像は学習データ内のものより難しく、より多くの token がなければ見分けられない一方、ユーザーは待ちたくないからです。デプロイ側でよく使われる手段は、キャッシュと段階的予算の 2 つです。

キャッシュについては、多輪対話でもっとも典型的な問題は、同じ画像が毎ターンで再度エンコードされることです。正しい方法は視覚 token を prefix にキャッシュし、後続のターンではテキスト token だけを追加するようにすることです。そうすれば prefix キャッシュがヒットし、視覚エンコードのコストは 1 度だけ払えば済みます。前提は、視覚 token の位置がテキストより前にあること、あるいはプレースホルダで挿入しつつ同じ prefix を維持することです。毎ターンで画像を異なる位置に挿入するなら、キャッシュは永遠にヒットしません。この 1 項目の実装上の利得は、視覚側のどの最適化よりも大きくなりがちで、しかもモデルをほとんど変更せずに済みます。

段階的予算はより能動的な手法です。まず軽量な判別器やルールで画像の難易度と寸法を素早く判定し、簡単な画像には小さい予算で直接回答し、複雑な画像にだけ十分な予算を与えて完全な手順を通します。文書のスクリーンショットのようにほぼ必ず高予算が必要な入力に対しては、この判定はほとんど外れません。チャットに添える写真のような簡単なシーンでは、節約できる計算量は相当大きなものになります。

圧縮は推論側で行うこともできますし、訓練側で圧縮するほうが割に合う場合が多く、それは再学習が不要だからです。方法は、視覚 token の最初と最後を保持し、類似度で選んだ代表 token をいくつか加えて残し、それ以外を捨てて、モデル自身が推論時にこの疎な入力に適応するようにすることです。ただしモデルが疎な入力をまったく見たことがなければ効果は落ちるので、より安定した順序は、まずキャッシュ、次に段階的予算、最後に推論側の切り詰め、というものです。

デプロイ側で最後に監視すべき指標は 3 つあります。視覚 token の P95 の長さ、リクエスト 1 件あたりのメモリピーク、そしてキャッシュヒット率です。この 3 つの数値が同時実行容量とテールレイテンシを決めます。平均 token 数より有用なのは、ユーザーが感じるもたつきがほぼすべて長尾に由来するからです。

九、まとめ

パイプライン全体を振り返ると、マルチモーダル大モデルのアーキテクチャ選択は、結局 3 つの決定的な問題に収束します。視覚塔はどんな形のベクトルを出力するか、射影層はいくつの token を残すか、学習時にどの部分のパラメータが動くか。この 3 つの問いの答えが、モデルの能力境界とコスト構造を共同で決定し、残りの細部はすべてこの 3 つの答えの下で局所的な最適化が行われています。

ほとんどのエンジニアリングチームにとって、もっとも省力な経路は次のようなものです。成熟したアライメント済み視覚塔＋2 層 MLP の射影層＋明確な token 予算＋順序立てられた 3 段階の学習手順。浮いた労力はデータの品質と特殊な入力形態の処理に使います。本当に差別化を生むのは、ある構造をより凝ったものに変えることではなく、文書、複数画像、動画という難しい入力形態を丁寧に処理することです。

覚えておく価値のある判断は、アーキテクチャがカバーできるのは解像度が足りないことで生じる問題であり、カバーできないのはそもそも十分なピクセルを与えていない、ということです。文字密度の高いタスクにおける投入対効果の優先度は、ほぼすべてのアーキテクチャ改造より前に置かれるべきです。見開き文書の入力を 448 から 896 へ上げるために計算量を 2 倍使うなら、その効果は射影層を 2 層から 4 層へ深くするより通常上大です。

本稿で扱うのはアーキテクチャの層だけです。本格的なマルチモーダルアプリ開発、システムプロンプト設計、ツール呼び出しのオーケストレーションは別の主線に属し、本稿のトレードオフ判断とはほぼ直交します。混ぜて話すとどちらもうまく説明できません。アーキテクチャが用意してくれるのは、上限が明確で、コストも推測できる基盤モデルです。その上限より上をどこまで引き出せるかは、エンジニアリングとデータで決まります。

もう 1 つ、見落とされがちな判断として、マルチモーダルシステム能力の上限は、もっとも強い段階によってではなく、もっとも弱い段階によって決まるということです。視覚塔は先端的なのに射影層の圧縮が過剰なシステムは、文字タスクでは、視覚塔は平凡でも解像度が十分与えられた素朴なシステムに負けます。したがってアーキテクチャレビューで行うべきは、最も長い板ではなく、最も短い板を探すことです。

そして 2026 年という時点から振り返ると、ネイティブマルチモーダルの収束、時空間モデリングの補完、そしてモデルが視覚ツールを能動的に呼び出すことを学ぶという 3 本の線が、同じ方向へ向かっています。視覚はモデルに対する一度限りの入力ではなく、必要なときに必要な分だけ引き出し、必要なときに拡大し、必要なときに表現を切り替える動的なリソースになります。この一点を理解することは、いかなる具体的な構造を覚えるよりも重要です。