IA agentique

Un système d’IA agentique est composé des composants suivants :

• Un composant d’orchestration d’agents gère et coordonne les actions d’un ensemble d’agents. Le composant d’orchestration d’agents peut utiliser un LLM pour décomposer et générer dynamiquement des workflows afin de résoudre des tâches complexes, ou il peut uniquement utiliser des workflows définis statiquement à l’aide de technologies comme la norme BPMN (modélisation et notation des processus métier), le langage d’exécution des processus métier (BPEL) ou d’autres technologies de workflow.
  
  
• Un ou plusieurs agents, des composants logiciels capables de s’autodéterminer et d’exécuter des actions pour atteindre des objectifs spécifiés. Les agents utilisent généralement un LLM pour générer dynamiquement des plans d’exécution des tâches. Les agents peuvent également utiliser des outils pour interagir avec des systèmes externes, par exemple l’API d’une application d’entreprise, rechercher dans des bases de connaissances, par exemple. interroger Wikipédia ou effectuer des calculs, par exemple. des opérations mathématiques qui ne peuvent être réalisées avec précision ou efficacité en utilisant uniquement un LLM.
  
  
• Enfin, les outils interagissent avec les sources et les systèmes internes et externes de l’entreprise pour récupérer des informations et mettre à jour les systèmes d’enregistrement.

Les agents possèdent leur propre architecture conceptuelle, illustrée dans la figure ci-dessous.

Les agents sont composés des composants principaux suivants :

• Le composant Entrée correspond à une ou plusieurs sources d’entrée qui déclenchent l’action de l’agent. Généralement, il s’agit d’une requête ou d’une tâche en langage naturel émanant d’un utilisateur, mais il peut également s’agir d’un événement système, comme la création d’un fichier, d’un message dans une file d’attente Kafka ou d’un appel d’API structuré.
  
  
• La composante Exécution coordonne les activités de l’agent afin d’exécuter la tâche requise. En général, la première tâche exécutée par le composant Exécution est de (i) rassembler une liste des outils et ressources disponibles pour l’agent, et (ii) d’invoquer le composant Planification et réflexion pour générer un plan d’activité permettant de réaliser la tâche. Le composant Exécution exécute ensuite le plan généré, en utilisant les outils et ressources nécessaires pour collecter des informations ou modifier l’environnement externe de l’agent, et peut périodiquement faire appel au composant Planification et réflexion pour adapter le plan d’activité en fonction des réponses ou des défaillances des outils.
  
  
• Le composant de planification et de réflexion, généralement un LLM, permet à l'agent de créer des plans d'action étape par étape pour accomplir une tâche en réponse à ses entrées, et de réfléchir aux résultats des actions et d’adapter ses plans en conséquence.
  
  
• Le composant Intégration d’outils permet à l'agent d'utiliser des « outils » pour appeler des API et accéder à des ressources afin de réaliser des actions et de recueillir des informations contribuant à l’accomplissement de la tâche globale.
  
  
• Le composant Mémoire gère les connaissances à court terme, liées au contexte de la tâche, ainsi que les connaissances à long terme, ce qui permet à l’agent de maintenir le contexte lors des invocations de tâches (par exemple, « Inverser le dernier bon de commande ») et de fournir une base pour l’analyse des actions passées et l’optimisation des actions futures.
  

Des composants supplémentaires, non illustrés sur la figure, peuvent être ajoutés pour assurer la gestion opérationnelle des agents, la surveillance des performances et les contrôles de sécurité tels que la propagation de l’identité et la prévention des fuites de données.

Le diagramme ci-dessous illustre le flux de contrôle et d’information à travers l’architecture conceptuelle.

1. Un utilisateur envoie une requête à une application d’IA générative (par exemple, un chatbot ou une interface de requête au sein d’une application d’entreprise)
   
   
2. L’application d’IA générative transmet la requête de l’utilisateur à l’orchestrateur d’agents sous la forme soit de la requête brute (par exemple lorsque l’application d’IA est une interface de chat), soit du déclenchement d’un workflow prédéfini, par exemple lors de la création d’une demande d’achat. Une requête brute sera supposée dans la présentation suivante.
   
   
3. Le routeur utilise un LLM adapté pour décomposer la requête de l’utilisateur en une série d’actions, ou d’étapes, nécessaires pour parvenir à une réponse. Par exemple, pour répondre à la question « Quelle est la température actuelle à Winnipeg, Manitoba, Canada ? » « Comment cela se compare-t-il à la moyenne historique pour cette période de l’année ? » Le LLM peut répondre par la liste conceptuelle d’actions suivante :
   
   
   • Recherchez la température actuelle de Winnipeg en utilisant l’agent météo.
   • Recherchez la date actuelle à l’aide de l’agent Calendrier.
   • Recherchez la température moyenne à Winnipeg à cette date en utilisant l’agent de recherche.
   • Calculez la différence entre la température actuelle et la moyenne historique à l’aide de l’agent Calculateur.
   • Formuler une réponse en langage naturel à l’aide de l’agent linguistique
     
     
4. L’orchestrateur invoque ensuite l’agent approprié pour chaque action de la liste. Continuer avec l’exemple de l’étape 3 :
   
   
   • L'orchestrateur invoque l'agent Météo pour obtenir la température actuelle de Winnipeg, soit -1 °C.
   • L'orchestrateur invoque l'agent Calendrier pour obtenir la date actuelle, à savoir le 9 novembre 2023.
   • L'orchestrateur utilise l'agent Recherche pour connaître la température normale à Winnipeg le 9 novembre, soit 1,4 °C.
   • L’orchestrateur invoque l’agent Calculateur pour trouver la différence entre les deux températures, -1 − 1,4 = –2,4.
   • L’orchestrateur utilise l’agent Langage pour formuler une réponse à la requête initiale en utilisant les données collectées.
      
5. Lorsqu’un agent est invoqué, il peut, comme l’orchestrateur, utiliser un LLM pour planifier ses actions. Poursuivons avec l’exemple : l'agent Météo recevrait la demande « Quelle est la température actuelle à Winnipeg ? », pour laquelle il générerait le plan suivant :
   
   
   • Recherchez dans quel pays se trouve Winnipeg.
   • Consultez le service météorologique national faisant autorité pour le pays de Winnipeg
   • Utilisez l’API météo pour interroger le service météo concernant la température actuelle à Winnipeg.
   • L’agent rechercherait ensuite le pays où se trouve Winnipeg (Canada) en utilisant soit un LLM, soit un service externe, utiliserait cette valeur pour consulter le service météorologique national du Canada (Environnement et Changement climatique Canada) et utiliserait l’API météo pour obtenir la température actuelle de Winnipeg.
      
6. La réponse obtenue est ensuite renvoyée à l’application d’IA générative ; dans notre exemple, « La température actuelle à Winnipeg est de -1 °C. C’est 2,4 °C de moins que la norme historique de 1,4 °C. »
   
   
7. La réponse formulée est renvoyée à l’utilisateur.

Le diagramme ci-dessus illustre la correspondance entre les produits IBM et l’architecture de l’IA agentique.

watsonx Orchestrate est une solution d’IA agentique « tout-en-un » qui combine :

• la publication et la gestion des outils (appelés compétences dans watsonx Orchestrate) ;
• la composition des compétences en processus complexes à plusieurs étapes à l’aide de workflows déclaratifs ; et
• des agents pré-créés spécifiques à un domaine pour les secteurs d’activité horizontaux tels que les RH et les achats.

L'Agent Builder de watsonx.ai est un outil low-code / no-code qui permet aux développeurs de construire des agents, de définir et de gérer des outils en utilisant des flux pré-créés.

Stratégie d’orchestration

L’orchestration des agents peut être mise en œuvre selon différentes approches. Une approche d’orchestration centralisée fait appel à un seul composant d’orchestration maître pour gérer les actions de tous les autres agents du système. Le fait de disposer d’un point unique de configuration et de gestion rend le système global simple à gérer et à contrôler, et facile à dépanner. L’inconvénient est qu’un point de contrôle unique peut devenir un goulot d’étranglement et entraîner des problèmes d’évolutivité lorsque les volumes de demandes et/ou le nombre d’agents augmentent.

Une approche d’orchestration décentralisée met en œuvre une file d'attente de tâches dans laquelle les agents récupèrent les tâches et publient les résultats, et acheminent les tâches en plusieurs parties entre eux, à l'instar d'un système de tableau noir. Les solutions d’orchestration décentralisées sont très robustes et tolérantes aux pannes, mais elles sont difficiles à concevoir et à dépanner lorsque les systèmes deviennent plus grands et dotés de capacités plus importantes.

Enfin, une approche d’orchestration hiérarchique combine des éléments des approches centralisée et décentralisée. Dans l’orchestration hiérarchique, un orchestrateur principal est utilisé pour coordonner les actions des agents de haut niveau qui, à leur tour, peuvent invoquer d’autres agents pour accomplir des tâches complexes. Cela permet de conserver une grande partie de la facilité de gestion et de contrôle d’une approche centralisée, mais réduit le risque que le composant de contrôle central devienne un goulot d’étranglement en cas de volumes de demandes élevés et/ou d’un grand nombre d’agents.

Granularité de l’agent

La granularité d’un agent IA fait référence à la complexité des tâches qu’il peut accomplir. Un agent à forte granularité peut être capable d'exécuter de nombreuses tâches ou un petit nombre de tâches de manière très détaillée, tandis qu'un agent à faible granularité peut n'être capable d'accomplir qu'un petit nombre de tâches ou même une seule tâche avec un faible niveau de détail. Pour que cela soit plus clair, prenons l’exemple d’un agent de service client. Un agent à faible granularité peut ne pouvoir répondre qu’à des questions simples sur un produit (par exemple, « Est-il disponible en noir ? »), tandis qu’un agent à forte granularité peut être en mesure de vérifier les stocks locaux et d’organiser la livraison du produit au domicile du client.

Les concepteurs de solutions agentiques doivent décider de la granularité des différents agents du système, par exemple en utilisant un petit nombre d’agents à forte granularité ou un plus grand nombre d’agents à faible granularité. Les vastes capacités d'un agent à forte granularité se traduisent par une augmentation des besoins en ressources informatiques et par des délais d'exécution des tâches plus longs. Bien que moins capables, les agents à faible granularité nécessitent moins de ressources informatiques et accomplissent généralement leurs tâches beaucoup plus rapidement.

Bien que le « bon » niveau de granularité reste inconnu, les premières expériences suggèrent que la création d’agents à faible granularité alignés sur des processus métier ciblés, par exemplePurchase_Order_Processing_Agent, permet d’obtenir un bon équilibre entre besoins en ressources, vitesse de traitement et complexité de la solution. Les agents à faible granularité peuvent alors être intégrés dans des workflows statiques, ou invoqués par des agents à haute granularité dans le cadre d’un processus plus large.

Workflows statiques vs dynamiques

Les concepteurs de solutions d’IA agentique doivent trouver un équilibre entre les agents qui suivent des processus et des workflows statiques et prédéfinis et les workflows générés dynamiquement en réponse aux prompts des utilisateurs. Bien qu’il n’y ait pas de bonne ou de mauvaise réponse, il est conseillé aux architectes de prendre en compte les recommandations et considérations suivantes :

• Les workflows statiques doivent être utilisés pour les processus métier composés de plusieurs étapes complexes qui recoupent différents domaines de connaissances (par exemple, le droit et la comptabilité) ou qui sont soumis à une supervision réglementaire. L’utilisation de workflows statiques dans ces instances offre aux architectes plusieurs avantages :

  • Les workflows statiques sont (relativement) simples à instrumenter, à surveiller et à auditer, et les workflows eux-mêmes peuvent être utilisés comme preuve de conformité réglementaire. Les workflows générés dynamiquement sont plus difficiles à surveiller lors de leur exécution et les exécutions individuelles des processus doivent être reconstruites à partir des journaux de chaque agent. Les workflows dynamiques ont également le potentiel de varier la séquence des tâches, ce qui complique davantage l’audit et le contrôle de la conformité.
    
    
  • Disposer de « transferts » bien définis entre les domaines d’expertise permet un découplage clair des responsabilités et facilite la garantie que les informations transmises sont complètes et correctes. Bien qu'il soit possible d'y parvenir avec un workflow généré dynamiquement, cela nécessite davantage d’attention lors de la conception et de la mise en œuvre.
    
    
• Les workflows dynamiques doivent être utilisés pour des activités ou des fonctions « en une seule étape » exécutées à des moments proches, qui ne recoupent pas différents domaines de connaissances et dont l’exécution n’est pas soumise à une surveillance ou à des contrôles réglementaires.