L'observabilité LLM au-delà de la latence et du coût

Jusqu’à présent, l’observabilité des applications LLM se concentrait sur les “4 fantastiques” : latence, coût, usage (tokens) et feedback utilisateur (pouce levé/baissé). Ces métriques sont essentielles, mais elles ne nous disent rien sur le comportement qualitatif du modèle. Est-ce que la réponse est factuellement correcte ? Est-ce qu’elle respecte les instructions ? La sortie de frameworks comme “OpenLLM-Observe v2” change la donne en introduisant des métriques sémantiques et comportementales, nous permettant de passer du “comment ça tourne” au “qu’est-ce que ça dit vraiment”.

les nouvelles frontières de la mesure

Ces nouvelles métriques permettent de quantifier des aspects qualitatifs qui étaient jusqu’ici dans l’angle mort de nos dashboards.

comment implémenter ces nouvelles métriques

Ces métriques ne sont pas magiques. Elles nécessitent une instrumentation au niveau du pipeline de l’application LLM, souvent dans un middleware qui intercepte la requête et la réponse.

1. qualité du RAG (Retrieval-Augmented Generation)

La confiance dans un système RAG dépend de sa capacité à utiliser correctement le contexte fourni.

Taux de citation valide: Pour chaque réponse, on vérifie si les sources citées ([doc-1], [doc-2]) correspondent bien aux documents qui ont été injectés dans le prompt. Un taux faible indique que le modèle invente des sources ou utilise mal le contexte.
Distance sémantique: On calcule l’embedding de la question et celui de la réponse. Une grande distance cosinus entre les deux peut signaler une réponse hors-sujet.

# Pseudo-code pour vérifier la validité des citations
def check_citation_validity(response_text, context_sources):
    cited_ids = set(re.findall(r'\[doc-(\d+)\]', response_text))
    context_ids = {src['id'] for src in context_sources}
    
    if not cited_ids:
        return "no_citations"
    if not cited_ids.issubset(context_ids):
        return "invalid_citations"
    return "valid"

2. conformité et sécurité

Ces métriques sont essentielles pour opérer de manière responsable.

Taux de détection PII: Utiliser un détecteur de PII (via des regex ou un petit modèle NER) sur les réponses pour s’assurer qu’aucune donnée personnelle n’est divulguée. L’objectif doit être de zéro.
Score de toxicité: Faire passer la réponse dans un classifieur de toxicité pour obtenir un score. Une alerte est déclenchée si le score dépasse un seuil.

3. performance fonctionnelle (pour les agents)

Si votre LLM peut utiliser des outils, il faut mesurer sa capacité à le faire correctement.

Succès des appels d’outils: Pour chaque tentative d’appel à un outil (API), on enregistre si l’appel a réussi, échoué, ou si les arguments étaient mal formatés.
Respect du format JSON: Si vous attendez une sortie JSON, mesurez le pourcentage de réponses qui sont syntaxiquement valides. Un taux d’échec élevé indique un prompt qui n’est pas assez contraignant.

le dashboard d’observabilité “augmenté”

Votre tableau de bord de pilotage doit intégrer ces nouvelles métriques aux côtés des anciennes.

-- Requête pour un dashboard hebdomadaire
SELECT
    DATE_TRUNC('week', ts)::date AS semaine,
    -- Métriques opérationnelles classiques
    AVG(latency_ms) AS latence_moyenne_ms,
    SUM(total_cost_eur) AS cout_total_eur,
    -- Nouvelles métriques qualitatives
    AVG(CASE WHEN citation_check = 'valid' THEN 1 ELSE 0 END) AS taux_citation_valide,
    AVG(CASE WHEN pii_detected = true THEN 1 ELSE 0 END) AS taux_fuite_pii,
    AVG(tool_call_success_rate) AS taux_succes_outils
FROM
    llm.observability_traces
GROUP BY 1
ORDER BY 1 DESC;

erreurs à éviter

L’over-instrumentation: Mesurer 50 métriques différentes dès le premier jour est le meilleur moyen de se noyer. Commencez par deux ou trois qui sont directement liées au risque principal de votre application.
Les seuils arbitraires: Ne fixez pas de seuil d’alerte sans avoir une baseline. Collectez les données pendant une semaine pour comprendre la distribution normale de vos nouvelles métriques avant de définir vos alertes.
L’absence d’action: Une métrique sans runbook associé est un simple chiffre. Que faites-vous si le taux de citation valide chute de 10% ? La réponse doit être documentée.

faq

Ai-je besoin d’outils payants pour implémenter ces métriques ? Non, pas pour commencer. Vous pouvez implémenter la plupart de ces vérifications avec des librairies open source (ex: pour la détection de PII ou le calcul de distance sémantique) dans un simple middleware Python ou Node.js.
Comment évaluer la pertinence d’une réponse, au-delà des citations ? C’est le problème le plus difficile. La solution la plus robuste reste l’évaluation humaine sur un échantillon. Une autre approche émergente est l’évaluation par un LLM plus puissant (ex: utiliser GPT-4 pour noter la qualité d’une réponse de Mistral), mais cela a un coût et ses propres biais.
Ces métriques ne ralentissent-elles pas le temps de réponse ? Si. C’est un compromis. Les vérifications légères (schéma JSON, citations) ont un impact négligeable. Les vérifications lourdes (score de toxicité, distance sémantique) peuvent ajouter des dizaines de millisecondes. Il faut donc les exécuter de manière asynchrone après avoir envoyé le début de la réponse à l’utilisateur.

Menu