Lorsque les agents IA passent de prototypes expérimentaux à des applications réelles, il devient essentiel de comprendre leur comportement, de surveiller leurs performances et d’évaluer systématiquement leurs résultats.
À la fin de cette leçon, vous saurez comment/comprendre :
L’objectif est de vous fournir les connaissances nécessaires pour transformer vos agents “boîte noire” en systèmes transparents, gérables et fiables.
Remarque : Il est important de déployer des agents IA sûrs et dignes de confiance. Consultez également la leçon Construire des Agents IA Fiables.
Les outils d’observabilité tels que Langfuse ou Azure AI Foundry représentent généralement les exécutions des agents sous forme de traces et de spans.
Sans observabilité, un agent IA peut ressembler à une “boîte noire” – son état interne et son raisonnement sont opaques, ce qui rend difficile le diagnostic des problèmes ou l’optimisation des performances. Avec l’observabilité, les agents deviennent des “boîtes de verre”, offrant une transparence essentielle pour instaurer la confiance et garantir qu’ils fonctionnent comme prévu.
Le passage des agents IA en environnement de production introduit un nouvel ensemble de défis et d’exigences. L’observabilité n’est plus un “plus”, mais une capacité essentielle :
Pour surveiller et comprendre le comportement des agents, il est important de suivre une gamme de métriques et de signaux. Bien que les métriques spécifiques puissent varier en fonction de l’objectif de l’agent, certaines sont universellement importantes.
Voici quelques-unes des métriques les plus courantes suivies par les outils d’observabilité :
Latence : Quelle est la rapidité de réponse de l’agent ? Des temps d’attente longs nuisent à l’expérience utilisateur. Vous devriez mesurer la latence des tâches et des étapes individuelles en traçant les exécutions des agents. Par exemple, un agent qui prend 20 secondes pour tous les appels de modèle pourrait être accéléré en utilisant un modèle plus rapide ou en exécutant les appels de modèle en parallèle.
Coûts : Quel est le coût par exécution d’agent ? Les agents IA s’appuient sur des appels LLM facturés par token ou des API externes. Une utilisation fréquente des outils ou de multiples prompts peut rapidement augmenter les coûts. Par exemple, si un agent appelle un LLM cinq fois pour une amélioration marginale de la qualité, vous devez évaluer si le coût est justifié ou si vous pourriez réduire le nombre d’appels ou utiliser un modèle moins cher. Une surveillance en temps réel peut également aider à identifier des pics inattendus (par exemple, des bugs provoquant des boucles API excessives).
Erreurs de requêtes : Combien de requêtes l’agent a-t-il échoué ? Cela peut inclure des erreurs d’API ou des appels d’outils échoués. Pour rendre votre agent plus robuste en production, vous pouvez alors configurer des mécanismes de secours ou des tentatives de reprise. Par exemple, si le fournisseur LLM A est hors service, vous passez au fournisseur LLM B en tant que solution de secours.
Retour utilisateur : Mettre en place des évaluations directes des utilisateurs fournit des informations précieuses. Cela peut inclure des évaluations explicites (👍pouce levé/👎baissé, ⭐1-5 étoiles) ou des commentaires textuels. Des retours négatifs constants devraient vous alerter, car cela indique que l’agent ne fonctionne pas comme prévu.
Retour utilisateur implicite : Les comportements des utilisateurs fournissent des retours indirects même sans évaluations explicites. Cela peut inclure une reformulation immédiate de la question, des requêtes répétées ou le clic sur un bouton de réessai. Par exemple, si vous constatez que les utilisateurs posent plusieurs fois la même question, cela indique que l’agent ne fonctionne pas comme prévu.
Précision : À quelle fréquence l’agent produit-il des résultats corrects ou souhaitables ? Les définitions de précision varient (par exemple, exactitude dans la résolution de problèmes, précision dans la récupération d’informations, satisfaction des utilisateurs). La première étape consiste à définir ce à quoi ressemble le succès pour votre agent. Vous pouvez suivre la précision via des vérifications automatisées, des scores d’évaluation ou des étiquettes de complétion de tâches. Par exemple, marquer les traces comme “réussies” ou “échouées”.
Métriques d’évaluation automatisée : Vous pouvez également configurer des évaluations automatisées. Par exemple, vous pouvez utiliser un LLM pour noter la sortie de l’agent, par exemple si elle est utile, précise ou non. Il existe également plusieurs bibliothèques open source qui vous aident à évaluer différents aspects de l’agent. Par exemple, RAGAS pour les agents RAG ou LLM Guard pour détecter le langage nuisible ou l’injection de prompts.
En pratique, une combinaison de ces métriques offre la meilleure couverture de la santé d’un agent IA. Dans le notebook d’exemple de ce chapitre, nous vous montrerons à quoi ressemblent ces métriques dans des exemples réels, mais d’abord, nous apprendrons à quoi ressemble un workflow d’évaluation typique.
Pour collecter des données de traçage, vous devrez instrumenter votre code. L’objectif est d’instrumenter le code de l’agent pour émettre des traces et des métriques qui peuvent être capturées, traitées et visualisées par une plateforme d’observabilité.
OpenTelemetry (OTel) : OpenTelemetry est devenu une norme industrielle pour l’observabilité des LLM. Il fournit un ensemble d’API, de SDK et d’outils pour générer, collecter et exporter des données de télémétrie.
De nombreuses bibliothèques d’instrumentation enveloppent les frameworks d’agents existants et facilitent l’exportation des spans OpenTelemetry vers un outil d’observabilité. Voici un exemple d’instrumentation d’un agent AutoGen avec la bibliothèque d’instrumentation OpenLit :
import openlit
openlit.init(tracer = langfuse._otel_tracer, disable_batch = True)
Le notebook d’exemple de ce chapitre démontrera comment instrumenter votre agent AutoGen.
Création manuelle de spans : Bien que les bibliothèques d’instrumentation fournissent une bonne base, il existe souvent des cas où des informations plus détaillées ou personnalisées sont nécessaires. Vous pouvez créer manuellement des spans pour ajouter une logique d’application personnalisée. Plus important encore, ils peuvent enrichir les spans créés automatiquement ou manuellement avec des attributs personnalisés (également appelés tags ou métadonnées). Ces attributs peuvent inclure des données spécifiques à l’entreprise, des calculs intermédiaires ou tout contexte utile pour le débogage ou l’analyse, comme user_id
, session_id
ou model_version
.
Exemple de création manuelle de traces et de spans avec le Langfuse Python SDK :
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
L’observabilité nous fournit des métriques, mais l’évaluation est le processus d’analyse de ces données (et de réalisation de tests) pour déterminer dans quelle mesure un agent IA fonctionne et comment il peut être amélioré. En d’autres termes, une fois que vous avez ces traces et métriques, comment les utilisez-vous pour juger l’agent et prendre des décisions ?
L’évaluation régulière est importante car les agents IA sont souvent non déterministes et peuvent évoluer (par des mises à jour ou des dérives de comportement du modèle) – sans évaluation, vous ne sauriez pas si votre “agent intelligent” fait bien son travail ou s’il a régressé.
Il existe deux catégories d’évaluations pour les agents IA : évaluation hors ligne et évaluation en ligne. Les deux sont précieuses et se complètent. Nous commençons généralement par l’évaluation hors ligne, car c’est l’étape minimale nécessaire avant de déployer un agent.
Cela consiste à évaluer l’agent dans un environnement contrôlé, généralement à l’aide de jeux de données de test, et non de requêtes d’utilisateurs en direct. Vous utilisez des jeux de données sélectionnés où vous connaissez le résultat attendu ou le comportement correct, puis vous exécutez votre agent sur ceux-ci.
Par exemple, si vous avez construit un agent pour résoudre des problèmes mathématiques, vous pourriez avoir un jeu de données de test de 100 problèmes avec des réponses connues. L’évaluation hors ligne est souvent réalisée pendant le développement (et peut faire partie des pipelines CI/CD) pour vérifier les améliorations ou éviter les régressions. L’avantage est qu’elle est répétable et vous pouvez obtenir des métriques de précision claires puisque vous avez une vérité terrain. Vous pourriez également simuler des requêtes d’utilisateurs et mesurer les réponses de l’agent par rapport à des réponses idéales ou utiliser des métriques automatisées comme décrit ci-dessus.
Le principal défi de l’évaluation hors ligne est de s’assurer que votre jeu de données de test est complet et reste pertinent – l’agent pourrait bien fonctionner sur un ensemble de test fixe mais rencontrer des requêtes très différentes en production. Par conséquent, vous devriez maintenir les ensembles de test à jour avec de nouveaux cas limites et exemples reflétant des scénarios réels. Un mélange de petits cas de “test rapide” et de plus grands ensembles d’évaluation est utile : petits ensembles pour des vérifications rapides et plus grands pour des métriques de performance plus larges.
Cela consiste à évaluer l’agent dans un environnement réel, c’est-à-dire pendant son utilisation en production. L’évaluation en ligne implique de surveiller les performances de l’agent sur des interactions réelles avec les utilisateurs et d’analyser les résultats en continu.
Par exemple, vous pourriez suivre les taux de réussite, les scores de satisfaction des utilisateurs ou d’autres métriques sur le trafic en direct. L’avantage de l’évaluation en ligne est qu’elle capture des éléments que vous pourriez ne pas anticiper en laboratoire – vous pouvez observer la dérive du modèle au fil du temps (si l’efficacité de l’agent diminue à mesure que les schémas d’entrée évoluent) et détecter des requêtes ou situations inattendues qui n’étaient pas dans vos données de test. Elle fournit une image fidèle du comportement de l’agent dans la réalité.
L’évaluation en ligne implique souvent de collecter des retours implicites et explicites des utilisateurs, comme discuté, et éventuellement de réaliser des tests en parallèle ou des tests A/B (où une nouvelle version de l’agent fonctionne en parallèle pour comparer avec l’ancienne). Le défi est qu’il peut être difficile d’obtenir des étiquettes ou des scores fiables pour les interactions en direct – vous pourriez vous appuyer sur les retours des utilisateurs ou des métriques en aval (comme si l’utilisateur a cliqué sur le résultat).
Les évaluations en ligne et hors ligne ne sont pas mutuellement exclusives ; elles se complètent fortement. Les informations issues de la surveillance en ligne (par exemple, de nouveaux types de requêtes utilisateur où l’agent fonctionne mal) peuvent être utilisées pour enrichir et améliorer les jeux de données de test hors ligne. Inversement, les agents qui fonctionnent bien lors des tests hors ligne peuvent ensuite être déployés et surveillés en ligne avec plus de confiance.
En fait, de nombreuses équipes adoptent une boucle :
évaluer hors ligne -> déployer -> surveiller en ligne -> collecter de nouveaux cas d’échec -> ajouter au jeu de données hors ligne -> affiner l’agent -> répéter.
Lorsque vous déployez des agents IA en production, vous pouvez rencontrer divers défis. Voici quelques problèmes courants et leurs solutions potentielles :
Problème | Solution Potentielle |
---|---|
L’agent IA n’exécute pas les tâches de manière cohérente | - Affinez le prompt donné à l’agent IA ; soyez clair sur les objectifs. - Identifiez où diviser les tâches en sous-tâches et les confier à plusieurs agents peut aider. |
L’agent IA entre dans des boucles continues | - Assurez-vous d’avoir des termes et conditions de terminaison clairs pour que l’agent sache quand arrêter le processus. |
Pour les tâches complexes nécessitant un raisonnement et une planification, utilisez un modèle plus grand spécialisé dans les tâches de raisonnement. | ||
Les appels d’outils d’agent AI ne fonctionnent pas bien | - Testez et validez les résultats des outils en dehors du système d’agent. - Affinez les paramètres définis, les invites et les noms des outils. |
|
Le système multi-agents ne fonctionne pas de manière cohérente | - Affinez les invites données à chaque agent pour garantir qu’elles soient spécifiques et distinctes les unes des autres. - Construisez un système hiérarchique en utilisant un agent “routeur” ou contrôleur pour déterminer quel agent est le plus approprié. |
Beaucoup de ces problèmes peuvent être identifiés plus efficacement avec une observabilité en place. Les traces et métriques que nous avons discutées précédemment aident à localiser précisément où dans le flux de travail de l’agent les problèmes surviennent, rendant le débogage et l’optimisation beaucoup plus efficaces.
Voici quelques stratégies pour gérer les coûts liés au déploiement des agents AI en production :
Utilisation de modèles plus petits : Les Small Language Models (SLMs) peuvent bien fonctionner pour certains cas d’utilisation agentiques et réduiront considérablement les coûts. Comme mentionné précédemment, construire un système d’évaluation pour déterminer et comparer les performances par rapport aux modèles plus grands est le meilleur moyen de comprendre à quel point un SLM peut répondre à votre cas d’utilisation. Envisagez d’utiliser des SLMs pour des tâches plus simples comme la classification d’intentions ou l’extraction de paramètres, tout en réservant les modèles plus grands pour les tâches de raisonnement complexes.
Utilisation d’un modèle routeur : Une stratégie similaire consiste à utiliser une diversité de modèles et de tailles. Vous pouvez utiliser un LLM/SLM ou une fonction sans serveur pour router les requêtes en fonction de leur complexité vers les modèles les plus adaptés. Cela permettra également de réduire les coûts tout en garantissant des performances optimales pour les tâches appropriées. Par exemple, routez les requêtes simples vers des modèles plus petits et rapides, et utilisez uniquement des modèles grands et coûteux pour les tâches de raisonnement complexes.
Mise en cache des réponses : Identifier les requêtes et tâches courantes et fournir les réponses avant qu’elles ne passent par votre système agentique est une bonne manière de réduire le volume de requêtes similaires. Vous pouvez même mettre en place un flux pour identifier à quel point une requête est similaire à vos requêtes mises en cache en utilisant des modèles AI plus basiques. Cette stratégie peut réduire significativement les coûts pour les questions fréquemment posées ou les flux de travail courants.
Dans le notebook d’exemple de cette section, nous verrons des exemples de l’utilisation des outils d’observabilité pour surveiller et évaluer nos agents.
Rejoignez le Discord Azure AI Foundry pour rencontrer d’autres apprenants, assister à des heures de bureau et obtenir des réponses à vos questions sur les agents AI.
Design Pattern de Métacognition
Avertissement :
Ce document a été traduit à l’aide du service de traduction automatique Co-op Translator. Bien que nous nous efforcions d’assurer l’exactitude, veuillez noter que les traductions automatisées peuvent contenir des erreurs ou des inexactitudes. Le document original dans sa langue d’origine doit être considéré comme la source faisant autorité. Pour des informations critiques, il est recommandé de recourir à une traduction professionnelle réalisée par un humain. Nous déclinons toute responsabilité en cas de malentendus ou d’interprétations erronées résultant de l’utilisation de cette traduction.