将900KB Transformer过拟合，把100MB CSV压缩到7MB

# 将 900KB Transformer 过度拟合，将 100MB CSV 压缩至 7MB 来源：https://news.ycombinator.com/item?id=48644463 https://news.ycombinator.com/vote?id=48682491&how=up&goto=item%3Fid%3D48644463 模型才是关键部分。基于模型的数数据集上，哈夫曼编码、自适应哈夫曼或其他编码器的表现会好得多。解码也需要模型。在数据量足够大的情况下，嵌入模型及其对文件记忆带来的好处可能会被抵消。针对特定数据集的非通用压缩算法（模型——我不是指特定的 LLM，而是“数据建模”）总是优于通用算法。我提到“编码器”并不重要——算术编码在处理输入数据时，每一天都能打败哈夫曼/自适应哈夫曼，但真正的“压缩”功劳在于模型。多年来我实现了不少“编码器”，包括商业和研究用途的算术编码（曾是 Glen Langdon 的学生）。 https://news.ycombinator.com/vote?id=48682109&how=up&goto=item%3Fid%3D48644463 传统方法下这些数据能压缩到多大？做个对比。我很好奇。经典的机器学习集成方法是过度拟合一组小模型，然后进行 bagging（例如投票），让模型具备泛化能力。我猜一定有人尝试过用一堆 Transformer 来做这类压缩，然后进行 bagging，看看效果如何？ https://news.ycombinator.com/vote?id=48682424&how=up&goto=item%3Fid%3D48644463 集成方法在计算或参数效率上并不高，所以压缩本身并不是一个好的应用场景。（这与为什么人们训练越来越大的 LLM，比如一个 10 万亿参数的 LLM，而不是 100 个 GPT-3 规模的 LLM 有关。） https://news.ycombinator.com/vote?id=48682492&how=up&goto=item%3Fid%3D48644463 小白问题：能不能训练一个模型来预测另一个模型的下一个字节？也就是说，将同样的逻辑应用于将更大的模型压缩到更小的模型中。我知道这绝对是个异想天开的想法，但请满足我的好奇心。 https://news.ycombinator.com/vote?id=48682316&how=up&goto=item%3Fid%3D48644463 我有个想法，构建一个类似的编解码器，专门针对特定图像进行过度拟合。但编解码器本身不会是一个固定大小的 Transformer……而是可以调整大小以获得更好的质量/更小的体积。所以编解码器可能像这样：我见过一些实验，人们使用“固定”的流程，但我认为更动态的设计效果会更好。 https://news.ycombinator.com/vote?id=48682201&how=up&goto=item%3Fid%3D48644463 三个问题： 1. 这个项目的文档有多少是由 AI 生成的？ 2. 仓库中没有提供 100MB CSV 数据源，所以似乎无法复现你的结果。enwik9 数据集说是更大数据集的“切片”，也存在多个 NYC 出租车行程记录数据集。能否提供你用来生成结果的数据集？ 3. 我很惊讶性能对比只在你设计的 Transformer 和 WinZIP 之间进行。将你的 Transformer 与更现代的方法（如 LZMA2 级别 9、BZIP2 和 ZPAQ 最大努力）进行对比时，结果如何？ https://news.ycombinator.com/vote?id=48667986&how=up&goto=item%3Fid%3D48644463 很巧妙的方法。由于 900KB 的模型随压缩文件一起发布，是否存在一个文件大小阈值，低于该阈值时模型的开销会吞噬掉增益？好奇转折点在哪里。 https://news.ycombinator.com/vote?id=48670504&how=up&goto=item%3Fid%3D48644463 要让模型开销显著到蚕食增益，文件大小需要相当小，对吧？我假设没人会用这个来压缩小于 100MB 的文件。我用 100MB 的文件测试，因为更大的文件评估时间太长。实际目标至少是 1GB，这种情况下我会使用 100MB 的模型（香农熵规则）。我还在一份 100MB 的 Photoshop 文件上测试过，能压缩到 45MB，而 ZIP 只能压到 60MB。所以增益并没有丢失。 https://news.ycombinator.com/vote?id=48646720&how=up&goto=item%3Fid%3D48644463 我在 enwik9 的 100MB 切片上试过，能压缩到 20MB + 900KB Transformer = 21MB。我知道最佳提交结果可以压到 13MB。还在尝试一些想法以获得更好的压缩率。 https://news.ycombinator.com/vote?id=48682164&how=up&goto=item%3Fid%3D48644463 既然你预先知道文件大小，也许可以改用某种文本扩散模型来过度拟合，而不是 Transformer？或许能用其他方法部分校正模型输出，然后填补之前生成错误留下的空白。 https://news.ycombinator.com/vote?id=48682092&how=up&goto=item%3Fid%3D48644463 也许大家都应该压缩圆周率的前 100MB 数字，这样才容易进行公平对比？呃，等等，这太简单了。需要生成/发布随机数字，这样每个人都能用。 https://news.ycombinator.com/vote?id=48682142&how=up&goto=item%3Fid%3D48644463 但随机数字是可压缩的。随机数据并不意味着它与你的字典中的模式不匹配，例如。 https://news.ycombinator.com/vote?id=48657421&how=up&goto=item%3Fid%3D48644463 太棒了！我也想尝试类似的东西。我一直在疯狂搞压缩工作。我觉得我能超过那个奖金链接。 https://news.ycombinator.com/vote?id=48670445&how=up&goto=item%3Fid%3D48644463 真的吗？那你有发表过什么成果吗？我能读读吗？听起来你有一些有趣的想法。 https://news.ycombinator.com/vote?id=48677700&how=up&goto=item%3Fid%3D48644463 我很快就会在 Hacker News 上展示一些东西！基本上我找到了一种将多人游戏状态从 ~100KB+ “压缩”到 ~1KB 的方法。但这只适用于我正在开发的游戏，而且不是纯粹的压缩工作，我不得不做一些巧妙的事情。 https://news.ycombinator.com/vote?id=48679379&how=up&goto=item%3Fid%3D48644463 作为对比，我最好的压缩方法能做到几十 KB，但真正的突破是达到了 ~1KB 的数值。注意这些数字都是压缩后的。这不是原始数据与压缩数据的对比。~100KB 这个数字也是压缩后的。背景是：这是一个基于网格的游戏，玩家每秒可以执行 4 个动作，我分享的数据是 30 分钟的游戏过程，同时有 2 到 1024+ 个玩家（真人玩家）参与。所以如果你计算一下，我的压缩成果相对于朴素的最佳情况，实际达到了约 99% 的压缩率。而如果与原始数据相比，这个数字还要更高。我还没算原始数据的大小，原始数据比 ~100KB 还要大一个数量级，所以相对于原始数据的“压缩率”接近 99.9%。我知道听起来完全像是胡扯 :D 但我会在游戏发布后很快写一篇博客文章。我给“压缩”加引号，是因为这不是纯粹的压缩成就，这 99%+ 的成果实际上是巧妙利用了哪些才是真正需要压缩才能达到相同结果的东西。 https://news.ycombinator.com/vote?id=48682143&how=up&goto=item%3Fid%3D48644463 之前我在做一个多人游戏，其中一个网络代码迭代是“瘦客户端”，客户端只发送输入，服务器模拟游戏，并以 60Hz 的频率将世界状态推送到管道。我没有发布那个版本，但我估计那种方法会产生 3000 美元的带宽费用！我开始研究状态差异、压缩等方法……直到我意识到，等一下！我的玩家移动是线性的，所以我只需要在启动和停止时发送数据包！于是我的效率实现了近乎无限提升 :) 我想这个词是……专用解决方案可以打败通用方案。另外，“记住程序真正需要做什么，然后让程序只做那件事”……我优化了网络代码：https://youtube.com/watch?v=pgoetgxecw8 https://news.ycombinator.com/vote?id=48682093&how=up&goto=item%3Fid%3D48644463 可能不行吧，这非常特定于 PvP 多人游戏，只在我的游戏上测试过。不过也许我能提取核心概念应用于 enwiki9，但我怀疑。