LangChain Project Executive Intelligence

Les intelligences de planification et d'exécution offrent une solution plus rapide, plus rentable et plus performante pour l'exécution des tâches que les conceptions précédentes. Cet article vous guidera dans la construction de trois intelligences de planification dans LangGraph.

 

Nous avons introduit trois intelligences en mode "planifier et exécuter" sur la plate-forme LangGraph. Ces intelligences présentent plusieurs améliorations par rapport aux intelligences classiques en mode "Raisonner et agir" (ReAct).

 

⏰ Premièrement, ces intelligences sont capables d'effectuer des tâches à plusieurs étapes plus rapidement, car il n'est pas nécessaire de demander à nouveau l'intervention des grandes intelligences après avoir terminé chaque action. Chaque sous-tâche peut être accomplie sans qu'il soit nécessaire de faire appel à un grand modèle de langage (LLM) supplémentaire ou à un support LLM plus léger.

Deuxièmement, ils peuvent effectivement réduire les coûts par rapport aux intelligences ReAct. Si des appels LLM sont nécessaires pour des sous-tâches, des modèles plus petits et spécifiques au domaine sont généralement utilisés. Les grands modèles ne sont invoqués que lorsque des étapes de (re)planification doivent être réalisées et que des réponses finales doivent être générées.

Enfin, en demandant au planificateur de "réfléchir" explicitement, étape par étape, au processus nécessaire pour mener à bien l'ensemble de la tâche, ces intelligences peuvent obtenir de meilleurs résultats en termes de taux d'achèvement et de qualité de la tâche. L'élaboration d'étapes de raisonnement détaillées est une technique de repérage validée qui permet d'améliorer les résultats. La segmentation du problème peut également conduire à une exécution plus ciblée et plus efficace de la tâche.

 

 

Contexte

 

Au cours de l'année écoulée, les agents intelligents et les machines à états basées sur des modèles de langage sont apparus comme un paradigme de conception prometteur pour développer des produits d'IA flexibles et efficaces.

Le cœur d'un agent est un modèle de langage en tant qu'outil générique de résolution de problèmes qui le relie à des ressources externes pour répondre à des questions ou exécuter des tâches.

En règle générale, les agents intelligents basés sur des modèles linguistiques passent par les grandes étapes suivantes :

1. proposer une action : le modèle linguistique génère un texte qui répond directement à l'utilisateur ou qui est communiqué à une fonction.
2) Exécuter une action : le code appelle d'autres logiciels pour effectuer, par exemple, une requête dans la base de données ou un appel à l'API et d'autres opérations.
3. observer Observer : réagir au retour d'information des appels d'outils, soit en appelant une autre fonction, soit en répondant à l'utilisateur.

 

ReAct Les agents intelligents en sont un bon exemple : ils utilisent des cycles répétitifs de réflexion, d'action et d'observation pour guider le modèle linguistique :

Réflexion : Je devrais appeler Search() pour rechercher le score du match en cours.
Action : Search("Quel est le score du match X en cours ?")
Observation : Le score actuel est de 24-21
... (Répéter N fois)

Il s'agit d'une trajectoire typique d'un agent intelligent de type ReAct.

 

Cette approche utiliseChaîne de penséede manière à ce qu'une seule décision d'action soit prise à chaque étape. Si cette méthode peut s'avérer efficace pour des tâches simples, elle présente des inconvénients majeurs :

1) Chaque appel d'outil nécessite un appel de modèle linguistique.
2) Le modèle linguistique planifie un sous-problème à la fois. Cela peut conduire à des trajectoires de traitement sous-optimales, car il n'est pas obligé de "raisonner" sur l'ensemble de la tâche.

Un moyen efficace de remédier à ces deux inconvénients est d'inclure une étape de planification explicite. Nous présentons ci-dessous deux exemples de ce type de conception que nous avons mis en œuvre à LangGraph.

 

Système de planification et d'exécution

 

LangChain计划执行型智能体

Agents d'exécution du programme

 

Cette structure simple est basée sur l'article de Wang et al [Conseils de planification et de résolution] proposée par Yohei Nakajima et s'inspirant de son [BabyAGI], qui est devenu l'architecture type d'un agent de planification. Il contient deux composants de base principaux :

1. un planificateur (A) planificateur), est chargé de diriger un modèle de langage (LLM) afin de générer des plans à plusieurs étapes pour des tâches complexes.
2. plusieurs actionneurs (Exécuteur(s)) qui peut traiter les exigences de la requête de l'utilisateur ainsi qu'une étape du plan et invoquer un ou plusieurs outils pour effectuer cette tâche.

 

Une fois l'exécution de la tâche terminée, l'agent est à nouveau invité à planifier, et il décide alors s'il doit simplement fournir une réponse pour y mettre fin, ou générer d'autres plans si nécessaire (si le plan initial n'a pas atteint son objectif).

 

Cette conception de l'agent évite de devoir recourir à un grand modèle de langage de planification pour chaque invocation de l'outil. Toutefois, comme il ne prend pas en charge les opérations d'affectation sur les variables et que l'outil doit être invoqué en série, un modèle de langage distinct est nécessaire pour chaque tâche.

 

 

Raisonner au-delà de l'observation indépendante

 

Dans [ReWOODans l'étude [...], Xu et al. ont conçu un nouveau modèle d'agent qui inverse la méthode traditionnelle selon laquelle chaque tâche doit s'appuyer sur le grand modèle linguistique (LLM) en permettant aux tâches suivantes de s'appuyer sur les résultats de la tâche précédente. Le modèle est mis en œuvre en incorporant la fonction d'affectation de variables dans la planification de la sortie. La figure suivante illustre la conception de ce modèle d'agent.

 

LangChain计划执行型智能体

Modèle d'agent ReWOO

 

Le planificateur est chargé de générer une liste de plans comprenant "plan" (raisonnement) en alternance avec la ligne "E#". Par exemple, pour la requête "Quelles sont les statistiques des quaterbacks des candidats au Super Bowl de cette année ?", le planificateur peut générer le plan suivant :

Le plan : J'ai besoin de connaître les équipes qui joueront le Super Bowl cette année
E1 : Recherche [qui joue au Super Bowl ?] PLAN : J'ai besoin de savoir qui est le quaterback de chaque équipe.
E2 : LLM [QB de la première équipe #E1] PLAN : J'ai besoin de savoir qui est le QB de chaque équipe
E3 : LLM [2nd team QB #E1] Plan : Je dois vérifier les statistiques du premier quarterback.
E4 : Recherche [stats QB de #E2] Plan : Je dois rechercher les stats du second quarterback.
E5 : Rechercher [les statistiques du quaterback de #E3].

Il convient de noter que le planificateur (planificateur) Comment peut-il se référer à une sortie précédente par le biais d'une syntaxe telle que `#E2`. Cela signifie qu'il est possible d'effectuer une série de tâches sans avoir à les reprogrammer à chaque fois.

"Les travailleurs (travailleurLe nœud ")" parcourt chaque tâche et affecte ses résultats à des variables prédéterminées. Lors de l'exécution des tâches suivantes, ces variables sont remplacées par les résultats correspondants.

En fin de compte, le "résolveur" (Solveur) "Intégrer tous les résultats pour obtenir la réponse finale.

Cette philosophie de conception des agents peut être plus efficace qu'un simple modèle planifier-exécuter, puisque chaque tâche ne contient que les informations contextuelles nécessaires (c'est-à-dire ses entrées et ses valeurs variables).

Toutefois, cette conception repose toujours sur l'exécution séquentielle des tâches, ce qui peut se traduire par des temps d'exécution plus longs.

 

 

LLMCompiler

 

LangChain计划执行型智能体

Agent LLMCompiler

 

LLMCompiler Il s'agit d'une combinaison de [Équipe KimDans le cadre de cette étude, nous avons développé une architecture d'agents conçue pour améliorer l'efficacité de l'exécution des tâches par rapport au plan d'exécution décrit précédemment avec les agents ReWOO, et même plus rapidement que les appels d'outils parallèles de l'OpenAI.

 

Le compilateur LLMC se compose des parties principales suivantes :

1. PlanificateurIl génère un graphe acyclique dirigé (DAG) de tâches. Chaque tâche comprend des outils, des paramètres et une liste de dépendances.

2. Unité d'acquisition de tâches (TFU) Responsable de la planification et de l'exécution des tâches. Il peut accepter un flux de tâches et les programmer une fois que leurs dépendances ont été satisfaites. Étant donné que de nombreux outils nécessitent des appels supplémentaires au moteur de recherche ou au LLM, cette exécution parallèle peut augmenter considérablement la vitesse (jusqu'à 3,6 fois selon l'article).

3. Connecteur (Joiner)Cette partie peut dynamiquement replanifier ou terminer la tâche sur la base de l'historique complet de l'exécution de la tâche, y compris les résultats de l'exécution de la tâche. C'est l'étape de la session LLM qui détermine s'il faut présenter directement le résultat final ou renvoyer la progression au planificateur afin de poursuivre le travail.

Le point clé de cette architecture pour accélérer la mise en œuvre est le suivant :

  • planificateurLa sortie dustreamingil est capable de produire des sorties instantanées des paramètres de la tâche et de leurs dépendances.
  • unité d'acquisition de tâches Il reçoit les tâches en flux continu et commence l'ordonnancement lorsque toutes les dépendances sont satisfaites.
  • Les paramètres de la tâche peuvent êtrevariantec'est-à-dire les résultats des tâches précédentes dans le graphe acyclique dirigé. Par exemple, le modèle peut être représenté par search("${1}") pour interroger le contenu de la recherche généré par la tâche 1. Cette approche permet à l'agent de travailler plus efficacement que les appels d'outils parallèles normaux d'OpenAI.

 

L'organisation des tâches dans un graphe acyclique dirigé permet non seulement de gagner un temps précieux lors de l'invocation de l'outil, mais aussi d'offrir une meilleure expérience à l'utilisateur.

 

 

résumés

 

Ces trois architectures proxy sont des prototypes du modèle de conception "Plan-Do", qui sépare le "planificateur" piloté par le LLM de l'exécution de l'outil. Si votre application nécessite plusieurs appels à l'outil ou à l'API, ces approches peuvent réduire le temps nécessaire pour obtenir le résultat final et vous aider à réduire les coûts en réduisant le nombre d'appels à des LLM de niveau supérieur.

© déclaration de droits d'auteur

Postes connexes

Pas de commentaires

Vous devez être connecté pour participer aux commentaires !
S'inscrire maintenant
aucun
Pas de commentaires...