Tornando modelos de ML em tempo real mais robustos em cenários adversariais: dicas práticas e considerações sobre monitoramento

Written by: Felipe Almeida

Contributors: Gustavo Durães, Juliano Garcia, Renata Andrade, Moisés Rojo, Mateus Magalhães

Introdução

Modelos de machine learning (ML) em tempo real são frequentemente usados para orientar decisões em processos de negócios. Embora sejam mais complexos de implementar e operar em comparação com modelos em batch, eles costumam ser mais eficazes porque usam dados em tempo real como features e desbloqueiam casos de uso em que o feedback imediato do usuário é essencial.

Atenção: embora grande parte do conteúdo deste artigo também se aplique a GenAI e Visão Computacional, o foco aqui é em ML tradicional, baseado em dados tabulares!

Sistemas em tempo real habilitados por ML tradicional (ou seja, baseados em dados estruturados) geralmente funcionam da seguinte forma: uma ação externa (por exemplo, um usuário interagindo com um aplicativo de banco digital) desencadeia uma sequência de eventos que faz com que serviços enviem dados a um modelo em tempo real, que então gera uma previsão com base nesses dados. Essa previsão é passada para outro serviço (às vezes chamado de camada de decisão) para determinar a decisão de negócios apropriada (por exemplo, aprovar ou rejeitar uma solicitação de empréstimo, ou aceitar ou negar uma solicitação de apólice de seguro). Um exemplo simples pode ser visto na Figura 1:

As features usadas em modelos de ML em tempo real geralmente vêm de padrões de comportamento do usuário e sinais, como dados de geolocalização, engajamento em redes sociais ou ações anteriores do usuário. Isso significa que algumas features podem estar implicitamente sob o controle do usuário.

A maioria das pessoas sabe que modelos de ML são usados em sistemas digitais hoje (por exemplo, para estimar riscos, recomendar conteúdo, classificar itens). Alguns podem tentar manipular os valores das features para influenciar o comportamento do sistema. Essas tentativas — geralmente feitas por agentes mal-intencionados — de manipular os valores das features são chamadas de ataques adversariais.

As tentativas maliciosas de manipular os valores dos recursos para modificar as saídas do modelo são chamadas de ataques adversariais.

Modelos podem ser vulneráveis a ataques adversariais se duas condições forem atendidas: (a) as features podem ser controladas de alguma forma pelos usuários e (b) existe um incentivo para as pessoas manipularem o modelo. Modelos de ML em tempo real são ainda mais vulneráveis; os ciclos de aprendizado são muito mais curtos, e as decisões tomadas com base na saída do modelo podem acontecer imediatamente, sem intervenção humana.

Os modelos de ML em tempo real são duplamente vulneráveis a ataques adversários; as decisões de negócios geralmente são tomadas automaticamente a partir dos resultados do modelo, e pode demorar um pouco para que os ataques sejam detectados.

Vamos explorar alguns exemplos em que modelos de ML em tempo real podem ser vulneráveis a ataques adversariais:

Exemplo 1: Concessão de crédito em tempo real

A decisão de um banco varejista conceder ou não um empréstimo a um cliente é frequentemente tomada por modelos de ML, às vezes em tempo real. A preferência por modelos em tempo real em vez de modelos em batch se deve ao fato de que decisões rápidas proporcionam uma melhor experiência do usuário (UX) e aumentam a receita, ceteris paribus.

Isso cria um conflito claro: os bancos querem emprestar dinheiro a pessoas que vão pagá-lo de volta, mas alguns clientes podem querer fazer empréstimos mesmo que não tenham certeza de que poderão quitá-los. Portanto, há um incentivo financeiro para que algumas pessoas tentem aumentar suas chances de aprovação de empréstimo manipulando o modelo de ML.

Exemplo 2: Detecção de fraudes em compras com cartão de crédito (CC)

Muitas organizações usam ML para detectar fraudes. Como no exemplo anterior, isso cria um incentivo para agentes mal-intencionados tentarem enganar os modelos, já que criminosos querem realizar operações fraudulentas sem serem pegos.

Um exemplo específico é quando um agente mal-intencionado usa informações vazadas para tentar fazer compras com o cartão de crédito de outra pessoa. Para proteger os clientes, muitos processadores de pagamento usam ML em tempo real para detectar e prevenir essas transações fraudulentas. 

Exemplo 3: Rankeamento em motores de busca

Os motores de busca usam informações das páginas da web para avaliar sua qualidade e determinar como devem ser classificadas nos resultados de busca. Isso geralmente é feito usando modelos de ML/NLP para rankeamento.

A maneira correta de melhorar o rankeamento de uma página da web é (como seria de esperar) produzir conteúdo de qualidade que os usuários queiram clicar e consumir. O campo de Search Engine Optimization (SEO) é construído em torno disso.

No entanto, como a receita com anúncios é uma função do número de visualizações que um site recebe, há um incentivo financeiro claro para que os gestores de sites ataquem adversariamente os motores de busca para inflar seus próprios rankings. Isso é chamado de Spamdexing e inclui muitas táticas, como o uso de texto invisível, fazendas de links e mais.

Como um profissional de ML que usa modelos em tempo real em cenários do mundo real, você deseja tornar os modelos menos vulneráveis a ataques adversários e manipulações em geral.

Há muitas maneiras de torná-los mais robustos (como veremos abaixo), mas a única solução sustentável a longo prazo é aceitar o fato de que modelos voltados para o usuário serão manipulados eventualmente e ter um cronograma de retreinamento frequente — para que pontos cegos sejam rapidamente incorporados ao próximo ciclo de retreino.

Antes de começarmos com as dicas, vamos abordar dois pré-requisitos básicos: 1) entender a importância das features e 2) ter algum tipo de configuração de monitoramento em vigor.

Conheça nossas oportunidades

Pré-requisito 1: entenda a importância e a direcionalidade das features

Você precisa saber quais features são as mais importantes e quais delas são vulneráveis a ataques e manipulações por parte dos usuários. Isso ajudará você a identificar onde está a maior parte do risco e em quais features você precisa focar; também permitirá que você estime o “raio de explosão” (blast radius) se uma feature for explorada.

Você precisa saber como os recursos mais importantes afetam a previsão e quais deles podem ser explorados

No mínimo, você precisa saber:

1. Quais features são as mais importantes em termos de poder preditivo absoluto;
2. Quais features podem ser influenciadas por ações do usuário — e, portanto, podem ser exploradas;
3. Como essas features afetam a saída (como valores específicos mudam a saída e em que direção, em média, eles afetam as previsões do modelo).

Saber a importância absoluta das features em um modelo (1) geralmente é fácil; a maioria das implementações fornece alguma maneira de identificar quais features carregam mais sinal. Também existem estratégias “agnósticas ao modelo”, como SHAP. Explicações contrafactuais também podem ser úteis, especialmente para investigar situações em que interações (em vez de features individuais) podem ser exploráveis.

Saber quais features são vulneráveis a ataques (2) depende 100% da implementação do modelo. Você pode precisar colaborar com diferentes membros da equipe (engenheiros de software, engenheiros de dados, etc.) para entender exatamente quais fontes de informação são usadas para construir as features do modelo no momento da inferência — e se os usuários finais têm controle sobre elas.

As duas subseções abaixo explicam como os valores de uma feature específica afetam a saída geral do modelo (3).

Entenda a importância direcional das features

A importância das features para um modelo treinado geralmente é apresentada como uma lista de features classificadas por quanto cada feature contribuiu para a saída, geralmente calculada como uma média sobre o conjunto de treinamento.

Mas, para proteger os modelos contra abusos, não basta saber que uma feature é importante; você também precisa entender em que direção essa feature impacta o escore de saída. Saber disso é crucial porque isso indicará onde está o incentivo: os atacantes naturalmente querem manipular as features na direção que os beneficia — em detrimento da organização.

Importância direcional da feature: saber não apenas a importância de uma feature, mas também se ela aumenta ou diminui os escores do modelo 

Uma das melhores maneiras de ver esse efeito é por meio do gráfico de resumo SHAP Beeswarm, como visto na Figura 5 abaixo. Neste exemplo, a saída do modelo é a probabilidade de uma pessoa ter ganhado mais de US$50 mil na década de 1990. O eixo Y indica a importância “absoluta” da feature, mas o eixo X mostra a direção do impacto no escore final do modelo.

O gráfico de resumo Beeswarm também é útil para depurar features durante o desenvolvimento do modelo: você pode verificar se o gráfico corresponde à sua intuição de como cada feature deve impactar os escores do modelo — e ajudar a identificar erros, como features defeituosas.

Entenda o impacto dependente do valor para features-chave

Entender a correlação aproximada entre as features e a saída do modelo é útil, mas saber quais valores observar é ainda mais importante. Isso é especialmente importante em modelos não lineares, como árvores “boosted” ou redes neurais, onde as relações entre as features e o escore podem ser altamente não lineares e contra-intuitivas.

Os atacantes geralmente aprendem essas relações por tentativa e erro e, eventualmente, descobrem não apenas quais features afetam o escore do modelo, mas também quais valores dessas features aumentam ou diminuem o escore.

Para ficar à frente dos atacantes, você precisa entender quais valores das features são particularmente “perigosos”. Então, você pode construir defesas (como monitoramento especial) focadas nesses valores ou até mesmo decidir remover a feature do modelo completamente.

Um gráfico de dependência parcial (Partial Dependence Plot – PDP) mostra o impacto entre uma feature e a saída do modelo no eixo Y, sobre diferentes valores dessa feature, no eixo X.

Os gráficos de dependência parcial mostram o efeito de valores diferentes de um determinado recurso na escoragem final do modelo

Por exemplo, a Figura 6 mostra o impacto da feature “idade” em um modelo treinado para prever doenças cardíacas. Agora, suponha que uma seguradora de saúde use esse modelo para conceder benefícios financeiros a pessoas consideradas com alto risco de doenças cardíacas. Se a “idade” for autorrelatada pelos clientes, agentes mal-intencionados tentando receber benefícios indevidos eventualmente aprenderão que informar incorretamente sua idade — especialmente acima de 54 anos — aumenta significativamente as chances de receber esses benefícios.

A Figura 6 acima usa a biblioteca PDPBox do Python, mas gráficos de dependência parcial também estão disponíveis em frameworks como scikit-learn. 

Pré-requisito 2: Tenha pelo menos uma configuração básica de monitoramento

O monitoramento de modelos é crucial para permitir que se observe como o modelo está funcionando e, mais importante, como ele está impactando as decisões de negócios. Sem pelo menos um monitoramento básico do modelo, você nem consegue detectar quando/ou se há ataques adversariais ocorrendo, muito menos fazer algo a respeito.

Você deve ter, no mínimo, monitoramento de features e monitoramento da camada de decisão.

Monitoramento de features

Por monitoramento de features, queremos dizer gráficos e plots que mostram os valores das features ao longo do tempo, para cada feature. Por exemplo, na Figura 7 abaixo, podemos ver como seria um ativo de monitoramento para uma determinada feature em um modelo. Embora básicos, gráficos como esse são úteis para avaliar a saúde geral do seu modelo e ajudar a detectar mudanças repentinas na distribuição, que podem indicar tentativas de exploração.

Monitoramento da camada de decisão

O monitoramento da camada de decisão também pode ser chamado de “monitoramento de negócio”; é aqui que se monitoram as decisões de negócios que são tomadas como resultado da saída do modelo. Se voltarmos aos exemplos 1 e 2 da introdução desse blog post, isso significaria monitorar a taxa de empréstimos negados ao longo do tempo e a taxa de compras com cartão de crédito negadas ao longo do tempo, respectivamente.

O monitoramento da camada de decisão responde à pergunta: “Como as decisões de negócio estão sendo impactadas pelas previsões do modelo?” Isso é crucial porque é aqui que o impacto real dos ataques aparece. Os atacantes exploram os modelos como um meio para um fim — o fim é sempre forçar o sistema a tomar uma decisão favorável (para eles).

O monitoramento da camada de decisão responde à pergunta: Como as decisões de negócio estão sendo impactadas pelas previsões do modelo?

Este é apenas o mínimo de configuração de monitoramento. Outras dimensões a considerar incluem métricas operacionais (CPU, RAM, Latência), métricas de desempenho (F1, AUC, etc.), desvio entre treino e produção, e você também deve adicionar alertas.

Para mais considerações sobre monitoramento, consulte a última seção deste post.

Com os pré-requisitos esclarecidos, vamos agora examinar as dicas reais para tornar seus modelos de ML mais robustos contra ataques adversariais.

Dica: alertas simples ajudam a detectar ataques

Embora o objetivo seja prevenir ataques adversariais, a detecção é crucial quando a prevenção falha. Para ML em tempo real, você precisa de sistemas de detecção em tempo real que acionem alertas quando certas condições forem atendidas. Ferramentas como Splunk, New Relic e Datadog podem ser usadas para criar alertas com base em consultas de logs.

Os atacantes sabem que precisam ser rápidos; uma vez que encontram uma vulnerabilidade, precisam explorá-la rapidamente antes que a organização alvo possa se defender. Portanto, alertas destinados a detectar ataques adversariais devem tentar detectar mudanças repentinas que possam indicar que um ataque está ocorrendo.

Além disso, você quer evitar a fadiga de alertas (alert fatigue) — ou seja, um grande número de falsos positivos —, então deve basear os alertas nas decisões de negócio reais, em vez de artefatos do modelo: em vez de alertas com base em escores brutos do modelo ou features, prefira alertas com base nas ações subsequentes que são impactadas pelos modelos, como empréstimos sendo emitidos, incidentes de fraude detectados, mensagens de clientes roteadas incorretamente, etc.

Aqui está um exemplo de alerta que atende a esses critérios: “Acione um alerta se a taxa de compras com cartão de crédito negadas nas últimas 6 horas for mais de 20% menor do que o mesmo valor na semana passada”. Esse alerta detecta uma mudança repentina (dentro de 6 horas) em uma métrica de negócio (transações com cartão de crédito negadas) e usa uma comparação com a semana anterior para levar em conta a sazonalidade.

Um exemplo do que fazer quando um alerta verdadeiro é acionado é desativar uma feature flag, como explicado abaixo. Para mais sobre melhores práticas de alertas, consulte Melhores Práticas para Machine Learning em Tempo Real: Alertas.

Dica: o retrineo frequente do modelo é a única solução sustentável em escala

Sistemas habilitados por ML voltados para o usuário sempre serão alvos de atacantes, especialmente em casos onde há possibilidade de ganho financeiro. No final das contas, os atacantes fazem uma análise de custo-benefício ao planejar ataques, e seu trabalho como profissional é aumentar o custo tanto que deixe de valer a pena para a maioria das pessoas explorar seu sistema; esperando que atacantes desistam de uma vida de crime e se tornem membros respeitáveis da comunidade. Certo?

No entanto, tentar combater cada vetor de ataque individualmente com condições manuais acaba tornando sistemas em grande escala frágeis e difíceis de manter, frustrando o propósito de deixar os dados orientarem as decisões de negócios. Pode se tornar um jogo de “whack-a-mole”, onde você está constantemente tentando defender o sistema contra novas ameaças, mas os atacantes logo encontram novas maneiras de contornar as defesas, e o ciclo nunca termina.

Algumas barreiras de proteção e um cronograma robusto de retreinamento são uma boa estratégia para se defender contra ataques adversariais em escala

Depois de ter algumas barreiras para evitar desastres, é provavelmente melhor aceitar que algumas explorações ocorrerão — e então usar esses eventos como dados de treinamento. O retreinamento frequente dos modelos permite que você incorpore tentativas de exploração ao conjunto de treinamento para as próximas iterações do modelo — fazendo com que o modelo aprenda com esses casos e se torne mais robusto ao longo do tempo.

Uma combinação especialmente útil é automatizar o retreino de modelos, pois isso reduz a probabilidade de erro humano e libera recursos para aprimorar os sistemas.

Dica: torne os ciclos de tentativa e erro mais caros para os atacantes

Os atacantes aprendem a manipular sistemas habilitados por ML por tentativa e erro; eles interagem repetidamente com o sistema para aprender suas “peculiaridades” e idiossincrasias. Tornar mais difícil para eles coletar informações sobre seus modelos é uma ótima maneira de mitigar o risco adversarial; mas certifique-se de que usuários legítimos não sejam prejudicados no processo.

Tornar mais difícil para os possíveis invasores coletarem informações sobre seus modelos é uma ótima maneira de reduzir o risco de ataques adversariais, mas certifique-se de que os usuários legítimos não sejam prejudicados no processo

Agora listaremos vários exemplos de como tornar esses ciclos de aprendizado mais caros; no entanto, você deve ter em mente que essas estratégias podem ter consequências não intencionais, prejudicando a experiência de usuários legítimos. Seu caso de uso específico determinará se a troca vale a pena.

Exemplo 1: limite a frequência de interações

Você pode limitar o número de vezes que os usuários podem interagir com seu sistema em um determinado período. Por exemplo, clientes que desejam solicitar uma apólice de seguro podem fazer apenas uma tentativa por mês. Isso exigiria que usuários mal-intencionados esperassem muito mais tempo para aprender ou criassem várias contas, etc.

É também por isso que os sistemas operacionais forçam você a esperar alguns segundos para tentar novamente depois de digitar a senha errada. Isso é feito para reduzir a chance de ataques de força bruta.

Exemplo 2: atrase a decisão do modelo

Quanto mais próximo no tempo o input do usuário estiver da resposta do modelo, mais claras serão as ligações de causalidade, e mais fácil será para as pessoas encontrarem padrões. Mitigue isso atrasando o feedback do modelo, em vez de fornecer uma resposta imediata.

Por exemplo, quando os clientes solicitam uma hipoteca por meio de um aplicativo móvel, opte por informá-los sobre o resultado após algumas horas (mesmo que o resultado esteja imediatamente disponível).

Dica: você pode precisar trocar robustez por desempenho

Às vezes, o impacto potencial de ataques adversariais é tão alto que a única solução disponível é propositalmente “diminuir” a sensibilidade de um modelo — efetivamente trocando um pouco de desempenho por maior robustez.

A solução mais simples (não necessariamente a melhor) para lidar com features exploráveis é simplesmente removê-las do modelo

Aqui estão algumas maneiras de fazer isso:

• Remova features vulneráveis completamente: a maneira mais simples de eliminar o risco é remover a feature do modelo.

• Use proxies em vez de features reais: às vezes, podemos substituir uma feature problemática por um proxy. Ou seja, alguma outra informação que tenha alta correlação com a feature original, mas não exponha a mesma superfície de ataque.

• Substitua valores problemáticos das features por valores neutros: durante a EDA e o treinamento do modelo, pode ser possível identificar valores neutros das features — ou seja, valores para os quais o impacto médio na saída do modelo é próximo de zero.

• Aumente a regularização do modelo: aplicar regularização, explicada em detalhes na seção abaixo, é outra maneira de trocar desempenho por robustez, já que modelos regularizados muitas vezes precisam abrir mão de poder preditivo bruto para melhor generalização fora da amostra (OOS).

Dica: a regularização ainda é sua amiga

A regularização é o processo de tornar os modelos menos sensíveis a mudanças nas features. Isso geralmente é feito para evitar overfitting, melhorar a generalização e estender a vida útil dos modelos de ML, já que modelos regularizados tendem a decair mais lentamente. Mas aumentar a regularização também ajuda a tornar seu modelo mais robusto contra ataques adversariais.

Há pelo menos duas abordagens para regularização, com robustez adversarial em mente: as abordagens específicas do modelo (ou seja, hiperparâmetros disponíveis para ajuste em algoritmos de ML) e abordagens centradas em dados (por exemplo, adicionar ruído ao seu conjunto de treinamento para tornar o modelo menos sensível a essas features).

Regularização específica de modelo

Por regularização específica do modelo, nos referimos a técnicas que só podem ser usadas para algoritmos de ML específicos. Na maioria das vezes, esses são hiperparâmetros que diminuem a capacidade do modelo e, portanto, sua capacidade de overfitting.

Algoritmos	Parâmetros
Gradient-boosted Trees	Column Sampling Gamma Learning Rate Maximum Tree Depth Minimum Child Weight Number of Trees
Random Forest	Max Tree Depth Number of Trees
Linear/Logistic Regression	L1/L2 Regularization
Neural Nets	Batch Normalization Dropout Early Stopping L1/L2 Weight Regularization Learning Rate

Regularização centrada em dados

Há também técnicas de regularização que envolvem algum tipo de pré-processamento de dados. A principal vantagem dessas técnicas é que elas podem ser compartilhadas entre vários modelos e podem ser específicas para cada feature; você pode optar por regularizar apenas algumas features, mantendo outras inalteradas. Isso (juntamente com os hiperparâmetros, como visto acima) deve forçar o modelo a confiar menos nessas features, sem descartá-las completamente. 

Uma maneira simples de obter a regularização centrada nos dados é adicionar ruído não correlacionado ao conjunto de treinamento, especialmente às features vulneráveis aos quais você deseja aumentar a robustez. 

Há também maneiras “específicas de domínio” de restringir os valores de uma feature. Por exemplo, se “idade” for uma feature em seu modelo, você poderá impor um intervalo válido para os valores durante o tempo de pré-processamento usando funções de piso (floor) e teto (ceiling). Mesmo que os invasores descubram como modificar esses valores, os danos serão um pouco limitados porque estarão dentro do intervalo predefinido.

Não se esqueça de testar essa abordagem, no entanto, para ver se ela funciona para você.

Dica: use feature flags para lidar rapidamente com ataques

Embora o objetivo final seja evitar ataques adversariais, é essencial estar preparado para agir rapidamente a fim de limitar os danos quando e se eles ocorrerem. Feature flags (também chamados de feature toggles) são uma maneira de lidar com ataques de forma ágil.

Feature flags são condições simples de IF/ELSE no código que controlam se a execução em tempo real segue um caminho ou outro, basicamente ativando ou desativando partes do código. Isso é mostrado na Figura 8 abaixo:

Feature flags geralmente são controlados fora do fluxo normal de CI/CD — para que possam ser atualizados sem a necessidade de um deployment completo do serviço, o que pode levar tempo e/ou falhar. Uma estratégia comum é armazenar feature flags como arquivos em um sistema de armazenamento remoto, como o S3.

Aqui estão alguns exemplos de como usar feature flags para reagir a um ataque adversarial em andamento:

• Torne os limites de decisão mais rigorosos: se uma decisão arriscada (por exemplo, conceder um empréstimo com base em um escore de risco) for tomada diretamente a partir de uma previsão do modelo, você pode tornar essa decisão temporariamente mais rigorosa ou conservadora. Por exemplo, exigir um escore de  risco muito menor do que o habitual para aprovar um empréstimo.
• Desative completamente o fluxo de negócios: dependendo da importância do fluxo de negócios afetado pelo ataque, você pode optar por desativá-lo completamente, mesmo que isso cause alguns problemas de experiência do usuário (UX).
• Substitua features manipuláveis por valores neutros: codificar valores neutros em vez de usar as informações fornecidas pelo usuário é outra maneira de se defender contra ataques. Você pode descobrir quais são esses valores usando gráficos de dependência parcial (PD plots), conforme explicado em “Entenda o impacto dependente de valor em features-chave”.
• Use uma versão de fallback do modelo, sem features manipuláveis: Outra alternativa é ter uma versão de “fallback” do modelo que não use nenhuma feature potencialmente explorável. Usar uma versão mais simples do modelo pode impactar o desempenho, mas provavelmente será melhor do que enfrentar diretamente o impacto de um ataque. Essa estratégia é mostrada abaixo como pseudocódigo na Listagem 1.

Feature flags são muito úteis em diversos outros cenários não relacionados ao aprendizado de máquina também. Eles são um tópico interessante por si só.

Dica: prefira encoding de baixa granularidade para features especialmente sensíveis

Às vezes, não é possível simplesmente remover features vulneráveis de um modelo. Isso pode acontecer devido a requisitos regulatórios ou porque a feature é absolutamente crucial para o modelo, e sua remoção tornaria o modelo inútil.

Uma maneira de manter features potencialmente exploráveis em um modelo (enquanto reduz um pouco a superfície de ataque) é diminuir sua granularidade. Isso geralmente torna o modelo um pouco menos preciso, mas oferece um nível de proteção contra ataques.

Para features numéricas, isso geralmente significa agrupar valores em intervalos, ou “bins”. Vários pacotes de software suportam a criação de intervalos ou “bucketization” como etapas de pré-processamento em um pipeline de engenharia de features.

A granularidade de uma funcionalidade refere-se ao nível de detalhe que ela possui. Quando há risco de ataques, pode ser útil preferir features de baixa granularidade (grosseiras) em vez de features de alta granularidade (detalhadas).

No caso de features categóricas, diminuir a granularidade significa reduzir sua dimensionalidade: seja agrupando valores ou usando métodos como PCA após a codificação. Já para features contínuas e/ou numéricas, você pode usar intervalos (também chamados de “bins”) em vez de valores brutos.

Diminuir a granularidade das features ajuda de duas maneiras:

• Reduz a “sensibilidade” do modelo em relação a essa feature, atuando, na prática, como uma forma de regularização.
• Reduz a chance de que pequenas perturbações no valor da feature alterem o escore do modelo — desde que os limites dos intervalos não sejam ultrapassados.

No entanto, é importante verificar (com gráficos de dependência parcial – PD Plots, por exemplo) se essa abordagem funciona no seu cenário específico. Em alguns casos, as features modificadas ainda apresentam uma superfície de ataque, principalmente se usuários mal-intencionados puderem inferir onde estão os limites dos intervalos.

Considerações sobre monitoramento

O monitoramento é essencial para detectar ataques adversariais em machine learning em tempo real, como explicado anteriormente. Aqui estão algumas dicas práticas para aprimorar sua configuração de monitoramento. Monitoramento é um pré-requisito para lidar com problemas adversariais em ML em tempo real, como explicado acima. Agora nós vamos detalhar dicas mais práticas para ajudá-lo ainda mais.

Monitore percentis para valores de features

A maioria das ferramentas de monitoramento se concentra em monitorar a média dos valores de features numéricas. Embora útil, a média esconde informações importantes, especialmente quando as decisões são tomadas com base em previsões nos extremos, como é o caso de previsões de risco.

Para evitar possíveis pontos cegos, você também precisa monitorar os percentis das features, principalmente aqueles relacionados aos extremos (percentis 1, 10, 90 e 99). Isso permite detectar visualmente desvios estranhos, que podem indicar que ataques adversariais estão ocorrendo.

Monitore decisões de negócios

Embora os atacantes tentem influenciar as features do modelo, seu objetivo final é impactar as decisões de negócio. Portanto, essas decisões devem ser monitoradas separadamente. Muitas vezes, os ataques são sutis, mas fortes o suficiente para mover o escore além do limite de decisão, afetando as decisões de negócio. Em outras palavras, é importante monitorar a distribuição das decisões impulsionadas pelo modelo no final do funil. Isso é o que chamamos de “monitoramento da camada de decisão” no Pré-requisito 2.

No exemplo mostrado na Figura 10, vemos as taxas de aprovação de sinistros para uma empresa fictícia de seguros de carro. A decisão de aprovar ou negar um sinistro é tomada com base em um modelo de ML. O pico em abril de 2024 é motivo de preocupação: pode ser o resultado de atacantes tentando cometer fraudes de seguro. No entanto, a previsão média do modelo que orienta as decisões não parece fora do normal; sem o monitoramento da camada de decisão, estaríamos cegos a um possível ataque.

Monitore por segmento

Segmentação refere-se a dividir as instâncias escoradas por um modelo em grupos semânticos, para fins de monitoramento. A ideia principal é que visualizar métricas agregadas para todas as instâncias como um grupo combinado oculta detalhes importantes: como o tamanho da amostra é maior, as métricas tendem a ser mais suaves, e fica mais difícil detectar problemas que afetam apenas um subconjunto da população total, especialmente se forem menos comuns.

Exemplos de segmentos incluem:

• Tipos de compra com cartão de crédito: compras físicas, compras contactless, compras online.
• Tipos de cliente: baixa renda, média renda, alta renda.
• Visitantes de um site: aqueles que usam navegadores, celulares, tablets, etc.

Visualizar métricas por segmento também é útil para detectar ataques adversariais, pois eles podem ser direcionados a subgrupos específicos, em vez de todo o espaço de instâncias. A Figura 11 abaixo mostra como a visualização de métricas por segmento permite detectar problemas que passariam despercebidos ao olhar apenas para os valores agregados globais.

Atributos de entrada vs. features

Muitos pipelines de modelo incluem engenharia de features ou pré-processamento sobre os dados brutos fornecidos pelo usuário antes de usá-los ns modelos. Pode ser difícil detectar ataques direcionados se apenas as features forem monitoradas, pois pode haver várias etapas de processamento até que um atributo de entrada se torne uma feature.

Você deve ter recursos de monitoramento separados para os valores dos atributos de entrada — além de monitorar as features e as previsões ao longo do tempo.

Construindo modelos de ML em tempo real eficazes e resilientes

Modelos de machine learning (ML) em tempo real são poderosos, mas vulneráveis a ataques adversariais, onde atores maliciosos manipulam features para influenciar resultados. Para proteger seus modelos, concentre-se em compreender a importância das features com ferramentas como SHAP e Gráficos de Dependência Parcial (Partial Dependence Plots) e configure um monitoramento ativo para detectar padrões incomuns. Use alertas em tempo real baseados em métricas de negócio para identificar ataques precocemente.

O retreino frequente dos modelos ajuda seu sistema a aprender com tentativas adversariais, enquanto estratégias como limitar interações, atrasar decisões ou adicionar ruído tornam a exploração mais difícil. Em alguns casos, trocar desempenho por robustez — removendo features vulneráveis ou aumentando a regularização — pode reduzir significativamente os riscos. Ferramentas como feature flags permitem que você responda rapidamente, e a redução da granularidade das features minimiza a superfície de ataque.

Ao combinar essas estratégias, você pode construir modelos de ML em tempo real que são tão eficazes quanto resilientes. O objetivo não é impedir todos os ataques, mas torná-los tão custosos que os atacantes desistam.

Se você deseja fortalecer seus sistemas de ML, continue lendo nosso blog para mais insights. E se você é apaixonado por construir soluções de ML de ponta, estamos contratando! Junte-se a nós na construção do Futuro Roxo.