A uto C luster: Un agent pour le clustering basé sur les grands modèles de langue (2025)

Abstract: Cette recherche présente AutoCluster, un agent basé sur les grands modèles de langue pour des tâches de classification non supervisée. Nous concevons trois agents dont deux sont basés sur la littérature et l’un, AutoCluster, est une contribution originale. Une analyse détaillée de leur performance sur 26 jeux de données de clustering révèle la supériorité de notre agent par rapport aux solutions de l’état de l’art. Enfin, nous justifions l’efficacité de notre agent à travers les nombreuses améliorations empiriques apportées au fur et à mesure de son développement.

## introduction l'ia générative est aujourd'hui basée en grande partie sur les grands modèles de langue (large language models, llms). excellant déjà dans des tâches classiques de tal comme la traduction ou la réponse aux questions @xcite , ceux-ci jouent désormais un rôle clé dans des applications avancées telles que l'assistance à la rédaction de code ou l'analyse de documents. l'émergence de ces modèles a ouvert la voie à une nouvelle génération d'agents capables de raisonner, planifier et interagir de façon autonome avec "l'extérieur" @xcite . la littérature @xcite décrit un agent à travers trois modules : la perception, qui lui permet de connaître son environnement, l'action afin d'interagir avec ce même environnement, et le cerveau, équipé de mémoire et de connaissances, contrôlant raisonnement et décisions. les agents basés sur les llms sont de tels agents, dans lesquels un llm a le rôle de module cérébral. ces derniers ont, entre autres choses, été popularisés grâce aux systèmes de rag (retrieval augmented generation) @xcite , démontrant leur applicabilité et ouvrant la voie à un large éventail d'applications, notamment dans l'industrie. cet article explore spécifiquement l'utilisation d'agents -désignant dans la suite de cet article agents basés sur des llms -pour des tâches d'analyse de données, en particulier des tâches de regroupement non supervisé (clustering). ces dernières années, de nombreux agents dédiés à la science des données ont émergé. certaines approches tentent d'automatiser des processus entiers d'analyse de données @xcite @xcite @xcite . elles sont très largement basées sur les capacités de planification des llms. pourtant, ces capacités sont remises en cause par la littérature récente @xcite @xcite . nous suivons des idées de ces derniers articles pour notre contribution, en diminuant l'autonomie et la prise de décision de l'agent que nous construisons (cf. 3.2.3). la création de collections de référence pour évaluer ces agents est également un domaine de recherche émergent et en pleine expansion. pybench @xcite inclut mais ne se limite pas à des tâches d'analyse de données, tandis que mle-bench @xcite et dsbench @xcite se concentrent davantage sur le machine learning, s'appuyant respectivement sur 75 et 74 compétitions kaggle (une plateforme de référence pour le partage et l'analyse de données). ces deux derniers benchmarks, bien que pertinents, présentent une limite : ils comparent les résultats des agents non pas au jeu de test privé des compétitions, mais à un jeu de validation issu du jeu d'entraînement, rendant les évaluations moins fiables. mlagentbench @xcite définit un benchmark plus restreint également basé sur kaggle et évalue la performance d'un agent en le comparant à une baseline relativement faible. infiagent-dabench @xcite évalue des agents sur des questions d'analyse de données spécifiques et délimitées, par opposition à une évaluation bout-à-bout d'un flot de travail complet. néanmoins, aucun de ces benchmarks ne se concentrent sur le clustering, ou sur des tâches d'analyse de données non supervisées. la fouille de données constitue un aspect essentiel de l'analyse de données, avec de nombreuses applications dans le monde industriel, notamment en software engineering @xcite . parmi les différentes approches existantes, le clustering est une technique permettant de rassembler des données similaires dans des mêmes groupes de façon non supervisée. cela permet notamment d'obtenir une idée de la structure sous-jacente des données sans avoir besoin de les annoter. les recherches de la littérature récente sur les agents s'intéressent principalement aux tâches supervisées et beaucoup moins des problèmes non supervisés. dans cet article, nous construisons, comparons et évaluons différentes approches à base d'agents pour l'exécution de tâches de clustering. les approches comparées proviennent de la littérature hormis une, autocluster 1 , que nous avons construite spécifiquement pour cette tâche. elles diffèrent par leurs architectures, c'est-à-dire la façon dont sont formulés et articulés les prompts (instruction textuelle guidant ou contraignant le modèle), et dans le degré d'autonomie laissé aux llms. les architectures utilisées sont, en théorie, agnostiques aux modèles de langue, ce qui facilite la comparaison des performances de différents llms. les modèles utilisés lors des expériences sont en open source ou mis à disposition gratuitement via des api (dans la limite des taux d'accès définis par les fournisseurs). la contribution de cet article est triple : ## travaux connexes de nombreuses recherches récentes se sont focalisées sur les différentes stratégies de prompting d'un llm afin d'optimiser la génération @xcite @xcite . ces modèles rencontrent souvent des difficultés face à des tâches complexes nécessitant plusieurs étapes, un raisonnement itératif ou des calculs avancés (ma et al., 2024). sur la base de cette analyse, de nouvelles directions de recherche ont émergé dans le domaine des agents. plusieurs architectures ont vu le jour, propulsées par l'engouement lié aux llms, dans le but d'optimiser l'entrelacement entre le raisonnement du llm et l'utilisation d'outils externes (yao et al., 2023b; shinn et al., 2023; schick et al., 2023). dans le cadre de cette étude, nous nous intéressons au clustering comme cas d'usage pour explorer et comparer différentes architectures de prompt issues de la littérature. en particulier, des architectures spécifiques ont déjà été développées dans des travaux connexes pour des tâches d'analyse de données : (li et al., 2024; hong et al., 2024; guo et al., 2024; huang et al., 2024b) et certaines méthodes ont été spécifiquement étudiées pour incorporer des llms dans des chaînes de traitement effectuant du clustering de textes : (viswanathan et al., 2024; zhang et al., 2023). datainterpreter (hong et al., 2024) repose sur une stratégie de planification hiérarchique et dynamique basée sur les llms, qui lui permet de décomposer un problème d'analyse de données en sous-tâches simples. il utilise des outils pré-construits par des humains (snippets de code) ou par lui-même, intégrant un module "mémoire" qui enregistre ses propres solutions pour réutilisation ultérieure. couplé à un module de vérification automatisée, dans lequel un llm génère ses propres tests unitaires, cet agent est fortement dépendant de la capacité de planification et prise de décision des llms. néanmoins, (huang et al., 2024b) met en évidence les limites à long terme de ces capacités. les expériences qu'ils ont menées avec leur agent montre des taux de succès de 0% sur des tâches nouvelles (apparues après le pré-entraînement des llms utilisés). aide (jiang et al., 2025), conçu pour du ml, repose également sur de la planification par llm, construisant dynamiquement un arbre de solutions potentiels, dans lequel un noeud contient une solution, et une branche correspond à un axe d'amélioration du parent. bien qu'affichant des performances comparables aux humains, cette approche exige d'importantes ressources pour explorer plusieurs pistes en parallèle et peut rapidement devenir complexe à mesure que l'arbre s'étend. ds-agent (guo et al., 2024) tire profit d'une riche base de données, construites sur des compétitions kaggle, fonctionnant sur un raisonnement à partir de cas. des cas similaires (requêté par similarité sémantique) à un problème donné viennent enrichir le contexte fourni au llm, améliorant la qualité du plan généré. néanmoins, ce contexte supplémentaire n'est pas facilement accessible dans des scénarios du monde réel, et limite l'application de l'agent aux tâches présentent dans la base de données. autokaggle emploie de son côté un cadre multi-agent dans un flot construit pour l'analyse de données. spécialisé pour kaggle, le système suppose une structure classique de compétition, notamment avec un découpage des données en jeu de test et jeu d'entraînement, ce qui n'est pas adapté à une tâche non supervisée comme le clustering. de plus, cette approche utilise une surcouche d'outil qui englobent les outils classiques de python pour l'analyse de données (notamment scikitlearn), ajoutant une strate de complexité supplémentaire pour l'agent, l'empêchant d'utiliser sa connaissance paramétrique des librairies de machine learning. enfin, agent k v1.0 (grosnit et al., 2024) emploie différents mécanismes des architectures cités ci-dessus, et orchestre des flots de travail pour des tâches de science des données. comme (guo et al., 2024) et (wang et al., 2023a), cet agent exploite les capacités inhérentes des llms à raisonner à partir de cas. il sélectionne activement les cas les plus pertinents en fonction de deux critères : la similarité avec la tâche en cours et la difficulté de résolution de l'exemple choisi. d'abord placé dans une machines à états finis (xia et al., 2024) pour découvrir et pré-traiter les données, le paradigme change pour la partie de mise en oeuvre des modèles, dans laquelle l'agent effectue ses propres choix. à travers des outils d'analyse de données tels que automl (données tabulaires de ml) et hebo (tuning des hyperparamètres), ou des prompts spécifiques, cet agent peut adopter des approches variées pour couvrir un maximum de diversité dans les problèmes rencontrés. guidé par des méta test génériques, l'agent peut également décider, à n'importe quelle étape du processus, de prendre une action intrinsèque, c'est à dire sans action sur l'environnement (formuler une hypothèse, raisonner, etc.) ainsi, son rôle est plus celui d'un orchestrateur qui décide de la marche à suivre en fonction du problème. bien que démontrant de fortes capacités (niveau de grand maître sur kaggle) dans diverses tâches (tabulaires, vision, traitement du langage naturel, multimodales), cet agent présente certaines limites. entre autres, il requiert un haut niveau de customisation des prompts par type de tâche (pour la partie de choix du modèle), difficile à mettre en place et à affiner. de plus, dû à son large éventail d'applications, il repose sur la capacité de planification des llms, qui est notamment mise en cause par (kambhampati et al., 2024; liu et al., 2023; xia et al., 2024). en effet, d'autres volets de la littérature examinent dans quelle mesure les llms possèdent les compétences nécessaires pour être utilisés dans des applications de telle complexité (huang et al., 2024a; kambhampati et al., 2024). des travaux récents montrent l'incapacité de ces modèles à planifier à long terme (liu et al., 2023), et à s'auto-critiquer de manière intrinsèque. sans l'aide de sources externes, les llms ne parviennent pas à détecter quand une autocritique est nécessaire (c'est à dire lorsque leur sortie contient une erreur). ainsi, solliciter l'auto-évaluation de ces modèles sans directives adéquates (comme pourrait en donner un oracle humain) entraîne une baisse drastique des performances. poussant l'analyse plus loin, agentless (xia et al., 2024) et repairagent (bouzenia et al., 2024) s'éloignent des systèmes agentiques populaires. leur "agent" opère dans le cadre d'une machine à états finis plutôt que de faire ses propres choix (ou transitions) comme c'est généralement le cas dans d'autres approches. nous nous inspirons de ces travaux pour le développement de autocluster. les agents présentés ci-dessus sont destinés à des usages relativement généraux. ils sont conçus pour s'attaquer à la fois à des tâches fermées (qui possèdent une solution clairement prédéfinie) et ouvertes (qui n'ont pas une seule réponse correcte, encourageant la réflexion et la créativité). le clustering se distingue comme une tâche à la fois ouverte et complexe qui, malgré sa pertinence, reste peu explorée dans l'évaluation de ces agents. c'est pourquoi nous choisissons de nous concentrer sur l'étude de leur capacité sur des tâches de clustering. ## approche proposée afin d'évaluer dans quelle mesure un llm peut être sollicité pour des tâches relativement complexes d'analyse de données, nous avons construit, testé et comparé plusieurs architectures d'agents pour traiter des tâches de clustering, en s'appuyant sur la littérature récente. après une présentation des données (section 3.1), nous expliquons dans 3.2 l'organisation interne des agents comparés (fonctionnement du "cerveau") avant de détailler le fonctionnement de leur module d'action (section 3.3), identique à chacun, qui leur permet d'interagir avec leur environnement @xcite . le module de perception des agents n'est pas présenté, car les données utilisées sont exclusivement textuelles ; le caractère multimodal de certains des llms testés n'est pas employé dans le périmètre de cet article. ## discussion sur les difficultés rencontrées sans que cela ne soit clairement explicité dans la littérature, les différentes solutions que nous avons mises en place nécessitent que les modèles vérifient un certain nombre de pré-requis. tout d'abord, le modèle doit être capable de générer une sortie structurée, pour permettre notamment l'appel à un outil @xcite ou tout simplement pour pouvoir structurer sa génération en code. sans cette capacité, les implémentations proposées ne sont pas applicables car le flot de travail est basé sur ce parsing (en particulier pour les architectures plus "autonomes"). or, cette fonctionnalité n'est généralement pas apprise lors du pré-entraînement et nécessite une étape de fine-tuning foot_2 , ce qui réduit l'éventail des modèles branchables sur notre architecture. de plus, dû à la complexité de la tâche @xcite , qui requiert une compréhension de l'outil à disposition, savoir quand l'invoquer (donc des capacités de planification), comment, et comprendre les résultats, les "petits" modèles peinent à l'accomplir. les modèles prêts à l'emploi (sans nécessité de fine-tuning spécifique à nos outils) dotés de cette capacité génériquement sont généralement assez gros (autour de 50 -70 milliards de paramètres). de plus, même apprise, cette fonctionnalité n'est pas totalement fiable, il n'est pas rare de voir les modèles échouer à générer des formats complexes (par exemple lorsque le format cible contient une union de type "répond en tel format ou en tel format"). des variantes de ce problème existent, le rendant plus compliqué à détecter : un deuxième point source de contraintes provient des différences inhérentes aux llms (différence de données de pré-entraînement, différents objectifs de fine-tuning, etc.). bien que théoriquement agnostique au modèle, notre cadre a dû évolué au fur et à mesure que de nouveaux llms ont été testés pour prendre en compte les subtilités liés à chacun. par exemple, les modèles mistral testés impose un historique des messages bien particulier (un message d'outil doit être le dernier d'une conversation), alors que cette limitation n'existait pas avec un llama ; un gemini qui échoue à appeler un outil va générer un message vide (ce sont ses métadonnées qui indique la cause de l'erreur) or certains modèles fonctionnent mal avec les messages vides dans l'historique. ce sont autant de problèmes qu'il a fallu traiter au cas par cas, provenant potentiellement du manque du maturité et de consensus global sur les approches à adopter pour ce genre de questions. ce sujet demeure en effet extrêmement récent. ## conclusion dans cet article, nous expliquons autocluster, un agent basé sur les llms spécialisé pour le clustering. nous démontrons l'avantage de connaître à l'avance le chemin suivi par l'agent, augmentant la robustesse des résultats produits (tests de conformité), et bénéficiant des capacités de leur capacité à formuler des solutions potentielles @xcite plutôt que de reposer sur leur capacité de planification. dans la même idée, le llm ne s'auto-critique pas mais reçoit le feedback de l'interpréteur python, lui permettant d'adapter son approche avec plus de sûreté. nous démontrons la supériorité de notre approche à travers des expérimentations sur des tâches de clustering (cf. 4.3), concept à partir duquel a été bâti autocluster. de nombreuses améliorations sont envisagées, principalement pour notre agent autocluster. une première piste consiste à augmenter les capacités de perception de l'agent, en tirant profit des modèles multimodaux auxquels on peut passer les images générés en code directement dans le contexte. ensuite, dans l'idée des rag, il serait intéressant d'évaluer les performances de l'agent auquel on fournit en contexte des données récupérées des pages scikit-learn ou scipy sur les algorithmes sélectionnés (qui incluent notamment des cas d'usage et des descriptions des paramètres). pour étendre cette direction et rejoindre la littérature @xcite @xcite , nous allons concentrer nos travaux sur l'implémentation d'une mémoire à long terme, avec requêtage actif à la manière de @xcite . enfin, nous souhaitons complexifier la tâche donnée à l'agent, avec des données moins structurées et des clusters moins bien définis, afin d'évaluer plus profondément les avantages de notre approche. dans la même idée, il serait intéressant d'étendre le périmètre de l'agent à d'autres tâches d'analyse de données comme la fouille de motif ou la découverte de sous-groupes.