Aller au contenu principal
LLMsMarkTechPost1j

Qu'est-ce que la dérive de tokenisation et comment y remédier ?

Résumé IASource uniqueImpact UE
Source originale ↗·

Un modèle de langage peut produire des résultats parfaits à un instant donné, puis se dégrader sans que rien n'ait changé dans les données ou le code. La cause, souvent invisible, se trouve dans la tokenisation : avant tout traitement, un modèle convertit le texte en identifiants numériques appelés tokens, et de minuscules variations de formatage, un espace en début de mot, un saut de ligne, une ponctuation différente, peuvent générer des séquences de tokens entièrement distinctes. Ce phénomène porte un nom : la dérive de tokenisation, ou tokenization drift. Une démonstration concrète avec le tokeniseur GPT-2 (le même schéma Byte-Pair Encoding utilisé par GPT-4, LLaMA et Mistral) l'illustre parfaitement : aucune des sept paires de mots testés, "classify" avec ou sans espace initial, ne produit le même identifiant de token. Mieux encore, " classify" avec espace est encodé en un seul token (36509), tandis que "classify" sans espace devient deux tokens distincts (4871 et 1958). Le modèle ne voit pas seulement un identifiant différent : il reçoit une séquence de longueur différente, ce qui modifie le calcul de l'attention sur l'ensemble du contexte suivant.

L'impact dépasse la simple curiosité technique. Lors du fine-tuning par instructions, les modèles apprennent non seulement des tâches, mais aussi la structure dans laquelle ces tâches leur sont présentées : séparateurs spécifiques, préfixes, motifs de formatage. Quand un prompt s'écarte de ces schémas appris, le modèle ne se retrouve plus dans sa distribution familière. Le résultat n'est pas une erreur franche mais quelque chose de plus insidieux : un modèle qui fait de son mieux sur des entrées qu'il n'a jamais été optimisé à traiter. Pour les équipes en production, cela signifie des régressions inexpliquées, des comportements non reproductibles entre environnements, et des bugs difficiles à diagnostiquer car aucun composant visible n'a changé.

La solution proposée passe par une boucle légère d'optimisation des prompts : mesurer la dérive entre formats alternatifs via une métrique de distance dans l'espace des tokens, puis sélectionner le format qui maintient les entrées dans la distribution la plus stable. Cette approche s'appuie sur des outils accessibles, NumPy, scikit-learn pour une réduction PCA, seaborn pour la visualisation, et ne nécessite aucun ré-entraînement du modèle. Le sujet s'inscrit dans une réflexion plus large sur la fragilité des systèmes LLM face à des variations superficielles : la robustesse d'un pipeline d'IA ne dépend pas seulement de la qualité du modèle ou des données, mais aussi de la cohérence avec laquelle les entrées sont formatées à chaque étape, de la conception du prompt jusqu'au déploiement en production.

Dans nos dossiers

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Combien de tokens me reste-t-il ? La question que Claude n’arrivera peut-être jamais à résoudre
1Numerama 

Combien de tokens me reste-t-il ? La question que Claude n’arrivera peut-être jamais à résoudre

Anthropic fait face depuis plusieurs semaines à des tensions croissantes autour de la gestion des quotas de tokens de Claude, son assistant IA. Les limites d'utilisation, qui déterminent combien de messages un utilisateur peut envoyer avant d'être temporairement bloqué, sont devenues imprévisibles : certains abonnés payants se retrouvent bridés sans avertissement clair, incapables de savoir combien de capacité il leur reste. L'entreprise américaine a reconnu le problème et procède à des ajustements à chaud, sans pour autant fournir de calendrier précis pour une solution pérenne. Le problème touche en priorité les utilisateurs professionnels et les développeurs qui intègrent Claude dans leurs flux de travail quotidiens. Pour eux, une limite opaque n'est pas un simple désagrément : c'est une rupture de service qui bloque des projets, force des migrations vers des alternatives et érode la confiance dans la plateforme. L'impossibilité de mesurer sa consommation en temps réel empêche toute planification, ce qui tranche avec les standards attendus d'un outil B2B. Cette situation illustre la tension structurelle à laquelle Anthropic est confrontée : le succès fulgurant de Claude dépasse la capacité d'infrastructure de l'entreprise à absorber la demande sans frictions. Anthropic, qui a levé plusieurs milliards de dollars ces dernières années, investit massivement dans ses capacités de calcul, mais la montée en charge reste un défi en temps réel. Dans un secteur où OpenAI, Google et Meta se disputent les mêmes utilisateurs, chaque friction devient un argument commercial pour la concurrence.

UELes abonnés et développeurs européens intégrant Claude dans leurs flux de travail sont directement affectés par ces limitations opaques, sans visibilité sur leur consommation ni calendrier de résolution annoncé.

LLMsOpinion
1 source
#Nextquick : Pourquoi et comment Opus 4.7 crame ses tokens beaucoup plus vite qu’Opus 4.6
2Next INpact 

#Nextquick : Pourquoi et comment Opus 4.7 crame ses tokens beaucoup plus vite qu’Opus 4.6

Depuis le lancement d'Opus 4.7, de nombreux utilisateurs d'Anthropic constatent que leur forfait de tokens s'épuise nettement plus vite qu'avec la version précédente du modèle. Les tarifs affichés sont pourtant identiques : 5 dollars par million de tokens en entrée et 25 dollars par million en sortie, exactement comme pour Opus 4.6. Mais Anthropic reconnaît lui-même qu'une même requête peut consommer entre 1,0 et 1,35 fois plus de tokens avec Opus 4.7, selon le type de contenu, en raison d'un nouveau tokeniseur intégré au modèle. À cela s'ajoute un comportement de raisonnement plus intensif : Opus 4.7 génère davantage de tokens de sortie lorsqu'il fait face à des tâches complexes, car il mobilise un effort cognitif plus soutenu. Des tests comparatifs sur des prompts simples ont mis en évidence une consommation supérieure de 41 % par rapport à Opus 4.6. Claude Code, l'outil de développement assisté d'Anthropic, était particulièrement touché, avant qu'Anthropic n'intervienne pour réduire la verbosité des réponses. Cette sur-consommation a des conséquences financières directes et non négligeables pour les développeurs et les entreprises qui utilisent l'API à grande échelle. À usage identique, le coût réel d'Opus 4.7 dépasse celui d'Opus 4.6 malgré un tarif affiché identique, ce qui brouille la lisibilité budgétaire pour les équipes techniques. Pour les abonnés aux forfaits à volume fixe, c'est une érosion accélérée des quotas mensuels, parfois sans modification de leurs pratiques d'utilisation. Le problème touche aussi bien les développeurs indépendants que les équipes professionnelles intégrant Claude dans des pipelines automatisés. Ce décalage entre prix nominal et coût réel illustre une tension croissante dans l'industrie des LLM : les modèles deviennent plus capables, mais leur économie d'usage se complexifie. Le passage à un nouveau tokeniseur, décision technique invisible pour l'utilisateur final, peut bouleverser les budgets sans que les grilles tarifaires ne changent d'un centime. Anthropic a partiellement corrigé le tir en limitant la longueur des réponses, mais la question de la transparence sur le coût effectif des tokens reste ouverte, d'autant que les prochaines versions de Claude continueront probablement d'évoluer dans cette direction de raisonnement étendu.

UELes développeurs et entreprises européens utilisant l'API Claude d'Anthropic subissent une hausse de coût réel de 20 à 41% sans modification du tarif affiché, dégradant la prévisibilité budgétaire des équipes techniques intégrant Claude dans des pipelines automatisés.

💬 41% de tokens en plus sur des prompts simples, avec un tarif affiché inchangé, c'est une hausse de prix déguisée. Le nouveau tokeniseur d'Opus 4.7 est une décision technique totalement invisible pour l'utilisateur, mais elle peut faire sauter des budgets entiers sans que personne n'ait changé la moindre ligne de code. Bonne chance pour l'expliquer à ton DAF.

LLMsOpinion
1 source
Mais au fait, c’est quoi la Retrieval-Augmented Generation (RAG) ?
3Blog du Modérateur 

Mais au fait, c’est quoi la Retrieval-Augmented Generation (RAG) ?

La Retrieval-Augmented Generation (RAG) est une architecture qui combine deux composants distincts : un moteur de recherche documentaire et un modèle de langage (LLM). Concrètement, lorsqu'un utilisateur pose une question, le système commence par interroger une base de données externe pour extraire les passages les plus pertinents, puis transmet ces extraits au LLM qui les intègre dans sa réponse. Introduite dans un article de recherche de Meta en 2020, cette technique s'est imposée comme l'une des approches dominantes du déploiement d'IA en entreprise. L'enjeu est de taille : les LLMs seuls souffrent d'une connaissance figée à leur date d'entraînement et hallucinent des faits avec assurance. Le RAG corrige ces deux défauts en ancrant les réponses dans des documents vérifiables et actualisables — contrats internes, bases de connaissances, documentation technique — sans nécessiter de réentraînement du modèle. Des entreprises comme Notion, Salesforce ou Mistral AI intègrent désormais cette approche au cœur de leurs produits. Le RAG est devenu incontournable parce qu'il offre un compromis pragmatique entre coût et fiabilité : fine-tuner un modèle coûte cher et reste rigide, tandis que le RAG permet une mise à jour continue des sources. La prochaine frontière s'appelle le RAG agentique, où le système décide lui-même quelles sources interroger et en quelle séquence, rapprochant encore davantage ces architectures d'un raisonnement autonome.

UEMistral AI, entreprise française, intègre le RAG au cœur de ses produits, ce qui positionne cette architecture comme un enjeu stratégique pour l'écosystème IA européen.

LLMsTuto
1 source
Mystère résolu : Anthropic révèle que des changements de configuration et d'instructions ont causé la dégradation de Claude
4VentureBeat AI 

Mystère résolu : Anthropic révèle que des changements de configuration et d'instructions ont causé la dégradation de Claude

Pendant plusieurs semaines, des développeurs et utilisateurs avancés d'Anthropic ont signalé une dégradation notable des performances de Claude, le modèle phare de la startup. Le 24 avril 2026, Anthropic a publié un post-mortem technique détaillé reconnaissant que trois modifications distinctes apportées à l'environnement d'exécution du modèle, et non aux poids du modèle lui-même, étaient responsables des problèmes signalés. Premier changement : le 4 mars, le niveau d'effort de raisonnement par défaut dans Claude Code a été abaissé de "élevé" à "moyen" pour réduire la latence d'interface. Deuxième changement : le 26 mars, un bug dans une optimisation de cache supprimait l'historique de raisonnement du modèle à chaque tour de conversation après une heure d'inactivité, plutôt qu'une seule fois, privant le modèle de sa mémoire à court terme. Troisième changement : le 16 avril, des instructions limitant les réponses à 25 mots entre les appels d'outils et 100 mots pour les réponses finales ont provoqué une baisse de 3 % sur les évaluations de qualité de code. Anthropic affirme avoir résolu les trois problèmes dans la version v2.1.116. Ces dysfonctionnements ont eu des conséquences concrètes et mesurables. Stella Laurenzo, directrice senior dans le groupe IA d'AMD, a publié sur GitHub une analyse de 6 852 fichiers de session Claude Code et plus de 234 000 appels d'outils, montrant une chute significative de la profondeur de raisonnement et une tendance du modèle à privilégier "la correction la plus simple" plutôt que la bonne. Le cabinet BridgeMind a quant à lui documenté une chute du taux de précision de Claude Opus 4.6 de 83,3 % à 68,3 %, faisant chuter son classement de la 2e à la 10e place dans leurs tests. Les effets ne se sont pas limités à l'interface CLI Claude Code : le Claude Agent SDK et Claude Cowork ont également été touchés, bien que l'API Claude directe soit restée indemne. La confiance des développeurs, particulièrement des équipes d'ingénierie qui s'appuyaient sur Claude pour des tâches complexes, a subi un coup sérieux. La controverse avait commencé à prendre de l'ampleur début avril 2026, alimentée par des analyses techniques détaillées circulant sur GitHub, X et Reddit sous le terme "AI shrinkflation". Anthropic avait d'abord repoussé les accusations de dégradation volontaire du modèle, notamment les soupçons de bridage délibéré pour gérer une demande en forte hausse. Le post-mortem publié marque un changement de posture : l'entreprise reconnaît explicitement que ces modifications ont donné l'impression que le modèle était "moins intelligent". Pour l'avenir, Anthropic annonce la mise en place de garde-fous supplémentaires pour détecter ce type de régressions avant déploiement, et s'engage à communiquer plus rapidement en cas de problèmes similaires. L'épisode soulève une question structurelle pour l'industrie : à mesure que les modèles d'IA s'intègrent dans des workflows critiques, la frontière entre modèle et infrastructure d'exécution devient un vecteur de dégradation silencieuse difficile à diagnostiquer de l'extérieur.

UELes développeurs européens utilisant Claude Code ou le Claude Agent SDK ont subi la même dégradation de performances documentée, affectant leurs workflows critiques jusqu'au correctif publié dans la version v2.1.116.

LLMsOpinion
1 source