Cette page vous explique comment préparer un modèle d'IA AML, en supposant que vous avez déjà configuré une instance et préparé les ensembles de données nécessaires.
Présentation des étapes
Le processus de préparation d'un modèle se compose des trois étapes suivantes:
Étape 1 : Configurez un moteur, y compris en sélectionnant 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éée avec une version antérieure du moteur dans la même version de réglage. Ce paramètre vous permet d'éviter de réajuster chaque fois que vous adoptez une nouvelle version du moteur de modèle.
La création d'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 backtesting é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 des sections Générer des scores de risque et de l'explicabilité et Préparer la gouvernance du modèle 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'IA AML. Cette section explique comment vous assurer que les ensembles de données utilisés pour le réglage, l'entraînement et l'évaluation du moteur fonctionnent bien ensemble.
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 cette période dépend de la table, de la version du moteur et de l'opération. La période minimale est détaillée 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 (backtesting) peuvent être effectués avec un seul ensemble de données. Consultez l'image suivante. 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 de lutte contre le blanchiment d'argent.
De même, pour obtenir un score de risque de haute qualité, l'ensemble de données utilisé pour créer des résultats de prédiction avec un modèle doit être cohérent avec l'ensemble de données utilisé pour entraîner ce modèle.
Assurez-vous en particulier que:
- La même logique est utilisée pour renseigner chaque champ. Modifier la logique utilisée pour renseigner un champ peut entraîner un décalage des caractéristiques entre l'entraînement du modèle et la prédiction ou l'é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_iddifférentes, entraîne une utilisation incorrecte des données par le modèle. Par exemple, un champ particulier utilise l'ID5dans la table PartySupplementaryData pour un ensemble de données, mais utilise ensuite l'ID7dans un autre ensemble de données. - La suppression d'une valeur
party_supplementary_data_idsur laquelle un modèle s'appuie peut avoir des effets imprévisibles. Par exemple, l'ID3est utilisé dans la table PartySupplementaryData d'un ensemble de données, mais est omis d'un autre ensemble de données.
- L'utilisation des mêmes données, mais avec des valeurs
Vous disposez maintenant d'un ensemble de données prêt à être configuré, entraîné et évalué. Notez que les opérations de modèle peuvent prendre plusieurs 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.