Dateikomprimierung: KI schlägt ZIP-Programme - bis zu einem bestimmten Punkt
Ersetzt Künstliche Intelligenz bald die klassischen Packprogramme wie WinRAR und 7-Zip? Ein Forschungspapier will den Beleg dafür liefern, dass LLMs durchaus eine echte Alternative darstellen können - allerdings nur bis zu einem gewissen Grad.
Wer Dateien oder ganze Ordner komprimieren und so etwas Speicherplatz einsparen will, greift in der Regel auf eine der herkömmlichen Softwarelösungen wie WinRAR oder 7-Zip zurück. Beide Tools gelten als beliebte Lösungen, wenn es um das Archivieren und Entpacken von ZIP- und RAR-Dateien geht - doch für lange noch? Denn wenn es nach einem Forschungsteam von Google DeepMind geht, ist auch in diesem Anwendungsbereich eine Künstliche Intelligenz die Zukunft.
Hierfür haben die Forscher das Chinchilla 70B LLM (Large Language Model) trainiert, um einen möglichst effektive Kompressionsalgorithmus zu entwickeln. Das Ergebnis kann sich sehen lassen: Dem Forschungspapier zufolge wurden Bilder auf etwa 43,4 Prozent sowie Audiodateien auf 16,4 Prozent ihrer ursprünglichen Dateigröße reduziert. Im Vergleich dazu können standardmäßige PNG-Kompressionsalgorithmen "nur" auf 58,5 Prozent reduzieren, FLAC-Komprimierer landen hier auf etwa 30,3 Prozent der ursprünglichen Dateigröße.
Wie die DeepMind-Forscher weiter ausführen, wurde Chinchilla 70B hauptsächlich auf reinen Text trainiert. Dennoch sei das KI-Modell "aufgrund der Vorhersagefähigkeiten von LLMs gut positioniert, um ein starker Kompressor zu sein". Entsprechend würden sich solche LLMs auch grundsätzlich dafür eignen, große Dateien zu komprimieren.
Einen Haken gibt es allerdings zu berücksichtigen, wie auch im Forschungspapier erläutert wird. Künstliche Intelligenz wie das Chinchilla 70B LLM sei (noch) bei Weitem nicht so skalierbar wie die eingangs erwähnten herkömmlichen Tools zum Komprimieren. Wird ein bestimmter Schwellenwert - der in der Untersuchung nicht konkretisiert wird - überschritten, hat das LLM noch Probleme, ähnliche Komprimierungsraten wie 7-Zip und Konsorten zu erreichen. Auch die Geschwindigkeit könne in solchen Szenarien noch nicht mithalten.
.gif)
Mit 64Bit bist du im Exabytebereich wenn du jedes einzelne Byte adressieren willst.
Und auch für den Dateinamen ist Platz genug im Wörterbuch
Um den Unterschied zu verdeutlichen:
2 Byte haben zwei Adressen. Für die Addressierung reicht "0 = erstes Byte", "1 = zweites Byte", also ein einziges Bit.
Sie enthalten aber je 8 Bit, die man je Byte auf 2^8 = 256 verschiedenen Wegen kombinieren kann. Und für die Kombination aus beiden beiden Bytes ist man schon bei 256 × 256 = 2^16 Möglichkeiten:
00000000 00000000
00000000 00000001
00000000 00000010
00000000 00000011
00000000 00000100
00000000 00000101
00000000 00000110
00000000 00000111
...
11111111 11111100
11111111 11111101
11111111 11111110
11111111 11111111
Um in deinem "alle Dateien der Welt"-Wörterbuch die richtige Kombination nachzuschlagen, musst du also bereits 65.536 verschiedene Namen an 2-Byte-Dateien vergeben können, also einen 16-Bit-Code für den Index einen Systems mit 1-Bit-Speicherzellenadressierung verwenden. Für alle 8-Byte-Dateien wären es 64 Bit, wohin gegen 8 Speicherzellen gerade einmal 3 Bit zur Adressierung brauchen. Und-so-exponentiell-weiter – jeweils genauso viele Index-Bits, wie die Dateien selbst Bits enthalten, denn genau daraus ergibt sich die mögliche Vielfalt. Ein alle Kombinationsmöglichkeiten abdeckender Index ist immer genauso groß, wie das was indiziert wird.
Erst wenn man einen unvollständigen Code hat, also die vorkommenden "Wörter" nicht alle denkbaren Buchstabenkombinationen enthalten spart man Platz. So gibt es zum beispiel 27^2 = 729 Möglichkeiten, zwei Buchstaben zu kombinieren. Aber es gibt nicht 729 Wörter mit zwei Buchstaben in der deutschen Sprache. (Sondern ... keine Ahnung? Schätze mal ein Dutzend.) Also bräuchte man da einen Index mit viel weniger als 27^2 Kombinationen, um alles abzudecken, und dieser Index ließe sich tatsächlich platzsparender speichern als die Wörter selbst.
Dann machen wirs mal konkret. Man nehme folgenden Text, der in der Datei "Datei123.txt" drinsteht:
"PCGHX ist ein ganz tolles Forum mit vielen netten Leuten".
Du kannst ein beliebig großes Wörterbuch benutzen.
Bitte erstelle eine Datei die maximal 64bit (=8 Bytes) groß ist, die alle diese Informationen enthält.
Selbst wenn du ein sehr gutes angepasstes Wörterbuch hättest das alle Wörter enthält (und auch NUR die und keine anderen dass der Verweis mit 1 Byte eineindeutig ist):
PCGHX =A
ist=A
ein=B
ganz=C
tolles=D
Forum=E
mit=F
vielen=G
netten=H
Leuten=I
Datei123=J
wäre deine zu speichernde Datei immer noch J 80 bit groß.
Mit einem gesamt Speicherbedarf von 40 Bit, verglichen mit 65-ASCII-Zeichen zu insgesamt 520 Bit, ist das aber ein gutes Beispiel dafür, wie Komprimierung funktioniert.
Höre ich zum ersten mal was von...
Ein solches Wörterbuch ist prinzipiell identisch mit einem theoretischen Fileserver, der mindestens alle Dateien der Menschheit enthält (um zumindest das alle überhaupt möglichen Dateien rauszunehmen).
Selbst dann müsstest du aber für die Fantastilliarden an Dateien noch eineindeutige "Pfade" speichern, die dann eben in den KB-Bereich gingen da solche Pfade eher... länglich würden.
Es ist unbestritten dass riesige Wörterbücher extreme Kompressionsraten erlauben würden, nur deine 64bit sind halt Unsinn. Das reicht selbst dann nicht, wenn du nur den Pfad speichern willst wo die Datei 1:1 zu finden ist.