Exécution multi-outils: quand un outil ne suffit pas

DEV - 23/09
Partie 7 de la série "From Zero to IA Agent: My Journey Into Java, des applications intelligentes" dans ...

Partie 7 de la série "From Zero to IA Agent: My Journey Into Java, des applications intelligentes"

Dans notre article précédent, nous avons construit un processeur de requête qui pourrait analyser le langage naturel et exécuter des outils uniques. Mais voici ce que j'ai découvert en le testant: les vrais utilisateurs ne pensent pas en termes unique.

Ils disent des choses comme:

  • "Obtenez la météo à Denver, CO et enregistrez-le dans un fichier"
  • "Créez un dossier de sauvegarde et déplacez tous mes documents là-bas"
  • "Vérifiez les prix sur trois sites Web et dites-moi le moins cher"

Chacun nécessite plusieurs outils travaillant ensemble. Aujourd'hui, nous résolvons cela en construisant un système d'orchestration multi-outils qui peut coordonner automatiquement les workflows complexes.

L'évolution: du célibataire à plusieurs

Commençons par ce que nous avions dans la partie 5. NotreSimpleInférencepourrait gérer ceci:

// ✅ Cela a bien fonctionné "Quel temps fait-il à New York?" → Outil unique → Weather-Server: Weather_Query
Entrez le mode de sortie en mode plein écran

Mais il ne pouvait pas gérer ceci:

// ❌ Cela nécessite le codage rigide ou l'échec entièrement "Obtenez la météo à New York et économisez-le à Weather.txt" → ??? → Deux outils nécessaires
Entrez le mode de sortie en mode plein écran

L'utilisateur veut une action fluide, mais nous avons besoin de deux appels d'outils distincts avec une coordination entre eux.

Le multitoolorchestrator:

Au lieu d'essayer de mettre la logique multi-outils dansSimpleInférence, nous avons créé un orchestrateur dédié spécialisé dans la coordination de plusieurs outils:

classe publique MultitoolorChestrator {private final llmclient llmclient; McPService final privé McPService; carte finale privéeStepResults = new HashMap <> (); public ToolResult ExecupLan (Plan MultitoolPlan) {return Switch (plan.getPlantype ()) {Case Sequential -> ExeculyEntial (plan); Case parallel -> ExecuteParalleall (plan); cas enchaîné -> ExecuteChained (plan); cas compétitif -> exécutif exécutif (plan); // Remarque: conditionnelle et itérative sont partiellement implémentées}; }}
Entrez le mode de sortie en mode plein écran

Insight clé: plutôt que d'avoir une méthode complexe qui essaie de tout gérer, nous avons des stratégies d'exécution spécialisées pour différents types de scénarios multi-outils.

Les quatre modèles d'exécution principaux (actuellement implémentés)

1. Séquentiel: "Faites ceci, alors ça"

Quand utiliser: les étapes doivent se produire dans un ordre spécifique, mais chaque étape est indépendante (pas de flux de données entre elles).

Exemple: "Envoyez un e-mail à John au sujet de la réunion, puis définissez un rappel de calendrier pour demain"

Private ToolResult Executivent (Plan MultitoolPlan) lève une exception {Listeétapes = plan.getSteps (); pour (étape étapes: étapes) {// Vérifiez si les dépendances de cette étape sont satisfaites si (! AreDependEnCIESSatified (Step)) {return ToolResult.Error ("De dépendances non satisfaites pour l'étape:" + étape.id ()); } // Exécuter la carte des étapesrésolvedParams = ResololPara...
[Courte citation de 8% de l'article original]