圧縮＝予測＝知能 — 情報理論から見るLLM

次のトークンを当てる訓練は、そのままファイルを縮める訓練でもあります。算術符号化を経由すると「確率モデル」と「符号」が同じものだと分かり、交差エントロピー損失が圧縮後のバイト数そのものになる。Hutter Prizeが圧縮率を知能の指標に据えた理由まで、1から積み上げます。

Language Modeling Is Compression

続きが読める人は、少ない字数で伝えられる

「本日は晴天な＿＿」と書かれた紙を渡されたら、日本語を知っている人はまず「り」を補います。ということは、この1文字は送らなくても伝わる。受け手が自分で復元できるからです。逆に「本日は晴天な虎」と書きたいなら、最後の1文字は省けません。誰も予測できないからです。

ここに圧縮という技術のすべてが入っています。予測できる部分は送らなくていい。予測できない部分だけ送ればいい。 ただし現実の言語は「完全に読める／全く読めない」の二択ではなく、「次は『り』が9割、他が1割」という中間にあります。この半端な確信を半端なままビット数に換算できれば、圧縮率は予測の質だけで決まることになります。

その換算をやるのが算術符号化であり、その「予測」を担う現時点で最良の道具が大規模言語モデルです。この記事では、LLMの訓練で使っている交差エントロピー損失が圧縮後のファイルサイズと文字通り同じ量であることを、一本道で示します。

符号長は、確率の対数で決まる

まず「予測の確からしさ」と「ビット数」の橋を架けます。

コイン投げの結果を送るには1ビット要ります。確率は $1/2$ ずつ。1024面のサイコロの出目なら10ビット（$2^{10} = 1024$）で、確率は $1/1024$ でした。並べると規則が見えます。必要なビット数は、確率の逆数の対数です。

$p(x)$ はその出来事が起きる確率、$\ell(x)$ はそれを伝えるのに要するビット数です。要するに、ありふれた出来事は短く、珍しい出来事は長く書ける、と言っているだけ。マイナスは、$\log_2 0.5 = -1$ のように確率の対数が負になるのを正のビット数に戻しているだけです。

大事なのは、この関係が両方向に成り立つことです。確率が分かれば符号長が決まる。逆に符号長の割り当てが与えられれば、そこから確率分布を復元できます（クラフトの不等式が保証します）。つまり確率モデルと符号は、同じものの二つの呼び名です。良い予測器を作った人は、すでに良い圧縮器を作っている。あとは両者を機械的に行き来する装置が要るだけです。

この対応が分かると、圧縮まわりでよく起きるすれ違いも解けます。「うちの圧縮器はモデルなんて使っていない」と言うとき、実際には符号表という形で確率モデルを持っているだけです。モデルを持たない圧縮器は存在しません。

この見方だと、エントロピー $H(p) = -\sum_x p(x)\log_2 p(x)$ は「最良の予測器を使ったときの平均ビット数」になります。シャノンはこれが下限——どんな符号を考えてもこれ以下にはできない値——であることを示しました（→情報理論とAI）。

算術符号化: 区間を刻んでいく

ここで問題が1つ。$-\log_2 p(x)$ はたいてい小数になります。確率0.9の出来事は約0.152ビットですが、ファイルに0.152ビットは書けません。

ハフマン符号のような「1記号＝1つのビット列」方式では、どんなに確率が高くても最低1ビット払わされます。0.152ビットで済むところに1ビット、6倍以上の無駄です。

算術符号化は、記号ごとに区切るのをやめてこれを外します。やることは区間を刻むだけ。

1. $[0, 1)$ から始める
2. 各記号に、確率の大きさに比例した幅を割り当てる
3. 実際に来た記号の区間まで狭め、その中で同じことを繰り返す
4. 最後に残った区間の中の数を1つ、2進小数で書き出す

A（確率0.5）、B（0.3）、C（0.2）の3記号で BA を送るとします。$[0,1)$ を A: $[0,\ 0.5)$、B: $[0.5,\ 0.8)$、C: $[0.8,\ 1)$ に割る。1文字目 B で $[0.5,\ 0.8)$（幅0.3）へ。その中を同じ比率で割り、2文字目 A で $[0.5,\ 0.65)$（幅0.15）へ。

最終的な幅0.15は $0.3 \times 0.5$、つまり BA という並びが起きる確率そのものです。この区間内の数を指定するのに要るビット数は約 $-\log_2 0.15 \approx 2.74$ ビット。実装上の上乗せは、メッセージ全体で高々2ビット程度に収まることが知られています。

つまり2.74ビットは、B の分と A の分の小数ビットが切り上げられずにそのまま足し合わされた結果です。1文字ごとに端数を捨てるハフマン符号との決定的な差がここにあります（比較とANSはエントロピー符号化を1から）。

そして、この先で効いてくる性質がもう一つ。手順2で使う確率は、毎ステップ違っていて構いません。 直前までに何が来たかを見て確率を作り直しても、エンコーダとデコーダが同じ手順で同じ数を出せる限り、復元は成立します。

この性質は昔から実装で使われてきました。H.264 や H.265 の CABAC は、符号化を進めながら文脈ごとの確率を更新していきます。両側が同じ更新規則を走らせるので、確率表を別途送らなくても復元できる。符号化の枠組み自体は数十年変わっていません——変わったのは、その口に何を挿すかだけです。

そして「確率を作り直す装置」の口が、いま空いています。