圧縮ソフトを「文章の続きを当てる装置」として使えるのか。そんな、少し変わっていて、それでいて情報理論の芯を突く実験を紹介したのが今回の話です。元記事は、機械学習の重みも学習済みモデルも使わず、OSに入っている gzip だけでテキスト生成を試しています。しかも単なる思いつきではなく、圧縮と予測が実は同じものだという見方を前提にしているのが面白いところです。結果は完璧な文章ではありませんが、意外なほど「何かを知っている」出力になっています。
著者は以前、ニューラルネットワークを使わずに言語モデルを作る話を書いていて、その流れで「Language Modeling is Compression」という論文に出会います。そこで示されるのが、予測と圧縮は表裏一体だという考え方です。ある文字や単語が起こりそうだと予測できるなら、その情報は短く符号化できる。逆に、圧縮アルゴリズムは「よく出る並び」を安く扱うので、裏返せば予測器でもある、というわけです。そこから著者は、ならば gzip でも言語モデルっぽいことができるのではないか、と考えます。
やり方はかなり素朴です。学習済みのネットワークはなく、パラメータもありません。代わりに、コーパスを gzip の内部状態に入れておき、普通のテキストプロンプトを与え、その続きを「最もよく圧縮される byte 列」として探します。元記事には tiny Shakespeare を使った実例があり、gzipt --corpus data/tinyshakespeare.txt --prompt $'MENENIUS:\n' --length 200 で実行すると、MENENIUS: に続いて Though all at once canq のような断片が出たあと、MARCIUS: や LARTIUS: といったシェイクスピア風の話者名を含む断片が混ざります。完全に筋の通った文ではないものの、著者は「gzip が思ったよりずっとテキストの癖を知っている」と感じたと書いています。
理屈はこうです。gzip が使う DEFLATE は、直近 32 KiB の sliding window の中から似た byte 列を探し、見つかったらその繰り返しを短い参照で表します。つまり、ある続きがコーパスや直前の文脈に似ていれば、圧縮後の長さは短くなる。逆に、まったく予想外の続きは長くなる。この性質をそのままスコアにして、len(gzip(context + candidate)) が小さい候補ほど「予測されている」とみなします。
ただし、1 byte ずつ一番よく圧縮される文字を選ぶやり方はうまくいきません。gzip は小数ではなく byte 長しか返さないので、候補間の差が丸め込みで消えてしまうからです。そこで著者は beam search を使います。今ある文脈に対して、コーパスに出てくる byte を全部試し、圧縮後の長さが小さい候補を上位 beam_width 個だけ残す。これを horizon byte 分先まで進め、最後にもっとも圧縮できる塊を採用して文章を伸ばします。生成の文脈にはコーパス全体ではなく「最近の尾部」だけを残すのも重要で、そうしないと gzip が過去に自分で出した文字列を延々とコピーし続けるループに落ちやすいからです。
実装は zlib を使った Python の標準ライブラリだけで書かれていて、著者は GitHub にコードも置いています。なお、元記事の脚注では、論文でもこの発想自体は試されたが結果は芳しくなく、beam search を足すことでかなり改善したと触れています。
この実験でいちばん面白いのは、gzip が「文章を理解している」ことではなく、理解っぽさがどこから出るかを見せている点だと思います。圧縮器は、次に来る byte を当てられるほど得をする。だから予測器であり、予測器は圧縮器でもある、という説明はきれいです。普段は言語モデルを「意味を持つもの」として見がちですが、実際には頻度や反復、近さのような統計的な手がかりでもそれなりに振る舞えてしまう。gzip の出力がどこかシェイクスピアっぽく見えるのは、その最低限の構造を拾っているからでしょう。
ただ、ここには大事な限界もあります。gzip は意味を持ちません。登場人物の関係も、会話の流れも、物語の整合性も知らない。あるのは近くの byte の再利用だけです。だから出力は「それらしく見える断片」の寄せ集めになりやすい。これは欠点である一方、言語モデルの本質の一部でもあるのかもしれません。人間が文章を読むときも、完全な論理ではなく、反復や定型、文体の手がかりで先を補っている面があるからです。gzip はその極端に単純な版だと見ると、なかなか示唆的です。
beam search を使っている点も、実はかなり本質的だと思います。圧縮長は離散的なので、1 byte 単位の貪欲法ではノイズに埋もれる。そこで少し先まで見て塊で決めると、急に意味のある並びが出てくる。これは、局所的な最適化だけでは文章が組み上がらないことを示しています。ニューラルモデルでも、次の1語だけでなく少し先までの候補を見た方が安定する場面がある。圧縮器の話に見えて、実は生成そのものの難しさをかなり素直に突いています。
この手法が気になるのは、学習済みモデルとは別の場所で、言語らしさが立ち上がるからです。gzip は「訓練された知識」を持っていませんが、コーパスを窓に入れた瞬間、その中で何が繰り返され、何が安いかというルールを即座に反映します。要するに、固定された脳ではなく、目の前のテキストに合わせて一時的にふるまいを変える仕組みです。そこに、見た目としての知性が出る。私はここに、LLM とは別系統の“軽い適応”の面白さがあると思います。
一方で、実用性はかなり限定的でしょう。生成速度は遅いはずですし、語彙の制御も細かくできない。なにより、意味の整合性を保証しません。それでもこの実験が無駄に見えないのは、モデルの正体を考え直させるからです。今の生成AIは巨大な学習済みモデルが中心ですが、言語を扱う仕組みはそれだけではない。圧縮、検索、最近傍の反復、局所統計。そうした古い技術の組み合わせでも、驚くほど「文章に見える」ものは作れる。これは、AI という言葉の幅の広さを思い出させます。
さらに言えば、こうした発想は、圧縮アルゴリズムの評価にも新しい見方を与えます。圧縮率が高いだけでなく、どれだけ予測能力を内包しているかを見る。逆に、言語モデルも単なる生成装置ではなく、どれだけ冗長性を見抜けるかという圧縮の問題として捉えられる。元記事は冗談っぽい題材を扱っていますが、実際にはかなり筋のいい問いです。gzip を言語モデルと呼ぶのは少し大げさでも、その境界が思ったほど硬くないことは確かだと思います。
この話のいいところは、派手な性能競争とは別の角度から「生成とは何か」を見せてくれることです。巨大モデルを持ち出さなくても、予測と圧縮の関係だけで文章生成の輪郭が見える。しかも、ただ理屈を述べるだけでなく、実際に tiny Shakespeare を食わせて出力を見せているので、抽象論で終わりません。シェイクスピアが少し崩れたような断片が返ってくる、あの半端さがむしろ説得力を持っています。
私は、この実験は「gzip が賢い」のではなく、「テキストには圧縮できる規則性がたくさん埋まっている」と示した点で価値があると思います。現代のLLMは意味理解のように見える振る舞いをしますが、その足場にはやはり繰り返しや定型、文脈依存の短い手がかりがある。gzip の実験は、その最下層を可視化している感じです。言い換えると、言語モデルを特別な魔法としてではなく、情報の偏りを利用する仕組みとして眺め直すきっかけになります。
もちろん、これをそのまま実用化するのは難しいでしょう。でも、研究や発想法としてはかなり豊かです。ニューラルネットワークが主役の時代でも、古典的な圧縮や探索の技術から学べることはまだある。むしろ、そうした地味な道具を突き詰めたところに、今の生成AIを理解する手がかりが隠れているのではないか。元記事はそのことを、かなり遊び心のある形で教えてくれます。
