MLOps: qué es el FeatureStore y cuándo usarlo.

En posts anteriores hemos hablado del concepto de MLOps y cómo nos sirve para facilitar y automatizar el proceso de llevar a producción proyectos y modelos de Machine Learning. Como veíamos, el MLOps es un conjunto de buenas prácticas y tecnologías, que se utilizan en conjunto para asegurar la trazabilidad y gobernanza de todos los procesos que componen una aplicación de Machine Learning.

Una de estas componentes que ha cogido mucha popularidad en los últimos años es lo que se denomina FeatureStore. El propósito del FeatureStore es servir como sistema de almacenamiento de características para entrenar y predecir modelos de Machine Learning. Sin embargo, en la práctica es común no saber cómo utilizarlo ni qué diferencias existen entre el uso del FeatureStore y un sistema de almacenamiento más convencional como un DataLake.

¿Qué es el FeatureStore?

El FeatureStore es un sistema de almacenamiento de datos usado para el entrenamiento y predicción de modelos de Machine Learning. La diferencia que existe entre un FeatureStore y el almacenamiento por medio de una tabla en un DataLake o DataWarehouse es que en el FeatureStore se almacena cada feature de manera independiente siguiendo un formato de clave-valor, donde cada valor lleva asociado un identificador.

De esta manera, con un FeatureStore almacenaremos cada columna de una tabla de manera independiente y para reconstruir la tabla original tendríamos que unir todas las columnas usando el ID.

El concepto de FeatureStore fue acuñado e implementado por primera vez en 2017 por Uber. El propósito con el que lo crearon fue, por un lado, para poder crear y documentar cada feature de manera independiente y, por otro lado, para facilitar un consumo de las features en tiempo real. Esto último fue una de las claves por las que Uber era capaz de estimar en tiempo real el precio óptimo de un viaje según la demanda por medio de técnicas de Machine Learning.

El concepto de FeatureStore se ha popularizado en estos últimos años y se intenta implementar en muchas arquitecturas de Machine Learning. Sin embargo, según los requerimientos de la plataforma, muchas veces puede no ser beneficioso o incluso puede ser contraproducente. En este post explicaremos en qué casos es útil el concepto de FeatureStore.

¿Cuándo debería usar un FeatureStore?

Un error común cuando la gente habla de FeatureStore es que su motivación sea la de asegurar la trazabilidad en el proceso de entrenamiento de los modelos y puede parece que tenga poca utilidad.

Nada más lejos de la realidad, la mayor utilidad del FeatureStore está principalmente en los procesos de inferencia bajo demanda, en los cuales el FeatureStore permite crear funcionalidades a la hora de hacer inferencia que serían imposibles con otro tipo de sistema de almacenamiento.

Caso 1 - Predicciones por ID

Generalmente, cuando se habla de predicciones bajo demanda por medio de una API de predicción, estamos hablando del caso en el que se envía dentro de la petición que se hace a la API el registro sobre el que se quiere hacer predicción, con todos los campos y valores que requiere el modelo de Machine Learning para hacer la predicción.

Sin embargo, hay veces que la información sobre la que queremos hacer predicción no está en el cliente que hace la petición, sino que la información se encuentra dentro del servidor o de la base de datos. Por ejemplo, en el caso de Uber, cuando se hace la estimación de tiempo sobre la ruta que va a tomar un conductor, la información que se envía desde la aplicación del conductor es solamente el ID. Con el ID, el FeatureStore obtienen los datos de predicción y toda la información relativa al conductor para hacer la predicción se encuentra del lado del servidor.

En estos casos, el FeatureStore funciona como proxy inverso que permite, con el ID del conductor, acceder a toda la información del conductor que esté almacenada en el servidor.

Caso 2 - Consumo en RealTime

A veces, según su naturaleza, hay features que tienen un tiempo de “actualización” más breve que otras (por ejemplo, hay variables que pueden permanecer sin actualizarse durante meses como el campo “edad” de una persona, mientras que hay otras que se actualizan continuamente como por ejemplo los campos de datos “climatológicos”).

Gracias al hecho de que cada una de las variables se almacena de manera independiente en el FeatureStore, hace que podamos actualizar cada una de las variables de manera independiente. Para ello se puede configurar una frecuencia de actualización periódica para cada feature.

En algunos casos, es necesario que algunas variables se actualicen en tiempo real. Esto se puede hacer mediante un proceso que continuamente comprueba si ha habido una actualización en el origen y actualiza el valor del FeatureStore (este tipo de configuración se denomina “Online FeatureStore”). Este servicio es más caro en términos de costes, pero permite que cuando se consume del FeatureStore, siempre se consuma la última versión de los datos sin necesidad de tener que acceder al origen.

Caso 3 - Sharing de Feature

Otra ventaja relacionada con el hecho de almacenar cada feature del FeatureStore, es que no solo podemos reconstruir el dataset original, sino que también podemos crear otros datasets combinando diferentes features sin tener que replicar el uso de la misma variable.

Por medio del FeatureStore no solo podemos evitar este tipo de redundancia de información, sino que, además, nos asegura que haya un único proceso que sea el encargado de generar cada una de las features (lo cual nos asegura la trazabilidad del dato). En caso contrario, es bastante frecuente que haya problemas de concordancia entre variables debido a que existan procesos independientes que generan la misma feature en datasets distintos y que estas features no sean equivalentes.

¿Cuándo NO debería usar un FeatureStore?

Generalmente, en cualquier circunstancia que no se corresponda con las anteriores la recomendación es no usar un FeatureStore, sino usar un sistema de almacenamiento de datos tradicional para el entrenamiento de los modelos de ML.

Algunas de las circunstancias comunes en las que se podría evitar el FeatureStore son las siguientes:

1 Cuando no existe un ID

En modelos de Machine Learning basados en datos tabulares, suele ser relativamente fácil separar cada columna de la tabla en una feature y asociar un ID común a cada registro.

Sin embargo, en otros tipos de problemas de ML no solo puede no ser tan fácil hacer esa asignación, sino que no es posible o no tiene sentido identificar cada registro con un ID. Un ejemplo de ello son por ejemplo:

• Modelos de segmentación semántica en ComputerVision.
• Modelos de lenguaje que generen texto a partir de un prompt sin configuración.
• Modelos en los que la predicción no se hace sobre un dato, sino sobre una ventana temporal.

2 Cuando no tenemos ni RealTime ni datasets compartidos

Los principales factores diferenciales del FeatureStore con respecto a otro sistema de almacenamiento de datos es que aseguran la trazabilidad cuando las features se reutilizan entre diferentes modelos y/o se quieren consumir en real time bajo demanda.

No obstante, la casuística anterior no suele ser especialmente común. Muchas organizaciones y empresas tienen arquitecturas de Machine Learning en las que su única necesidad es realizar procesos batch y el modelo tiene sus propias features y no se quieren compartir con otros modelos. En estos casos, utilizar un FeatureStore no solo no sería útil, sino que además provocaría un aumento de costes innecesario.

¿Qué cloud vendors ofrecen este servicio?

Aunque existe algún producto de FeatureStore opensource, la mayoría de grandes empresas que requieren de este servicio (Uber, Twitter…) han desarrollado sus propios productos de uso interno. Lo más común en los proyectos es usar los servicios de FeatureStore ofrecidos por los framework de Machine Learning de cada cloud vendor.

• AWS Sagemaker. Ofrece la ingesta y consumo de features tanto de manera online como offline. Una de sus características principales es que ofrece “time travel” el cual permite recuperar valores pasados de las features en el caso de que se hayan actualizado tras los procesos de ingesta.
• GCP VertexAI. Muy similar al FeatureStore de Sagemaker, pero además tiene un UI más desarrollado que permite la visualización y generación de métricas y estadísticas de las features.
• Azure AzureML. Actualmente, Azure no ofrece este servicio desde su framework de ML; sin embargo, sí lo ofrece desde el producto de Databricks.

Conclusiones

En este post hemos visto que el FeatureStore es una herramienta muy útil en los proyectos de MLOps que nos permite almacenar cada variable de manera independiente junto con un ID para su consumo. Esto permite no solo una trazabilidad y documentación del dato a nivel de feature en vez de dataset, sino que además el FeatureStore nos sirve como proxy inverso, a la hora de consumir las features, así como facilitar su consumo en realtime.

Sin embargo, creemos que a pesar de todas las bondades que tiene el FeatureStore, en muchos otros casos no suele ser necesario y su uso no solo supondrá un sobrecoste del precio de la infraestructura, sino que además también supondrá una sobreingeniería que hará mucho más tedioso el consumo de datos así como la documentación de datasets.