Pourquoi ce sujet est important
Sans instrumentation, une mauvaise réponse est difficile à expliquer. Le modèle a-t-il reçu le bon prompt ? Le retriever a-t-il trouvé les bons documents ? Un outil a-t-il échoué ? Une trace relie ces événements, tandis que métriques et alertes montrent si le problème devient systémique.
Définir la trace
Créez une trace par requête métier et non par simple appel HTTP. Utilisez des spans pour le preprocessing, la recherche, le reranking, le modèle, les outils et la validation. Propagez un identifiant de corrélation jusqu’aux services externes.
Choisir les attributs
Enregistrez fournisseur, identifiant exact du modèle, version du prompt, température, latence, tokens, coût estimé, résultat de validation et statut des outils. Pour un RAG, ajoutez identifiants de documents, scores et filtres. Pour un agent, ajoutez nom de l’outil, durée et nombre d’étapes.
Protéger les données
Masquez secrets et données personnelles avant l’export. Les règles côté interface ne protègent pas le stockage brut. Définissez rétention, échantillonnage, rôles et séparation des environnements. Utilisez un mode de diagnostic temporaire et audité pour les incidents nécessitant plus de détails.
Calculer le coût
Calculez à partir des tokens réellement facturés, du cache, des outils et des fournisseurs. Agrégez par fonctionnalité, client et version. Le coût par requête est insuffisant : suivez coût par tâche réussie et coût des nouvelles tentatives.
Créer des alertes utiles
Alertez sur taux d’erreur, latence p95, coût par tâche, boucles d’outils, sorties invalides, refus anormaux et baisse d’un score métier. Chaque alerte doit pointer vers des traces représentatives et un runbook. Évitez les seuils trop sensibles qui créent du bruit.
Relier production et évaluation
Transformez les incidents et feedbacks en cas de test. Rejouez-les avant une nouvelle version de modèle ou de prompt. La boucle trace → dataset → évaluation → déploiement rend l’observabilité réellement utile.
Tableau de décision
| Signal | Exemple | Action |
|---|---|---|
| Fiabilité | Taux JSON invalide | Vérifier prompt et modèle |
| Performance | Latence p95 | Examiner spans lents |
| Coût | € par tâche réussie | Réduire contexte ou router |
| Agent | Nombre d’étapes | Stopper les boucles |
| RAG | Rappel ou citations | Vérifier retrieval |
Exemple concret
Un agent de support passe soudain de trois à neuf appels d’outils. L’alerte sur le nombre d’étapes identifie une nouvelle version de prompt. Les traces montrent que l’agent répète la recherche après un résultat vide. Un test de régression est ajouté et la règle d’arrêt corrigée.
Les erreurs fréquentes
- créer un span indépendant pour chaque appel sans trace métier
- stocker clés ou documents sensibles dans les attributs
- utiliser un alias de modèle non versionné
- calculer le coût sans cache ni retries
- alerter sans seuil basé sur une ligne de base
- ne pas relier les incidents aux évaluations
Checklist de mise en production
- [ ] Convention de nommage des spans
- [ ] Identifiant de corrélation propagé
- [ ] Redaction avant export
- [ ] Versions modèle et prompt enregistrées
- [ ] Tokens et coûts agrégés
- [ ] SLO et seuils documentés
- [ ] Runbooks reliés aux alertes
- [ ] Régressions converties en tests
FAQ
Quelle différence entre logs et traces ?
Les logs décrivent des événements ; une trace relie les étapes d’une même requête avec leur durée et leurs relations.
Faut-il tracer toutes les requêtes ?
Pas nécessairement. Échantillonnez selon risque et volume, mais conservez suffisamment d’incidents et de cas rares.
Peut-on enregistrer la chaîne de pensée ?
Évitez de dépendre d’un raisonnement privé. Tracez entrées, sorties, outils et décisions observables nécessaires au diagnostic.
Comment estimer le coût ?
Utilisez l’usage retourné par le fournisseur et une table tarifaire versionnée, puis rapprochez avec la facture.
Exemple OpenTelemetry : une trace sans contenu sensible
~~~python from opentelemetry import trace
tracer = trace.get_tracer("assistant.production")
def call_model(client, model, messages, feature): with tracer.start_as_current_span("chat") as span: span.set_attribute("gen_ai.operation.name", "chat") span.set_attribute("gen_ai.request.model", model) span.set_attribute("app.feature", feature) try: response = client.responses.create( model=model, input=messages, ) usage = response.usage span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens) span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens) return response except Exception as error: span.record_exception(error) span.set_status(trace.Status(trace.StatusCode.ERROR)) raise ~~~
N’enregistrez pas prompts et réponses par défaut : ils peuvent contenir secrets ou données personnelles. Propager le contexte de trace entre API, retriever, LLM et outils permet d’identifier l’étape lente. Utilisez des attributs à faible cardinalité pour modèle, fonctionnalité et version du prompt. Ajoutez des métriques agrégées pour coût, tokens, erreurs, temps au premier token et latence totale, puis définissez des alertes avec un seuil et une action de repli.