Aller au contenu

real-sample-comparison

real-sample-comparison est la page opérateur pour exécuter et interpréter un Real Sample Comparison sur une verticale donnée.

La définition du Read Service et sa philosophie read-only sont documentées dans ../read-services/real-sample-comparison.md.

Cette page se concentre sur l'usage pratique :

  • choisir un échantillon ;
  • lancer la comparaison ;
  • lire les KPI ;
  • décider si on continue vers audit, simulation ou patch.

Rôle pratique

Le real-sample-comparison est la première mesure fiable avant toute correction.

Il permet de comparer, sur un échantillon réel :

  • ancien comportement vs nouveau comportement ;
  • legacy vs Platform ;
  • ou attendu vs observé, selon la verticale.

Position dans le workflow

real-sample-comparison
-> difference-family-audit
-> resolution-status-audit
-> virtual-patch
-> validation-report

Quand l'utiliser

Utiliser cette étape :

  • au démarrage d'une nouvelle verticale read-only ;
  • après un micro-patch local ;
  • après un changement de scoring, policy ou resolver local ;
  • avant d'affirmer qu'une verticale est stable.

Entrées attendues

En pratique, la comparaison exploite :

  • un échantillon DB ou un jeu de cas réels ;
  • les lignes marchandes normalisées ;
  • les identités / projections old et new si elles existent ;
  • les statuts de résolution ;
  • les attributs ou métriques verticaux utiles.

KPI à lire en premier

Toujours commencer par les indicateurs les plus structurants :

  • identity_match_rate
  • differences
  • conflicts
  • blocking_conflicts_new si disponible
  • minor_divergences_new si disponible
  • causes spécialisées selon la verticale

Ensuite seulement, lire les exemples détaillés.

Comment interpréter

Lecture recommandée :

  • match rate élevé + peu de conflits : verticale proche de la validation ;
  • peu de différences mais beaucoup de resolution_status_only : policy à auditer ;
  • peu de différences d'identité mais beaucoup de blocking : conflit policy ou bruit non déclassé ;
  • beaucoup de différences structurées : passer par difference-family-audit avant tout patch.

Décision industrielle

Après real-sample-comparison, les suites possibles sont :

  • lancer difference-family-audit si les écarts sont nombreux ;
  • lancer resolution-status-audit si l'identité semble bonne mais les statuts divergent ;
  • lancer virtual-patch si une règle locale paraît mesurable sans risque ;
  • ne rien modifier si le bruit observé est acceptable ou légitime.

Garde-fous

Cette étape ne doit jamais servir à :

  • patcher directement une verticale ;
  • conclure seule qu'un Core est en défaut ;
  • ignorer les écarts minoritaires mais critiques ;
  • masquer des conflits réels sous un bon score global.

Voir aussi