ML vs LLM : 5 erreurs qui font dérailler les LLM — et comment l’utilisation d’outils ML y remédie

TL;DR

• Votre LLM peut désormais exécuter Python, donc il peut effectuer des calculs. Il ne peut cependant toujours pas apprendre un modèle capable de généraliser, de conserver un état par flux ou d'évaluer un flux en direct. Le calcul n'a jamais été le plus difficile.
• Les modèles d'apprentissage automatique sont précis pour des tâches numériques spécifiques, mais inutiles pour décider quoi faire du résultat.
• Un agent d'IA performant a besoin des deux. Ci-dessous : une matrice de décision et cinq invites qui provoquent une erreur dans un modèle linéaire généralisé (LLM), chacune accompagnée de l'appel d'outil d'apprentissage automatique permettant de la corriger.

Pourquoi les équipes continuent-elles de chercher le mauvais outil ?

La question de l'utilisation du ML par rapport au LLM revient très fréquemment dans le domaine de l'IA appliquée, et neuf fois sur dix, le problème ne vient pas des données. Il vient plutôt du fait qu'une équipe a appliqué un LLM à une tâche qui nécessite du ML, ou a créé un dashboard uniquement sur le ML qui avait besoin d'un LLM pour être exploitable.

C'est un piège facile. Les démonstrations de LLM sont impressionnantes : on décrit un problème en termes simples, et on obtient un résultat cohérent. L'étape suivante consiste donc naturellement à intégrer des données de capteurs à ce même modèle et à lui demander de prévoir la charge du lendemain, de signaler une pompe défaillante ou de classer les machines par ordre de risque. Cela fonctionne à merveille… dans la démonstration. Puis arrive la production, avec son lot d'erreurs, de lacunes et de dérives, et les réponses, jusque-là rassurantes, se révèlent fausses.

L'échec inverse est tout aussi fréquent, mais plus discret : des scores d'apprentissage automatique précis qui restent lettre morte sur un dashboard que personne ne consulte. Le travail intéressant se situe à la frontière entre les deux, et c'est précisément là que les objections fusent

Attendez… les titulaires d’un LLM ne peuvent plus exécuter Python maintenant ?

Question pertinente. Il y a deux ans, la réponse à la question « Pourquoi ne pas simplement demander au LLM ? » était : « Il ne peut pas faire les calculs. » Cette réponse est désormais erronée – et si cet article s’y appuyait encore, un ingénieur avisé fermerait l’onglet. Soyons donc précis sur ce qui a changé et ce qui est resté le même.

Dans une fenêtre de discussion, oui. L'outil d'analyse avancée de ChatGPT et l'outil d'analyse de Claude exécutent tous deux du code Python dans un environnement isolé. Mais cet environnement isolé fait partie du produit qui entoure le modèle, et non du modèle lui-même.

Via l'API, uniquement si vous la configurez. L'API est la couche IoT sur laquelle reposent la quasi-totalité des agents et plateformes d'outils et qui vous renvoie un conteneur provisionné (environ$d'Anthropic d'exécution de code sur l'API Messages est en version bêta et désactivé par défaut. Appelez le point de terminaison brut avec une invite de commande pour obtenir des jetons, mais pas d'exécution de code.

Au sein d'un agent de production, son fonctionnement est de toute façon inadapté. Même activé, il ne s'agit que d'un environnement de test éphémère : il est lancé, renvoie un résultat, puis est arrêté. C'est un outil de calcul, pas un lieu pour entraîner un modèle, établir des valeurs de référence par capteur ou observer un flux en direct. De plus, il fonctionne à l'aveugle : le code est réécrit à chaque appel, importe ce qui se trouve dans l'image de l'environnement de test et, à moins de mettre en place l'infrastructure nécessaire pour le capturer, s'exécute sans trace vérifiable ni reproductible. Pour un numéro qui dépêche un technicien ou déclenche une alarme de sécurité, l'affirmation « le master a écrit du code Python que nous n'avons jamais examiné » est à elle seule disqualifiante.

La règle honnête n'est donc pas « les LLM ne peuvent pas calculer ». C'est plutôt ceci : l'exécution de code permet à un LLM de calculer ; elle ne lui permet pas d'apprendre un modèle généralisable, de conserver un état sur des centaines de flux, ni d'évaluer un flux en temps réel. Voilà la limite – et c'est précisément cette limite que franchissent les cinq invites ci-dessous.

La véritable ligne de démarcation : calculer contre apprendre

L'apprentissage automatique (ML) permet d'acquérir un modèle généralisable ; le modèle linguistique (LLM) raisonne sur le résultat en utilisant le langage naturel. L'exécution de code permet au LLM de calculer, mais pas d'apprendre.

L'apprentissage automatique (ML) sert à l'inférence, le modèle linéaire mixte (LLM) au raisonnement.

Le ML est l'outil idéal lorsqu'il s'agit de déterminer la valeur d'un chiffre : une prévision, un score d'anomalie, une estimation de la durée de vie restante ou une étiquette de classe. Le LLM est l'outil idéal lorsqu'il s'agit de déterminer les actions à entreprendre face à ce chiffre : l'expliquer, le hiérarchiser, rédiger le message, décider de la prochaine étape et utiliser l'outil approprié.

Trois vérifications rapides de bon sens :

• Un modèle linéaire peut-il prévoir une série temporelle ? Parfois, mais mal. Pas pour les charges de travail en production où une erreur coûte cher.
• Un modèle d'apprentissage automatique peut-il créer un ticket de maintenance ? Non. Il renvoie un numéro. Interpréter ce numéro dans son contexte relève du langage.
• Ai-je besoin des deux ? Pour tout flux de travail impliquant une intervention humaine, oui.

La matrice de décision

Voici le tableau comparatif ML vs LLM que nous redessinons sans cesse sur les tableaux blancs pour les projets IoT et industriels : quand utiliser machine learningtraditionnel, quand utiliser un LLM et quand utiliser les deux. À mettre de côté.

Si votre tâche correspond à une ligne de la colonne de gauche et que vous cherchez le mauvais outil dans la colonne du milieu, cet article est pour vous.

Cinq exemples qui mettent à mal les LLM

Chaque exemple suit la même structure : l’invite qui plante — pourquoi l’exécution de Python ne la sauvegarde pas — le travail de ML (avec un schéma de code) — le transfert que l’opérateur voit réellement.

4.1 Détection d'anomalies — vibrations sur un moteur de pompe (fabrication)

La question est : cette pompe est-elle sur le point de tomber en panne ?

Fournissez les données brutes à un modèle linéaire à longue portée (LLM) et il calculera les moyennes, les valeurs maximales et un écart type. Mais « sur le point de tomber en panne » ne correspond pas à un calcul : il s’agit d’un écart par rapport à un appris du fonctionnement normal de cette pompe, et le LLM n’a jamais observé cette pompe.

Le rôle de l'apprentissage automatique : entraîner un modèle d'apprentissage automatique (une forêt d'isolation) sur 90 jours de données « normales » de vibrations RMS et de température des roulements. Analyser les nouvelles mesures en temps réel.

from sklearn.ensemble import IsolationForest import numpy as np # X_normal : forme (n_samples, 2) — [vibration_rms, bearing_temp] clf = IsolationForest(contamination=0.01, random_state=42) clf.fit(X_normal) # Les scores négatifs indiquent une plus grande anomalie. Un seuil de -0,1 convient à la plupart des capteurs industriels. scores = clf.score_samples(X_today) anomalies = X_today[scores < -0.1]

Le modèle renvoie un score par minute. Il n'a pas d'avis sur la manière de l'utiliser.

Rôle du LLM. Lorsqu'un score dépasse le seuil, le LLM consulte l'historique des ordres de travail de cet équipement, vérifie la date de la dernière intervention, interroge l'inventaire des pièces et rédige un message à l'attention du responsable de la maintenance.

Le transfert que l'opérateur observe :

« La pompe P-103 a franchi son seuil d'anomalie à 02h14. La dernière révision des roulements remonte à 7 mois, soit un retard par rapport au plan de maintenance semestriel. Aucun kit de roulements de rechange n'est disponible sur site. Il est recommandé d'envoyer un technicien ce matin avant le démarrage. »

Le modèle d'apprentissage automatique a produit un résultat numérique. Le modèle d'apprentissage automatique l'a transformé en décision. Ce processus est au cœur de ce qui rend dans l'industrie manufacturière réellement utiles sur le terrain.

4.2 Prévision — demande énergétique dans un bâtiment (CVC / installations)

La question posée est : « Quelle sera la consommation énergétique de ce bâtiment demain ? » Un modèle linéaire mixte (LLM) exécuté en ligne de commande effectuera une régression rapide sur les données que vous lui fournirez et vous fournira une estimation précise et fiable, sans tenir compte de la consommation de référence de votre bâtiment. Il s'agit d'une reconnaissance de formes ,et non d'une prévision. Ce n'est pas une simple spéculation : une étude publiée dans NeurIPS en 2024 a démontré que le fait de supprimer le LLM des méthodes de prévision courantes basées sur ce modèle n'altérait pas la précision et l'améliorait même souvent.

Le travail du ML consiste à intégrer les variables de décalage (heure, jour de la semaine, décalage à 1 jour, décalage à 7 jours, prévision de température) dans un régresseur XGBoost — ou Prophet si la maintenance doit être assurée par un ingénieur non spécialisé en ML.

import xgboost as xgb from sklearn.model_selection import train_test_split # features: hour, dow, lag_1d, lag_7d, temp_forecast X_train, X_test, y_train, y_test = train_test_split(features, target, test_size=0.2) model = xgb.XGBRegressor(n_estimators=200, learning_rate=0.05) model.fit(X_train, y_train) tomorrow_forecast = model.predict(tomorrow_features)

Le transfert de responsabilité. Le LLM transforme le chiffre en instruction : « Demain, la température sera 14 % supérieure à celle d’un mercredi normal, probablement en raison de la vague de chaleur annoncée. Pré-refroidissez le bâtiment entre 3 h et 5 h du matin afin de décaler la consommation en heures creuses et d’éviter la surtaxe liée à la demande. »

4.3 Maintenance prédictive — durée de vie utile restante (logistique / mobilité)

La question posée est la suivante : « Quels camions nécessitent un remplacement d’alternateur dans les 30 prochains jours ? » Il s’agit d’un modèle de survie basé sur des pannes historiques et des signaux de dégradation actuels (dérive de tension, fréquence de redémarrage, exposition à la chaleur), classant des actifs qu’il n’a jamais observés. Un modèle de gestion de l’énergie (LLM) ne peut pas extrapoler ces données.

from lifelines import CoxPHFitter import pandas as pd # df : une ligne par actif, colonnes = signaux de dégradation + 'duration' + 'événement' (1 = échec) cph = CoxPHFitter() cph.fit(df, duration_col='duration', event_col='event') risk_scores = cph.predict_partial_hazard(current_fleet_signals) ranked_fleet = current_fleet_signals.assign(risk=risk_scores).sort_values('risk', ascending=False)

Le transfert des responsabilités. Le responsable de la maintenance prédictive (LLM) compare les résultats du modèle au contexte opérationnel de la semaine (itinéraires critiques, entrepôts disposant de la pièce, personnel de service) et établit les cinq ordres de travail prioritaires. C'est le principe de base de IoT : la liste de classement seule est ignorée ; seule la justification déclenche l'action.

4.4 Classification — alarmes de qualité de l'eau (services publics / environnement)

La question posée est la suivante : « Cette combinaison de pH/turbidité/conductivité correspond-elle à une alarme réelle ou à un bruit de capteur ? » La plupart des systèmes de surveillance des infrastructures d'eau utilisent encore des seuils fixes qui déclenchent des valeurs trois à cinq fois supérieures aux seuils normaux. Un classificateur entraîné sur environ 10 000 relevés étiquetés réduit de plus de moitié les faux positifs. Demander à un technicien de laboratoire d'étiqueter manuellement les 50 000 relevés quotidiens n'est pas fiable d'une analyse à l'autre et coûte beaucoup plus cher qu'un traitement par lots effectué en quelques millisecondes.

from xgboost import XGBClassifier # X: [pH, turbidité, conductivité, heure_de_la_journée, âge_du_capteur_jours] # y: 1 = alarme réelle, 0 = bruit clf = XGBClassifier(n_estimators=100, use_label_encoder=False, eval_metric='logloss') clf.fit(X_train, y_train) p_alarm = clf.predict_proba(X_today)[:, 1]

Le transfert. Lorsque P(alarme) > 0,7, le LLM récupère le contexte en amont (précipitations récentes, maintenance à proximité, capteurs voisins) et décide : envoyer un échantillon sur le terrain, ouvrir un ticket ou fermer automatiquement comme bruit.

4.5 Texte libre → structuré — notes de quart du technicien (celle où LLM l'emporte haut la main)

La question est la suivante : parmi des milliers de notes techniques non structurées rédigées sur une période de deux ans, qu'est-ce qui ressort réellement ?

Voici pourquoi l'apprentissage automatique est inefficace dans ce cas : il faudrait un ensemble d'entraînement étiqueté, ce qui n'est pas le cas, et les catégories évoluent avec le temps, à mesure que le matériel vieillit et que de nouveaux modes de défaillance apparaissent. Un classificateur supervisé entraîné il y a six mois ne pourra pas détecter le nouveau mode de défaillance apparu au dernier trimestre.

Travail de LLM. Classification à partir d'un nombre limité d'exemples dans une liste de catégories stables — « panne électrique », « usure mécanique », « perte de communication », « erreur utilisateur », « indéterminé » — ainsi qu'extraction de l'identifiant de l'actif, de la gravité et des pièces mentionnées.

import anthropic client = anthropic.Anthropic() def parse_note(note_text: str) -> dict: response = client.messages.create( model="claude-sonnet-4-6", max_tokens=256, messages=[{ "role": "user", "content": f"""Classifiez cette note de technicien. Retournez uniquement du JSON. Note : {note_text} Schéma : {{ "category": "electrical_fault|mechanical_wear|comms_loss|user_error|unclear", "severity": "low|medium|high", "asset_id": "string or null", "parts_mentioned": ["list of strings"] }}""" }] ) import json return json.loads(response.content[0].text)

Pas de données d'entraînement. Pas de sprint d'étiquetage. Livraison cette semaine.

Le processus s'effectue ici en sens inverse. Le LLM produit les champs structurés → une requête SQL simple (ou un modèle ML, si le nombre de lignes est suffisant) les agrège dans un diagramme de Pareto des catégories de défauts par site, par classe d'actifs et par trimestre.

Vérification d'honnêteté : si vous disposez déjà de 100 000 notes étiquetées et d'une taxonomie de catégories stable, affinez un petit modèle ; ce sera plus rapide et moins coûteux par appel. Dans le cas contraire, le LLM est sans conteste le point de départ idéal.

Deux autres qui se cassent — pour une raison différente

« Parmi mes 400 capteurs, lesquels présentent un comportement anormal actuellement ? » Le problème n'est pas le calcul, (400 et instantanément. Un modèle linéaire à grande échelle (LLM) ne permet pas de conserver une valeur de référence en temps réel pour chaque capteur, pour 400 flux de données, et d'évaluer chaque nouvelle mesure par rapport à cette valeur de référence. Il s'agit d'un état persistant, et le LLM n'en dispose pas.

« M’avertir dès que cette lecture s’écarte de la normale. » Un LLM fonctionne selon le principe requête-réponse. Il ne peut pas surveiller un flux MQTT et analyser chaque paquet à la milliseconde près lorsqu’un seuil est atteint. Ce n’est pas une question de difficulté technique, c’est une impossibilité architecturale : aucune quantité de code ne changera cela.

Le modèle d'architecture

Au final, le diagramme est identique quelle que soit la verticale :

Le LLM est l'orchestrateur. Les modèles d'apprentissage automatique sont des outils. La base de données l'est aussi. Slack également. Traitez-les tous de la même manière — comme des outils appelables par le LLM — et l'architecture restera simple quel que soit le nombre de modèles ou de sources de données ajoutés. C'est la même architecture qui est au cœur des basés sur le cloud SCADA et Industrie 4.0 ; la différence réside dans le fait que la couche de raisonnement est désormais un LLM au lieu d'un moteur de règles.

Ce diagramme met en évidence un point essentiel : le modèle linéaire généralisé (LLM) ne manipule jamais les données brutes. Il travaille sur des agrégats, des scores et des résumés produits par les outils d’apprentissage automatique et d’analyse de données. C’est un choix délibéré. ​​Un LLM qui raisonne sur un résumé de 50 lignes est rapide, économique et fiable. En revanche, un LLM qui traite 50 000 lignes brutes — même avec son propre script Python — est lent, coûteux et sans état : il recalcule tout à chaque appel au lieu d’interroger un modèle ayant déjà appris la structure.

Anti-motifs

1. Demander au LLM d'écrire du SQL sur de grandes tables. Le LLM maîtrise parfaitement le SQL. Le problème réside dans l'exécution d'une requête complexe sur 25 000 lignes et le retour de l'ensemble des résultats dans la fenêtre de contexte : une opération lente, coûteuse et sujette aux erreurs. Il est préférable de commencer par agréger les données à l'aide d'un outil de « vue préparée » qui réduit les données brutes aux 50 lignes pertinentes, puis de laisser le LLM analyser le résumé.

2. Intégrer les règles métier au modèle d'apprentissage automatique. Si le modèle est entraîné à signaler une lecture comme une alarme en fonction de vos seuils SLA actuels, chaque modification de seuil nécessite un réentraînement. Il est préférable de conserver les règles métier dans la couche d'invite LLM, où toute modification se fait en une seule ligne, sans cycle de réentraînement.

3. Utiliser une démo comme preuve de concept. La démo fonctionnait correctement sur 10 points dans un notebook. En production, il y a 10 000 points, des horodatages manquants, des lectures en double et des capteurs qui tombent en panne pendant trois jours et renvoient des valeurs obsolètes. Un pipeline entraîné gère ces situations ; une invite, même avec un environnement de test isolé, ne le fait pas, car elle n’a jamais appris à reconnaître un signal correct.

FAQ

Les LLM ne peuvent-ils pas simplement exécuter du Python ? Alors pourquoi aurais-je besoin de ML ?
L'exécution de code corrige le calcul, pas l'apprentissage. Et généralement, cette fonctionnalité est même inexploitée : via l'API, il s'agit d'une option que la plupart des plateformes d'agents n'intègrent jamais. Même lorsqu'elle est présente, elle reste un environnement de test éphémère : elle ne peut pas entraîner un modèle généralisable, conserver un état par flux, ni évaluer en temps réel. De plus, son code, nouveau, non figé et non déterministe, n'est pas auditable comme l'est un code de production. Un LLM peut effectuer des calculs sur les données que vous lui fournissez ; il ne peut pas constituer le modèle.

Quand un agent d'IA devrait-il utiliser l'apprentissage automatique plutôt qu'un modèle linéaire ?
Dès que la tâche consiste à « produire un nombre ». La prévision, la détection d'anomalies, la classification et l'estimation de la durée de vie restante sont autant de tâches relevant de l'apprentissage automatique. Un modèle linéaire, même avec un environnement de test, peut calculer une valeur ponctuelle, mais il ne peut pas constituer le modèle : il est incapable d'apprendre un schéma généralisable, de conserver un état ou de s'exécuter en temps réel.

Un modèle linéaire mixte (LLM) peut-il effectuer des prévisions de séries temporelles ?
Dans une certaine mesure, oui : pour des horizons très courts et des tendances simples, un LLM utilisant un outil de prévision statistique peut donner l'impression de réaliser des prévisions. Mais il ne fait pas la prévision ; il se contente d'appeler l'outil. Demander à un LLM brut d'extrapoler une séquence numérique à partir de son contexte produira des résultats qui semblent convaincants, mais statistiquement erronés. À éviter absolument en production.

Un modèle d'apprentissage automatique peut-il détecter les anomalies ?
Pas de manière fiable. La détection d'anomalies nécessite un modèle appris du comportement « normal », construit à partir de données historiques : une distribution, une valeur de référence et un seuil calibré pour votre équipement spécifique. Un modèle d'apprentissage automatique ne possède pas un tel modèle. Il peut interpréter un score d'anomalie une fois qu'un modèle d'apprentissage automatique l'a calculé.

Quelle est la différence entre un agent d'IA et un machine learning ?
Un modèle d'apprentissage automatique est une fonction : il reçoit des données structurées et renvoie un nombre ou une étiquette. Un agent d'IA est un orchestrateur : il prend un objectif en compte, décide des outils à utiliser (modèles d'apprentissage automatique, bases de données, API, services de messagerie, etc.), interprète les résultats et agit en conséquence. Un agent sans outils d'apprentissage automatique est un chatbot. Un modèle d'apprentissage automatique sans agent est un dashboard que personne ne consulte.

Faut-il réentraîner son modèle d'apprentissage automatique lorsque les règles métier changent ?
Non, et c'est là l'un des avantages les plus sous-estimés de l'architecture à deux couches. Conservez les règles métier (seuils, SLA, logique d'escalade, politiques spécifiques au client) dans la couche d'invite LLM. Il s'agit de texte brut ; les modifier ne prend que quelques secondes. Réservez le réentraînement aux changements de la distribution du signal sous-jacent : nouveaux équipements, nouveaux modes de défaillance, nouvelles conditions d'exploitation.

Le fine-tuning d'un modèle de langage (LLM) peut-il remplacer un modèle d'apprentissage automatique pour les tâches numériques ?
Presque jamais. Le fine-tuning apprend au LLM à produire un texte ressemblant à la sortie numérique attendue, mais ne lui apprend pas à effectuer des calculs. Pour les charges de travail en production où la précision numérique est cruciale (prévision, détection d'anomalies, classification), un modèle scikit-learn bien paramétré sur des données propres sera plus performant, plus rapide, moins coûteux et plus facile à auditer.

Encore une chose

Ce modèle – l'IA dans IoT parfaitement maîtrisée – est omniprésent dans nos développements chez Ubidots. Notre solution d'agents IA coordonne les processus LLM, tandis UbiFunctionqu'UbiFunctions permet d'intégrer votre propre code Python (scikit-learn, XGBoost, pvlib, votre modèle pré-entraîné) sous forme d'outil. L'architecture reste identique à celle du schéma ci-dessus ; nous vous fournissons simplement l'environnement d'exécution et les données des capteurs déjà configurés – un environnement persistant et auditable, contrairement à un bac à sable LLM éphémère.