Présentation de la préparation du modèle

Cette page vous présente les étapes à suivre pour préparer une stratégie de lutte contre le blanchiment d'argent (AML) basée sur l'IA en supposant que vous avez déjà configuré une instance et préparé des ensembles de données.

Présentation des étapes

Le processus de préparation d'un modèle comprend les trois étapes suivantes:

• Étape 1: Configurer un moteur y compris la sélection de la source des hyperparamètres:

  • Réglage : réglage automatique des hyperparamètres
  • Hériter: hériter des hyperparamètres d'une configuration de moteur précédente créé avec une version de moteur antérieure dans le même réglage de version. Ce paramètre vous évite d'effectuer de nouveaux réglages chaque fois que vous adoptez un nouveau modèle. version du moteur de recherche.

  Créer une configuration de moteur stocke les résultats du réglage ou de l'héritage dans une Ressource EngineConfig.

• Étape 2: Générer un modèle

  La création d'un modèle déclenche l'entraînement, qui stocke les résultats en tant que ressource de modèle.

• Étape 3: Évaluer un modèle

  Créer des résultats de backtest évalue les performances du modèle sur un ensemble de mois spécifié, en stockant les résultats récapitulatifs dans une ressource BacktestResult. Vous pouvez éventuellement créer des résultats de prédiction pour évaluer les sorties par parti du modèle.

Une fois que vous avez terminé les étapes précédentes et que les performances du modèle répondent à vos besoins, consultez les conseils dans les sections Générer des scores de risque et expliquer leur explicabilité. Préparez-vous à la gouvernance des modèles et des risques.

Avant de commencer

Avant de commencer, vous avez besoin des éléments suivants :

• Un ou plusieurs ensembles de données
• Version du moteur sélectionnée à utiliser

Exigences concernant les ensembles de données

Pour obtenir des conseils détaillés sur le modèle de données et le schéma, consultez les pages sous Préparer les données pour l'AML basée sur l'IA Cette section explique comment s'assurer que les jeux de données utilisés pour le réglage du moteur, l'entraînement et l'évaluation fonctionnent bien ensemble.

Remarque : La plupart des règles de gouvernance des modèles définissent une exigence de suivi de la lignée des données utilisées dans toutes les opérations de ML, de la configuration du moteur, de l'entraînement et de l'évaluation. Pour vous assurer que les données ne changent pas, nous vous recommandons de créer un instantané de table BigQuery de vos tables BigQuery une fois qu'elles ont passé la validation des données, puis de faire référence à l'instantané dans l'ensemble de données AML AI. Si vous référencez des tables régulièrement mises à jour, les opérations d'IA AML lisent les tables BigQuery chaque fois qu'une opération utilise le jeu de données d'IA AML. Par conséquent, les modifications apportées aux tables BigQuery sous-jacentes peuvent avoir un impact sur le réglage, l'entraînement, le rétrocompatibilité et les prédictions.

Plages temporelles des ensembles de données

Chaque ensemble de données utilisé pour le réglage, l'entraînement, le backtesting et les opérations de prédiction doit contenir des données valides pour une période se terminant à la fin du dernier mois calendaire complet précédant l'heure de fin spécifiée dans l'appel d'API. La durée de dépend de la table, de la version du moteur et de l'opération. La période minimale est décrite en détail dans Comprendre la portée et la durée des données.

Par exemple, pour le réglage du moteur avec les versions de moteur v004.004, la table "Transaction" doit couvrir au moins 30 mois.

La configuration d'un moteur, l'entraînement et l'évaluation (tests rétrospectifs) peuvent être effectués avec un seul ensemble de données ; consultez l'image ci-dessous. Pour garantir de bonnes performances en production en évitant le surajustement, vous devez vous assurer que la période utilisée pour l'évaluation (c'est-à-dire la création de résultats de backtest) est postérieure à la période utilisée pour l'entraînement (c'est-à-dire la création d'un modèle).

Par exemple, si vous utilisez trois périodes pour le rétrocompatibilité et des périodes jusqu'à la fin de février 2024 pour l'entraînement (c'est-à-dire la date de fin début mars 2024), vous pouvez utiliser des périodes jusqu'à la fin de mai 2024 pour le rétrocompatibilité (c'est-à-dire la date de fin début juin 2024).

Cohérence des ensembles de données

Lorsque vous utilisez différents ensembles de données pour les étapes de réglage, d'entraînement et d'évaluation du moteur, assurez-vous que les ensembles de données sont cohérents en ce qui concerne les champs renseignés et la manière dont ils sont renseignés. Cela est important pour la stabilité et les performances du modèle AML.

De même, pour un score de risque de haute qualité, le utilisé pour créer des résultats de prédiction à l'aide d'un modèle doit être cohérent avec l'ensemble de données utilisé pour entraîner le modèle.

Vérifiez en particulier les points suivants:

• La même logique est utilisée pour renseigner chaque champ. Modifier la logique utilisée pour renseigner un champ peut introduire un décalage de caractéristiques entre l'entraînement du modèle une prédiction ou une évaluation.
• La même sélection de champs RECOMMANDÉS est renseignée. Par exemple, supprimer un champ renseigné lors de l'entraînement du modèle peut entraîner une distorsion ou une absence de fonctionnalités sur lesquelles le modèle s'appuie lors de l'évaluation ou de la prédiction.

• La même logique s'applique pour fournir des valeurs. Dans le tableau PartySupplementaryData, la même logique est utilisée pour fournir des valeurs pour chaque champ party_supplementary_data_id.

  • L'utilisation des mêmes données, mais avec des valeurs party_supplementary_data_id différentes, entraîne une utilisation incorrecte des données par le modèle. Par exemple, un champ particulier utilise l'ID 5 dans la table PartySupplementaryData pour un ensemble de données, mais utilise ensuite l'ID 7 dans un autre ensemble de données.
  • Supprimer une valeur party_supplementary_data_id sur laquelle repose un modèle peut avoir des effets imprévisibles. Par exemple, l'ID 3 est utilisé dans PartySupplementaryData dans un ensemble de données, mais n'est sont omises dans un autre jeu de données.

Vous disposez maintenant d'un ensemble de données prêt pour le réglage, l'entraînement et l'évaluation du moteur. Remarque que les opérations du modèle peuvent prendre des dizaines d'heures. Pour savoir comment vérifier si une opération est toujours en cours d'exécution ou si elle est terminée (échec ou réussite), consultez la section Gérer les opérations de longue durée.