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

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

• 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 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 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 d'IA peuvent être alimentées par un éventail de systèmes, allant des simples appels LLM aux systèmes multi-agents complexes. Lors de la création de toute application basée sur l'IA, start simplement. Introduisez des comportements agentiques 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 agentiques plus nombreuses offrent une plus grande flexibilité et un potentiel accru, mais elles s'accompagnent d'un coût de complexité supplémentaire et d'une 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 dispose d'un LLM autonome ou d'un autre modèle d'IA qui répond aux invites basées sur les connaissances issues d'un vaste dataset d'entraînement. Cette conception est adaptée aux queries simples ou génériques, mais elle est souvent déconnectée de vos données commerciales réelles. Vous pouvez personnaliser le comportement en fournissant une invite système avec vos instructions personnalisées ou des données embarquées.

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

Les chaînes déterministes augmentent les modèles d'IA avec l'appel d'outils, mais le développeur définit quels outils ou modèles sont appelés, dans quel ordre et avec quels parameters. Le LLM ne prend pas de décisions concernant les outils à appeler ni l'ordre dans lequel les appeler. Le système suit un workflow ou une « chaîne » prédéfini pour toutes les requêtes, ce qui le rend hautement 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 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 MCPs and agent tools pour plus d’informations 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.