Nesse artigo, vamos falar sobre os conceitos de monitoramento de modelos de machine learning e como o SageMaker Model Monitor pode nos ajudar com isso.

1. Introdução

Quando treinamos um modelo de ML e ele tem uma performance muito boa, geralmente, implantamos em produção. O modelo pode funcionar muito bem em produção por algum tempo, mas os usuários podem começar a observar que as previsões não estão fornecendo resultados muito confiáveis. Dessa forma, temos que investigar o que está acontecendo com o modelo, tentar achar onde está o problema, podendo estar no modelo ou nos dados.

No desenvolvimento de software tradicional, definimos a maior parte do projeto no inicio e, quando colocamos em produção, o nosso sistema geralmente funciona como determinamos. Quando falamos de modelos de machine learning (ML) é um pouco diferente, haja visto que não conseguimos garantir com certeza como o modelo irá performar, mas por meios de dados tentamos construir soluções estatísticas que tentam descrever ou prever comportamentos do nosso sistema. Essa é uma das principais diferenças entre desenvolvimento de software tradicional e o desenvolvimento de ML.

A etapa de monitoramento de um modelo faz parte do ciclo de vida do desenvolvimento de projetos de aprendizado de máquina. Essa fase tem como objetivo avaliar o desempenho dos nossos modelos em produção ao longo do tempo. Nós podemos acompanhar vários atributos, como: desvio de dados, métricas de performance, saúde do sistema físico (uso de CPU, memória etc), entre outros.

Dito isso, a Amazon tem a ferramenta Amazon SageMaker Model Monitor, que é integrado diretamente com o Amazon SageMaker. Essa ferramenta ajuda no monitoramento contínuo da qualidade dos modelos registrados no SageMaker em produção implantados como endpoints em tempo real. A qualidade dos dados dos modelos em produção é validada em relação aos dados que usamos como base(geralmente os dados de treinamento) e arquivos de estatísticas. Podemos criar alertas para que, quando ocorra qualquer desvio de dados, os usuários seja notificados desse evento por meio de um e-mail, SMS etc.

Por fim, nesse artigo vamos ver quais os principais fatores que afetam na performance de um modelo e como Amazon SageMaker Model Monitor pode nos ajudar com o monitoramento desses eventos.

2. O que devemos monitorar?

Depois das várias etapas para chegar em um modelo bom e implantando em produção, temos que agora monitorar o que esse modelo está entregando, qual valor ele está gerando, performance etc, pois muitas vezes um modelo ajuda na tomada de decisão de times de negócios, assim, temos que passar confiança no que ele tá gerando. Dessa forma, esses são alguns pontos que podemos monitorar em um projeto de machine learning:

2.1 — Saúde do sistema

Quando colocamos um modelo em produção, ele geralmente é consumido via API ou por algum processo em batch. Dessa forma, temos que acompanhar alguns indicadores de integridade do nosso sistema, como: utilização de memória e CPU, tempo de resposta etc.

O objetivo dessa métrica é acompanhar que o serviço está operacional e condições necessárias para uso.

2.2 — Data Drift

No monitoramento de data drift, acompanhamos as distribuições das variáveis que estão entrando no nosso modelo. Dessa forma, o quanto mais semelhante for a distribuição das entradas com os nossos dados de treinamento, melhor, porque isso represente que o modelo está recebendo dados parecidos com os que foram treinados. Quando as distribuições não são muito semelhantes, é um sinal que temos que retreinar ou mudar alguma etapa do pipeline do nosso modelo. O processo de drift nos dados é uma das principais razões pelas quais um modelo se degrada ao longo do tempo.

2.3 — Desempenho do modelo

A maneira mais básica para analisar se o modelo está funcionando bem é comparar as previsões feitas com os valores reais. Podemos usar as métricas que obtivemos no treinamento para usar como comparação, a fim de metrificar o desempenho. Se algum evento acontecer com a qualidade dos dados ou os padrões mudarem, as métricas provavelmente irão diminuir.

Contudo, nem sempre sabemos os resultados reais com tanta rapidez.

2.4 — Impacto do modelo nos negócios

Com essa métrica tentamos calcular o impacto do nosso modelo no negócio. Por exemplo, se construirmos um modelo para fazer um sistema de recomendação para um anuncio. Dessa forma, podemos verificar o impacto desse modelo acompanhando a taxa de cliques no anúncio, isso seria um bom indicador da eficiência do nosso modelo nos negócios.

3. Como o Amazon SageMaker pode nos ajudar no monitoramento de modelos?

A ferramenta da AWS que nos ajuda no monitoramento dos nossos modelos é o SageMaker Model Monitor. Ele monitora continuamente a qualidade dos nossos modelos de machine learning em produção. O Model Monitor do SageMaker é capaz de nos alertar quando há desvios na qualidade do modelo. É possível usar recursos de monitoramento pré-criados da ferramenta, que não precisam de codificação. Ele também tem a flexibilidade de monitorar modelos por meio de codificação também, a fim de habilitar uma análise mais personalizada. A detecção antecipada e automatizada desses desvios permite que nós tenhamos ações corretivas, como: retreino automatizado, correção de problemas de qualidades sem precisar monitorar os modelos manualmente e criar ferramentas adicionais.

Dito isso, vamos usar explorar um pouco essa ferramenta. Nesse artigo vamos usar um modelo já treinado. Esse modelo usa o algoritmo xgboost para fazer previsão de churn. Esse artigo tem como intuito focar no serviço de monitoramento do SageMaker. Todo o código e com mais detalhes vai estar no GitHub.

3.1 — Criando o Endpoint

Para habilitar a captura de dados para monitorar a qualidade dos dados do modelo, especificamos o parâmetro “DataCaptureConfig” (linha 28) na configurações do endpoint, como é mostrado acima. Esse parâmetro recebe uma variável dicionário, que é criada na linha 1. Dito isso, indicamos qual a porcentagem de requisições queremos capturar, o caminho do S3 que vai armazenar esses dados, se vamos capturar input ou output (nesse caso, estamos capturando input e output) e especificamos quais tipos de dados vamos capturar. Por fim, criamos as configurações do endpoint e o criamos.

Agora, temos um endpoint pronto para capturar todas as requisições que ele irá receber.

3.2 — Criando linha base e restrições para o modelo

Os cálculos da linha de base e restrições são necessários para definir um padrão de dados que deve usado para detectar o desvio de dados e outros problemas de qualidade de dados podem ocorrer.

Dito isso, o Model Monitor fornece um contêiner interno que oferece a capacidade de sugerir automaticamente as restrições para a entrada JSON e CSV, que é criado na linha 4 no trecho de código acima, que recebemos como argumentos qual a role e informações de infraestrutura desse container.

Com o nosso container criado, vamos criar nossa linha base, que começa a ser criado na linha 12. Usamos os dados de treinamento para definir nossa linha base (linha 13). O esquema dos dados de inferência devem corresponder exatamente aos dados que foram definido como base. Na linha 14, definimos qual o formato dos dados. Por fim, definir onde salvaremos os nossos dados estatísticos.

Depois que iniciarmos o nosso container de monitoramento e carregar a nossa ultima execução, vamos ter algumas estatísticas descritivas bem importantes de cada atributo do nosso modelo, como: média, desvio padrão, mínimo, máximo, distribuição e muito mais, como é mostrado na imagem acima. Além disso, podemos colocar essas informações em gráficos também, para ter uma melhor visualização

Então, quando geramos nossa linha base para os nossos dados, criamos automaticamente nossas restrições. Esse dado de restrições vai ser para detectar anomalias na qualidade dos nossos dados, então vamos ter informações sobre porcentagem de valores nulos, tipo do dados etc, como é mostrado na imagem a seguir.

3.3- Criando agendamento para o nosso monitoramento

Quando criamos uma instância de monitoramento, podemos criar um agendamento para ele, a fim de manter um monitoramento contínuo do nosso modelo. Então, no trecho de código mostrado acima, criamos o nosso agendamento para o modelo desse artigo. Dito isso, passamos os parâmetros: o nome que queremos para o nosso agendamento, qual o endpoint que queremos monitorar, onde queremos salvar os reports, quais são nossas estatísticas e regras que usaremos como base, a expresão cron do nosso agendamento(no exemplo, tá executando a cada uma hora) e habilitamos que as métricas desse monitoramento sejam disponibilizadas no cloudwatch.

3.4 — Analisando o relatório do monitoramento

Depois que começamos a monitorar o nosso modelo, então, temos três resultados para a nossa execução:

º Completed — Quando a execução do nosso monitoramento foi concluída e nenhum problema foi encontrado no relatório.

º CompletedWithViolations — A execução foi concluída com sucesso, mas têm atributos que violaram nossas restrições.

º Failed — A execução do monitoramento falhou.

Se olharmos as execuções que fizemos, podemos ver que a nossa última execução está com status “CompletedWithViolations”, o que significa que os dados que entraram no nosso modelo não obedeceram nossas regras geradas anteriormente. Dito isso, o monitoramento também gera relatórios com o intuito de informar quais atributos estão com problemas de qualidade dos dados e quais são as violações.

Podemos ver que os problemas relatados são que vieram valores que não correspondem a tipagem dos dados, pois, conforme os dados que foram definidos como base, essas features não recebiam valores nulos. Se houver violações no tráfego de inferência, segundo a documentação, podemos ter as seguintes violações:

º data_type_check

º completeness_check

º baseline_drift_check

º missing_column_check

º extra_column_check

º categorial_values_check

3.5 — Gerando alertas

Na seção 3.3, quando criamos o nosso agendamento de monitoramento, habilitamos as nossas métricas no CloudWatch. O CloudWatch disponibiliza métricas bem úteis para o acompanhamento do nosso modelo. Conforme a documentação, o contêiner de monitoramento gera as seguintes métricas para os nossos atributos no CloudWatch:

º Max;

º Min;

º Sum;

º SampleCount;

º Average;

º Completeness;

º Baseline Drift;

As cinco primeiras métricas, cada atributo do modelo é identificado da seguinte forma: feature_data_{feature_name} . Para a Completeness, é identificado por feature_non_null_{feature_name}. E, por fim, a métrica de data drift é identificado por feature_baseline_drift_{feature_name}.

Dito isso, com todas essas métricas geradas automaticamente, podemos criar alarmes no CloudWatch para quando algum evento acontece. Por exemplo:

No exemplo acima, criamos um alarme para a métrica feature_baseline_drift_Night Calls, essa métrica é dada pelo o calculo de drift no atributo Night Calls do nosso modelo (na documentação é demonstrada como é o cálculo de drift). Esse alarme tem como ação chamar um tópico SNS (linha 16) , que é o serviço de mensagem da AWS, nele podemos mandar um e-mail, por exemplo. Dessa forma, estamos gerando o nosso sistema de alerta. Poderíamos, invés de chamar um tópico SNS, chamar o pipeline de treinamento do modelo. Assim, toda vez que acontecesse algum alarme, retreinariamos o modelo. Se tiverem interesse em como construir esse pipeline, aqui eu mostro como faz um.

4. Conclusão

Nesse artigo, vimos que, além de ter que construir um bom modelo, temos que desenvolver várias ferramentas para garantir a qualidade do funcionamento do nosso modelo, e o monitoramento é uma dessas ferramentas. A etapa de monitoramento de um modelo faz parte do ciclo de vida do desenvolvimento de projetos de aprendizado de máquina. O monitoramento é essencial para o bom funcionamento do projeto, haja visto que as empresas usam cada vez mais dados e modelos machine learning para as tomadas de decisão. Dessa forma, é importante identificar desvio na distribuição dos dados e evitar a baixa a performance de um modelo para não impactar na finalidade dele. Por fim, vimos como a ferramenta Amazon SageMaker Monitor pode nos ajudar com isso, pois tem funcionalidades bem legais e úteis para o monitoramento de um modelo de machine learning em tempo real.