Escrito por: Felipe Almeida, con contribuciones de Luiz Felix

Esta es la primera parte de una serie de tres partes sobre feature stores para ML en tiempo real en Nubank. En la parte 2, exploraremos las lecciones que aprendimos al usar feature stores en producción. En la parte 3, recorreremos arquitecturas de extremo a extremo usadas en escenarios del mundo real.

Introducción a las feature stores

Una de las pocas constantes en el desarrollo de software es que los sistemas tienden a acumular entropía y volverse más complejos con el tiempo. Sin embargo, es posible frenar ese deterioro extrayendo funcionalidades comunes a bibliotecas y plataformas. Esto simplifica los sistemas y mantiene la complejidad en niveles manejables.

A medida que una organización orientada por datos crece y madura, el código de ML también tiende a volverse cada vez más complejo. Por ejemplo, cuando los modelos empiezan a usarse en varios equipos, es común ver la lógica de features duplicada en varios lugares. Esto hace mucho más difícil gestionar y mantener esos modelos e impide la reutilización de código en toda la organización.

“Todos los problemas en ciencias de la computación pueden resolverse [agregando] otro nivel de indirección” — David Wheeler

Una estrategia común para abordar este problema es centralizar toda la lógica de features en una biblioteca, de modo que los equipos puedan reutilizar las features de otros en lugar de tener que reescribirlas y duplicarlas cada vez que entrenan un nuevo modelo.

Cuando los modelos se usan para inferencia en tiempo real, hay todavía otra capa de código involucrada, a saber, el código usado para recuperar features en tiempo de inferencia. Ese código de “tiempo de inferencia” suele estar en microservicios del entorno de producción.

Las feature stores son plataformas que centralizan la lógica de features para todos los modelos de una organización. En escenarios de inferencia en tiempo real, la feature store también provee endpoints centralizados para la recuperación de features.

Una feature store es una plataforma que centraliza la gestión de features (en tiempo de entrenamiento y en tiempo de inferencia).

Veamos dos ejemplos de cómo se ve el código de ML con y sin una feature store, tanto en tiempo de entrenamiento como en tiempo de inferencia.

Tiempo de entrenamiento

En tiempo de entrenamiento, usar una feature store significa que cada equipo importará las definiciones de features desde una biblioteca estándar, en lugar de definir las suyas específicas. En la Figura 1 a continuación mostramos ejemplos de cómo se ve el código de entrenamiento con y sin una feature store:

Figura 1 — From feature_store import: en tiempo de entrenamiento, los equipos de ciencia de datos suelen partir de un dataset base que contiene IDs de entidades y timestamps, y luego iterativamente “aplican” features sobre él. Con una feature store, esa “lógica de features” se extrae a una biblioteca compartida y reutilizable.

Tiempo de inferencia

En tiempo de inferencia, las features deben ser recuperadas por algún tipo de orquestador. En arquitecturas basadas en microservicios, ese orquestador será un servicio (llamado “Servicio upstream” en la Figura 2 a continuación) que armará el payload, lo enviará al modelo de ML en tiempo real y manejará las predicciones del modelo:

Figura 2: una feature store abstrae toda la complejidad involucrada en recuperar, calcular y transformar features usadas en tiempo real.

Entrega de features por “llamada directa” vs. basada en streaming

Para proporcionar una feature a un servicio upstream, la feature store necesita primero recuperar esa información de alguna manera. Las dos estrategias más comunes son:

  • (1) Llamada directa: en este modelo, la feature store hace llamadas HTTP directamente a los microservicios que poseen los datos requeridos cada vez que se solicita una feature.
  • (2) Streaming: aquí, los microservicios publican eventos en una capa de streaming, como Kafka, a medida que ocurren los eventos. La feature store entonces consume esos eventos y recupera las features de la capa de streaming cuando es necesario. En algunos casos, estas features también se almacenan en bases de datos locales para un acceso más rápido.

Estas dos estrategias se ilustran a continuación:

Figura 3: las features pueden recuperarse directamente desde servicios de origen o mediante plataformas de streaming como Kafka. Las features basadas en streaming suelen llamarse near-real-time porque pueden tener pequeños retrasos de actualización, normalmente del orden de milisegundos o segundos.

Una sola feature store puede soportar ambas estrategias simultáneamente. Es muy común que algunas features se recuperen directamente desde fuentes primarias (caso (1)), mientras que otras se recuperan desde plataformas de streaming.

Cada estrategia trae ventajas, desventajas y modos de falla distintos. Discutiremos eso en la próxima parte de esta serie.

En las próximas secciones, enumeraremos las ventajas y desventajas de usar feature stores, según nuestra experiencia en Nubank.

Descubre las oportunidades

Pros

Pro: Las feature stores mitigan el sesgo entre entrenamiento e inferencia (training-serving skew)

Training-serving skew se refiere a las diferencias entre cómo se definen las features en tiempo de entrenamiento y en tiempo de inferencia.

Estas inconsistencias rompen la suposición de que los datos en tiempo de inferencia seguirán una distribución similar a la usada durante el entrenamiento. Cuando esa suposición falla, las métricas de desempeño estimadas durante el entrenamiento dejan de reflejar el comportamiento real del modelo.

El training-serving skew ocurre porque la definición de features en tiempo de entrenamiento se hace en el entorno analítico, por científicos de datos, mientras que en tiempo de inferencia muchas veces se hace en el entorno de producción, por ingenieros. Como lo hacen personas distintas, en entornos distintos (frecuentemente con stacks distintos), las diferencias en las implementaciones son muy comunes y difíciles de detectar. Vea un resumen en la Figura 4 a continuación:

Figura 4 — Diferencias entre tiempo de entrenamiento y tiempo de inferencia: el trabajo del modelo lo hacen no solo personas distintas, sino también en entornos distintos y frecuentemente con stacks distintos. Estas diferencias son la causa principal del training-serving skew.

Si la feature store puede manejar tanto los datos de tiempo de entrenamiento como la recuperación en tiempo de inferencia, puede eliminar —o al menos mitigar— el training-serving skew, porque ambas definiciones ahora viven en el “mismo lugar”, por así decirlo.

Las feature stores reducen el riesgo de training-serving skew porque la lógica de features —en tiempo de entrenamiento y en tiempo de inferencia— se hace “en el mismo lugar”.

El monitoreo del training-serving skew también se vuelve más fácil y eficiente. Como todos los datos necesarios están centralizados en un solo lugar, el monitoreo puede ser manejado por el propio equipo de la feature store.

Pro: Las feature stores permiten la descubribilidad y la reutilización de features entre equipos

Las feature stores normalmente tienen un registro o catálogo donde se definen, describen y versionan las features individuales de los modelos.

Esto puede ser tan simple como una carpeta dentro de un repositorio común, una biblioteca, o un sitio interno completo donde los usuarios ingresan información (vea la Figura 5 para inspirarse).

Figura 5 — Ejemplo de registro de features: UI web de ejemplo para un registro de features imaginario. Los usuarios pueden buscar features existentes y encontrar información sobre ellas. Aquí vemos que la feature reported_income está en la versión 3, está siendo usada por 4 modelos y su dueño es la BU de Onboarding.

Estos registros son el lugar perfecto para que los potenciales usuarios (es decir, los practicantes de ML) naveguen por las features existentes y descubran aquellas que no sabían que existían. Los usuarios pueden elegir fácilmente features existentes para añadirlas a un modelo, reduciendo el Time-to-Market (TTM).

Dos escenarios en los que los registros de features son útiles:

  • Crear un modelo baseline (v0) de bajo costo usando features existentes: puede simplemente buscar algunas features comunes y rápidamente desplegar un modelo baseline simple para probar una hipótesis.
  • Aumentar un modelo existente: añadir nuevas features a modelos existentes es una de las tareas más comunes en las que los científicos de datos participan. Los registros de features permiten ver rápidamente qué features ya están disponibles y el esfuerzo involucrado en añadirlas a su modelo.

Pro: Las feature stores aumentan el incentivo para la creación de features

Las empresas suelen basar la progresión de carrera de los empleados en criterios objetivos, para alinear incentivos y promover una dinámica de trabajo más justa. Ejemplos de métricas usadas incluyen el impacto financiero generado por un proyecto, el número de personas que usan una herramienta o plataforma dada, NPS o feedback de usuarios, etc.

Crear features es una tarea importante, que normalmente tiene impactos financieros en la organización. Por eso, los practicantes de ML están incentivados a hacerlo, ya que lleva a un mayor impacto financiero que, a su vez, lleva a una mejor progresión de carrera. Ese impacto es aún mayor si otros equipos pueden usar las features creadas por los individuos; por lo tanto, el incentivo para que los practicantes creen features también aumenta. Vea un resumen en la Figura 6 a continuación:

Figura 6 — Los incentivos importan: crear features en una feature store normalmente implica trabajo extra (hay que crear metadatos, conseguir revisiones de otros equipos, etc.), pero aumenta de forma desproporcionada el impacto de dichas features, lo que a su vez ayuda a la progresión de carrera de los practicantes. Gana-gana.

Los incentivos son importantes: las feature stores aumentan el impacto de las features que, a su vez, aumenta el impacto organizacional de los practicantes de ML y los incentivos para crearlas.

Pro: Las feature stores centralizan la gestión de features en una sola plataforma, aumentando la eficiencia

Recuperar features de modelo en tiempo real desde una feature store (en lugar de hacerlo desde los servicios de origen de cada feature individualmente) significa que muchas responsabilidades ahora pueden “abstraerse” en la plataforma.

La observabilidad es un buen ejemplo. Una feature store puede instrumentar fácilmente la recuperación de features con logs y métricas cada vez que un servicio upstream las solicita. También puede generar dashboards de monitoreo genéricos para que las partes interesadas tengan visibilidad sobre las distribuciones de features y monitoreen problemas. Vea una representación visual a continuación.

Figura 7 — Logs y métricas centralizados permiten que los servicios cliente obtengan observabilidad “gratis”, sin implementar funcionalidad repetitiva para cada integración.

Muchas otras responsabilidades también pueden extraerse a una plataforma de feature store para que los equipos clientes no tengan que lidiar con ellas:

  • Documentación: toda la documentación de features puede centralizarse en un registro de features (como se muestra en la Figura 5), que es parte de la feature store.
  • Mantenimiento: actualizar el código de las features para corregir bugs, mejorar la eficiencia y gestionar el versionado. Todo esto se vuelve mucho más eficiente cuando lo maneja un equipo dedicado y especializado.
  • Capacidades de depuración/troubleshooting: la plataforma puede crear herramientas centralizadas para visualización y procesamiento de logs (p. ej., visualización de tracing distribuido, consultas SQL sobre logs y más).
  • Caché: es muy común que los valores de features se cacheen para reducir costos y tiempos de procesamiento. Proveer esa capa de caché en los puntos de entrada de la plataforma puede hacerlo fácilmente el equipo de la feature store.
  • Gobernanza/Auditoría: las organizaciones que operan en entornos altamente regulados (p. ej., banca, salud, defensa) suelen necesitar mantener trazas de auditoría precisas de cómo se usan los modelos. Algunos ejemplos:
  • ¿Cuáles fueron los valores exactos de las features y el score de salida para cada instancia individual evaluada? (o al menos una muestra de esto)
  • ¿Qué versión exacta del modelo se estaba usando en un momento específico?

Contras

Contra: Las feature stores pueden volverse cuellos de botella para equipos que necesitan iterar rápido

Desde el punto de vista de los equipos clientes, recuperar una feature desde una plataforma de feature store puede ser más difícil que hacerlo “a la manera habitual” (es decir, consultando directamente su fuente primaria).

Como resultado, los equipos con ciclos de experimentación muy cortos pueden ver la plataforma como una fuente de fricción. Esto generalmente ocurre en escenarios como:

Pruebas de concepto (PoCs) rápidas

Un equipo quiere crear una feature simple para probar una nueva fuente de datos, pero tener que agregarla primero a la FS añade demasiado overhead y desvirtúa el propósito de una PoC simple.

Capacidades aún no disponibles en la feature store

Un equipo necesita funcionalidad personalizada (como pre-procesamiento o post-procesamiento personalizado) que aún no existe en la plataforma. Sin embargo, el equipo de la FS tiene su propio roadmap y objetivos y no puede priorizar habilitar esa funcionalidad ahora.

Por supuesto, el equipo de la FS puede y debe hacer la plataforma lo más simple posible de usar. La facilidad de uso reduce el overhead y, por lo tanto, reduce estos problemas. Aprendimos varias lecciones sobre este tema, como veremos en la parte 2 de esta serie.

Contra: Las arquitecturas ingenuas pueden introducir latencia adicional

La implementación más “ingenua” de una feature store en tiempo real es como una “capa intermedia” entre los modelos y los servicios upstream que poseen las features.

Sin embargo, esta nueva capa agregará algo de overhead de latencia en comparación con el acceso directo a esas fuentes (simplemente porque se están agregando llamadas extra de red o de base de datos al flujo).

Puede ser un problema en escenarios donde los milisegundos hacen diferencia (p. ej., High-frequency Trading), pero estos casos son poco frecuentes. Aun así, existen varias estrategias para reducir este impacto:

  • Prefetching: se refiere a obtener y cachear las próximas features (antes de que siquiera sean solicitadas). En otras palabras, si sabemos que la feature C siempre se solicita después de las features A y B, podemos calcular C de antemano para que ya esté disponible cuando sea solicitada.
  • Caché local: los datos usados para construir features críticas pueden almacenarse localmente en la plataforma de la FS para una recuperación rápida (en lugar de ser obtenidos por la red). Por ejemplo, si las features relacionadas con transferencias son muy importantes para usted, todas las transferencias podrían almacenarse en un key-value store local como Redis, de modo que la recuperación sea instantánea cuando/si las features son solicitadas.
  • Búsqueda en paralelo: las features independientes pueden recuperarse en paralelo mediante multithreading.

Vale la pena notar, sin embargo, que no todas las implementaciones de feature store siguen este enfoque ingenuo. De hecho, muchas elecciones de arquitectura pueden, de hecho, reducir el tiempo de obtención de features en lugar de aumentarlo.

Contra: Las feature stores pueden dificultar la observabilidad y la depuración para los equipos clientes

Introducir una feature store para recuperar features en tiempo real normalmente significa que la observabilidad (ver logs y métricas) y la depuración (rastrear la causa raíz de un problema) cambiarán. Eso ocurre porque la lógica de recuperación ahora está abstraída, y los logs pueden no parecerse a lo que los equipos clientes están acostumbrados.

Esto a menudo crea una resistencia inicial a la adopción. Es importante asegurar que los equipos clientes no pierdan la capacidad de observar y depurar la recuperación de features por su cuenta, porque a nadie le gusta perder autonomía al resolver problemas en producción.

En la práctica, esta resistencia puede reducirse significativamente cuando la feature store sigue las mismas convenciones usadas por los otros servicios de la organización. Algunas prácticas importantes incluyen:

Seguir las convenciones de logging existentes

Los logs y métricas emitidos por la plataforma de la feature store deben ser lo más parecidos posible a los usados por otros servicios (no-ML): usando las mismas tecnologías, los mismos patrones, la misma estructura, siguiendo los mismos patrones de tracing distribuido donde sea aplicable.

Asegurar que las necesidades básicas de los usuarios sean atendidas

Los casos de uso “mínimos” deben permanecer simples y fáciles. Todos los equipos clientes deben poder:

  • Inspeccionar las features de entrada crudas para instancias individuales evaluadas por un modelo.
  • Ver métricas de latencia (promedios y percentiles) para features individuales a lo largo del tiempo.
  • Ver mensajes de excepción y stack traces cada vez que ocurran errores durante la recuperación de features.

Incluir todas las dimensiones necesarias en logs y métricas

Los logs y métricas deben incluir el nombre del modelo llamador y cualquier otra dimensión requerida para distinguir distintos flujos de llamada (p. ej., llamadas en modo shadow vs. no-shadow).

Este “contra” solo es un problema durante la adopción inicial de una feature store. A largo plazo, una feature store puede proveer incluso mejores capacidades de observabilidad y depuración que los servicios estándar.

Conclusión

Las feature stores conllevan un costo real de implementación y adopción, especialmente para organizaciones que todavía están comenzando a estructurar sus sistemas de ML en tiempo real. Aun así, a medida que el número de modelos, equipos y casos de uso crece, los beneficios de estandarización, reutilización, gobernanza y eficiencia operacional tienden a superar esa inversión inicial.

Al centralizar la lógica de features en una sola plataforma, las organizaciones pueden reducir problemas como el training-serving skew, simplificar el mantenimiento de pipelines de ML, acelerar la experimentación y crear sistemas de inferencia en tiempo real más escalables. Además, los efectos de segundo orden, como la descubribilidad de features entre equipos, la observabilidad centralizada y la reutilización de componentes, se amplifican a medida que crece la adopción.

En la parte 2 de esta serie, exploraremos las principales lecciones aprendidas al usar feature stores en producción en Nubank. ¡Manténgase atento!

Descubre las oportunidades