Un modelo de fraude necesita la feature "número de transacciones de esta tarjeta en los últimos 5 minutos", pero las features se calculan en un trabajo por lotes diario. ¿Por qué no basta?
Opciones
- El trabajo por lotes es demasiado rápido
- La feature tendría hasta un día de antigüedad y no vería la ráfaga de actividad que el modelo debe detectar; necesita valores frescos calculados desde un flujo (stream), con la misma lógica que en el entrenamiento (Opción correcta)
- El modelo no puede usar recuentos
- Los trabajos por lotes no se pueden programar
Respuesta
La feature tendría hasta un día de antigüedad y no vería la ráfaga de actividad que el modelo debe detectar; necesita valores frescos calculados desde un flujo (stream), con la misma lógica que en el entrenamiento
Por qué
La frescura de la feature debe coincidir con la decisión. Una feature de hace horas no puede describir lo que pasó hace cinco minutos, y la señal se pierde.
Calcula este tipo de features con ventana desde un flujo (o bajo demanda a partir de eventos recientes) y sírvelas desde un almacén online. La misma definición debe producir también los valores de entrenamiento, con corrección point-in-time, o tendrás training-serving skew.
Las features que cambian despacio (edad del cliente, tipo de cuenta) pueden seguir en batch.
Recuerda
La frescura de la feature debe ajustarse a la escala de tiempo de la decisión.