Aller au contenu principal
Essentiel6–10 heures

Laboratoire de rapprochement de métriques IA

Validez le SQL et les métriques générés par IA avec un contrat sémantique, des contrôles déterministes, un rapprochement autoritatif et des cas de régression avant qu’un chiffre n’alimente un dashboard ou une décision.

contrats de métriquesvalidation SQLrapprochement de donnéesanalyse des défaillancestests de régression

Scénario

Tâche

L’IA a généré du SQL pour un KPI clé, mais le dashboard affiche un autre chiffre. La requête s’exécute sans erreur, ce qui ne prouve rien : l’écart peut venir du grain, du fuseau horaire, de la cardinalité des jointures, des filtres, de données tardives ou de la définition métier elle-même. Construisez une vérification qui sépare succès syntaxique et correction sémantique tout en conservant une piste de preuve reproductible.

Exécution pas à pas

1. Figer la sémantique avant de générer le SQL

Résultat: L’IA reçoit un contrat de métrique explicite au lieu de deviner les règles métier.

Tâches

  • Documenter le grain et l’unité d’analyse
  • Figer numérateur, dénominateur, filtres et exclusions
  • Définir fuseau horaire, clôture de période et règle de fraîcheur
  • Nommer la table ou le rapport autoritatif et son owner

Vérifications

  • Une métrique possède un seul contrat versionné
  • Les règles métier indéfinies restent des questions ouvertes
  • L’IA ne résout pas seule les ambiguïtés de politique

2. Traiter le SQL généré comme artefact candidat

Résultat: Une exécution réussie ne peut plus masquer une erreur logique.

Tâches

  • Conserver prompt, contexte et requête exacte
  • Valider le schéma et les champs référencés
  • Ajouter des contrôles row count, nulls et doublons
  • Vérifier les clés de jointure et le fan-out one-to-many ou many-to-many

Vérifications

  • Le succès de la requête n’est pas un critère d’acceptation
  • Les champs inconnus ou casts implicites échouent explicitement
  • La cardinalité des jointures est vérifiée séparément des totaux

3. Effectuer le rapprochement autoritatif

Résultat: Le chiffre clé est reproduit indépendamment et tout écart est expliqué.

Tâches

  • Comparer le KPI au rapport ou à la source autoritative
  • Recalculer les totaux avec une requête ou formule indépendante
  • Vérifier segments extrêmes et dates limites
  • N’utiliser une tolérance qu’avec justification métier

Vérifications

  • Un mismatch n’est jamais arrondi en PASS
  • La tolérance possède un owner et une justification
  • Chaque écart est localisé dans la définition, les données, la requête ou l’état de la source

4. Transformer les défaillances en suite de régression

Résultat: Une future modification SQL, schéma ou modèle ne réintroduit pas silencieusement une erreur connue.

Tâches

  • Simuler wrong join, partition stale, décalage de fuseau, filtre manquant et doublons
  • Documenter le signal déterministe attendu
  • Attribuer sévérité et action de release
  • Versionner les fingerprints dataset, query et contrat

Vérifications

  • Une défaillance critique bloque publication
  • Les cas de régression se reproduisent sans LLM judge
  • Un changement du contrat de métrique relance la baseline verification

Critères d’acceptation

  • Le contrat contient grain, définitions, filtres, sémantique temporelle, fraîcheur et source autoritative
  • Le SQL généré est conservé comme artefact candidat versionné avec ses hypothèses
  • Cardinalité des jointures, doublons, nulls, totaux et segments extrêmes ont des contrôles déterministes
  • Le KPI clé est rapproché indépendamment ou conserve une divergence explicite non résolue
  • Au moins cinq cas de défaillance deviennent des tests de régression permanents