Vos données synthétiques ont réussi tous les tests et ont quand même brisé votre modèle

Cependant, trois mois plus tard, le modèle de détection de fraude ne parvenait plus à détecter les classes de transactions qu’il avait précédemment détectées sans faute, non seulement avec une dégradation des performances, mais aussi un échec complet. Tout un groupe de comportements extrêmes avait été effectivement retiré de la réalité du modèle.

Après avoir enquêté sur le problème, l’équipe n’a trouvé aucune erreur technique dans les données synthétiques. Toutes les mesures utilisées par l’équipe ont continué à être satisfaisantes.

Mais le problème était qu’aucun de ces indicateurs ne mesurait réellement ce qui comptait vraiment.

Le cadre à trois mesures et pourquoi il induit les praticiens en erreur

Le triangle fidélité-utilité-confidentialité est devenu le lexique standard pour l’évaluation de la qualité des données synthétiques et pour cause. Il capture les trois aspects de la qualité que vous souhaitez réellement atteindre : les données synthétiques ressemblent-elles aux données réelles (fidélité) ; les données synthétiques entraînent-elles des modèles qui se comportent de manière similaire aux modèles formés sur des données réelles (utilitaire) ; et les données synthétiques protègent-elles l’identité des personnes dont proviennent les données (confidentialité) ?

Le cadre lui-même est solide. Cependant, c’est dans l’exécution de ce cadre que des problèmes se posent.

La plupart des praticiens évaluent les trois indicateurs de qualité de manière séquentielle, considérant que la réussite de chacun d’entre eux est suffisante pour le déploiement. Cette approche est erronée pour trois raisons interdépendantes qui nécessitent une explication détaillée :

Problème n°1 : les mesures de fidélité évaluent les distributions marginales, et non les interactions entre les fonctionnalités

Les mesures de fidélité les plus fréquemment utilisées, la divergence KL, le test de Kolmogorov-Smirnov, la distance de variation totale et la distance de Wasserstein mesurent toutes le degré auquel la distribution des caractéristiques individuelles dans l’ensemble de données synthétiques se compare à l’original.
Aucune de ces mesures n’évalue la manière dont les caractéristiques sont corrélées les unes aux autres.

Il s’agit d’une distinction subtile mais cruciale. Par exemple, considérons un ensemble de données sur les soins de santé dont la version synthétique reproduit avec précision les distributions marginales de l’âge des patients et de la gravité de la maladie, les distributions marginales semblent pratiquement impossibles à distinguer. Mais il existe une divergence mineure dans la corrélation entre les deux caractéristiques des données synthétiques. En conséquence, lorsqu’un modèle est formé sur celui-ci, le modèle identifie les signaux appropriés séparément, mais la mauvaise interaction entre les signaux.

En 2025, une étude évaluée par des pairs sur les données synthétiques des patients a évalué cinq modèles génératifs sur trois ensembles de données cliniques. Les résultats ont montré que même si les distributions marginales étaient presque toujours très similaires, les scores de corrélation différaient de 20 points ou plus. Les effets en aval ont été spectaculaires : sur un ensemble de données, les modèles formés sur des données synthétiques ont donné des valeurs d’aire sous courbe (AUC) d’environ 0,80, alors que des valeurs d’AUC d’environ 0,88 ont été obtenues en utilisant les données réelles. La variable qui déterminait s’il s’agissait de la première ou de la seconde solution était la préservation de la corrélation plutôt que la fidélité de la distribution marginale.

Pour résoudre ce problème : Exécutez les tests KS et KL comme référence pour confirmer la similarité des distributions marginales. Incluez toujours une comparaison des matrices de corrélation. Calculez la norme de Frobenius de la différence pour obtenir une valeur unique représentant la quantité de structure de corrélation perdue. Établissez un seuil de perte de structure de corrélation avant de synthétiser les données, pas après.

import numpy as np
import pandas as pd
def correlation_drift_score(real_df: pd.DataFrame, synthetic_df: pd.DataFrame) -> float:
“””
Computes the Frobenius norm of the difference between
real and synthetic correlation matrices.
Lower is better. A score above 0.5 warrants investigation.
“””
real_corr = real_df.corr().fillna(0).values
synth_corr = synthetic_df.corr().fillna(0).values
return np.linalg.norm(real_corr — synth_corr, ‘fro’)
score = correlation_drift_score(real_df, synthetic_df)
print(f”Correlation Drift Score: {score:.4f}”)

Un numéro. Exécutez-le à chaque fois. S’il dépasse votre seuil, retournez au générateur avant de faire quoi que ce soit d’autre.

Problème 2 : les scores d’utilitaire TSTR masquent le comportement de queue alors qu’ils ne représentent que des performances moyennes

S’entraîner sur des données synthétiques, tester sur des données réelles est l’une des mesures utilitaires de référence, et elle mérite la réputation qu’elle a gagnée. Former un modèle sur des données synthétiques et le faire fonctionner correctement sur des données réelles est certainement une preuve significative de son utilité.

Cependant, les scores TSTR sont basés sur des moyennes. Ainsi, ils cachent exactement ce qui va casser la production. Dans l’exemple de détection de fraude présenté au début de cet article, l’AUC TSTR globale était de 91 %, mais lorsque les performances ont été ventilées par décile de volume de transactions, le décile le moins performant (les transactions les plus rares et de plus grande valeur) est tombé à 67 % (les données synthétiques ont généré des transactions courantes avec une grande précision ; cependant, les données synthétiques ne représentaient pas avec autant de précision les scénarios les plus rares ou les plus inhabituels). Par conséquent, le modèle formé sur des données synthétiques a appris les comportements les plus courants avec une extrême précision et les comportements les moins courants avec peu de précision.

C’est le problème de la perte de queue. Il est formellement abordé dans la littérature sur l’effondrement des modèles (Alemohammad et al., 2024, ICLR) et peut être appliqué à tout type de processus de génération de données synthétiques : les modèles génératifs optimisés pour générer des zones de distribution à haute probabilité sous-représentent progressivement les événements rares. Le générateur de données synthétiques ne tente pas de sous-représenter les événements rares : il représente simplement les mathématiques de la façon dont ces modèles apprennent.

Réparer: Ne déclarez pas le TSTR de manière globale. Déclarez le TSTR séparément pour chacun des déciles dans lesquels vous avez stratifié votre variable cible. Les déciles où les performances synthétiques diminuent le plus fortement par rapport aux performances réelles vous indiqueront exactement quels déciles vos données synthétiques ne représentent pas avec précision.

from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import roc_auc_score
import pandas as pd
import numpy as np
def tstr_by_decile(
real_train: pd.DataFrame,
synthetic_train: pd.DataFrame,
real_test: pd.DataFrame,
target_col: str,
n_deciles: int = 10
) -> pd.DataFrame:
“””
Runs TSTR evaluation stratified by deciles of the target variable.
Returns a comparison dataframe for real vs synthetic training performance.
“””
results = []
real_test = real_test.copy()
real_test[‘decile’] = pd.qcut(
real_test[target_col], q=n_deciles, labels=False, duplicates=’drop’
)
feature_cols = [c for c in real_train.columns if c != target_col]
for label, train_df in [(“Real”, real_train), (“Synthetic”, synthetic_train)]:
clf = RandomForestClassifier(n_estimators=100, random_state=42)
clf.fit(train_df[feature_cols], train_df[target_col])
for decile_id, group in real_test.groupby(‘decile’):
if len(group[target_col].unique()) < 2:
continue
score = roc_auc_score(
group[target_col],
clf.predict_proba(group[feature_cols])[:, 1]
)
results.append({
‘Train Source’: label,
‘Decile’: decile_id,
‘AUC-ROC’: round(score, 4)
})
return pd.DataFrame(results).pivot(
index=’Decile’, columns=’Train Source’, values=’AUC-ROC’
)
decile_results = tstr_by_decile(real_train, synthetic_train, real_test, ‘fraud_flag’)
print(decile_results)

Problème 3 : les mesures de confidentialité doivent traiter toutes les fonctionnalités de la même manière alors qu’elles ne le devraient pas.

Le risque d’inférence d’adhésion est la mesure de confidentialité la plus courante. Le risque d’inférence d’adhésion pose une question : un attaquant peut-il déterminer si un enregistrement particulier existe dans l’ensemble de données de formation ? Des scores faibles sont vraiment une bonne nouvelle.

Cependant, ceci est mesuré au niveau de l’enregistrement, donc il mesure le risque d’identifier un enregistrement dans son ensemble. Le type d’attaque le plus risqué est l’inférence d’attributs ; Étant donné les informations accessibles au public sur les caractéristiques d’un individu, un attaquant peut-il identifier un attribut sensible dans les données synthétiques ? Il s’agit du modèle d’attaque qui préoccupe les régulateurs dans le cadre de la norme de réidentification du RGPD et il fonctionne au niveau de la combinaison (et non au niveau de l’enregistrement).

Un cadre consensuel de mesures de confidentialité (Pilgram et al., 2025) a défini trois types de risques distincts : la singularisation (identifier un seul individu), la liaison (lier les enregistrements à travers des ensembles de données) et l’inférence (déduire des attributs sensibles à partir de combinaisons de quasi-identifiants). Les praticiens mesurent presque exclusivement le premier type (Singling Out). Le troisième type de risque (inférence) est le domaine dans lequel les données sensibles fuient réellement et est complètement invisible pour la notation d’inférence d’adhésion standard.

Correctif : hiérarchisez vos fonctionnalités en fonction de leur sensibilité avant la synthèse. Classez-les en publics (caractéristiques qui peuvent être incluses dans les données synthétiques sans restriction), quasi-identifiants (combinaisons de fonctionnalités publiques pouvant permettre la liaison) et sensibles (les attributs que vous essayez de protéger). Mesurez le risque d’inférence d’appartenance uniquement pour les fonctionnalités sensibles et n’incluez pas l’intégralité de l’ensemble de données. Ensuite, effectuez un test d’inférence d’attribut : entraînez un modèle externe pour prédire chaque caractéristique sensible en fonction des quasi-identifiants à l’aide de données synthétiques. Comparez la précision du modèle entraîné à un modèle qui a été entraîné pour prédire chaque caractéristique sensible sur la base des mêmes quasi-identifiants mais en utilisant des données conservées. Si la différence de précision est faible, vos données synthétiques fuient.

from sklearn.ensemble import GradientBoostingClassifier
def attribute_inference_risk(
synthetic_df: pd.DataFrame,
real_test_df: pd.DataFrame,
quasi_identifiers: list,
sensitive_feature: str
) -> dict:
“””
Estimates attribute inference risk by checking how well
a model trained on synthetic data predicts a sensitive feature
using only quasi-identifiers.
High accuracy on real test data = synthetic data is leaking
information about the sensitive attribute.
“””
clf = GradientBoostingClassifier(random_state=42)
clf.fit(synthetic_df[quasi_identifiers], synthetic_df[sensitive_feature])
real_accuracy = clf.score(
real_test_df[quasi_identifiers],
real_test_df[sensitive_feature]
)
majority_class_accuracy = (
real_test_df[sensitive_feature].value_counts(normalize=True).max()
)
lift = real_accuracy — majority_class_accuracy
return {
“inference_accuracy_on_real”: round(real_accuracy, 4),
“baseline_accuracy”: round(majority_class_accuracy, 4),
“inference_lift”: round(lift, 4),
“risk_level”: “HIGH” if lift > 0.10 else “MODERATE” if lift > 0.05 else “LOW”
}
risk = attribute_inference_risk(
synthetic_df, real_test_df,
quasi_identifiers=[‘age_band’, ‘region’, ‘employment_status’],
sensitive_feature=’income_bracket’
)
print(risk)

Lorsque vous voyez un « supérieur à 0,10 » (ou quel que soit le chiffre) pour l’impact, cela signifie que votre ensemble de données synthétiques est un meilleur enseignant pour identifier les attributs sensibles de vos utilisateurs que le hasard. Peu importe que votre score d’inférence d’adhésion (MIS) soit inférieur à 0,10 ou quel que soit le seuil ; ce n’est pas pertinent.

Le cadre d’évaluation unifié

Comme indiqué précédemment, ces trois défis constituent essentiellement un seul défi : ils proviennent chacun de l’utilisation de métriques destinées à évaluer les caractéristiques d’un ensemble de données, puis de l’utilisation de ces mêmes métriques comme base de certification d’un ensemble de données pour un déploiement en production. Ce sont deux tâches très différentes.

Vous trouverez ci-dessous une liste de contrôle complète des évaluations qui comblent chacune des lacunes de l’évaluation :

Dimension, métrique standard, ce qui manque et vérification augmentée

Fidélité

• Divergence KL, test KS
• Structure de corrélation entre les fonctionnalités
• Score de dérive de corrélation (norme Frobenius)

Utilitaire

• ASC moyenne du TSTR
• Performances extrêmes sur des événements rares
• TSTR stratifié par décile cible

Confidentialité

• Risque d’inférence d’adhésion
• Inférence d’attribut via des quasi-identifiants
• Test d’inférence d’attribut

Le bon seuil dépend de votre cas d’utilisation

L’aspect le plus négligé de la table ronde FCA-ICO-Alan Turing Institute sur la validation des données synthétiques était le suivant : « Zéro risque = Zéro utilité ». Les données synthétiques ne peuvent pas être à la fois complètement privées et aussi utiles. La question n’est plus « Est-ce que les données passent ? La question est « Les compromis répondent-ils aux besoins des cas d’utilisation ? »

Les données synthétiques utilisées pour les tests d’assurance qualité en interne pour une application nécessitent une haute fidélité et une précision structurelle. Cependant, l’accès aux données étant contrôlé, l’accent est moins mis sur la confidentialité.

D’un autre côté, les données que vous divulguez à des utilisateurs externes, à des organisations, à des régulateurs ou à des fins de recherche doivent bénéficier de garanties de confidentialité plus élevées. Dans de tels cas, vous pouvez accepter une fidélité statistique inférieure dans les données synthétiques.

Par conséquent, lors du développement de votre cadre d’évaluation, définissez le cas d’utilisation avant d’évaluer vos données synthétiques. Répondez aux questions suivantes avant de générer des données synthétiques :

1) Qui aura accès à cet ensemble de données synthétiques et dans quelles conditions ? Cela établit votre seuil de confidentialité.

2) Quelle tâche en aval ces données seront-elles entraînées ou testées ? Cela définit les mesures des services publics qui sont porteuses par rapport au bruit.

3) Y a-t-il des fonctionnalités requises pour la tâche en aval ? Si tel est le cas, cela définit où vous devez préserver la fidélité et où vous pouvez tolérer la variance.

Établissez ces seuils en fonction de vos réponses aux questions ci-dessus avant d’exécuter la synthèse. Exécutez vos évaluations par rapport à vos seuils établis (et non aux seuils signalés par l’outil par défaut).

Conclusion : l’écart de qualité est un écart de mesure

Le modèle de détection des fraudes n’a pas échoué en raison de la mauvaise qualité des données synthétiques. Le modèle a échoué parce que l’équipe a évalué les mauvaises caractéristiques et a tiré des conclusions incorrectes basées sur leurs mesures correctes. La fidélité, l’utilité et la confidentialité sont les bonnes dimensions.

Les mesures standard au sein de chaque dimension sont de bons points de départ. Cependant, ils ont été développés pour mesurer et décrire des données et non pour certifier des données destinées à une utilisation en production. Combler cet écart de mesure nécessite trois évaluations supplémentaires qui identifient les écarts dans les mesures standard ; dérive de corrélation, utilité de queue par décile et risque d’inférence d’attribut.

Ces trois évaluations ne nécessitent pas d’outils spécialisés. Les trois implémentations décrites dans cet article s’exécutent dans les standards scikit-learn et NumPy. Le travail difficile n’est pas d’écrire le code, il s’agit de poser les bonnes questions avant de mettre votre modèle en production.