LLM en amont du pipeline ML : gains d'itération mais nouvelle classe de défaillances

Un assistant en amont, pas un remplacement

Dans un projet récent d'apprentissage automatique sans caractère exceptionnel – mélange de champs structurés, de texte et de valeurs manquantes – une équipe a décidé de placer un grand modèle de langage (LLM) non pas à la place du modèle existant, mais en amont de celui-ci, en tant qu'assistant de prétraitement. L'idée était de confier au LLM la tâche de nettoyer les entrées textuelles brutes et d'en extraire une structure exploitable par le modèle traditionnel, sans modifier le modèle lui-même.

Les premiers résultats se sont révélés « agacants de qualité », selon un membre de l'équipe. Là où les règles écrites à la main et les expressions régulières peinaient, le LLM a su normaliser des descriptions, extraire des catégories d'intention cohérentes et transformer un langage humain brouillon en signal utilisable. Ce premier constat rejoint ce qui est souvent mis en avant dans les présentations : un système aux prises avec des entrées bruitées peut recevoir, avec un effort modéré, des caractéristiques (features) de meilleure qualité que celles produites manuellement.

Un gain de vitesse qui change l'économie de l'itération

Le premier changement notable, avant même la qualité du modèle final, a concerné la vitesse d'itération. Auparavant, toute nouvelle idée d'extraction nécessitait d'écrire du code, de l'intégrer au pipeline, d'attendre une exécution, puis de constater que l'idée n'était pas bonne. Avec le LLM dans la boucle, une grande partie de ce travail s'est transformée en expérimentation à « vitesse conversationnelle ». Les membres de l'équipe ont pu demander des étiquettes candidates, des résumés de champs, des catégories normalisées, ou des indications de confiance, autant de micro-structures qui auraient auparavant été trop coûteuses à produire pour un simple test.

Cette réduction de la friction a modifié l'économie même de l'itération. Au lieu de protéger chaque hypothèse comme un héritage, les développeurs ont pu en essayer dix, parce que l'effort nécessaire était soudainement faible. Le gain principal est donc venu du positionnement du LLN « en amont » du modèle, dans la phase de conception et de prototypage, bien avant la mise en production.

Une politesse trompeuse : le défaut silencieux des LLM

Mais « plus rapide » n'est pas synonyme de « meilleur », et les retours d'expérience mettent en garde contre une nouvelle classe de défaillances. Alors qu'un prétraitement classique plantait bruyamment en cas d'erreur, le LLM se montre « bien plus poli ». Il produit une réponse plausible, parfois élégante, occasionnellement pertinente, mais parfois aussi complètement trompeuse d'une manière difficile à détecter car rien n'explose.

Cette caractéristique est jugée « dangereuse » par l'équipe : « elles échouent en phrases complètes », résume l'un des observateurs. Une classification légèrement erronée ici, un résumé un peu trop beau là, une catégorie stable jusqu'à ce que suffisamment de cas limites s'accumulent : le modèle aval se retrouve à apprendre à partir d'un monde cohérent en apparence mais erroné dans le détail. Le risque est d'autant plus grand une fois le système placé « sur le chemin chaud entre les clients et la base de données », où il peut redéfinir silencieusement ce que signifie une catégorie pendant que tout le monde est en réunion.

Génération de données synthétiques : le problème de la confiance générée

L'équipe a également tenté d'utiliser le LLM pour générer des données d'entraînement supplémentaires, en particulier pour des cas rares mais importants. L'idée était de créer des variantes, d'enrichir les classes et de produire des exemples que les utilisateurs n'avaient pas encore fournis. Dans un sens étroit, cela a fonctionné : le jeu de données s'est enrichi, le modèle a été exposé à des motifs auparavant sous-représentés, et certains résultats se sont améliorés.

Cependant, l'équipe a rapidement constaté que les données générées partagent le même problème que la confiance générée : elles peuvent être « très convaincantes tout en étant très légèrement déconnectées de la réalité ». Le LLM ne ment pas – le mensonge supposerait une intention – mais il produit des données plausible qui, en apparence cohérentes, peuvent s'écarter subtilement du monde réel, rendant l'évaluation de leur qualité particulièrement délicate.

Conclusion : un outil puissant mais dangereux pour le pipeline ML

Cet exemple illustre comment l'intégration d'un LLM en amont d'un pipeline classique peut accélérer de manière significative la phase d'exploration et de prototypage, tout en améliorant la qualité des caractéristiques extraites. Mais il met aussi en lumière les risques associés à une confiance excessive dans des sorties qui échouent « en phrases complètes » : les défaillances sont silencieuses, cohérentes et donc difficiles à détecter. L'équipe prévient qu'il s'agit d'une « propriété dangereuse » qui appelle à une vigilance particulière, surtout lorsque le système est déployé sur le chemin critique d'une application.