{"id":32434,"date":"2025-04-07T11:58:18","date_gmt":"2025-04-07T14:58:18","guid":{"rendered":"https:\/\/building.nu.com\/?p=32434"},"modified":"2025-04-07T12:17:52","modified_gmt":"2025-04-07T15:17:52","slug":"practicas-para-escalar-operaciones-de-machine-learning","status":"publish","type":"post","link":"https:\/\/building.nu.com\/es\/practicas-para-escalar-operaciones-de-machine-learning\/","title":{"rendered":"Pr\u00e1cticas para escalar operaciones de Machine Learning"},"content":{"rendered":"\n

En Nubank, la innovaci\u00f3n en machine learning (ML) y ciencia de datos (DS) impulsa nuestra misi\u00f3n de construir el Futuro P\u00farpura. Recientemente, celebramos la 92\u00aa edici\u00f3n de nuestro DS & ML Meetup, con el tema \u201cPr\u00e1cticas para Escalar Operaciones de Machine Learning\u201d. Este evento profundiz\u00f3 en los desaf\u00edos t\u00e9cnicos y las soluciones para construir sistemas de ML en tiempo real, con un enfoque en la detecci\u00f3n de fraude\u2014un dominio donde la velocidad, precisi\u00f3n y escalabilidad son cr\u00edticas.<\/p>\n\n\n\n

Liderada por Ot\u00e1vio Vasques, Lead Machine Learning Engineer, la sesi\u00f3n explor\u00f3 la arquitectura, estrategias de optimizaci\u00f3n y pr\u00e1cticas de implementaci\u00f3n detr\u00e1s 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\u00e9cnicas para reducir la latencia y los costos de infraestructura, y las mejores pr\u00e1cticas para probar e implementar modelos utilizando el modo shadow.<\/p>\n\n\n\n

En este art\u00edculo, desglosaremos estos insights, ofreciendo una mirada detr\u00e1s de escena de c\u00f3mo Nubank escala las operaciones de machine learning para proteger a millones de clientes. Si eres un cient\u00edfico de datos, ingeniero de ML o simplemente curioso sobre ML en tiempo real, este post ofrece lecciones pr\u00e1cticas para construir sistemas robustos y escalables. \u00a1Vamos all\u00e1!<\/p>\n\n\n\n

\u00bfQu\u00e9 son los modelos en tiempo real?<\/h2>\n\n\n\n

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\u00famenes de datos durante la noche y generan predicciones para el d\u00eda siguiente, los modelos en tiempo real responden a eventos en el momento en que ocurren.<\/p>\n\n\n\n

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

Por ejemplo, si alguien roba tu tarjeta de cr\u00e9dito e intenta hacer una compra, un modelo en tiempo real puede marcar la transacci\u00f3n de inmediato, mientras que un modelo batch solo la detectar\u00eda al d\u00eda siguiente\u2014mucho despu\u00e9s de que el da\u00f1o est\u00e9 hecho.<\/p>\n\n\n\n

La arquitectura de los modelos en tiempo real en Nubank<\/h2>\n\n\n\n

En Nubank, nuestros modelos en tiempo real se construyen sobre una arquitectura robusta que garantiza baja latencia y alta confiabilidad. As\u00ed es como funciona:<\/p>\n\n\n\n

    \n
  1. Model Server: <\/strong>Este es el n\u00facleo 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\u00f3n, seguridad y logging, mientras que la capa de Python se enfoca en la inferencia.<\/li>\n\n\n\n
  2. Flujo de Datos:<\/strong> En un setup batch, los datos fluyen a trav\u00e9s de Grafos Ac\u00edclicos 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.<\/li>\n\n\n\n
  3. Ingenier\u00eda de Features: <\/strong>Los modelos en tiempo real requieren que las features se calculen al instante. Esto a menudo implica consultar m\u00faltiples servicios para recopilar los datos necesarios. Por ejemplo, para detectar fraude, podr\u00edamos necesitar obtener informaci\u00f3n del cliente, historial de transacciones y detalles de la cuenta\u2014todo en tiempo real.<\/li>\n\n\n\n
  4. Procesamiento S\u00edncrono vs. As\u00edncrono: <\/strong>Dependiendo del caso de uso, los modelos en tiempo real pueden operar de forma s\u00edncrona (respondiendo inmediatamente) o as\u00edncrona (procesando eventos con un ligero retraso). La detecci\u00f3n de fraude, por ejemplo, requiere procesamiento s\u00edncrono para bloquear transacciones sospechosas al instante.<\/li>\n<\/ol>\n\n\n\n

    Optimizando para escala y velocidad<\/h2>\n\n\n\n

    Los modelos en tiempo real son intensivos en recursos, especialmente cuando operan a la escala de Nubank. Aqu\u00ed hay algunas de las t\u00e9cnicas que utilizamos para optimizar el rendimiento:<\/p>\n\n\n\n

    1. Implementaci\u00f3n Fragmentada vs. Global<\/h3>\n\n\n\n
      \n
    • Implementaci\u00f3n Fragmentada: <\/strong>Tradicionalmente, implement\u00e1bamos modelos de manera fragmentada, con instancias separadas para diferentes segmentos de clientes (o \u201cshards\u201d). Aunque esto garantiza alta disponibilidad, puede llevar a ineficiencias de recursos, especialmente para modelos que atienden solo a un peque\u00f1o subconjunto de clientes.<\/li>\n\n\n\n
    • Implementaci\u00f3n Global: <\/strong>Al implementar modelos globalmente (es decir, atendiendo todos los shards desde un \u00fanico conjunto de pods), hemos reducido los costos de infraestructura hasta en un 30% mientras mejoramos la estabilidad. Este enfoque tambi\u00e9n simplifica la escalabilidad, ya que no necesitamos mantener pods redundantes para cada shard.<\/li>\n<\/ul>\n\n\n\n

      2. Filtrado Pre-Pol\u00edtica<\/h3>\n\n\n\n
        \n
      • No todos los eventos requieren la atenci\u00f3n de un modelo. Al implementar reglas pre-pol\u00edtica, podemos filtrar eventos de bajo riesgo antes de que lleguen al modelo. Por ejemplo, en la detecci\u00f3n de fraude, hemos reducido el n\u00famero de transacciones procesadas por un modelo de 2.800 por segundo a solo 20 por segundo\u2014ahorrando recursos computacionales significativos.<\/li>\n<\/ul>\n\n\n\n

        3. Paralelizaci\u00f3n de la Recuperaci\u00f3n de Features<\/h3>\n\n\n\n
          \n
        • Los modelos en tiempo real a menudo dependen de m\u00faltiples 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\u00f3n de features ocurra de manera concurrente, en lugar de secuencial.<\/li>\n<\/ul>\n\n\n\n

          4. Monitoreo y Timeouts<\/h3>\n\n\n\n
            \n
          • 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\u00fan podamos tomar decisiones\u2014incluso si faltan algunas features.<\/li>\n<\/ul>\n\n\n\n

            Construyendo pipelines de features confiables<\/h2>\n\n\n\n

            La ingenier\u00eda de features es una parte cr\u00edtica de cualquier modelo de ML, pero es especialmente desafiante en sistemas en tiempo real. As\u00ed es como garantizamos consistencia y confiabilidad:<\/p>\n\n\n\n

              \n
            1. Separaci\u00f3n de features a corto y largo plazo:<\/strong><\/li>\n<\/ol>\n\n\n\n
                \n
              • Features a corto plazo (por ejemplo, transacciones de las \u00faltimas 24 horas) se calculan en tiempo real y se almacenan en una base de datos \u201ccaliente\u201d.<\/li>\n\n\n\n
              • Features a largo plazo (por ejemplo, transacciones de los \u00faltimos 90 d\u00edas) se precomputan en batch y se sirven a trav\u00e9s de un feature store.<\/li>\n<\/ul>\n\n\n\n
                  \n
                1. Feature Stores:<\/strong><\/li>\n<\/ol>\n\n\n\n
                    \n
                  • Utilizamos herramientas como Conrado (una capa de servicio para features batch) y Feature Store (una aplicaci\u00f3n de Spark Streaming) para garantizar consistencia entre pipelines batch y en tiempo real. Estas herramientas tambi\u00e9n simplifican la recuperaci\u00f3n de features y reducen el riesgo de errores.<\/li>\n<\/ul>\n\n\n\n
                      \n
                    1. Infraestructura personalizada:<\/strong><\/li>\n<\/ol>\n\n\n\n
                        \n
                      • 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\u00f3n fallidos) e historiales de transacciones, permiti\u00e9ndonos calcular features complejas en tiempo real.<\/li>\n<\/ul>\n\n\n\n

                        Pruebas y modo shadow<\/h2>\n\n\n\n

                        La implementaci\u00f3n de modelos en tiempo real requiere pruebas rigurosas para garantizar que funcionen como se espera. Aqu\u00ed est\u00e1 nuestro enfoque:<\/p>\n\n\n\n

                          \n
                        1. Pruebas de integraci\u00f3n: <\/strong>Ejecutamos pruebas de integraci\u00f3n extensivas para cubrir casos extremos, como entradas vac\u00edas, tipos de datos incorrectos y errores inesperados.<\/li>\n\n\n\n
                        2. Modo shadow:<\/strong> Antes de implementar completamente un modelo, lo ejecutamos en \u201cmodo shadow\u201d, 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).<\/li>\n<\/ol>\n\n\n\n

                          Reflexiones finales<\/h2>\n\n\n\n

                          Construir modelos de ML en tiempo real es un desaf\u00edo complejo, pero gratificante. En Nubank, hemos aprendido que el \u00e9xito depende de una combinaci\u00f3n de arquitectura robusta, optimizaci\u00f3n cuidadosa y colaboraci\u00f3n entre equipos. Aunque las t\u00e9cnicas que hemos desarrollado est\u00e1n adaptadas a la detecci\u00f3n de fraude, muchos de los principios\u2014como paralelizar la recuperaci\u00f3n de features, monitorear dependencias y probar rigurosamente\u2014pueden aplicarse a otros casos de uso en tiempo real.<\/p>\n\n\n\n

                          Como se enfatiz\u00f3 durante el meetup, no todos los modelos necesitan todas las optimizaciones. La clave es ser cr\u00edtico con tu caso de uso, entender tus restricciones y enfocarte en las mejoras que aportar\u00e1n m\u00e1s valor. Y recuerda: el ML en tiempo real es un esfuerzo de equipo. Se necesitan cient\u00edficos de datos, ingenieros y analistas trabajando juntos para construir sistemas que sean r\u00e1pidos y confiables.<\/p>\n\n\n\n

                          \n