Ils nous ont promis des agents, mais tout ce que nous avons obtenu étaient des chaînes statiques

Au printemps 2023, le monde s’est enthousiasmé pour l’émergence d’agents basés sur les LLM (Large Language Models). Des démos puissantes comme AutoGPT et BabyAGI ont démontré le potentiel des LLM en fonctionnant en boucle, en choisissant la prochaine action, en observant ses résultats et en choisissant la prochaine action, une étape à la fois (également connu sous le nom de framework ReACT). Cette nouvelle méthode devait alimenter des agents capables de réaliser des tâches multi-étapes de manière autonome et générique. Donnez-lui un objectif et un ensemble d’outils et il se chargera du reste. D’ici la fin de 2024, le paysage sera rempli d’agents et de frameworks de construction d’agents. Mais comment mesurent-ils par rapport à la promesse ?

Il est sage de dire que les agents alimentés par le framework ReACT naïf ReACT souffrent de graves limitations. Donnez-leur une tâche qui nécessite plus d’une few étapes, en utilisant plus d’un few outils et ils échoueront lamentablement. Au-delà de leurs problèmes de latence évidents, ils perdront la trace, ne suivront pas les instructions, s’arrêteront trop tôt ou trop tard et produiront des résultats très différents à chaque tentative. Et ce n’est pas étonnant. Le framework ReACT prend les limitations des LLM imprévisibles et les aggrave en fonction du nombre d’étapes. Cependant, les constructeurs d’agents qui cherchent à résoudre des cas d’utilisation réels, en particulier dans l’entreprise, ne peuvent pas se contenter de ce niveau de performance. Ils ont besoin de résultats fiables, prévisibles et explicables pour des flux de travail multi-étapes complexes. Et ils ont besoin de systèmes d’IA qui atténuent, plutôt qu’exagèrent, la nature imprévisible des LLM.

Alors, comment les agents sont-ils construits dans l’entreprise aujourd’hui ? Pour les cas d’utilisation qui nécessitent plus d’un few outils et d’un few étapes (par exemple, RAG conversationnel), les constructeurs d’agents ont largement abandonné la promesse dynamique et autonome de ReACT pour des méthodes qui s’appuient fortement sur la chaîne statique – la création de chaînes prédéfinies conçues pour résoudre un cas d’utilisation spécifique. Cette approche ressemble à l’ingénierie logicielle traditionnelle et est loin de la promesse agente de ReACT. Elle atteint des niveaux de contrôle et de fiabilité plus élevés, mais manque d’autonomie et de flexibilité. Les solutions sont donc intensives en développement, étroites dans leur application et trop rigides pour répondre à des niveaux élevés de variation dans l’espace d’entrée et l’environnement.

Pour être sûr, les pratiques de chaîne statique peuvent varier dans leur degré de « statisme ». Certaines chaînes n’utilisent les LLM que pour effectuer des étapes atomiques (par exemple, pour extraire des informations, résumer du texte ou rédiger un message) tandis que d’autres utilisent également les LLM pour prendre certaines décisions de manière dynamique au moment de l’exécution (par exemple, un LLM acheminant entre des flux alternatifs dans la chaîne ou un LLM validant le résultat d’une étape pour déterminer s’il doit être réexécuté). Dans tous les cas, tant que les LLM sont responsables de la prise de décision dynamique dans la solution – nous sommes inévitablement pris dans un compromis entre fiabilité et autonomie. Plus une solution est statique, plus elle est fiable et prévisible, mais moins autonome et donc plus étroite dans son application et plus intensive en développement. Plus une solution est dynamique et autonome, plus elle est générique et simple à construire, mais moins fiable et prévisible.

Ce compromis peut être représenté dans le graphique suivant:

Cela soulève la question, pourquoi n’avons-nous pas encore vu un framework agente qui puisse être placé dans le quadrant supérieur droit ? Sommes-nous condamnés à éternellement faire un compromis entre fiabilité et autonomie ? Ne pouvons-nous pas obtenir un framework qui offre l’interface simple d’un agent ReACT (prendre un objectif et un ensemble d’outils et le résoudre) sans sacrifier la fiabilité ?

La réponse est – nous pouvons et nous allons ! Mais pour cela, nous devons réaliser que nous avons tout fait de travers. Tous les frameworks de construction d’agents actuels partagent un défaut commun : ils s’appuient sur les LLM comme composant dynamique et autonome. Cependant, l’élément crucial que nous manquons – ce dont nous avons besoin pour créer des agents qui soient à la fois autonomes et fiables – est la technologie de planification. Et les LLM ne sont pas de grands planificateurs.

Mais qu’est-ce que la « planification » ? Par « planification », nous entendons la capacité à modéliser explicitement des cours d’action alternatifs qui mènent à un résultat souhaité et à explorer et à exploiter ces alternatives sous des contraintes budgétaires. La planification doit être effectuée à la fois aux niveaux macro et micro. Un plan macro divise une tâche en étapes dépendantes et indépendantes qui doivent être exécutées pour atteindre le résultat souhaité. Ce qui est souvent négligé est le besoin de micro-planification visant à garantir les résultats souhaités au niveau de l’étape. Il existe de nombreuses stratégies disponibles pour augmenter la fiabilité et atteindre des garanties au niveau de l’étape unique en utilisant plus de calculs au moment de l’inférence. Par exemple, vous pouvez paraphraser des requêtes de recherche sémantique plusieurs fois, vous pouvez récupérer plus de contexte par requête donnée, vous pouvez utiliser un modèle plus grand et vous pouvez obtenir plus d’inférences à partir d’un LLM – le tout aboutissant à des résultats plus satisfaisants pour les exigences dont vous pouvez choisir le meilleur. Un bon micro-planificateur peut utiliser efficacement les calculs au moment de l’inférence pour atteindre les meilleurs résultats sous un budget de calcul et de latence donné. Pour ajuster l’investissement de ressources en fonction des besoins spécifiques de la tâche en question. De cette façon, les systèmes d’IA planifiés peuvent atténuer la nature probabiliste des LLM pour atteindre des résultats garantis au niveau de l’étape. Sans ces garanties, nous sommes de retour au problème d’erreur cumulative qui sapera même le meilleur plan de niveau macro.

Mais pourquoi les LLM ne peuvent-ils pas servir de planificateurs ? Après tout, ils sont capables de traduire des instructions de haut niveau en chaînes de pensée raisonnables ou en plans définis dans un langage naturel ou du code. La raison est que la planification nécessite plus que cela. La planification nécessite la capacité à modéliser des cours d’action alternatifs qui pourraient raisonnablement mener au résultat souhaité ET à raisonner sur l’utilité attendue et les coûts attendus (en calcul et/ou en latence) de chaque alternative. Alors que les LLM peuvent potentiellement générer des représentations des cours d’action disponibles, ils ne peuvent pas prédire leur utilité et leurs coûts attendus. Par exemple, quels sont l’utilité et les coûts attendus de l’utilisation du modèle X par rapport au modèle Y pour générer une réponse à une requête particulière ? Quel est l’utilité attendu de rechercher une pièce d’information particulière dans le corpus de documents indexés par rapport à un appel d’API au CRM ? Votre LLM n’a pas la moindre idée. Et pour bonne raison – les traces historiques de ces traits probabilistes sont rarement trouvées dans la nature et ne sont pas incluses dans les données de formation des LLM. Ils tendent également à être spécifiques à l’outil et à l’environnement de données dans lequel le système d’IA fonctionnera, contrairement aux connaissances générales que les LLM peuvent acquérir. Et même si les LLM pouvaient prédire l’utilité et les coûts attendus, la prise de décision logique pour choisir le cours d’action le plus efficace est une déduction théorique de la décision qui ne peut pas être supposée être réalisée de manière fiable par les prédictions de jeton suivant des LLM.

Alors, quels sont les ingrédients manquants pour la technologie de planification d’IA ? Nous avons besoin de modèles de planificateurs qui puissent apprendre de l’expérience et de la simulation pour modéliser explicitement des cours d’action alternatifs et des probabilités d’utilité et de coûts correspondants pour une tâche particulière dans un outil et un environnement de données particuliers. Nous avons besoin d’un langage de définition de plan (PDL) qui puisse être utilisé pour représenter et raisonner sur lesdits cours d’action et probabilités. Nous avons besoin d’un moteur d’exécution qui puisse exécuter de manière déterministe et efficace un plan donné défini dans PDL.

Certaines personnes travaillent déjà dur pour tenir cette promesse. Jusqu’à ce que cela arrive, continuez à construire des chaînes statiques. Mais s’il vous plaît, n’appelez-les pas « agents ».