Un modelo de fraude es tan actual como sus features. Online Feature Store de Snowflake, ya en GA

Considere dos versiones de la misma comprobación de fraude de tarjeta.

En la primera, el modelo puntúa una transacción con features calculadas la noche anterior: el gasto medio del cliente, sus comercios habituales, sus países habituales. Una tarjeta robada esta mañana y usada seis veces en una hora parece normal, porque las features describen al cliente de ayer.

En la segunda, el mismo modelo lee features actualizadas desde el stream de eventos: transacciones de los últimos diez minutos, un dispositivo nuevo, una categoría de comercio que nunca se había visto. El modelo es idéntico. La decisión no.

Esa diferencia, entre un modelo que es bueno y un modelo que está al día, es lo que Snowflake llevó a disponibilidad general el 20 de octubre.

Qué alcanzó la disponibilidad general (GA)

Online Feature Store sirve los valores de features más recientes con recuperación de baja latencia para machine learning en tiempo real: detección de fraude, recomendaciones, personalización. Admite vistas de features batch, stream y en tiempo real, recibe eventos mediante API REST y se integra con la inferencia de modelos en tiempo real. Los equipos eligen un tamaño para el servicio online y pueden redimensionarlo según cambie el tráfico. Feature Store monitoring en Snowsight también está en GA, y hace seguimiento del estado de refresco offline, la latencia y los errores del serving en línea, y la salud de la ingesta de stream.

Hay dos restricciones: está disponible en regiones comerciales de AWS y Azure, no en Google Cloud, y la facturación tiene tres partes (cómputo del servicio online, cómputo de autoescalado y almacenamiento), así que el costo de servir features es distinto del costo del data warehouse.

Antes y después

Antes de un almacén en línea, la mayoría de las empresas tenía dos rutas para las features: una offline gobernada, en el data warehouse, usada para entrenamiento; y otra operativa, construida por un equipo de aplicaciones en una caché o un almacén clave-valor, usada para serving. Las dos se desviaban. Una feature calculada de una forma en entrenamiento y de otra en producción es una de las razones más comunes por las que un modelo que dio buenos resultados en pruebas rinde peor tras el lanzamiento.

Con el almacén en línea dentro de la misma plataforma que los datos de entrenamiento, la definición de una feature se puede escribir una vez y servir en ambos lugares. Eso no garantiza la consistencia, pero elimina la razón más común de su ausencia: dos equipos escribiendo la misma lógica dos veces.

Lo mismo vale para los agentes de IA y los modelos de decisión que actúan sobre contexto en vivo. Los modelos de decisión tipados de Snowflake son rápidos; sus decisiones son tan buenas como los inputs que reciben en ese momento. Y, como señalamos en la ruta de datos de los agentes, los problemas de latencia en los sistemas de IA suelen estar en la recuperación de datos más que en el modelo.

Qué añadir al adoptarlo

Un objetivo de frescura por feature. “Baja latencia” describe la rapidez con la que se lee un valor, no su antigüedad. Para cada feature usada en una decisión en tiempo real, defina cuánto puede envejecer y alerte sobre ello. La monitorización que ahora está en GA da las señales; los umbrales son una decisión de negocio.

Una regla de fallback. Cuando el stream se detiene, ¿el modelo debe puntuar con features obsoletas, usar un valor por defecto o enviar el caso a revisión? Cada respuesta tiene un riesgo distinto. Decídalo antes del primer incidente.

Una comprobación de que entrenamiento y serving coinciden. Compare periódicamente los valores de features servidos con los que calcula el pipeline offline para las mismas entidades y el mismo momento. Una deriva entre ambos es un defecto, incluso cuando las dos rutas vienen de la misma plataforma.

Un responsable del costo. El serving en línea se ejecuta de forma continua. Su cómputo y autoescalado deberían estar en un presupuesto con un responsable con nombre, como cualquier otro servicio en producción.

Las features frescas no hacen que las predicciones sean correctas. Aseguran que un modelo correcto esté mirando el presente.