Les agents IA devraient appeler des modèles

L’article MLAT décrit un pilote en production où un agent appelle un modèle de tarification XGBoost comme outil, atteint R^2 = 0,807 sur des données mises de côté, signale une erreur absolue moyenne de 3 688 USD et réduit la génération de propositions de plusieurs heures à moins de 10 minutes.¹

L’idée utile n’est pas le modèle de tarification exact. L’idée utile, c’est la frontière : lorsqu’une tâche exige un score, une prévision, un prix, une estimation de risque, un classement, un classificateur ou un détecteur, l’agent doit appeler le modèle entraîné pour cette tâche. Il ne doit pas improviser une réponse statistique dans une prose fluide.

Un modèle entraîné a sa place dans le registre d’outils de l’agent. Le LLM peut décider quand l’appeler, expliquer le résultat, demander les entrées manquantes et gérer les exceptions. Le modèle ajusté doit produire l’estimation numérique, le signal de confiance, la sortie versionnée et la piste de preuves.

TL;DR

Les agents LLM sont efficaces pour l’orchestration. Les modèles statistiques et de machine learning sont souvent meilleurs pour les prédictions bornées. Le schéma Machine Learning as a Tool traite un modèle ML ajusté comme un outil appelable dans un flux de travail d’agent, aux côtés de la recherche, des bases de données, des API et d’autres outils.¹

Ce schéma donne aux équipes une règle d’exploitation nette : laissez l’agent coordonner le travail, mais confiez l’inférence spécialisée aux modèles spécialisés. Le résultat doit inclure la version du modèle, le schéma d’entrée, le schéma de sortie, les notes de calibration et un enregistrement d’appel traçable. Sans cette frontière, le LLM peut paraître sûr de lui tout en remplaçant silencieusement un modèle par une supposition.

Points clés

• Pour les équipes qui construisent des agents : exposez les modèles entraînés comme des outils typés, avec schémas, versions et modes de défaillance.
• Pour les équipes ML : traitez l’agent comme un appelant, non comme un remplaçant de l’évaluation, de la persistance ou de la discipline de registre des modèles.
• Pour les équipes produit : indiquez si un nombre vient d’un appel de modèle, d’une règle, d’une base de données ou d’une explication du LLM.
• Pour les équipes sécurité : appliquez aux outils de modèle la même logique d’autorité limitée que dans Les clés d’agent ont besoin de budgets de risque.
• Pour les relecteurs : exigez l’appel de modèle, la version du modèle, les entrées, la sortie et les limites de confiance avant de croire la réponse.

Pourquoi les agents devraient-ils appeler des modèles plutôt que les imiter ?

Un LLM peut parler d’un prix. Un modèle de tarification peut l’estimer à partir des variables qu’il a apprises. Un LLM peut résumer un risque. Un modèle de risque peut calculer un score à partir d’un ensemble de variables testé. Un LLM peut décrire l’attrition client. Un modèle d’attrition peut renvoyer une probabilité liée à un processus d’entraînement.

Ce sont des tâches différentes.

Les outils d’agent permettent déjà cette séparation. La documentation OpenAI Agents SDK décrit des outils de fonction avec des paramètres JSON Schema, des gestionnaires d’invocation d’outils et des sorties d’outils structurées.² La documentation d’Anthropic sur l’utilisation d’outils décrit Claude appelant des outils côté client et des fonctions externes avec des entrées définies par JSON Schema.³ L’agent peut demander une prédiction de modèle avec le même schéma d’outil que celui qu’il utilise pour la recherche, les mises à jour de calendrier, les commandes shell ou les requêtes de base de données.

Le principal mode de défaillance apparaît lorsque les équipes négligent cette séparation. Elles demandent une estimation au LLM parce que le LLM peut en produire une. La réponse arrive vite. La prose semble raisonnable. L’interface ne donne aucun indice visible montrant que le nombre vient d’une complétion de motif plutôt que d’un estimateur ajusté.

C’est un contrat faible. L’utilisateur ne sait pas ce qui a produit le résultat. Le relecteur ne peut pas inspecter la version du modèle ni les variables d’entrée. L’opérateur ne peut pas rejouer l’appel. Le produit ne peut pas expliquer pourquoi la réponse a changé.

Le seuil de preuve s’applique ici : la confiance n’est pas une preuve. Un appel de modèle peut produire une preuve. Une supposition en prose, généralement non.

Qu’apporte le schéma MLAT ?

MLAT signifie Machine Learning as a Tool. L’article présente un modèle ML entraîné comme un outil de premier rang qu’un agent LLM peut invoquer lorsque la conversation exige une estimation quantitative.¹

Le système pilote de l’article, PitchCraft, utilise deux agents. Un agent de recherche rassemble le contexte du prospect au moyen d’appels d’outils parallèles. Un agent de rédaction appelle un modèle de tarification XGBoost, puis rédige une proposition au moyen de sorties structurées.¹ Le modèle ML gère la tarification. Le LLM gère le contexte, l’assemblage et l’explication.

Cette séparation compte, car elle évite deux mauvaises conceptions :

L’agent reste important. Il peut détecter qu’une entrée de tarification est incomplète. Il peut demander à l’utilisateur les champs manquants. Il peut appeler des outils de recherche ou de CRM avant d’invoquer le modèle. Il peut expliquer que l’estimation vient d’un modèle, et non de sa propre autorité.

Voilà la bonne division du travail : le LLM orchestre ; le modèle ajusté prédit.

Que doit renvoyer un outil de modèle ?

Un outil de modèle ne doit pas renvoyer un nombre nu. Un outil sérieux doit renvoyer un objet de preuve.

Cette forme de sortie rend les outils de modèle compatibles avec Les traces d’exécution d’agent sont le contrat d’exécution. Si un agent appelle un modèle de tarification, la trace doit montrer l’appel du modèle. Si un agent ignore le modèle et écrit tout de même un nombre, la trace doit rendre cette absence évidente.

La même logique soutient Les dossiers de relecture sont la nouvelle réponse finale. Une réponse finale avec un prix est faible. Une réponse finale avec un enregistrement d’appel de modèle, la version du modèle, un instantané des variables et une note de confiance donne au relecteur quelque chose à inspecter.

Où les registres de modèles s’insèrent-ils ?

L’encapsulation en outil ne remplace pas le MLOps. Elle expose le MLOps à l’environnement d’exécution de l’agent.

La documentation du registre de modèles MLflow décrit la lignée, le versionnement, les alias, les balises de métadonnées et les informations de cycle de vie des modèles.⁴ Cette couche de registre compte, car un flux de travail d’agent ne peut citer une version de modèle que si la plateforme suit d’abord les versions.

La documentation scikit-learn sur la persistance des modèles formule un point voisin côté service : les choix de persistance impliquent des compromis de sécurité et de portabilité, et ONNX peut servir des modèles sans environnement Python, tandis que les chemins fondés sur pickle exigent de faire confiance à la source.⁵ Un outil de modèle ne doit pas faire entrer en douce un artefact de modèle dangereux dans un agent simplement parce que l’agent a demandé une prédiction.

La pile minimale d’exploitation ressemble à ceci :

Les équipes fusionnent souvent ces couches dans un seul point de terminaison appelé predict. Ce raccourci fonctionne pour les démos. Il échoue lorsque l’agent commence à enchaîner des prédictions dans des e-mails client, des propositions commerciales, des notes de souscription, des plans d’infrastructure ou des brouillons de triage médical.

Le produit a besoin d’un contrat de modèle, pas d’un point de terminaison magique.

Comment les produits devraient-ils afficher les sorties de modèle ?

L’UI doit dire à l’utilisateur quand une réponse vient d’un outil de modèle.

Une mauvaise copie d’interface masque la provenance :

Une meilleure copie nomme le chemin de production :

Cette distinction protège la dignité de l’utilisateur. Les utilisateurs ne devraient pas avoir à deviner si un nombre vient d’un modèle testé, d’une fiche de modèle, d’une règle métier ou d’une complétion par modèle de langage. Le design agentique est un design de surface de contrôle soutient que les produits agentiques ont besoin de surfaces de supervision et de contrôle. La provenance des modèles en fait partie.

Les fiches de modèle aident à traiter le même problème au niveau de la documentation. L’article Model Cards propose un reporting structuré sur les caractéristiques du modèle, son usage prévu, ses métriques et son contexte d’évaluation.⁶ Les interfaces agentiques peuvent emprunter cette idée au moment de l’exécution : chaque réponse de modèle doit porter assez de contexte pour qu’un utilisateur ou un relecteur comprenne quel type d’affirmation le modèle a produit.

Que les agents devraient-ils refuser ?

Un agent conscient des modèles doit refuser plusieurs raccourcis tentants.

Il doit refuser d’inventer une sortie de modèle lorsque l’outil de modèle est indisponible. Il peut dire que le modèle de tarification a échoué. Il peut demander si l’utilisateur souhaite une estimation approximative étiquetée comme humaine. Il ne doit pas remplacer silencieusement le modèle.

Il doit refuser d’élargir le domaine du modèle sans preuve. Un modèle d’attrition entraîné sur des données SaaS mid-market ne doit pas devenir un oracle universel de santé d’entreprise parce que le prompt le demande poliment.

Il doit refuser de masquer l’incertitude. Si un modèle renvoie un intervalle, la réponse ne doit pas le réduire à un seul nombre assuré, sauf si le produit dispose d’une règle d’affichage claire.

Il doit refuser d’appeler un outil de modèle avec des variables manquantes ou fabriquées. L’agent peut collecter les entrées, poser des questions de suivi ou marquer des champs comme inconnus. Il ne doit pas remplir le vecteur de variables avec une fiction commode.

Il doit refuser de traiter l’autorité du modèle comme une autorité d’action. Un modèle peut estimer un risque de fraude. Cela ne signifie pas que l’agent peut geler un compte. L’action exige toujours la discipline de clés à portée limitée décrite dans Les clés d’agent ont besoin de budgets de risque.

La règle de décision

Utilisez cette règle lorsque vous construisez un flux de travail d’agent :

Cette règle donne au LLM un rôle précieux sans l’autoriser à imiter tous les autres systèmes. Il peut coordonner le flux de travail, expliquer les sorties, rédiger le message et poser de meilleures questions. Il ne peut pas devenir le modèle de tarification, le modèle de risque, le modèle de fraude, le modèle de classement ou le moteur de règles simplement parce qu’il s’exprime avec aisance.

Les meilleurs produits agentiques ne demanderont pas à un seul modèle de faire semblant d’être toute l’entreprise. Ils construiront une surface d’outils où chaque système accomplit la tâche qu’il peut prouver.

FAQ

Est-ce seulement pour les modèles traditionnels de machine learning ?

Non. Le même schéma s’applique à tout estimateur ou système de score spécialisé : modèles de gradient boosting, classificateurs, systèmes de classement, modèles de prévision, moteurs de règles, systèmes de score pour la recherche d’information et détecteurs propres à un domaine. L’algorithme n’est pas le sujet. Le sujet, c’est le contrat autour de la sortie.

Pourquoi ne pas laisser le LLM estimer directement ?

Une estimation qualitative approximative suffit parfois. Un produit doit alors le dire clairement. Lorsque l’utilisateur a besoin d’un prix, d’un score de risque, d’une prévision ou d’une décision d’éligibilité, la réponse doit venir d’un modèle testé ou d’un chemin de règle avec des entrées et des limites traçables.

Un outil de modèle rend-il automatiquement la réponse correcte ?

Non. Un outil de modèle peut tout de même être obsolète, biaisé, mal calibré, mal utilisé ou hors de son domaine valide. L’outil de modèle facilite l’inspection. Il ne supprime pas le besoin d’évaluation, de surveillance et de relecture humaine.

Quel est le contrat minimal viable pour un outil de modèle ?

Commencez par le schéma d’entrée, le schéma de sortie, la version du modèle, la prédiction, la confiance ou la réserve, la forme d’erreur, le délai d’expiration et l’ID de trace. Ajoutez les noms de variables, le lien vers le registre, la référence à la fiche de modèle et les notes de calibration lorsque le modèle affecte l’argent, l’accès, la sécurité ou des décisions visibles par les clients.

En quoi cela change-t-il l’UX agentique ?

L’interface doit étiqueter la source des sorties importantes. Les utilisateurs doivent voir si une réponse vient d’un appel de modèle, d’un document récupéré, d’une règle métier, d’une approbation humaine ou d’une synthèse du LLM. Cette provenance change le niveau de confiance que la réponse mérite.

Références