Detecção de Anomalia Simples em Databricks Usando Média e Desvio Padrão

Postado em 23 de Junho de 2025

Qualquer plataforma de dados moderna enfrenta desafios críticos de qualidade e monitoramento de dados. Seja para detectar falhas silenciosas após um deploy ou para identificar comportamentos inesperados dos usuários, conseguir sinalizar anomalias rapidamente pode evitar perda de receita, degradação da experiência do usuário ou riscos de conformidade. A seguir, mostramos como solucionamos esse problema usando um método estatístico simples combinado com IA generativa.

No universo dos dados, padrões regulares são companheiros reconfortantes. Quando seu café está pronto pontualmente às 7h30 ou quando seu gato espera receber ração exatamente às 6h00, é essa previsibilidade que torna a experiência agradável. Mas, de vez em quando, algo quebra esse ritmo - um alarme de café que não dispara ou um miado alto lembrando que você esqueceu de alimentar o bichano. Bem-vindo ao intrigante mundo das anomalias.

Na Consumidor Positivo, enfrentávamos situações em que deploys impactavam nossos sistemas sem que percebêssemos até muito depois, apesar de termos testes unitários e de integração robustos. Pior ainda, levaria um bom tempo até identificarmos a causa e correlacioná-la ao deploy. Isso nos levou a buscar maneiras simples de detectar deslocamentos repentinos nos padrões de dados, para sermos alertados e diagnosticarmos problemas com muito mais agilidade.

Desde então, criamos um sistema chamado ADULA (o nome é uma piada interna que eu não posso contar aqui, infelizmente - a menos que a gente te contrate, é claro) responsável por detectar anomalias nos nossos dados de eventos, e que também evoluiu para diagnosticá-las automaticamente (dentro do possível).

Fundamentos e Premissas

Antes de mergulhar, vamos estabelecer algumas premissas que utilizaremos para construir esse projeto:

Definição Clara de Anomalia

Para detectar uma anomalia, primeiro precisamos definir esse conceito. Aplicamos a regra estatística conhecida como "regra dos três sigma".

Um evento é sinalizado como anomalia quando sua contagem se desvia mais de três desvios-padrão ($3\sigma$) em relação à média (ponderada). Sob a hipótese de normalidade, valores fora dessa faixa ocorrem com probabilidade muito baixa - menos de 0,3% dos dados ficam além dos limites de três sigma, como ilustrado abaixo.

Implementação

Primeiro, definimos nossas restrições: alertas a cada 30 minutos ofereceram um bom equilíbrio entre custo e precisão de detecção para o nosso caso - consideramos e testamos um framework de consultas em janela deslizante (streaming) para avaliação contínua em janelas menores de 1 minuto, mas ficamos bastante satisfeitos com o proof of concept rodando a cada 30 minutos, que era simples de configurar e econômico em termos de custos de cluster.

Em segundo lugar, precisávamos definir quais segmentações usar para verificar se algo era uma anomalia - quanto mais refinada a segmentação, maior a probabilidade de falsos positivos ou até de não encontrar dados suficientes para trabalhar. No nosso caso, como o volume de eventos varia significativamente por hora do dia e dia da semana, dividimos em:

E, por fim, como rodamos em janelas de 30 minutos, o nível final de segmentação determina se o evento cai no intervalo de 0–29 ou 30–59 minutos. Embora calcular a média de diferentes períodos de 30 minutos pudesse oferecer mais precisão, essa abordagem mais simples atendeu suficientemente às nossas necessidades.

Usando os últimos 90 dias de dados, criamos então uma tabela que contém a linha de base (média de contagem de eventos, ponderada por recência) para cada uma das segmentações acima, bem como o desvio-padrão ponderado dessa amostra. Esse workflow é executado semanalmente para recalcular a linha de base. A tabela final fica assim:

Em seguida, outro workflow é responsável por agregar nossos dados em tempo real a cada 30 minutos e comparar o volume observado com a tabela de referência. Se a contagem de eventos se desviar mais de $3\sigma$ da média, isso dispara uma anomalia. No nosso caso, interessava-nos apenas identificar anomalias de limite superior para eventos de rastreamento de erros (aumento inesperado) e anomalias de limite inferior para métricas de negócio (queda inesperada, como PageViews).

Para ajudar a esclarecer como as partes se encaixam, aqui está um resumo visual da arquitetura do sistema que implementamos:

Vamos mergulhar em como os modelos de linguagem nos ajudam logo em seguida.

Para a V1, Isso Foi Tudo - E Aí?

Esse foi o nosso proof of concept. Colocamos no ar (com testes e ajustes) em apenas dois dias. Funcionou de forma surpreendente. Logo no primeiro dia, detectou uma mudança na contagem de eventos de autenticação de usuário. Descobrimos que um deploy recente havia impedido alguns usuários de se autenticarem, e o revertimos imediatamente. Se o sistema de anomalias não estivesse ativo, provavelmente só teríamos percebido o problema quando alguém do time de negócios notasse a queda na taxa de autenticação ao revisar os dashboards.

Após algumas semanas usando o sistema de detecção de anomalias, percebemos oportunidades de melhoria. Primeiro, o limiar de 0,3% em centenas de eventos acabava gerando muitos falsos positivos, e o diagnóstico demorava a ser realizado. Então pensamos: e se pudéssemos automatizar o diagnóstico do disparo de anomalia - talvez usando GenAI?

Automação do Diagnóstico

Nossos eventos chegam em payloads JSON enviados por diferentes aplicações, padronizados por um arquivo JSON Schema que descreve campos e tipos de dados. Um evento de page view, por exemplo, inclui o site, o path da página com UTMs de atribuição, o user agent e outros campos. Um evento de form submission traz o ID do formulário, o ID do step e assim por diante.

Um agente LLM analisando isso pode reconhecer que certas segmentações são potencialmente importantes para diagnosticar uma anomalia - por exemplo, uma queda nas submissões de formulário pode estar concentrada em um form específico e em um step determinado - então o primeiro passo é compartilhar uma amostra desses payloads com um agente encarregado de identificar as segmentações mais valiosas para análise.

Essas segmentações são então convertidas em um template de consulta que compara o volume de eventos para cada valor de segmentação durante a janela de anomalia com as médias históricas - assim, é possível determinar se uma segmentação específica é a principal responsável pela anomalia. Por exemplo, se a queda estiver concentrada em um único form_id, esse será apontado como o driver provável.

Os dados de variação de volume são consolidados em um prompt final, que é enviado a um “Anomaly Detection Analyst Agent”. Esse agente avalia o volume total, o share de variação e identifica as causas mais prováveis da anomalia. Por fim, o agente gera um relatório que é enviado a um canal no Slack junto com o alerta de anomalia, para que os usuários compreendam rapidamente as prováveis causas raiz.

Um exemplo de diagnóstico:

AI Diagnostics for event ProductViewed (workspace `abc`) is complete.
Summary:
Diagnosis: Explainable 
Confidence: 0.85 
Most significant drivers: 
* location -> `offer-popup`
  * variation_share_of_total -> **43%**
  * z_score -> **-4.88**
* channel_source -> `Direct`
  * variation_share_of_total -> **26%**
  * z_score -> **-4.23**
Notes:
* The bulk of the drop is driven by the offer-popup location and Direct channel.

Com isso, fica muito mais fácil identificar o deploy responsável - primeiro, porque ele provavelmente teve um merge nos últimos 30 minutos; e segundo, porque a origem da anomalia tende a ser bem determinada pelo diagnóstico automático.

Observações sobre Trade-offs

Embora esse sistema tenha se mostrado altamente eficaz para nós, não está livre de limitações. Pressupostos estatísticos como normalidade e estacionaridade nem sempre se mantêm, especialmente em eventos de baixa frequência. Falsos positivos ainda podem ocorrer mesmo após ajustes, e diagnosticar anomalias raras ou com múltiplas causas continua desafiador. Ainda assim, ao priorizar simplicidade, interpretabilidade e rapidez de resposta, criamos um sistema que entrega valor real sem demandar infraestrutura complexa ou modelos de ML pesados.

Construindo as Coisas Realmente “Desnecessárias”

Próximo passo “óbvio”? Construir uma API e uma UI! Como os usuários engajaram bem, decidimos incorporar esse sistema de anomalias em uma interface e adicionar recursos de gestão:

Ela se parece com isso:

As faixas verdes mostram onde a variação de volume é esperada - qualquer ponto fora delas dispara o processo descrito acima. Há mais funcionalidades na UI, mas não dá para mostrar tudo aqui.

Considerações Finais

Desenvolver o ADULA foi um lembrete de que ferramentas simples, combinadas com inteligência, podem resolver problemas reais. Nem sempre é preciso usar deep learning para trazer inteligência ao seu stack - às vezes, basta uma boa linha de base, segmentações inteligentes e um toque de IA generativa. Se você enfrenta desafios parecidos, vamos trocar ideias - ou quem sabe até trabalhar juntos!