Les grands modèles de langage sont entraînés sur du texte propre. C'est à la fois leur force et leur angle mort. Lorsque ces modèles rencontrent le texte désordonné et truffé de fautes que les vrais humains produisent, ils trébuchent — interprétant mal l'intention, perdant le contexte ou échouant silencieusement. La solution n'est pas d'entraîner sur plus de données propres. C'est d'injecter délibérément du bruit réaliste dans les pipelines d'entraînement pour que les modèles apprennent à gérer le texte imparfait qu'ils recevront effectivement.

Cet article explore deux cas d'utilisation émergents pour la génération de fautes basée sur la physique : l'augmentation des données d'entraînement LLM avec du bruit réaliste, et l'ajout d'imperfection contrôlée aux workflows multi-agents où le texte stérile passant entre agents crée ses propres problèmes.

Le problème des données propres

Les LLM modernes sont massivement entraînés sur du texte édité, relu et sélectionné — livres, articles, documentation et pages web qui ont été nettoyés et dédupliqués. Cela crée un décalage de distribution. Le modèle apprend à traiter de la prose soignée, mais le texte qu'il reçoit en production est plein de fautes, d'artefacts d'autocorrection, d'erreurs d'espacement et du chaos général de la frappe humaine.

Ce n'est pas une préoccupation théorique. Les études sur la robustesse des modèles montrent systématiquement que même de petites perturbations du texte d'entrée — une substitution de caractère, un mot transposé, un espace manquant — peuvent modifier considérablement la sortie d'un modèle. Un classifieur de sentiment entraîné sur du texte propre peut inverser sa prédiction quand « great » devient « grrat ». Un système de reconnaissance d'entités nommées peut échouer à identifier « Gogle » comme « Google ». Un système de réponse aux questions peut perdre le fil d'une requête quand un utilisateur tape « waht » au lieu de « what ».

La solution est l'augmentation de données : étendre les jeux de données d'entraînement avec des variantes réalistes des exemples existants. Mais la qualité du bruit compte énormément.

Pourquoi le bruit aléatoire échoue pour les données d'entraînement

L'approche la plus courante de l'augmentation de texte est la perturbation aléatoire de caractères — échanger un caractère, supprimer un caractère, insérer un caractère à des positions aléatoires. Cela produit du bruit, mais pas du bruit réaliste. Les mutations aléatoires créent des erreurs qu'aucun humain ne ferait jamais. Elles ne suivent pas la géométrie du clavier, les schémas tactiles spécifiques aux appareils ou la distribution statistique des vraies erreurs de frappe.

Quand vous entraînez un modèle sur du texte perturbé aléatoirement, vous lui enseignez à gérer des perturbations aléatoires. Vous ne lui enseignez pas à gérer les types spécifiques d'erreurs que les humains font réellement. Le modèle peut devenir robuste face à « h3llo » (une substitution aléatoire) mais échouer toujours sur « hrllo » (une frappe de touche adjacente que les vrais utilisateurs produisent quotidiennement). L'augmentation dépense son budget d'erreur sur des entrées impossibles plutôt que sur des entrées probables.

La génération de fautes basée sur la physique résout ce problème en produisant des erreurs qui suivent la même distribution que la vraie frappe humaine. Les touches adjacentes sont frappées parce qu'elles sont physiquement adjacentes. Les caractères sont sautés parce que les doigts bougent trop vite. Les mots sont doublés parce que le cerveau bégaie. Le bruit est réaliste parce qu'il est ancré dans les mêmes mécanismes qui produisent les vraies fautes.

Augmentation des données d'entraînement avec LikelyTypo

Le workflow principal pour l'augmentation des données d'entraînement LLM est simple : prendre des exemples d'entraînement propres existants, les passer dans un générateur de fautes avec des paramètres contrôlés, et ajouter les variantes bruitées au jeu d'entraînement aux côtés des originaux. Le modèle apprend alors à associer à la fois les entrées propres et bruitées à la bonne sortie.

Contrôler la distribution du bruit

Tous les exemples d'entraînement ne devraient pas recevoir le même niveau de bruit. Un pipeline d'augmentation bien conçu fait varier les caractéristiques d'erreur à travers le jeu de données :

  • Variation du taux d'erreur — Certains exemples devraient avoir des erreurs clairsemées (une faute par phrase), d'autres devraient être fortement corrompus. Cela enseigne au modèle à gérer une gamme de qualité d'entrée.
  • Variation d'appareil — Les erreurs de clavier sont différentes des erreurs de tap téléphone. Inclure les deux dans les données d'entraînement garantit que le modèle gère les schémas d'erreur de toutes les sources d'entrée.
  • Variation de profil — Un dactylographe soigneux fait des erreurs différentes de quelqu'un qui tape rapidement ou avec colère. Mélanger les profils dans le jeu d'entraînement couvre tout le spectre du comportement de frappe humain.
  • Reproductibilité par graine — L'utilisation de graines déterministes signifie que vous pouvez regénérer exactement le même jeu de données augmenté pour des expériences reproductibles. Changez la graine, obtenez une augmentation différente. Même graine, mêmes résultats.

Ajustement des poids d'erreur

LikelyTypo expose des poids individuels pour chaque type d'erreur — frappes de touches adjacentes, caractères sautés, touches doublées, erreurs d'espacement, erreurs de ponctuation, et plus encore. Cela signifie que vous pouvez façonner la distribution du bruit pour correspondre à votre cas d'utilisation spécifique. Si votre modèle reçoit principalement des entrées mobiles, augmentez le poids des erreurs liées au rayon tactile. S'il traite du texte formel, gardez le bruit subtil avec principalement des substitutions de touches adjacentes.

Ce niveau de contrôle est ce qui sépare l'augmentation utile de l'ajout de bruit pour le simple fait d'ajouter du bruit. L'objectif n'est pas de dégrader les données d'entraînement. C'est de les rendre plus représentatives de ce que le modèle rencontrera effectivement.

Workflows multi-agents : le problème du pipeline stérile

Une application moins évidente émerge dans les architectures agentiques — des systèmes construits avec des frameworks comme AutoGen, CrewAI ou LangGraph où plusieurs agents IA collaborent sur des tâches. Dans ces workflows, un agent génère du texte qu'un autre agent consomme comme prompt, document de contexte ou tour de conversation. Le texte passant entre agents est parfaitement propre, parfaitement formaté et parfaitement artificiel.

Cette stérilité crée des problèmes. Quand un agent en aval est affiné pour des entrées humaines, recevoir un texte parfait par une machine peut subtilement altérer son comportement. Le modèle peut activer différents schémas d'attention, produire différents scores de confiance ou générer des réponses avec un ton différent de celui qu'il aurait pour une entrée humaine équivalente. Le pipeline fonctionne, mais il fonctionne différemment qu'avec de vrais utilisateurs.

Ajouter du bruit réaliste aux messages inter-agents

L'injection de fautes contrôlées dans la couche de transmission de messages d'un système multi-agents sert plusieurs objectifs :

  • Cohérence comportementale — Si un agent est affiné pour des entrées humaines, lui fournir des entrées de type humain (fautes incluses) produit un comportement plus prévisible et cohérent que de lui fournir du texte machine immaculé.
  • Test de robustesse — Ajouter du bruit entre agents dans un pipeline d'orchestration révèle la fragilité de chaque étape. Si un agent en aval tombe en panne quand la sortie d'un agent en amont contient une seule faute, c'est un problème de fiabilité qu'il vaut mieux découvrir avant la mise en production.
  • Fidélité de simulation — Les systèmes multi-agents qui simulent des conversations humaines — pour la génération de données synthétiques, les benchmarks d'évaluation ou les tests utilisateurs — produisent des interactions plus réalistes quand le texte inclut les imperfections de la vraie frappe humaine.
  • Authenticité du persona — Un agent jouant le rôle d'un client pressé ne devrait pas produire une prose immaculée. Ajouter des fautes cohérentes avec un profil de frappe rapide rend le persona plus convaincant pour les autres agents du workflow.

Calibrer le bruit pour les pipelines d'agents

Le taux d'erreur pour les messages inter-agents devrait généralement être plus bas que pour l'augmentation des données d'entraînement. L'objectif n'est pas de mettre l'agent récepteur sous pression mais de déplacer la distribution d'entrée plus près de ce à quoi ressemble le texte généré par des humains. Un profil subtil avec des erreurs occasionnelles de touches adjacentes et de rares erreurs d'espacement suffit généralement pour obtenir cet effet sans dégrader le contenu informationnel du message.

La vision d'ensemble

Alors que les LLM passent des démos de recherche aux systèmes de production, la robustesse face aux entrées du monde réel n'est plus optionnelle. Les utilisateurs ne tapent pas soigneusement. Ils tapent sur leur téléphone en marchant. Ils tapent avec l'autocorrection qui les combat. Ils tapent dans des langues où la disposition du clavier ne correspond pas aux caractères dont ils ont besoin. Chacun de ces scénarios produit un schéma d'erreurs distinctif, et les modèles qui n'ont jamais vu ces schémas pendant l'entraînement les géreront mal.

La génération de fautes basée sur la physique offre une approche principielle pour combler cet écart. Au lieu d'espérer que les modèles généralisent du texte propre au texte bruité, vous pouvez explicitement les entraîner sur les types de bruit qu'ils rencontreront. L'idée clé est que les erreurs de frappe ne sont pas aléatoires — elles suivent des schémas physiques et cognitifs prévisibles — et le bruit que vous ajoutez à vos données d'entraînement devrait suivre ces mêmes schémas.

Générez du bruit de fautes réaliste pour votre pipeline

Expérimentez avec différents appareils, profils et taux d'erreur pour voir comment les fautes basées sur la physique se comparent au bruit aléatoire. Intégrez-les dans votre workflow via l'API REST ou le serveur MCP.

Essayer la vitrine interactive Documentation API Configuration serveur MCP

Le texte que les humains produisent est désordonné par nature. Les données d'entraînement devraient refléter ce désordre — pas avec de la corruption aléatoire, mais avec les imperfections spécifiques et physiquement ancrées que de vrais doigts sur de vrais appareils produisent effectivement. C'est la différence entre le bruit et le bruit réaliste, et pour la robustesse des LLM, cette distinction compte.