← #811

gzip 能当语言模型用吗？

文章摘要

作者 Nathan Barry 之前写过一篇”不用神经网络做语言建模”，用无界 n-gram 模型生成莎士比亚：没有权重，没有训练，只是计数。后来他读到 DeepMind 的论文《Language Modeling is Compression》，其中提到”压缩—预测等价性”：每个预测模型本质上都是压缩器，所有压缩算法也都是预测模型。于是他问了一个自然的问题：gzip 能做语言建模吗？不要神经网络，不要学习参数，就用操作系统自带的那个压缩器。

他写了个叫 gzipt 的小工具：先用语料”预热”gzip，给它一段普通文本提示，然后它通过搜索”压缩效果最好的字节序列”来续写。以 tiny Shakespeare 为语料、提示词为 MENENIUS: 时，生成 200 字节的真实、未经编辑的输出是这样的：先是一句夹着乱码的 MENENIUS 台词，然后切到 MARCIUS 说”Pray now, nocamest thou to a morsel”，再切到 LARTIUS……他的评价是”算是可以？”——文本并不连贯，但它显然”知道”一些关于这段文字的东西，比他预想中 gzip 能知道的多得多。

压缩即预测。 压缩器会在它”预期”的数据上花很少的字节，在意外的数据上花很多字节。一个由一百万个字母 A 组成的文件一句话就能描述，而一百万个随机字节几乎无法压缩。这不是巧合，而是信息论的核心：编码一个符号需要 −log₂p 比特，p 是模型给它的概率，概率越高比特越少。所以任何压缩器内部都藏着一个概率模型，不管有没有人把它写下来。

gzip 使用的 DEFLATE 算法，会在最近 32 KiB 的滑动窗口里寻找与接下来字节的匹配。如果某段续写重复了窗口里已有的内容，DEFLATE 就把它编码成一个廉价的回溯引用，而不是逐字存储。因此，gzip”预期”的续写（因为它呼应了窗口中已有的文本）几乎不占空间。这就得到了一个打分函数：候选续写的分数 = len(gzip(上下文 + 候选))，压缩后越短，这个候选就越”被预测到”。为了预热模型，他把语料放进 gzip 的窗口里，于是任何像语料的续写都压得很小，不像的则压得很大。

用束搜索来生成。 打分是一回事，生成是另一回事。最朴素的做法是每次挑选使压缩结果最短的下一个字节，但这会惨败，原因很微妙：gzip 只给出整数字节长度，没有小数。多加一个字节常常根本不改变压缩长度，于是大量候选打平，信号淹没在量化噪声里。解决办法是先向前看一整段再做决定。gzipt 在字节序列上运行束搜索，每一步的上下文是”语料窗口 + （提示词 + 已生成字节）的最近尾部”，循环如下：

提示：以用户的提示词作为续写起点。没有起始 token，提示词字节只是 gzip 看到的上下文的一部分。
上下文：给 gzip 看语料窗口加上提示词/已生成文本的最近尾部。
搜索：保留 beam_width 个最可压缩的部分续写，用语料中出现过的每个字节去扩展它们，全部按压缩长度打分，再剪回 beam_width 个，重复 horizon 个字节。
提交：取最可压缩的完整片段（或在温度为正时从候选中采样），追加到输出，然后重新开始循环。

一个关键细节是：评分上下文里只保留最后一小段已生成的输出。DEFLATE 对近处的匹配编码得比远处更便宜，如果让 gzip 看到全部历史，最省字节的做法往往就是掉进逐字循环，反复复制自己刚刚输出过的文字。

整个工具是一个纯标准库 Python 文件（只用 zlib），代码在 GitHub 上。两个脚注也值得一提：那篇论文其实试过用压缩器生成，但效果很差，加入束搜索（论文中提到过的想法）显著提升了生成质量；另外代码实际用的是 zlib 而不是调用 gzip 进程，”但 GziPT 这个名字实在太好了”，两者底层都是 DEFLATE。

HN 评论精华

159 条评论，404 分。评论区有不少玩笑，但也有几条非常硬核的反驳和复现实验。

最有力的反驳来自 shoo 的实验：这个”最优化”目标本身就有问题。 mg 先提出疑问：搜索空间比束搜索覆盖的范围大许多个数量级，我们怎么知道搜索做得好不好？shoo 顺着这个思路指出：DEFLATE 的核心成分之一就是把重复子串换成对前文的回溯引用，所以如果语料里存在”提示词 + 某 200 字节”这样的子串，直接把它照抄过来就是一个极好的近似最优解。他动手验证：语料取 tinyshakespeare.txt 前 30000 字节，提示词 MENENIUS:\n，目标函数是压缩后长度。空字符串（不可行解）13023 字节；gzipt 的束搜索得到 13051 字节，耗时 11.93 秒；而他写的”rfind”方法——在语料里找到提示词最后一次出现的位置，把后面 200 字节原样复制——得到 13026 字节，只比空字符串多 3 个字节，耗时 0.04 秒。复制出来的就是莎士比亚原文（MENENIUS 说”O, true-bred!”，接着是元老的台词）。他的结论：大段重复输入上下文，能极好地最小化压缩长度，但作为生成模型毫无用处。

StilesCrisis 从另一面补刀：作者其实并不是在找压缩最好的输出，因为那样很快就会退化成 aaaaaaa，于是只保留最近一小段文本做上下文。”我觉得整个前提就垮在这个选择上——他们通过调整算法，直到 gzip 开始挑随机的字母块而不是越来越长的重复串，从而强行得到一个看起来有趣的结果。”im_down_w_otp 回怼说这和 LLM 被施加的调教相比不值一提；Dylan16807 也认为这里的调优参数很少、很通用，没理由因此否定它。

换成别的压缩器会怎样？ networked 让 MiMo-V2.6-Flash 分叉了 gzipt 代码做了对比：bzip2 生成的是 “yxyxyxyvyyy” 之类完全不像人类语言的序列，看起来是在为 Burrows-Wheeler 变换优化出最重复的模式；zstd 则输出一堆空白夹着零星字母，因为 zstd 把单字节重复编码成几乎免费的游程，而空格和换行是语料里最便宜的字面量。他后来又试了 LZMA，得到几个词后接大量空白；python-lz4 则在提示词后面全是换行，因为不同候选的压缩长度完全相同。jeremyjh 质疑他让 AI 写了自己不懂的代码，networked 贴出了关键 diff 并解释：zlib 默认按自己的块划分输入，所以先压缩上下文再克隆编码器状态，与每次整体压缩的结果一致，他在温度为零时验证了与上游最新提交输出相同。

这是不是在把压缩等同于智能？ bob1029 认为不加注意力机制或类似东西就不行：”gzip 能对一个非常特定的叙事预测下一个 token，LLM 能对整个叙事宇宙做预测”，gzip 线性扩展、能压 1TB 文件，LLM 则近乎二次方；如果非要类比，LLM 更像 JPEG 和 MP3 而不是 gzip 和 FLAC——你可以在比特流层面狠狠折腾一个 JPEG，另一端仍然看得过去，gzip 远做不到这点。Retr0id 反驳说 gzip 能线性扩展部分原因是窗口只有 32 KiB。montebicyclelo 提醒，历史上人们常常过分夸大 n-gram 这类模型与大型神经网络的相似度；Matumio 则认为理解两者在解决同一个数学问题，总比把 LLM 当成魔法强，”LLM 的目标是文本压缩，这个心智模型没有错，接下来该问的是它期待压缩什么样的文本”。

反过来，LLM 当压缩器表现如何？ 这是 tromp、amelius 等人更感兴趣的问题。magicalhippo 指出 Fabrice Bellard 的 ts_zip 用一个很老的 LLM 就稳稳胜过 xz；gkbrk 提到 Hutter Prize 的头名选手就用了神经网络，computably 补充 Hutter Prize 把解压器大小也计入成绩，大于 1GB 的 LLM 会被直接取消资格，londons_explore 说它还禁用 GPU。eru 纠正了一个常见误解：用 LLM 做确定性压缩靠的是算术编码，而不是”找一个能生成原文的提示词”。

用压缩做分类是个老把戏。 jll29 给出了经典方法：把测试文件分别接在体育、政治、商业语料后面用 gzip -9 压缩，压得最小的就是它的主题，并提到新西兰怀卡托大学 Witten 的团队可能是最早研究这个的。stingraycharles 说二十年前他就用维基百科各语言文章当 gzip 字典做语言检测，”绝对不是最好的方法，但非常快，实现超级简单”。woadwarrior01 点出这就是”归一化压缩距离”（NCD）。myrmidon 挑了个细节：这样做会让参考文本本身的可压缩性污染结果，应该减去参考文件各自的压缩长度。chris_va 回忆几十年前的课程项目用类似的互信息方法检验”培根是莎士比亚作品真正作者”的假说，结论是令人信服地否定了它。basilgohar 顺手开了个玩笑：与其按”词”切分，不如切成更小的子词单元，就叫”量子”吧，再做个”扩展字典模型”……dspillett 解释他是在描述 LLM 的分词。

DonHopkins 引用了 Will Wright 的观点，从反方向描述了同一种联系：压缩即程序化内容生成。 Wright 谈到 demoscene 用 64K 的程序算法化地生成上百兆的 3D 环境、音乐和动画，而 CD-ROM 和廉价硬盘出现后游戏开发者丢掉了这门手艺。DonHopkins 还给出一个前 LLM 时代的小实验：把一大堆 HN 帖子压缩，把压缩文件后半截换成随机数再解压，你会发现在切口之后它还会继续吐出一阵几乎说得通的文本，然后才逐渐滑向胡言乱语。

关于文章本身，也有人不买账。 relevant_stats 认为这篇文章明显是 AI 写的、带着 vibe coding 的审美，”如果作者连写一篇 700 字总结的力气都没有，说明他自己也没那么感兴趣”，并与 elendilm 就”AI 写文档是否等于信号作废”来回辩论了多轮。_def 则说题材有趣，但文章是生成的、而且根本没真用 gzip，这让人感觉怪怪的。rsrsrs86 的评价更刻薄：这类知识本是机器学习/数据科学岗位的常识，如今人们靠和 AI 聊天才重新发现它。

最后是玩笑区：Culonavirus 开场就说”这完美解释了为什么 WinRAR 比 OpenAI 更赚钱”，随后 shezi 真的翻出了 WinRAR 德国公司的公开财报证明它确实盈利，这又引出了一长串 7-Zip、zstd、LZMA 的压缩器之争。modin 则一本正经地引用了”R. Hendricks 等人，《通过优化的中间向外比特流处理实现无损压缩》，Pied Piper 公司技术报告”（美剧《硅谷》梗）。