LLM Outils d'observabilité: Weights & Biases, Langsmith

Les applications LLM sont passées de chats à un seul tour à des agents multi-étapes qui utilisent des outils, interrogent des bases de données et se coordonnent avec d’autres modèles, ce qui rend leur comportement plus difficile à interpréter.

L’observabilité des LLM offre une visibilité continue sur ces flux de travail complexes, aidant les organisations à surveiller la qualité, détecter les défaillances, résoudre les problèmes, et gérer les performances et les coûts.

LLM : Comparaison des fonctionnalités des outils d’observabilité

Weights & Biases (W&B Weave)

W&B Weave est la plateforme Weights & Biases d’LLM observabilité pour surveiller, évaluer et optimiser les applications de modèles de langage. Weave suit automatiquement chaque appel LLM à l’aide du décorateur @weave.op, en capturant les entrées, les sorties, les coûts, la latence et les métriques d’évaluation sans configuration manuelle.

La plateforme suit l’utilisation des tokens et calcule automatiquement les coûts, surveille les temps de réponse pour détecter les requêtes lentes et mesure la précision en comparant les prédictions aux résultats attendus. Différentes expériences peuvent être comparées côte à côte pour voir quel modèle ou prompt fonctionne le mieux. Le suivi des erreurs montre quelles prédictions ont échoué et pourquoi, tandis que la gestion automatique des versions préserve chaque changement de configuration à des fins de reproductibilité. Cela facilite le test de différentes approches, l’identification de ce qui fonctionne le mieux et le débogage des problèmes lorsque les modèles font des erreurs.

Tableau de bord de synthèse des scores

Figure 1 : Graphiques montrant le tableau de bord des métriques de performance du modèle, suivant l’exactitude, les coûts et l’évolution de la latence.

Les métriques de performance sont affichées pour toutes les exécutions d’évaluation. Le coût total, l’utilisation des tokens et les temps de réponse sont affichés avec des graphiques montrant les évolutions. Les métriques personnalisées, telles que l’exactitude et les taux d’erreur, apparaissent dans des panneaux séparés. Les lignes de tendance aident à repérer quand les performances se dégradent ou que les coûts augmentent de manière inattendue, le tableau de bord se mettant à jour automatiquement à mesure que de nouveaux tests sont terminés.

Vue des traces

Figure 2 : Tableau de traces d’évaluation montrant les versions du modèle et leurs résultats de classification d’intention.

Chaque exécution de test est enregistrée avec tous les détails. Chaque trace montre quel modèle a été utilisé, quel prompt a été envoyé et tous les paramètres. Les indicateurs de réussite ou d’échec indiquent si les tests ont été exécutés correctement. La colonne de prompt affiche le texte envoyé au modèle pour vérification. Cette journalisation permet de comparer différentes versions côte à côte, de voir ce qui a changé entre les exécutions et de répéter n’importe quel test en utilisant sa configuration enregistrée.

Classement comparatif des modèles

Figure 3 : Image montrant le classement comparant les versions du modèle de classification d’intention selon les métriques d’exactitude et de latence.

Différents modèles et paramètres peuvent être comparés sur les mêmes données de test. Les colonnes affichent l’exactitude, les prédictions correctes, les scores et les temps de réponse. Le code couleur met en évidence en vert les meilleures performances. Cette comparaison révèle des compromis tels qu’une exactitude supérieure au prix d’une vitesse plus lente, ou des réponses plus rapides avec une exactitude légèrement inférieure, ce qui aide à choisir la configuration la plus adaptée aux besoins de production.

Gestion des versions des modèles

Figure 4 : Panneau de configuration du classificateur d’intention montrant les paramètres du modèle et les détails de version.

Chaque changement de configuration crée automatiquement une nouvelle version, conservant un historique complet. Les détails de version indiquent quand les changements ont eu lieu, qui les a effectués et l’espace de stockage utilisé. L’onglet Valeurs affiche les paramètres exacts, notamment le nom du modèle, les paramètres et les versions des fonctions. Cette gestion des versions garantit que n’importe quel test peut être répété avec des paramètres identiques, permet de suivre l’évolution des performances et de revenir à des versions antérieures si nécessaire.

Résultats d’évaluation détaillés

Figure 5 : Résultats d’évaluation montrant des cas de test individuels avec les intentions prédites et les scores d’exactitude.

Les résultats de test individuels sont affichés pour chaque échantillon. La section Scores résume le total des prédictions correctes, le pourcentage d’exactitude et les scores personnalisés.

Le tableau des résultats affiche chaque requête avec sa réponse attendue et la prédiction du modèle, en utilisant des coches pour les réponses correctes et des croix pour les réponses incorrectes. Les prédictions échouées sont faciles à repérer, montrant souvent des schémas tels qu’une confusion entre des catégories similaires.

Cliquer sur n’importe quelle ligne ouvre la trace complète, notamment le prompt, la réponse, le nombre de tokens et les temps, ce qui facilite le débogage des échecs et l’amélioration des prompts ou du choix du modèle.

Langsmith

LangSmith est la plateforme d’observabilité de LangChain pour surveiller, déboguer et évaluer les applications LLM. Elle trace automatiquement chaque appel LLM, capture les prompts et les sorties, suit les coûts et la latence, et permet une évaluation systématique via des tests basés sur des datasets. LangSmith s’intègre nativement avec LangChain mais prend en charge n’importe quelle application LLM via son SDK.

Résultats d’évaluation par échantillon

Figure 6 : Image montrant l’évaluation d’un cas de test individuel sur les prédictions et les métriques de performance.

Les résultats de prédiction individuels sont affichés à côté des sorties attendues, ce qui permet d’identifier où le modèle commet des erreurs. La comparaison entre les prédictions attendues et réelles révèle une confusion entre des catégories sémantiquement similaires. La latence par requête et le nombre de tokens indiquent quels types d’entrées sont plus coûteux à traiter, permettant d’optimiser les requêtes lentes ou coûteuses.

Volume de traces et surveillance de la santé

Figure 7 : Graphique montrant la visualisation des traces du projet suivant les taux de réussite et d’erreur.

La santé de l’application est affichée via les tendances du volume de traces et les ratios réussite/erreur. Différentes vues sont disponibles pour analyser les appels LLM, les tendances de coûts, les invocations d’outils ou les scores de feedback. Des problèmes tels que des pics d’erreurs ou des augmentations de coûts deviennent visibles, indiquant des problèmes nécessitant une investigation.

Comparaison des modèles et configurations

Figure 8 : Vue de comparaison d’expériences montrant les métriques de performance sur plusieurs exécutions de test.

Différents modèles peuvent être comparés côte à côte sur le même dataset de test. Les compromis entre exactitude, latence (P50/P99) et efficacité des tokens sont affichés visuellement. Identifier la configuration qui répond le mieux aux exigences – qu’il s’agisse de maximiser l’exactitude ou de minimiser les coûts et le temps de réponse – est simple grâce à ces comparaisons.

Langfuse

Langfuse est une plateforme d’observabilité LLM open source conçue pour surveiller, déboguer et évaluer les applications de modèles de langage. Disponible à la fois en auto-hébergé et en cloud, Langfuse offre un traçage complet avec capture automatique des prompts, sorties, coûts et latence.

La plateforme prend en charge n’importe quel framework LLM via son SDK flexible et offre des capacités d’évaluation intégrées, notamment LLM-as-a-judge pour l’évaluation automatisée de la qualité. Langfuse suit les versions des prompts entre les exécutions, permettant de comparer les métriques de performance entre différentes formulations.

La collecte de feedback utilisateur via les évaluations pouce levé/pouce baissé aide à identifier les sorties de haute et basse qualité, tandis que la notation personnalisée permet de suivre des métriques spécifiques à l’application. Les évaluations automatisées peuvent traiter des milliers de traces à des taux d’échantillonnage configurables, permettant une surveillance continue de la qualité à grande échelle sans revue manuelle de chaque sortie.

Langfuse a été acquis par ClickHouse et fonctionne désormais comme partie de ClickHouse, tout en restant open source.¹

Vue détaillée des traces

Figure 10 : Journaux de traces montrant les détails des appels API avec les données de performance et de coût.

Les traces individuelles affichent tous les détails d’exécution pour chaque appel LLM. La vue des traces montre les mesures exactes de latence, la consommation de tokens (tokens de prompt et de complétion séparément) et les coûts calculés par requête.

La configuration du modèle est conservée, notamment la température, max_tokens et d’autres paramètres. La section Aperçu affiche le prompt complet envoyé au modèle ainsi que la réponse complète, vous permettant de comprendre précisément ce que le modèle a reçu et généré.

Cette visibilité granulaire permet de déboguer des échecs spécifiques en examinant la paire entrée-sortie précise qui a provoqué une erreur.

Tableau de synthèse des traces

Figure 11 : Inspection de trace individuelle montrant les détails de la requête et la réponse du modèle.

Toutes les traces sont agrégées dans un tableau filtrable montrant les sorties, les niveaux d’observation, la latence, l’utilisation des tokens et les coûts totaux. Chaque ligne représente un appel LLM unique avec des niveaux d’observation codés par couleur indiquant la hiérarchie ou l’importance des traces. Les compteurs de tokens affichent à la fois les tokens de prompt et de complétion, ainsi que les totaux, tandis que les calculs de coûts sont automatiquement effectués en fonction du modèle utilisé.

Le sélecteur de colonnes permet de personnaliser les métriques affichées, et les filtres permettent de réduire les traces par environnement, plage de temps ou d’autres critères. Cette vue tabulaire facilite l’identification de schémas tels que des requêtes constamment lentes ou des requêtes anormalement coûteuses.

Braintrust

Braintrust est une plateforme d’observabilité LLM combinant évaluation et surveillance de production. La plateforme permet de tester des modèles sur des datasets, de comparer différents prompts ou configurations et de suivre des métriques de qualité via une notation automatisée. Les fonctions d’évaluation intégrées et personnalisées mesurent l’exactitude, la pertinence ou des critères métier, avec les résultats affichés dans des tableaux de comparaison montrant les différences de performance entre les versions.

Pour la surveillance de production, Braintrust suit des métriques en temps réel, notamment la latence, les coûts et des scores de qualité personnalisés lorsque le trafic traverse les applications. Des alertes se déclenchent lorsque des seuils de qualité sont franchis ou que des garde-fous de sécurité sont violés. Brainstore, le système de stockage de journaux de la plateforme, ingère les journaux applicatifs à grande échelle avec une recherche optimisée pour les interactions IA. Le tableau de bord affiche des métriques agrégées entre les expériences et les exécutions de production, capturant le suivi des coûts, l’utilisation des tokens et les métadonnées de réponse pour les requêtes d’évaluation et de production.

Helicone

Helicone est une plateforme d’observabilité basée sur un proxy qui surveille les applications LLM en acheminant les requêtes API via son serveur proxy. L’intégration nécessite de changer l’URL de base sans installation de SDK ni modification de code. La plateforme capture automatiquement les requêtes, les réponses, les coûts et l’utilisation des tokens pour surveiller le comportement de l’application.

Le tableau de bord affiche les volumes de requêtes totales, les coûts agrégés et la consommation de tokens sur tous les appels API. Les journaux de requêtes montrent les prompts d’entrée complets et les sorties du modèle, permettant d’enquêter sur des prédictions ou erreurs spécifiques. Le suivi des coûts répartit les dépenses par type de modèle, utilisateur ou tags personnalisés pour identifier les opérations coûteuses. La mise en cache intégrée détecte les requêtes en double et sert des réponses en cache, réduisant à la fois les coûts API et les temps de réponse. La limitation de débit définit des plafonds d’utilisation par utilisateur ou endpoint pour éviter des pics de dépenses imprévus.

La plateforme se concentre sur la surveillance des appels API individuels – chaque requête apparaît comme une entrée de journal distincte sans prise en charge intégrée du regroupement d’appels liés ou de la visualisation de séquences. Cela rend Helicone pratique pour des applications telles que les appels LLM indépendants (par exemple, des chatbots à un seul tour), la génération de contenu en lot ou les tâches de classification, mais moins adapté au suivi de workflows multi-étapes où comprendre les relations entre appels séquentiels est important.

Comet Opik

Opik est une plateforme open source d’observabilité et d’évaluation LLM de Comet, un fournisseur établi de MLOps et de suivi d’expériences.² Ses capacités principales incluent :

• Tracing : capture les appels LLM, les étapes des agents et les invocations d’outils pour une visibilité de bout en bout du comportement de l’application
• Évaluation : fournit des métriques intégrées et des évaluateurs LLM as judge pour noter les sorties telles que hallucination, la pertinence et la modération
• Intégration avec Comet : connecte les traces LLM à la plateforme de suivi d’expériences de Comet, permettant aux équipes d’unifier les métadonnées ML traditionnelles et l’observabilité LLM en un seul endroit³

Arize Phoenix

Arize Phoenix est une plateforme open source pour le développement, l’observabilité et l’évaluation d’applications d’IA, créée par Arize IA et la communauté open source.⁴ Elle est construite sur OpenTelemetry et propulsée par l’instrumentation OpenInference, de sorte que les traces fonctionnent avec les outils existants sans format propriétaire. Ses capacités principales incluent :

• Tracing : capture chaque étape effectuée par un agent, y compris les prompts, les récupérations, les appels d’outils et les sorties, offrant une visibilité de bout en bout des exécutions d’agents
• Évaluation : fournit un framework d’évaluation qui note les sorties et aide à détecter les régressions avant qu’elles n’atteignent les utilisateurs, avec prise en charge de la revue humaine et des approches LLM as judge
• Prompt engineering et itération : inclut un IDE de prompt pour tester les changements de prompt et de harnais sur des exemples de production réels
• Datasets et expériences : permet aux équipes de construire des datasets à partir des traces et d’exécuter des expériences qui comparent les changements sur les mêmes entrées pour mesurer si la qualité s’améliore réellement
• Annotations : prend en charge l’étiquetage des traces et des spans pour signaler ce qui a fonctionné et ce qui a échoué pendant la revue
• Options de déploiement : peut s’exécuter localement, via Docker, sur Kubernetes avec Helm, ou comme Phoenix Cloud, avec deux instances gratuit Phoenix Cloud disponibles
• Open source et auto-hébergeable : sous licence ELv2 avec plus de 10 000 étoiles GitHub et 2,5 millions de téléchargements par mois, avec des traces stockées dans l’environnement de l’utilisateur lorsqu’il est auto-hébergé

Plateformes de surveillance s’étendant à l’observabilité des LLM

Les fournisseurs établis de surveillance des performances applicatives (APM) étendent leurs plateformes pour couvrir les charges de travail LLM.

Datadog

Le produit d’observabilité LLM de Datadog est généralement disponible et trace chaque étape d’un pipeline LLM, y compris les prompts, les réponses du modèle, les étapes de récupération et les appels d’outils. Il suit la latence et l’utilisation des tokens à travers ces étapes et exécute des évaluations intégrées sur les sorties, notamment des vérifications des hallucinations, des injections de prompt, de la toxicité et de l’exposition de données sensibles.^{5 6}

IBM Instana

IBM Instana propose l’observabilité GenAI dans le cadre de sa plateforme full-stack de surveillance des applications et des infrastructures, aux côtés de ses capacités d’investigation d’incidents d’IA agentique.⁷

OpenObserve

OpenObserve a introduit Observability 3.0, une plateforme native IA qui combine journaux, métriques, traces et surveillance réelle des utilisateurs avec l’observabilité LLM dans un seul outil. Son agent IA SRE corrèle les alertes en incidents et identifie automatiquement les causes profondes, tandis qu’un Assistant IA convertit le langage naturel en requêtes SQL et PromQL, résume les modèles de journaux et génère des tableaux de bord et des alertes à partir de descriptions en langage clair. La détection d’Anomaly est proposée comme type d’alerte intégré aux côtés des options de seuil et composites.⁸

Honeycomb

Honeycomb, une plateforme d’observabilité, a ajouté des fonctionnalités spécifiques à l’IA et aux LLM à son produit. Sa Timeline d’agent révèle les relations entre les entrées utilisateur, les interactions LLM, les appels d’outils et les invocations d’agents, tandis que BubbleUp, un outil de détection d’anomalies basé sur l’apprentissage automatique, fait remonter les anomalies en combinant métriques, traces et journaux. La plateforme prend également en charge la surveillance de l’utilisation des tokens et un Assistant de requête en langage naturel pour analyser le comportement du système.⁹

New Relic

New Relic a introduit Agentic IA Monitoring, ajoutant des capacités axées sur les agents à sa plateforme d’observabilité. Elle fournit une carte de services des interactions entre agents, des métriques de performance telles que le volume de requêtes, la latence moyenne et les pourcentages d’erreurs, ainsi qu’une exploration détaillée au niveau des traces des appels individuels d’agents et d’outils.¹⁰

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Qu’est-ce que l’observabilité LLM ?

L’observabilité des LLM est la pratique consistant à collecter et interpréter des données continues provenant des grands modèles de langage pour comprendre comment ils se comportent en utilisation réelle. Elle se concentre sur la collecte de métriques, de traces et de journaux qui montrent comment les LLM répondent à différents prompts, outils et appels API externes.

Étant donné que les modèles de langage fonctionnent par raisonnement probabiliste, leurs processus internes ne peuvent pas être inspectés directement. Cela rend la surveillance des LLM dépendante de l’examen des sorties LLM, des entrées LLM et des étapes intermédiaires qui apparaissent dans les workflows agentiques. En étudiant ces traces, les développeurs LLM gagnent en visibilité sur les performances du système, le comportement du modèle et les modèles d’utilisation qui influencent les performances des applications et la qualité des sorties.

L’observabilité des LLM est essentielle pour plusieurs raisons :

• Assurance qualité : Les grands modèles de langage peuvent produire des sorties incorrectes ou de mauvaise qualité pour de nombreuses raisons, notamment des prompts peu clairs, des données en dérive ou un comportement utilisateur inattendu. La surveillance des prompts et des réponses aide à suivre des métriques d’évaluation telles que l’exactitude, la cohérence, la pertinence et la factualité. Cela permet aux équipes de détecter quand les sorties LLM commencent à décliner en qualité de réponse ou quand le modèle commence à générer des hallucinations. À mesure que l’utilisation des LLM s’étend dans les workflows d’entreprise, garantir une exactitude constante devient un défi courant.
• Dépannage : Lorsque des problèmes surviennent dans les applications LLM, les causes profondes peuvent provenir de nombreux domaines. Exemples : des prompts mal réglés, un fine-tuning défectueux, des appels API externes échoués ou des erreurs logiques dans les workflows d’agents multi-étapes. En collectant des traces LLM qui montrent les étapes intermédiaires, les développeurs peuvent effectuer une analyse des causes profondes efficacement et identifier précisément l’étape à laquelle le comportement a divergé. Cela réduit le besoin d’intervention humaine et raccourcit le temps de suivi des erreurs.
• Optimisation : Le suivi des performances système, de l’utilisation des ressources et de l’utilisation des tokens aide les organisations à identifier les goulots d’étranglement et à améliorer les performances des LLM. Les équipes peuvent mesurer la latence, le débit, l’utilisation de la mémoire et les taux d’erreur pour comprendre comment les LLM se comportent sous différents niveaux de charge. Elles peuvent également suivre les tokens pour contrôler les coûts et examiner les modèles d’utilisation pour améliorer les performances et l’efficacité coût. La surveillance continue de ces métriques clés est particulièrement précieuse dans la génération augmentée par récupération et les workflows d’agents, où les goulots d’étranglement de performance proviennent souvent d’appels d’outils inefficaces ou de trajets inutiles pendant le raisonnement.

Catégories de métriques essentielles

Les outils d’observabilité LLM regroupent généralement les métriques pertinentes en trois catégories qui soutiennent à la fois les équipes de développement logiciel et les équipes opérationnelles.

Métriques de performance système

• Latence : Mesure le temps entre la réception d’un prompt et la fourniture d’une réponse.
• Débit : Indique combien de requêtes le modèle peut traiter sur une période donnée.
• Taux d’erreur : Révèlent à quelle fréquence le système renvoie des réponses invalides ou échouées.

Métriques d’utilisation des ressources

• Consommation CPU et GPU : Aide à comprendre avec quelle efficacité le système utilise le matériel.
• Utilisation de la mémoire : Affecte les décisions de mise à l’échelle et la planification des capacités.
• Utilisation des tokens : Influence l’efficacité des coûts et aide les équipes à contrôler les coûts lors d’une utilisation intensive LLM.
• Compromis débit-latence : Montrent comment le système équilibre vitesse et volume de traitement.

Métriques de comportement du modèle

• Exactitude, factualité et qualité de réponse : Pour identifier les sorties de mauvaise qualité.
• Engagement et feedback utilisateur : Fournissent des informations sur la manière dont le modèle répond aux besoins des utilisateurs.
• Métriques de fidélité et d’ancrage : Reflètent à quel point le modèle adhère au matériel source.

Observabilité manuelle vs autonome

S’appuyer sur l’observation manuelle présente plusieurs défis. Les grands modèles de langage génèrent de gros volumes de données, et les chaînes de raisonnement multi-étapes produisent de nombreux journaux et traces. Le besoin de surveillance en temps réel augmente la complexité opérationnelle, et même les équipes expérimentées ont du mal à examiner chaque appel LLM sans manquer des signaux essentiels. Les workflows manuels rendent également difficile de suivre les changements continus du comportement des utilisateurs et des variations de prompts.

Les systèmes d’observabilité autonomes relèvent ces défis en utilisant des agents logiciels qui analysent en continu l’activité LLM. Ces agents détectent les anomalies, diagnostiquent les problèmes et effectuent une analyse des causes profondes sans intervention humaine constante. Les évaluations automatisées aident également à identifier les comportements à risque, tels que l’injection de prompt.

Un système de ce type prend en charge la surveillance continue et garantit un suivi cohérent des métriques d’évaluation sur l’ensemble du modèle. En conséquence, les organisations bénéficient d’un dépannage plus rapide, de meilleures performances applicatives et d’un meilleur contrôle des risques opérationnels.

Que rechercher dans les outils d’observabilité LLM

Évaluations de qualité et de sécurité

• Détection d’hallucination pour identifier quand le modèle s’écarte des données fiables.
• Détection d’injection de prompt et de jailbreak pour répondre aux préoccupations de sécurité.
• Notation de toxicité et évaluations de sécurité qui soutiennent la conformité et la réduction des risques.
• Clustering qui regroupe des sorties LLM similaires pour identifier la dérive.

Fonctionnalités d’expérimentation

• Tests A/B pour la gestion des prompts et les changements de configuration.
• Comparaison rapide entre plusieurs modèles LLM ou paramètres.
• Évaluation de l’exactitude, de la consommation de tokens et de la latence avant le déploiement.
• Tester les changements de modèle sur des scénarios réels à l’aide de données similaires à la production.

Corrélation avec l’infrastructure

• Connecter les traces LLM aux données de surveillance des performances des applications backend.
• Relier le temps de réponse et la qualité de réponse aux sessions utilisateur réelles.
• Identifier comment les performances système affectent les performances LLM et la stabilité de l’application.

Pour les déploiements LLM sur site, cette corrélation s’étend souvent jusqu’à la télémétrie au niveau du GPU. OpenLIT, un outil d’observabilité natif OpenTelemetry pour les applications GenAI et LLM, inclut une surveillance intégrée du GPU avec prise en charge du matériel NVIDIA et AMD Radeon, capturant des métriques telles que l’utilisation, l’utilisation de la mémoire, la température et la consommation électrique pendant l’inférence.

La corrélation de ces métriques avec le débit du modèle permet aux opérateurs d’identifier quand les limites de puissance ou thermiques dégradent les performances d’inférence, et aide à régler les paramètres matériels pour maintenir des charges de travail IA fiables.^{11 12}

LLMOps et gouvernance

• Garde-fous qui filtrent les prompts dangereux et bloquent les réponses nuisibles.
• Tableaux de bord pour suivre l’exposition des PII, les hallucinations et les violations de sécurité.
• Outils qui soutiennent la conformité, le reporting et l’analyse des incidents de sécurité.

Plusieurs produits sont construits spécifiquement autour de ces besoins de gouvernance et de conformité :

Databricks Unity IA Gateway est une couche de contrôle centrale pour les agents, les endpoints LLM et les serveurs Model Context Protocol (MCP). Ses capacités incluent :

• Contrôles d’accès et de politique : configure les permissions et applique des garde-fous sur les endpoints
• Gestion de la capacité : gère la capacité entre les fournisseurs et limite le débit des endpoints
• Journalisation des payloads : journalise les payloads de requête et de réponse à des fins d’audit
• Surveillance de l’utilisation et des coûts : suit l’utilisation et les coûts via des tables système
• Gouvernance des serveurs MCP : gouverne les serveurs MCP via les permissions Unity Catalog^{13 14}

Openlayer est une plateforme de gouvernance et d’observabilité de l’IA destinée aux industries réglementées. Ses capacités incluent :

• Tests pré-déploiement : tests structurés sur les hallucinations, les biais, la toxicité et la robustesse
• Observabilité en temps réel : surveillance et traçage des appels LLM, des pipelines de récupération et des agents multi-étapes
• Garde-fous : protection contre l’injection de prompt et les fuites de PII
• Support de conformité : cartographie de conformité automatisée avec capture continue des preuves et reporting prêt pour l’audit, aligné sur des cadres comme l’EU IA Act et ISO/IEC 42001¹⁵

OpenTelemetry comme standard émergent

OpenTelemetry est un framework open source, neutre vis-à-vis des fournisseurs, pour collecter les traces, métriques et journaux des systèmes logiciels. Il est important pour l’observabilité LLM car les applications d’IA combinent de nombreuses pièces mobiles telles que les modèles, les bases de données vectorielles, les outils et les frameworks d’agents, et sans standard partagé, chaque composant émet des données dans son propre format, ce qui rend le débogage de bout en bout difficile et enferme les équipes dans le fournisseur de surveillance pour lequel elles ont instrumenté en premier.

Les conventions sémantiques GenAI d’OpenTelemetry définissent un schéma commun pour les appels de modèle, l’utilisation des tokens, les invocations d’outils et les workflows d’agents, afin que les traces provenant de différentes bibliothèques puissent être capturées et analysées de manière cohérente.¹⁶

La plupart des grandes plateformes d’observabilité LLM, notamment Arize Phoenix, Langfuse et Honeycomb, ingèrent les données OpenTelemetry nativement, ce qui permet aux équipes d’instrumenter leurs applications une seule fois et de changer de backend ultérieurement sans réécrire leur code de traçage.¹⁷

Observabilité des workflows multi-agents

À mesure que les LLM alimentent des workflows d’agents multi-étapes, les exigences d’observabilité s’étendent au-delà des simples paires requête-réponse. Les applications agentiques introduisent des couches de complexité supplémentaires qui nécessitent des approches de traçage dédiées.

Dimensions clés de l’observabilité pour les agents :

• Traces de planification et de raisonnement : Visibilité sur la manière dont l’agent décompose les tâches, sélectionne les actions et affine son approche en fonction des résultats intermédiaires
• Surveillance des appels d’outils : Suivi des appels API externes, des requêtes de base de données et des exécutions de fonctions pour identifier les goulots d’étranglement de latence ou les échecs
• Traçage des transferts : Pour les systèmes multi-agents, surveiller comment les tâches sont transférées entre agents et si le contexte est préservé correctement
• Évolution de l’état : Comprendre comment la mémoire et le contexte changent sur plusieurs tours au sein d’une session

Together, ces dimensions forment la base du monitoring agentique. Les outils d’observabilité LLM tels que Langsmith, Langfuse, AgentOps et Weights & Biases fournissent des vues de traçage spécifiques aux agents qui affichent des graphes d’exécution complets.

Au-delà de ces outils généraux, certains produits se concentrent spécifiquement sur la fiabilité des agents. Un exemple est Omium, qui se positionne comme un produit d’observabilité et de fiabilité conçu spécialement pour les agents IA en production.¹⁸

Ses principales capacités incluent :

• Spans structurés : Capture des spans pour chaque appel LLM, utilisation d’outil et décision d’agent
• Traçage multi-agents : Assemble les appels inter-agents en une seule trace unifiée pour des diagnostics en temps réel
• Classification des échecs : Étiquette automatiquement les échecs dans des catégories telles que hallucination, boucle infinie, erreur d’outil et perte de contexte
• Reprise par points de contrôle : Prend des instantanés de l’état de l’agent à chaque appel d’outil et réponse LLM, permettant aux workflows de reprendre depuis n’importe quel point de contrôle au lieu de recommencer depuis zéro
• Prise en charge des frameworks : SDK pour TypeScript, Python et Go, avec détection auto pour LangChain, LangGraph, OpenAI et Anthropic

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{ermut2026,
  author = {Ermut, Sıla and Şipi, Nazlı},
  title  = {{LLM Outils d'observabilité: Weights & Biases, Langsmith}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/llm-observability}},
  note   = {AIMultiple. Consulté le 9 Juin 2026}
}

Liens de référence

1.

ClickHouse raises $400M Series D led by Dragoneer to accelerate expansion across analytics and AI infrastructure | ClickHouse

ClickHouse

2.

Open-Source AI Observability Platform | Opik by Comet

3.

GitHub - comet-ml/opik: Debug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards. · GitHub

4.

What is Arize Phoenix? - Phoenix

Mintlify

5.

Monitor, troubleshoot, improve, and secure your LLM applications with Datadog Agent Observability | Datadog

Datadog

6.

Agent Observability | LLM Observability | Datadog

7.

IBM Instana Observability

8.

OpenObserve — Open Source Observability Platform

OpenObserve

9.

Observability for AI & LLMs | Honeycomb

Honeycomb

10.

New Relic Unveils Platform Innovations that Align Technical Performance to Business Outcomes, Making Observability a Value Driver | New Relic

New Relic

11.

Open Source Platform for AI Engineering | OpenLIT | OpenTelemetry-native GenAI and LLM Application Observability

OpenLIT

12.

GPU Performance Monitoring - OpenLIT

Mintlify

13.

AI governance with Unity AI Gateway | Databricks on Google Cloud

14.

MCPs and agent tools | Databricks on AWS

15.

AI governance and observability platform | Openlayer

Openlayer

16.

Moved: Generative AI semantic conventions | OpenTelemetry

17.

LLM observability with ClickStack, OpenTelemetry, and MCP | ClickHouse

ClickHouse

18.

Omium — AI Agent Observability & Reliability for Production

Omium

Sıla Ermut

Analyste sectoriel

Suivre

Sıla Ermut est une analyste sectorielle chez AIMultiple couvrant les modèles d'IA, l'infrastructure d'IA, la gouvernance de l'IA et les applications d'IA en entreprise. Ses recherches se concentrent principalement sur l'utilisation de l'IA dans le marketing, la santé, les chaînes d'approvisionnement et la durabilité. Elle a précédemment travaillé comme recruteuse dans des sociétés de gestion de projet et de conseil. Sıla est titulaire d'un Master en psychologie sociale et d'une Licence en Relations Internationales.

Voir le profil complet

Recherche effectuée par

Nazlı Şipi

Chercheuse en IA

Suivre

Nazlı est analyste de données chez AIMultiple. Elle a une expérience préalable en analyse de données dans divers secteurs, où elle a travaillé à transformer des ensembles de données complexes en informations exploitables.

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