Detección de fraude en tiempo real con Feature Views

La detección de fraude en tiempo real depende de tres tipos de características: lo que un cliente hizo hace unos segundos, cómo gasta normalmente y cómo se compara el pago actual. Esas características deben calcularse de la misma manera para el entrenamiento del modelo y para la puntuación en vivo; de lo contrario, la fuga de datos y el sesgo entre entrenamiento y servicio erosionan silenciosamente la calidad del modelo. Feature Views, que forma parte de Databricks Feature Store, resuelve este problema. Defines cada característica una sola vez, y esa definición produce tanto datos de entrenamiento con consistencia temporal (point-in-time) como los pipelines administrados para la inferencia en línea.

Un pago de $900 puede ser rutinario para un cliente e inusual para otro. Cuando llega, un modelo de fraude solo tiene un momento para decidir si parece normal, necesita revisión o debe ser bloqueado. Aprobar una transacción fraudulenta puede costarle dinero al cliente. Bloquear una legítima interrumpe su experiencia de pago y erosiona su confianza en la plataforma.

La transacción por sí sola no cuenta toda la historia. El modelo también necesita saber cómo realiza transacciones normalmente este cliente y qué hizo hace segundos, minutos, días o semanas. Durante el entrenamiento, las características deben utilizar únicamente la información disponible en el momento en que ocurrió cada pago. Durante la puntuación en vivo, deben reflejar las transacciones recientes con la suficiente rapidez como para detectar actividad sospechosa. Si ambas rutas implementan la lógica por separado, se introducen pequeñas diferencias entre ellas.

Este recorrido sigue ese pago de $900 desde un stream de Kafka hasta una puntuación de fraude servida por Model Serving, con código en cada paso. La idea central es que una sola definición de característica, que impulsa tanto el entrenamiento como el servicio, te ofrece datos de entrenamiento correctos en el punto temporal y características en línea consistentes. No construyes un pipeline separado para cada ruta.

¿Qué es una Feature View?

Una Feature View es una definición de Databricks Feature Store que especifica la fuente de una característica, las claves de entidad, la semántica temporal y la transformación. La misma definición calcula valores históricos para el entrenamiento e impulsa los pipelines administrados que mantienen las características frescas para el servicio. Una sola API cubre características por lotes (batch), de streaming y bajo demanda. Unity Catalog gobierna sus definiciones, permisos y linaje.

Dos modos de fallo motivan este diseño:

• El sesgo entre entrenamiento y servicio (Training-serving skew) ocurre cuando una característica se calcula de una manera en el entrenamiento y de otra en producción. En el momento de la inferencia, el modelo ve entradas que no coinciden con aquello con lo que aprendió.
• La fuga de datos (Data leakage) ocurre cuando los datos de entrenamiento incluyen información que no estaba disponible en el momento de la predicción. Las características correctas en el punto temporal lo evitan al utilizar únicamente los eventos que ocurrieron antes del momento que se está prediciendo.

Las Feature Views integran el cálculo de características de streaming en el mismo flujo de trabajo de ciencia de datos que el entrenamiento histórico y la puntuación en vivo. Puedes evaluar características frente a transacciones pasadas y, a continuación, utilizar las mismas definiciones para mantener fresco el contexto del cliente para las decisiones en vivo.

¿Qué características necesita un modelo de fraude en tiempo real?

El objetivo es señalar pagos sospechosos a medida que llegan sin generar falsas alarmas en los legítimos. Por sí solo, el pago de $900 puede parecer inofensivo. Pero si es el décimo pago en cinco minutos, podría ser parte de un flujo sospechoso. Cualquier retraso en reconocer ese flujo le da a alguien con acceso a una cuenta comprometida más tiempo para realizar pagos adicionales.

Una aplicación de detección de fraude construida con Databricks Apps procesa un flujo de transacciones financieras. Cada evento incluye un ID de cliente, importe, tipo de pago, marca de tiempo y los países de origen y destino. La aplicación envía cada transacción a un endpoint de Model Serving. A continuación, muestra la puntuación de riesgo de la transacción junto con el volumen de transacciones en vivo, las transacciones marcadas y los flujos entre países.
 

El modelo combina tres tipos de contexto:

• Actividad reciente: un recuento de transacciones de cinco minutos y un importe total de 10 minutos, calculados con RollingWindow, capturan la frecuencia con la que el cliente paga y cuánto está gastando.
• Línea base de gasto: un promedio de 30 días y una desviación estándar, mantenidos con SawtoothWindow, describen el importe típico de pago del cliente y cuánto varía.
• Detalles de la transacción: el importe del pago actual, el tipo de pago y los países de origen y destino proporcionan contexto para la decisión.

La arquitectura tiene una ruta histórica para el entrenamiento y una ruta en línea para la inferencia. Ambas parten de las mismas definiciones de características en Unity Catalog. La ruta histórica lee la tabla de ingesta del Stream para construir conjuntos de entrenamiento con consistencia temporal. La ruta en línea materializa los agregados en Online Feature Store, donde Model Serving los lee en el momento de la solicitud.

Cómo definir características de streaming desde Kafka

Antes de decidir qué características servir, puedes probar alternativas con transacciones históricas. ¿Un recuento de transacciones de cinco minutos proporciona una señal más fuerte que uno de 15 minutos? ¿Comparar el importe actual con la variabilidad de gasto del cliente ayuda más que usar solo su promedio?

En este ejemplo, los eventos de transacciones de clientes llegan como streams de Kafka. Un Stream registrado mantiene la conexión, el esquema y la configuración de ingesta, y un StreamSource lo referencia para calcular características en tiempo real. Los temas de Kafka no retienen suficiente historial para el entrenamiento de modelos. Por lo tanto, Databricks administra una copia sin conexión del stream en una tabla de ingesta. Para el entrenamiento o para rellenar un almacén en línea (backfilling), Databricks calcula los valores históricos a partir de la tabla de ingesta y utiliza el feed de Kafka en vivo para los datos más recientes.

En la ingesta, transformation_sql remodela los campos anidados del payload de valor de Kafka en el esquema que las características necesitan. La proyección pasa a formar parte de la definición de la fuente, por lo que no es necesario implementar un pipeline de preprocesamiento independiente. Para nuestro pago, el payload de valor de Kafka contiene:

La demo utiliza demo_user_id junto con customer_id para mantener separados los historiales de clientes de los diferentes usuarios de la aplicación.

Definimos el recuento de cinco minutos con RollingWindow. El notebook complementario incluye importaciones, configuración y la proyección completa de la fuente.

Puedes inspeccionar sus valores históricos en un notebook con compute_features(features=[recent_transaction_count]). El total de 10 minutos utiliza la misma fuente y claves, con Sum sobre un RollingWindow de 10 minutos.

Una ventana en diente de sierra (Sawtooth window) es una agregación de retrospectiva larga cuyo límite más antiguo avanza en pasos diarios. Combina el histórico calculado por lotes con actualizaciones de streaming para la actividad reciente. Para nuestro pago de $900, SawtoothWindow añade una línea base de gasto de 30 días a las ventanas deslizantes cortas. Ambos tipos de ventana mantienen fresca la actividad reciente. Debido a que el límite más antiguo de la ventana Sawtooth se mueve diariamente en lugar de de forma continua, su retrospectiva efectiva es ligeramente superior a 30 días. La línea base utiliza las agregaciones integradas Avg, StddevPop y Count sobre los importes de pago durante la misma ventana Sawtooth.

Databricks inicia un pipeline de ingesta administrado cuando se crea un Stream y mantiene los eventos entrantes en su tabla de ingesta. Si también necesitas eventos de antes de que existiera el Stream, StreamBackfillSource te permite proporcionar tu propio historial durante la configuración del Stream. Una vez que la tabla cubre toda la retrospectiva, una nueva característica Sawtooth puede utilizarla de inmediato en lugar de esperar 30 días a que se acumulen los eventos.

Cómo comparar un pago en tiempo real con la línea base de un cliente

Una característica bajo demanda se calcula en el momento de la solicitud combinando los valores de la solicitud de puntuación con las características almacenadas. Comparar una transacción en tiempo real con la línea base histórica de un cliente es una forma común de detectar comportamientos anormales. En Feature Views, la información en el momento de la inferencia se representa con RequestSource; aquí, transaction_amount proviene de la solicitud de la aplicación.

Dos clientes pueden tener un promedio de $300 por pago, pero gastar de manera muy diferente. Con desviaciones estándar de $100 y $600, el mismo pago de $900 se sitúa a seis desviaciones estándar por encima del promedio de un cliente y a solo una del promedio del otro. El modelo combina esta comparación con la actividad reciente y los detalles del pago para estimar el riesgo de fraude.

Las agregaciones Sawtooth mantienen el promedio y la desviación estándar de 30 días. La característica bajo demanda las combina con el monto actual para calcular (current_amount - average) / standard_deviation. Implementamos este cálculo como una función UDF de Python registrada en Unity Catalog:

La definición de la característica utiliza objetos Feature ascendentes registrados. FeatureViewSource reúne el monto actual y las tres estadísticas de 30 días, y CustomUDF invoca la función:

Cuando no hay suficiente historial utilizable, la función devuelve cero como valor de reserva. Un indicador separado permite al modelo distinguir ese valor de reserva de un cero real, lo que significa que el pago coincide con el promedio del cliente. La misma característica derivada se evalúa frente a entradas históricas durante el entrenamiento y frente a la solicitud actual más las estadísticas recuperadas durante la inferencia.

Cómo probar candidatos de características antes de implementarlos

Durante el desarrollo de características, puedes inspeccionar las definiciones de características en un notebook con compute_features(). Esto funciona para características derivadas cuyos entradas provienen enteramente de datos de origen históricos. Para comparaciones dependientes de solicitudes como amount_deviation, utiliza create_training_set() en su lugar, el cual proporciona los campos de pago actuales a partir de ejemplos etiquetados. La función de Unity Catalog debe existir, pero las definiciones de características pueden permanecer sin registrar mientras pruebas los candidatos.

Esto te permite comprobar si una característica mejora el rendimiento fuera de línea del modelo de fraude antes de implementarlo para la puntuación en tiempo real. Por ejemplo, puedes comparar modelos con y sin amount_deviation en pagos posteriores retenidos. Estos experimentos se ejecutan en computación por lotes sobre el historial de transacciones, por lo que puedes evaluar cada candidato sin necesidad de configurar una materialización en línea. Una vez que hayas seleccionado las características, registra sus definiciones y materializa las agregaciones móviles y Sawtooth para la fase de servicio.

Cómo crear datos de entrenamiento correctos en función del momento temporal

Cada ejemplo de entrenamiento histórico necesita características calculadas a partir de la marca de tiempo de ese pago. Para nuestro pago de $900 a las 10:00 a. m., el recuento de cinco minutos debe incluir transacciones desde las 9:55 a. m. hasta las 10:00 a. m., sin incluir esta última. Un recuento obtenido a las 10:03 a. m. podría incluir un pago realizado a las 10:02 a. m., el cual no estaba disponible cuando se puntuó el pago original. Eso es fuga de datos: el modelo aprende de la actividad futura y su rendimiento fuera de línea parece mejor de lo que realmente es. Feature Views utiliza las claves de cliente y la marca de tiempo de cada ejemplo para calcular la ventana histórica correcta a partir de los eventos en la tabla de ingesta de Stream.

Después de registrar las características seleccionadas, create_training_set() crea los datos de entrenamiento del modelo. El DataFrame etiquetado proporciona las claves de cliente, la hora del evento, los campos de pago actuales y is_fraud. Este fragmento selecciona las características registradas del recorrido, incluida la línea base de 30 días, y utiliza filas anteriores a un punto de corte elegido para el entrenamiento:

Las claves y las marcas de tiempo seleccionan el historial del cliente, pero se excluyen como entradas del modelo. Los campos de solicitud alimentan los cálculos de características; el clasificador utiliza las características nombradas resultantes. Las filas posteriores forman un conjunto de validación utilizando las mismas definiciones.

Entrenamos un clasificador de bosque aleatorio (random forest) y evaluamos la precisión promedio y el ROC AUC en este último. Luego, registramos el modelo a través del cliente de Feature Engineering. Pasar training_set=train_set registra las dependencias de características que el servicio necesitará:

Cómo servir características en tiempo real para la inferencia en línea

Mover las características seleccionadas anteriormente a la puntuación en tiempo real requiere que las canalizaciones mantengan agregados de streaming, procesen datos históricos y mantengan actualizado el almacén en línea. Construir y operar estas canalizaciones añade meses de trabajo de ingeniería de datos más allá del desarrollo del modelo de fraude. Con Feature Views, las definiciones de características registradas impulsan este proceso: una llamada a materialize_features() crea canalizaciones gestionadas que hacen que las agregaciones estén disponibles en Databricks Online Feature Store, impulsado por Lakebase.

La ruta de streaming utiliza Spark Real-Time Mode (RTM) para procesar eventos entrantes de forma continua y actualizar agregados móviles a medida que llegan.

Materializamos las agregaciones móviles y Sawtooth. Para la línea base Sawtooth de 30 días, Databricks mantiene la porción histórica con computación por lotes y la actividad reciente con streaming. Ambas se combinan al leerlas en una sola característica, y StreamingMode() gestiona esta ruta híbrida sin necesidad de una llamada por lotes separada. Verifica ambas rutas de materialización en Catalog Explorer antes de realizar el servicio. La guía de Sawtooth recomienda esperar dos días completos antes del uso en producción.

RequestSource proporciona valores de cada solicitud de puntuación y las características derivadas se calculan bajo demanda. Una vez que se implementa el modelo, la aplicación envía las claves de los clientes y los campos de pago actuales a su endpoint. Model Serving recupera las características más recientes del cliente y evalúa la desviación bajo demanda, y luego pasa las entradas al modelo de fraude. Este es nuestro pago de $900 en el formato de solicitud de la aplicación, utilizando la llamada al SDK del puntuador:

La aplicación envía event_time en esta solicitud, pero la búsqueda en línea utiliza las características del cliente más recientes disponibles, no una instantánea histórica seleccionada por esa marca de tiempo. En esta demostración, la aplicación puntúa cada pago antes de publicarlo en Kafka. Eso mantiene el pago actual fuera de su propio historial, lo que coincide con la exclusión de ese pago en la ventana de entrenamiento. Las actualizaciones de características y la puntuación se ejecutan de forma asíncrona, por lo que es posible que haya otros eventos en curso cuando se puntúe el siguiente pago.

El endpoint devuelve una probabilidad en fraud_probability y un indicador en fraud_prediction. La aplicación almacena las transacciones puntuadas en Lakebase para el panel.

Cómo regir las características de ML en Unity Catalog

Los modelos de fraude en producción plantean cuestiones de gobernanza: qué modelos utilizan una característica, de dónde proviene y quién puede leerla. Unity Catalog reúne las definiciones de características, los permisos y el linaje para responder a ellas. MLflow registra qué características utiliza cada modelo, y Model Serving utiliza esas dependencias cuando gestiona una solicitud de inferencia.

Los privilegios de características controlan el ciclo de vida:

• CREATE FEATURE controla el registro.
• READ FEATURE otorga acceso a los metadatos de las características.
• MANAGE autoriza operaciones como la materialización.

Los privilegios de características no reemplazan los permisos de SELECT necesarios en las tablas de origen o materializadas para el entrenamiento y la inferencia.

En Catalog Explorer, las vistas de características aparecen en Functions, junto con sus definiciones, enlaces de origen, tablas materializadas y estado. Las materializaciones de streaming se vinculan a sus canalizaciones de Lakeflow administradas por el sistema para su inspección. Etiquetas de materialización permiten a los equipos atribuir los costos de computación de las canalizaciones o trabajos a un equipo o proyecto específico.

Puntos clave para la detección de fraude en tiempo real

Nuestro pago de $900 ahora tiene contexto: actividad reciente, una línea base a más largo plazo y la solicitud actual. Tres prácticas hicieron posible lo anterior:

• Definir una vez, usar dos veces. Las definiciones de características compartidas para el entrenamiento y la inferencia reducen el sesgo entre entrenamiento e inferencia que proviene de implementaciones separadas.
• Calcular el punto en el tiempo. Las ventanas de entrenamiento que excluyen eventos futuros evitan la fuga de datos y mantienen honestas las métricas sin conexión.
• Dejar que la plataforma ejecute las canalizaciones. La materialización y la búsqueda en línea están gestionadas, por lo que el trabajo se centra en elegir mejores señales de fraude.

Los mismos patrones van más allá de este recorrido. LastN mantiene secuencias como los países de destino de los 10 pagos más recientes de un cliente, lo que ayuda a los modelos a detectar cambios en las rutas de pago. Las características por lotes también pueden utilizar agregaciones de todo el ciclo de vida para resumir el historial completo de una entidad.

Para ver más de cerca la infraestructura detrás de la frescura de streaming subsegunda, lea Cómo Databricks Feature Store sirve características con frescura subsegunda. Para obtener detalles de implementación, consulte la documentación de la API de vistas de características, materialización y exploración de vistas de características en Unity Catalog.

Preguntas frecuentes

¿Qué son las vistas de características de Databricks?

Las vistas de características son una capacidad de Databricks Feature Store para definir características de ML una vez y utilizarlas tanto para el entrenamiento como para la producción. Cada definición especifica un origen, claves de entidad, semántica de tiempo y una transformación. La misma API cubre características por lotes, de streaming y bajo demanda, y Unity Catalog las rige.

¿Cómo evitan las vistas de características la fuga de datos al entrenar un modelo de fraude?

Las vistas de características calculan las características de cada ejemplo de entrenamiento a partir de la marca de tiempo de ese ejemplo. Para un pago a las 10:00 a. m., un recuento de transacciones de cinco minutos incluye los pagos desde las 9:55 a. m. hasta las 10:00 a. m. (sin incluir esta última). Esto evita que la actividad futura forme parte de los datos de entrenamiento, por lo que el rendimiento sin conexión no se infla.

¿Qué es el sesgo entre entrenamiento e inferencia y cómo lo reducen las vistas de características?

El sesgo entre entrenamiento e inferencia se produce cuando las características se calculan de una manera para el entrenamiento y de otra para la inferencia en vivo. Las vistas de características lo reducen al utilizar una única definición registrada tanto para el cálculo histórico como para la materialización en línea. Los equipos no tienen que volver a implementar la lógica de características para la producción.

¿Pueden las vistas de características calcular características a partir de flujos de Kafka?

Sí. Un Stream registrado contiene la conexión de Kafka, el esquema y la configuración de ingesta, y un StreamSource hace referencia a él en las definiciones de características. Databricks mantiene una copia sin conexión del flujo en una tabla de ingesta para el entrenamiento y las recargas de datos históricos. El modo en tiempo real actualiza los agregados de streaming a medida que llegan nuevos eventos.

¿Cómo se sirven las características en tiempo real a un modelo de fraude en producción?

Llamar a materialize_features() crea canalizaciones gestionadas que mantienen los agregados actualizados en la tienda de características en línea, impulsada por Lakebase. Cuando el modelo se registra con log_model() y se implementa en Model Serving, el endpoint recupera las características más recientes del cliente y calcula las características bajo demanda a partir de la solicitud. A continuación, devuelve una probabilidad de fraude.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original