Detecção de bots

01 · CONTEXTO E REQUISITOS

Um problema adversarial, com poucos rótulos

Bots são atores automatizados maliciosos que fazem muitas coisas numa plataforma, como criar contas falsas, enviar pedidos de amizade e mensagens, postar conteúdo duplicado ou nocivo e espalhar desinformação. Este caso projeta um sistema de detecção de bots para uma rede social, com o objetivo de separar a atividade de usuários legítimos da atividade automatizada ou maliciosa.

As respostas do entrevistador definem o desenho. Ele pode informar que, sem remediação, os bots são 50% ou mais de todas as ações, mas que heurísticas simples reduzem isso a menos de 1%. A escala assumida é de 500M de usuários ativos por dia, com 1-2 sessões por dia. Classificar um usuário real como bot afasta bons usuários e reduz o engajamento deles, e, embora existam recursos, revisá-los é caro.

Algumas restrições mandam no desenho. O problema é adversarial: autores de bots se adaptam o tempo todo para evitar a detecção, e os bots mais recentes são bem mais sofisticados e difíceis de detectar do que os que enviavam requisições em frequência muito maior que a humana. A prevalência é alta e o sistema fica na frente de muitas superfícies de interação, então computação é uma restrição central. Por fim, os dados rotulados são escassos e caros, e os investigadores verificam contas manualmente na casa das centenas por semana.

02 · OBJETIVO

O que otimizar: impacto, não contagem

Antes de escolher o modelo, é preciso traduzir o problema num objetivo de negócio, que é distinto da função de perda e do objetivo de ML. A fonte compara formulações possíveis do objetivo.

O objetivo de ML, por sua vez, é direto: no fundo, é um problema de classificação binária, em que se classifica uma conta como bot ou não bot.

03 · DADOS E FEATURES

Rótulos escassos, sinais diversos

Os rótulos vêm de fontes com forças diferentes. Os de investigadores são a fonte de maior qualidade, mas, como são poucos, convém enviar à revisão manual as contas perto das fronteiras de decisão ou com padrões novos. Denúncias de usuários dão rótulos ruidosos, mas escaláveis, e recursos bem-sucedidos dão rótulos negativos de alta confiança.

Também é possível propagar rótulos pelo grafo social: IPs maliciosos conhecidos dão rótulos positivos adicionais e a criação em massa de contas a partir de origens parecidas indica fazendas de bots. A própria fonte alerta que é preciso cuidado para não propagar erros pelo grafo.

As features se organizam em grupos. Em padrões de atividade entram a cadência de postagem, medida pela distribuição do tempo entre eventos, e a detecção de rajadas, que são picos de atividade acima da capacidade humana; esses padrões são calculados em várias janelas de tempo, como hora, dia e semana. Em sinais de rede entram a razão entre seguidores e seguidos, que costuma ser enviesada em bots, a velocidade de formação de conexões e o coeficiente de agrupamento. Os metadados da conta cobrem idade, verificação, completude do perfil, frequência de login e diversidade de dispositivos.

Os sinais de conteúdo estão entre os mais fracos, por serem os mais fáceis de falsificar e os mais visíveis: se o sistema derruba sempre conteúdo de um tipo e não de outro, os adversários passam a produzir mais do outro. Os padrões temporais de atividade sofrem menos com isso.

Nem todas as features estão disponíveis logo no cadastro. O modelo deve lidar bem com dados ausentes e possivelmente usar conjuntos de features diferentes para contas novas e estabelecidas.

04 · MODELAGEM

Começar simples e juntar grafo com sequência

O desenho combina duas abordagens. Para bots óbvios ou assinaturas já observadas, usam-se técnicas supervisionadas e abordagens não paramétricas, de alta precisão. Para os mais difíceis de detectar ou nunca detectados, usam-se técnicas não supervisionadas. As respostas combinam banimentos, rebaixamentos e limites: com confiança, remove-se a conta; sem certeza, reduz-se a visibilidade ou o volume de interações com outros usuários.

Em modelagem, a fonte propõe começar com algo simples, ver onde estão as lacunas e acrescentar sofisticação onde importa. O baseline não é trabalho descartável: ele vira o canário que avisa quando uma versão futura piora.

A detecção de bots é mais um desafio de avaliar comportamento do que de julgar só o conteúdo. A proposta junta duas visões complementares: o grafo mostra com quem a conta se conecta e quão densamente, e a sequência mostra o que a conta faz ao longo do tempo. A fonte escolhe uma GRU em vez de um transformer porque o alvo é comportamento suspeito, não a nuance da linguagem.

1. O tronco principal se divide em dois ramos especializados, um para a sequência de eventos e outro para o grafo, e depois junta as visões de cada conta.

2. O ramo de grafo usa GraphSAGE, que é indutivo, sobre um subgrafo compacto de k saltos, normalmente k=2. A amostragem de vizinhos limita o fan-out de contas de celebridades.

3. O ramo de sequência pega cerca de 200 eventos recentes, agrupa os horários em intervalos de cinco minutos, embute o tipo do evento e passa a sequência por uma GRU bidirecional com estado oculto pequeno.

4. Os vetores de saída dos dois ramos se encontram numa única camada de atenção cruzada.

5. A representação passa por um MLP minúsculo de três camadas que emite um score bruto de risco.

6. O score bruto é calibrado para virar uma probabilidade de bot; uma opção é ajustar uma sigmoide ao score bruto, com dois parâmetros aprendidos num conjunto hold-out.

Treinar um modelo grande com poucos dados e um único objetivo binário é receita para overfitting e treino instável, por isso a fonte recorre ao pré-treino. Com boa parte do trabalho feita por autossupervisão, o ajuste fino é leve: congela-se a maior parte das camadas, usam-se alguns milhares de rótulos confiáveis e calibra-se o score final para ler como probabilidade de bot.

A função de perda é a entropia cruzada binária ponderada. O peso de cada amostra reflete quantos usuários reais a conta poderia ter incomodado, e os pesos têm teto para evitar gradientes descontrolados.

05 · INFERÊNCIA EM ESCALA

Um filtro leve na frente do modelo caro

O modelo supervisionado principal é caro e provavelmente exige GPUs. Para reduzir a computação, otimiza-se o modelo, por exemplo com treino com consciência de quantização, que reduz memória mantendo a acurácia, e reaproveitam-se cálculos: embeddings de grafo da conta podem ser guardados por um curto período e as codificações de padrões de atividade podem ser reaproveitadas, num cache.

Além disso, em vez de rodar o modelo caro em toda conta, adota-se uma arquitetura em dois estágios: um filtro leve, que é uma regressão logística rápida com sinais básicos, e o modelo pesado completo, reservado às contas que passam pelo filtro inicial. O filtro leve é treinado em formato professor-aluno para aproximar a saída do modelo pesado.

A cascata reduz a computação em 80-90% mantendo a qualidade de detecção, e, se o sistema está com poucos recursos, sobe-se o limiar do modelo leve para rodar o modelo pesado em menos contas, com perdas de eficácia.

1. No diagrama, as ações das contas passam pelas superfícies da plataforma e chegam à fila de eventos. Cadastro de conta e denúncias de usuários estão entre os gatilhos que disparam o modelo leve.

2. O filtro leve é uma regressão logística rápida, com sinais básicos como frequência de postagem, idade da conta e padrões de dispositivo, e identifica rapidamente as contas obviamente legítimas.

3. O modelo completo de grafo e sequência fica reservado às contas que passam pelo filtro inicial.

4. Os embeddings de grafo da conta podem ser guardados por um curto período, e as codificações de padrões de atividade podem ser reaproveitadas.

5. Técnicas não supervisionadas cobrem os bots mais difíceis de detectar ou ainda não detectados.

6. Com confiança, a conta é removida; onde não há certeza, reduz-se a visibilidade da conta ou limita-se o volume de interações com outros usuários.

O sistema precisa tratar avaliação de contas em tempo real e atualizações conforme os padrões evoluem. O modelo leve é disparado por vários eventos: cadastro de conta, cruzamento de limiares de atividade suspeita, mudanças na rede e denúncias de usuários. A estratégia de cache é adequada para reavaliar, desde que a vizinhança da conta na rede não tenha mudado muito.

Ao reavaliar, há desafios de dados. Na supressão positiva, como a detecção eficaz remove contas antes que mostrem o comportamento completo, o modelo corre o risco de aprender que dados comportamentais indicam legitimidade. No viés de sobrevivência, os bots restantes ficam mais sofisticados e exigem adaptação constante. Para lidar com isso, a fonte usa holdouts, que coletam dados valiosos e escondem dos adversários a informação que as ações do sistema revelariam, mas é preciso cuidado para que autores de bots não os explorem para passar pela detecção.

06 · AVALIAÇÃO E DERIVA

Medir sem rótulos suficientes e sem olhar só o passado

Na avaliação online, rodam-se os modelos candidato e controle lado a lado, agindo com base em apenas um deles, o que exige rotulagem adicional porque os modelos sinalizam populações diferentes de contas. Com prevalência baixa, amostragem aleatória exigiria amostras enormes, então usa-se amostragem por importância baseada nos scores: amostram-se mais as contas perto das fronteiras de decisão onde os modelos discordam e sub-amostram-se os casos óbvios, com reponderação.

1. Com prevalência baixa de bots, a amostragem aleatória exigiria amostras enormes; por isso, a escolha das contas a rotular parte dos scores dos modelos.

2. A amostragem dá mais peso às contas perto das fronteiras de decisão onde os modelos discordam, e sub-amostra os casos óbvios, com scores perto de 0.0 ou 1.0, com reponderação.

3. Os investigadores verificam contas manualmente na casa das centenas por semana, e esses rótulos são a fonte de maior qualidade.

4. Denúncias de usuários dão rótulos ruidosos, mas escaláveis, e recursos bem-sucedidos dão rótulos negativos de alta confiança.

5. O sistema deve distinguir os rótulos de investigadores dos rótulos gerados pelo sistema e pesá-los de acordo.

6. Os rótulos servem, entre outros usos, para criar conjuntos de teste que refletem a sofisticação real dos bots e para calibrar limiares de confiança.

O principal indicador online é a redução de interações de bots por usuário legítimo, sujeita a manter a taxa de falsos positivos abaixo de 1% nas restrições de conta. Para iterar mais rápido, usam-se proxies: denúncias de usuários, taxa de sucesso de recursos e efeitos de rede, como aceitação de pedidos de amizade e taxa de resposta a mensagens.

Offline, a métrica primária Precision@Recall90 está alinhada ao limiar operacional das ações automáticas, PR-AUC é um indicador estável do poder discriminativo geral e as métricas ponderadas por impacto usam a exposição potencial dos usuários. Como diagnósticos, há a taxa de detecção precoce, que é a fração de bots pegos nas primeiras 24 horas de atividade, e a cobertura de rede. Avalia-se também o desempenho entre demografias e geografias para identificar viés.

Um dos maiores desafios em cenário adversarial é a deriva: espera-se que o comportamento dos bots futuros seja diferente do dos já vistos. Uma das formas mais simples de refletir isso offline é estratificar os conjuntos de validação por tempo. A fonte ainda testa regularmente contra comportamentos simulados e técnicas de evasão conhecidas, mantendo um conjunto de dados de red team.

Na calibração, scores não calibrados fazem as ações divergirem muito de uma probabilidade ingênua, já que 0.6 não significa que 60% das vezes a conta é bot; calibrar ajuda a respeitar os guardrails e estabiliza o sistema em migrações e novos deploys, e a fonte considera Platt scaling uma ótima opção, dados os rótulos caros e os poucos pontos relevantes da curva.

Na detecção de anomalias, as isolation forests isolam anomalias com menos divisões aleatórias que dados normais e são boas para anomalias pontuais, mas têm dificuldade com anomalias contextuais. Os autoencoders custam mais, porém capturam dependências temporais e padrões sequenciais que as isolation forests perdem. A proposta é um ensemble que usa isolation forests para triagem rápida de outliers óbvios e autoencoders nas contas que passam desse filtro.

07 · CONTRAPONTO EM PRODUÇÃO

Cloudflare: o mesmo problema, requisição a requisição

Há sistemas assim em produção. A Cloudflare descreve um score de 0 a 100 para cada requisição, que indica se ela veio de um humano (score alto) ou de um programa automatizado (score baixo). O escopo difere do caso da Hello Interview, em que o alvo é classificar uma conta como bot ou não bot.

Os requisitos técnicos da Cloudflare são exigentes: calcular o score em toda requisição, mesmo acima de 10 milhões por segundo, sem atrasar o processamento em mais de 100 microssegundos.

A plataforma usa cinco mecanismos de detecção complementares, cada um produzindo seu próprio score, e os combina num score único que vai para o Firewall.

Dois detalhes da plataforma merecem registro. Primeiro, por causa da alta certeza, as requisições classificadas por heurísticas treinam os modelos de ML. Segundo, vários modelos CatBoost rodam em modo shadow em cada requisição, enquanto um roda em modo ativo e influencia o score final. Novos modelos são implantados em segundos pelo banco de configuração Quicksilver.