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

LLM applications se sont étendues des conversations en aller-simple aux agents à étapes multiples qui utilisent des outils, interrogent des bases de données, et se coordonnent avec d'autres modèles, rendant leur comportement plus difficile à interpréter.

L'observabilité 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 d'observabilité LLM de Weights & Biases pour la surveillance, l'évaluation et l'optimisation des applications de modèle de langage. Weave suit automatiquement chaque appel LLM en utilisant le décorateur @weave.op, capturant les entrées, sorties, coûts, latence et 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 repérer 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 le versionnage automatique préserve chaque changement de configuration pour la 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 commettent des erreurs.

Tableau de bord récapitulatif des scores

Figure 1 : Graphiques montrant le tableau de bord des métriques de performance du modèle, suivant les tendances de précision, de coût et de latence au fil du temps.

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 dans le temps. Les métriques personnalisées, telles que la précision et les taux d'erreur, apparaissent dans des panneaux séparés. Les lignes de tendance aident à repérer lorsque la performance se dégrade ou que les coûts augmentent de manière inattendue, le tableau de bord se mettant à jour automatiquement à mesure que les nouveaux tests sont terminés.

Vue des traces

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

Chaque exécution de test est sauvegardé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 succès ou d'échec indiquent si les tests ont été terminés correctement. La colonne 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 sauvegardée.

Tableau de comparaison des modèles

Figure 3 : Image montrant le tableau de bord comparant les versions du modèle de classification d'intention en fonction des métriques de précision et de latence.

Différents modèles et paramètres peuvent être comparés sur les mêmes données de test. Les colonnes montrent la précision, les prédictions correctes, les scores et les temps de réponse. Un code couleur met en évidence les meilleurs performeurs en vert. Cette comparaison révèle des compromis comme une précision plus élevée au détriment d'une vitesse plus lente ou des réponses plus rapides avec une précision légèrement inférieure, aidant à choisir quelle configuration fonctionne le mieux pour les besoins de production.

Versionnage 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, y compris le nom du modèle, les paramètres et les versions des fonctions. Ce versionnage garantit que tout test peut être répété avec des paramètres identiques, permet de suivre l'évolution des performances dans le temps, et permet de revenir à des versions antérieures si nécessaire.

Résultats d'évaluation détaillés

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

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

Le tableau 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 motifs tels que la confusion entre des catégories similaires.

Cliquer sur une ligne ouvre la trace complète, y compris le prompt, la réponse, le nombre de tokens et le chronométrage, ce qui facilite le débogage des échecs et l'amélioration des prompts ou de la sélection des modèles.

Langsmith

LangSmith est la plateforme d'observabilité de LangChain pour la surveillance, le débogage et l'évaluation des 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 toute application LLM via son SDK.

Résultats d'évaluation par échantillon

Figure 6 : Image montrant l'évaluation individuelle des cas de test 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, vous permettant d'identifier où le modèle commet des erreurs. La comparaison des prédictions attendues par rapport aux prédictions réelles révèle une confusion entre des catégories sémantiquement similaires. La latence par requête et le nombre de tokens montrent quels types d'entrée 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 succès et d'erreur au fil du temps.

La santé de l'application est affichée via les tendances du volume de traces et les ratios de succès/erreur au fil du temps. Différentes vues sont disponibles pour analyser les appels LLM, les tendances de coûts, les invocations d'outils ou les scores de retours. Les problèmes tels que les pics d'erreur ou les augmentations de coûts deviennent visibles, indiquant des problèmes nécessitant une investigation.

Comparaison des modèles et des 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 ensemble de données de test. Les compromis entre la précision, la latence (P50/P99) et l'efficacité des tokens sont affichés visuellement. Identifier quelle configuration répond le mieux aux exigences – qu'il s'agisse de maximiser la précision ou de minimiser le coût 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 la surveillance, le débogage et l'évaluation des applications de modèles de langage. Disponible en solution auto-hébergée et cloud, Langfuse fournit un traçage complet avec capture automatique des prompts, des sorties, des coûts et de la latence.

La plateforme prend en charge tout framework LLM via son SDK flexible et offre des capacités d'évaluation intégrées, y compris le LLM-as-a-judge pour l'évaluation automatique de la qualité. Langfuse suit les versions de prompts à travers les exécutions, permettant la comparaison des métriques de performance entre différentes formulations.

La collecte des retours utilisateurs via des évaluations pouce en l'air / pouce en bas aide à identifier les sorties de haute et de 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 examen manuel de chaque sortie.

Langfuse a été racheté par ClickHouse et opère désormais en tant que 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 les détails complets d'exécution de chaque appel LLM. La vue de trace 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 préservée, y compris la température, max_tokens et les 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 exacte qui a causé une erreur.

Tableau d'aperçu des traces

Figure 11 : Inspection individuelle des traces 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 affichant les sorties, les niveaux d'observation, la latence, l'utilisation des tokens et les coûts totaux. Chaque ligne représente un seul appel LLM avec des niveaux d'observation codés par couleur indiquant la hiérarchie ou l'importance de la trace. Les comptes 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 horaire ou d'autres critères. Cette vue tabulaire permet d'identifier facilement des motifs tels que des requêtes constamment lentes ou des demandes anormalement coûteuses.

Braintrust

Braintrust est une plateforme d'observabilité LLM combinant évaluation et surveillance en production. La plateforme permet de tester des modèles par rapport à des datasets, de comparer différents prompts ou configurations, et de suivre les métriques de qualité via une notation automatisée. Des fonctions d'évaluation intégrées et personnalisées mesurent la précision, la pertinence ou des critères spécifiques au domaine, avec des résultats affichés dans des tableaux de comparaison montrant les différences de performance entre les versions.

Pour la surveillance en production, Braintrust suit en temps réel des métriques incluant la latence, le coût et des scores de qualité personnalisés au fur et à mesure que le trafic traverse les applications. Les alertes se déclenchent lorsque les seuils de qualité sont franchis ou que des garde-fous de sécurité sont violés. Brainstore, le système de stockage de logs de la plateforme, ingère les journaux d'application à grande échelle avec une recherche optimisée pour les interactions IA. Le tableau de bord affiche les métriques agrégées à travers 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 proxy qui surveille les applications LLM en acheminant les requêtes API via son serveur proxy. L'intégration nécessite uniquement 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 totaux de requêtes, 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 des modèles, permettant d'étudier des prédictions ou des erreurs spécifiques. Le suivi des coûts ventile 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 renvoie les réponses mises en cache, réduisant à la fois les coûts API et les temps de réponse. La limitation de débit fixe 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 des appels liés ou de la visualisation des séquences. Cela rend Helicone pratique pour des applications telles que les appels LLM indépendants (par exemple, chatbots à tour unique), la génération de contenu par lots ou les tâches de classification, mais moins adapté au suivi des workflows multi-étapes où il est important de comprendre les relations entre les appels séquentiels.

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 :

• Traçage : 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-a-judge pour noter les sorties telles que les hallucinations, la pertinence et la modération
• Intégration avec Comet : connecte les traces LLM avec 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 IA, construite par Arize IA et la communauté open source.⁴ Elle est construite au-dessus d'OpenTelemetry et alimentée par l'instrumentation OpenInference, de sorte que les traces fonctionnent avec les outils existants sans format propriétaire. Ses capacités principales incluent :

• Traçage : capture chaque étape qu'un agent effectue, y compris les prompts, les récupérations, les appels d'outils et les sorties, donnant une visibilité de bout en bout des exécutions de l'agent
• Évaluation : fournit un cadre d'évaluation qui note les sorties et aide à détecter les régressions avant qu'elles n'atteignent les utilisateurs, avec prise en charge à la fois de la révision humaine et des approches LLM-as-a-judge
• Ingénierie et itération des prompts : inclut un IDE de prompt pour tester les changements de prompts et de harnais par rapport à des exemples de production réels
• Datasets et expériences : permet aux équipes de créer des datasets à partir de 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 s'est cassé pendant la révision
• Options de déploiement : peut s'exécuter localement, via Docker, sur Kubernetes avec Helm, ou en tant que Phoenix Cloud, avec deux instances Phoenix Cloud gratuites 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 les traces stockées dans l'environnement de l'utilisateur en auto-hébergement

Plateformes de surveillance s'étendant à l'observabilité 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 des modèles, 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, y compris des vérifications des hallucinations, des injections de prompts, de la toxicité et de l'exposition de données sensibles.^{5 6}

IBM Instana

IBM Instana répertorie l'observabilité GenAI comme faisant partie de sa plateforme de surveillance applicative et d'infrastructure full-stack, positionnée aux côtés de ses capacités d'investigation d'incidents d'IA agentique.⁷

OpenObserve

OpenObserve a introduit Observabilité 3.0, une plateforme native IA qui combine logs, métriques, traces et surveillance réelle des utilisateurs avec l'observabilité LLM en un seul outil. Son agent SRE IA corrèle les alertes en incidents et identifie automatiquement les causes racines, tandis qu'un Assistant IA convertit le langage naturel en requêtes SQL et PromQL, résume les motifs de logs et génère des tableaux de bord et des alertes à partir de descriptions en langage naturel. La détection d'anomalies 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 Chronologie des Agents 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 le machine learning, fait apparaître les anomalies en combinant métriques, traces et logs. La plateforme prend également en charge la surveillance de l'utilisation des tokens et un Assistant de Requêtes en langage naturel pour analyser le comportement du système.⁹

New Relic

New Relic a introduit la Surveillance Agentic IA, ajoutant des capacités axées sur les agents à sa plateforme d'observabilité. Elle fournit une carte de services des interactions entre les agents, des métriques de performance telles que le volume de requêtes, la latence moyenne et les pourcentages d'erreurs, et un drill-down au niveau des traces dans les appels individuels des agents et des 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é LLM est la pratique consistant à collecter et interpréter des données continues provenant de grands modèles de langage pour comprendre leur comportement en utilisation réelle. Elle se concentre sur la collecte de métriques, de traces et de logs 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 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 obtiennent une visibilité sur la performance du système, le comportement du modèle et les modèles d'utilisation qui influencent les performances applicatives et la qualité des sorties.

L'observabilité LLM est vitale pour plusieurs raisons :

• Assurance qualité : Les grands modèles de langage peuvent produire des sorties incorrectes ou de faible qualité pour un large éventail de raisons, notamment des prompts peu clairs, des données dérivant ou un comportement utilisateur inattendu. La surveillance des prompts et des réponses dans le temps aide à suivre les 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 lorsque le modèle commence à générer des hallucinations. À mesure que l'utilisation des LLM se répand dans les workflows d'entreprise, assurer une précision constante devient un défi commun.
• Résolution de problèmes : Lorsque des problèmes surviennent dans les applications LLM, les causes racines peuvent provenir de nombreux domaines. Par exemple, des prompts mal ajustés, un fine-tuning défaillant, 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 racines 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 du système, de l'utilisation des ressources et des tokens aide les organisations à identifier les goulets d'étranglement et à améliorer les performances 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érentes charges. 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é des coûts. La surveillance continue de ces métriques clés est particulièrement précieuse dans les workflows de génération augmentée par récupération et d'agents, où les goulets d'étranglement de performance émergent souvent d'appels d'outils inefficaces ou de tours de raisonnement inutiles.

Catégories de métriques fondamentales

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 livraison d'une réponse.
• Débit : Indique le nombre de requêtes que le modèle peut traiter dans une période donnée.
• Taux d'erreur : Révèlent la fréquence à laquelle le système renvoie des réponses invalides ou échouées.

Métriques d'utilisation des ressources

• Consommation CPU et GPU : Aident à 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 de la capacité.
• Utilisation des tokens : Influence l'efficacité des coûts et aide les équipes à contrôler les dépenses lors d'une utilisation intensive des LLM.
• Compromis débit-latence : Montrent comment le système équilibre la vitesse et le volume de traitement.

Métriques de comportement du modèle

• Exactitude, factualité et qualité de réponse : Pour identifier les sorties de faible qualité.
• Engagement et retours des utilisateurs : Fournissent des indications sur la façon dont le modèle répond aux besoins des utilisateurs.
• Métriques de fidélité et de fondement : Reflètent à quel point le modèle adhère au matériau source.

Observabilité manuelle vs. autonome

Se fier à une observation manuelle présente plusieurs défis. Les grands modèles de langage génèrent des volumes élevés de données, et les chaînes de raisonnement multi-étapes produisent de nombreux logs et traces. Le besoin de surveillance en temps réel augmente la complexité opérationnelle, et même les équipes expérimentées peinent à 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 répondent à 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 racines sans intervention humaine constante. Les évaluations automatisées aident également à identifier les comportements à risque, tels que l'injection de prompts.

Un système de ce type prend en charge la surveillance continue et assure un suivi cohérent des métriques d'évaluation sur l'ensemble du modèle. En conséquence, les organisations bénéficient d'une résolution plus rapide des problèmes, d'une amélioration des performances applicatives et d'un meilleur contrôle des risques opérationnels.

Que rechercher dans les outils d'observabilité LLM

Évaluations de la qualité et de la sécurité

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

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 la précision, de la consommation de tokens et de la latence avant le déploiement.
• Test des changements de modèle par rapport à des scénarios réels en utilisant des données de type production.

Corrélation avec l'infrastructure

• Connexion des traces LLM aux données de surveillance des performances applicatives backend.
• Liaison du temps de réponse et de la qualité de réponse aux sessions utilisateur réelles.
• Identification de la façon dont 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 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 de NVIDIA et du matériel 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.

Corréler 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 à ajuster les paramètres matériels pour soutenir 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 le suivi de l'exposition des PII, des hallucinations et des 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 politiques : configure les permissions et applique les garde-fous sur les endpoints
• Gestion de capacité : gère la capacité entre les fournisseurs et limite les débits des endpoints
• Journalisation des charges utiles : journalise les charges utiles de requêtes et de réponses pour l'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é 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 pour les appels LLM, les pipelines de récupération et les agents multi-étapes
• Garde-fous : protection contre l'injection de prompts et les fuites de PII
• Support de conformité : mappage de conformité automatisé avec capture continue de preuves et rapports prêts pour l'audit, alignés sur des cadres tels que l'EU IA Act et l'ISO/IEC 42001¹⁵

OpenTelemetry en tant que norme émergente

OpenTelemetry est un cadre open source, neutre vis-à-vis des fournisseurs, pour collecter des traces, des métriques et des logs à partir de systèmes logiciels. Cela importe pour l'observabilité LLM parce que les applications 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 un 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èles, l'utilisation des tokens, les invocations d'outils et les workflows d'agents, de sorte que les traces provenant de différentes bibliothèques puissent être capturées et analysées de manière cohérente.¹⁶

La plupart des principales plateformes d'observabilité LLM, y compris Arize Phoenix, Langfuse, et Honeycomb, ingèrent nativement les données OpenTelemetry, ce qui permet aux équipes d'instrumenter leurs applications une fois et de changer de backend plus tard sans réécrire leur code de traçage.¹⁷

Observabilité des workflows multi-agents

Alors 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 façon 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 goulets d'étranglement de latence ou les échecs
• Traçage des transferts : Pour les systèmes multi-agents, surveillance de la façon dont les tâches sont transférées entre les agents et si le contexte est préservé correctement
• Évolution de l'état : Compréhension de la façon dont la mémoire et le contexte changent sur plusieurs tours au sein d'une session

Ensemble, ces dimensions forment la base de la surveillance 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éralistes, 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écifiquement 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-agent : Rassemble les appels inter-agents en une seule trace unifiée pour le diagnostic 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 point de contrôle : Réalise 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 redémarrer de zéro
• Support de frameworks : SDK pour TypeScript, Python et Go, avec détection automatique 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.

Model Context Protocol (MCP) on Databricks | Databricks on AWS

15.

AI governance and observability platform | 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 Sectorielle

Suivre

Sıla Ermut est analyste sectorielle chez AIMultiple, spécialisée dans le marketing par email et les vidéos de vente. Elle a précédemment travaillé comme recruteuse dans des cabinets de gestion de projet et de conseil. Sıla est titulaire d'un Master of Science en psychologie sociale et d'un Bachelor of Arts 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é à la transformation d'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