Entrenamiento y despliegue del modelo.

Una vez limpiados, preparados y movidos los datos a Object Storage, estará listo para entrenar y desplegar el modelo.

Creación y formación del modelo

Al crear el modelo, se especifica el activo de datos de formación y se definen algunos parámetros. El modelo se entrena automáticamente al crearlo.

El siguiente diagrama muestra el proceso.

Descripción de la ilustración training-flow.png

Este es el proceso para crear y entrenar un modelo:

1. Cree un proyecto. Cree un proyecto en un compartimento de OCI y asígnele un nombre al proyecto. El compartimento puede ser uno específico para contener uno o más proyectos de detección de anomalías.
2. Especifique el activo de datos de formación, que es un archivo de Object Storage. El archivo debe estar limpio y listo para la formación. Si no es así, puede utilizar servicios OCI como Data Science para realizar la limpieza y el procesamiento previo. El archivo puede estar en formato CSV o en formato JSON.
3. Cree el modelo. Cuando crea el modelo, selecciona el activo de datos de formación y define la probabilidad de alarma falsa y el ratio de fracción de formación. El modelo se entrena como parte del proceso de creación.

La documentación del servicio de detección de anomalías contiene instrucciones detalladas sobre cómo hacerlo. Puede utilizar la interfaz de usuario de la consola o puede utilizar la API de REST.

A continuación se ofrecen algunas orientaciones para establecer la falsa probabilidad de alarma y la relación de fracción del tren:

Probabilidad de alarma de falso

Esta es la probabilidad de que una anomalía detectada no sea realmente una anomalía. Defina este valor para que esté cerca del mismo nivel del porcentaje de anomalías que encuentra en escenarios de negocio reales. Un valor 0.01 (1%) es adecuado para muchos escenarios. Cuanto menor sea el valor, mayor será el tiempo necesario para entrenar el modelo. Además, si define la probabilidad de alarma falsa de destino demasiado baja, es posible que el modelo no alcance el destino.

Train Fraction Ratio

Se trata de la cantidad de datos que se utilizan para la formación. Por ejemplo, un valor de 0.7 especifica que el 70% de los datos se utiliza para la formación y el 30% se utiliza para probar y evaluar el rendimiento del modelo.

Desplegar y probar el modelo

Después de crear el modelo, debe desplegarlo para poder utilizarlo.

Cuando se despliega el modelo, está listo para recibir los datos que desea probar para detectar anomalías.

Puede utilizar la interfaz de usuario de la consola para desplegar el modelo o utilizar la API de REST. Al desplegar el modelo, se le asigna un nombre. También puede proporcionar una descripción, pero es opcional. Un modelo puede tener más de un despliegue.

En la siguiente captura de pantalla se muestra un ejemplo de un modelo en la interfaz de usuario de la consola. Para agregar un despliegue, haga clic en el botón Agregar despliegue.

Descripción de la ilustración add-deployment.png

Detectar anomalías

Puede enviar datos para detectar anomalías en lotes o detectar anomalías en los datos de transmisión.

El siguiente diagrama ilustra una arquitectura de proceso en batch.

Descripción de la ilustración predictions-batch-flow.png

Los lotes se procesan de la siguiente manera:

1. Los datos se recopilan en un bloque de Object Storage desde Streaming o desde otras bases de datos a través de Oracle Data Integration.
2. Object Storage es la zona de llegada para que el servicio de detección de anomalías procese los datos por lotes.
3. El procesamiento previo de datos se puede realizar en aplicaciones alojadas, contenedores o mediante funciones sin servidor. Los datos procesados se envían al servicio de detección de anomalías.
4. El servicio de detección de anomalías realiza predicciones utilizando el modelo entrenado y desplegado durante la fase de formación.
5. Las referencias producidas por el servicio de detección de anomalías se convierten en acciones inmediatas que se envían a aplicaciones o plataformas de notificación a través de REST.
6. Los resultados de inferencia del servicio de detección de anomalías se pueden almacenar en el almacenamiento de objetos para su uso posterior en los servicios de análisis, registro y notificación.

La arquitectura de transmisión es más compleja que la arquitectura por lotes, pero se necesita cuando desea detectar anomalías en tiempo real o casi en tiempo real.

El siguiente diagrama ilustra una arquitectura de transmisión.

Descripción de la ilustración predictions-streaming-flow.png

1. El servicio de transmisión ingiere datos de diferentes orígenes de datos de transmisión.
2. El procesamiento previo de datos, si es necesario, se realiza en aplicaciones alojadas, contenedores o mediante funciones sin servidor. Los datos procesados se envían a la interfaz de flujo de servicios de detección de anomalías. Si los datos son bien conocidos y no se necesita ningún procesamiento adicional, el flujo puede conectarse directamente al servicio de detección de anomalías.
3. El servicio de detección de anomalías realiza predicciones utilizando el modelo entrenado y desplegado durante la fase de entrenamiento.
4. El servicio de detección de anomalías publica inferencias en un flujo de salida para las acciones que se deben realizar y el registro.
5. Las referencias producidas por el servicio de detección de anomalías se convierten en acciones inmediatas que se envían a aplicaciones o plataformas de notificación a través de aplicaciones en máquinas virtuales o contenedores o a través de funciones sin servidor.
6. El flujo de salida del servicio de detección de anomalías puede rellenar un pipeline para operaciones y análisis descendentes.

Los resultados de inferencia del servicio de detección de anomalías se pueden almacenar en el almacenamiento de objetos para su uso posterior en los servicios de análisis, registro y notificación.