Observabilité pour les applications LLM : Une étude de cas pratique

La montée des applications LLM et le besoin d’observabilité

Le domaine du développement logiciel a été radicalement transformé par la révolution des modèles de langage large (LLM). Des chatbots sophistiqués et des générateurs de contenu intelligents aux assistants de code et outils d’analyse de données, les LLM sont intégrés dans une gamme toujours plus étendue d’applications. Cette adoption rapide, bien que passionnante, introduit une nouvelle classe de défis, notamment en ce qui concerne la compréhension et la maintenance de ces systèmes en production. Les outils de surveillance traditionnels, conçus pour des logiciels déterministes et basés sur des règles, ont souvent du mal à saisir les subtilités du comportement des LLM.

Voici l’observabilité. L’observabilité, dans le contexte des applications LLM, est la capacité à comprendre l’état interne d’un système alimenté par un LLM à partir de ses sorties externes. Elle va au-delà des simples contrôles de santé pour fournir des insights profonds sur la manière dont le LLM interprète les requêtes, génère des réponses, gère le contexte et interagit avec des outils ou des sources de données externes. Sans une observabilité solide, le débogage des problèmes de performance, l’assurance de l’équité, l’identification des hallucinations ou l’optimisation des coûts peuvent devenir une tâche décourageante, voire presque impossible. Cet article présente une étude de cas pratique sur la mise en œuvre de l’observabilité pour une application LLM, démontrant des principes et outils clés.

Etude de cas : ‘DocuChat’ – Un assistant de base de connaissances interne

Considérons une application hypothétique appelée ‘DocuChat’. DocuChat est un assistant de base de connaissances interne conçu pour aider les employés à trouver rapidement des réponses au sein d’une vaste collection de documents internes (pages Confluence, archives Slack, wikis internes, etc.). Il utilise une architecture de génération augmentée par la récupération (RAG) :

1. Requête utilisateur : Un employé pose une question (par exemple, “Comment demander un nouvel ordinateur portable ?”).
2. Récupération : Le système recherche dans une base de données vectorielle (peuplée d’embeddings de documents internes) pour trouver des morceaux de documents pertinents.
3. Augmentation : Ces morceaux récupérés, ainsi que la requête utilisateur originale, sont fournis comme contexte à un LLM.
4. Génération : Le LLM synthétise une réponse basée sur le contexte fourni et la requête de l’utilisateur.

DocuChat utilise le GPT-4 d’OpenAI pour la génération et un modèle d’embedding auto-hébergé pour la récupération. Il est construit en utilisant Python, LangChain et une base de données vectorielle comme Pinecone ou Weaviate. Initialement, l’équipe de développement s’est concentrée sur la fonctionnalité, mais au fur et à mesure que l’application a gagné des utilisateurs, une multitude de questions opérationnelles se sont posées :

• Pourquoi certaines réponses sont-elles lentes ?
• Le LLM hallucine-t-il, ou la récupération échoue-t-elle ?
• Les utilisateurs sont-ils satisfaits des réponses ?
• Combien cela nous coûte-t-il par requête ?
• Atteignons-nous les limites de taux de l’API ?
• Quels types de questions les utilisateurs posent-ils le plus souvent ?

Ces questions mettent en évidence le besoin critique d’observabilité.

Piliers de l’observabilité LLM pour DocuChat

Pour DocuChat, nous allons nous concentrer sur les trois piliers traditionnels de l’observabilité, adaptés aux applications LLM :

1. Journaux : Enregistrements structurés d’événements.
2. Métriques : Mesures numériques agrégées au fil du temps.
3. Traces : Vues de bout en bout des requêtes à travers des systèmes distribués.

De plus, nous considérerons un quatrième pilier crucial pour les LLM : Retour d’expérience / Évaluation.

1. Journaux : Le ‘Ce qui s’est passé’

Les journaux d’application traditionnels sont vitaux, mais pour les applications LLM, ils doivent capturer des détails spécifiques centrés sur le LLM. Pour DocuChat, nous avons instrumenté diverses étapes du pipeline RAG pour émettre des journaux structurés.

Exemple de structure de journal (JSON) :

{
 "timestamp": "2023-10-27T10:30:00Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "user_query",
 "session_id": "abcd-1234-efgh",
 "user_id": "user_123",
 "query": "How do I request a new laptop?",
 "metadata": {
 "user_agent": "Mozilla/5.0...",
 "ip_address": "192.168.1.10"
 }
},
{
 "timestamp": "2023-10-27T10:30:01Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "retrieval_start",
 "session_id": "abcd-1234-efgh",
 "query": "How do I request a new laptop?",
 "vector_db_query": "laptop request policy",
 "k_value": 5
},
{
 "timestamp": "2023-10-27T10:30:02Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "retrieval_complete",
 "session_id": "abcd-1234-efgh",
 "retrieved_docs_count": 3,
 "retrieved_docs": [
 {"id": "doc-456", "source": "confluence/laptop-policy", "score": 0.89},
 {"id": "doc-789", "source": "slack/it-announcements", "score": 0.81}
 ],
 "retrieval_duration_ms": 1000
},
{
 "timestamp": "2023-10-27T10:30:03Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "llm_generation_start",
 "session_id": "abcd-1234-efgh",
 "model_name": "gpt-4",
 "temperature": 0.7,
 "prompt_tokens": 500,
 "system_prompt_hash": "abc123def456" 
},
{
 "timestamp": "2023-10-27T10:30:08Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "llm_generation_complete",
 "session_id": "abcd-1234-efgh",
 "response": "To request a new laptop, please visit the IT portal...",
 "completion_tokens": 150,
 "total_tokens": 650,
 "llm_duration_ms": 5000,
 "finish_reason": "stop"
},
{
 "timestamp": "2023-10-27T10:30:09Z",
 "service": "docuchat-rag-api",
 "level": "INFO",
 "event_type": "response_sent",
 "session_id": "abcd-1234-efgh",
 "total_request_duration_ms": 9000
}

En centralisant ces journaux (par exemple, en utilisant ELK Stack, Splunk, Datadog), l’équipe peut :

• Filtrer par session_id pour reconstruire une interaction entière.
• Identifier les appels de récupération ou de LLM lents.
• Analyser les requêtes courantes et leurs résultats.
• Déboguer les problèmes en examinant l’exact prompt fourni au LLM et les documents récupérés.

2. Métriques : Le ‘Combien’ et ‘À quelle vitesse’

Les métriques fournissent des insights agrégés et quantifiables sur la performance et l’utilisation du système. Pour DocuChat, nous suivons les métriques clés en utilisant Prometheus et les visualisons avec Grafana.

Métriques clés spécifiques aux LLM :

• Latence :
  • docuchat_total_request_duration_seconds_sum/_count (temps de réponse global du système)
  • docuchat_retrieval_duration_seconds_sum/_count
  • docuchat_llm_api_duration_seconds_sum/_count
• Utilisation des tokens & Coût :
  • docuchat_llm_prompt_tokens_total (compteur)
  • docuchat_llm_completion_tokens_total (compteur)
  • docuchat_llm_total_tokens_cost_usd_total (calculé en fonction du prix du modèle)
• État de l’API :
  • docuchat_llm_api_calls_total (compteur, labellisé par model_name, status_code)
  • docuchat_vector_db_queries_total (compteur, labellisé par status_code)
  • docuchat_llm_api_rate_limit_errors_total (compteur)
• Performance de récupération :
  • docuchat_retrieved_documents_count_sum/_count (moyenne de documents récupérés par requête)
  • docuchat_retrieved_documents_avg_score (gauge/synthèse)
• Engagement utilisateur :
  • docuchat_successful_responses_total (compteur)
  • docuchat_failed_responses_total (compteur)

Ces métriques permettent à l’équipe de :

• Mettre en place des alertes pour une haute latence ou une augmentation des taux d’erreur.
• Surveiller le coût financier de l’utilisation des LLM en temps réel.
• Identifier les goulets d’étranglement dans le pipeline RAG (par exemple, récupération lente contre LLM lent).
• Comprendre la répartition des scores des documents récupérés, indiquant l’efficacité de la récupération.

3. Traces : Le ‘Chemin pris’

Les traces fournissent une vue d’ensemble du parcours d’une seule requête à travers un système distribué. Pour DocuChat, OpenTelemetry est utilisé pour instrumenter le pipeline LangChain et tous les appels d’API externes. Chaque étape du processus RAG devient une plage au sein d’une trace.

Exemple de flux de trace pour DocuChat :

1. Plage : Requête utilisateur (Plage racine)
   • Attributs : user_id, query, session_id
2. Plage : Récupération
   • Attributs : vector_db_query, k_value, retrieval_engine
   • Plage enfant : Requête Vector DB
     • Attributs : query_vector_size, response_time_ms
   • Plage enfant : Prétraitement de document (le cas échéant)
     • Attributs : num_docs_processed
   • Événements : “3 documents récupérés”, “Aucun document pertinent trouvé”
3. Plage : Génération LLM
   • Attributs : model_name, temperature, prompt_tokens, completion_tokens
   • Plage enfant : Appel API OpenAI
     • Attributs : api_endpoint, status_code, request_id
   • Événements : “La génération du LLM a commencé”, “La génération du LLM est terminée”, “Hallucination du LLM détectée (confiance faible)”
4. Plage : Post-traitement & Réponse
   • Attributs : response_length_chars, sentiment_score

À l’aide d’un backend de traçage (comme Jaeger, Honeycomb, Datadog APM), l’équipe peut :

• Inspecter visuellement la séquence exacte des opérations pour une requête donnée.
• Identifier quelle étape du pipeline RAG consomme le plus de temps.
• Comprendre le contexte transmis au LLM (documents récupérés) pour un trace spécifique.
• Identifier les erreurs ou les comportements inattendus dans des intervalles spécifiques.

4. Retour d’Information Humain & Évaluation : Le ‘Comment Bien’

Les LLMs, par nature, sont probabilistes. Alors que les journaux, les métriques et les traces nous renseignent sur les mécanismes du système, ils ne nous disent pas toujours quelle est la qualité de la sortie du LLM. C’est ici que le retour d’information humain et les métriques d’évaluation automatisées deviennent cruciaux.

Pour DocuChat, nous avons mis en place :

1. Boutons de Vote Positif/Négatif : Mécanisme de retour d’information simple sur chaque réponse. Les votes négatifs déclenchent une alerte pour une révision manuelle si un certain seuil est atteint.
2. Fonctionnalité “Signaler un Problème” : Permet aux utilisateurs de fournir un retour d’information en texte libre sur les hallucinations, les réponses incorrectes ou les informations non pertinentes.
3. Évaluation de Jeu de Données Golden : Un ensemble de questions connues avec des réponses vérifiées par des experts. Exécuter régulièrement DocuChat contre cet ensemble de données et évaluer les réponses en utilisant des métriques telles que :
   • RAGAS : Un cadre spécifiquement pour l’évaluation RAG, mesurant des aspects comme la fidélité, la pertinence des réponses, la précision du contexte et le rappel du contexte.
   • Similarité Sémantique : Utilisation de modèles d’embedding pour comparer la réponse générée avec la réponse de référence.
   • Chevauchement de Mots-Clés : Vérifications simples pour la présence de termes clés.
4. LLM-en-Tant-Que-Juge : Dans certains cas, un LLM plus puissant (par exemple, GPT-4) peut être utilisé pour évaluer la sortie d’un LLM moins puissant (par exemple, GPT-3.5) par rapport à une référence ou pour des critères spécifiques (par exemple, concision, ton).

L’intégration de ces retours permet à l’équipe de :

• Mesurer directement la satisfaction des utilisateurs et identifier les problèmes.
• Améliorer de manière itérative le pipeline RAG (par exemple, affiner la stratégie de segmentation, améliorer le modèle d’embedding, ajuster l’ingénierie des invites).
• Suivre la performance des différentes versions de LLM ou des algorithmes de récupération au fil du temps.

Mise en Œuvre Pratique et Outils

La pile d’observabilité pour DocuChat utilise une combinaison d’outils open-source et commerciaux :

• Journalisation : Le module logging de Python, configuré pour produire du JSON, envoyé à Loki (le système d’agrégation de journaux de Grafana Labs).
• Métriques : Prometheus pour la collecte de données temporelles, exposé via un point de terminaison FastAPI personnalisé avec prometheus_client. Grafana pour la création de tableaux de bord et d’alertes.
• Traçage : OpenTelemetry Python SDK pour l’instrumentation, envoyant des traces à Jaeger. LangChain offre des rappels intégrés pouvant être adaptés à OpenTelemetry.
• Plateformes Spécifiques aux LLM : Des outils comme LangSmith (pour le traçage et l’évaluation avec LangChain), Weights & Biases (pour le suivi des expériences et l’évaluation des modèles), ou Arize AI (pour l’observabilité et la surveillance des LLM) peuvent considérablement simplifier le processus, en particulier pour des cas d’utilisation avancés et des équipes importantes. Pour cette étude de cas, nous avons opté pour une approche plus DIY utilisant des composants open-source pour illustrer les fondamentaux.
• Retour d’Information Humain : Éléments d’interface utilisateur personnalisés intégrés à un service de retour d’information dédié qui journalise vers Loki et met à jour un compteur de métriques.

Avantages et Résultats pour DocuChat

La mise en œuvre de cette stratégie d’observabilité approfondie a entraîné des avantages significatifs pour l’équipe de DocuChat :

• Débogage Plus Rapide : Lorsque qu’un utilisateur a signalé une réponse incorrecte, les ingénieurs pouvaient rapidement retracer la requête, examiner les documents récupérés, l’invite exacte et la réponse du LLM, identifiant souvent des problèmes en quelques minutes.
• Optimisation des Coûts : En surveillant l’utilisation des tokens, l’équipe a identifié des opportunités pour réduire la taille des invitations et expérimenter avec des modèles de LLM moins chers pour des cas d’utilisation spécifiques, conduisant à une réduction de 15 % des coûts d’API.
• Performance Améliorée : Les métriques ont révélé que la base de données vectorielle était parfois lente. Cela a conduit à optimiser la stratégie d’indexation vectorielle et à agrandir la base de données, résultant en une amélioration de 20 % du temps de réponse moyen.
• Fiabilité Renforcée : Les alertes pour les erreurs de l’API du LLM ou les taux élevés d’hallucination ont permis une intervention proactive, empêchant une insatisfaction généralisée des utilisateurs.
• Itération Basée sur les Données : Le retour d’information humain et les métriques d’évaluation ont fourni des preuves concrètes des changements les plus efficaces à apporter au pipeline RAG ou à l’ingénierie des prompts, favorisant ainsi une amélioration continue.
• Transparence : Les parties prenantes ont eu une meilleure vue d’ensemble des performances du système et de la valeur qu’il délivrait.

Défis et Travaux Futurs

Bien que réussie, la mise en œuvre n’a pas été sans défis :

• Volume de Données : Les interactions avec les LLM peuvent générer beaucoup de données (invites, réponses, contexte). Gérer et stocker ces données de manière efficace est crucial.
• Compréhension Contextuelle : Interpréter les sorties des LLM nécessite encore souvent un jugement humain. L’évaluation automatisée s’améliore mais n’est pas parfaite.
• Changements d’Ingénierie des Invites : Les changements fréquents aux invites nécessitent une gestion soigneuse des versions et une assurance que les métriques d’évaluation restent pertinentes.
• Détection d’Hallucinations : Bien que certaines métriques (comme la fidélité RAGAS) aident, la détection solide et en temps réel des hallucinations reste un domaine de recherche actif.

Les travaux futurs pour DocuChat incluent :

• Intégrer une détection avancée des anomalies pour les sorties des LLM.
• Développer des cadres de tests A/B plus sophistiqués pour différentes configurations RAG.
• Explorer la détection proactive des invites adversariales ou des tentatives d’injection d’invites.
• Utiliser des modèles plus petits et ajustés pour des tâches spécifiques afin d’optimiser encore les coûts et la latence.

Conclusion

L’observabilité n’est pas simplement un avantage mais une exigence fondamentale pour construire des applications LLM fiables, performantes et économiques. Comme le montre l’étude de cas de DocuChat, une stratégie approfondie incorporant des journaux structurés, des métriques détaillées, des traces de bout en bout, et un retour d’information humain crucial fournit les aperçus nécessaires pour naviguer dans les complexités uniques des systèmes alimentés par LLM. En investissant dans l’observabilité dès le départ, les équipes de développement peuvent gagner en confiance dans leurs applications LLM, déboguer rapidement des problèmes, optimiser la performance, et finalement offrir une expérience utilisateur supérieure.

🕒 Published: March 26, 2026