モデル覚書

土台はむしろ共通化してきている

意外に思われるかもしれませんが、いま主流の画像・動画モデルの中身も Transformer です。画像を小さな四角（パッチ）に切り、それを並びとして扱えば、文章と同じ機械が使える。だから「絵のモデル」と「言葉のモデル」は、部品としてはよく似ています。

違うのは、その機械に何を練習させたか。

三つのつまみ

この表の右端が、そのまま伸びの速さになっています。機械で採点できる領域は、人手を待たずに何万回でも練習を回せるからです。コードと数学だけが突出して速く伸びてきた理由は、ほぼこれです。

言語モデルが左から右へ一語ずつ書くのに対し、画像モデルは一枚まるごとを、ぼんやりからくっきりへ持っていきます。拡散モデル（diffusion）と呼ばれる方式です。

学習は「足したノイズを当てる」

やっていることは、次の一行に尽きます。

正解（足したノイズ）は自分で作ったものなので、人が正解を書く必要がありません。第1回の「正解がデータの中にある」と同じ構図です。だから画像も、いくらでもデータを増やせました。

なぜ言葉で指示できるのか

鍵は、言葉と絵を同じ座標系に置くことです。画像とその説明文の対を大量に集め、対応する組は近くへ、無関係な組は遠くへ、と座標を訓練します（対照学習。CLIP がその代表です）。

この空間ができると、「夕暮れの港」という文をベクトルに変え、そのベクトルを目印にノイズを取り除いていける。言葉が、絵を削り出す方向を指す羅針盤になるわけです。

潜在空間 — 画素のままでは重すぎる

1024×1024 の画素をそのまま扱うと計算が持ちません。そこで先に別のネットワークで縦横それぞれ 1/8 ほどに圧縮した潜在空間を作り、そこで拡散を回し、最後に画像へ戻します。手元のPCで画像生成が動くのは、この工夫のおかげです。

文字と手が苦手だった理由

拡散は「その場所らしさ」を積み上げていく方式です。局所的にもっともらしければ損失は下がる。ところが文字は、一画でも違えば意味が壊れる正確な並びを要求します。指も同じで、五本という数え上げは局所的なもっともらしさでは守れません。

近年これが改善したのは、言葉側のエンコーダを大きくし、説明文の質を上げ、モデル自体を大きくしたためです。仕組みが変わったというより、苦手だった部分に資源を注いだ結果に近い。

動画は「画像が並んだもの」ではありません。次元がひとつ増えると、質の違う難しさが出てきます。

難しさ① 量

512×512 の絵を毎秒24枚、5秒ぶん作れば、扱う情報は一枚絵の百倍を超えます。第1回・二章の「2乗のコスト」がそのまま効くので、長さを倍にすると計算は倍では済みません。生成できる長さが数秒〜十数秒に留まりがちなのは、この壁です。

難しさ② 一貫性

フレームを一枚ずつ独立に描くと、次の瞬間には別人になります。そこで時間方向にも Attention を通す。ある瞬間の画素が、前後のフレームの同じあたりを参照しながら決まる仕組みです。

実装としては、画像と同じく時空間をパッチに切り、Transformer で処理する形（DiT）が主流になりました。これにより、言語モデルで確かめられてきた大きくすれば良くなるという経験則が、そのまま動画にも効くようになっています。

物理は教えていない

誤解されやすいところですが、モデルに重力や流体の式は入っていません。膨大な映像から「落ちるものはこう見える」「水はこう動く」という見た目の規則性を学んでいるだけです。

だから、よくある場面は驚くほど自然なのに、物が一瞬で消えたり、増えたり、手前と奥が入れ替わったりする。もっともらしさは満たしているが、保存則は守っていない——これは第1回・四章の幻覚と、根が同じ現象です。

① 実行が正解になる

文章の良し悪しは人が決めるしかありませんが、コードはテストが通るかどうかで決まります。すると報酬モデル（第1回・三章）を挟まず、正解そのものを報酬にして学習を回せる。人手を待たない練習は、そのまま伸びの速さになります。

② 穴埋めの練習

エディタの補完は「続きを書く」だけでは足りません。カーソルの前後を見て真ん中を埋める必要がある。そこで学習時にわざと途中を隠し、前後から復元させる穴埋め（fill-in-the-middle）を混ぜます。

③ 長い文脈と、その外側

実務のコードでは、使う関数の定義が数百行離れていたり、別ファイルにあったりします。文脈長を伸ばすだけでは足りず、必要なファイルを探して渡す仕組みと組み合わせて初めて実用になります。第1回・六章のエージェントが効くのは、まさにこの部分です。

④ 形式が厳しいことは、むしろ有利

括弧ひとつで動かなくなる厳しさは、裏を返せば間違いが機械的に分かるということです。文章の「なんとなく変」は測れませんが、コードの「動かない」は測れる。評価できる領域は、改善が積み上がります。

「意図を理解している」ように見える部分を、順に分解します。結論から言えば、理解というより条件付けです。

① 事前学習で「会話の型」を大量に読んでいる

ウェブには質問と回答、相談と助言、課題と解説が無数にあります。次の語を当てる練習の過程で、「こう訊かれたら、こう答えるのが自然」という型そのものが身についていきます。

② 事後学習で「答える側に立つ」ことを覚える

素のモデルは質問に質問を返すことすらあります。指示と模範解答の組で追加学習し、人の評価で磨く（第1回・三章）。ここで初めて、訊かれたら答えるという立ち位置が固定されます。

③ 実際の推測 — 手がかりの重みづけ

入力からは、書かれていること以上の情報が読み取れます。

• 使われている語彙と丁寧さ ── 相手の立場と、求められている距離感
• 貼られたコードの言語やフレームワーク ── 前提となる環境
• 専門用語の有無 ── どこまで噛み砕くべきか
• 直前までのやりとり ── いま何を作ろうとしているのか

これらを Attention が重みづけて、この文脈でもっともあり得る続きを作る。「意図を読む」の実体は、この重みづけです。

④ 曖昧さに気づくかどうか

近年のモデルは、前提が足りないときに聞き返す振る舞いも学習しています。ただしそれは「分からないことが分かった」というより、聞き返した方が評価が高かったという学習の結果です。過信せず、こちらから前提を書く方が確実です。

バグの検出は、性質の違う三つの層が重なって成立しています。

層① 典型形の記憶

学習データには、公開リポジトリの修正コミットが大量に含まれます。「壊れた状態」と「直した状態」が対になって並んでいる。そこから、境界の一つずれ、未チェックの null、閉じ忘れたリソース、握りつぶした例外、といった典型形が身につきます。

これは知識としての検出で、速く、広く効きます。

層② 意味の食い違いを見る

より人間のレビューに近いのがこちらです。名前・コメント・型・呼び出し側の期待と、実際の処理を突き合わせる。

リンタは「floor は正しい関数だ」としか言えません。ここを拾えるのは、コメントとコードを同じ文脈の中で照らし合わせているからです。

層③ 実際に動かす

読むだけでは限界があります。テストを書いて走らせる、エラーを再現する、スタックトレースを読んで仮説を絞る——第1回・六章のエージェントが担うのはこの層です。推測を検証に変えるここが入って、初めて実用の精度になります。

得意と不得意

静的解析との住み分け

リンタや型検査は規則の集合です。網羅的で再現するが、規則の外は見えない。モデルは読めば分かる不整合を拾えるが、網羅性がなく、実行のたびに違うことを言う可能性がある。

性質が逆なので、置き換えではなく重ねるのが現実的です。機械的に測れるものは静的解析に任せ、モデルには「意図と実装のずれ」を見てもらう。