¿Qué problema resuelve un feature store que no puedas resolver con un buen pipeline de datos?

Resuelve la consistencia entre entrenamiento y servicio. La misma característica debe calcularse desde el histórico batch para entrenar y desde datos frescos con baja latencia para servir, y cuando son dos implementaciones separadas divergen. Un feature store define la característica una vez, la materializa a un almacén offline para datos de entrenamiento correctos en el tiempo y a un almacén online para consultas de milisegundos, y aporta joins correctos en el punto temporal.

El problema es que la misma característica tiene dos vidas. Para entrenar necesito su valor a fecha de una marca temporal histórica, unida sin incluir por accidente nada que pasara después. Para servir la necesito ahora mismo, en menos de diez milisegundos, indexada por entidad. Si son dos bases de código, y siempre empiezan siendo dos bases de código, divergen. Alguien cambia una ventana de treinta días a veintiocho en el trabajo de entrenamiento, nadie toca la ruta de servicio, y ahora el modelo puntúa contra características con las que nunca se entrenó. Esa divergencia no hace ruido, y por eso sale cara. Un feature store te da una definición que se materializa en una tabla offline para entrenar y en un almacén clave valor online para servir, más joins correctos en el punto temporal para que la consulta histórica no pueda filtrar el futuro. Dicho eso, no montaría uno para un equipo con dos modelos. La sobrecarga es real, y consigues casi todo el beneficio con una librería de transformaciones compartida más un trabajo programado que escriba a una caché. Tiraría de un feature store gestionado cuando varios equipos comparten características, porque es cuando las definiciones duplicadas empiezan a multiplicarse.