Évaluer un modèle

Les résultats des rétrotests fournissent un résumé des performances du modèle dans une période spécifiée. Cela permet de mesurer les performances du modèle sur une période différente de celle utilisée pour l'entraînement, ou également au fil du temps pour détecter une dégradation des performances.

Effectuer un rétrotest

Pour créer une ressource BacktestResult, consultez la section Créer et gérer les résultats des tests backtest.

Vous devez en particulier sélectionner les éléments suivants:

  • Données à utiliser pour le backtesting:

    Spécifiez un ensemble de données et une heure de fin dans la plage de dates de l'ensemble de données.

    L'entraînement utilise des libellés et des fonctionnalités basés sur des mois calendaires complets jusqu'au mois de l'heure de fin sélectionnée, mais sans compter cette information. Pour en savoir plus, consultez la section Plages de temps pour les ensembles de données.

    Spécifiez le nombre de mois de données étiquetées à utiliser pour le backtesting (c'est-à-dire le nombre de périodes de tests arrière).

  • Modèle créé à partir d'un ensemble de données cohérent:

    Consultez la section Configurer un moteur.

Périodes de rétrotest

Le champ backtestPeriods spécifie le nombre de mois calendaires consécutifs au cours desquels utiliser les caractéristiques et les libellés lors de l'évaluation des performances de ce modèle.

Les éléments suivants s'appliquent aux données de backtest:

  • Les mois utilisés dans l'évaluation sont les mois calendaires complets les plus récents avant le endTime spécifié. Par exemple, si endTime correspond à 2023-04-03T23:21:00Z et backtestPeriods correspond à 5, les étiquettes des mois suivants sont utilisées: 2023-03, 2023-02, 2023-01, 2022-12 et 2022-11.
  • Vous devez utiliser les données les plus récentes disponibles pour le backtesting lors de l'évaluation d'un modèle en vue de son utilisation en production.

  • Les périodes de rétrotest doivent être définies sur 3 ou plus. Un minimum de trois mois est requis pour qu'AML AI puisse tenir compte des alertes répétées lors de l'estimation des enquêtes par période.

  • Évitez d'utiliser des mois qui se chevauchent pour l'entraînement et le rétrotest, car cela risque de surentraîner. Assurez-vous que les heures de rétrotest et de fin de l'entraînement sont éloignées d'au moins backtestPeriods. Autrement dit,

    (mois de fin des résultats des tests antérieurs) >= (mois de l'heure de fin du modèle) + backtestPeriods

Si vous le souhaitez, vous pouvez également créer des résultats de prédiction pour un modèle et effectuer vos propres analyses des performances du modèle au niveau d'un tiers.

Retour sur la sortie du test

Les métadonnées des résultats des tests Backtest contiennent les métriques suivantes. Elles indiquent en particulier les éléments suivants:

  • Les performances du modèle par rapport aux étiquettes d'une période distincte et pour différents volumes d'enquête ou seuils de score de risque

  • Toute modification importante des familles de caractéristiques acceptées par l'ensemble de données (réglage du moteur, entraînement, évaluation et prédiction)

Nom de la métrique Description de la métrique Exemple de valeur de métrique
ObservedRecallValues Métrique de rappel mesurée sur l'ensemble de données spécifié pour le backtesting. L'API comprend 20 de ces mesures, à différents points de fonctionnement, réparties uniformément de 0 (non inclus) à 2 * partyInvestigationsPerPeriodHint. L'API ajoute une mesure finale du rappel à partyInvestigationsPerPeriodHint. 

{
  "recallValues": [
    {
      "partyInvestigationsPerPeriod": 5000,
      "recallValue": 0.80,
      "scoreThreshold": 0.42,
    },
    ...
    ...
    {
      "partyInvestigationsPerPeriod": 8000,
      "recallValue": 0.85,
      "scoreThreshold": 0.30,
    },
  ],
}
Manque de précision

Part des valeurs manquantes pour toutes les caractéristiques de chaque famille de caractéristiques.

Idéalement, le champ "Manquant" de toutes les familles de fonctionnalités AML AI doit être proche de 0. Des exceptions peuvent se produire lorsque les données sous-jacentes à ces familles de fonctionnalités ne sont pas disponibles pour l'intégration.

Un changement significatif de cette valeur pour toute famille de caractéristiques entre le réglage, l'entraînement, l'évaluation et la prédiction peut indiquer des incohérences dans les ensembles de données utilisés. 


{
  "featureFamilies": [
    {
      "featureFamily": "unusual_wire_credit_activity",
      "missingnessValue": 0.00,
    },
    ...
    ...
    {
      "featureFamily": "party_supplementary_data_id_3",
      "missingnessValue": 0.45,
    },
  ],
}