Esse post foi revistado por: Luis Moneda, Gabriela Mourao e Cristiano Breuel.


Modelos de aprendizado de máquina (ML) são softwares bem delicados, sendo necessários monitoramentos cuidadosos para garantir um bom funcionamento e sucesso no uso.

Isto é importante principalmente quando decisões corporativas são feitas automaticamente usando as conclusões de tais modelos. Isto significa que modelos com erros normalmente terão impactos significativos na experiência do usuário final.

Modelos são tão bons quanto os dados que consomem. Por isso, o monitoramento dos dados inseridos (e das conclusões) é essencial para que o modelo cumpra seu verdadeiro objetivo: ser útil para levar a boas decisões e fazer com que o negócio atinja sua meta.

Aqui estão algumas dicas práticas e independentes de estruturas que você pode usar para ter uma estratégia de monitoramento mais robusta ao usar modelos de aprendizado de máquina na produção.

(Diversas dicas podem se misturar, já que devem ser usadas como parte de uma estratégia integrada e não de forma isolada)

Médias não contam toda a história

Contexto 

Você monitora valores médios para características numéricas nos modelos que usa. Isto acontece porque você quer detectar problemas de dados, entender quando e se distribuições de rótulos e características mudam etc.

Alegação

Monitoramentos de valores médios não contam toda a história porque presumem algumas coisas que não necessariamente refletem a realidade. Por exemplo: 

  • se há dados em falta, a maioria das ferramentas numéricas os ignora e calcula médias para os dados remanescentes (não nulos);
  • eles presumem que problemas de dados serão suficientemente grandes para alterar o valor médio de forma significativa. Por outro lado, alterações nas características podem modificar as médias bastante, mas não afetam percentuais mais altos, nos quais a maioria das decisões de modelo é tomada.
  • Eles presumem que as alterações em pontuações de modelo têm um relacionamento linear com as ações que serviram como base.

Para resumir, pode haver um problema que afeta seus dados de forma significativa, mas as médias de valores podem não sofrer nenhuma alteração e é por isso que você deve incluir outros ângulos.

Sugestões 

  • Monitore os percentuais de valores de características numéricos como 99°, 95°, 90°, além de 10°, 5° e 1°. Desta forma, você poderá detectar casos em que os exemplos finais mudam, mesmo quando o valor médio da característica não foi alterado. Isto é útil principalmente em casos em que a distribuição de dados está distorcida e/ou desbalanceada.
  • Monitore taxas de valores ausentes em todas as características. Isto precisa ser monitorado separadamente, já que uma grande quantidade de valores ausentes é um problema grave, mesmo quando a média dos valores não ausentes não mudou muito.
  • Divida o monitoramento em subgrupos para detectar falhas que afetam apenas alguns dos exemplos pontuados.

Conheça nossas oportunidades

Camadas de política/decisão precisam de monitoramento adicional

Contexto

O modelo é usado para tomar decisões (negar/aprovar empréstimos, exibir ou não um anúncio etc.) usando alguma forma de política

Você monitora modelos com base em uma perspectiva técnica (valores de característica, precisão, exatidão etc.), mas não é óbvio quando as decisões são feitas a partir daí (essa é a camada de política/decisão).

Alegação

Não é suficiente monitorar modelos com base em uma perspectiva técnica porque não fica claro para outras partes interessadas como isso afeta o negócio

É importante também monitorar as decisões usando o modelo para garantir que ele esteja cumprindo o valor de negócio esperado.

Sugestões

  • Monitore as decisões tomadas usando o modelo. Por exemplo: quantas pessoas conseguiram a aprovação de empréstimos com o modelo de risco diariamente? Quantas pessoas tiveram suas contas bloqueadas pelo modelo de fraude diariamente? Na maioria dos casos, é interessante monitorar tanto os valores absolutos quanto os relativos .
  • Certifique-se de ajustar o nível de granularidade dependendo do público-alvo: se seu modelo dá uma pontuação para um cliente diversas vezes, seu público-alvo pode estar mais interessado em métricas agregadas pelos clientes do que entidades individuais sendo pontuadas.
  • Se você está executando um modelo em tempo real, quantas decisões erradas foram tomadas devido a incompatibilidades de distorção entre treinamento e exibição? Você também deve monitorar isto.

Divida o monitoramento em subgrupos para obter mais detalhes

Contexto

Você é responsável por cuidar de modelos de aprendizado de máquina frequentemente usados para pontuar diversos exemplos individuais diariamente. 

Você monitora características/pontuações em painéis e há diversos padrões “interessantes” que deseja investigar, mas normalmente leva muito tempo para identificar os motivos de tais problemas.

Alegação

Uma forma de facilitar o entendimento de dados e/ou padrões de modelos é dividir o monitoramento de dados em subgrupos (subníveis dos dados sendo pontuados pelo modelo) e monitorá-los separadamente.

Isto é porque diversos problemas de dados têm um impacto significativo em alguns subníveis de exemplos, mas podem “desaparecer” porque seus impactos absolutos não são suficientes para serem observados ao olhar os valores agregados no conjunto de dados geral.

Sugestões

  • Em vez de olhar valores de pontuação/características agregados em conjuntos de dados, divida-os em subgrupos e os monitore em vez disso.
    • Por exemplo: se você tem um modelo de fraude, pode valer a pena dividir o monitoramento pelo tipo de dispositivo (web, celulares etc.) usado em cada exemplo pontuado.
  • Monitore também as contagens brutas de cada grupo (quantos exemplos cada um foram pontuados diretamente, qual foi a porcentagem etc.)

Codificação de característica apropriada torna o monitoramento mais fácil

Contexto

Características usadas em modelos normalmente são pré-processadas ou codificadas para permitir o uso em alguns classificadores. 

Isto é um problema às vezes, já que é difícil monitorar visualmente ou programaticamente características complexas e feitas com cuidado, mas que não são óbvias desde o começo.

Alegação

Ou codificar (ou decodificar) características com cuidado, você pode monitorar mais facilmente. Isto acontece porque estruturas de monitoramento são melhores com valores numéricos e categóricos. Se você usa tipos diferentes de características (como incorporações de palavras ou coordenadas de geolocalização), talvez seja melhor decodificá-las (como em linhas e nomes de cidades, respectivamente) para que você possa analisar essas questões com mais facilidade em relatórios e mapas.

Além disso, talvez você queira monitorar os valores originais (não processados, não codificados), já que isto torna mais fácil a comunicação com outras equipes e também a solução de problemas quando eles aparecem.

Sugestões

  • Monitore valores de inserção (ou seja, não necessariamente as características em si, mas as informações usadas para criar características) além das características em si. Isto é útil ao aplicar diversas transformações numéricas nelas.
  • Sempre que possível, codifique valores de características booleanas como números reais (1,0, 0,0 e nulo), para facilitar o monitoramento delas como variáveis numéricas normais (meios de extração e outras propriedades numéricas etc.) e reutilizar todas as ferramentas (como mapas) feitas pra eles.
  • Para características categóricas codificadas com estratégias, como one-hot encoding ou target-enconding, talvez seja melhor decodificá-las novamente para seus valores originais para monitorar as classes e não as categorias codificadas.

Consistência reduz a carga mental de monitoramento

Contexto

Você é responsável por manter/operar um ou mais modelos de aprendizado de máquina, sendo que cada um deles tem diversas características, usadas de forma distinta e tudo mais. 

Você tem à sua disposição diversos painéis e relatórios sendo gerados, mas o esforço necessário para analisá-los é muito grande e levará bastante tempo.

Alegação

É possível reduzir a carga cognitiva e o tempo necessário para analisar painéis e relatórios de monitoramento. 

Uma forma de fazer isso é por meio da consistência e padronização, para que custos de mudança de contexto possam ser minimizados e sua equipe possa ser mais eficiente.

Sugestões

  • Use uma única ferramenta para monitorar tudo. Se for possível, uma única ferramenta ou fornecedor para toda monitoração de modelos. Isto facilita a configuração compartilhada e o uso dos mesmos padrões em vários modelos.
  • Ordene as coisas de forma consistente. Por exemplo: ordene mapas de características de acordo com a importância da característica para que possa verificar rapidamente se há problemas graves que precisam ser investigados (ou simplesmente ordene alfabeticamente)
  • Nomeie as coisas de forma consistente: se você precisa nomear coisas como arquivos, conjuntos de dados, painéis, tabelas etc., certifique-se de seguir algum tipo de padrão (como <nome-da-equipe>-<nome-do-modelo>-<data>) para facilitar a automatização e configuração para toda a equipe.

Monitore tarefas/rotinas de monitoramento em si (meta monitoramento)

Contexto

Você usa rotinas auxiliares, tarefas em massa ou scripts ad-hoc para processar dados de registros de modelos. Você usa estas rotinas para analisar as características do modelo, além das pontuações e valores agregados dos resultados. Você também pode usar estas ferramentas para gerar alertas sob certas condições.

Alegação

Rotinas/tarefas de monitoramento de modelo em massa são apenas outros softwares e, normalmente, param de funcionar de vez em quando (alguém mudou o nome de uma tabela e o script não funciona, suas credenciais expiraram etc.). 

Se você conta com tarefas/rotinas/scripts de monitoramento e alerta para condições de problemas, a ausência de alertas pode levar você a acreditar que está tudo bem, quando na verdade as tarefas de monitoramento não foram executadas ou houve algum problema com elas. 

Você precisa monitorar as próprias tarefas de monitoramento para evitar esse problema (meta monitoramento).

Sugestões

  • Monitore os tempos de execução da tarefa. Tempos de execução cada vez maiores podem indicar que você precisará mudar a estratégia em breve. Já os curtos demais podem indicar que houve algum problema com a tarefa.
  • Use alertas no formato de pulsação. É possível adicionar um passo ao final de cada tarefa/script para enviar um ping para outro sistema. Alertas de pulsação são enviados quando algo não aconteceu. Por exemplo, se o back-end não recebeu um ping por mais de 24 horas.

Padrões para monitoramento em massa

Contexto

Você tem tarefas em massa que analisam dados de registros de modelos e calculam uma média agregada neles (valor médio de característica a cada dia, pontuações médias etc.), mas alguém precisa examinar os dados para ver se está tudo bem. 

Alegação

É fácil criar relatórios de monitoramento que são ignorados porque ninguém teve tempo de abrir os painéis/notebooks e observar os resultados. Aqui estão algumas formas de torná-los mais úteis e eficientes.

Sugestões

  • Faça com que as tarefas realmentemandem os resultados (gráficos, tabelas etc.) como uma mensagem para o seu e-mail ou canal do Slack ao final de cada execução. No campo da mensagem, inclua apenas as informações mais importantes.
    • A ideia é ter informações suficientes para que você possa entender rapidamente se há algum problema.
    • No campo da mensagem, inclua um link para os dados completos do relatório/painel para que as pessoas possam ver tudo, se necessário.
  • Escreva códigos que possam lidar com os dados históricos por padrão: isto facilita a reutilização do código para análises de históricos e para monitoração gradual (como as diárias).
  • Use linguagem corporativa sempre que possível, para que todas as partes interessadas (e não só as técnicas) possam entender o impacto dos modelos nas decisões corporativas.

Apenas modelos em tempo real: monitoramento de distorção entre treinamento e exibição

Contexto

Modelos usados para interferir em tempo real são normalmente treinados de acordo com dados históricos recuperados de uma base de dados, em massa. 

Isto cria o risco do trajeto dos dados usados para treinamento não ser o mesmo da interferência (normalmente chamadas de HTTP para serviços externos com o objetivo de obter características). Isto é chamado de distorção entre treinamento e exibição.

Alegação

Distorção entre treinamento e exibição é um grande risco a ser considerado ao implementar modelos em tempo real. Isto deve ser monitorado continuamente, pelo tempo em que o modelo estiver em funcionamento. 

As causas mais comuns de incompatibilidades são mudanças em serviços externos dos quais o modelo depende para obter dados de características em tempo real.

Sugestões

  • Monitore a taxa de compatibilidades perfeita entre fluxos em massa/tempo real (exemplo: você pode exibir “1” se for uma compatibilidade perfeita entre os dois fluxos e “0” se não houver) e monitorar este valor da mesma forma que monitora outras características. Desta forma, você poderá ver quanta distorção há por característica.
  • Monitore a magnitude das diferenças: para casos em que houve uma incompatibilidade entre os trajetos de dados em massa e em tempo real, qual a gravidade dela? Foi pouca ou grande diferença?
  • Também monitore as contagens: monitore quantos exemplos haviam em cada trajeto de dados em um dia. Isto é importante, já que alterações desconhecidas podem causar a pontuação de mais exemplos em tempo real do que o esperado. 

Apenas modelos em tempo real: padrões de alerta

Agora, temos um artigo dedicado sobre este assunto: Melhores práticas para aprendizado de máquina em tempo real: alertas

Contexto

Você criou alguns alertas em tempo real (e-mails, mensagens de Slack, notificações push em dispositivos móveis etc.) para lhe alertar sobre qualquer comportamento inesperado do modelo, como valores de características estranhos, características ausentes, pontuações muito altas/baixas etc.

Alegação

É muito fácil ficar com alertas que são muito chamativos (são exibidos com muita frequência e não são mais levados a sério) ou não funcionam (nunca são disparados, mesmo quando deviam).

Você precisa manter os alertas relevantes e fáceis de resultar em uma ação (incluindo informações suficientes para alguém saber se é um problema real).

Sugestões

  • Fique de olho em períodos estranhos, como de manhã cedo, fins de semana etc., já que são momentos em que você poderá receber menos exemplos pontuados por modelos e os alertas podem ser disparados pelo simples motivo da dimensão da amostra ser pequena.
  • Sempre inclua o prazo e os pontos específicos de dados usados para permitir que as pessoas analisem se é um falso positivo ou não. Ruim: “A característica X no modelo Y está grande demais”. Bom: “O valor médio da característica X no modelo Y nos últimos 15 minutos foi grande demais (o esperado era de 0,4 e 0,5, mas foi 100,0)”.
  • Se possível, inclua um link para o painel completo ou outro lugar onde você pode analisar dados mais completos e decidir se uma investigação é necessária.
  • Se possível, tenha algum tipo de guia de solução de problemas em mãos para que integrantes novos da equipe possam agir facilmente após os alertas.

Conclusão

Estas são algumas dicas que achamos úteis para monitorar diversos modelos de aprendizado de máquina (ML) aqui no Nubank. 

Eles são usados em diversos contextos de negócios (crédito, fraude, CX, operações etc.), e acreditamos que têm um grande alcance para serem usados em outras empresas também.

Conheça nossas oportunidades