让 gzip 当语言模型？压得最小的地方，就是它“觉得”最像原文的地方

frost697

Nathan Barry 提出了一个脑洞实验：能不能让 gzip 当语言模型？不要神经网络、不要训练参数，就用你操作系统里那个现成的压缩器——拿语料喂进它的滑动窗口，给个正常提示词，让它在"怎么压最省"的驱动下继续往下生成。结果真的能出字符，虽然远谈不上通顺，但它确实"知道"语料里的一些东西，比作者预期的多得多。

理论根基是那篇《Language Modeling is Compression》讲的压缩-预测等价：每个预测模型本质上是压缩器，而所有压缩算法本质上都是预测模型。信息论的核心——一个符号编码需要的比特数等于 -log2(p)，p 是模型给它的概率——意味着任何压缩器内部都藏着一个概率模型，不管有没有人把它写出来。

1. 
   
2. gzipt --corpus data/tinyshakespeare.txt --prompt $'MENENIUS:\n' --length 200

复制代码

1. 
   
2. MENENIUS:
   
3. 'Though all at once canq
   
4. 
   
5. MARCIUS:
   
6. Pray now, nocamest thou to a morsel .
   
7. 
   
8. LARTIUS:
   
9. Hence, and
   
10. I' the end admire, where G
    
11. again; and after it ag .

复制代码

gzip 用的是 DEFLATE，它压缩下几个字节的方式是在 32 KiB 的滑动窗口里找最近的匹配。如果生成的续写呼应了窗口里的文本，DEFLATE 就会用便宜的回指编码而不是逐个字节，于是压得极小。这就给出一个打分方法：想判断某段候选续写好不好，就看 len(gzip(上下文+候选))，压得越小说明越"被预测"。把语料塞进窗口当"先验"，像语料的续写就压得小，不像的就压得大。

但真正生成没那么简单。最朴素的"选压得最省的下一个字节"会翻车，因为 gzip 只给整数的字节长度——加上一个字节经常根本不影响压缩长度，一堆候选并列，信号被量化噪声淹没了。作者的解法是往前看一段整的再做决定：gzipt 跑的是束搜索，每一步尝试语料中出现过的每个字节，把所有候选按压缩长度打分并剪枝，保留最省的那一束，推进一个 horizon 后再提交。

有个细节特别关键：得分时只有生成的最近一小段尾字节留在上下文里。因为 DEFLATE 对近处的匹配编码得更便宜，如果让 gzip 看到全部历史，它最容易滑进逐字复读——不停拷贝自己刚生成的内容。限制成像窗口那样只留尾部，才逼着它去"接话"而非"复读"。

整件事就是一个纯标准库 Python 文件（只用 zlib），代码在 GitHub 上。论文里也试过这条路但效果差，作者认为束搜索把生成质量显著拉高了一截。这个实验的启示不是"gzip 能干翻大模型"——它显然不能——而是把"压缩即预测"从理论变成能玩的东西：最朴素的压缩器，配上一行束搜索，就能自己"写"出有语感的文本。对理解压缩和预测为什么是一体两面，这比任何抽象论述都直观。

来源：

• Can gzip be a language model? - Nathan Barry

原文链接

nova630

看完顺手回一个，内容确实有料。

golden_turbo

看完受益，已转给同事，让他们也看看gzip这块。

code816

坐等更新，当语言模型系列要是能写下去就更好了。

raven_flux_77

已阅，受益匪浅，楼主加油更新。

code389

有一说一，现在肯把当语言模型讲这么细的人不多了。

zen689

整件事就是一个纯标准库 Python 文件（只用 zlib），代码在 GitHub 上。

这段深有同感，当语言模型确实是这样。