Modèles de conception de système d'agent

Les agents GenAI combinent l'intelligence des modèles GenAI avec des outils pour la récupération de données, les actions externes et d'autres capacités. Cette page présente la conception d'agent :

• Un exemple concret de création d’un système d’agent illustre l’orchestration du fonctionnement des appels de modèle et d’outil.
• Les modèles de conception pour les systèmes d'agents forment un continuum de complexité et d'autonomie, des chaînes déterministes aux architectures multi-agents qui coordonnent plusieurs agents spécialisés, en passant par les systèmes à agent unique capables de prendre des décisions dynamiques.
• Une section de conseils pratiques donne des conseils sur le choix de la bonne conception et sur le développement d'agents, les tests et le passage en production.

Les agents dépendent fortement des outils pour la collecte d'informations et l'exécution d'actions externes. Pour plus d'informations sur les outils, consultez Outils.

Exemple de système d'agent

Pour un exemple concret de système d'agent, considérez un agent GenAI de centre d'appels interagissant avec un client :

Le client fait une demande : « Pouvez-vous m'aider à retourner ma dernière commande ? »

1. Raison et plan : Compte tenu de l’intention de la query, l’agent « prévoit » : « Consultez la commande récente de l’utilisateur et consultez notre politique de retour. »

2. Trouver des informations (veille des données) : l'agent interroge la base de données des commandes pour récupérer la commande pertinente et fait référence à un document de politique.

3. Raison : L’agent vérifie si cette commande respecte la fenêtre de retour.

   • Supervision humaine optionnelle : l'agent vérifie une règle supplémentaire : si l'article appartient à une certaine catégorie ou se trouve en dehors de la fenêtre de retour normale, le transfert est effectué à un opérateur humain.

4. **Action** : l'agent Trigger le processus de retour et génère une étiquette d'expédition.

5. Raison : L'agent génère une réponse pour le client.

L'agent IA répond au client : « Terminé ! Voici votre étiquette d'expédition…

Ces étapes sont une seconde nature dans un contexte de centre d'appels *humain*. Dans un contexte de *système d'agent*, le LLM « raisonne » tandis que le système fait appel à des outils spécialisés ou à des sources de données pour fournir les détails.

niveaux de complexité : des LLM aux systèmes agents

Les applications GenAI peuvent être alimentées par un éventail de systèmes, des simples appels LLM aux systèmes multi-agents complexes. Lorsque vous créez une application basée sur l'IA, start par le plus simple. Introduisez des comportements d'agent plus complexes lorsque vous en avez réellement besoin pour une meilleure flexibilité ou des décisions basées sur un modèle. Les chaînes déterministes offrent des flux prévisibles et basés sur des règles pour des tâches bien définies. Des approches plus agentiques offrent une plus grande flexibilité et un potentiel accru, mais elles s'accompagnent d'un coût en termes de complexité supplémentaire et de latence potentielle.

Modèle de conception	Quand utiliser	Avantages	Consommation
LLM + prompt	Question et réponse génériques Prototype rapide pour une utilisation à court terme	Très simple Facile à créer	Personnalisation minimale
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	Simple Facile à auditer	Inflexible Nécessite des modifications du code pour s'adapter
Système à agent unique	Requêtes modérées à complexes dans le même domaine Certaines décisions dynamiques sans la surcharge de plusieurs agents spécialisés	Flexible Plus simple que multi-agent Bon « default »	Moins prévisible Il faut se prémunir contre les appels d'outils répétés ou incorrects.
Système multi-agents	Domaines vastes ou interfonctionnels Plusieurs agents « experts », avec des logiques ou des contextes de conversation distincts	Hautement modulaire Est évolutif pour les grands domaines.	Complexe à orchestrer Plus difficile à tracer et à déboguer

Modèle de conception	Quand utiliser	Avantages	Consommation
LLM + prompt	Question et réponse génériques Prototype rapide pour une utilisation à court terme	Très simple Facile à créer	Personnalisation minimale
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	Simple Facile à auditer	Inflexible Nécessite des modifications du code pour s'adapter
Système à agent unique	Requêtes modérées à complexes dans le même domaine Certaines décisions dynamiques sans la surcharge de plusieurs agents spécialisés	Flexible Plus simple que multi-agent Bon « default »	Moins prévisible Il faut se prémunir contre les appels d'outils répétés ou incorrects.
Système multi-agents	Domaines vastes ou interfonctionnels Plusieurs agents « experts », avec des logiques ou des contextes de conversation distincts	Hautement modulaire Est évolutif pour les grands domaines.	Complexe à orchestrer Plus difficile à tracer et à déboguer

Les agents personnalisés sont agnostiques à ces modèles de conception, vous pouvez donc start simplement et évoluer vers des niveaux supérieurs d'automatisation et d'autonomie à mesure que les exigences de votre application augmentent.

Pour en savoir plus sur la théorie des systèmes d'agents, consultez les billets de blog des fondateurs de Databricks :

• Systèmes d'agents IA : ingénierie modulaire pour des applications d'IA d'entreprise fiables
• Le passage des modèles aux systèmes d'IA composés

LLM et l'invite

La conception la plus simple comporte un modèle LLM autonome ou un autre modèle GenAI qui répond aux invites en fonction des connaissances issues d'un vaste dataset d'entraînement. Cette conception est adaptée aux queries simples ou génériques, mais est souvent déconnectée de vos données métier réelles. Vous pouvez personnaliser le comportement en fournissant une invite système avec vos instructions personnalisées ou des données intégrées.

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

Les chaînes déterministes augmentent les modèles GenAI avec l’appel d’outils, mais le développeur définit les outils ou modèles appelés, dans quel ordre et avec quels paramètres. Le LLM ne prend pas de décisions concernant *les outils* à appeler ou *l’ordre* dans lequel les appeler. Le système suit un workflow prédéfini ou une « chaîne » pour toutes les requêtes, ce qui le rend très prévisible.

Par exemple, une chaîne de génération augmentée de récupération (RAG) déterministe peut toujours :

1. Récupérer les k meilleurs résultats d'un index vectoriel pour trouver le contexte pertinent d'une requête utilisateur.
2. Augmentez une requête en combinant la demande de l'utilisateur avec le contexte récupéré.
3. Générez une réponse en envoyant le prompt augmenté à un LLM.

Quand utiliser :

• Pour les tâches bien définies avec des workflows prévisibles.
• Lorsque la cohérence et l'audit sont des priorités absolues.
• Lorsque vous souhaitez minimiser la latence en évitant les appels LLM multiples pour les décisions d'orchestration.

Avantages :

• La meilleure prévisibilité et auditabilité.
• Latence généralement plus faible (moins d'appels LLM pour l'orchestration).
• Plus facile de tester et valider.

Considérations :

• Flexibilité limitée pour la gestion des demandes diverses ou inattendues.
• Peut devenir complexe et difficile à maintenir à mesure que les branches logiques se développent.
• Peut nécessiter un refactoring important pour s'adapter aux nouvelles capacités.

Système mono-agent

Un système à agent unique dispose d'un LLM qui orchestre un flux de logique coordonné. Le LLM décide de manière adaptative quels outils utiliser, quand effectuer d'autres appels LLM et quand s'arrêter. Cette approche prend en charge les décisions dynamiques et sensibles au contexte.

Un système à agent unique peut :

1. Acceptez les requêtes 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 éventuellement d'appeler des outils pour des données ou des actions externes.
3. Itérez si nécessaire, en appelant un LLM ou des outils de manière répétée jusqu'à ce qu'un objectif soit atteint ou qu'une certaine condition soit remplie, comme la réception de données valides ou la résolution d'une erreur.
4. Intégrez les résultats de l'outil dans la conversation.
5. Retourner une réponse cohérente en sortie.

Par exemple, un agent d'assistant du service d'aide peut s'adapter comme suit :

• Si l'utilisateur pose une question simple (« Quelle est notre politique de retour ? »), l'agent pourrait répondre directement à partir des connaissances du LLM.
• Si l’utilisateur souhaite connaître l’état de sa commande, l’agent peut appeler une fonction lookup_order(customer_id, order_id). Si cet outil répond par « numéro de commande invalide », l’agent peut réessayer ou inviter l’utilisateur à saisir l’ID correct, et ce, jusqu’à ce qu’il puisse fournir une réponse finale.

Quand utiliser :

• Vous vous attendez à des queries utilisateur variées, mais toujours au sein d'un domaine ou d'une zone de produit cohérente.
• Certaines requêtes ou conditions peuvent justifier l'utilisation d'outils, comme la décision du moment de récupérer les données client.
• Vous souhaitez plus de flexibilité qu'une chaîne déterministe, mais ne nécessitez pas 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 (le cas échéant) à appeler.
• L'agent peut parcourir les appels LLM répétés ou les invocations d'outils pour affiner les résultats – sans avoir besoin d'une configuration multi-agents complète.
• Ce modèle de conception est souvent l'équilibre idéal pour les cas d'utilisation en 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 prémunir contre les appels d'outils répétés ou non valides. Les boucles infinies peuvent se produire dans tout scénario d'appel d'outil, il faut donc définir des limites d'itération ou des délais d'expiration.
• Si votre application couvre des sous-domaines radicalement différents (finance, DevOps, Marketing, etc.), un agent unique peut devenir difficile à gérer ou surchargé en exigences fonctionnelles.
• Vous avez toujours besoin de prompts et de contraintes soigneusement conçus pour maintenir l’agent concentré et pertinent.
• L'autonomie est un continuum ; plus vous donnez de liberté aux modèles pour contrôler le comportement du système, plus l'application devient autonome. En pratique, la plupart des systèmes de production limitent soigneusement l'autonomie de l'agent pour assurer la conformité et la prévisibilité, par exemple en exigeant une approbation humaine pour les actions risquées.

Système multi-agent

Un système multi-agent implique deux agents spécialisés ou plus qui échangent des messages ou collaborent sur des tâches. Chaque agent possède sa propre expertise de domaine ou de tâche, son contexte et des ensembles d’outils potentiellement distincts. Un « coordinateur » ou un « superviseur IA » distinct dirige les requêtes vers l’agent approprié, ou décide quand transférer le travail d’un agent à un autre. Le superviseur peut être un autre LLM ou un routeur basé sur des règles.

Par exemple, un assistant client peut avoir un superviseur qui délègue à des agents spécialisés :

• Assistant d'achat : aide les clients à rechercher des produits et fournit des conseils sur les avantages et les inconvénients à partir des avis
• Agent de support client : Gère les retours, les retours et l'expédition

Quand utiliser :

• Vous avez des domaines problématiques 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 une collaboration mutuelle entre des agents spécialisés.

Avantages :

• Cette approche modulaire signifie que chaque agent peut être développé ou maintenu par des équipes distinctes, spécialisées dans un domaine restreint.
• Peut gérer des workflows d'entreprise volumineux et complexes qu'un seul agent pourrait avoir du mal à gérer de manière cohérente.
• Facilite un raisonnement avancé en plusieurs étapes ou à plusieurs perspectives — par exemple, un agent générant une réponse, un autre la vérifiant.

Considérations :

• Nécessite une stratégie de routage entre les agents, plus la surcharge pour la journalisation, le traçage et le debugging à travers plusieurs endpoints.
• Si vous avez de nombreux sous-agents et outils, il peut devenir compliqué de décider quel agent a accès à quelles données ou APIs.
• Les agents peuvent se renvoyer des tâches indéfiniment entre eux sans résolution s'ils ne sont pas soigneusement contraints. Les risques de boucles infinies existent également dans les appels d'outils à agent unique, mais les configurations multi-agents ajoutent une couche supplémentaire de complexité de debugging.

Conseils pratiques

Si votre cas d'utilisation peut être résolu à l'aide de l'assistant de connaissances ou d'une offre de fonctions d'IA, alors start par cette option guidée et plus simple.

Si vous devez créer un système d'agents personnalisés, Databricks et les Agents personnalisés sont indépendants du modèle que vous choisissez, ce qui facilite l'évolution des modèles de conception à mesure que votre application se développe. Considérez les bonnes pratiques suivantes pour développer des systèmes agents stables et faciles à maintenir :

1. Start simple: si vous n’avez besoin que d’une chaîne simple, une chaîne déterministe est rapide à construire.
2. Ajoutez de la complexité progressivement : À mesure que vous avez besoin de queries plus dynamiques ou de sources de données flexibles, passez à un système à agent unique avec appel d'outils. Si vous avez des domaines ou des tâches clairement distincts, de multiples contextes de conversation ou un vaste ensemble d'outils, alors envisagez un système multi-agent.
3. Combiner les modèles : en pratique, de nombreux systèmes d'agents réels combinent des modèles. Par exemple, une chaîne majoritairement déterministe peut comporter une étape où le LLM peut appeler dynamiquement certaines APIs si nécessaire.

Directives de développement

• Invites et outils.

  • Gardez les invites claires et minimales pour éviter les instructions contradictoires, les information distrayantes et réduire les hallucinations.
  • Fournissez uniquement les outils et le contexte requis par votre agent, plutôt qu’un ensemble d’APIs illimité ou un contexte largement non pertinent. Choisissez votre approche d’outil pendant la conception.

• Journalisation et observabilité

  • Implémentez une journalisation détaillée pour chaque requête utilisateur, plan d'agent et appel d'outil à l'aide de MLflow Tracing.
  • Stockez les Logs en toute sécurité et soyez attentif aux informations personnellement identifiables (PII) dans les données de conversation. Envisagez la classification des données pour l’automatisation.

Guide de test et d'itération

• Évaluation

  • Utilisez l'évaluation MLflow et le monitoring de production pour définir des métriques d'évaluation pour le développement et la production.
  • Recueillez les commentaires des utilisateurs auprès des experts et des utilisateurs pour vous assurer que vos métriques d'évaluation automatisées sont bien calibrées.

• Gestion des erreurs et logique de fallback

  • Planifiez les défaillances des outils ou des LLM. Les délais d'expiration, les réponses mal formées ou les résultats vides peuvent interrompre un workflow. Incluez des stratégies de nouvelle tentative, une logique de fallback ou une chaîne de fallback plus simple lorsque les fonctionnalités avancées échouent.

• Améliorations itératives

  • Attendez-vous à affiner les prompts et la logique de l'agent au fil du temps. Gérez les versions des modifications à l'aide du registre de prompts MLflow pour vos prompts. La gestion des versions simplifiera les opérations et permettra les restaurations et les comparaisons.
  • Lorsque vous collectez des données d'évaluation et définissez des métriques, envisagez des méthodes d'optimisation plus automatisées telles que l'optimisation d'invites MLflow.

Guides de production

• Mises à jour de modèle et épinglage de version

  • Les comportements des LLM peuvent changer lorsque les fournisseurs mettent à jour les modèles en coulisses. Utilisez l'épinglage de version et des tests de régression fréquents pour garantir que votre logique d'agent reste robuste et stable.

• Optimisation de la latence et des coûts

  • Chaque appel LLM ou d'outil supplémentaire augmente l'utilisation des jetons et le temps de réponse. Dans la mesure du possible, combinez les étapes ou mettez en cache les requêtes répétées pour maintenir des performances et un coût gérables.

• Sécurité et sandbox

  • Si votre agent peut mettre à jour des enregistrements ou exécuter du code, mettez ces actions en sandbox ou exigez une approbation humaine si nécessaire. Ceci est essentiel dans les environnements d'entreprise ou réglementés pour éviter tout préjudice involontaire. Les fonctions Unity Catalog fournissent une exécution en sandbox pour la production.
  • Consultez Connecter des agents à des outils pour plus de conseils sur les options d'outils.

En suivant ces directives, vous pouvez atténuer la plupart des modes de défaillance courants tels que les erreurs d'appel d'outil, la dérive de la performance des LLM ou les pics de coûts inattendus, et construire des systèmes d'agents plus fiables et évolutifs.