Modèles de conception pour systèmes d’agents

La création d’un système d’agent implique l’orchestration des appels LLM, de la récupération des données et du flux d’actions externes. Vous pouvez envisager des modèles de conception pour les systèmes d’agent sur un continuum de complexité et d’autonomie : des chaînes déterministes, via des systèmes à agent unique capables de prendre des décisions dynamiques (et qui peuvent impliquer plusieurs appels LLM sous le capot), jusqu’à des architectures multi-agents qui coordonnent plusieurs agents spécialisés.

Appel de l’outil

Avant de plonger dans les modèles de conception, il est important de comprendre l’appel d’outils comme une fonctionnalité fondamentale qui peut être utilisée dans n’importe quel système d’agent, de simple à complexe. L’appel d’outils est un mécanisme qui permet à un système d’agent d’interagir avec des fonctions externes, des sources de données ou des services. Cela peut être activé :

• Recherche de données actives, telles que des requêtes SQL, des extractions CRM ou une récupération d’index vectoriel.
• Actions telles que l’envoi d’un e-mail ou la mise à jour d’un enregistrement.
• Logique ou transformations arbitraires par le biais de fonctions ou d’API Python.

L’appel d’outils fournit donc un mécanisme puissant permettant de rendre les machines virtuelles « conscientes » des données externes ou des API, quel que soit le modèle de conception que vous choisissez.

Pour en savoir plus sur les outils d'agent IA, consultez outils d'agent IA.

Les sections ci-dessous décrivent trois modèles de conception de systèmes d’agent, chacun pouvant tirer parti de l'appel d’outils à différents degrés.

Comparer les modèles de conception d’application AI gen

Les modèles de conception d’application Gen AI (agent) sont présentés dans l’ordre de complexité.

Modèle de conception	Quand utiliser	Avantages	Inconvénients
Chaîne déterministe	Tâches bien définies Pipelines statiques tels que RAG de base Il n’est pas nécessaire de prendre des décisions à la volée	Très simple Facile à auditer	Inflexible Nécessite des modifications de code pour s’adapter
Système à agent unique	Des requêtes allant de modérées à complexes dans le même domaine Certaines décisions dynamiques sans surcharge de plusieurs agents spécialisés.	Souple Plus simple que le multi-agent Bonne « valeur par défaut »	Moins prévisible Doit se protéger contre les appels d’outils répétés ou incorrects
Système multi-agent	Domaines volumineux ou interfonctionnels ; plusieurs agents « experts » ; contextes de logique ou de conversation distincts ; modèles de réflexion avancés.	Hautement modulaire S'adapte aux grands domaines	Complexe à orchestrer Plus difficile à tracer et à déboguer

Système à agent unique

Un système à agent unique comprend un flux coordonné de logique , souvent orchestrant plusieurs appels LLM pour gérer les requêtes entrantes. L’agent peut :

1. Acceptez les demandes telles que les requêtes utilisateur et tout contexte pertinent, tel que l’historique des conversations.
2. Réfléchir à la meilleure façon de répondre, en décidant optionnellement d'utiliser des outils pour obtenir des données externes ou effectuer des actions.
3. Itérer si nécessaire, appeler un LLM (et/ou les mêmes outils) à plusieurs reprises jusqu’à ce qu’un objectif soit atteint ou qu’une certaine condition soit remplie (par exemple, la réception de données valides ou la résolution d’une erreur).
4. Intégrer les sorties de l’outil dans la conversation.
5. Retourne une réponse cohérente en tant que sortie.

Dans de nombreux cas d’usage, un seul tour de raisonnement LLM (souvent avec appel d’outils) suffit. Toutefois, les agents plus avancés peuvent parcourir plusieurs étapes jusqu’à ce qu’ils arrivent à un résultat souhaité.

Même s’il n’existe qu’un seul agent, vous pouvez toujours avoir plusieurs appels LLM et d’outils sous le capot (pour la planification, la génération, la vérification, et ainsi de suite), tous gérés par ce flux unifié unique.

Exemple : Assistant(e) d'assistance technique

• Si l’utilisateur pose une question simple (« Qu’est-ce que notre stratégie de retour ? »), l’agent peut répondre directement à partir des connaissances du LLM.
• Si l’utilisateur souhaite connaître l'état de sa commande, l’agent appelle une fonction lookup_order(customer_id, order_id). Si cet outil répond avec « numéro de commande non valide », l’agent peut réessayer ou inviter l’utilisateur à entrer l’ID correct, en continuant jusqu’à ce qu’il puisse fournir une réponse finale.

Quand les utiliser :

• Vous attendez des requêtes utilisateur variées, mais toujours dans un domaine ou une zone de produit cohérent.
• Certaines requêtes ou conditions peuvent justifier l’utilisation de l’outil, par exemple décider quand extraire des données client.
• Vous souhaitez plus de flexibilité qu’une chaîne déterministe, mais vous n’avez pas besoin d’agents spécialisés distincts pour différentes tâches.

Avantages :

• L’agent peut s’adapter aux requêtes nouvelles ou inattendues en choisissant les outils à appeler (le cas échéant).
• L’agent peut boucler à travers des appels LLM répétés ou des invocations d’outils pour affiner les résultats, sans avoir besoin d’une configuration complète de multi-agents.
• Ce modèle de conception est souvent l’endroit idéal pour les cas d’usage d’entreprise , plus simple à déboguer que les configurations multi-agents tout en permettant une logique dynamique et une autonomie limitée.

Considérations :

• Par rapport à une chaîne codée en dur, vous devez vous protéger contre les appels d’outils répétés ou non valides. (Les boucles infinies peuvent se produire dans n’importe quel scénario d’appel d’outils, donc définir des limites d’itération ou des délais d’expiration.)
• Si votre application s’étend sur des sous-domaines radicalement différents (finance, devops, marketing, etc.), un seul agent peut devenir instable ou surchargé avec des exigences de fonctionnalités.
• Vous avez toujours besoin d’invites et de contraintes soigneusement conçues pour que l’agent reste concentré et pertinent.

Chaîne déterministe (étapes codées en dur)

Dans ce modèle, le développeur définit quels composants sont appelés, dans quel ordre et avec quels paramètres. Il n’y a pas de prise de décision dynamique sur les outils à appeler ou dans quel ordre. Le système suit un flux de travail prédéfini pour toutes les requêtes, ce qui le rend hautement prévisible.

Communément appelé « chaîne », le flux est essentiellement une chaîne fixe d’étapes, comme :

1. Récupérez toujours la requête de l’utilisateur et récupérez à partir d’un index vectoriel pour un contexte pertinent.
2. Combinez ce contexte avec la demande de l’utilisateur dans une invite LLM finale.
3. Appelez le LLM et retournez la réponse.

Exemple : Chaîne RAG de base

Une chaîne RAG déterministe peut toujours :

1. Récupérer les résultats top-k à partir d’un index vectoriel à l’aide de la requête d’un utilisateur entrant (récupérer).
2. Mettre en forme les blocs récupérés dans un gabarit de demande (augmenter).
3. Transmettez cette invite augmentée à LLM (générer).
4. Retourne la réponse de LLM.

Quand les utiliser :

• Pour les tâches bien définies avec des flux de travail prévisibles.
• Lorsque la cohérence et l’audit sont les principales priorités.
• Lorsque vous souhaitez réduire la latence en évitant plusieurs appels LLM pour les décisions d’orchestration.

Avantages :

• Plus grande prévisibilité et auditabilité.
• En règle générale, la latence est inférieure (moins d’appels LLM pour l’orchestration).
• Plus facile à tester et valider.

Considérations :

• Flexibilité limitée pour la gestion de demandes diverses ou inattendues.
• Peut devenir complexe et difficile à maintenir à mesure que les branches logiques augmentent.
• Peut nécessiter une refactorisation importante pour prendre en charge de nouvelles fonctionnalités.

Système multi-agent

Un système multi-agent implique deux agents spécialisés ou plus qui échangent des messages et/ou collaborent sur des tâches. Chaque agent possède son propre domaine ou compétence en matière de tâches, son contexte et ses ensembles d’outils potentiellement distincts. Un « coordinateur » distinct, qui peut être un autre LLM ou un routeur basé sur des règles, dirige les requêtes vers l’agent approprié, ou décide du transfert d’un agent à un autre.

Exemple : Assistant Entreprise avec des agents spécialisés

• Agent de support client : Gère les recherches, les retours et les expéditions CRM.
• Agent d’analyse : Se concentre sur les requêtes SQL et le résumé des données.
• Superviseur/routeur : Choisit l'agent le plus approprié pour une requête utilisateur donnée ou quand changer.

Chaque sous-agent peut effectuer des appels d’outils dans son propre domaine (tel que lookup_customer_account ou run_sql_query) nécessitant souvent des sollicitations uniques ou des historiques de conversation.

Quand les utiliser :

• Vous avez des domaines de problème distincts ou des ensembles de compétences tels qu’un agent de codage ou un agent financier.
• Chaque agent a besoin d’accéder à l’historique des conversations ou aux invites spécifiques au domaine.
• Vous disposez de tant d'outils qu'il est impraticable de tous les intégrer dans le schéma d'un seul agent ; chaque agent peut posséder un sous-ensemble.
• Vous souhaitez implémenter la réflexion, la critique ou la collaboration réciproque entre les agents spécialisés.

Avantages :

• Cette approche modulaire signifie que chaque agent peut être développé ou géré par des équipes distinctes, spécialisées dans un domaine étroit.
• Peut gérer des flux de travail d’entreprise volumineux et complexes qu’un seul agent peut avoir du mal à gérer de manière cohérente.
• Facilite le raisonnement multi-étape ou multi-perspective avancé , par exemple, un agent générant une réponse, un autre le vérifiant.

Considérations :

• Nécessite une stratégie pour le routage entre les agents, ainsi que le surcoût pour la journalisation, le traçage et le débogage sur plusieurs points de terminaison.
• Si vous avez de nombreux sous-agents et outils, il peut être compliqué de décider quel agent a accès aux données ou API.
• Les agents peuvent rebondir indéfiniment entre eux sans résolution s’ils ne sont pas soigneusement contraints.
  • Les risques de boucle infinie existent également dans l’appel d’outils à agent unique, mais les configurations multi-agents ajoutent une autre couche de complexité en matière de débogage.

Conseils pratiques

Quel que soit le modèle de conception que vous sélectionnez, tenez compte des meilleures pratiques suivantes pour développer des systèmes d’agent stables et gérables.

1. Commencez simple : Si vous n’avez besoin que d’une chaîne simple, une chaîne déterministe est rapide à construire.
2. Ajoutez progressivement la complexité : À mesure que vous avez besoin de requêtes dynamiques ou de sources de données flexibles, passez à un système à agent unique avec appel d’outils.
3. Accédez à plusieurs agents : Uniquement si vous avez des domaines ou des tâches clairement distincts, plusieurs contextes de conversation ou un ensemble d’outils volumineux trop volumineux pour l’invite d’un seul agent.

Si votre cas d’usage démarre petit, comme une chaîne RAG simple, commencez par une chaîne codée en dur. À mesure que les exigences évoluent, vous pouvez ajouter une logique d’appel d’outils pour la prise de décision dynamique ou même segmenter des tâches dans plusieurs agents spécialisés. En pratique, de nombreux systèmes d’agents réels combinent des modèles. Par exemple, utilisez une chaîne principalement déterministe, mais autorisez le LLM à appeler dynamiquement certaines API en une seule étape si nécessaire.

Mosaïque AI Agent Framework est indépendant de tout modèle que vous choisissez, ce qui facilite l’évolution des modèles de conception à mesure que votre application augmente.

Conseils de développement

• Indications
  • Gardez les invites claires et minimales pour éviter les instructions contradictoires, les informations distrayantes et réduire les hallucinations.
  • Fournissez uniquement les outils et le contexte dont votre agent a besoin, plutôt qu’un ensemble non lié d’API ou de contexte non pertinent volumineux.
• Journalisation et observabilité
  • Implémentez la journalisation détaillée pour chaque demande d’utilisateur, plan d’agent et appel d’outil. Le suivi MLflow peut aider à capturer les journaux structurés afin de faciliter le débogage.
  • Stockez les logs informatiques de manière sécurisée et soyez attentif aux informations d’identification personnelle (PII) dans les données de conversation.
• Mises à jour du modèle et épinglage de version
  • Les comportements LLM peuvent changer lorsque les fournisseurs mettent à jour les modèles en arrière-plan. Utilisez l’épinglage de version et les tests de régression fréquents pour vous assurer que votre logique de l’agent reste robuste et stable.
  • La combinaison de MLflow avec l’évaluation de l’agent Mosaïque AI offre un moyen simplifié d’utiliser des agents de contrôle de version et d’évaluer régulièrement la qualité et les performances.

Conseils de test et d’itération

• Gestion des erreurs & logique de secours
  • Planifiez les échecs de l’outil ou du LLM. Les délais d’expiration, les réponses incorrectes ou les résultats vides peuvent interrompre un flux de travail. Incluez des stratégies de nouvelle tentative, une logique de secours ou une chaîne de secours plus simple lorsque les fonctionnalités avancées échouent.
• Ingénierie de prompt itératif
  • Attendez-vous à affiner les invites et les enchaînements logiques au fil du temps. Créer une version de chaque modification (à l’aide de Git et de MLflow) afin de pouvoir annuler ou mesurer les performances entre les versions.
  • Envisagez des infrastructures telles que DSPy pour optimiser les invites et d’autres composants au sein de votre système d’agent.

Conseils en matière de production

• Latence et optimisation des coûts
  • Chaque appel LLM ou outil supplémentaire augmente l’utilisation des jetons et le temps de réponse. Dans la mesure du possible, combinez des étapes ou cachez des requêtes répétées pour maintenir les performances et les coûts gérables.
• Sécurité et bac à sable
  • Si votre agent peut mettre à jour des enregistrements ou exécuter du code, isolez ces actions ou requérez une approbation humaine si nécessaire. Cela est essentiel dans les environnements d’entreprise ou réglementés pour éviter les dommages involontaires.
  • Databricks recommande les outils de catalogue Unity pour l’exécution en bac à sable (sandbox). Consultez Choisir votre approche d’outil. Le catalogue Unity permet l’isolation de l’exécution arbitraire du code et empêche les acteurs malveillants de tromper l’agent dans la génération et l’exécution de code qui interfère ou écoute sur d’autres requêtes.

En suivant ces instructions, vous pouvez atténuer la plupart des modes d’échec les plus courants, tels que les appels incorrects des outils, la dérive des performances LLM ou des pics de coûts inattendus, et créer des systèmes d’agent plus fiables et évolutifs.