Aller au contenu principal
Essentiel•8–14 heures

Laboratoire AI Observability, SLO et preuves runtime

Construisez un contrat d’observabilité pour une charge IA : traces de bout en bout, SLI/SLO segmentés par risque, signaux de qualité et de coût, télémétrie respectueuse de la vie privée, postconditions autoritatives et preuves runtime qui distinguent l’état réel de production d’un joli dashboard.

observabilité IAtracing distribuéconception SLI/SLOpreuves runtimeattribution des coûtstélémétrie respectueuse de la vie privée

Scénario

Tâche

Un service IA affiche un uptime vert et une latence médiane acceptable, mais les tâches à haut risque se dégradent après une modification de model revision, retrieval ou tool dependency. Le dashboard agrégé ne le montre pas, tandis que les prompts bruts dans les traces créent un risque de confidentialité. Construisez un contrat d’observabilité qui relie chaque request à un behavior fingerprint, aux spans model/retrieval/tool, au résultat métier réel et au coût, sans transformer la télémétrie en nouveau stockage de secrets.

Exécution pas à pas

1. Concevoir la trace comme un graphe de preuves, pas comme un dump de logs

Résultat: Une tâche est traçable à travers model, retrieval, tool, approval et résultat autoritatif sans perdre l’identité de release.

Tâches

  • →Définir le correlation/run ID et le contrat de spans parent-enfant
  • →Ajouter un behavior fingerprint sans secrets
  • →Séparer les spans model/retrieval/tool/approval/outcome
  • →Marquer les états de télémétrie sampled, dropped et unavailable

Vérifications

  • ✓La trace permet d’identifier la révision model/config précise
  • ✓Un span manquant n’est pas interprété comme un succès
  • ✓Les labels à forte cardinalité ne créent pas une explosion incontrôlée des coûts

2. Établir la frontière de confidentialité et de minimisation des données

Résultat: L’observabilité fournit assez de preuves pour diagnostiquer sans copier de façon incontrôlée prompts, PII et payloads de tools.

Tâches

  • →Classifier metadata, content et champs sensibles
  • →Appliquer redaction ou hashing avant export
  • →Définir la politique de retention et d’access
  • →Traiter le chemin provider/exporter comme une frontière séparée de data egress

Vérifications

  • ✓Secrets et credentials n’entrent pas dans les spans
  • ✓Le contenu sensible n’est pas activé par défaut pour toutes les traces
  • ✓Retention et deletion ont un owner et un état de policy vérifiable

3. Construire des SLO segmentés par risque et les unit economics

Résultat: L’équipe voit non seulement l’uptime, mais aussi la qualité, le résultat vérifié et le coût selon les classes de tâches.

Tâches

  • →Définir des SLI pour latency, availability, quality et authoritative task success
  • →Séparer les segments normal/high-risk/no-answer/tool-write
  • →Ajouter le coût par tâche vérifiée réussie
  • →Attribuer error budget et blocking threshold aux segments critiques

Vérifications

  • ✓Une moyenne agrégée ne masque pas une régression d’un segment critique
  • ✓Une tâche échouée ou dangereuse ne compte pas comme résultat réussi
  • ✓Chaque SLO possède une source de données, une fenêtre et un owner précis

4. Réaliser un exercice de runtime evidence et d’incident

Résultat: Une alerte mène à une cause reproductible et l’incident devient un contrôle de régression.

Tâches

  • →Injecter un fingerprint model/retrieval obsolète
  • →Simuler un timeout de tool avec side effect incertain
  • →Vérifier le chemin UNKNOWN → reconciliation → verified outcome
  • →Minimiser le défaut en cas replay/regression et le lier au release gate

Vérifications

  • ✓Un runtime mismatch ne peut pas finir en PASS
  • ✓Aucun retry n’a lieu avant reconciliation d’un side effect incertain
  • ✓Le rapport d’incident contient un lien trace/evidence, un control change, un owner et un regression test

Critères d’acceptation

  • Une trace de bout en bout relie release fingerprint, étapes model/retrieval/tool et résultat autoritatif
  • La télémétrie possède un contrat de minimisation des données, redaction, retention et access
  • Les SLI/SLO sont séparés par segments de risque/tâche et incluent le coût par tâche vérifiée réussie
  • Une preuve runtime absente ou obsolète se termine en UNKNOWN/FAIL, jamais en false-green PASS
  • Au moins un incident injecté est converti en replay minimisé et cas permanent de régression