Entraîner et déployer le modèle
Une fois les données nettoyées, préparées et déplacées dans Object Storage, vous êtes prêt à former et à déployer le modèle.
Créer et entraîner le modèle
Lorsque vous créez le modèle, vous indiquez la ressource de données de formation et définissez certains paramètres. Le modèle est entraîné automatiquement lorsque vous le créez.
Le schéma suivant présente le processus.

Description de l'illustration training-flow.png
Voici le processus de création et de formation d'un modèle :
- Créez un projet. Vous créez un projet dans un compartiment dans OCI et attribuez un nom au projet. Le compartiment peut être spécifiquement destiné à contenir un ou plusieurs projets de détection d'anomalies.
- Indiquez la ressource de données de formation, qui est un fichier dans Object Storage. Le fichier doit être propre et prêt pour la formation. Dans le cas contraire, vous pouvez utiliser des services OCI tels que Data Science pour effectuer le nettoyage et le prétraitement. Le fichier peut être au format CSV ou au format JSON.
- Créez le modèle. Lorsque vous créez le modèle, vous sélectionnez la ressource de données de formation et définissez la probabilité d'alarme fausse et le ratio de fraction de formation. Le modèle est formé dans le cadre du processus de création.
La documentation du service de détection des anomalies contient des instructions détaillées sur la procédure à suivre. Vous pouvez utiliser l'interface utilisateur de la console ou l'API REST.
Voici quelques conseils sur la définition de la probabilité de fausse alarme et du rapport de fraction du train :
- Probabilité d'alarme
- Il s'agit de la probabilité qu'une anomalie détectée ne soit pas réellement une anomalie. Définissez cette valeur pour qu'elle soit proche du même niveau de pourcentage d'anomalies que dans les scénarios réels. Une valeur 0.01 (1 %) convient à de nombreux scénarios. Plus la valeur est faible, plus le modèle est long. En outre, si vous définissez la probabilité de fausse alarme cible trop faible, le modèle risque de ne pas atteindre la cible.
- Train Fraction Ratio
- Il s'agit de la quantité de données utilisées pour la formation. Par exemple, la valeur 0.7 indique que 70 % des données sont utilisées pour la formation et que 30 % sont utilisés pour tester et évaluer les performances du modèle.
Déployer et tester le modèle
Après avoir créé le modèle, vous devez le déployer pour pouvoir l'utiliser.
Lorsque le modèle est déployé, il est prêt à recevoir des données que vous souhaitez tester en cas d'anomalie.
Vous pouvez utiliser l'interface utilisateur de la console pour déployer le modèle ou utiliser l'API REST. Lorsque vous déployez le modèle, vous lui attribuez un nom. Vous pouvez également lui donner une description, mais cela est facultatif. Un modèle peut avoir plusieurs déploiements.
La capture d'écran suivante présente un exemple de modèle dans l'interface utilisateur de la console. Pour ajouter un déploiement, cliquez sur le bouton Ajouter un déploiement.

Description de l'illustration add-deployment.png
détecter les anomalies
Vous pouvez soumettre des données pour la détection d'anomalies par lots, ou détecter des anomalies dans les données de transmission en continu.
Le schéma suivant illustre une architecture de traitement par lots.

Description de l'illustration predictions-batch-flow.png
Les lots sont traités comme suit :
- Les données sont collectées dans un bucket Object Storage à partir de Streaming ou d'autres bases de données via Oracle Data Integration.
- Object Storage est la zone de destination des données de lot à traiter par le service de détection d'anomalies.
- Le prétraitement des données peut être effectué sur des applications hébergées, des conteneurs ou via des fonctions sans serveur. Les données traitées sont envoyées au service de détection des anomalies.
- Le service de détection des anomalies effectue des prévisions à l'aide du modèle qui a été formé et déployé pendant la phase d'entraînement.
- Les infos produites par le service de détection des anomalies deviennent des actions immédiates qui sont envoyées aux applications ou aux plates-formes de notification via REST.
- Les résultats d'inférence du service de détection des anomalies peuvent être stockés sur le stockage d'objets pour une utilisation ultérieure dans les services d'analyse, de journalisation et de notification.
L'architecture de diffusion en continu est plus complexe que l'architecture en batch, mais elle est nécessaire lorsque vous souhaitez des détections d'anomalie en temps réel ou quasiment en temps réel.
Le schéma suivant illustre une architecture de transmission en continu.

Description de l'illustration predictions-streaming-flow.png
- Le service de transmission en continu intègre des données provenant de différentes sources de données de transmission en continu.
- Le prétraitement des données, si nécessaire, est effectué sur des applications hébergées, des conteneurs ou via des fonctions sans serveur. Les données traitées sont envoyées à l'interface de flux du service Anomaly Detection. Si les données sont connues et qu'aucun traitement supplémentaire n'est requis, le flux peut se connecter directement au service de détection d'anomalies.
- Le service de détection des anomalies effectue des prévisions à l'aide du modèle qui a été formé et déployé pendant la phase d'entraînement.
- Le service de détection d'anomalies publie des infusions dans un flux de sortie pour les actions à effectuer et la journalisation.
- Les infos produites par le service de détection des anomalies deviennent des actions immédiates qui sont envoyées aux applications ou aux plates-formes de notification via des applications sur des machines virtuelles ou des conteneurs ou via des fonctions sans serveur.
- Le flux de sortie du service Anomaly Detection peut alimenter un pipeline pour les opérations et l'analyse en aval.
Les résultats d'inférence du service de détection des anomalies peuvent être stockés sur le stockage d'objets pour une utilisation ultérieure dans les services d'analyse, de journalisation et de notification.