- Byte Latent Transformer (BLT) est une architecture de LLM au niveau des octets qui s'entraîne sur des octets bruts sans tokenisation à vocabulaire fixe, tout en atteignant à grande échelle des performances comparables à celles des LLM basés sur la tokenisation
- Le point clé consiste à regrouper les octets non pas en tokens fixes mais en patches de taille dynamique, puis à allouer davantage de calcul et de capacité du modèle aux positions où l'entropie de l'octet suivant est élevée
- Meta a mené une étude de scaling contrôlée en FLOP jusqu'à 8B de paramètres et 4T d'octets d'entraînement, validant l'extensibilité des modèles au niveau des octets
- Plus les données sont prévisibles, plus le modèle choisit des patches longs afin d'améliorer l'efficacité d'entraînement et d'inférence, avec aussi des améliorations qualitatives en raisonnement et en généralisation long tail
- À coût d'inférence fixe, l'approche BLT qui augmente à la fois la taille des patches et celle du modèle montre un meilleur scaling que les modèles basés sur la tokenisation
La structure de LLM au niveau des octets proposée par BLT
- Byte Latent Transformer (BLT) est une architecture de LLM au niveau des octets qui utilise des octets bruts comme unité d'entrée au lieu d'une tokenisation fondée sur un vocabulaire fixe
- Dans des configurations à grande échelle, il atteint des performances comparables à celles des LLM basés sur la tokenisation, tout en montrant des gains notables en efficacité d'inférence et en robustesse
Les patches dynamiques deviennent l'unité de calcul
- BLT encode les octets en patches de taille dynamique et utilise ces patches comme principale unité de calcul
- Le découpage en patches se fait dynamiquement selon l'entropie de l'octet suivant
- Davantage de calcul et de capacité du modèle sont alloués aux points où la complexité des données augmente
- Lorsque les données sont prévisibles, des patches longs sont choisis afin de réduire le calcul
Expériences de scaling contrôlées en FLOP
- Meta a mené une étude de scaling contrôlée en FLOP sur des modèles au niveau des octets
- L'échelle expérimentale va jusqu'à 8B de paramètres et 4T d'octets d'entraînement
- Les résultats montrent que des modèles entraînés sur des octets bruts sans vocabulaire fixe peuvent eux aussi passer à l'échelle
Résultats sur l'efficacité et la généralisation
- Le choix dynamique de patches longs améliore à la fois l'efficacité d'entraînement et l'efficacité d'inférence
- Les résultats qualitatifs montrent des améliorations en raisonnement et en généralisation long tail
- À coût d'inférence fixe, BLT montre un meilleur scaling que les modèles basés sur la tokenisation
- Cela repose sur une approche qui augmente simultanément la taille des patches et celle du modèle
Ressources
- Download the Paper : téléchargement de l'article Byte Latent Transformer
1 commentaires
Commentaires sur Hacker News
Article : https://scontent-sjc3-1.xx.fbcdn.net/v/t39.2365-6/470135129_...
Je travaillais dans une startup qui faisait de la classification avec un modèle CNN à base de caractères l’été où BERT est sorti
Dans l’équipe, on réfléchissait beaucoup aux représentations alternatives ; les autres préféraient les vecteurs de mots, mais moi pas vraiment. Dans les documents qu’on traitait, il y avait souvent des mots hors vocabulaire, ils étaient importants, et les ignorer aurait sans doute mené à l’échec
Comme nous construisions aussi un « modèle de base », le problème n’était pas seulement que le modèle final rencontre des mots hors vocabulaire, mais aussi que cela arrive dès l’étape du modèle de base, où le coût d’entraînement est encore plus élevé
La classification avec des modèles à base de caractères marchait plutôt bien, mais comme on considérait que stocker un « dictionnaire » dans le réseau de neurones n’était pas une bonne manière d’utiliser un réseau de neurones, il y avait beaucoup d’attentes autour des tokens
D’un autre côté, j’étais tellement convaincu que des approches comme Word2Vec étaient sans avenir que j’avais même quitté un projet précédent où l’on entraînait un RNN à rédiger de faux résumés de cas cliniques PubMed pour créer un modèle de base de compréhension du texte
Quand le byte-pair encoding est apparu, je me souviens avoir dit en réunion que c’était la première méthode de tokenisation parmi celles qu’on avait examinées que je pouvais vraiment soutenir
Malgré tout, je continue à penser qu’il serait préférable de pouvoir travailler directement au niveau des caractères
Les tokens sont un pis-aller. En général, ça fonctionne bien, mais quand ça échoue, ça se voit clairement
[1] https://arxiv.org/abs/2103.06874
Dans le monde réel, les gens inventent et utilisent chaque jour des mots absents du dictionnaire pour communiquer. Par exemple, « notify » est dans le dictionnaire, mais « notifier », au sens de « moyen d’avertir quelqu’un », ne l’est pas, et le code qui envoie des notifications par e-mail devient un « email notifier ». Ensuite, on enchaîne avec des notifier pour SMS, appels vocaux, rappels de centre d’appels, etc.
Chaque secteur et chaque organisation ont leur jargon, des mots personnalisés absents du dictionnaire et des acronymes peu distinctifs
Si un système de machine learning ne sait pas gérer la communication du monde réel et ne peut produire que des réponses dans le dictionnaire soigneusement épurées comme en laboratoire, je ne vois pas bien comment sa sortie pourrait être utile
J’espère que ça marchera. Les tokenizers doivent disparaître
Ce qui est intéressant, c’est que c’est une hiérarchie dont il n’y a que deux niveaux. Empiler davantage de niveaux semble être une direction naturelle pour les travaux futurs
À noter : j’ai aussi laissé ce commentaire sur un autre post lié[1], et l’auteur a répondu ceci
« Je suis l’auteur :), je pense que c’est une bonne piste à explorer ! Mais au-delà du fait que ça fait beaucoup de travail d’un coup, il faut aussi faire attention à la manière de répartir le budget de FLOP sur l’ensemble de la hiérarchie. Avec deux niveaux, on peut rendre un niveau (octets/encodeur local) efficace en FLOP, et l’autre (patchs/encodeur global) gourmand en FLOP. Il faut aussi trouver un moyen de regrouper les patchs en unités plus grandes. Cela dit, il y a beaucoup de directions possibles à partir d’ici ! »
[1] https://news.ycombinator.com/item?id=42413430
Pour créer les patchs, ils utilisent un petit modèle pour prédire la probabilité du caractère suivant dans la chaîne d’entrée
Si la chaîne d’entrée est « Lazy dog jumped over a fence. », le modèle prédit la probabilité de chaque caractère
Par exemple, il peut être sûr à 100 % que le prochain caractère est « a », ou bien donner 10 % pour « a » et 10 % pour « b »
Ensuite, ils regroupent ces estimations de caractères. Le nombre de caractères regroupés est choisi de sorte que l’incertitude totale de chaque groupe, c’est-à-dire l’entropie, soit similaire
Cela forme alors un patch, ou « token »
Elle n’utilise que l’entropie de l’octet suivant, et vérifie si elle dépasse un seuil (contrainte globale) ou si elle est supérieure à celle de l’octet précédent d’un autre seuil (contrainte de monotonie approchée)
Du coup, comme montré dans l’annexe E, des séquences longues et répétitives peuvent conduire à des patchs pathologiquement longs
Ce qui m’intrigue vraiment, c’est le petit modèle CNN au niveau des octets utilisant un contexte de 2 octets dans la figure 3(f), qui n’est mentionné nulle part ailleurs dans l’article
Article connexe récent :
Meta FAIR partage de nouvelles recherches, modèles et jeux de données - https://news.ycombinator.com/item?id=42412360 - décembre 2024, 61 commentaires
Est-ce que cela signifie que la seule chose qui enseigne quelque chose au modèle, c’est-à-dire la loss, se réduit à une prédiction de probabilité dans un espace d’octets unique ?
Si je ne me trompe pas, cela voudrait dire que cela suffit à lui seul, et ça semble assez prometteur
Si j’ai bien compris, cette approche ne supprime pas seulement la tokenisation, mais aussi le sampling, non ?
Le sampling peut être une vraie plaie pour les LLM, mais il permet aussi des usages intéressants, comme forcer une grammaire pour que le modèle produise toujours un JSON valide, ajuster la température pour obtenir des distributions plus variées, ou utiliser le sampling XTC
Quel serait l’équivalent dans BLT ?
La seule méthode qui me vient à l’esprit serait de fournir au décodeur des octets autorisés/interdits en entrée supplémentaire, puis de répéter le décodage jusqu’à obtenir une sortie valide, mais il existe peut-être une approche plus simple et plus évidente
Comme avec un modèle basé sur BPE, il suffit de calculer le softmax dans la couche de sortie uniquement sur les octets autorisés, puis d’échantillonner à partir de là
Est-ce que cela veut dire que l’IA pourrait aussi être préentraînée sur du binaire ?
On pense que l’aboutissement sera que l’IA écrive le code à notre place, mais elle pourrait peut-être nous dépasser d’une manière bien plus simple
Il est intéressant de voir à quel point les approches linguistiques et fondées sur l’expérience sont passées de mode
Les humains, même si c’est possible, ne lisent généralement pas caractère par caractère. Ils ont des racines lexicales et comprennent aussi les flexions. La tokenisation ne reproduit pas cela, et quand on regarde les tokens présents dans le vocabulaire des LLM, c’est particulièrement visible ; il en va de même pour l’encodage par caractères ou par octets
Les humains ont plusieurs façons de parser les mots. On peut comprendre toute une phrase d’un coup, lire par groupes syntaxiques, lire mot par mot, ou encore déchiffrer un mot nouveau lettre par lettre en le prononçant
Très peu d’articles affirment explicitement qu’une méthode est bonne parce qu’elle reproduit la manière dont les humains accomplissent des tâches ou perçoivent le monde
Plus notre dépendance aux LLM augmentera, plus j’aurai envie que les modèles se rapprochent de notre expérience. Je pense alors que les erreurs qu’ils produisent seront aussi plus faciles à comprendre
La phrase « contrairement à la tokenisation, BLT n’a pas de vocabulaire fixe pour les patchs » signifie, si j’ai bien compris, que le vocabulaire des patchs n’est pas connu avant l’entraînement
Une fois que l’entraînement aura établi ce vocabulaire des patchs, l’inférence utilisera vraisemblablement le même vocabulaire fixe. Sinon, je ne vois pas comment cela pourrait fonctionner
C’est bien ça ?