En Nubank, la innovación en machine learning (ML) y ciencia de datos (DS) impulsa nuestra misión de construir el Futuro Púrpura. Recientemente, celebramos la 92ª edición de nuestro DS & ML Meetup, con el tema “Prácticas para Escalar Operaciones de Machine Learning”. Este evento profundizó en los desafíos técnicos y las soluciones para construir sistemas de ML en tiempo real, con un enfoque en la detección de fraude—un dominio donde la velocidad, precisión y escalabilidad son críticas.

Liderada por Otávio Vasques, Lead Machine Learning Engineer, la sesión exploró la arquitectura, estrategias de optimización y prácticas de implementación detrás de los modelos de ML en tiempo real de Nubank. Los temas principales incluyeron las diferencias entre modelos batch y en tiempo real, el papel del Model Server, técnicas para reducir la latencia y los costos de infraestructura, y las mejores prácticas para probar e implementar modelos utilizando el modo shadow.

En este artículo, desglosaremos estos insights, ofreciendo una mirada detrás de escena de cómo Nubank escala las operaciones de machine learning para proteger a millones de clientes. Si eres un científico de datos, ingeniero de ML o simplemente curioso sobre ML en tiempo real, este post ofrece lecciones prácticas para construir sistemas robustos y escalables. ¡Vamos allá!

¿Qué son los modelos en tiempo real?

Los modelos en tiempo real se diferencian de los modelos batch tradicionales en un aspecto crucial: operan dentro de la infraestructura de servicios, no solo en pipelines de datos. Mientras que los modelos batch procesan grandes volúmenes de datos durante la noche y generan predicciones para el día siguiente, los modelos en tiempo real responden a eventos en el momento en que ocurren.

Esto es esencial para casos de uso como la detección de fraude, donde retrasar una decisión incluso unos segundos puede significar la diferencia entre detener una transacción fraudulenta o permitir que se concrete.

Por ejemplo, si alguien roba tu tarjeta de crédito e intenta hacer una compra, un modelo en tiempo real puede marcar la transacción de inmediato, mientras que un modelo batch solo la detectaría al día siguiente—mucho después de que el daño esté hecho.

Descubre las oportunidades

La arquitectura de los modelos en tiempo real en Nubank

En Nubank, nuestros modelos en tiempo real se construyen sobre una arquitectura robusta que garantiza baja latencia y alta confiabilidad. Así es como funciona:

  1. Model Server: Este es el núcleo de nuestra infraestructura de ML en tiempo real. Combina Clojure (para la interfaz con los sistemas internos de Nubank) y Python (para ejecutar los modelos de ML). La capa de Clojure maneja autenticación, seguridad y logging, mientras que la capa de Python se enfoca en la inferencia.
  2. Flujo de Datos: En un setup batch, los datos fluyen a través de Grafos Acíclicos Dirigidos (DAGs), donde las tablas se procesan secuencialmente. En tiempo real, reemplazamos estas tablas por servicios. En lugar de interrumpir el flujo para procesar datos, enviamos eventos al Model Server, que devuelve predicciones en milisegundos.
  3. Ingeniería de Features: Los modelos en tiempo real requieren que las features se calculen al instante. Esto a menudo implica consultar múltiples servicios para recopilar los datos necesarios. Por ejemplo, para detectar fraude, podríamos necesitar obtener información del cliente, historial de transacciones y detalles de la cuenta—todo en tiempo real.
  4. Procesamiento Síncrono vs. Asíncrono: Dependiendo del caso de uso, los modelos en tiempo real pueden operar de forma síncrona (respondiendo inmediatamente) o asíncrona (procesando eventos con un ligero retraso). La detección de fraude, por ejemplo, requiere procesamiento síncrono para bloquear transacciones sospechosas al instante.

Optimizando para escala y velocidad

Los modelos en tiempo real son intensivos en recursos, especialmente cuando operan a la escala de Nubank. Aquí hay algunas de las técnicas que utilizamos para optimizar el rendimiento:

1. Implementación Fragmentada vs. Global

  • Implementación Fragmentada: Tradicionalmente, implementábamos modelos de manera fragmentada, con instancias separadas para diferentes segmentos de clientes (o “shards”). Aunque esto garantiza alta disponibilidad, puede llevar a ineficiencias de recursos, especialmente para modelos que atienden solo a un pequeño subconjunto de clientes.
  • Implementación Global: Al implementar modelos globalmente (es decir, atendiendo todos los shards desde un único conjunto de pods), hemos reducido los costos de infraestructura hasta en un 30% mientras mejoramos la estabilidad. Este enfoque también simplifica la escalabilidad, ya que no necesitamos mantener pods redundantes para cada shard.

2. Filtrado Pre-Política

  • No todos los eventos requieren la atención de un modelo. Al implementar reglas pre-política, podemos filtrar eventos de bajo riesgo antes de que lleguen al modelo. Por ejemplo, en la detección de fraude, hemos reducido el número de transacciones procesadas por un modelo de 2.800 por segundo a solo 20 por segundo—ahorrando recursos computacionales significativos.

3. Paralelización de la Recuperación de Features

  • Los modelos en tiempo real a menudo dependen de múltiples servicios para calcular features. Para minimizar la latencia, paralelizamos estas solicitudes utilizando herramientas como los constructores future y delay de Clojure. Esto asegura que la recuperación de features ocurra de manera concurrente, en lugar de secuencial.

4. Monitoreo y Timeouts

  • Monitoreamos de cerca los tiempos de respuesta de todas las dependencias. Si un servicio comienza a degradarse, establecemos timeouts para evitar que afecte a todo el modelo. Esto garantiza que aún podamos tomar decisiones—incluso si faltan algunas features.

Construyendo pipelines de features confiables

La ingeniería de features es una parte crítica de cualquier modelo de ML, pero es especialmente desafiante en sistemas en tiempo real. Así es como garantizamos consistencia y confiabilidad:

  1. Separación de features a corto y largo plazo:
  • Features a corto plazo (por ejemplo, transacciones de las últimas 24 horas) se calculan en tiempo real y se almacenan en una base de datos “caliente”.
  • Features a largo plazo (por ejemplo, transacciones de los últimos 90 días) se precomputan en batch y se sirven a través de un feature store.
  1. Feature Stores:
  • Utilizamos herramientas como Conrado (una capa de servicio para features batch) y Feature Store (una aplicación de Spark Streaming) para garantizar consistencia entre pipelines batch y en tiempo real. Estas herramientas también simplifican la recuperación de features y reducen el riesgo de errores.
  1. Infraestructura personalizada:
  • Cuando las herramientas existentes no son suficientes, construimos nuestra propia infraestructura. Por ejemplo, hemos creado servicios dedicados para almacenar eventos de riesgo (por ejemplo, intentos de inicio de sesión fallidos) e historiales de transacciones, permitiéndonos calcular features complejas en tiempo real.

Pruebas y modo shadow

La implementación de modelos en tiempo real requiere pruebas rigurosas para garantizar que funcionen como se espera. Aquí está nuestro enfoque:

  1. Pruebas de integración: Ejecutamos pruebas de integración extensivas para cubrir casos extremos, como entradas vacías, tipos de datos incorrectos y errores inesperados.
  2. Modo shadow: Antes de implementar completamente un modelo, lo ejecutamos en “modo shadow”, donde procesa datos reales, pero no afecta las decisiones orientadas al cliente. Esto nos permite validar el rendimiento del modelo y asegurar que cumpla con nuestros SLAs (por ejemplo, 700ms para transacciones PIX).

Reflexiones finales

Construir modelos de ML en tiempo real es un desafío complejo, pero gratificante. En Nubank, hemos aprendido que el éxito depende de una combinación de arquitectura robusta, optimización cuidadosa y colaboración entre equipos. Aunque las técnicas que hemos desarrollado están adaptadas a la detección de fraude, muchos de los principios—como paralelizar la recuperación de features, monitorear dependencias y probar rigurosamente—pueden aplicarse a otros casos de uso en tiempo real.

Como se enfatizó durante el meetup, no todos los modelos necesitan todas las optimizaciones. La clave es ser crítico con tu caso de uso, entender tus restricciones y enfocarte en las mejoras que aportarán más valor. Y recuerda: el ML en tiempo real es un esfuerzo de equipo. Se necesitan científicos de datos, ingenieros y analistas trabajando juntos para construir sistemas que sean rápidos y confiables.

Descubre las oportunidades