Utiliser le ML classique pour responsabiliser les agents IA

Je fais ces journées au travail, j’ai l’impression qu’ils sont parfois surpris quand je dis « construire des classificateurs CatBoost » ou « installer des forêts d’isolement ». Mais c’est en fait ce à quoi je passe une bonne partie de mon temps. Le produit de mon entreprise est une plate-forme d’IA agentique sophistiquée, mais je ne fais pas beaucoup d’ingénierie rapide au quotidien.

Si vous me l’aviez demandé il y a un an ou deux, j’aurais été sérieusement préoccupé par l’avenir du travail de ML classique dans le domaine de l’apprentissage automatique, car nous nous enfoncions tellement dans un paradigme d’utilisation des LLM pour gérer les choses, qu’ils fassent du bon travail ou non. Cependant, il s’avère que L’IA agentique a bien plus besoin du ML classique que nous ne le pensions probablement.

Pour un bref récapitulatif au cas où les lecteurs ne seraient pas familiers :

Un agent IA signifie combiner des LLM et d’autres outils logiciels pour créer des flux de travail avec une intervention humaine minimale ou nulle, en orchestrant un nombre quelconque de modèles ou d’outils.
Le LLM constitue généralement l’interface entre les utilisateurs humains et tous les autres outils logiciels, y compris des tâches telles que la traduction d’invites humaines en langage informatique. Le LLM interprète également les sorties des outils et choisit les outils à appeler aux moments appropriés.
Cela permet beaucoup plus de fonctionnalités qu’un LLM en lui-même, car comme je l’ai mentionné ici à plusieurs reprises, un LLM n’est qu’un modèle générateur de jetons, prédisant le mot ou la phrase suivante dans un passage en fonction de son contexte.
Outre les agents autonomes, la combinaison d’une interface LLM avec d’autres outils est nécessaire pour effectuer un grand nombre de choses que nous pensons familièrement aux chatbots LLM. ChatGPT, Gemini et Claude font ce genre de choses, enchaînant l’interface LLM avec des éléments tels que la récupération de données, la recherche sur le Web, les calculatrices mathématiques, etc.

Comme vous pouvez le constater, un aspect clé de l’ensemble de l’écosystème de l’IA agentique est l’outillage : votre agent doit avoir accès à des outils afin d’accomplir efficacement des tâches en dehors des fonctions principales du LLM.

Ces outils peuvent prendre toutes sortes de formes : la plupart d’entre eux aujourd’hui dans le contexte professionnel sont des outils de récupération et d’organisation de données, des bases de données graphiques, des bases de connaissances RAG, la construction et la validation de requêtes, etc.

Pourquoi le ML classique

Cependant, je tiens à vous rappeler que les modèles ML classiques peuvent également être des outils très précieux pour votre agent. Allez plus loin que de simplement appeler des outils rudimentaires et donnez à vos modèles d’agents IA à utiliser ! Par exemple, considérons un agent conçu pour l’analyse immobilière. Si vous souhaitez connaître le prix de marché approprié pour une propriété, donnez l’adresse à votre agent. Il peut utiliser un outil de récupération API pour récupérer des détails sur la propriété, puis transmettre ces détails formatés à un modèle de régression qui génère une estimation de prix.

Bien sûr, vous pouvez théoriquement demander au LLM de simplement estimer lui-même les valeurs. Cependant, cela est discutable, voire risqué, pour plusieurs raisons.

Précision: Un LLM est particulièrement mauvais pour toute tâche où vous devez calculer un nombre significatif – il s’agit de deviner, pas de faire un calcul basé sur des preuves empiriques. Un modèle ML classique bien entraîné sera beaucoup plus précis et digne de confiance.
Interprétabilité: Vous avez une interprétabilité et une explicabilité minimales de la supposition du LLM. Nous savons que les LLM ont tendance à être une boîte noire, ce qui restreint considérablement votre capacité à évaluer le chemin qu’il a fallu pour arriver à l’estimation que vous avez reçue. Avec un modèle ML classique, vous pouvez identifier les décisions prises pour arriver à votre inférence et les valider par rapport à votre expertise en la matière.
Coût: Exécuter un LLM coûte très vite cher (voir mes articles des derniers mois sur les coûts des jetons). Si vous avez de nombreux cas sur lesquels travailler, les prix des jetons deviendront rapidement significatifs. L’exécution d’un classificateur ou d’un modèle de régression est incroyablement légère et peu coûteuse, même à des volumes élevés. De plus, dans un LLM, vous ne contrôlez pas le coût de chaque appel, et l’utilisation et les dépenses des jetons peuvent augmenter – nous le constatons déjà dans le secteur technologique.
Précision: Vous ne contrôlez pas la formation ou le réglage du LLM (sauf si vous peaufinez un modèle de base). Vous pouvez faire confiance au LLM générique pour faire le travail, mais vous prenez un gros risque et, comme mentionné ci-dessus, valider le travail est extrêmement difficile. D’un autre côté, peaufiner un modèle de base pourrait être efficace, mais cela nécessite beaucoup plus de données et des compétences plus spécialisées que la simple formation d’une régression ou d’un classificateur, tout en vous laissant avec des problèmes d’interprétabilité.
Contrôle de vos données: Vos données peuvent quitter votre environnement contrôlé et être consultées par un fournisseur de modèles LLM tiers, ce qui peut créer un risque.
Contrôle des infrastructures: Avec un LLM, vous n’avez aucune autorité sur la gestion de l’infrastructure, donc les temps d’arrêt causés par des tiers créent un risque pour votre entreprise.

Bien entendu, la construction d’un modèle classique nécessite des compétences différentes de celles de la simple mise en place d’un LLM sur une tâche. Vous devez bien comprendre vos données, être prêt à réaliser l’ingénierie des fonctionnalités avec une expertise en la matière, et vous devez disposer de suffisamment de calculs et de données pour entraîner le modèle. Si vous ne disposez d’aucune donnée étiquetée, vous serez limité à un apprentissage non supervisé ou peut-être à l’amorçage de vos propres étiquettes. Heureusement, il existe une multitude de contenus sur la manière de créer ces modèles, ainsi que sur la manière de les évaluer rigoureusement et de les surveiller après leur déploiement.

Connecter votre modèle à votre agent

Vous serez peut-être convaincu d’essayer, mais avant de commencer, il y a également quelques choix architecturaux à considérer. Comment votre modèle et votre agent interagiront-ils ?

Appels directs

Le moyen le plus rapide de démarrer est peut-être simplement de laisser l’agent disposer du modèle comme outil à appeler directement. C’est la forme de mon exemple d’outil de recherche immobilière : l’agent peut utiliser un modèle pour une inférence juste à temps basée sur une invite. Pour mettre cela en place, votre agent IA doit être équipé pour formater correctement ses requêtes au modèle classique. Votre agent doit comprendre à quoi sert ce modèle, quand l’appeler et quand utiliser autre chose. Cela signifie documenter clairement l’objectif et les capacités du modèle, mais si vous construisez déjà une IA agentique, c’est une tâche familière.

En sortie, la réponse de votre modèle doit être structurée de manière à ce que l’agent IA puisse la traiter efficacement. Le simple fait de renvoyer un résultat numérique peut ne pas suffire, car l’agent aura besoin d’informations contextuelles pour l’interpréter et en faire le meilleur usage. Pour mes modèles, j’utilise souvent des f-strings pour construire des descriptions textuelles dans le cadre de l’inférence, indiquant, par exemple, quelles étaient les caractéristiques les plus importantes du modèle, quelle est la probabilité du résultat, etc. Le simple renvoi d’une probabilité limite la capacité de votre agent à interpréter le résultat et à produire une réponse utile pour l’utilisateur final.

Accès à la base de données

Une autre option consiste à faire du modèle non pas un outil direct de l’agent, mais un fournisseur de données contextuelles. Vous pouvez pré-calculer les inférences en exécutant votre modèle ML classique en tant que tâche planifiée et stocker ces inférences dans la solution de stockage de données à laquelle votre agent a accès. Au lieu que l’agent effectue un premier appel d’inférence directement à une API de modèle, il écrit une requête et la transmet à votre base de données.

Si vous disposez d’un ensemble fini de cas pour lesquels vous pourriez potentiellement avoir besoin de l’inférence, cela peut être une bonne solution. Par exemple, si vous avez 500 personnes dans votre base de données et que votre agent est censé récupérer des informations sur leur santé financière, vous pouvez utiliser un modèle de notation de crédit et pré-calculer leur solvabilité pour que l’agent puisse la récupérer au moment de l’exécution avec toutes les autres données qu’il collecte. En fonction de l’infrastructure de votre modèle, cela peut réduire la latence et la répétition, en mettant efficacement en cache les résultats.

Cette approche crée des exigences différentes pour l’appel et la récupération que l’appel direct d’un outil. Si vous pré-calculez les inférences et que vous les mettez simplement à la disposition de votre agent via une base de données, votre agent devra savoir que ces résultats existent. S’il ignore que la table ou le contenu est disponible, il ne les utilisera pas le cas échéant. Vous disposez peut-être déjà de l’infrastructure permettant d’indiquer à l’agent ce que contient la base de données dans votre ingénierie d’invite, si votre agent appelle la base de données pour d’autres informations, donc la réutilisation peut vous éviter de dupliquer les efforts. Dans le cas contraire, votre agent peut avoir besoin d’outils spécifiques qu’il peut utiliser pour examiner les métadonnées de la base de données.

Côté format des résultats, les exigences sont similaires au cas de l’accès direct aux outils. Avoir une description textuelle des résultats est un bon choix, car l’agent doit être capable d’interpréter ce qu’il récupère, quelle que soit la source.

Conclusion

Les modèles ML classiques constituaient des capacités de pointe dans de nombreux secteurs différents pendant plus d’une décennie avant l’arrivée des LLM, donnant aux utilisateurs un aperçu des données qu’ils n’auraient pas pu obtenir autrement. Ce pouvoir ne doit pas être écarté, mais peut plutôt être combiné avec les capacités des LLM. Nous pouvons tirer parti des atouts du LLM, en convertissant le langage humain en langage informatique, en enchaînant différents appels d’outils et en récupérant les résultats de ces outils, tout en utilisant des modèles classiques dans ce cadre pour effectuer le travail pour lequel un LLM n’est pas approprié.

La barrière à l’entrée réside dans l’ensemble des compétences nécessaires à la création de modèles ML classiques de haute qualité, qui ne sont malheureusement pas aussi glamour que certains travaux liés à l’IA de nos jours. Cela en vaut cependant la peine, en raison des avantages : exactitude, précision, interprétabilité, coût et contrôle. Je recommande aux praticiens de perfectionner leurs compétences avec des outils tels que XGBoost, LightGBM et scikit-learn, pour constater ces résultats par vous-mêmes.

En savoir plus sur mon travail sur www.stephaniekirmer.com.