6. Monitorización continua

En el monitoreo continuo, los procesos automatizados observan y detectan los problemas de rendimiento y los problemas del modelo. De este modo, los propietarios pueden identificar posibles problemas y amenazas en tiempo real para abordarlos rápidamente.

El monitoreo continuo revela posibles problemas en el modelo, como la calidad de los datos, el cambio de distribución, el cambio de concepto del modelo y la degradación de la calidad del modelo. La supervisión continua también incluye un registro exhaustivo de las medidas tradicionales del sistema, como la saturación, la latencia, el tráfico y los errores. Se ha establecido una práctica estrategia de notificación y alerta para notificar a los propietarios cuando surjan problemas.

6.1 Monitorización de modelos: detección de la calidad de los datos	La monitorización basada en reglas permite saber cuándo los datos entrantes se desvían de los datos de entrenamiento del modelo. Este tipo de supervisión crea un esquema a partir de los datos de entrenamiento, establece restricciones en función de ese esquema y, a continuación, ejecuta excepciones cuando se produce una infracción.
6.2 Monitorización de modelos: cambio de distribución	La supervisión está configurada para observar la distribución de los datos entrantes y comprobar que no se ha desviado de la distribución de los datos de entrenamiento del modelo. Por ejemplo, los datos entrantes se muestrean como una ventana móvil sobre los datos de inferencia. Luego, se ejecuta un trabajo para probar la distribución muestreada y la distribución de entrenamiento para ver si son iguales.
6.3 Supervisión del modelo: desviación conceptual del modelo	Una verificación de la desviación conceptual busca que la relación entre las entradas de un modelo y la variable objetivo permanezca inalterada con respecto a los datos de entrenamiento. Una comprobación adicional consiste en confirmar que las características relativas y su importancia no cambian.
6.4 Supervisión del modelo: comprobación de la evaluación del modelo	Se trata de un control de seguimiento que evalúa si la calidad del modelo se ha degradado. La verificación de evaluación del modelo compara las métricas de evaluación de referencia del tiempo de entrenamiento con los resultados entrantes para evaluar si el nivel de precisión del modelo ha disminuido con los nuevos datos. Como calcula las métricas de precisión, esta comprobación requiere disponer de la veracidad fundamental de los nuevos datos tras la inferencia.
6.5 Capturas del sistema: esquemas de entrada	El sistema ML captura el esquema de los datos de entrenamiento, pruebas y validación. Además de proporcionar información sobre las entradas, los esquemas proporcionan estadísticas sobre su sesgo e integridad.  Los esquemas se utilizan para realizar pruebas inmediatas y comprobar la calidad de los datos en la producción.
6.6 Capturas del sistema: resultados de la evaluación y estadísticas	El sistema ML genera información precisa sobre los datos de validación y entrenamiento. Puede generar las predicciones y las etiquetas reales de las ejecuciones de validación y entrenamiento. Se utilizan como restricciones de monitoreo para el modelo de producción en vivo.
6.7 Capturas del sistema: anomalías	Existe un mecanismo de seguimiento para detectar las anomalías en los flujos de datos entrantes. Si se producen valores atípicos en los datos entrantes o si durante un período de tiempo específico cambia la distribución de las características clave, el sistema reconoce que se trata de una anomalía y la marca.
6.8 Registro: saturación y recursos	Se está registrando el grado de llenado del sistema. Las métricas de recursos y saturación deben centrarse en el uso de la CPU, el uso de la unidad de procesamiento gráfico (GPU), el uso de la memoria y el uso del disco. Estas métricas deben estar disponibles en formato de series temporales con la capacidad de medirse en percentiles. En el caso de los trabajos por lotes, proporciona información sobre el rendimiento, que muestra cuántas unidades de información puede procesar el sistema en cada período de tiempo.
6.9 Registro: latencia	Debe existir un registro para medir el retraso en la comunicación de la red o el tiempo que se tarda en atender una solicitud. Un ingeniero debería poder determinar cuánto tardan los modelos de inferencia en realizar las predicciones y cuánto tardan en cargarse.
6.10 Registro: tráfico	La configuración de registro del tráfico mide el volumen de tráfico en cada instancia. El tráfico se mide por la cantidad de solicitudes HTTP y de bytes o paquetes enviados o recibidos durante un período de tiempo determinado. El registro del tráfico proporciona información sobre la carga de trabajo total que se deposita en un sistema.
6.11 Registro: errores	La configuración de registro de errores captura el número de solicitudes que fallan. Los errores son de los siguientes tipos: Explícitos (por ejemplo, errores HTTP 500) Implícito (por ejemplo, una respuesta correcta de HTTP 200 acompañada de un contenido incorrecto) Política (por ejemplo, si te comprometes a un tiempo de respuesta de un segundo, cualquier solicitud superior a un segundo será un error) Si los códigos de respuesta del protocolo no son suficientes para expresar todas las condiciones de error, es posible que se necesiten protocolos secundarios (internos) para rastrear los modos de falla parcial.
6.12 Notificaciones y alertas	Las notificaciones y alertas se configuran a partir de la supervisión. Las notificaciones incluyen la posibilidad de recibir Slack, notificaciones por correo electrónico, páginas y mensajes del Servicio de Mensajes Cortos (SMS). Alertar no significa enviar notificaciones sobre todas las posibles infracciones. Por el contrario, significa establecer alertas sobre excepciones específicas que sean significativas e importantes para el equipo de desarrollo. De esta forma, se evita la fatiga de las alertas.