Lab 3 : détecter une dérive automatiquement

Durée : 1 h 30. Prérequis : lab 2 réussi, module 3.

En cours de validation en lab

Configuration pas encore exécutée de bout en bout dans un lab : les noms, versions et paramètres peuvent demander des ajustements.

Le scénario

Le script enchaîne quatre phases et produit, dans le score, la trace d’une dérive injectée volontairement. Il publie sous son propre service, lab3-drift, en réutilisant le pipeline du lab 2. Détection : la moyenne de la phase passe sous 0,6, le seuil commun à tous les labs.

Phase	Ce qui se passe	Score suivi	Ordre de grandeur attendu
Référence	5 questions dans le domaine, 3 répétitions	fidélité au contexte	au-dessus du seuil, vers 0,75
Dérive de données	5 questions hors domaine (cuisine, météo, sport), 2 répétitions	fidélité au contexte	nettement sous le seuil, vers 0,20
Dérive de concept	2 questions dont la réponse a changé dans la réalité, 3 répétitions	comparaison à la vérité terrain	proche de 0 tant que la base n’est pas mise à jour
Dérive de pipeline	top_k passe silencieusement de 3 à 1	fidélité au contexte	sous le seuil, vers 0,45

Ces valeurs sont indicatives : elles varient selon le modèle et d’un lancement à l’autre. La fidélité du kit est un ratio de mots communs entre la réponse et le contexte récupéré, pas une mesure sémantique ; elle suffit à montrer une rupture, pas à noter finement une réponse.

Étape 1 : lancer les quatre phases (10 min)

cd app && python lab3_drift_detection.py
# une seule phase, plusieurs passages :
python lab3_drift_detection.py --phase data --repeat 2

Étape 2 : visualiser la rupture (20 min)

Sur le tableau de bord Drift Detection, repérez :

• la chute du score au passage de la référence à la dérive de données ;
• les événements de dérive émis (mttl_drift_events_total, un par phase en dérive) ;
• le tableau des clients en dérive (drift-tenant, score moyen sous 0,6 sur 15 min).

Pour la dérive de pipeline, ouvrez une trace : la cause, mttl.rag.top_k = 1, est visible dans les attributs du span de récupération.

Étape 3 : dérive de concept (30 min)

La phase concept compare les réponses à une vérité terrain (VERITE_TERRAIN dans le script) : l’offre fictive coûte désormais 59 EUR et répond sous 2 heures, alors que la base dit encore 49 EUR et 4 heures. La fidélité au contexte reste haute, puisque le modèle répète fidèlement une base périmée ; seule la comparaison à la vérité terrain révèle la dérive.

1. Modifiez DOCS dans lab2_rag_pipeline.py (59 EUR, 2 heures).
2. Relancez python lab3_drift_detection.py --phase concept : rien ne change, car les scripts ne réindexent jamais d’eux-mêmes.
3. Lancez python lab2_rag_pipeline.py --reindex, puis la phase concept à nouveau : le score remonte.

Question à discuter : comment industrialiser cette détection ? Versionnement de la base, reconstruction des embeddings, tests de non-régression sur un jeu de référence.

Étape 4 : Grafana ou Phoenix (20 min)

Les traces partent aussi vers Phoenix : le Collector les lui envoie par l’exportateur otlp/phoenix (port 4317 dans le réseau Docker, publié sur 4319 côté hôte). Ouvrez http://localhost:6006 et comparez les deux approches.

# otel/otel-collector-config.yaml (extrait)
exporters:
  otlp/phoenix:
    endpoint: phoenix:4317
    tls:
      insecure: true
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [resource/defaults, transform/genai_compat, batch]
      exporters: [otlp/tempo, otlp/phoenix]

	Grafana	Phoenix
Force	métriques, alertes, astreinte	exploration des conversations, évaluation
Usage	détecter et alerter	comprendre et qualifier

On garde donc les deux. L’alerte part de Grafana, puis l’enquête sur les conversations concernées se fait dans Phoenix.

Étape 5 : plan de réponse (10 min)

Rédigez un plan pour chaque type de dérive :

• données : qui prévenir, sous quel délai ;
• concept : processus de mise à jour de la base, fréquence ;
• pipeline : tests de non-régression et portes de contrôle en intégration continue.

Récapitulatif du lab

Notion	Ce que le lab montre
Détection statistique	moyenne mobile et seuil : suffisant pour démarrer
Étape suivante	KS, PSI, Wasserstein
Grafana et Phoenix	alerte opérationnelle d’un côté, exploration et évaluation de l’autre
Tri	toute alerte a un responsable et une procédure

Révisé le 2 octobre 2026 : encadré sur l’état du kit, scores attendus présentés comme indicatifs, mesure de fidélité du kit expliquée, label client ajouté à la métrique de dérive, réindexation séparée dans l’option --reindex, configuration de l’export des traces vers Phoenix.

Marquer comme lue