Technology

I tried reading the paper. There is a free preprint version on arxiv. This page (from the article linked by OP) also links the code they used and the data they tried compressing, in the end.

While most of the theory is above my head, the basic intuition is that compression improves if you have some level of "understanding" or higher-level context of the data you are compressing. And LLMs are generally better at doing that than numeric algorithms.

As an example if you recognize a sequence of letters as the first chapter of the book Moby-Dick you'll probably transmit that information more efficiently than a compression algorithm. "The first chapter of Moby-Dick"; there .. I just did it.

This is not new knowledge and predates the current LLM fad.

See the Hutter prize which has had “machine learning” based compressors leading the ranking for some time: http://prize.hutter1.net/

It’s important to note when applied to compressors, the model does produce a code (aka encoding) that exactly reproduces the input. But on a different input the same model is unlikely to produce an impressive compression.

Where I work, we've been looking into data compression that's optimized by an ML system. We have a shit-ton of parameters, and the ML algorithm compares the number of sig figs in each parameter to its byte size, and truncates where that doesn't cause any loss of fidelity. So far, it looks promising, really good compression factor, but we still need to do more work on de-skilling the decompression at the receiving end.

I wouldn't have thought LLM was the right technology to use for something like this.

Middle-LLM compression

Can’t wait to find hallucinated data in your uncompressed files.

The basic idea behind the researchers' data compression algorithm is that if an LLM knows what a user will be writing, it does not need to transmit any data, but can simply generate what the user wants them to transmit on the other end

Great... but if that’s the case, maybe we should reconsider the usefulness of transmitting that data in the first place.

This is just a more complex version of shared dictionary compression which I think one of the web compression algorithms does. Stupid LLM fuckers at it again with dumb garbage.

I found the article to be rather confusing.

One thing to point out is that the video codec used in this research (but for which results weren't published for some reason), H264, is not at all state of the art.

H265 is far newer and they are already working on H266. There are also other much higher quality codecs such as AV1. For what it's worth, they do reference H265, but I don't have access to the source research paper, so it's difficult to say what they are comparing against.

The performance relative to FLAC is interesting though.

So if I have two machines running the same local LLM and I pass a prompt between them, I've achieved data compression by transmitting the prompt rather than the LLM's expected response to the prompt? That's what I'm understanding from the article.

Neat idea, but what if you want to transmit some information that an LLM can't tokenize and generate accurately?

If this really is lossless, it is incredible. I'm skeptical until I see it in action though.

Ok so the article is very vague about what's actually done. But as I understand it the "understood content" is transmitted and the original data reconstructed from that.

If that's the case I'm highly skeptical about the "losslessness" or that the output is exactly the input.

But there are more things to consider like de-/compression speed and compatibility. I would guess it's pretty hard to reconstruct data with a different LLM or even a newer version of the same one, so you have to make sure you decompress your data some years later with a compatible LLM.

And when it comes to speed I doubt it's nearly as fast as using zlib (which is neither the fastest nor the best compressing...).

And all that for a high risk of bricked data.