Detecção de fraudes em tempo real com Feature Views

A detecção de fraudes em tempo real depende de três tipos de features: o que um cliente fez segundos atrás, como ele costuma gastar e como o pagamento atual se compara. Essas features precisam ser computadas da mesma maneira para o treinamento do modelo e para o scoring em tempo real — caso contrário, o vazamento de dados e o desvio entre treinamento e serving corroem silenciosamente a qualidade do modelo. Os Feature Views, que fazem parte do Databricks Feature Store, resolvem isso. Você define cada feature uma vez, e essa definição produz tanto dados de treinamento pontuais quanto os pipelines gerenciados para inferência online.

Um pagamento de $900 pode ser rotineiro para um cliente e incomum para outro. Quando ele chega, um modelo de fraude tem apenas um momento para decidir se parece normal, precisa de revisão ou deve ser bloqueado. Aprovar uma transação fraudulenta pode custar dinheiro ao cliente. Bloquear uma transação legítima interrompe a experiência de pagamento dele e corrói sua confiança na plataforma.

A transação por si só não conta toda a história. O modelo também precisa saber como esse cliente transaciona normalmente e o que ele fez segundos, minutos, dias ou semanas atrás. Durante o treinamento, as features devem usar apenas as informações disponíveis no momento em que cada pagamento ocorreu. Durante o scoring em tempo real, elas devem refletir transações recentes rapidamente o suficiente para detectar atividades suspeitas. Se os dois caminhos implementarem a lógica separadamente, pequenas diferenças entre eles acabam surgindo.

Este passo a passo acompanha esse pagamento de $900 desde um stream do Kafka até um score de fraude servido pelo Model Serving, com código em cada etapa. A ideia central é que uma única definição de feature, direcionando tanto o treinamento quanto o serving, fornece dados de treinamento corretos no tempo e features online consistentes. Você não constrói um pipeline separado para cada caminho.

O que é um Feature View?

Um Feature View é uma definição do Databricks Feature Store que especifica a origem de uma feature, chaves de entidade, semântica temporal e transformação. A mesma definição computa valores históricos para treinamento e aciona os pipelines gerenciados que mantêm as features atualizadas para o serving. Uma única API abrange features em lote, de streaming e sob demanda. O Unity Catalog governa suas definições, permissões e linhagem.

Dois modos de falha motivam este design:

• Desvio entre treinamento e serving ocorre quando uma feature é computada de uma maneira no treinamento e de outra na produção. No momento da inferência, o modelo vê entradas que não correspondem ao que ele aprendeu.
• Vazamento de dados ocorre quando os dados de treinamento incluem informações que não estavam disponíveis no momento da previsão. As features corretas no tempo evitam isso usando apenas os eventos que aconteceram antes do momento previsto.

Os Feature Views trazem a computação de features em streaming para o mesmo fluxo de trabalho de ciência de dados que o treinamento histórico e o scoring em tempo real. Você pode avaliar features em relação a transações passadas e, em seguida, usar as mesmas definições para manter o contexto do cliente atualizado para decisões em tempo real.

De que features um modelo de fraude em tempo real precisa?

O objetivo é sinalizar pagamentos suspeitos à medida que chegam, sem gerar falsos alarmes em pagamentos legítimos. Sozinho, o pagamento de $900 pode parecer inofensivo. Mas se for o décimo pagamento em cinco minutos, pode fazer parte de uma rajada suspeita. Qualquer atraso no reconhecimento dessa rajada dá a alguém com acesso a uma conta comprometida mais tempo para fazer pagamentos adicionais.

Um aplicativo de Detecção de Fraudes construído com Databricks Apps processa um fluxo de transações financeiras. Cada evento inclui um ID de cliente, valor, tipo de pagamento, timestamp e os países de origem e destino. O aplicativo envia cada transação para um endpoint do Model Serving. Em seguida, ele exibe o score de risco da transação juntamente com o volume de transações em tempo real, transações sinalizadas e fluxos entre países.
 

O modelo combina três tipos de contexto:

• Atividade recente: uma contagem de transações de cinco minutos e um valor total de 10 minutos, computados com RollingWindow, capturam com que frequência o cliente está pagando e quanto ele está gastando.
• Linha de base de gastos: uma média de 30 dias e desvio padrão, mantidos com SawtoothWindow, descrevem o valor típico de pagamento do cliente e o quanto ele varia.
• Detalhes da transação: o valor do pagamento atual, o tipo de pagamento e os países de origem e destino fornecem contexto para a decisão.

A arquitetura tem um caminho histórico para treinamento e um caminho online para inferência. Ambos começam a partir das mesmas definições de feature no Unity Catalog. O caminho histórico lê a tabela de ingestão do Stream para construir conjuntos de dados de treinamento pontuais. O caminho online materializa agregados para o Online Feature Store, onde o Model Serving os lê no momento da requisição.

Como definir features de streaming do Kafka

Antes de decidir quais features servir, você pode testar alternativas em relação a transações históricas. Uma contagem de transações de cinco minutos fornece um sinal mais forte do que uma contagem de 15 minutos? Comparar o valor atual com a variabilidade de gastos do cliente ajuda mais do que usar apenas a média dele?

Neste exemplo, os eventos de transação do cliente chegam como streams do Kafka. Um Stream registrado mantém a conexão, o esquema e as configurações de ingestão, e um StreamSource faz referência a ele para computar features em tempo real. Os tópicos do Kafka não retêm histórico suficiente para o treinamento do modelo. Portanto, o Databricks gerencia uma cópia offline do stream em uma tabela de ingestão. Para treinamento ou preenchimento de uma store online, o Databricks calcula valores históricos a partir da tabela de ingestão e usa o feed do Kafka ao vivo para os dados mais recentes.

Na ingestão, transformation_sql remodela os campos aninhados do payload de valor do Kafka para o esquema que as features precisam. A projeção se torna parte da definição de origem, para que você não precise implantar um pipeline de pré-processamento separado. Para o nosso pagamento, o payload de valor do Kafka contém:

A demonstração usa demo_user_id junto com customer_id para manter separados os históricos de clientes de diferentes usuários do aplicativo.

Definimos a contagem de cinco minutos com RollingWindow. O notebook complementar inclui importações, configuração e a projeção de origem completa.

Você pode inspecionar seus valores históricos em um notebook com compute_features(features=[recent_transaction_count]). O total de 10 minutos usa a mesma origem e chaves, com Sum sobre um RollingWindow de 10 minutos.

Uma janela Sawtooth é uma agregação de lookback longo cuja fronteira mais antiga avança em etapas diárias. Ela combina histórico computado em lote com atualizações em streaming para atividades recentes. Para o nosso pagamento de $900, SawtoothWindow adiciona uma linha de base de gastos de 30 dias às janelas deslizantes curtas. Ambos os tipos de janela mantêm a atividade recente atualizada. Como a fronteira mais antiga da janela Sawtooth se move diariamente em vez de continuamente, seu lookback efetivo é ligeramente maior que 30 dias. A linha de base usa as agregações integradas Avg, StddevPop e Count em valores de pagamento ao longo da mesma janela Sawtooth.

O Databricks inicia um pipeline de ingestão gerenciado quando um Stream é criado e mantém os eventos recebidos em sua tabela de ingestão. Se você também precisar de eventos de antes de o Stream existir, StreamBackfillSource permite fornecer seu próprio histórico durante a configuração do Stream. Assim que a tabela cobre todo o lookback, uma nova feature Sawtooth pode usá-la imediatamente, em vez de esperar 30 dias para que os eventos se acumulem.

Como comparar um pagamento em tempo real com a linha de base de um cliente

Uma feature on-demand é calculada no momento da requisição combinando valores da requisição de scoring com features armazenadas. Comparar uma transação em tempo real com a linha de base histórica de um cliente é uma forma comum de identificar comportamento anormal. Em Feature Views, as informações em tempo de inferência são representadas com RequestSource — aqui, transaction_amount da requisição do aplicativo.

Dois clientes podem ter uma média de $300 por pagamento, mas gastar de formas muito diferentes. Com desvios padrão de $100 e $600, o mesmo pagamento de $900 fica a seis desvios padrão acima da média de um cliente e a apenas um acima da do outro. O modelo combina essa comparação com a atividade recente e os detalhes do pagamento para estimar o risco de fraude.

As agregações Sawtooth mantêm a média e o desvio padrão de 30 dias. A feature on-demand os combina com o valor atual para calcular (current_amount - average) / standard_deviation. Implementamos esse cálculo como uma Python UDF registrada no Unity Catalog:

A definição da feature usa objetos Feature upstream registrados. FeatureViewSource reúne o valor atual e as três estatísticas de 30 dias, e CustomUDF chama a função:

Quando não há histórico útil suficiente, a função retorna zero como fallback. Um indicador separado permite que o modelo diferencie esse fallback de um zero verdadeiro, o que significa que o pagamento corresponde à média do cliente. A mesma feature derivada é avaliada em relação a entradas históricas durante o treinamento e em relação à requisição atual mais as estatísticas recuperadas durante a inferência.

Como testar candidatos a features antes de implantá-los

Durante o desenvolvimento de features, você pode inspecionar definições de features em um notebook com compute_features(). Isso funciona para features derivadas cujas entradas vêm inteiramente de dados de origem históricos. Para comparações dependentes de requisições, como amount_deviation, use create_training_set() em vez disso, que fornece os campos de pagamento atuais a partir de exemplos rotulados. A função do Unity Catalog deve existir, mas as definições de features podem permanecer não registradas enquanto você testa os candidatos.

Isso permite verificar se uma feature melhora o desempenho offline do modelo de fraude antes de implantá-lo para scoring em tempo real. Por exemplo, você pode comparar modelos com e sem amount_deviation em pagamentos retidos posteriormente. Esses experimentos são executados em computação em lote sobre o histórico de transações, para que você possa avaliar cada candidato sem configurar a materialização online. Assim que tiver selecionado as features, registre suas definições e materialize as agregações móveis e Sawtooth para serving.

Como criar dados de treinamento corretos em termos de ponto no tempo

Cada exemplo de treinamento histórico precisa de features calculadas a partir do timestamp desse pagamento. Para o nosso pagamento de $900 às 10:00, a contagem de cinco minutos deve incluir transações das 9:55 até as 10:00, mas sem incluí-la. Uma contagem recuperada às 10:03 pode incluir um pagamento feito às 10:02, que não estava disponível quando o pagamento original foi pontuado. Isso é vazamento de dados: o modelo aprende com a atividade futura, e seu desempenho offline parece melhor do que realmente é. Feature Views usam as chaves de cliente e o timestamp de cada exemplo para calcular a janela histórica correta a partir de eventos na tabela de ingestão do Stream.

Após registrar as features selecionadas, create_training_set() cria os dados de treinamento do modelo. O DataFrame rotulado fornece as chaves de cliente, o horário do evento, os campos de pagamento atuais e is_fraud. Este trecho seleciona as features registradas do passo a passo, incluindo a linha de base de 30 dias, e usa linhas anteriores a um corte escolhido para treinamento:

Chaves e timestamps selecionam o histórico do cliente, mas são excluídos como entradas do modelo. Os campos de requisição alimentam os cálculos de features; o classificador usa as features nomeadas resultantes. As linhas posteriores formam um conjunto de validação usando as mesmas definições.

Treinamos um classificador random-forest e avaliamos a precisão média e o ROC AUC no último. Em seguida, registramos o modelo por meio do cliente do Feature Engineering. A passagem de training_set=train_set registra as dependências de features de que o serving precisará:

Como servir features em tempo real para inferência online

Mover as features selecionadas acima para o scoring em tempo real exige pipelines para manter agregados de streaming, processar dados históricos e manter a online store atualizada. Construir e operar esses pipelines adiciona meses de trabalho de engenharia de dados além do desenvolvimento do modelo de fraude. Com Feature Views, as definições de features registradas direcionam esse processo: uma chamada para materialize_features() cria pipelines gerenciados que disponibilizam as agregações no Databricks Online Feature Store, alimentado por Lakebase.

O caminho de streaming usa Spark Real-Time Mode (RTM) para processar eventos de entrada continuamente e atualizar agregados móveis conforme eles chegam.

Materializamos as agregações móveis e Sawtooth. Para a linha de base Sawtooth de 30 dias, o Databricks mantém a parte histórica com computação em lote e a atividade recente com streaming. As duas são mescladas na leitura em uma única feature, e StreamingMode() gerencia esse caminho híbrido sem uma chamada de lote separada. Verifique ambos os caminhos de materialização no Catalog Explorer antes do serving. O guia do Sawtooth recomenda aguardar dois dias inteiros antes do uso em produção.

RequestSource fornece os valores de cada requisição de pontuação, e as features derivadas são calculadas sob demanda. Assim que o modelo é implantado, a aplicação envia as chaves do cliente e os campos de pagamento atuais para o seu endpoint. O Model Serving recupera as features mais recentes do cliente e avalia o desvio sob demanda, passando então as entradas para o modelo de fraude. Aqui está o nosso pagamento de US$ 900 no formato de requisição da aplicação, usando a chamada de SDK do pontuador:

A aplicação envia event_time nesta requisição, mas a busca online usa as features de cliente mais recentes disponíveis, e não um snapshot histórico selecionado por esse timestamp. Nesta demonstração, a aplicação pontua cada pagamento antes de publicá-lo no Kafka. Isso mantém o pagamento atual fora de seu próprio histórico, o que corresponde à exclusão desse pagamento na janela de treinamento. As atualizações de features e a pontuação ainda executam de forma assíncrona, portanto outros eventos podem estar em trânsito quando o próximo pagamento for pontuado.

O endpoint retorna uma probabilidade em fraud_probability e uma flag em fraud_prediction. A aplicação armazena as transações pontuadas no Lakebase para o painel.

Como fazer a governança de features de ML no Unity Catalog

Modelos de fraude em produção levantam questões de governança: quais modelos usam uma feature, de onde ela vem e quem pode lê-la. O Unity Catalog reúne definições de features, permissões e linhagem para responder a essas perguntas. O MLflow registra quais features cada modelo usa, e o Model Serving usa essas dependências ao lidar com uma requisição de inferência.

Os privilégios de feature controlam o ciclo de vida:

• CREATE FEATURE controla o registro.
• READ FEATURE concede acesso aos metadados de features.
• MANAGE autoriza operações como a materialização.

Os privilégios de feature não substituem as permissões SELECT necessárias nas tabelas de origem ou materializadas para treinamento e atendimento.

No Catalog Explorer, as Feature Views aparecem em Funções, com suas definições, links de origem, tabelas materializadas e status. As materializações em streaming se conectam aos seus pipelines do Lakeflow gerenciados pelo sistema para inspeção. Tags de materialização permitem que as equipes atribuam os custos de computação de pipelines ou jobs a uma equipe ou projeto específico.

Principais aprendizados para detecção de fraudes em tempo real

Nosso pagamento de US$ 900 agora tem contexto: atividade recente, uma linha de base de longo prazo e a requisição atual. Três práticas tornaram isso possível:

• Defina uma vez, use duas. Definições compartilhadas de features para treinamento e atendimento reduzem a divergência entre treinamento e atendimento decorrente de implementações separadas.
• Calcule o ponto no tempo. Janelas de treinamento que excluem eventos futuros evitam vazamento de dados e mantêm as métricas offline confiáveis.
• Deixe a plataforma executar os pipelines. A materialização e a busca online são gerenciadas, para que o trabalho continue focado em escolher melhores sinais de fraude.

Os mesmos padrões vão além deste passo a passo. LastN mantém sequências como os países de destino dos 10 pagamentos mais recentes de um cliente, o que ajuda os modelos a identificar alterações nas rotas de pagamento. Features em lote também podem usar agregações de histórico completo para resumir todo o histórico de uma entidade.

Para ver mais de perto a infraestrutura por trás da atualização em streaming em menos de um segundo, leia Como o Databricks Feature Store atende features com atualização em menos de um segundo. Para obter detalhes de implementação, consulte a documentação da API de Feature Views, de materialização e de exploração de Feature Views no Unity Catalog.

FAQ

O que são as Databricks Feature Views?

As Feature Views são um recurso do Databricks Feature Store para definir features de ML uma vez e usá-las tanto para treinamento quanto para produção. Cada definição especifica uma origem, chaves de entidade, semântica temporal e uma transformação. A mesma API abrange features em lote, de streaming e sob demanda, e o Unity Catalog faz a governança delas.

Como as Feature Views evitam o vazamento de dados ao treinar um modelo de fraude?

As Feature Views calculam as features de cada exemplo de treinamento com base no timestamp daquele exemplo. Para um pagamento às 10:00, uma contagem de transações de cinco minutos inclui pagamentos das 9:55 até, mas sem incluir, às 10:00. Isso mantém a atividade futura fora dos dados de treinamento, para que o desempenho offline não seja inflacionado.

O que é a divergência entre treinamento e atendimento e como as Feature Views a reduzem?

A divergência entre treinamento e atendimento ocorre quando as features são calculadas de uma maneira para o treinamento e de outra para a inferência online. As Feature Views a reduzem usando uma única definição registrada tanto para o cálculo histórico quanto para a materialização online. As equipes não precisam reimplementar a lógica de features para a produção.

As Feature Views podem calcular features a partir de streams do Kafka?

Sim. Um Stream registrado armazena a conexão, o esquema e as configurações de ingestão do Kafka, e um StreamSource faz referência a ele nas definições de features. O Databricks mantém uma cópia offline do stream em uma tabela de ingestão para treinamento e backfills. O Modo em Tempo Real atualiza as agregações de streaming à medida que novos eventos chegam.

Como as features em tempo real são fornecidas a um modelo de fraude em produção?

A chamada de materialize_features() cria pipelines gerenciados que mantêm as agregações atualizadas no Online Feature Store, alimentado pelo Lakebase. Quando o modelo é registrado com log_model() e implantado no Model Serving, o endpoint recupera as features mais recentes do cliente e calcula features sob demanda a partir da requisição. Em seguida, ele retorna uma probabilidade de fraude.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original