Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
6. Supervisión continua
En la supervisión continua, los procesos automatizados observan y detectan los problemas de rendimiento y los problemas con el modelo. De este modo, los responsables pueden identificar problemas y amenazas posibles en tiempo real para resolverlos de manera rápida.
La supervisión continua revela problemas posibles con 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 integral de las medidas tradicionales del sistema, como la saturación, la latencia, el tráfico y los errores. Se estableció una práctica estrategia de notificación y alerta para notificar a los responsables cuando surjan problemas.
6.1 Supervisión de modelos: detección de la calidad de los datos |
La supervisión basada en reglas permite saber cuándo se desvían los datos entrantes de los datos de entrenamiento del modelo. Este tipo de supervisión crea un esquema a partir de los datos de entrenamiento, establece restricciones según ese esquema y, a continuación, ejecuta excepciones cuando se produce una infracción. |
6.2 Supervisión de modelos: cambio de distribución |
La supervisión está configurada para observar la distribución de los datos entrantes y verificar que no se desvió de la distribución de los datos de entrenamiento del modelo. Por ejemplo, los datos entrantes se muestrean como una ventana móvil |
6.3 Supervisión del modelo: deriva conceptual del modelo |
Una verificación de la deriva conceptual busca que la relación entre las entradas de un modelo y la variable de destino permanezca inalterada con respecto a los datos de entrenamiento. Una verificación adicional consiste en confirmar que las características relativas y su importancia no cambian. |
6.4 Supervisión del modelo: verificación de la evaluación del modelo |
Se trata de una verificación del seguimiento que evalúa si la calidad del modelo se degradó. 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 disminuyó con los datos nuevos. Como calcula las métricas de precisión, para esta verificación es necesario disponer de la verdad fundamental (o ground truth) de los datos nuevos tras la inferencia. |
6.5 Capturas del sistema: esquemas de entrada |
El sistema de 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 hacer pruebas inmediatas y verificar la calidad de los datos en la producción. |
6.6 Capturas del sistema: resultados de la evaluación y estadísticas |
El sistema de 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 supervisión para el modelo de producción en tiempo real. |
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 periodo 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 |
Existe un registro que indica el nivel de ocupación 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 y poder medirse en percentiles. En el caso de los trabajos por lotes, esto proporciona información sobre el rendimiento, que muestra cuántas unidades de información puede procesar el sistema en cada periodo. |
6.9 Registro: latencia |
Se debe implementar un registro para medir el retraso en la comunicación de red o el tiempo que tarda en atenderse una solicitud. Un ingeniero debe poder evaluar cuánto tiempo tardan los modelos de inferencia en generar predicciones y cuánto tiempo tarda en cargarse el modelo. |
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 periodo 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 presentan errores. Los errores son de los tipos siguientes:
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 seguir los modos de error parcial. |
6.12 Notificaciones y alertas |
Las notificaciones y alertas se configuran a partir de la supervisión. Entre las notificaciones se incluye poder recibir mensajes de Slack, notificaciones por correo electrónico, páginas y mensajes SMS (servicio de mensajes cortos). Alertar no significa enviar notificaciones sobre todas las infracciones posibles. En cambio, significa configurar alertas para excepciones específicas que sean significativas e importantes para el equipo de desarrollo. De esta manera, se evita la fatiga por alertas. |
