REPLY AI Agent Challenge - Abril de 2026

Participei do REPLY AI Agent Challenge em abril de 2026.

O que foi realmente o desafio

Removendo a narrativa, o problema era:

Dados múltiplos conjuntos de dados (transações, usuários, locais, SMS, e-mails), decidir quais transações são fraudulentas.

Restrições principais:

o comportamento de fraude evolui com o tempo
as decisões têm custo assimétrico (falsos positivos vs falsos negativos)
os sistemas devem generalizar entre conjuntos de dados
apenas o conjunto de dados de avaliação determina a pontuação oficial
apenas a primeira submissão nos dados de avaliação é aceita

Além da precisão, o sistema também é avaliado em:

custo
velocidade
eficiência

Execução Pré-Desafio

Antes do início do desafio, foquei em algo que geralmente é ignorado:

como a equipe operaria sob restrição.

A equipe estava dividida entre o Japão e o Brasil, então introduzi uma estrutura mínima logo cedo:

um canal compartilhado para decisões finais e conclusões
loops privados para iteração e feedback
separação explícita entre sinal e ruído

Os papéis foram definidos antecipadamente:

Arquitetura / Direção (eu) → design do sistema, decisões, controle de escopo
Engenharia Principal → implementação e integração
Validação / Saída → testes e resultado final

Alinhamos em um loop de execução simples:

definir → implementar → conectar → testar → repetir

Isso não foi sobre sobrecarga de processo — foi sobre evitar:

trabalho duplicado
desalinhamento sob pressão de tempo
gargalos de decisão

Resultado:

a equipe pôde se mover em paralelo sem perder a direção

Estratégia Antes dos Dados

Antes de ver o problema completo, alinhamos algumas suposições de trabalho:

este é um sistema de decisão sobre dados, não um problema de UI
a velocidade de iteração importa mais do que a precisão inicial
precisamos de algo que funcione cedo e melhore incrementalmente

Com base nisso, preparamos:

um pipeline de dados básico
uma estrutura de pontuação modular
logs para apoiar a iteração rápida

Assim, quando o desafio começou:

estávamos adaptando um sistema, não começando do zero

Design do Sistema

Construímos um sistema de decisão em camadas para equilibrar a qualidade do sinal, custo e velocidade.

L1 — Linha de Base Estatística

Para cada usuário, calculamos:

valor mediano da transação
MAD (Desvio Absoluto Mediano)
referências comportamentais (destinatários, métodos, horas de atividade)

Isso estabeleceu uma noção estável de comportamento "normal" por usuário.

L2 — Pontuação Baseada em Atributos

Cada transação foi transformada em um conjunto de atributos (features):

desvio de valor (baseado em MAD)
valor vs renda
taxa de esgotamento de saldo
detecção de novo destinatário
inconsistência geográfica (quando aplicável)
sinais baseados em descrição
exposição a phishing antes da transação

A exposição a phishing foi modelada por:

parsing de SMS e e-mails
detecção de padrões suspeitos
construção de uma linha do tempo por usuário
correlação do timing da transação com eventos anteriores

Isso adicionou um contexto que não é visível apenas na transação.

L3 — Pontuação Composta

Os atributos foram combinados em uma pontuação ponderada.

Escolhas de design:

nenhum atributo individual é decisivo
padrões benignos conhecidos reduzem a pontuação
transações pequenas têm o peso fortemente reduzido
certos tipos de transação são penalizados

Usamos um limiar dinâmico (~top 10%) para selecionar transações suspeitas.

Isso garantiu:

restrições de saída válidas
adaptabilidade entre conjuntos de dados

L4 — Uso Seletivo de LLM

O LLM foi usado seletivamente, não como um mecanismo primário.

Enviamos:

~30% das transações de maior risco

para um modelo hospedado no Groq.

O modelo recebeu:

contexto da transação
perfil do usuário
comunicações recentes

e retornou uma pontuação de probabilidade.

Neste sistema:

o LLM atua como um sinal secundário em camadas sobre a análise estatística e comportamental

Escolha Principal de Design

Em vez de tentar detectar a fraude diretamente, focamos em:

o que acontece antes da transação.

Especificamente:

mensagens de phishing
e-mails suspeitos
tempo entre o contato e a ação

Isso nos permitiu modelar o contexto causal, não apenas anomalias isoladas.

Considerações de Eficiência

A eficiência foi tratada como uma restrição de primeira classe:

a maioria das transações resolvida localmente
LLM usado apenas quando necessário
processamento em lote para controlar a latência
métodos estatísticos simples sobre modelos mais pesados

Isso manteve o sistema responsivo e previsível sob carga.

Resultado

40º lugar de 1.971 equipes

Dado:

uma restrição de 6 horas
uma equipe distribuída
conjuntos de dados em evolução

este resultado reflete uma execução consistente em vez de uma única otimização.

O que eu melhoraria

Sob a restrição de tempo, várias decisões foram tomadas para priorizar a velocidade e a confiabilidade.

Com mais tempo, eu focaria em:

Modelagem temporal As transações foram avaliadas principalmente de forma independente. Incorporar uma análise sensível à sequência capturaria melhor o comportamento de fraude em evolução.
Ponderação adaptativa Os pesos dos atributos eram fixos. Uma abordagem orientada a dados melhoraria a generalização entre conjuntos de dados.
Loop de feedback mais estreito O limiar e a pontuação foram calibrados por conjunto de dados, mas não refinados continuamente durante a execução.
Roteamento de LLM mais seletivo O LLM já era usado como um fallback, mas a seleção poderia ser ainda mais otimizada para custo vs impacto.

Essas foram trocas deliberadas:

priorizar um sistema que funcione de forma confiável sob restrição em vez de um sistema mais complexo que exigiria mais tempo para estabilizar.

Conclusão Final

Este desafio não foi sobre construir um modelo perfeito.

Foi sobre:

tomar decisões sob incerteza
equilibrar precisão com custo e velocidade
estruturar um sistema que possa se adaptar rapidamente

E ao nível da equipe:

criar estrutura suficiente para que a execução permaneça estável sob pressão