LLMs are surprisingly great at compressing images and audio, DeepMind researchers find

Comments

• MossyFeathers@pawb.social ⁨1⁩ ⁨year⁩ ago

  Honestly? I’m not super surprised by this. The human brain (and I assume brains in general) are really good at data compression. Considering neural networks are more or less meant to mimic different aspects of the human brain, it doesn’t surprise me too much that they’d be really good at data compression as well.

  source
• akrot@lemmy.world ⁨1⁩ ⁨year⁩ ago

  I wonder how consistent is the decompression and how much information is lost in the process.

  source

  • PupBiru@kbin.social ⁨1⁩ ⁨year⁩ ago

    i’d guess they could hyper optimise for “perceived difference” rather than data loss specifically… they do a pretty good job of generating something from nothing, so i’d say with enough data they’d probably generate a pretty reasonable facsimile of “standard” stuff

    source

    • Edgelord_Of_Tomorrow@lemmy.world ⁨1⁩ ⁨year⁩ ago

      An LLM can’t know what difference a person has perceived.

      source

      • -> View More Comments
  • BetaDoggo_@lemmy.world ⁨1⁩ ⁨year⁩ ago

    It’s lossless: arxiv.org/pdf/2309.10668.pdf

    source
• xodoh74984@lemmy.world ⁨1⁩ ⁨year⁩ ago

  Gavin Belson has entered the chat

  source
• PlexSheep@feddit.de ⁨1⁩ ⁨year⁩ ago

  So like, mp3, gzip and zstd? Why would you use a LLM for compression??

  source

  • rubikcuber@programming.dev ⁨1⁩ ⁨year⁩ ago

    The research specifically looked at lossless algorithms, so gzip

    “For example, the 70-billion parameter Chinchilla model impressively compressed data to 8.3% of its original size, significantly outperforming gzip and LZMA2, which managed 32.3% and 23% respectively.”

    However they do say that it’s not especially practical at the moment, given that gzip is a tiny executable compared to the many gigabytes of the LLM’s dataset.

    source

    • NaibofTabr@infosec.pub ⁨1⁩ ⁨year⁩ ago

      Do you need the dataset to do the compression? Is the trained model not effective on its own?

      source

      • -> View More Comments
    • Aceticon@lemmy.world ⁨1⁩ ⁨year⁩ ago

      Runlength-encoding algorithms (like the ones in GZIP) aren’t especially amazing at compression, they’re more of a balance between speed and compression ability plus they’re meant to compress streams of bytes as the bytes come in.

      There are better algorithms from achieving maximum compression such as substitution ones (were bytes and sets of bytes are replaced by bit sequences, the most common ones getting the shortest bit sequence, the second most common the second shortest one and so on) but they’re significantly slower and need to analyse the entire file to be compressed before compressing it (and the better you want the compression to be, the more complex the analysis and the slower it gets).

      Maybe the LLMs can determine upfront the most common character patterns (I use “patterns” here because it might be something more complex that mere sequences, for example a pattern could be for characters in slots 0, 3 and 4 whilst a sequence would be limited to 0, 1 and 2) and are thus much faster and more thorough at doing the analysis stage or just use it as a pre-analysed frequency model for character patterns in a given language which is superior to general run-length encoding compression (whose frequence “analysis”-ish is done as the bytes in the stream are coming in)

      source