15 Outils d'observabilité d'agents IA: AgentOps & Langfuse

Les outils d'observabilité d'agents IA, tels que Langfuse et Arize, aident à rassembler des traces détaillées (un enregistrement de l'exécution d'un programme ou d'une transaction) et fournissent des tableaux de bord pour suivre les métriques en temps réel.

De nombreux frameworks d'agents, comme LangChain, utilisent la norme OpenTelemetry pour partager des métadonnées avec la surveillance agentic. En plus de cela, de nombreux outils d'observabilité fournissent une instrumentation personnalisée pour plus de flexibilité.

Nous avons testé 15 plateformes d'observabilité pour les applications LLM et les agents IA. Chaque plateforme a été mise en œuvre manuellement en configurant des flux de travail, en configurant des intégrations et en exécutant des scénarios de test. Nous avons effectué un benchmark de 4 outils d'observabilité pour mesurer s'ils introduisent une surcharge dans les pipelines de production. Nous avons également démontré un LangChain tutoriel d'observabilité utilisant Langfuse.

Benchmark de la surcharge des outils de surveillance agentic

Nous avons intégré chaque plateforme d'observabilité dans notre système de planification de voyages multi-agents et exécuté 100 requêtes identiques pour mesurer leur surcharge de performance par rapport à une référence sans instrumentation. Lisez notre méthodologie de benchmark.

• LangSmith a démontré une efficacité exceptionnelle avec une surcharge pratiquement imperceptible, ce qui le rend idéal pour les environnements de production critiques en termes de performance.
• Laminar a introduit une surcharge minimale de 5 %, ce qui le rend très adapté aux environnements de production où la performance est critique.
• AgentOps et Langfuse ont montré une surcharge modérée de 12 % et 15 % respectivement, proxy un compromis raisonnable entre les fonctionnalités d'observabilité et l'impact sur la performance. Ces plateformes maintiennent toujours une latence acceptable pour la plupart des cas d'utilisation en production.

Raisons potentielles des différences de performance

Notre benchmark indique que les différences de latence sont dues à la profondeur de l'instrumentation et à l'implication du chemin d'exécution, en particulier dans les flux de travail multi-agents. Les outils offrant une observabilité plus profonde au niveau des étapes ont présenté une surcharge plus élevée, tandis que les approches de traçage plus légères sont restées plus proches de la référence.

1. Profondeur de l'instrumentation sur le chemin d'exécution

Les outils d'observabilité ajoutent une logique au flux d'exécution de l'agent pour capturer des traces et des métadonnées. Lorsque cette logique s'exécute de manière synchrone pendant la gestion des requêtes, elle augmente directement la latence de bout en bout car l'agent doit accomplir ce travail supplémentaire avant de renvoyer une réponse.

Par exemple :

• LangSmith a ajouté une surcharge pratiquement imperceptible (~0 %), indiquant peu de travail synchrone,
• L'instrumentation plus profonde au niveau des étapes de Langfuse a contribué à une surcharge plus élevée (~15 %).

2. Amplification des événements dans les pipelines multi-étapes

Dans les systèmes multi-agents, une seule requête utilisateur déclenche plusieurs actions d'agent. Lorsqu'un outil enregistre des données détaillées à chaque étape, le nombre total d'événements augmente rapidement, augmentant la surcharge de traitement et de gestion des traces à mesure que le flux de travail devient plus profond.

Dans les résultats du benchmark :

• Langfuse et AgentOps ont généré une surcharge nettement plus élevée (15 % et 12 %) dans notre flux de travail de planification de voyages multi-étapes
• LangSmith et Laminar ont émis moins d'événements par étape d'agent.

3. Surcharge d'évaluation et de validation en ligne

Certaines plateformes effectuent des vérifications ou une surveillance supplémentaires pendant l'exécution de l'agent. Bien que chaque vérification soit légère, leur application répétée à toutes les étapes de l'agent ajoute une latence mesurable.

Par exemple :

• La surveillance au niveau du cycle de vie de AgentOps coïncidait avec une surcharge de 12 %
• Laminar n'a montré aucune preuve d'évaluation en ligne affectant l'exécution, est resté à ~5 %.

4. Fréquence de sérialisation et de persistance

Capturer des données d'observabilité détaillées nécessite de sérialiser les traces et de les écrire dans un stockage ou des backends externes. Une plus grande détail des traces augmente la fréquence de cette opération, ajoutant une surcharge d'E/S à chaque requête.

Dans notre benchmark :

• Le traçage détaillé des prompts, des sorties et des tokens de Langfuse a entraîné la surcharge la plus élevée (~15 %)
• Les artefacts de trace plus légers de LangSmith sont restés proches de la référence.

5. Intégration serrée avec le framework d'agent

La façon dont un outil s'intègre au framework d'agent affecte la performance. Des intégrations plus serrées réduisent les étapes de traduction et d'orchestration, tandis que des SDK plus génériques ajoutent des couches de traitement supplémentaires.

Par exemple :

• L'alignement serré de LangSmith avec l'exécution de l'agent était corrélé à une surcharge de ~0 %
• AgentOps et Langfuse ont montré un impact de latence plus élevé, cohérent avec des chemins d'intégration plus découplés.

Plateformes d'observabilité d'agents IA

Niveau 1 : Observabilité fine des LLM et des prompts / sorties

* Les capacités listées dans ces colonnes sont des exemples illustratifs de ce que chaque outil peut surveiller lorsqu'il est étendu via des intégrations ou une personnalisation. Ceux-ci ne sont pas exclusifs à une seule plateforme.

Niveau 2 : Observabilité du flux de travail, du modèle et de l'évaluation

Niveau 3 : Observabilité du cycle de vie et des opérations de l'agent

Niveau 4 : Surveillance du système et de l'infrastructure (non native à l'agent)

Datadog (avec son module d'LLM Observability) et Prometheus (via des exportateurs) sont de plus en plus utilisés aux côtés de Langfuse/LangSmith.

Plateformes de développement et d'orchestration d'agents :

• Des outils comme Flowise, Langflow, SuperAGI et CrewAI permettent de construire, d'orchestrer et d'optimiser des flux de travail d'agents avec des interfaces sans code/low-code

Déploiement, éditions gratuites et tarification

Les éditions gratuites varient selon les limites d'utilisation (par ex., observations, traces, tokens ou unités de travail). Les prix de départ sont généralement pour un plan de base, qui peut avoir des restrictions sur les fonctionnalités, les utilisateurs ou les limites d'utilisation.

Weights & Biases (W&B Weave)

Cas d'utilisation : Débogage des échecs dans les systèmes multi-agents en traçant comment les erreurs se propagent à travers les appels d'agent.

Figure 1 : Tableau de bord des traces de Weights & Biases Weave.

Weights & Biases Weave enregistre des traces d'exécution structurées pour les systèmes multi-agents, préservant les relations parent-enfant entre les appels d'agent. Les entrées, sorties, états intermédiaires, latence et utilisation de tokens sont capturés par agent et par trace.

Fonctionnalités de surveillance de Weave

• Traçage hiérarchique des agents plutôt que des journaux de requêtes plats
• Attribution des coûts et de la latence au niveau de l'agent
• Support natif pour les scoreurs d'évaluation appliqués directement aux traces.

Capacités d'évaluation

Weave fournit également des scoreurs intégrés pour l'évaluation, notamment :

• HallucinationFreeScorer pour détecter les hallucinations,
• SummarizationScorer pour évaluer la qualité du résumé,
• EmbeddingSimilarityScorer pour la similarité sémantique,
• ValidJSONScorer et ValidXMLScorer pour la validation du format,
• PydanticScorer pour la conformité du schéma,
• OpenAIModerationScorer pour la sécurité du contenu,
• Les scoreurs RAGAS comme ContextEntityRecallScorer,
• ContextRelevancyScorer pour l'évaluation du système RAG.

Mieux adapté pour : Les équipes exécutant des flux de travail multi-étapes ou multi-agents qui ont besoin d'une analyse des causes profondes au niveau des traces plutôt que de métriques de surface.

Langfuse

Cas d'utilisation : Suivre les interactions LLM, gérer les versions de prompts et surveiller la performance du modèle avec des sessions utilisateur.

Figure 2 : Exemple de tableau de bord Langfuse montrant les détails de la trace.¹

Langfuse offre une visibilité approfondie sur la couche de prompt, capturant les prompts, les réponses, les coûts et les traces d'exécution pour aider à déboguer, surveiller et optimiser les applications LLM.

Cependant, Langfuse peut ne pas convenir aux équipes qui préfèrent les flux de travail basés sur Git pour la gestion du code et des prompts, car son système de gestion de prompts externe peut ne pas offrir le même niveau de contrôle de version et de collaboration.

Fonctionnalités de surveillance de Langfuse

• Visibilité sur l'évolution et les modèles d'utilisation des prompts
• Analyse basée sur les sessions adaptée aux applications destinées aux utilisateurs
• Modèle de métadonnées et de balisage pratique pour le filtrage et l'examen

Fonctionnalités de niveau entreprise :

Certaines de ces fonctionnalités incluent :

• Niveaux de journalisation : Ajustez la verbosité des journaux pour des insights plus granulaires.
• Multi-modalité : Prend en charge le texte, les images, l'audio et d'autres formats pour les applications LLM multi-modales.
• Sorties & versioning : Suivez l'historique des versions et voyez comment les nouvelles sorties affectent la performance du modèle.
• URL de traces : Accédez à des traces détaillées via des URL uniques pour une inspection et un débogage supplémentaires.
• Graphes d'agents : Visualisez les interactions et les dépendances des agents pour une meilleure compréhension du comportement de l'agent.
• Échantillonnage : Collectez des données représentatives des interactions pour analyser sans submerger le système.
• Suivi des tokens & des coûts : Suivez l'utilisation des tokens et les coûts pour chaque appel de modèle, assurant une gestion efficace des ressources.
• Masquage : Protégez les données sensibles en les masquant dans les traces, assurant la confidentialité et la conformité.

Mieux adapté pour : Les équipes itérant sur les prompts et surveillant l'utilisation en production, en particulier là où les sessions utilisateur comptent.

Galileo

Cas d'utilisation : Surveiller le coût/la latence, évaluer la qualité de la sortie, bloquer les réponses non sécurisées et fournir des correctifs exploitables.

Figure 3 : Graphiques montrant la qualité de sélection d'outils, l'adhésion au contexte, la compilation des actions d'agent et le temps jusqu'au premier token.

Galileo suit les métriques de coût, de latence et de qualité de sortie tout en appliquant des vérifications de sécurité et de conformité en temps réel.

La plateforme combine l'observabilité traditionnelle (latence, coût, performance) avec le débogage et l'évaluation alimentés par l'IA (détection d'hallucinations, exactitude factuelle, cohérence, adhésion au contexte).

Fonctionnalités de surveillance de Galileo

• Identification des modes d'échec au-delà des erreurs de surface (par ex., hallucinations conduisant à des entrées d'outils invalides)
• Retour prescriptif tel que des changements de prompts suggérés ou des ajouts few-shot
• Couplage serré entre les résultats d'évaluation et les correctifs recommandés.

Mieux adapté pour : Les organisations privilégiant la qualité de sortie, la sécurité et les cycles d'itération rapides avec une remédiation guidée.

Guardrails AI

Cas d'utilisation : Prévenir les sorties nuisibles, valider les réponses LLM et assurer la conformité avec les politiques de sécurité

Figure 4 : Tableau de bord de comportement de garde montrant les différences dans la durée d'exécution de la garde et les échecs de garde.

Guardrails valide les entrées et sorties LLM par rapport à des règles configurables, y compris la toxicité, les biais, l'exposition PII, les signaux d'hallucinations et la conformité du format.

Fonctionnalités de surveillance de Guardrails AI

• Validation déterministe via les spécifications RAIL
• Gardes d'entrée pour la détection d'injection de prompts et de jailbreak
• Nouvelles tentatives automatiques en cas d'échec de validation.

Mieux adapté pour
Les équipes qui doivent faire respecter des garanties strictes de sécurité, de conformité ou de formatage avant que les réponses ne soient renvoyées.

LangSmith

Cas d'utilisation : Débogage du raisonnement et des appels d'outils de l'agent (centré sur LangChain)

Figure 5 : Tableau de bord LangSmith montrant des traces, y compris leurs noms, entrées, heures de début et latences.

LangSmith capture des traces de raisonnement complètes pour les agents basés sur LangChain, y compris les prompts, le contexte récupéré, la logique de sélection d'outils, les entrées/sorties d'outils, les erreurs et les exceptions.

Fonctionnalités de surveillance de LangSmith

• Inspection étape par étape des chemins de décision de l'agent
• Jeu de lecture et comparaison côte à côte à travers les prompts, les modèles ou les outils
• Intégration serrée avec LangChain via des callbacks.

Mieux adapté pour
Les équipes construisant avec LangChain qui doivent déboguer un raisonnement incorrect ou une invocation d'outil en détail.

Langtrace AI

Cas d'utilisation : Identifier les goulots d'étranglement de coût et de latence dans les applications LLM

Figure 6 : Tableau de bord de trace Langtrace AI.

Langtrace suit les nombres de tokens, la durée d'exécution, les coûts API et les paramètres de requête à travers les pipelines LLM en utilisant des traces compatibles OpenTelemetry.

Fonctionnalités de surveillance de Langtrace AI

• Alignement OpenTelemetry pour l'intégration avec les backends existants
• Visibilité sur les facteurs de coût et de latence par étape
• Versioning léger des prompts et bac à sable de test.

Mieux adapté pour : Les équipes optimisant la performance et les dépenses à travers les flux de travail LLM plutôt que d'évaluer la qualité de sortie.

Arize (Phoenix)

Cas d'utilisation : Surveiller la dérive du modèle, détecter les biais et évaluer les sorties LLM avec des systèmes de notation complets

Figure 7 : Tableau de bord de surveillance de dérive Arize Phoenix.

Phoenix se concentre sur la dérive comportementale, la détection de biais et le score LLM-as-a-judge pour la pertinence, la toxicité et l'exactitude.

Cependant, il a une surcharge d'intégration plus élevée par rapport aux proxies légers et ne gère pas le versioning des prompts aussi proprement que les outils dédiés.

Fonctionnalités de surveillance de Phoenix

• Cœur open-source avec extensions d'entreprise optionnelles
• Bac à sable de prompt interactif pour le développement
• Détection de dérive pour suivre les changements comportementaux dans le temps
• Vérifications de biais pour identifier les biais de réponse,
• Score LLM-as-a-judge pour l'exactitude, la toxicité et la pertinence.

Mieux adapté pour : Les équipes surveillant le comportement à long terme du modèle et le risque de régression plutôt que l'itération de prompts.

Agenta

Cas d'utilisation : Trouver quel prompt fonctionne le mieux sur quel modèle

Figure 8 : Image montrant diverses alternatives de prompts d'Agenta.

Agenta compare les réponses du modèle à travers le coût, la latence et la qualité de sortie en utilisant des entrées partagées et un contexte contrôlé.

Figure 9 : Exemple de sortie d'Agenta.

Fonctionnalités de surveillance d'Agenta

• Évaluation de modèle côte à côte
• Soutien à la décision pré-production.

Mieux adapté pour : Évaluation précoce et sélection de modèle.

AgentOps.ai

Cas d'utilisation : Surveiller le raisonnement de l'agent, suivre les coûts et déboguer les sessions en production

Figure 10 : Exemple de tableau de bord de replay de session de AgentOps.ai.

AgentOps capture des traces de raisonnement, des appels d'outils/API, l'état de session, le comportement de mise en cache et les métriques de coût pour les agents déployés.

Fonctionnalités de surveillance de AgentOps

• Replay de session pour le débogage en production
• Focus sur le comportement de l'agent en direct plutôt que sur l'évaluation hors ligne.

Mieux adapté pour : Les équipes exécutant des agents en production qui ont besoin de visibilité opérationnelle.

Braintrust

Cas d'utilisation : Trouver quel prompt, dataset ou modèle fonctionne mieux avec une évaluation détaillée et une analyse des erreurs

Figure 11 : Tableau de bord d'agent de support client de Braintrust.

Braintrust évalue les prompts, les datasets et les modèles par rapport aux sorties attendues, en suivant la latence, le coût, les erreurs d'outils et les métriques d'exécution.

Fonctionnalités de surveillance de Braintrust

• Évaluer les datasets de test avec des entrées et des sorties attendues, puis comparer les prompts ou les modèles côte à côte en utilisant des variables comme {{input}}, {{expected}}, et {{metadata}}.
• Détails des métriques incluant la qualité d'exécution des outils

Mieux adapté pour : Les équipes effectuant un benchmark de modèles et de prompts avant le déploiement.

Découvrez davantage de nos benchmarks et analyses basées sur les données dans la recherche Google.

Ajouter comme source préférée

AgentNeo

Cas d'utilisation : Déboguer les interactions multi-agents, tracer l'utilisation des outils et évaluer les flux de travail de coordination

AgentNeo suit la communication des agents, l'utilisation des outils, les graphes d'exécution et le coût et la latence par agent via un SDK Python.

Fonctionnalités de surveillance d'AgentNeo

• Open-source et exécutable localement
• Tableau de bord interactif local (localhost:3000) pour la surveillance en temps réel des flux de travail multi-agents.
• Intégration utilisant des décorateurs (par ex., @tracer.trace_agent, @tracer.trace_tool)

Mieux adapté pour : Les équipes d'ingénierie expérimentant avec des systèmes multi-agents.

Laminar

Cas d'utilisation : Suivre la performance à travers différents frameworks et modèles LLM.

Figure 12 : Exemple de tableau de bord de traces de Laminar.

Laminar suit les spans d'exécution, les coûts, l'utilisation de tokens et les percentiles de latence à travers les frameworks et modèles LLM.

Fonctionnalités de surveillance de Laminar

• Analyse de performance agnostique du framework
• Inspection fine des spans.

Mieux adapté pour : Analyse comparative de performance à travers des stacks hétérogènes.

Helicone

Cas d'utilisation : Suivre les flux de travail d'agents multi-étapes et analyser les modèles de sessions utilisateur.

Figure 12 : Image montrant 3 mois de changements dans les requêtes, les coûts, les erreurs et la latence.

Helicone capture les volumes de requêtes, les coûts, les erreurs, les tendances de latence et les flux de travail d'agents au niveau de la session.

Fonctionnalités de surveillance de Helicone

• Visibilité du parcours utilisateur
• Analyse des tendances historiques.

Mieux adapté pour : Les équipes produit surveillant les modèles d'utilisation et le comportement au niveau de l'utilisateur.

Coval

Cas d'utilisation : Simuler des milliers de conversations d'agent, tester les interactions vocales/chat et valider le comportement avant le déploiement.

Figure 13 : Tableau de bord d'évaluation de Coval montrant les pourcentages d'objectifs atteints, d'identité vérifiée, de répétition correcte, de clarté de l'agent et d'informations incorrectes.

Coval simule des milliers de conversations pour mesurer l'achèvement des tâches, l'exactitude et l'efficacité des appels d'outils.

Fonctionnalités de surveillance de Coval

• Test d'agent basé sur la simulation
• Détection automatique de régression
• Support des agents vocaux et textuels.

Mieux adapté pour : Validation pré-déploiement et détection de régression.

Datadog

Cas d'utilisation : Observabilité de l'infrastructure et des applications avec corrélation de signal LLM.

Datadog collecte des métriques d'infrastructure (CPU, mémoire, réseau), des données de performance d'application (latence, taux d'erreur, débit) et des journaux. Pour les applications LLM, il peut ingérer l'utilisation de tokens, le coût par requête, la latence du modèle et des signaux liés à la sécurité tels que les tentatives d'injection de prompts.

Fonctionnalités de surveillance de Datadog

• Observabilité large à l'échelle du système à travers l'infrastructure, les applications et les charges de travail IA
• Grand écosystème d'intégration (900+ intégrations) permettant la corrélation entre le comportement IA et la santé de l'infrastructure

Mieux adapté pour : Les organisations qui veulent corréler le comportement LLM avec l'infrastructure sous-jacente et la performance des applications plutôt que d'inspecter le raisonnement de l'agent ou le prompt

Prometheus

Cas d'utilisation : Surveiller la performance du système, suivre les métriques d'application et configurer l'alerting pour les problèmes d'infrastructure.

Prometheus est un système de surveillance open-source qui récupère des métriques de séries temporelles à partir de points de terminaison HTTP à intervalles réguliers pour suivre l'infrastructure, les applications, les bases de données, les conteneurs et les métriques métier personnalisées.

Fonctionnalités de surveillance de Prometheus

• Collecte de métriques de séries temporelles via un scraping basé sur le pull
• PromQL pour les requêtes, l'agrégation et les conditions d'alerte
• Écosystème d'exportateurs (par ex., Node Exporter) pour une couverture système large

Mieux adapté pour : Surveillance de l'infrastructure et des applications avec alerting basé sur des règles.

Grafana

Cas d'utilisation : Visualiser les métriques, construire des tableaux de bord et router les alertes à travers les données LLM, d'agent et d'infrastructure.

Figure 14 : Tableau de bord de traces montrant le changement du taux de requêtes, des tokens d'utilisation totaux, du coût d'utilisation moyen et du coût d'utilisation total.

Grafana est une plateforme de visualisation et d'analyse open-source qui s'intègre avec des sources de données telles que Prometheus, OpenTelemetry et Datadog pour fournir des tableaux de bord d'observabilité unifiés.

Fonctionnalités de surveillance de Grafana

• Tableaux de bord à travers les métriques, les journaux et les traces
• Corrélation inter-système pour les signaux LLM, d'agent et d'infrastructure
• Router les alertes et gérer les notifications.

Mieux adapté pour : Visualisation centralisée de l'observabilité et réponse aux incidents.

Tutoriel : Observabilité LangChain avec Langfuse

Nous avons construit un pipeline LangChain multi-étapes avec trois étapes :

1. analyse de la question
2. génération de réponse
3. vérification de la réponse

Après avoir configuré le pipeline, nous l'avons connecté à Langfuse pour surveiller et suivre l'exécution en temps réel. En faisant cela, nous avons pu explorer comment Langfuse nous aide à rassembler des insights détaillés sur la performance, les coûts et le comportement des applications IA.

Voici ce que nous avons observé à travers Langfuse :

Aperçu du tableau de bord

Figure 15 : Tableaux de bord de coût, de gestion de l'utilisation et de latence de Langfuse.

Langfuse nous a fourni plusieurs tableaux de bord qui nous donnent une visibilité sur différents aspects de la performance du pipeline :

1. Tableau de bord des coûts : Cela suit les dépenses à travers tous les appels API, avec des détails par modèle et par période de temps.
2. Gestion de l'utilisation : Il surveille les métriques d'exécution, telles que les nombres d'observations et l'allocation de ressources, nous aidant à suivre comment les ressources sont utilisées pendant l'exécution.
3. Tableau de bord de latence : Ce tableau de bord nous a aidés à analyser les temps de réponse, détecter les goulots d'étranglement et visualiser les tendances de performance.

Métriques d'utilisation

Figure 16 : Image montrant les métriques d'utilisation de Langfuse, y compris le nombre total de traces, le nombre total d'observations et le nombre total de scores (numériques et catégoriels).

Le tableau de bord des métriques d'utilisation nous a donné les insights suivants sur la performance du système :

• Nombre total de traces : Nous avons suivi huit traces, chacune proxy un cycle complet de question-réponse dans le pipeline.
• Nombre total d'observations : En moyenne, chaque trace avait 16 observations, reflétant la nature multi-étapes du processus.

En plus de cela, Langfuse nous permet de suivre les modèles d'utilisation, l'allocation de ressources et les heures de pointe au cours des 7 derniers jours, nous aidant à comprendre quand le système est le plus actif et comment les ressources sont distribuées dans le temps.

Inspection des traces

Figure 17 : Tableau de bord de traces de Langfuse montrant l'entrée, la sortie, les niveaux d'observabilité, la latence et les tokens.

Lors de l'exploration d'une trace individuelle, nous avons pu voir des informations d'exécution détaillées :

• Lignes de trace : Chaque ligne représente une exécution complète du pipeline avec un ID de trace unique.
• Métriques de latence : Le temps d'exécution variait, allant de 0,00s à 34,08s.
• Nombres de tokens : Le tableau de bord suivait l'utilisation des tokens d'entrée/sortie, ce qui aide dans la gestion des coûts et de l'efficacité.
• Filtrage de l'environnement : Nous pouvions filtrer les traces en fonction des environnements de déploiement (par ex., développement, production).

Détails de la trace individuelle

Figure 18 : Architecture de chaîne séquentielle de Langfuse.

Nous avons exploré plus en détail la trace pour comprendre la répartition de l'exécution :

• Architecture de chaîne séquentielle : La trace affichait un flux visuel montrant chaque étape, commençant par SequentialChain → LLMChain → ChatOpenAI, avec une structure hiérarchique.
• Suivi de l'entrée/sortie : La question originale, "Quels sont les avantages d'utiliser Langfuse pour l'observabilité des agents IA ?" a été suivie à chaque étape, ainsi que les sorties respectives produites par l'IA à chaque étape.
• Analyse des tokens : Nous avons observé que 1 203 tokens ont été utilisés pour l'entrée et 1 516 tokens pour la sortie, ce qui a des implications de coût liées à l'utilisation des tokens et aide à optimiser la gestion des ressources.
• Données de timing : La latence totale pour la trace complète était de 34,08s, répartie sur chaque composant :
  • SequentialChain → 14,02s
  • LLMChain → 10,25s
  • ChatOpenAI → 9,81s
• Informations sur le modèle : Langfuse a confirmé l'utilisation du modèle Anthropic Claude-Sonnet-4, avec des détails sur les paramètres spécifiques, y compris la configuration de température.
• Sortie formatée : Les vues Preview et JSON ont été fournies pour le débogage, donnant des insights sur la réponse du modèle sous une forme lisible par l'homme et un format lisible par la machine.

Analyse automatisée

Figure 19 : Exemple d'évaluations automatisées de Langfuse.

Langfuse a également fourni des évaluations automatisées de nos réponses :

• Évaluation de la qualité : Le système a évalué la structure, la cohérence et l'exhaustivité des réponses, mettant en évidence des sections bien organisées mais suggérant que les réponses pourraient être plus concises.
• Suggestions d'amélioration : Il a identifié des sections avec redondance, suggérant où le libellé pourrait être amélioré, et combiné des points connexes pour rendre la réponse plus transparente et plus efficace.
• Insights de performance : Le système a donné des commentaires sur l'utilisation des tokens et la pertinence de la réponse, nous aidant à optimiser l'efficacité tout en assurant que la sortie reste utile et sur le sujet.
• Retour structuré : Le retour était organisé en catégories, nous permettant de traiter des domaines spécifiques d'amélioration de manière ciblée.

Analytique utilisateur

Figure 20 : L'image montre l'activité utilisateur anonymisée, montrant les premières et dernières interactions de chaque utilisateur, les volumes d'événements, la consommation de tokens et les coûts associés pour aider à analyser l'engagement, l'utilisation des ressources et l'allocation du budget.

Langfuse suit les interactions détaillées entre les utilisateurs et l'agent IA :

• Chronologie de l'activité utilisateur : Affiche la première et la dernière interaction pour chaque utilisateur, aidant à identifier les utilisateurs actifs par rapport aux utilisateurs dormants. Nous pouvons voir quand les utilisateurs ont interagi avec le système pour la première et la dernière fois.
• Suivi du volume d'événements : Suit le nombre d'événements déclenchés par chaque utilisateur. Par exemple, certains utilisateurs ont généré plus de 2 000 événements, montrant leur niveau d'engagement avec le système.
• Analyse de la consommation de tokens : Surveille le nombre total de tokens consommés par chaque utilisateur. L'utilisation de tokens variait de 6,59K à 357K tokens, fournissant des insights sur l'utilisation des ressources.
• Attribution des coûts : Décompose les coûts associés à chaque utilisateur, facilitant le suivi des dépenses et l'optimisation de l'allocation du budget pour l'utilisation des ressources.
• Identification de l'utilisateur : Utilise des ID d'utilisateur anonymisés pour maintenir la confidentialité tout en suivant les interactions individuelles des utilisateurs, aidant à l'analyse de l'utilisation sans compromettre la confidentialité de l'utilisateur.

Figure 21 : Un exemple de vue de session, montrant tout le flux de conversation à côté du code Python exécuté, corrélant les entrées utilisateur avec les sorties système et affichant les métadonnées de session pour donner une image complète de la façon dont l'interaction a été traitée.

La vue de session nous permet de suivre des détails granulaires des interactions utilisateur :

• Flux de conversation complet : Montre l'interaction complète de question-réponse, facilitant le suivi de toute la conversation du début à la fin.
• Visibilité de l'implémentation : Affiche le code Python réel utilisé pendant la session, fournissant un aperçu de l'implémentation technique.
• Corrélation entrée/sortie : Lie les questions utilisateur aux réponses système correspondantes, nous aidant à dépanner et identifier où des problèmes ont pu survenir dans la conversation.
• Métadonnées de session : Inclut des détails techniques tels que le timing, le contexte utilisateur et des données d'implémentation spécifiques, offrant une vue complète de l'exécution de la session.

Quand ne pas utiliser d'outils d'observabilité

• Développement précoce : Si vous validez encore l'adéquation produit-marché ou construisez vos premiers flux de travail d'agent, l'accent devrait être mis sur la fonctionnalité de base plutôt que sur une observabilité extensive.
  
• Goulots d'étranglement API : Si vos problèmes principaux sont les coûts API, la latence ou la mise en cache, la priorité immédiate devrait être d'optimiser ces domaines, pas de suivre les métriques au niveau du système.
  
• Optimisation du modèle : Si les améliorations sont principalement pilotées par la sélection de modèle, le fine-tuning ou l'ingénierie de prompts, les outils d'observabilité pour la dérive et les biais peuvent ne pas encore être nécessaires.

Quand utiliser des outils d'observabilité

• Production à grande échelle : Lorsque vous opérez à travers plusieurs modèles, agents ou chaînes, les outils d'observabilité sont essentiels pour surveiller la performance et assurer la santé du système.
• Applications d'entreprise ou destinées aux clients : Pour les applications où la fiabilité, la sécurité et la conformité sont non négociables, les outils d'observabilité fournissent la visibilité et le contrôle nécessaires.
• Surveillance continue : Lorsque vous devez surveiller la dérive, les biais, la performance et les problèmes de sécurité dans le temps, ce qui ne peut pas être facilement capturé avec des scripts de base ou des vérifications manuelles, les outils d'observabilité sont cruciaux.
• Scénarios à haut risque : Dans les environnements où le coût de l'échec (par ex., hallucinations, sorties non sécurisées) est significatif, l'observabilité assure que les risques sont minimisés et les problèmes détectés tôt.

Méthodologie de benchmark

Pour évaluer la surcharge de performance des plateformes d'observabilité dans les applications LLM de production, nous avons développé une approche de benchmark systématique en utilisant un flux de travail agentic du monde réel.

Application de test

Nous avons construit un système de planification de voyages multi-agents séquentiel utilisant LangChain qui traite les demandes de voyage en langage naturel à travers cinq étapes :

1. Agent analyseur : Extrait des données structurées (origine, destination, dates, durée) à partir de l'entrée utilisateur
2. Agent de recherche de vols : Récupère les vols disponibles via l'API Amadeus
3. Agent rapporteur météo : Récupère les prévisions météorologiques de destination en utilisant WeatherAPI
4. Agent recommandateur d'activités : Suggère des activités basées sur les conditions météorologiques
5. Agent planificateur de voyages : Synthétise toutes les sorties dans un itinéraire complet

Le système utilise Claude 4 Haiku via OpenRouter pour tous les appels LLM et intègre des API externes pour des données en temps réel.

Conception du benchmark

Établissement de la référence : Nous avons d'abord mesuré la performance de l'application sans aucune instrumentation d'observabilité, en exécutant 100 requêtes identiques pour établir une référence de comparaison.

Intégration de la plateforme : Nous avons ensuite intégré cinq plateformes d'observabilité de premier plan (LangSmith, Laminar, AgentOps, Langfuse) une à la fois, instrumentant les mêmes points de traçage sur toutes les plateformes pour la cohérence.

Exécution séquentielle : Chaque plateforme a été testée indépendamment en exécutant toutes les 100 requêtes consécutivement avant de passer à la plateforme suivante. Cette approche minimise la variabilité due à des facteurs externes tels que les conditions réseau ou les limites de taux API.

Environnement contrôlé : Tous les tests ont été exécutés sur la même infrastructure de serveur avec des ensembles de requêtes identiques pour assurer une comparaison équitable. Pour isoler la surcharge des variations de latence induites par LLM, nous avons configuré le modèle avec temperature=0 et des prompts structurés pour minimiser la variabilité de réponse entre les exécutions.

Métriques collectées

Pour chaque plateforme, nous avons mesuré la latence moyenne et calculé la surcharge comme la latence supplémentaire introduite par rapport à la référence : ((Platform Latency - Base Latency) / Base Latency) × 100

FAQ

Citer cette recherche

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{dilmegani2026,
  author = {Dilmegani, Cem},
  title  = {{15 Outils d'observabilité d'agents IA: AgentOps & Langfuse}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/agentic-monitoring}},
  note   = {AIMultiple. Consulté le 2 Juillet 2026}
}

Liens de référence

1.

Model Usage & Cost Tracking for LLM applications (open source) - Langfuse

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017. AIMultiple informe chaque mois des centaines de milliers d'entreprises (selon similarWeb), dont 55 % des entreprises du classement Fortune 500. Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes et le Washington Post, ainsi que par des entreprises mondiales comme Deloitte et HPE, des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne. Vous trouverez d'autres entreprises et ressources réputées ayant fait référence à AIMultiple. Tout au long de sa carrière, Cem a exercé les fonctions de consultant, d'acheteur et d'entrepreneur dans le secteur des technologies. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la numérisation. Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité directe du PDG. Il a également piloté la croissance commerciale de la société de deep tech Hypatos, qui a atteint un chiffre d'affaires annuel récurrent à sept chiffres et une valorisation à neuf chiffres en seulement deux ans. Les travaux de Cem chez Hypatos ont été présentés dans des publications technologiques de référence telles que TechCrunch et Business Insider. Cem intervient régulièrement lors de conférences internationales sur les technologies. Diplômé en génie informatique de l'université de Bogazici, il est également titulaire d'un MBA de la Columbia Business School.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire