Compartir vía

Procedimientos recomendados para usar Multivariate Anomaly Detector API

  • Artículo

Importante

A partir del 20 de septiembre de 2023, no podrá crear nuevos recursos de Anomaly Detector. El servicio Anomaly Detector se retira el 1 de octubre de 2026.

En este artículo, se proporcionan instrucciones sobre los procedimientos recomendados que deben seguirse al usar las API multivariantes de Anomaly Detector (MVAD). En este tutorial, hará lo siguiente:

  • Uso de API: aprenda a usar MVAD sin errores.
  • Ingeniería de datos: aprenda a preparar mejor los datos para que MVAD se ejecute con una mayor precisión.
  • Problemas comunes: obtenga información sobre cómo evitar problemas comunes que encuentran los clientes.
  • Preguntas más frecuentes: obtenga respuestas a las preguntas más frecuentes.

Uso de la API

Siga las instrucciones de esta sección para evitar errores al usar MVAD. Si sigue recibiendo errores, consulte la lista completa de códigos de error para obtener explicaciones y conocer las medidas que debe tomar.

Parámetros de entrada

Parámetros obligatorios

Estos tres parámetros son necesarios en las solicitudes de API de entrenamiento e inferencia:

  • source: vínculo al archivo ZIP que se encuentra en la instancia de Azure Blob Storage con las firmas de acceso compartido (SAS).
  • startTime: hora de inicio de los datos usados para el entrenamiento o la inferencia. Si es anterior a la marca de tiempo más temprana real de los datos, se usará la marca de tiempo más temprana real como punto de partida.
  • endTime: hora final de los datos usados para el entrenamiento o la inferencia, que debe ser posterior o igual a startTime. Si endTime es posterior a la marca de tiempo más reciente real de los datos, se usará la marca de tiempo más reciente real como punto final. Si endTime es igual a startTime, significa la inferencia de un único punto de datos, que se suele usar en escenarios de streaming.

Parámetros opcionales para la API de entrenamiento

Otros parámetros de la API de entrenamiento son opcionales:

  • slidingWindow: cuántos puntos de datos se usan para determinar las anomalías. Número entero entre 28 y 2880. El valor predeterminado es 300. Si slidingWindow es k para el entrenamiento del modelo, deben ser accesibles al menos k puntos desde el archivo de origen durante la inferencia para obtener resultados válidos.

    MVAD toma un segmento de puntos de datos para decidir si el siguiente punto de datos es una anomalía. La longitud del segmento es slidingWindow. Tenga en cuenta dos cosas al elegir el valor de slidingWindow:

    1. Las propiedades de los datos: si son periódicos y la frecuencia de muestreo. Cuando los datos son periódicos, puede establecer una longitud de 1 a 3 ciclos como valor de slidingWindow. Cuando los datos tienen una frecuencia alta (granularidad pequeña), como en el nivel de minutos o segundos, podría establecer un valor relativamente superior para slidingWindow.
    2. El equilibrio entre el tiempo de entrenamiento o inferencia y el posible impacto en el rendimiento. Un valor mayor de slidingWindow puede provocar un tiempo de entrenamiento o inferencia más largo. No hay ninguna garantía de que valores mayores de slidingWindow vayan a dar lugar a mejoras de precisión. Un valor pequeño de slidingWindow puede hacer difícil que el modelo vaya a converger en una solución óptima. Por ejemplo, es difícil detectar anomalías cuando slidingWindow solo tiene dos puntos.

  • alignMode: cómo alinear varias variables (series temporales) en las marcas de tiempo. Hay dos opciones para este parámetro, Inner y Outer, y el valor predeterminado es Outer.

    Este parámetro es fundamental cuando hay una alineación incorrecta entre las secuencias de marcas de tiempo de las variables. El modelo debe alinear las variables en la misma secuencia de marcas de tiempo antes de continuar el procesamiento.

    Inner significa que el modelo solo mostrará los resultados de la detección en las marcas de tiempo en las que todas las variables tienen un valor, por ejemplo, la intersección de todas las variables. Outer significa que el modelo solo mostrará los resultados de la detección en las marcas de tiempo en las que alguna variable tiene un valor, por ejemplo, la unión de todas las variables.

    Este es un ejemplo para explicar los distintos valores de alignModel.

    Variable-1

    timestamp value
    2020-11-01 1
    2020-11-02 2
    2020-11-04 4
    05-11-2020 5

    Variable-2

    timestamp value
    2020-11-01 1
    2020-11-02 2
    2020-11-03 3
    2020-11-04 4

    Combinación Inner de dos variables

    timestamp Variable-1 Variable-2
    2020-11-01 1 1
    2020-11-02 2 2
    2020-11-04 4 4

    Combinación Outer de dos variables

    timestamp Variable-1 Variable-2
    2020-11-01 1 1
    2020-11-02 2 2
    2020-11-03 nan 3
    2020-11-04 4 4
    05-11-2020 5 nan

  • fillNAMethod: cómo rellenar nan en la tabla combinada. Es posible que falten valores en la tabla combinada y se deben controlar adecuadamente. Proporcionamos varios métodos para rellenarlos. Las opciones son Linear, Previous, Subsequent, Zero y Fixed, y el valor predeterminado es Linear.

    Opción Método
    Linear Rellenar los valores nan por interpolación lineal
    Previous Propagar el último valor válido para rellenar los espacios. Ejemplo: [1, 2, nan, 3, nan, 4] ->[1, 2, 2, 3, 3, 4]
    Subsequent Usar el siguiente valor válido para rellenar los espacios. Ejemplo: [1, 2, nan, 3, nan, 4] ->[1, 2, 3, 3, 4, 4]
    Zero Rellenar los valores nan con 0.
    Fixed Rellenar los valores nan con un valor válido especificado que se debe proporcionar en paddingValue.

  • paddingValue: el valor de relleno se usa para rellenar los valores nan cuando fillNAMethod es Fixed y se debe proporcionar en ese caso. En otros casos, es opcional.

  • displayName: parámetro opcional que se usa para identificar los modelos. Por ejemplo, puede usarlo para marcar parámetros, orígenes de datos y cualquier otro metadato sobre el modelo y sus datos de entrada. El valor predeterminado es una cadena vacía.

Esquema de datos de entrada

MVAD detecta anomalías en un grupo de métricas; cada métrica se denomina variable o serie temporal.

  • Puede descargar el archivo de datos de ejemplo de Microsoft para comprobar el esquema aceptado desde: https://aka.ms/AnomalyDetector/MVADSampleData

  • Cada variable debe tener dos, y solo dos, campos, timestamp y value, que deben almacenarse en un archivo de valores separados por comas (CSV).

  • Los nombres de columna del archivo CSV deben ser exactamente timestamp y value, y distinguir mayúsculas de minúsculas.

  • Los valores de timestamp deben cumplir la norma ISO 8601; los de value pueden ser números enteros o decimales con cualquier número de posiciones decimales. Un buen ejemplo del contenido de un archivo CSV:

    timestamp value
    2019-04-01T00:00:00Z 5
    2019-04-01T00:01:00Z 3.6
    2019-04-01T00:02:00Z 4
    … …

    Nota

    Si las marcas de tiempo tienen horas, minutos o segundos, asegúrese de que se redondeen correctamente antes de llamar a las API.

    Por ejemplo, si se da por hecho que la frecuencia de los datos es un punto de datos cada 30 segundos, pero observa marcas de tiempo como "12:00:01" y "12:00:28", es señal segura de que debe procesar previamente las marcas de tiempo a nuevos valores como "12:00:00" y "12:00:30".

    Para obtener más información, vea la sección "Redondeo de marcas de tiempo" del documento de procedimientos recomendados.

  • El nombre del archivo csv se va a usar como nombre de variable y debe ser único. Por ejemplo, "temperature.csv" y "humidity.csv".

  • Las variables para el entrenamiento y las variables para la inferencia deben ser coherentes. Por ejemplo, si usa series_1, series_2, series_3, series_4 y series_5 para el entrenamiento, debe proporcionar exactamente las mismas variables para la inferencia.

  • Los archivos CSV deben comprimirse en un archivo ZIP y cargarse en un contenedor de blobs de Azure. El archivo ZIP puede tener el nombre que desee.

Estructura de carpetas

Un error común en la preparación de datos son las carpetas adicionales del archivo ZIP. Por ejemplo, imagine que el nombre del archivo ZIP es series.zip. Después de descomprimir los archivos en una nueva carpeta ./series, la ruta de acceso correcta a los archivos CSV es ./series/series_1.csv, y una ruta de acceso incorrecta podría ser ./series/foo/bar/series_1.csv.

Ejemplo correcto del árbol de directorios después de descomprimir el archivo ZIP en Windows

.
└── series
    ├── series_1.csv
    ├── series_2.csv
    ├── series_3.csv
    ├── series_4.csv
    └── series_5.csv

Ejemplo incorrecto del árbol de directorios después de descomprimir el archivo ZIP en Windows

.
└── series
    └── series
        ├── series_1.csv
        ├── series_2.csv
        ├── series_3.csv
        ├── series_4.csv
        └── series_5.csv

Ingeniería de datos

Ahora puede ejecutar el código con las MVAD API sin errores. ¿Qué se puede hacer para mejorar la precisión del modelo?

Calidad de los datos

  • A medida que el modelo aprende los patrones normales a partir de los datos históricos, los datos de entrenamiento deben representar el estado normal general del sistema. Si hay gran cantidad de anomalías en los datos de entrenamiento, es difícil que el modelo aprenda estos tipos de patrones. Un umbral empírico de tasa anómala es de 1 % y por debajo para una buena precisión.
  • En general, la proporción de valores que faltan de los datos de entrenamiento debe ser inferior a un 20 %. El hecho de que falten demasiados datos puede hacer que algunos valores se rellenen de forma automática (normalmente valores lineales o constantes) que se aprenden como patrones normales. Esto puede dar lugar a que se detecten puntos de datos reales (que no faltan) como anomalías.

Cantidad de datos

  • El modelo subyacente de MVAD tiene millones de parámetros. Necesita un número mínimo de puntos de datos para aprender un conjunto óptimo de parámetros. La regla empírica es que debe proporcionar 5 000 o más puntos de datos (marcas de tiempo) por variable para entrenar el modelo para una buena precisión. En general, cuantos más datos de entrenamiento tenga, mejor será la precisión. Sin embargo, en los casos en los que no pueda acumular tantos datos, le recomendamos que experimente con menos datos y vea si la precisión comprometida sigue siendo aceptable.

  • Cada vez que llame a la API de inferencia, debe asegurarse de que el archivo de datos de origen contiene suficientes puntos de datos. Normalmente, slidingWindow es mayor el número de puntos de datos que realmente necesitan resultados de inferencia. Por ejemplo, en un caso de streaming en el que cada vez que se quiera hacer una inferencia sobre UNA nueva marca de tiempo, el archivo de datos podría contener solo el slidingWindow inicial más UN punto de datos; entonces se podría seguir y crear otro archivo ZIP con el mismo número de puntos de datos (slidingWindow + 1) pero moviéndolo UN paso hacia el lado "derecho" y enviarlo para otro trabajo de inferencia.

    Cualquier cantidad mayor o "anterior" a la ventana deslizante principal, no afectará el resultado de la inferencia y solo provocaría una disminución del rendimiento. Cualquier cantidad menor puede provocar un error NotEnoughInput.

Resumen de marca de tiempo

En un grupo de variables (serie temporal), cada variable se puede recopilar de un origen independiente. Las marcas de tiempo de diferentes variables pueden ser incoherentes entre sí y con las frecuencias conocidas. Este es un ejemplo sencillo.

Variable-1

timestamp value
12:00:01 1.0
12:00:35 1.5
12:01:02 0.9
12:01:31 2.2
12:02:08 1.3

Variable-2

timestamp value
12:00:03 2.2
12:00:37 2.6
12:01:09 1.4
12:01:34 1.7
12:02:04 2.0

Tenemos dos variables recopiladas de dos sensores que envían un punto de datos cada 30 segundos. Sin embargo, los sensores no envían puntos de datos con una frecuencia estrictamente uniforme, sino que unas veces se adelantan y otras se retrasan. Dado que el MVAD tiene en cuenta las correlaciones entre las distintas variables, las marcas de tiempo deben alinearse apropiadamente para que las métricas puedan reflejar correctamente el estado del sistema. En el ejemplo anterior, las marcas de tiempo de la variable 1 y la variable 2 deben estar correctamente "redondeadas" a su frecuencia antes de la alineación.

Veamos lo que sucede si no se procesan previamente. Si se establece alignMode en Outer (lo que significa la unión de dos conjuntos), la tabla combinada será:

timestamp Variable-1 Variable-2
12:00:01 1.0 nan
12:00:03 nan 2.2
12:00:35 1.5 nan
12:00:37 nan 2.6
12:01:02 0.9 nan
12:01:09 nan 1.4
12:01:31 2.2 nan
12:01:34 nan 1.7
12:02:04 nan 2.0
12:02:08 1.3 nan

nan indica que faltan valores. Obviamente, la tabla combinada no es lo que cabría esperar. La variable 1 y la variable 2 se intercalan, y el modelo MVAD no puede extraer información sobre las correlaciones entre ellas. Si se establece alignMode en Inner, la tabla combinada estará vacía, ya que no hay una marca de tiempo común en la variable 1 y la variable 2.

Por lo tanto, las marcas de tiempo de las variables 1 y 2 deben procesarse previamente (redondearse a las marcas de tiempo de 30 segundos más cercanas) y las nuevas series temporales serán:

Variable-1

timestamp value
12:00:00 1.0
12:00:30 1.5
12:01:00 0.9
12:01:30 2.2
12:02:00 1.3

Variable-2

timestamp value
12:00:00 2.2
12:00:30 2.6
12:01:00 1.4
12:01:30 1.7
12:02:00 2.0

Ahora la tabla combinada es más razonable.

timestamp Variable-1 Variable-2
12:00:00 1.0 2.2
12:00:30 1.5 2.6
12:01:00 0.9 1.4
12:01:30 2.2 1.7
12:02:00 1.3 2.0

Los valores de diferentes variables en marcas de tiempo cercanas están bien alineados y el modelo MVAD ahora puede extraer información de correlación.

Limitaciones

Las API de entrenamiento e inferencia presentan limitaciones, téngalas en cuenta para evitar errores.

Limitaciones generales

  • Ventana deslizante: 28-2880 marcas de tiempo, el valor predeterminado es 300. Para los datos periódicos, establezca la longitud de 2-4 ciclos como ventana deslizante.
  • Números de variable: para la inferencia por lotes y de entrenamiento, como máximo 301 variables.

Limitaciones de entrenamiento

  • Marcas de tiempo: como máximo 1 000 000. Si las marcas de tiempo son demasiado escasas, la calidad del modelo puede disminuir. Se recomienda tener más de 5000 marcas de tiempo.
  • Granularidad: la mínima es per_second.

Limitaciones de la inferencia por lotes

  • Marcas de tiempo: como máximo 20 000, al menos 1 de longitud de ventana deslizante.

Limitaciones de la inferencia de streaming

  • Marcas de tiempo: como máximo 2880, al menos 1 de longitud de ventana deslizante.
  • Detección de marcas de tiempo: de 1 a 10.

Calidad del modelo

¿Cómo tratar con los falsos positivos y negativos en escenarios reales?

Se ha incluido la severidad, la cual indica la importancia de las anomalías. Los falsos positivos se pueden filtrar si se configura un umbral de importancia. A veces pueden aparecer demasiados falsos positivos cuando hay cambios de patrón en los datos de inferencia. En tales casos, es posible que el modelo deba volver a entrenarse con datos nuevos. Si los datos de entrenamiento contienen demasiadas anomalías, podría haber falsos negativos en los resultados de la detección. Esto se debe a que el modelo aprende patrones de los datos de entrenamiento y las anomalías pueden traer sesgo al modelo. Por lo tanto, limpiar los datos correctamente puede ayudar a reducir los falsos negativos.

¿Cómo calcular qué modelo es mejor según la pérdida de entrenamiento y la pérdida de validación?

Por lo general, es difícil decidir qué modelo es el mejor sin un conjunto de datos etiquetado. Sin embargo, podemos aprovechar las pérdidas de entrenamiento y validación para tener una estimación aproximada y descartar esos modelos incorrectos. En primer lugar, es necesario observar si convergen las pérdidas de entrenamiento. Las pérdidas divergentes suelen indicar una mala calidad del modelo. En segundo lugar, los valores de pérdida pueden ayudar a identificar si se produce un sobreajuste o un ajuste insuficiente. Es posible que el rendimiento de los modelos con ajuste insuficiente o sobreajuste no sea el deseado. En tercer lugar, aunque la definición de la función de pérdida no refleja directamente el rendimiento de detección, los valores de pérdida pueden ser una herramienta auxiliar para calcular la calidad del modelo. Los modelos correctos tienen necesariamente un valor bajo de pérdida, por lo que podemos descartar los modelos con valores de pérdida elevados.

Dificultades habituales

Además de la tabla de códigos de error, hemos aprendido de clientes como usted algunos problemas comunes al usar las API de MVAD. Esta tabla le ayudará a evitar estos problemas.

Problema Consecuencia Explicación y solución
Las marcas de tiempo en los datos de entrenamiento o de inferencia no se redondearon para alinearse con la frecuencia de datos respectiva de cada variable. Las marcas de tiempo de los resultados de la inferencia no son las esperadas: o bien, hay muy pocas marcas de tiempo, o bien, demasiadas. Consulte Resumen de marca de tiempo.
Demasiados puntos de datos anómalos en los datos de entrenamiento La precisión del modelo se ve afectada negativamente porque trata los puntos de datos anómalos como patrones normales durante el entrenamiento. Empíricamente, mantener la tasa anómala en un 1 % o menos resultará de ayuda.
Demasiados pocos datos de entrenamiento La precisión del modelo está en peligro. Empíricamente, el entrenamiento de un modelo MVAD requiere 15 000 o más puntos de datos (marcas de tiempo) por variable para mantener una buena precisión.
Toma de todos los puntos de datos con isAnomaly=true como anomalías Demasiados falsos positivos. Debe utilizar tanto isAnomaly como severity (o score) para filtrar las anomalías que no son importantes y (opcionalmente) utilizar la agrupación para comprobar la duración de las anomalías para suprimir el ruido aleatorio. Consulte la sección de preguntas más frecuentes a continuación para ver la diferencia entre severity y score.
Compresión de las subcarpetas en el archivo de datos para el entrenamiento o la inferencia Los archivos de datos csv dentro de subcarpetas se omiten durante el entrenamiento o la inferencia. No se permite ninguna subcarpeta en el archivo ZIP. Consulte Estructura de carpetas para obtener más información.
Demasiados datos en el archivo de datos de inferencia: por ejemplo, comprimir todos los datos históricos en el archivo ZIP de datos de inferencia Es posible que no vea ningún error, pero experimentará un rendimiento inferior al intentar cargar el archivo ZIP en el blob de Azure, así como al intentar ejecutar la inferencia. Consulte Cantidad de datos para obtener más información.
Creación de recursos de Anomaly Detector en regiones de Azure que aún no admiten MVAD y llamada a las API de MVAD Recibirá un error "Recurso no encontrado" al llamar a las MVAD API. Durante la fase de versión preliminar, MVAD solo está disponible en algunas regiones. Por favor, guarde como marcador Novedades de Anomaly Detector para mantenerse al día con los lanzamientos de regiones de MVAD. También puede presentar una incidencia de GitHub o ponerse en contacto con nosotros en AnomalyDetector@microsoft.com para solicitar regiones específicas.

Preguntas más frecuentes

¿Cómo funciona la ventana deslizante de MVAD?

Vamos a usar dos ejemplos para aprender cómo funciona la ventana deslizante de MVAD. Supongamos que ha establecido slidingWindow = 1440 y los datos de entrada están en una granularidad de un minuto.

  • Escenario de streaming: Quiere predecir si el punto de datos UNO en "2021-01-02T00:00:00Z" es anómalo. Sus valores startTime y endTime serán iguales ("2021-01-02T00:00:00Z"). Sin embargo, el origen de datos de inferencia debe contener al menos 1440 + 1 marca de tiempo. Porque MVAD tomará los datos iniciales anteriores al punto de datos objetivo ("2021-01-02T00:00:00Z") para decidir si el objetivo es una anomalía. La longitud de los datos iniciales necesarios es slidingWindow, o 1440 en este caso. 1440 = 60 * 24, por lo que sus datos de entrada deben empezar como máximo en "2021-01-01T00:00:00Z".

  • Escenario de lotes: Tiene múltiples puntos de datos objetivo para predecir. El valor de endTime será mayor que el valor de startTime. La inferencia en estos escenarios se realiza de una manera de "ventana móvil". Por ejemplo, MVAD utilizará los datos de 2021-01-01T00:00:00Z a 2021-01-01T23:59:00Z (inclusive) para determinar si los datos de 2021-01-02T00:00:00Z son anómalos. Luego avanza y utiliza los datos de 2021-01-01T00:01:00Z a 2021-01-02T00:00:00Z (inclusive) para determinar si los datos de 2021-01-02T00:01:00Z son anómalos. Se mueve de la misma manera (tomando 1440 puntos de datos para comparar) hasta la última marca de tiempo especificada por endTime (o la última marca de tiempo real). Por lo tanto, el origen de datos de inferencia debe contener datos a partir de startTime - slidingWindow e idealmente contiene en total de tamaño slidingWindow + (endTime - startTime).

¿Cuál es la diferencia entre severity y score?

Normalmente, le recomendamos que utilice severity como filtro para averiguar las "anomalías" que no son tan importantes para su negocio. Dependiendo de su escenario y patrón de datos, aquellas anomalías que son menos importantes a menudo tienen valores severity relativamente bajos o valores severity altos independientes (discontinuos) como picos aleatorios.

En los casos en los que haya detectado la necesidad de reglas más sofisticadas que los umbrales de severity o la duración de los valores severity altos continuos, es posible que desee utilizar score para generar filtros más eficaces. Comprender cómo usa MVAD score para determinar anomalías puede ayudar:

Consideramos si un punto de datos es anómalo desde la perspectiva global y local. Si score en una marca de tiempo es mayor que un umbral determinado, la marca de tiempo se marca como una anomalía. Si score es menor que el umbral pero relativamente mayor en un segmento, también se marca como anomalía.

Pasos siguientes