Il faut prêter attention au tokenizer

• En aidant au développement d’applications d’IA traitant des données e-commerce, on a constaté que la retrieval-augmented generation (RAG) fonctionnait bien pour certaines requêtes, mais pas pour d’autres
• Pour résoudre ce type de problème, il est important d’examiner les données d’entrée (le texte source indexé, les requêtes utilisateur utilisées pour la recherche)
• Une optimisation semblait notamment nécessaire du point de vue du chunking et de la tokenization

[Tokenization]

• La tokenization est le processus qui consiste à décomposer un texte en plus petits éléments, appelés tokens, par un tokenizer
• Ces tokens sont associés à des token IDs, c’est-à-dire des valeurs entières qui identifient de manière unique un token dans le vocabulaire du tokenizer
• Le vocabulaire du tokenizer est l’ensemble de tous les tokens possibles utilisés pour entraîner le tokenizer
• Des problèmes peuvent survenir lorsque les tokens d’un texte ne figurent pas dans le vocabulaire du tokenizer du LLM
• La plupart des LLM possèdent un grand vocabulaire de 30k à 300k éléments
• La plupart des LLM largement utilisés reposent sur des tokenizers subword (BPE, Wordpiece, etc.)
• Types de tokenizer
  • word : découpe selon les espaces, la ponctuation, etc.
  • character : découpe en caractères individuels (parfois en incluant la ponctuation)
  • subword : découpe les tokens en sous-mots qui peuvent sembler dénués de sens
  • La plupart des LLM utilisent des tokenizers subword
    • BPE (Byte-Pair Encoder) : bibliothèque tiktoken d’OpenAI
    • Wordpiece : Cohere, MiniLM-L6-v2, etc.

Comparaison entre MiniLM-L6-v2 et tiktoken

• La taille du vocabulaire du tokenizer du modèle MiniLM-L6-v2 est de 30522, bien plus petite que celle de tiktoken (200019)
• Si l’on tokenise la phrase "tokenizer tokenizes text into tokens"
  • MiniLM-L6-v2 : [CLS] token ##izer token ##izes text into token ##s [SEP]
  • tiktoken : token, izer, token, izes, text, into, tokens
• La bibliothèque tiktoken d’OpenAI implémente un tokenizer BPE et est utilisée dans les modèles LLM de ChatGPT
• Le vocabulaire de MiniLM-L6-v2 comprend aussi des caractères allemands et japonais

Tokenization des emojis, fautes de frappe et termes spécifiques au domaine

• MiniLM-L6-v2 tokenise les emojis en token [UNK]
• tiktoken a été entraîné sur certains tokens de caractères Unicode, mais cela peut tout de même poser problème en RAG
• Des noms de produits spécifiques au domaine comme "Gucci Savoy Leathertrimmed Printed Coatedcanvas Suitcase" ne sont pas non plus correctement tokenisés
• Dans le cas d’une phrase avec fautes de frappe ("I hve received wrong pckage")
  • MiniLM-L6-v2 : i, h, ##ve, received, wrong, pc, ##ka, ##ge
  • tiktoken : I, h, ve, received, wrong, p, ck, age

[Embeddings]

• Le tokenizer en lui-même n’est pas très utile. Il a surtout été développé pour permettre des analyses numériques complexes basées sur la fréquence des tokens individuels
• Pour préserver le sens contextuel d’un texte, il faut une méthode capable de capturer les relations entre les tokens
• Les embeddings sont des vecteurs représentant les tokens, qui capturent bien le sens et les relations entre les mots d’un texte
• Les embeddings sont un sous-produit de l’entraînement des transformeurs, et sont effectivement appris à partir d’un corpus de texte tokenisé
• Lorsqu’on demande une génération de texte, ce qui est donné en entrée au LLM, ce sont précisément ces embeddings
• Un LLM se compose de deux grands éléments : un encodeur et un décodeur
  • L’encodeur comme le décodeur prennent des embeddings en entrée
  • La sortie de l’encodeur est aussi un embedding, transmis aux têtes de cross-attention du décodeur, où il joue un rôle essentiel dans la génération (prédiction) des tokens en sortie
• Dans un pipeline RAG, le texte est d’abord tokenisé, puis transformé en embeddings, avant d’être envoyé au transformeur
  • Les token IDs servent d’indices dans le vocabulaire du tokenizer et sont également utilisés pour récupérer les embeddings dans la matrice d’embedding
  • Les embeddings récupérés sont assemblés en tenseur puis donnés en entrée au transformeur
• Flux côté encodeur : tokenization du texte -> récupération de l’embedding de chaque token -> assemblage du tenseur d’embeddings -> injection dans l’entrée du transformeur -> encodage -> transmission de la sortie de l’encodeur à la cross-attention du décodeur -> génération de la sortie du décodeur

Exemples d’embeddings

• "You can break it 😞" et "You can not break it 😊" ont des sentiments opposés, mais dans MiniLM-L6-v2, la distance entre leurs embeddings est très faible
• OpenAI obtient de meilleures performances parce que son vocabulaire de tokens gère bien les emojis
• OpenAI gère aussi mieux les fautes de frappe
• Mais même chez OpenAI, l’ajout d’un espace final à la fin d’une phrase peut écarter la distance entre embeddings de manière inattendue
• Les développeurs rencontrent aussi des difficultés avec les formats de date. Les expressions de temps relatives ("expédié hier") peuvent poser un problème encore plus important
• Les différences de notation monétaire (£40, $50, 40£, 50¢, etc.) peuvent également provoquer des problèmes étranges
• Dans le cas de données spécifiques au domaine, comme l’exemple du sac Gucci, on résout généralement cela par du fine-tuning, mais il faut toujours vérifier les données et les métriques d’évaluation

Conclusion

• Cet article aide à mieux comprendre comment les tokenizers peuvent affecter une application RAG, et pourquoi il faut y prêter attention
• Dans les applications agentiques, le principe garbage-in garbage-out ne produira pas toujours les résultats attendus
• Un simple nettoyage léger du texte d’entrée peut déjà beaucoup aider
  • standardiser les formats de date de façon cohérente
  • supprimer autant que possible les espaces de fin de ligne ou de fin de texte (on a constaté leur effet sur les embeddings)
  • appliquer la même logique à d’autres données numériques, comme les prix exprimés dans différentes devises
• On peut espérer qu’un jour, il ne sera plus du tout nécessaire de penser aux tokenizers. Qu’on pourra complètement s’en débarrasser
• À ce moment-là, il ne sera plus nécessaire de gérer les fautes de frappe, les espaces arbitraires, les attaques adversariales basées sur la perplexité des mots, etc. Toute une catégorie de tristesse pourrait disparaître du jour au lendemain
• D’ici là, tokenisez de manière responsable

L’avis de GN⁺

• Cet article montre bien comment les tokenizers et les embeddings peuvent influencer les performances d’applications d’IA basées sur le RAG. Il explique avec des cas concrets les points de vigilance, notamment pour les emojis, les fautes de frappe et les termes spécifiques à un domaine, ce qui devrait être très utile aux développeurs
• Cela dit, MiniLM-L6-v2 et tiktoken présentés dans cet article sont tous deux optimisés pour l’anglais ; lorsqu’on traite d’autres langues comme le coréen, des considérations supplémentaires peuvent s’appliquer. Dans le cas du coréen, on utilise souvent une tokenization fondée sur l’analyse morphologique, et il serait utile d’examiner aussi ses avantages, ses limites et ses contraintes
• En outre, cet article se concentre sur le rôle des tokenizers et des embeddings dans un pipeline RAG, mais dans un environnement de production réel, il y a bien davantage d’éléments à prendre en compte, comme le prétraitement des données, le tuning des hyperparamètres ou l’allégement des modèles. Il est donc important de voir le contenu de cet article comme un point de départ et de rechercher la meilleure approche au moyen d’expérimentations et d’évaluations variées au cours du développement réel
• Par ailleurs, certains estiment que l’importance du tokenizer diminue avec l’arrivée de grands modèles de langage comme GPT-4. Comme ces modèles fonctionnent au niveau de la phrase ou du paragraphe plutôt qu’au seul niveau du token, l’impact de la qualité des tokens individuels sur les performances pourrait devenir relativement moindre. Cela dit, les recherches sur ce point restent encore insuffisantes, et il semble difficile de trancher de façon définitive
• Enfin, comme l’article le souligne, le simple fait de nettoyer et de standardiser les données d’entrée en amont peut déjà améliorer fortement les performances du modèle. Lors du développement d’un service réel, il est donc très important de construire un pipeline de prétraitement des données robuste, tenant compte de la diversité et du bruit dans les entrées utilisateur. Il semble également nécessaire d’investir suffisamment de ressources dans l’annotation et le labeling des données afin d’obtenir des données d’entraînement de haute qualité

[GN⁺]

Commentaire Hacker News

• Les tokenizers ne sont pas considérés comme la partie « sexy » des LLM, mais certains y voient une opportunité. Des articles comme xVal proposent des stratégies de spécialisation de la tokenization. L’orthographe et les tâches au niveau des caractères constituent un autre problème qui pourrait bénéficier d’innovations en tokenization

  • Les LLM sont faibles pour compter le nombre de caractères dans un mot ou effectuer des omissions de caractères. Par exemple, GPT-4o écrit et exécute un petit programme Python pour compter les occurrences de caractères. La tokenization efface en pratique la connaissance des caractères du prompt et nuit directement aux performances sur ce type de tâches

• Il faut comprendre les données pour effectuer un travail utile. La principale raison pour laquelle beaucoup de gens utilisent des outils automatisés de traitement des données est qu’ils ne veulent pas regarder les données eux-mêmes. Ils voudraient qu’un ordinateur puisse examiner les données et demander à collecter des informations supplémentaires

• J’ai particulièrement apprécié la partie du billet de blog sur les fautes de frappe. J’aide sur un projet avec une application semblable à du RAG, et je m’inquiète de l’impact de petites fautes de frappe ou différences de format dans les requêtes utilisateur sur le calcul des distances d’embedding

  • Je me demande s’il faut ajouter des fautes de frappe / substitutions / capitalisations intentionnelles dans les données d’entraînement afin que le modèle apprenne que « wrk » et « work » sont probablement synonymes

• J’ai travaillé sur une application qui utilisait Elasticsearch pour traiter, via des requêtes textuelles avancées, la similarité entre des entrées d’une à deux phrases et des documents d’au moins un paragraphe. Il était intéressant de voir à quel point la stratégie de tokenization pouvait influer sur certaines requêtes

  • Par exemple, dans des cas comme « W-4 » ou « W4 », la tokenization standard peut couper sur « - » ou à la frontière lettre/chiffre. Cette entrée devient alors totalement impossible à identifier dans l’index

• J’ai l’impression que l’article manque d’une discussion sur les solutions à chacun des problèmes. Je proposerais d’exécuter le correcteur orthographique avant la tokenization, ou de tokenizer côte à côte le mot mal orthographié et ses corrections potentielles

  • Pour le problème des noms de marque, je ne vois pas comment le résoudre. Ce problème peut être plus grave dans des langues moins courantes ou dans celles qui utilisent beaucoup de mots composés

• Beaucoup de développeurs ont l’habitude de développer dans un espace traditionnel (déterministe), mais ne parviennent pas à changer leur manière de penser les problèmes dans un espace statistique. Les applications LLM relèvent au final d’un espace statistique

  • En tant que développeur, j’ai du mal à expliquer ce problème aux utilisateurs

• La plupart des personnes qui implémentent du RAG réfléchissent aux embeddings, pas à la tokenization

  • Elles découpent le corpus de données en chunks et calculent un embedding pour chaque chunk. Elles génèrent des requêtes et calculent un embedding pour chacune. Elles classent les chunks du corpus selon leur distance à la requête. Elles construisent ensuite la valeur de retour
  • Cet article met en évidence l’importance de tâches cachées et relativement banales qui peuvent avoir un impact majeur sur les performances du système

• Je n’arrive pas à reproduire certains chiffres du billet de blog. Par exemple, le résultat du calcul de similarité cosinus entre deux phrases dans le code utilisant SentenceTransformer diffère de ce qui est attendu

• J’ai vu, dans plusieurs implémentations de RAG, le problème qui consiste à supposer que le document cible constituera une bonne clé de recherche pour la requête entrante. Dans un projet récent, la pertinence de la recherche a fortement progressé en séparant les clés de recherche de la valeur de retour (les documents découpés en chunks) et en utilisant un LM pour générer puis embedder des clés appropriées

• On dit que les vocabulaires de nombreux grands LLM sont déjà assez volumineux, mais l’anglais seul compte plus d’un million de mots. Entre 30k et 300k tokens, cela semble peu