iFood: plataforma de features em tempo real para antifraude (250 → 50 ms)

01 · CONTEXTO E PROBLEMA

Fraude em tempo real exige features frescas

A prevenção a fraudes é crucial no ecossistema das Food Techs, e o iFood se tornou um alvo atraente para fraudadores, especialmente os que testam cartões roubados ou gerados. Como resposta, o iFood combina mecanismos tradicionais de segurança com modelos avançados de inteligência artificial, que avaliam, entre diversos parâmetros, o risco de estornos futuros.

Gerir esses modelos é complexo: um dos desafios é manter as features atualizadas e assegurar a integridade e a baixa latência no acesso aos dados. A resposta foi uma Plataforma de Features, em que os cientistas de dados definem o quê e a plataforma gerencia o como.

02 · A PLATAFORMA

Três camadas e um fluxo de ponta a ponta

A plataforma é composta por três abstrações principais: a Feature Engine, a Feature Store e a Feature Management. A Engine calcula a feature, a Store armazena e serve as features de forma consistente, e o Management garante a integridade, a eficiência e a segurança da plataforma.

Entre as ferramentas integradas estão Apache Spark, Apache Kafka, Delta Lake e Redis, e a plataforma foi desenvolvida principalmente para processar features em tempo real, com o streaming como foco principal. Uma vantagem apontada é a reutilização: as features existentes podem ser compartilhadas por diferentes modelos, sem recriar ou reprocessar features a cada novo modelo.

O Feature Management inclui o monitoramento contínuo, o gerenciamento do ciclo de vida das features (quais podem ser deletadas, quais são acessadas e por quem, além do custo) e o versionamento, que mantém o histórico de todas as alterações.

1. No diagrama, o fluxo de eventos é a entrada da Feature Engine.

2. Cada atualização da feature é armazenada em uma Delta Table localizada em um bucket do S3.

3. Os materializadores leem as transações da Delta Table e as armazenam no destino adequado.

4. O Redis Materializer salva apenas a versão mais recente da feature no Redis.

5. O Delta Materializer assegura a consistência do histórico, armazenando-o em uma Delta Table.

6. Para as features em tempo real há uma API REST, que atende modelos no SageMaker e outras aplicações.

03 · FEATURE ENGINE

Agregação em dois passos

Os cientistas costumam criar várias features semelhantes que variam apenas a janela, como a contagem de pedidos dos últimos 7, 30 e 60 dias. Por isso o iFood desenvolveu o que chama de agregação em duas etapas.

O Two Step Aggregator organiza o dado em janelas menores, chamadas de passo; se o objetivo é agregar um mês, o passo pode ser de um dia. Os resultados desses pequenos segmentos são armazenados como estados intermediários e depois combinados para produzir a agregação final.

Entre os benefícios citados, há redução de custos, porque várias janelas são processadas numa mesma execução de query Spark, e a mesma base de código processa tanto batch quanto streaming.

Cada atualização da feature vira uma nova entrada na Delta Table, o que facilita a reconstrução de qualquer banco de dados em momentos subsequentes, de maneira análoga a um log transacional.

1. No diagrama, os dados de entrada chegam à agregação por passo.

2. O dado é organizado em janelas menores, os passos; para um mês, o passo pode ser de um dia.

3. Os resultados desses pequenos segmentos são armazenados como estados intermediários.

4. Os estados intermediários são combinados para produzir a agregação final, e várias janelas saem de uma mesma execução de query Spark.

5. Cada atualização da feature é armazenada em uma Delta Table.

04 · FEATURE STORE

Online para servir, offline para treinar

A Feature Store é o repositório das features processadas e prontas para uso em modelos de machine learning, segmentada em duas categorias. A tabela resume o que o texto diz de cada uma.

No armazenamento online, o iFood guarda as features em Redis e atinge latências menores do que 10 milissegundos; combinado a uma aplicação no Kubernetes, chega a taxas de 3 milhões de requisições por minuto, e em momentos de baixo fluxo os recursos desnecessários são deslocados.

O armazenamento offline permite recuperar o valor de uma feature num certo ponto no tempo, necessário para o treinamento de modelos, e cada armazenamento possui ainda um consumer específico.

05 · TREINO E INFERÊNCIA

Dois jeitos de ler a mesma feature

No treinamento, a precisão dos dados é a principal preocupação, sem necessidade de focar em latência. A extração usa um identificador único e um momento preciso no tempo, com janela de tempo fechada: o momento escolhido deve ser sempre posterior ao término da janela, para assegurar a não exposição de informações futuras.

O produto final é um dataframe do Spark em que cada característica vira uma coluna distinta.

Na inferência, a latência assume um papel crucial e basta o identificador para acessar os dados mais recentes. O iFood oferece uma API REST especializada, altamente escalável e capaz de processar milhões de requisições por minuto, e cada modelo recupera por ela todas as features necessárias para a sua etapa de inferência.

Segundo o iFood, a plataforma atacou o problema de diferenças entre a lógica da feature no pipeline de treinamento e a lógica para a inferência, o feature skew.

1. No diagrama, há dois caminhos de leitura: um parte da SDK de treino e outro parte do modelo de fraude.

2. Para o histórico há uma SDK em Python que busca os dados históricos.

3. A consulta usa um identificador e um momento no tempo, que deve ser posterior ao término da janela.

4. Cada modelo acessa a plataforma de features pela API, recuperando as features de que precisa.

5. Na inferência basta o identificador para acessar os dados mais recentes, guardados no Redis.

06 · RESULTADO E LIMITES

O que mudou e o que o texto não mostra

Segundo o iFood, o tempo de resposta médio do sistema de fraude era de 250 ms antes da plataforma e passou a 50 ms depois dela. O texto também descreve a redução da latência na recuperação de features de 250 ms para 50 ms, em aproximadamente cinco vezes.

Os modelos de fraude já aproveitavam o Amazon SageMaker, mas o iFood enfrentava desafios internos relacionados à criação e manutenção de features.

Ao tratar features como código e oferecer uma biblioteca padronizada, o iFood incentivou a reutilização e a descoberta de features entre as equipes. Segundo o texto, a plataforma serve mais de um bilhão de requisições diárias, abrange mais de 800 features e é usada por times como recomendação, logística e marketing.