Almacenes de características: Feast y Tecton

Los equipos vuelven a implementar las mismas features una y otra vez, y las canalizaciones de entrenamiento las calculan de forma diferente al código de serving. Un feature store centraliza las definiciones, la reutilización y el serving de features, eliminando el trabajo duplicado y el training-serving skew.

Dos feature stores destacados:

• Feast: de código abierto y ligero; usted aporta su propia infraestructura
• Tecton: comercial y gestionado; añade canalizaciones de features en streaming y gobernanza

Ambos comparten los conceptos fundamentales de entidades, features y offline/online stores.

Una entidad es aquello que describen las features, como un usuario o un producto. Una vista de features agrupa las features relacionadas con una entidad y apunta a una fuente de datos. Estas definiciones viven en el código y se versionan como cualquier otro artefacto.

feast apply registra las definiciones de entidades y vistas de features en el registro del feature store. Es la forma en que el store descubre qué features existen y de dónde proceden sus datos.

Las features deben cargarse en el online store antes del serving. La materialización calcula los valores de las features hasta un momento determinado y los escribe en el online store (por ejemplo, Redis) para que estén listos para consultas de baja latencia.

feast materialize recibe una fecha de inicio y una fecha de finalización, y carga en el online store los valores de las features correspondientes a ese intervalo. Ejecútelo según una programación para mantener actualizadas las features online.

Durante la inferencia, obtiene las features más recientes para las entidades indicadas mediante get_online_features, pasando entity_rows que identifican las entidades que se deben consultar. Devuelve los valores más recientes en milisegundos.

Para entrenar, une los valores de las features con las etiquetas históricas. El feature store lee del offline store y devuelve un conjunto de datos alineado con la marca de tiempo de cada etiqueta, lo que garantiza que las entradas de entrenamiento coincidan con las que proporcionará el serving.

La garantía clave del feature store es la unión point-in-time: para cada etiqueta de entrenamiento, obtiene únicamente los valores de las features que se conocían en ese momento o antes de la marca de tiempo de la etiqueta. Esto evita utilizar información futura.

Sin corrección point-in-time, corre el riesgo de sufrir una fuga de datos: entrenar con valores de features calculados después del evento de la etiqueta, lo que infla las métricas offline, pero provoca un colapso en producción. El feature store impone automáticamente la coherencia temporal.

El ciclo de vida del feature store conecta todos los elementos:

• feast apply registra las definiciones
• feast materialize carga el online store
• el entrenamiento utiliza uniones point-in-time desde el offline store
• el serving lee valores recientes mediante get_online_features

Ponga a prueba sus conocimientos sobre feature stores.

Ha aprendido a utilizar feature stores con Feast y Tecton:

• feast apply registra entidades y vistas de features
• feast materialize carga el online store para las fechas indicadas
• get_online_features proporciona valores recientes para entity_rows
• Las uniones point-in-time crean datos de entrenamiento sin fugas