Technique de détection automatique des tokens sous-entraînés dans les grands modèles de langage

• Dans les LLM, la création du tokenizer et l’entraînement du modèle sont séparés, ce qui peut amener certains tokens comme _SolidGoldMagikarp à provoquer des comportements inattendus
• Le cœur du problème réside dans les tokens sous-entraînés présents dans le vocabulaire du tokenizer, mais vus très rarement, voire jamais, pendant l’entraînement ; on les appelle souvent « glitch tokens »
• L’étude propose une méthode pour détecter automatiquement ces tokens en combinant analyse du tokenizer, métriques sur les poids des embeddings du modèle et techniques de prompting
• Ces tokens gaspillent de la capacité de vocabulaire dans les tokenizers de taille fixe et peuvent affecter la longueur des entrées/sorties, le coût d’inférence, les hallucinations ou les sorties corrompues
• Dans les environnements utilisant des outils et des agents qui recherchent et traitent des données externes, la détection et le nettoyage des tokens sous-entraînés sont directement liés à la sécurité et à la robustesse des modèles déployés

---

Décalage entre tokenizer et entraînement du modèle

• La plupart des composants des LLM sont entraînés de manière non supervisée sur de grands volumes de données, mais le tokenizer est généralement entraîné séparément, avec un algorithme distinct et un jeu de données plus petit
• GPT-2 a posé de nombreuses bases de la modélisation du langage moderne fondée sur les Transformers, et son framework de tokenisation basé sur le byte-pair encoding (BPE) a aussi été largement adopté
• La tokenisation BPE transforme le texte d’entrée en séquence de tokens de sous-mots, en fusionnant de manière répétée deux tokens adjacents selon des règles de fusion fixes
• Les règles de fusion sont apprises par un algorithme glouton sur un jeu de données plus petit, qui doit être représentatif des données d’entraînement du LLM

Structure d’apparition des glitch tokens

• Lorsque le tokenizer et l’entraînement du modèle sont séparés, certains tokens peuvent n’apparaître que très rarement, voire jamais, pendant l’entraînement du modèle
• Si de tels tokens sont inclus dans l’entrée, ils peuvent provoquer des comportements inattendus, comme des hallucinations ou des sorties corrompues
• L’étude distingue ces tokens comme des tokens sous-entraînés ou tokens non entraînés
  • untrained n’est utilisé que lorsqu’il existe un indice clair qu’un token donné n’est pas apparu dans les données d’entraînement du modèle
  • En général, ils sont aussi appelés « glitch tokens »
• Le token _SolidGoldMagikarp est cité comme exemple emblématique

Limites des méthodes de tokenisation existantes et alternatives

• Des travaux récents ont aussi étudié la suppression de la tokenisation au profit d’entrées en octets bruts, mais ce choix entraîne généralement un coût élevé en vitesse d’inférence
• Ce coût en vitesse peut être compensé par des architectures spéciales dans les couches initiales et finales, ou par un calcul variable dans les couches intermédiaires
• Ces approches ne sont pas encore largement adoptées, et la plupart des modèles modernes reposent toujours sur la tokenisation en sous-mots
• La principale alternative au BPE est la méthode Unigram, mais malgré des travaux suggérant qu’elle est meilleure que le BPE, elle reste peu utilisée en pratique

Problèmes concrets posés par les tokens sous-entraînés

• Dans un tokenizer de taille fixe, les tokens sous-entraînés occupent une capacité de vocabulaire qui pourrait être utilisée par des tokens plus fréquents
  • Cela peut faire manquer des occasions de réduire la longueur moyenne des entrées/sorties et le coût d’inférence
• Si ces tokens sont inclus intentionnellement ou accidentellement dans les données d’entrée, ils peuvent produire des sorties indésirables du modèle et casser des applications en aval
• Avec la progression de l’utilisation d’outils par les LLM et des agents qui recherchent et traitent des données externes, la robustesse face aux entrées inattendues ou malveillantes devient plus importante
• Si le modèle est poussé hors de sa distribution d’entraînement, ces tokens pourraient aussi être exploités pour contourner des garde-fous

Approche de détection automatique et outil public

• Des travaux antérieurs avaient déjà tenté de trouver ces tokens par l’analyse des modèles et des tokenizers, mais il manquait des méthodes automatisées fiables fonctionnant de manière cohérente sur divers modèles
• L’étude combine trois méthodes pour identifier les tokens problématiques
  • Analyse du tokenizer
  • Métriques basées sur les poids des embeddings du modèle
  • Techniques de prompting
• Ces méthodes ont été appliquées à plusieurs modèles à poids ouverts populaires et récemment publiés, et l’extension à des modèles fermés est aussi brièvement explorée
• Un outil d’analyse général compatible avec les modèles Hugging Face, ainsi que des résultats détaillés par modèle, ont également été publiés
  • cohere-ai/magikarp

[GN⁺]

Avis sur Hacker News

• La vidéo de Computerphile sur les tokens glitch d’il y a un an était excellente : https://www.youtube.com/watch?v=WO2X3oZEJOA

  • D’une certaine manière, cette vidéo paraît plus intéressante que la prépublication de l’article

• Plutôt que de chercher seulement les tokens sous-entraînés, il faudrait aussi chercher les déséquilibres de données d’entraînement dans tous les poids de toutes les autres couches, puisque les tokens sont en fait la première couche du réseau neuronal
  Si l’on trouve de tels poids, il peut être préférable de supprimer ceux par lesquels très peu de données transitent, ce qui pourrait rendre le modèle plus petit ou aider à sa généralisation

  • Je dirais que la distillation de modèle fait cela. SparseGPT en a été un grand exemple et, si je me souviens bien, il a supprimé 50 % des paramètres sans perte importante de précision
    J’ai aussi vu récemment un article qui citait SparseGPT et atteignait environ 70 à 80 % de sparsité, ce qui était assez impressionnant
  • « Supprimer les poids par lesquels très peu de données transitent », n’est-ce pas l’idée des réseaux neuronaux clairsemés ?
  • Les modèles réguliers peuvent déjà être compressés ou fusionnés

• C’est quand même difficile à croire qu’un modèle d’une entreprise canadienne contenait des tokens sous-entraînés liés au hockey, même s’ils étaient en allemand
  Blague à part, c’est assez chouette, et j’ai hâte que l’on comprenne mieux l’impact de la tokenisation sur les modèles. La découverte selon laquelle beaucoup des premiers modèles open source ont des problèmes avec les retours chariot est particulièrement notable, car selon la source des données, les retours chariot peuvent apparaître assez fréquemment

• Il existe une méthode de diagnostic de l’entraînement fondée sur la théorie des matrices aléatoires, qui utilise la densité spectrale de la matrice de corrélation des poids
  On ajuste la densité spectrale de chaque couche à une loi de puissance tronquée, et si l’exposant alpha de la loi de puissance est légèrement supérieur à 2, on considère que l’entraînement est correct
  https://jmlr.org/beta/papers/v22/20-410.html

• La solution ne serait-elle pas simplement d’entraîner le tokenizer sur le même corpus que le LLM ? Je ne comprends pas bien pourquoi la réutilisation de tokenizers est si courante. Quelqu’un sait ?

  • En plus de ce que d’autres ont dit, même si l’on pouvait entraîner le tokenizer exactement sur le même jeu de données d’entraînement, cela ne ferait pas disparaître tous ces problèmes
    Avec l’approche BPE, certains tokens peuvent devenir très rares parce qu’ils sont fusionnés avec d’autres. Si l’on a les tokens X et Y, et que presque tous les X sont suivis de Y, le processus BPE créera un nouveau token XY, mais ne supprimera pas le token X existant, qui devient alors sous-entraîné
    Pour résoudre cela, il faudrait sans doute un algorithme de fusion plus sophistiqué qu’une fusion gloutonne
  • Deux raisons me viennent à l’esprit pour réutiliser un tokenizer
    Premièrement, lorsqu’on veut poursuivre le pré-entraînement d’un modèle au lieu de repartir de zéro. Cela dit, certaines personnes ignorent peut-être qu’on peut réutiliser assez facilement les poids d’un modèle même en l’entraînant avec un nouveau tokenizer. J’ai écrit un article à ce sujet : https://umarbutler.com/how-to-reuse-model-weights-when-train...
    Deuxièmement, c’est pratique pour les utilisateurs finaux. Tokeniser un très grand corpus et le découper en chunks peut prendre beaucoup de temps ; si l’on peut le traiter une fois avec le tokenizer GPT2 puis entraîner plusieurs modèles sur les mêmes données, cela évite de tout retokeniser
  • À la lecture du résumé, cette technique semble utile quand on n’a pas accès au corpus. Par exemple, quand on peut télécharger des poids open source, mais que le corpus est privé
    Sinon, il me semble qu’il suffirait de calculer un histogramme des tokens sur un échantillon statistique du corpus
  • En général, on commence avec l’intention d’utiliser le même corpus pour le tokenizer et le LLM, mais après avoir entraîné le tokenizer, pendant les tests du LLM, on découvre qu’une partie du corpus n’est qu’un fatras inutile
    Sans vouloir offenser SolidGoldMagikarp pour ses efforts sur le subreddit counting, ces parties sont exclues de l’entraînement ultérieur. Mais à ce moment-là, le tokenizer fait déjà partie de l’API, donc passer à une nouvelle version casserait d’autres choses, et les tokens inutiles restent finalement dans le vocabulaire
  • C’est possible, mais si le corpus est très volumineux, c’est difficile en pratique

• Le titre de l’article est vraiment excellent

  • Le titre complet est « Fishing for Magikarp: Automatically Detecting Under-trained Tokens in Large Language Models »