Il y a un moment, j'ai écrit sur la modélisation du langage sans réseaux de neurones, où j'ai généré du Shakespeare avec un modèle n-gram non borné : pas de poids, pas d'entraînement, juste du comptage. Heureusement, je suis tombé sur l'article 'Language Modeling is Compression', qui mentionnait l'équivalence compression-prédiction : chaque modèle de prédiction est intrinsèquement un compresseur, et tous les algorithmes de compression sont des modèles de prédiction. Cela a naturellement conduit à la question : gzip peut-il faire de la modélisation du langage ? Aucun réseau de neurones, aucun paramètre appris, rien. Juste le compresseur fourni avec votre système d'exploitation. Vous l'amorcez avec un corpus, vous lui donnez un prompt de texte normal, et il poursuit ce prompt en recherchant les séquences d'octets qui se compressent le mieux. Voici une sortie réelle et non éditée après l'avoir amorcé sur tiny Shakespeare :

gzipt --corpus data/tinyshakespeare.txt --prompt $'MENENIUS:\n' --length 200

MENENIUS:'Though all at once canq MARCIUS: Pray now, nocamest thou to a morsel .LARTIUS: Hence, and I' the end admire, where Gagain; and after it ag .Il s'avère, d'une certaine manière ? Ce n'est pas exactement un texte cohérent, mais il connaît clairement quelque chose sur le texte. Bien plus que ce que j'attendais de gzip.

Alors, comment un compresseur peut-il générer cela ? La compression, c'est la prédiction. Pensez à ce que fait un compresseur. Il dépense peu d'octets sur les données qu'il 'attend' et beaucoup d'octets sur les données qu'il ne prévoit pas. Si je vous donne un fichier constitué de la lettre A répétée un million de fois, vous pouvez le décrire en une phrase. Un million d'octets aléatoires, en revanche, n'ont aucune structure à exploiter et ne se compressent presque pas. Ce n'est pas une coïncidence ; c'est le cœur de la théorie de l'information. Le nombre de bits nécessaires pour encoder un symbole est $-\log_2 p$, où $p$ est la probabilité que le modèle lui attribue. Une probabilité élevée signifie peu de bits. Donc tout compresseur possède intrinsèquement un modèle de probabilité caché en lui, que quelqu'un l'ait écrit ou non. gzip utilise DEFLATE, qui compresse les octets suivants en trouvant des correspondances par rapport au texte récent dans une fenêtre glissante de 32 KiB. Si une continuation fait écho à quelque chose déjà présent dans la fenêtre, DEFLATE l'encode comme une référence arrière bon marché au lieu d'octets littéraux. Ainsi : une continuation que gzip 'attendait', parce qu'elle fait écho à du texte déjà présent dans sa fenêtre, se compresse presque à rien. Cela nous donne un score. Si j'ai un certain contexte et que je veux savoir quelle est la qualité d'une continuation candidate, je mesure simplement : score(candidat) = len(gzip(contexte + candidat)). Plus la longueur compressée est petite, plus le candidat est 'prédit'. Pour amorcer le modèle, j'inclus un corpus dans la fenêtre de gzip. Toute continuation ressemblant au corpus se compresse petitement, et toute continuation ne ressemblant pas au corpus se compresse largement. Génération par recherche en faisceau. Le scoring est une chose ; la génération en est une autre. L'approche naïve consistant à choisir l'octet suivant unique qui compresse le mieux échoue lamentablement, et pour une raison subtile : gzip ne donne qu'une longueur en octets entière (pas de fractions). Ajouter un octet ne change souvent pas du tout la longueur compressée, donc de nombreux candidats font égalité et le signal se perd dans le bruit de quantification. La solution consiste à regarder un tronçon complet avant de s'engager. gzipt effectue une recherche en faisceau sur des séquences d'octets. À chaque étape, le contexte actuel est : fenêtre du corpus + récente fin de (prompt + octets générés). Ensuite, gzipt essaie des octets suivants possibles. Chaque continuation candidate est notée en compressant contexte + candidat et en vérifiant combien d'octets occupe le résultat compressé. La boucle est :

Prompt. Commencez avec le prompt de l'utilisateur comme texte initial à poursuivre. Il n'y a pas de jeton de départ ; les octets du prompt font simplement partie du contexte que gzip voit.

Contexte. Montrez à gzip la fenêtre du corpus plus la récente fin du prompt/texte généré.

Recherche. Gardez les beam_width partielles continuités les plus compressibles. Étendez chacune avec chaque octet qui apparaît dans le corpus, notez toutes par longueur compressée, puis réduisez à nouveau aux meilleures beam_width.

Répétez pour horizon octets.

Engagement. Prenez la continuation complète la plus compressible (ou échantillonnez parmi les finalistes si la température est positive), ajoutez-la, et continuez.

...

FAQ Q : gzip peut-il être utilisé comme modèle de langage ?

FAQ A : Oui, gzip peut fonctionner comme modèle de langage grâce à la prédiction basée sur la compression. En l'amorçant avec un corpus et en utilisant la recherche en faisceau pour trouver les séquences d'octets qui se compressent le plus efficacement, gzip identifie effectivement des modèles et génère des prolongements de texte. Cela fonctionne parce que les algorithmes de compression construisent intrinsèquement des modèles de probabilité : lorsque le texte fait écho à des motifs précédemment vus, il se compresse plus efficacement, indiquant une prévisibilité plus élevée.