Habr AI Explique Pourquoi les LLM Ne Calculent Pas, N'Apprennent Pas dans le Dialogue et Dépendent des Outils

Un article sur Habr AI démonte le mythe populaire selon lequel un chatbot moderne est déjà en lui-même une intelligence universelle. La thèse principale de l'auteur est simple : un LLM de base, par sa nature, ne sait que travailler avec du texte — accepter une demande textuelle et générer une réponse textuelle. Tout le reste que l'utilisateur perçoit comme les « capacités magiques » du modèle est généralement fourni par des outils externes, des intégrations et de l'orchestration. C'est pourquoi les mêmes interfaces peuvent dessiner des images, chercher sur internet et calculer des nombres, bien que le modèle de langage lui-même ne devienne pas un artiste, un moteur de recherche ou une calculatrice pour autant.

Le premier malentendu est lié à la sensation qu'un LLM « peut tout faire ». Si vous lui demandez de créer une image, il formule une demande pour un modèle de génération séparé. Si vous lui parlez par la voix, la reconnaissance vocale et la synthèse vocale participent à la chaîne.

Si vous avez besoin d'un calcul précis, les résultats fiables n'apparaissent généralement qu'après avoir appelé un interpréteur de code ou un autre outil de calcul. Sans ces couches supplémentaires, un LLM s'appuie sur la reproduction probabiliste de modèles d'apprentissage : il peut résoudre correctement un exemple simple, mais sur les longs nombres, les formules et les tâches nécessitant une haute précision, il se trompe facilement. Il en découle une limite pratique importante : la force du modèle n'est pas la mathématique en tant que telle, mais la description textuelle de la tâche et la sélection de l'outil approprié.

Le deuxième mythe est que le modèle apprend pendant la conversation. L'auteur nous rappelle que l'inférence et l'apprentissage sont deux processus différents. Lorsqu'un utilisateur écrit une demande, le modèle génère séquentiellement des tokens basés sur des poids déjà fixés, et les poids eux-mêmes ne changent pas à ce moment.

Cela signifie qu'un LLM spécifique dans une session spécifique ne « retient pas une leçon » et ne devient pas plus intelligent de l'observation d'un utilisateur. Oui, les fournisseurs peuvent ensuite utiliser les dialogues anonymisés pour entraîner les futures versions, mais c'est déjà un cycle d'ajustement fin séparé, pas une mise à jour magique dans le chat. De cela découle aussi une autre conclusion : la mémoire utilisateur entre les dialogues est généralement non pas un apprentissage du modèle, mais du contexte sauvegardé qui est ensuite mélangé à nouveau dans la demande.

L'article explique ensuite brièvement de quoi se compose un LLM public. À sa base se trouve un transformer qui voit tout le contexte disponible à la fois et construit une réponse comme une séquence de tokens probables, maintenant la cohérence globale du texte grâce aux modèles appris. Au-dessus, fonctionne RLHF — l'ajustement pour le format d'assistant, la politesse, le respect des instructions et les restrictions de sécurité.

Mais RLHF ne transforme pas le modèle en machine logique et ne corrige pas les faiblesses fondamentales. Par conséquent, les modèles de langage sont bons pour l'analyse de texte, la synthèse, le changement de style, les instructions étape par étape, le travail avec des formats comme JSON et la sélection d'outils. Ils sont faibles en calcul précis, traitement des grandes tables, conservation d'énormes volumes de données en contexte et connaissance de l'état actuel du monde après la date d'entraînement.

À cela s'ajoutent la nature probabiliste de la réponse, la sensibilité à la formulation de la requête et le risque d'hallucinations.

Pour rendre un LLM utile en production, on construit une couche supplémentaire autour de lui. Pour les connaissances statiques, on utilise RAG : les documents sont divisés en fragments, les pièces sémantiquement proches sont trouvées par demande, et le modèle ne reçoit que le contexte pertinent. Pour les données dynamiques et les actions, on applique function calling : le LLM décide quand appeler une API, une base de données, une calculatrice ou une simulation, et l'orchestrateur valide les appels, ajoute les réponses des outils à l'historique et gère tout le cycle. Le même orchestrateur gère la mémoire du dialogue, les invites système, la validation du format de sortie et le lancement des sous-agents.

Sur cette base émergent des concepts plus ambitieux — les agents IA, les employés numériques, les copilotes et les jumeaux numériques. En essence, ce n'est pas une magie séparée, mais des combinaisons de LLMs, de bases de connaissances, d'APIs, d'automatisation et de moteurs de calcul classiques. Cela signifie que discuter « d'intelligence artificielle » sans distinguer les technologies n'est plus suffisant.

Si une entreprise a besoin d'un calcul précis, d'une automatisation stricte ou d'une prévision sur des données structurées, un LLM seul ne suffit pas. Si le travail avec les courriers, les documents, les instructions, la recherche de connaissances et une interface de dialogue à un système complexe est nécessaire, un LLM offre vraiment un coup de pouce puissant. La perspective lucide de l'article est utile précisément parce qu'elle supprime les attentes excessives : il n'y a pas besoin d'attribuer des capacités surhumaines à un modèle de langage, mais il ne faut pas non plus le sous-estimer en tant qu'interface et coordinateur d'autres outils.