Cómo hacer que las iniciativas de IA funcionen para Machine Learning Engineering

Escrito por: Felipe Fábio Frigeri y Camila Fragoso

La IA generativa ha traído un conjunto completamente nuevo de capacidades a las empresas de tecnología. En Nubank, donde el código convierte ideas en productos y en mejores experiencias para los clientes, eso abre muchas posibilidades para Machine Learning Engineering (MLE). La preparación de datos, la construcción de datasets, la experimentación, el despliegue y el monitoreo implican pasos que la IA podría ayudar a mejorar, y estas actividades sostienen modelos que informan decisiones de negocio y, en última instancia, impactan a nuestros clientes.

Con Large Language Models (LLMs) rápidos y de fácil acceso, la tentación de automatizar casi cada paso es comprensible. Pero poder construir una solución rápidamente plantea otra pregunta: ¿qué la hará útil más allá del primer experimento exitoso?

Sin criterios claros, las aplicaciones pueden empezar a acumularse sin que nadie sepa quién las va a usar, cómo encajan en el flujo de trabajo o si todavía cumplen su propósito original. Hay algo casi poético en esto: la facilidad y el poder de crear soluciones sofisticadas pueden convertirse precisamente en la razón por la que perdemos de vista los problemas que queríamos resolver.

En el equipo de Tarjeta de Crédito PJ (Pessoa Jurídica, es decir, clientes empresariales), esto nos llevó a ser más selectivos con las iniciativas de IA que impulsamos. Antes de comprometernos con la implementación, queríamos explicar qué problema resolvería un proyecto, cómo evaluaríamos su utilidad y si el enfoque podría servir para otros casos de uso. Siguiendo el valor de Nubank de buscar altos estándares y eficiencia inteligente, organizamos esta discusión en torno a tres preguntas prácticas.

En este post, compartimos esas preguntas y presentamos un proyecto de descubrimiento de features del equipo de Tarjeta de Crédito PJ. Explicamos la idea, cómo respondimos cada pregunta y cómo esas respuestas ayudaron a definir el alcance y el enfoque del proyecto.

Si no sabes a dónde vas, cualquier IA te sirve

Estas preguntas nos dan un punto de partida común para discutir propuestas antes de comprometernos a construirlas. También nos dan algo a lo que volver a medida que los proyectos avanzan.

1. ¿Qué problema o flujo de trabajo estamos tratando de mejorar?

El trabajo de Machine Learning Engineering es una secuencia de tareas que se mueve entre procesos estructurados y trabajo creativo. Del lado de los procesos, sin importar el problema que estemos resolviendo o el modelo que estemos construyendo, algunos pasos siempre forman parte del trabajo: entender el contexto de negocio, recopilar datos, construir datasets, desplegar modelos y monitorearlos.

Luego está el trabajo creativo: explorar una nueva técnica surgida de la investigación, considerar un algoritmo que otro equipo ha estado usando o diseñar una secuencia de experimentos para mejorar las métricas que nos importan. Estos dos lados suelen superponerse, pero nos dan dos formas útiles de abordar la primera pregunta.

¿Qué paso del proceso de modelado podríamos hacer más rápido o más fluido?

Esto podría significar simplificar la experimentación, construir datasets, validar supuestos de negocio, preparar documentación, evaluar modelos o decidir cuándo reentrenarlos. En un entorno de modelado donde gran parte de lo que hacemos ya tiene su propia automatización, ayuda ser específicos sobre de dónde vendría la mejora adicional. ¿Qué parte todavía requiere un esfuerzo considerable? ¿En qué gastamos tiempo una y otra vez que podría destinarse a otro trabajo?

¿Podría la IA ayudarnos a explorar territorios todavía inexplorados?

Otro lugar donde buscar oportunidades es el trabajo que seguimos posponiendo: hipótesis, técnicas o fuentes de datos que nos gustaría investigar, pero para las que no hemos tenido capacidad. Esto podría incluir nuevos algoritmos, enfoques de feature engineering, fuentes de datos o formatos de datos. También podría significar adaptar modelos existentes a un contexto diferente, por ejemplo, investigar dónde tendría sentido pasar de predicciones en batch a decisiones en línea. Una idea que antes requería más tiempo o capacidad de la que teníamos podría volverse viable ahora.

Estas dos preguntas pueden parecer apuntar en direcciones distintas, una hacia la eficiencia de tiempo y la otra hacia la creatividad. Pero ambas nacen de la misma convicción: debemos crear más espacio para el pensamiento científico y la experimentación. Facilitar las tareas recurrentes nos da más tiempo para formular hipótesis, explorar distintos enfoques y probar ideas. Ampliar el alcance de nuestro trabajo nos permite abordar preguntas que antes no podíamos asumir. Ambas sostienen una parte esencial de Machine Learning Engineering: convertir las matemáticas y la ciencia en soluciones prácticas que mejoran las decisiones de negocio y la experiencia de nuestros clientes.

Con ese propósito claro, un proyecto AI-first tiene una condición adicional: la IA debe ser central para lo que hace posible el enfoque propuesto.

2. ¿Cómo podemos medir el éxito: tiempo, alcance o ambos?

Una vez que identificamos una oportunidad, la siguiente pregunta es qué nos convencería de que impulsarla marcó una diferencia.

El tiempo es un punto de partida natural. En ingeniería, hablamos a menudo de time to market, y reducir el tiempo necesario para entregar un modelo es un resultado útil. El mismo razonamiento aplica a pasos individuales, como construir un dataset o evaluar un experimento. Si esa es la mejora buscada, debemos establecer una línea base observando cuánto tiempo tomaba un trabajo comparable antes de introducir la solución. Incluso una medida aproximada nos da algo concreto a lo que volver, siempre que el trabajo siga cumpliendo los estándares de calidad que esperamos.

Para las iniciativas que amplían el alcance de nuestro trabajo, necesitamos explicar cómo vamos a evaluar la utilidad de la nueva capacidad. Poder correr más experimentos nos da una medida observable, pero también debemos identificar qué preguntas nos ayudan a responder esos experimentos y qué decisiones podrían informar.

Por ejemplo, podríamos evaluar sistemáticamente si dos poblaciones de clientes se beneficiarían de modelos separados, revisando un supuesto que antes teníamos poca capacidad de cuestionar. Necesitaríamos evaluaciones comparables y criterios claros para decidir si un cambio está justificado. De igual forma, descubrir más features candidatas amplía nuestras posibilidades, mientras que evaluar su contribución nos dice cuáles vale la pena seguir.

Cuando la oportunidad está más cerca de una iniciativa de negocio, debemos conectar la entrega con el resultado que podría habilitar. Para una nueva política de crédito, eso podría significar identificar a los clientes antes desatendidos a los que podría llegar. La relación no siempre será directa, y las aproximaciones son aceptables, pero debemos poder explicar cómo la nueva capacidad contribuye a los objetivos más amplios del equipo.

Algunos proyectos harán ambas cosas: ampliar lo que podemos asumir y reducir el tiempo necesario para entregarlo. Cuando eso suceda, debemos hacer explícitas ambas ganancias. Las medidas pueden ser aproximadas al principio, pero deben ayudarnos a evaluar si la iniciativa está haciendo nuestro trabajo más efectivo y creando las oportunidades que justificaron construirla.

3. ¿Qué tan reutilizable es nuestra solución?

Un problema bien definido y criterios de éxito claros le dan a una iniciativa de IA una base sólida. Una tercera pregunta que vale la pena hacerse desde el principio es qué tanto de la solución podría ser útil en otros contextos, equipos o problemas.

Al inicio de este post, comentamos cómo la facilidad de construir con IA puede llevar a soluciones que se olvidan rápidamente. Otro riesgo es construir algo tan ligado a su contexto original que adaptarlo se vuelva casi tanto trabajo como empezar de nuevo. En modelado, llamamos overfitting a lo que ocurre cuando un modelo aprende las particularidades de sus datos de entrenamiento con tanto detalle que tiene un mal desempeño con datos nuevos. Aquí hay una analogía útil: una solución de IA puede volverse tan dependiente de un modelo, un repositorio o el flujo de trabajo de una persona que su utilidad apenas va más allá de ese entorno.

Una forma práctica de abordar esto es mirar los pasos recurrentes de Machine Learning Engineering. Preparar datos, evaluar experimentos, desplegar modelos e investigar alertas de monitoreo son actividades familiares para muchos equipos. La pregunta pasa a ser: ¿esto es algo que solo hago yo, o podría otro ML Engineer estar enfrentando el mismo problema?

Incluso dentro de nuestro propio equipo, esa pregunta puede cambiar el diseño. Una automatización construida para evaluar un modelo también podría servir para versiones futuras u otros modelos si hacemos explícitos sus supuestos y mantenemos los inputs específicos del modelo separados de la lógica de evaluación compartida. Otros equipos podrían estar haciéndose preguntas de negocio distintas y, aun así, beneficiarse de partes del mismo proceso.

La facilidad de adopción también importa aquí. Otra persona necesita entender qué hace la solución, qué espera y cómo usarla en su propio trabajo. Una documentación clara y una interfaz sencilla ayudan a convertir la posibilidad de reutilización en algo que la gente realmente pueda adoptar.

Un proyecto AI-first real: descubrimiento automatizado de features a través de grafos de red

Para mostrar cómo estas preguntas guían un proyecto desde la idea inicial hasta la implementación, presentamos una iniciativa de descubrimiento automatizado de features en el equipo de Tarjeta de Crédito PJ. Discutimos las tres preguntas antes de empezar a programar y usamos nuestras respuestas para definir el alcance, los criterios de éxito y las oportunidades de reutilización.

Encontrar nuevas features más allá de los caminos conocidos

Nuestro proceso de descubrimiento de features se había centrado en reutilizar features ya adoptadas por otros modelos, pero nunca probadas en PJ. Queríamos ampliar esa búsqueda para incluir experimentos descartados y señales que nunca se habían convertido en features. El modelado basado en grafos aborda una parte específica de esta oportunidad: aprender interacciones entre features existentes y explorar relaciones en eventos sin procesar. Complementa, en lugar de reemplazar, el trabajo de encontrar y reutilizar candidatas de otros modelos. Nuestro objetivo es darle a la IA generativa autonomía para entrenar modelos predictivos y proponer de forma creativa nuevas features candidatas a partir de los insights de esos experimentos.

Para investigar las interacciones entre features existentes, elegimos el artículo Automatic Feature Generation based on Graph Structure Learning (AFGSL) como referencia de modelado. En la fase 1, las features agregadas se convertirían en nodos de un grafo que intercambian información, produciendo embeddings contextualizados para un modelo de riesgo downstream. Se trata de representaciones aprendidas, no de features de negocio automáticamente interpretables, y las conexiones son predictivas, no causales.

La fase 2 exploraría transacciones y eventos, comparando un baseline de embeddings sin grafo con un grafo temporal que conecta empresas y entidades relacionadas. El modelo de grafo produciría embeddings relacionales; una capa de lectura interpretable opcional convertiría el contexto aprendido en features con nombre. Estos enfoques con eventos sin procesar van más allá del artículo de AFGSL y buscan descubrir señales ausentes en las columnas de features existentes.

Cómo evaluamos estos resultados

Estos resultados requieren evaluaciones distintas. Para los embeddings de cualquiera de las dos fases, la pregunta es qué le aportan al modelo de riesgo downstream, lo que se evalúa mediante comparaciones con baselines adecuados y verificaciones de desempeño out-of-time, calibración y estabilidad. Para las features con un significado definido, un flujo de validación automatizado puede identificar patrones de riesgo que el modelo actual no captura del todo, lo que ofrece un primer indicio de señal adicional y no una prueba de ganancia downstream. La evaluación se profundizaría a medida que las candidatas avancen, usando solo información disponible antes de cada decisión de crédito.

El objetivo a largo plazo es la reutilización más allá de PJ. Una vez que demostremos valor en nuestros modelos, los componentes compartidos de descubrimiento y evaluación podrían apoyar a otros equipos de riesgo, mientras que los inputs específicos de cada modelo siguen siendo configurables. Esto mantiene la iniciativa anclada en un problema concreto, en evidencia de utilidad y en un camino hacia una adopción más amplia.

De qué se trata realmente este trabajo

Este es un vistazo al trabajo que hacemos como Machine Learning Engineers en Nubank. En el centro de nuestro día a día está buscar nuevas ideas, probar hipótesis y convertir la investigación en mejores modelos y experiencias para los clientes. Las preguntas de este post nos ayudan a decidir qué oportunidades impulsar y qué las haría valiosas para el negocio. Si este suena como un entorno que disfrutarías y te gustaría contribuir, explora nuestras vacantes abiertas en Nubank.