Observabilité LLM — Traçage, Comptabilisation des Tokens, Détection d'Hallucinations
À jour au 2026-10-06
Qu'est-ce que Observabilité LLM ?
Les outils APM traditionnels ne peuvent pas dire si la réponse d'un LLM était réellement correcte — les plateformes d'observabilité LLM comblent ce vide en échantillonnant en continu 1-5 % du trafic plus 100 % des réponses les moins confiantes contre un LLM-as-judge ou un dataset golden.
L'observabilité des LLM est la discipline qui consiste à voir, pour chaque appel de modèle qu'un système de production effectue, ce qui s'est passé, pourquoi c'est arrivé, combien cela a coûté, et si la réponse était réellement correcte. Le monitoring applicatif classique répond mal aux deux premières questions et pas du tout aux deux dernières — il a été conçu pour des chemins de code déterministes, pas pour un système dont la sortie varie d'un appel presque identique à l'autre. Une nouvelle génération de plateformes conçues spécifiquement pour cela s'est développée pour combler cet écart, en étendant les standards généraux de traçage distribué avec des attributs pensés pour l'IA générative : quel modèle a servi la requête, combien de tokens d'entrée et de sortie il a consommés, ce que cela a coûté, et combien de temps cela a pris.
Les quatre surfaces qui comptent
Le traçage distribué de chaque appel de modèle est le socle. Chaque requête utilisateur devient un arbre d'étapes reliées entre elles — l'entrée utilisateur, d'éventuels appels de récupération, une étape de reclassement, l'appel au modèle lui-même, les éventuels appels d'outils déclenchés par le modèle, et la réponse finale — capturé comme une trace connectée plutôt que comme un ensemble de lignes de journal déconnectées. Sans cette trace, déboguer une réponse fausse ou étrange en production relève quasiment de la conjecture, car il n'existe aucun moyen de voir quelle étape en amont a réellement produit l'entrée défectueuse.
Pourquoi c'est important
- Quatre surfaces sont non négociables : le traçage distribué de l'arbre de spans complet (entrée → retriever → reranker → modèle → outils → réponse), la comptabilisation par appel taguée par tenant/workflow/modèle, l'évaluation qualité échantillonnée, et la détection d'hallucination/ancrage.
- La spec de conventions sémantiques OpenTelemetry GenAI 2026 standardise des attributs de span comme gen_ai.usage.input_tokens, adoptés par tout fournisseur d'observabilité sérieux (Langfuse, Arize Phoenix, LangSmith, Helicone).
- Le scoring d'ancrage capture les échecs spécifiques au RAG (les affirmations apparaissent-elles dans le contexte récupéré ?) tandis que les classifieurs toxicité/PII/jailbreak capturent les échecs de sécurité — deux classes d'échec distinctes exigeant deux vérifications distinctes.
Points clés
- Les conventions sémantiques OpenTelemetry GenAI sont le standard industriel 2026 : `gen_ai.system`, `gen_ai.request.model`, `gen_ai.usage.input_tokens/output_tokens`, etc.
- Le traçage distribué de l'arbre complet de spans de la requête (entrée → retriever → reranker → modèle → outils → réponse) est non négociable pour le débogage.
- La comptabilisation par appel taguée par tenant + workflow + modèle est le substrat FinOps (concept compagnon C249).
- Évaluation qualité : échantillonner 1-5% du trafic, rejouer contre LLM-as-judge ou dataset golden, suivre le score, alerter sur la dérive.
- Détection d'hallucinations : scoring d'ancrage pour RAG ; classifieurs toxicité/PII/jailbreak pour sécurité ; échantillonner 100% des réponses peu confiantes.
- Paysage fournisseurs : Langfuse, Arize Phoenix, LangSmith, Weights & Biases Weave, Helicone — choisissez-en un et intégrez via OTLP.
Termes employés sur cette page
- OpenTelemetry GenAI
- Extension de convention sémantique du standard OpenTelemetry définissant des attributs de span standard pour les appels d'IA générative (modèle, tokens, coût, outils).
- LLM-as-judge
- Modèle d'évaluation où un LLM distinct note la qualité de la sortie d'un autre LLM par rapport à une grille ; moins cher que la revue humaine, plus bruité que la revue humaine.
- Groundedness
- Métrique de qualité spécifique au RAG : les affirmations de la réponse apparaissent-elles dans le contexte récupéré ? Une faible ancrage (groundedness) = hallucination.
- OTLP
- OpenTelemetry Protocol — le protocole de transport pour acheminer traces/métriques/logs des applications instrumentées vers les collecteurs et backends.
- Span
- Une opération tracée unique au sein d'un arbre de trace distribué — un appel de récupération, une étape de reranking, ou un appel de modèle — portant des attributs tels que la durée, le nombre de tokens et le statut ; l'unité de base que les conventions sémantiques OpenTelemetry GenAI standardisent.
- Détection de dérive
- Surveiller si la qualité de sortie réelle d'un modèle ou d'un pipeline s'éloigne de sa référence établie, typiquement en relançant périodiquement une évaluation contre un jeu de données golden ou en suivant un score LLM-as-judge dans le temps — la pratique qui transforme une régression de qualité silencieuse en alerte.
- Échantillonnage pondéré par la confiance
- Une stratégie d'échantillonnage d'évaluation qui examine en totalité ou presque toutes les réponses à faible confiance d'un système, tout en n'échantillonnant qu'un faible pourcentage du trafic à haute confiance — concentrant l'effort de revue là où les hallucinations et erreurs se concentrent réellement, plutôt que de le répartir uniformément.
- SAP AI Core Inference Observability
- La capacité propre nommée de SAP pour capturer les données de requête/réponse par appel, l'usage de tokens et la latence des appels effectués via le generative AI hub, documentée dans le guide de service AI Core de SAP — la réponse native SAP aux surfaces de traçage et de comptabilisation des tokens de cette fiche, avec une mise en garde documentée selon laquelle les payloads capturés sont stockés non masqués.
Sources
- OpenTelemetry — Generative AI Semantic Conventions
- Langfuse — LLM Observability Documentation
- Arize Phoenix — Tracing and Evaluation
- OpenTelemetry — Observability primer
- NIST — AI Risk Management Framework knowledge base
- SAP Help — Generative AI Hub overview
- GitHub — open-telemetry/semantic-conventions-genai
- OpenTelemetry — Gen AI attribute registry
- OpenTelemetry Blog — Inside the LLM Call: GenAI Observability with OpenTelemetry (2026)
- MLflow Docs — OpenTelemetry GenAI Semantic Conventions
- OpenTelemetry — semantic-conventions-genai PR 498: Add gen_ai.skill.* attributes to the execute tool span (merged 29 Sep 2026)
- OpenTelemetry — semantic-conventions-genai PR 270: Add gen_ai.main_agent entity (merged 30 Sep 2026)
- OpenTelemetry — semantic-conventions-genai PR 520: Recommend the inference event be of severity level debug (merged 5 Oct 2026)
- InfoWorld — Observability for AI-native systems: New SLIs beyond latency and error rate (30 Sep 2026, opinion)
Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.