Mas leido
Building Stories
Modo Rua: Redefiniendo el desarrollo de aplicaciones mediante iteración centrada en el usuario Ago 23
Building Stories
NuStories: Adaptación de productos para clientes fanáticos en varios países Oct 30
Culture & Values
Cómo los valores y la cultura de Nu dan forma a los productos que creamos Ago 7
Carreras
Reunimos a grandes mentes de diversos orígenes que permiten la discusión y el debate y mejoran la resolución de problemas.
Conoce más sobre nuestras carreras
Escrito por Felipe Almeida
Con aportes de Caique Lima y Luiz Felix
El Aprendizaje Automático en Tiempo Real se refiere a la integración del aprendizaje automático en sistemas que funcionan continuamente; esto a menudo significa modelos que generan puntuaciones y predicciones a pedido, cuando se solicitan.
Como cualquier software de este tipo, las cosas pueden salir mal, y a menudo lo hacen, de diversas formas. Es una máquina bien engrasada en la que una pieza defectuosa suele tener impactos negativos posteriores, como por ejemplo:
Además de lo anterior, existen muchos otros tipos de fallas que se aplican específicamente a los modelos de Aprendizaje Automático:
La principal diferencia entre el software normal y el habilitado para ML es que los modelos de ML pueden fallar silenciosamente.
Es decir, los sistemas de aprendizaje automático pueden estar produciendo predicciones erróneas aunque no haya excepciones explícitas ni mensajes de error.
En las siguientes secciones analizamos las lecciones aprendidas y las mejores prácticas recopiladas a partir de años de aplicación del ML a problemas de la vida real en Nubank.
Alertas vs Monitoreo
El monitoreo de modelos se refiere a comprender y abordar el comportamiento latente, mientras que la alerta generalmente se refiere a detectar problemas urgentes que deben abordarse de inmediato.
Como tal, el enfoque del monitoreo suele ser detectar problemas con el objetivo de comprender e investigar lo que está sucediendo.
Sin embargo, existe una estrecha relación entre alerta y monitoreo: la primera acción que toma alguien que aborda una alerta puede ser precisamente abrir paneles de monitoreo para comparar datos a corto plazo con datos a mediano plazo.
El objetivo de las alertas es hacer que el sistema funcione normalmente lo más rápido posible.
Descubre las oportunidades
Se sigue aplicando el monitoreo operativo
¡Los sistemas habilitados para ML también son software! Esto significa que todos los problemas habituales que pueden ocurrirle a cualquier otro sistema también pueden ocurrirle a los sistemas basados en ML.
A continuación se presentan algunos puntos del monitoreo regular de software que también se aplican a los sistemas ML:
Estado del sistema operativo
Al igual que con cualquier otro software de producción en tiempo real, es posible que desee recibir alertas de métricas y controles de estado periódicos:
Registro/Rastreo
Necesitarás las herramientas habituales de registro y rastreo distribuido para centralizar y permitir el análisis de los datos de registro.
Esto es esencial en las alertas porque la mayoría de las alertas verdaderas generalmente desencadenarán algún tipo de investigación; aquí es donde entra en juego una infraestructura de registro sólida.
Algunas herramientas comunes en este espacio son Splunk, Datadog y New Relic.
Horarios de guardia
Es una práctica estándar en los equipos de ingeniería general tener horarios de guardia para que siempre haya alguien disponible para abordar asuntos urgentes.
Las alertas deben estandarizarse siempre que sea posible
La estandarización ayuda a impulsar la eficiencia y te ayuda a escalar tus procesos.
También te permite ver una colección de cosas como versiones diferentes de la misma cosa, disminuyendo así la carga cognitiva al interactuar con sistemas grandes.
Las alertas no son diferentes, aquí hay algunos ejemplos de lo que se puede/debe estandarizar a este respecto:
Incluir el comportamiento esperado
Al escribir el texto de la alerta, no te limites a decir lo que está mal, di lo que se esperaba y siempre incluye el período de tiempo evaluado.
Esto ayuda a las personas a comprender cuán crítica es la alerta y qué tan rápido deben actuar, lo que aumenta la eficiencia y reduce las posibilidades de falsos positivos.
Las alertas deben ser procesables
Siempre que sea posible, agregua un vínculo o un curso de acción claro para ayudar a los socorristas a actuar en respuesta a las alertas.
Esto es útil tanto para ingenieros experimentados como para principiantes que quizás nunca antes hayan enfrentado un problema específico.
Una manera aún mejor de hacerlo es tener manuales estándar con guías sobre cómo abordar los problemas más comunes, dónde acudir en busca de ayuda, etc. Esto garantiza procesos estandarizados y disminuye los riesgos de error humano.
Pregúntate al crear una alerta: “¿Cuál es la primera información que el socorrista deberá buscar al abordar la alerta? ¿Cómo puedo hacerlo más fácil para ellos?
Haga clic aquí para abrir DLQ y volver a intentar la configuración”
Haz clic aquí para ver el manual de estrategias para problemas y soluciones comunes”.
Haz clic aquí para editar la configuración de escala”
Haz clic aquí para editar este indicador de función o comuníquese con los ingenieros de #some-slack-channel para obtener ayuda”.
Las alertas deben ser fácilmente configurables
Las alertas para los modelos de aprendizaje automático eventualmente quedarán obsoletas con el tiempo.
Esto puede suceder por una multitud de razones: la distribución subyacente de los datos cambió con el tiempo, los requisitos comerciales o de ingeniería han cambiado, o incluso se lanzó otra alerta que ya abarca la actual.
Las alertas dejan de funcionar de dos maneras:
En otras palabras, es posible que sea necesario cambiar la relación precisión/recuperación.
Hazlo para que cualquiera pueda fácilmente:
Haz clic aquí para editar la configuración de alerta”
Haz clic aquí para editar la configuración de alerta
Haz clic aquí para posponer esta alerta durante 6 horas”.
Ten en cuenta a tu audiencia
Las alertas deben redactarse teniendo en cuenta a la audiencia deseada; esto garantizará que el mensaje que deseas transmitir llegue al otro lado.
Diferentes personas desempeñan un papel en la entrega a producción de un sistema funcional habilitado para ML. Estos incluyen, por ejemplo: ingenieros, profesionales de DS/ML y gente de productos/negocios.
Dependiendo de quién sea tu público objetivo, querrás adaptar:
Haz clic aquí para ver la configuración de escala y estado del pod”.
Haz clic aquí para ver el panel de recuperación de funciones”
Haz clic aquí para ver el panel de negocios. Para obtener más información, visita #algún-canal en Slack”.
Ejemplo: la misma alerta se ve a través de 3 lentes diferentes , según el público objetivo
Las alertas deben ser reconocibles y rastreables
Por definición, las alertas deberían ser “raras” y la activación de una alerta es, necesariamente, un evento un tanto caótico y desordenado.
Necesitas al menos una forma sólida de indicar que se está atendiendo una alerta.
Ser capaz de reconocer ayuda a tu equipo a garantizar que haya al menos una persona investigando activamente la alerta actual. También evita que varias personas interfieran entre sí. La mayoría de las herramientas de alerta admiten esto (por ejemplo, OpsGenie).
Además de ser reconocibles, lo ideal es que las alertas sean rastreables, es decir, debe haber un registro del cronograma de la alerta, por ejemplo:
Estos registros ayudan a los futuros ingenieros a encontrar información y probablemente harán que futuros incidentes sean más fáciles y rápidos de abordar.
También te permitirán analizar datos de alerta y descubrir, por ejemplo, culpables comunes del sistema y patrones de alerta.
Otros Consejos
Alertas por ausencia de eventos
Generalmente utilizamos recuentos, promedios y sumas para detectar comportamientos anormales.
Sin embargo, si un servicio en particular ha dejado de funcionar por completo, es posible que no haya registros, lo que significa que no habrá promedios, recuentos ni sumas.
Una forma de abordar esto es tener alertas de latido, mediante las cuales debes hacer ping a alguna API externa para indicar que tu servicio/sistema está en buen estado.
Estas alertas de latido generalmente se configuran con un período de tiempo y si tu servicio/sistema no envía un ping en este período de tiempo, se activará una alerta.
Prueba tus alertas de antemano
Al igual que con cualquier fragmento de código, debes probar que la alerta se active cuando debería.
Una forma de probar las alertas es hacer que los umbrales de activación sean artificialmente bajos, de modo que la alerta sea más sensible y comprobable:
Cuidado con la estacionalidad
Los datos de funciones de los sistemas en tiempo real suelen ser representativos de los datos del cliente. Como tal, es propenso a ciclos naturales como día/noche, día laborable/fin de semana, etc.
Esto puede dificultar los flujos de alerta porque la definición de “comportamiento normal” suele depender de la hora del día, el día de la semana, etc.
Una forma de abordar esto es incluir un umbral de tamaño de muestra mínimo para garantizar que algunas alertas (por ejemplo, la tasa de acciones) solo se activen si hay suficientes datos.
Por ejemplo: activar alerta si la tasa de puntuaciones superiores a 0.9 es superior al 20%, pero solo si el tamaño de la muestra es de al menos 10,000
A escala, el costo será un problema
Cuando operas a una escala lo suficientemente alta (piensa en millones de solicitudes a un modelo en tiempo real por día), el costo se convertirá en un problema.
Por lo general, las alertas deben realizarse en tiempo real (aunque también existen usos para las alertas por lotes), por lo que necesitarás una infraestructura y herramientas sólidas y costosas para manejar todos esos eventos.
Una forma sencilla de solucionar este problema es utilizar datos de muestra para las alertas en lugar de los datos completos.
En otras palabras, podría seleccionar una muestra aleatoria del 10% de sus datos y calcular alertas sobre eso en lugar de utilizar todos los datos; la mayoría de las métricas estadísticas serán las mismas, a una fracción del costo. Recuerda, sin embargo, que el muestreo de los datos sólo produce resultados sólidos si la distribución subyacente es lo suficientemente grande.
Descubre las oportunidades