Les grands modèles de langage ont été popularisés par leur utilisation dans des outils comme chatGPT, mais ils peuvent aussi être utilisés pour la compression sans perte. Et ils sont très efficaces, battant même les algorithmes de compression utilisés pour les formats PNG et FLAC.
Une récente étude (mise en ligne sur le serveur de preprint arXiv et pas encore publiée dans une revue scientifique), montre que le modèle de langage Chinchilla 70B (publié en mars 2022 par Deepmind) est plus efficace que les algorithmes de compression de PNG et FLAC. Elle a été réalisée par des chercheurs de DeepMind (la filiale Intelligence artificielle de Google) en collaboration avec un doctorant d'Inria et de Meta.
Les grands modèles de langage permettent de créer des générateurs de baratin particulièrement bluffants tout en soulevant un bon nombre de problèmes.
- Difficile évaluation du coût environnemental et financier de l'utilisation des grands modèles de langage
- Dangers des grands modèles de langage : des chercheuses avaient prévenu
- Les IA génératives tournent mal quand elles sont entraînées sur leurs propres données
Mais les chercheurs ont rapidement compris qu'ils pouvaient aussi être utilisés comme de redoutables outils de compression sans perte comme le format d'image PNG, et contrairement au format JPEG qui compresse les images en perdant des informations au passage.
Théorie de l'information
Dans leur article, les chercheurs de Deep Mind rappellent que, dès 1948, Claude Shannon a décrit, dans sa théorie de l'information (voir ce billet d'Olivier Rioul, pour plus d'explications, et encore plus dans ce cours [PDF] de master d'Antoine Chambert-Loir), l'idée fondamentale pour la compression informatique qu'une information pouvait être compressée sans perte grâce à des modèles probabilistes. Il a aussi théorisé que cette compression, pour une information précise, ne pouvait se faire en deçà d'un nombre minimal de bits (ce qu'il a appelé l'entropie).
Il existe différents modèles probabilistes qui permettent d'appliquer cette théorie pour réaliser de la compression sans perte et se rapprocher au plus près de l'entropie : le codage de Huffman, le codage arithmétique, et, apparus plus récemment, les systèmes numériques asymétriques (en anglais, asymmetric numeral systems, ANS) utilisés dans l'algorithme de compression LZFSE d'Apple ou celui du JPEG XL, par exemple.
Comme les modèles de langage « présentent des capacités prédictives impressionnantes, ils sont bien placés pour être des compresseurs puissants » avec le codage arithmétique, expliquent les auteurs de l'étude. Et ce n'est pas peu dire.
Chinchilla plus efficace que PNG ou FLAC
En créant un modèle de compression basé sur le modèle de langage Chinchilla 70B, les auteurs de l'article ont réussi à effectuer une compression sans perte sur des images issues de la base de données ImageNet à, en moyenne, 43,4 % de leur poids d'origine. En comparaison, le format PNG, pour les mêmes images, les compresse en obtenant des fichiers dont la taille est de 58,5 % celle de l'original.
De même, utilisé sur des fichiers audio provenant de la base de données LibriSpeech, Chinchilla 70B arrive à les compresser à un taux très faible de 16,4 % alors que le format FLAC compresse ces mêmes sons à 30, 3 %. Pourtant, ce modèle a été entraîné, comme la plupart des modèles type (GPT-3, BLOOM, etc), sur des masses de données comprenant essentiellement du texte.
L'efficacité de la « tokenisation » en question
Généralement, les modèles de langage ne sont pas entraînés sur des données brutes, mais sur des versions « tokenisées » de celles-ci. C'est-à-dire que leurs créateurs créent des séries de caractères (les « tokens ») qui permettent de découper un texte et faciliter l'entraînement. Les auteurs de cet article expliquent que cette tokenisation peut être considérée comme une pré-compression.
En théorie, selon eux, cette pré-compression par tokenisation devrait être sans perte. Mais en pratique, ils observent que, quand le modèle est petit, l'augmentation du nombre de tokens augmente les performances de compression. Mais plus le modèle est grand, plus « il semble que ce soit l'inverse qui se produise ».
Bref, il reste encore du chemin avant de faire une version stabilisée de format de compression standardisé qui utiliserait les modèles de langage. Mais le principe d'utiliser les modèles de langage comme outils de compression est validé et devrait avoir de beaux jours devant lui.
Commentaires (29)
#1
Impressionnant …
S’il y a bien un domaine dans lequel j’attendais pas l’IA, c’était bien celle-là.
#1.1
Il me semble que Djvu utilisait déjà un système assez proche en 1998 https://fr.m.wikipedia.org/wiki/DjVu
#2
Du coup, est-ce qu’un jour on aura des RAID IA qui permettent de reconstruire de la donnée à partir de très peu de données ? Ca serait fun
.
#2.1
en fait on peut compresser énormément même sans pertes
je pense que, au moins en partie, l’une des limite de flac et de png, c’est la puissance nécessaire (que ce soit en espace ram ou en nombre de cycles processeur), l’un des buts de ces 2 formats, c’est d’être rapide à décompresser, sur des appareils standards (et déjà datés actuellement).
est-ce qu’en “débridant” les algo de flac et png pour qu’ils fassent le double de cycles (ou le triple, ou 10, ou 100, ou utilisent la même puissance brute que ce qui est utilisé par le modèle de langage) ils seraient vraiment derrière ce qu’à produit Chinchilla 70B ?
c’est peut-être abordé dans la source, mais j’avoue avoir un peu la flemme de vérifier là maintenant tout de suite
#2.2
J’ai le même sentiment. Dommage de ne pas avoir évoqué la puissance de calcul nécessaire pour arriver à ce résultat comparé aux algo FLAC et PNG. Car les algorithmes qui compressent mieux et sans perte que le FLAC et le PNG en utilisant plus de ressource existent déjà.
PNG et FLAC ne sont pas fait pour compresser aux maximum avec les ressources quasi illimitées dont disposent les modèles de langages. Ils sont développés pour être compressé et décompressé “rapidement” sur des machine de puissance modeste.
L’intérêt ici aurait été de comparer le taux de compression à consommation égale de ressource (RAM, processeur…).
#3
Cette analogie “modèle de langage ~ compression” avait déjà été évoquée il y a quelques mois. Je me rappelle notamment avoir un article assez intéressant :
https://www.newyorker.com/tech/annals-of-technology/chatgpt-is-a-blurry-jpeg-of-the-web
#4
Mais est-ce que la taille du dictionnaire est prise en compte ?
#5
Ahah, c’est marrant c’est ce que je me suis dit il y a quelques jours quand j’ai entendu parler de la taille des modèles de langage : les IA de langage seraient en fait un peu un gros dictionnaire/table d’index dans lequel on vient piocher en fonction du prompt.
#6
J’ai dû aller chercher pour ma culture personnelle sur ce besoin de tokeniser notamment via cet article https://www.machinelearningplus.com/nlp/what-is-tokenization-in-natural-language-processing/ mais autrement tout ceci est passionnant merci !
#7
Super article. Merci pour tous les liens. J’ai lu celui d’Olivier Rioul, super intéressant (j’imagine que c’est le b.a. ba pour tout étudiant en informatique ou télécom, mais c’est neuf pour moi). Reste à lire tous les autres…
#8
C’est effectivement un gros, très gros, très très très gros, dictionnaire d’informations où pour chaque mot ou élément de mot, le modèle a retenu des liaisons permettant de prédire la valeur la plus cohérente. C’est justement grâce au fait que les mots soient associés à de nombreuses définitions et étiquettes pour les comprendre que le modèle est capable d’éviter de produire un résultat incohérent qui pourrait être causé par la confusion d’un homonyme qui rendrait la phrase ambiguë (du type “mes fils ont cassé les fils”).
Donc ouais pour le coup, l’utilisation de ces modèles probabilistes est vraiment intéressante pour la compression/décompression d’information.
Après pour les images, les modèles de génération pour celles-ci sont aussi des excellents outils. L’IA sait très bien faire de l’upscale typiquement.
#9
A noter que notre Fabrice Belard national (enfin national pour celles et ceux qui sont en France
) à également travailler sur le sujet : https://bellard.org/nncp/
Il a fait des essais non pas sur des images, mais sur du texte. Les résultats sont aussi impressionnant.
L’inconvénient de ce genre d’approche, c’est que le modèle utilisé pour la compression peut être nécessaire pour la décompression. Ca va déprendre de l’algorithme utilisé !
#10
C’est un domaine bien complexe dans lequel je n’ai aucune connaissance. Mais ce qui importe dans les codecs, c’est - selon le contexte - la mémoire consommée, la vitesse de compression et la vitesse de décompression.
Or là, il faut un LLM en entrée et… en sortie ? Et la compression/décompression prend combien de temps ? PNG et FLAC sont faits pour tourner sur des machines sans trop de ressources, donc la comparaison est délicate.
#11
C’est sûr que ce sera fun quand tout le monde confondra compression et redondance… Je vais de ce pas acheter le popcorn…
#11.1
Tu limites l’espace nécessaire à la redondance en compressant les données qui sont, justement, en redondance, d’où mon commentaire. J’ai fait un raccourci, mille excuses, je pensais que c’était évident.
#11.2
Si cette compression est efficace et performante , tu vas l’utiliser dans ta chaîne d’écriture avant la couche de redondance/intégrité et pas dans la couche de redondance/intégrité.
Et si elle n’est pas performante, tu ne veux certainement pas la mettre dans la couche de redondance/intégrité
#12
Je ne suis pas certain qu’utiliser des jeux de données aussi spécifiques soit opportun.
Il me semble que FLAC peut traiter des sons autres que de la voix.
#13
Je profite du sujet pour demander si l’un(e) d’entre vous connaîtrait des ressources, liens, tutoriels, etc. pour se lancer dans le domaine de l’IA, d’un point de vue programmeur, parce qu’entre les chaînes de Markov, le deep learning, machine learning, réseaux de neurones, etc., il y a de quoi en perdre son latin !
#13.1
Perso je suis passé par le bouquin “Deep Learning from Scratch: Building with Python from First Principles” de Seth Weidman. Et une fois à l’aise avec les concepts mathématiques de ce truc là je me suis mis à suivre diverses ressources traitant de scikit-learn pour élargir au machine learning de manière général.
#14
Du coup, si on compresse d’affilée plusieurs images très similaires, on peut réutiliser ce “dictionnaire”?
#15
Comme je n’ai rien compris au LLM je pose une question conne.
Imaginons que je me serve d’un modèle de langage pour compresser ma musique, est ce que le fait de rajouter des milliers morceaux ne risque pas d’altérer la restitution d’un fichier compressé avant l’ajout de ces morceaux ?
En gros je me dis qu’il aura “appris” d’autres pattern et qu’il implémentera ces évolutions dans la restitution du fichier original en y ajoutant des artefacts.
C’est une connerie ?
#15.1
à priori ça se tient …
mais “à priori” également, il “suffirait” que ce qui a été compressé contienne un marqueur permettant de connaître la “version” des patterns disponibles au moment de la compression pour effectivement ne pas corrompre la décompression en ajoutant des artefacts issus des éléments d’entraînement appris entre la compression et la décompression
#15.2
“Cool ! J’ai économisé 300 ko sur ce morceau de musique en téléchargeant un modèle de 5 Go !”
A priori, le principe serait d’avoir une base stable de modèle pour compresser. Ou, au pire, en ajouter un tag de version spécifique de ce modèle. T’as la même chose dans les compressions classique, type zip/rar, où y’a différentes version des dictionnaires.
Donc non, tu risques pas de perdre tes données.
Après, comme il s’agit d’une mode, dans 20 ans, il y aura probablement plus trace de ces modèles, donc toutes les données seront perdues. Alors que FLAC et ZIP seront encore connu dans 20 ans ;)
#15.3
Merci pour vos réponse, j’y vois un peu plus clair
#16
“énormément même sans perte”, non, seulement si les données ont peu de “désordre” (entropie faible).
La limite est essentiellement liée à l’entropie des données à compresser (ça se calcule). La compression théorique maximale d’un fichier donné peut être approchée de plus en plus près en y mettant plus de moyens, mais souvent des algorithmes comme LZMA en sont proches (effectivement ils sont gourmands en CPU), ou on voit que zstd est de plus en plus efficace avec le niveau de compression - parfois avec palier et parfois petite régression.
Ça m’étonnerait beaucoup. Les algorithmes sont déjà “bons”.
#17
En fait, en utilisant un dictionnaire (ce que permet Zstd par exemple), c’est facile de gagner en compression. Le souci c’est que chacun doit en disposer, pour compresser et pour décompresser (pour décompresser, peut-être seulement une partie, ça dépend de l’algo).
PS : je vois que d’autres ont fait la même remarque.
#18
Le FLAC est fait pour de la musique au départ (la voix en fait partie a priori), et il existe des algorithmes spécifiques pour la voix, comme Speex et Opus (selon les options choisies).
#19
Non, car tu ne vas pas mettre à jour le modèle lors de la compression.
Oui c’est une connerie
(mais c’est gentillet hein ;) )
L’entrainement d’un modèle et l’utilisation d’un modèle sont deux étapes bien distinctes. On peut avoir l’impression que non à cause de l’actualité, où on entend, par exemple, qu’OpenAI met à jour ChatGPT à l’aide des requêtes des utilisateurs, mais le processus derrière est complexe et surtout pas en temps réel.
Ce que fait OpenAI dans ce cas, c’est ceci :
Par contre, là où les choses changes, c’est qu’aujourd’hui, les algorithmes de compression/décompression sont petits d’un point de vue implémentation (quelques ko). Avec des algorithmes à bases de modèles, on peut facilement avoir des algorithmes nécessitant plusieurs Go !
Comme on peut avoir plusieurs modèles, et des versions différents par modèles, il serait possible d’avoir des algorithmes qui ne diffère que par le modèle utilisé. S’il venait à se multiplier, on pourrait se retrouver avec des programmes de compression/décompression qui vont nécessiter de télécharger des Go et des Go de données pour pouvoir décompression un fichier de quelques Mo….
Bref, l’approche peut être intéressante pour du stockage à long terme en interne par exemple (archivage), mais je vois mal ce genre d’algorithme se populariser ailleurs que sur des ordinateurs devant la consommation d’espace et de RAM nécessaire pour les faire tourner…
Au delà de l’espace disque et mémoire nécessaire, il y a aussi le temps nécessaire. Fabrice Bellard, dans cet article, fait un comparatif du débit à la compression. Là où un
gzip -9traite 17400ko/s, les algorithmes à base de réseaux neuronaux atteignent pour la plupart… entre 1 et 3 ko/s ! (il y a un “petit” modèle qui réussi à atteindre quasiment 42ko/s)#20
Honnêtement, je pense qu’on est plus dans la démonstration technique et d’usage qu’autre chose. Pour dire “ils en sont aussi capable” au même titre qu’ils sont très efficaces pour faire de la traduction (vu que c’était une des finalités d’origine de Transformer).
Il y a aussi le risque de corruption de la donnée qui peut être inquiétant, car le LLM invente le contenu donc il n’est pas impossible qu’il dérive. Cela se voit notamment lorsqu’on lui demande de traduire un texte. Il ne se contente pas de le traduire mais il le réécrit dans la langue cible, avec parfois des petits écarts. Ceux-ci ne viennent pas spécialement changer le sens de la phrase, mais ils peuvent être repérés.