Monitorando Modelos de Aprendizado de Máquina em Produção

Depois de implantar seu modelo de aprendizado de máquina na produção, logo fica claro que o trabalho não acabou.

Photo by Ibrahim Boran on Unsplash

Disclaimer

Esse post é uma tradução e localização e foi originalmente escrito por Chris Samiullah, que me autorizou traduzi-lo para Português. É possível ler o post original aqui, além de conhecer outros trabalhos do autor.

This post is a translation and localization and was originally written by Chris Samiullah, who authorized me to translate it into Portuguese. You can read the original post here, as well as learn about other works by the author.

Como saber modelos estão realmente se comportando como você espera? E se na próxima semana/mês/ano o comportamento do cliente mudar e os dados de treinamento ficarem desatualizados? Em muitos aspectos, a jornada está apenas começando e esses são desafios complexos, além de serem agravados pelo fato de que o monitoramento do aprendizado de máquina é um campo em rápida evolução em termos de ferramentas e técnicas. Como se isso não bastasse, o monitoramento é um esforço verdadeiramente interdisciplinar, mas o termo “monitoramento” pode significar coisas diferentes em ciência de dados, engenharia, DevOps e nas áreas de negócio.

Dada essa combinação difícil de complexidade e ambigüidade, não é surpresa que muitos cientistas de dados e engenheiros de aprendizado de máquina (ML) não tenham certeza sobre como conduzir a etapa de monitoramento.

Este guia abrangente tem como objetivo, no mínimo, alertá-lo qual a origem da complexidade no monitoramento de modelos de aprendizado de máquina em produção, por que isso é importante e, além disso, fornecer um ponto de partida prático para implementar suas próprias soluções de monitoramento de ML. Caso o leitor esteja interessado em uma abordagem mais pratica, tutoriais e projetos, é possivel verificar tudo isso em nosso curso online dedicado ao tópico: Testing & Monitoring Machine Learning Model Deployments.

Esta postagem não é destinada a iniciantes, mas não se preocupe. Você deve ser capaz de acompanhar se estiver preparado para seguir os vários links.

Conteúdo

1. O ciclo de vida em uma solução de ML.
2. O que torna difícil monitorar uma solução de ML.
3. Por que você precisa de monitoramento.
4. Princípios fundamentais para monitorar uma solução de ML.
5. Compreendendo o espectro do gerenciamento de risco de ML.
6. Monitoramento e Ciência de dados.
7. Monitoramento operacional.
8. Unindo Ops e DS — Métricas com Prometheus e Grafana.
9. Unindo Ops e DS — Logs.
10. A mudança de panorama.

1. O ciclo de vida em uma solução de ML

O monitoramento de modelos de aprendizado de máquina refere-se às maneiras como rastreamos e entendemos o desempenho de nosso modelo na produção, tanto de uma perspectiva operacional quanto de ciência de dados. O monitoramento inadequado pode levar a modelos incorretos deixados sem verificação na produção, modelos obsoletos que param de agregar valor ao negócio ou bugs sutis em modelos que aparecem com o tempo e nunca são detectados. Quando o ML está no centro do seu negócio, deixar de detectar esses tipos de bugs pode conduzi a um cenário realmente critico — principalmente se sua empresa operar em um ambiente regulamentado.

Martin Fowler popularizou o conceito de Continuous Delivery for Machine Learning (CD4ML), e o diagrama para esse conceito oferece um guia visual útil para o ciclo de vida do ML e onde o monitoramento entra em ação:

Fonte: martinfowler.com

Este diagrama descreve seis fases distintas no ciclo de vida de um modelo de ML:

1. Construção do modelo: Entendimento do problema, preparação de dados, feature engineering e prototipação do código inicial. Artefatos típicos são notebooks Jupyter com de códigos.
2. Avaliação e experimentação de modelos: Seleção de features, ajuste de hiperparâmetros e comparação da eficácia de diferentes algoritmos em um determinado problema. Os artefatos típicos incluem notebooks com estatísticas e gráficos avaliando pesos de recursos, acurácia, precisão e Curvas ROC.
3. Produtização do Modelo: Preparar o código de utilizado na etapa da prototipação e ajusta-lo para que o mesmo possa ser implantado. Os artefatos típicos são códigos de nível de produção, que em alguns casos estarão em uma linguagem de programação e/ou estrutura completamente diferente.
4. Testes: Garantir que o código de produção se comporte da maneira que esperamos e que seus resultados correspondam aos que vimos durante a fase de avaliação e experimentação do modelo. Os artefatos típicos são casos de teste.
5. Implantação: Colocar o modelo em produção, onde ele pode começar a agregar valor atendendo às previsões. Artefatos típicos são APIs para acessar o modelo.
6. Monitoramento e Observação: A fase final, em que garantimos que nosso modelo está fazendo o que esperamos na produção. O foco desse artigo.

No diagrama mostrado anteriormente, observe o aspecto cíclico, onde as informações coletadas na fase final de “Monitoramento e Observação” (mais sobre observação em breve) retornam para a primeira etapa, a de “Construção de Modelo”. Para a maioria das empresas, este é um processo não automatizado de avaliar o impacto de um modelo de uma perspectiva de negócios e, em seguida, considerar se o modelo existente precisa ser atualizado, abandonado ou pode se beneficiar de um modelo complementar. Em empresas mais avançadas, pode significar que os dados coletados durante a fase de monitoramento alimentam diretamente os dados de treinamento para atualizações de modelo de maneira automatizada (o que traz consigo muitos desafios adicionais que discutiremos em breve).

Você pode considerar as duas primeiras fases do diagrama (“construção de modelo” e “avaliação de modelo”) como o ambiente de pesquisa, normalmente o domínio dos cientistas de dados, e as últimas quatro fases são mais o domínio da engenharia e DevOps, embora essas distinções variem de uma corporação para outra.

Se você não tem certeza sobre o que envolve a fase de implantação, existe uma postagem sobre esse tópico aqui.

Cenários de monitoramento

Fonte: https://christophergs.com/

O primeiro cenário é simplesmente a implantação de um modelo totalmente novo. O segundo cenário é quando substituímos completamente este modelo por um modelo totalmente diferente. O terceiro cenário (à direita) é muito comum e implica em fazer pequenos ajustes em nosso modelo ativo atual.

Digamos que temos um modelo em produção e uma variável se torna indisponível, então precisamos implementar novamente esse modelo sem esse recurso, ou alternativamente, desenvolvemos uma super feature que acredita-se ser incrivelmente preditiva e queremos reimplantar nosso modelo, mas agora tomando esse nova feature como uma entrada adicional.

Independentemente da situação, a etapa de monitoramento é como validamos se as alterações do nosso modelo estão apresentando o efeito desejado, que é o que nos preocupa em última análise. A única exceção a essa regra são as implantações de modelos sombra ou shadow models, que são explicadas neste post. Mas antes de nos aprofundarmos nas especificidades do monitoramento, vale a pena construirmos um contexto e discutirmos alguns dos desafios inerentes aos sistemas de ML.

2. O que torna difícil monitorar uma solução de ML

Soluções de aprendizado de máquina têm todos os desafios de código tradicional, além de uma série adicional de considerações específicas do aprendizado de máquina. Isso está bem documentado no artigo do Google “Hidden Technical Debt in Machine Learning Systems”

Um ponto importante a se esclarecer com relação ao artigo mencionado acima é que, ao falarmos sobre modelos de aprendizado de máquina em produção, estamos falando sobre soluções de ML.

The model is a tiny fraction of an overall ML system — Sculley et al. 2015

Fonte: Sculley et al. 2015

Quando se trata de uma solução de ML, nos preocupamos fundamentalmente em rastrear o comportamento do sistema. Isso se resume a três componentes:

Fonte: https://christophergs.com/

• Código (e configuração)
• Modelo (requisito específico da solução de ML)
• Dados (requisito específico da solução de ML)

Temos dois componentes adicionais a serem considerados em uma solução de ML, dependência de dados e o modelo. Ao contrário dos sistemas de software tradicionais, o comportamento de uma solução de ML é regido não apenas por regras especificadas no código, mas também pelo comportamento aprendido pelo modelo a partir dos dados. Além disso, para tornar as coisas mais complexas, as entradas de dados são instáveis, talvez mudando com o tempo.

Sem uma maneira de entender e rastrear essas alterações de dados (e, portanto, do modelo), é quase que impraticável o entedimento da sua solução como um todo.

Mas não termina por aí. Isso não é tão simples quanto “OK, agora temos duas novas dimensões a considerar” (o que por si só é bastante desafiador). O código e a configuração também assumem complexidade e sensibilidade adicionais em um sistema de ML devido a alguns fatores:

• Emaranhamento: Quando um recurso de entrada é alterado, então a importância, pesos ou o uso das demais features pode mudar também. Isso também é conhecido como o problema “mudar qualquer coisa muda tudo”. A etapa de feature engineering bem como a etapada de feature selection de uma solução de ML precisam ser testadas com muito cuidado.
• Configuração: Como os hiperparâmetros, versões e recursos do modelo são frequentemente controlados na configuração do sistema, o menor erro aqui pode causar um comportamento radicalmente diferente da solução, que por sua vez não será detectado com os testes de software tradicionais. Isso acaba se tornando bastante frequente em sistemas onde os modelos são constantemente iterados e sutilmente alterados.

Felizmente, começa a ficar claro que as soluções de ML são complexas em sua implementação. Ainda assim, um outro desafio que pode ser levado em consideração é o grande número de equipes envolvidas na solução.

O Desafio da responsabilidade

Soluções de ML abrangem várias equipes (também podem incluir engenheiros de dados, DBAs, analistas etc.):

Antes de continuarmos discutindo a etapa de monitoramento, é importante mencionar que essa etapa tem conotações diferentes em diferentes partes de uma organização. Logo, em soluções de ML, é necessário em mente duas perspectivas a saber:

Cientistas de dados: Uma vez que já ficou claro que o foco desse artigo é o monitoramento de pós-produção e não avaliação de pré-implantação (que é onde olhamos as distribuições de forma prévia, além de métricas similares no ambiente de pesquisa), o foco aqui é em testes estatísticos do modelo em suas entradas e saídas (mais sobre as especificações na seção 6).

Engenheiros e DevOps: Aqui a palavra “monitoramento”, faz referência a integridade do sistema, latência, memória/CPU/utilização de disco (mais detalhes na seção 7).

Enquanto no desenvolvimento de software tradicional as etapas de monitoramento e observação tendem a cair no DevOps, em uma solução de ML é quase improvável que sua equipe de DevOps tenha a experiência necessária para monitorar corretamente os modelos de ML (a menos que você tenha as funções de engenheiro de DevOps e Cientista de Dados sendo desempenhadas pela mesma pessoa, a quem você deve se agarrar e dar um aumento). Logo, podemos concluir que:

1. Toda a equipe precisa trabalhar em conjunto no monitoramento e falar a língua uns dos outros para que a solução como um todo seja eficaz.
2. Que é importante definir bem esses termos para evitar confusão.

Toda essa complexidade agrupa uma série de complexidades caso as equipes pensem no monitoramento do modelo de forma isolada após a etapa de implantação.

O monitoramento deve ser planejado juntamente com a solução durante a etapa de produtização do ciclo de vida da solução de ML (junto com os testes). Nesse cenário, atividades como a manutenção contínua do sistema, as atualizações, experimentos, a auditoria e as mudanças sutis de configuração que farão com que o débito técnico e os erros se acumulem. Porém, antes de prosseguirmos, vale a pena considerar as implicações potenciais de não monitorar.

3. Por que é necessário monitorar

“Ao falhar em se preparar, você está se preparando para falhar” — Benjamin Franklin

O monitoramento deve ser projetado para fornecer avisos antecipados sobre uma série de coisas que podem dar errado com um modelo de ML em produção. Entre esses erros podemos citar:

Distorções nas distribuições

As distorções de dados ocorrem quando os dados de treinamento do nosso modelo não são representaçãoes válidas dos dados oriundos do mundo real. Ou seja, os dados que usamos para treinar o modelo no ambiente de pesquisa ou produção não representam os dados que realmente obtemos em nossa solução de ML ativa.

Existem vários motivos pelos quais isso pode acontecer:

• Projetamos os dados de treinamento incorretamente: As distribuições das variáveis ​​em nossos dados de treinamento não correspondem à distribuição das variáveis ​​nos dados do mundo real.
• Uma feature não está disponível em produção: Isso geralmente significa que precisamos remover essa feature, alterá-la por outra semelhante que existe na produção ou recriar essa feature combinando outros recursos existentes no ambiente produção.
• Incompatibilidade nos dados de prototipação e dados reais: Os dados que usamos para treinar nossos modelos no ambiente de pesquisa vêm de uma fonte e os dados do mundo real vêm de uma fonte diferente. Isso pode significar que as variáveis ​​podem não ser geradas de forma idêntica, então, embora o pipeline retorne a mesma previsão para os mesmos dados de entrada (o que significa que nossos testes diferenciais passam), diferentes fontes de dados podem levar a diferentes valores utilizando as mesmas features, o que resultará em diferentes previsões.
• Dependências de dados: Nossos modelos podem ingerir variáveis ​​que são criadas ou armazenadas por outros sistemas (internos ou externos). Esses sistemas podem mudar a maneira como seus dados são gerados, e infelizmente, é bem comum que tais mudanças não sejas comunicadas com clareza. O efeito indireto é que as variáveis ​​que são produzidas hoje não são equivalentes às que eram produzidas há alguns anos. A implementação do código de uma feature muda, produzindo resultados ligeiramente diferentes, ou a definição da própria feature pode mudar. Por exemplo, um sistema externo pode ajustar a idade para votar de 18 para 16. Se a idade para votar for uma feature com alto poder preditivo no modelo, isso mudará suas previsões.

Modelo Obsoleto

• Mudanças no ambiente: Se usarmos dados históricos para treinar os modelos, precisamos antecipar que a população e seu comportamento podem não ser os mesmos nos tempos atuais. Por exemplo, se treinarmos nossos modelos financeiros usando dados da época da recessão, esse modelo pode se tornar ineficaz para prever a inadimplência em momentos em que a economia está saudável.
• Mudanças no comportamento do consumidor: As preferências do cliente mudam, assim como as tendências da moda, da política, da ética, etc. Particularmente em sistemas de recomendação, este é um risco que deve ser monitorado constantemente.
• Cenários adversos: Os famosos Bad Users (fraudadores, criminosos, governos estrangeiros), podem buscar ativamente os pontos fracos de um modelo e ajustar seus ataques a esses pontos. Freqüentemente, trata-se de uma contínua “corrida armamentista”.

Loops de Feedback Negativos

Feedback Loops, tonam-se uma questão complexa quando os modelos são treinados automaticamente nos dados coletados na produção. Se esses dados forem distorcidos/corrompidos de alguma forma, os modelos subsequentes treinados nesses dados terão um desempenho insatisfatório. Nesse link Dan Shiebler da equipe Cortex AI do Twitter descreve este desafio (mais especificamente no minuto 37:00):

“Precisamos ter muito cuidado sobre como os modelos que implantamos afetam os dados que utilizamos para treinamento […] um modelo que está tentando mostrar aos usuários um conteúdo que o próprio modelo presumiu que tais usuarios vão gostar está corrompendo a qualidade dos dados de treinamento que alimentam o próprio modelo, além de alterar a distribuição desses dados.”

Vale a pena ler este artigo, que cobre exemplos de desafios relacionados, como o label concept drift.

4. Princípios fundamentais para monitorar uma solução de ML

Embora o aprendizado de máquina acadêmico tenha suas raízes na pesquisa da década de 1980, a implementação prática de sistemas de aprendizado de máquina no ambiente de produção ainda é relativamente nova. Com algumas exceções, a maioria das empresas de tecnologia só utiliza soluções de ML/AI em escala há alguns anos, e muitas estão apenas começando a longa jornada. Isso significa que:

• Os desafios são muitas vezes mal compreendidos ou completamente esquecidos.
• As estruturas e ferramentas estão mudando rapidamente (tanto para ciência de dados quanto para MLOps).
• As melhores práticas costumam ser abordagens cinza.
• Os requisitos regulamentares estão mudando o tempo todo (LGPD).

Os pontos listados acima são recorrentes na etapa de monitoramento, o que talvez explique por que essa etapa é tão frequentemente negligenciada.

Existem alguns papers detalhando as melhores práticas em torno de design de sistema, processos, testes e monitoramento escritos por empresas com experiência em implantações de ML em grande escala. Analisar previamente temas e problemas comuns pode economizar para uma organização enormes quantidades de sangue, suor e lágrimas. Duas das empresas mais experientes na área de ML, Google e Microsoft, publicaram artigos nesta área com o objetivo de ajudar outras pessoas que enfrentam desafios semelhantes. Os papers são:

1. The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction (2017) Breck et al. (Google)
2. Software Engineering for Machine Learning: A Case Study (2019) Amershi et al. (Microsoft)

O artigo do Google se concentra mais em estratégias de teste e monitoramento de soluções de ML que podem ser empregadas para melhorar esses sistemas em termos de confiabilidade, reduzindo o débito técnico e diminuindo a carga de manutenção de longo prazo. O artigo do Google é estruturado em torno de 28 testes, que praticamente são um apanhado de pontos a serem considerados para avaliar o quão pronto um determinado sistema de aprendizado de máquina está para produção. Esses testes são “extraídos da experiência com uma ampla gama de sistemas de ML de produção”.

O artigo da Microsoft tem uma visão mais ampla, examinando as práticas recomendadas em torno da integração de recursos de IA ao software. O documento apresenta os resultados de uma pesquisa com cerca de 500 engenheiros, cientistas de dados e pesquisadores da Microsoft que estão envolvidos na criação e implantação de sistemas de ML e fornece insights sobre os desafios identificados.

Ambos os artigos destacam que os processos e padrões para a aplicação de técnicas tradicionais de desenvolvimento de software, como teste e operacionalização geral dos estágios de um sistema de ML, ainda não estão bem estabelecidos.

Pontos de destaque relacionados ao monitoramento que os artigos mencionados destacam.

Segundo Breck et al., 2017:

• Monitoramento 1: Mudanças de dependência resultam em alertas
• Monitoramento 2: O estado dos dados deve ser o mesmo no treinameto assim como na predição.

“Pode ser difícil monitorar com eficácia o comportamento interno de um modelo treinado para corrigi-lo posteriormente, mas os dados de entrada devem ser o mais transparente possível. Consequentemente, analisar e comparar conjuntos de dados é a primeira linha de defesa para detectar problemas que demonstrem que o mundo está mudando, e de maneira que possa confundir um sistema de ML. ”

• Monitor 3: As features utilizadas no treinamento e na inferencia devem apresentar os mesmos valores — Training/Serving Skew.
• Monitor 4: Os modelos não não devem estar muito desatualizados.
• Monitor 5: O modelo é numericamente estável.
• Monitor 6: O modelo não apresentou regressões dramáticas ou de vazamento na velocidade de treinamento, latência de serviço, taxa de transferência ou uso de RAM.
• Monitor 7: O modelo não apresentou uma regressão na qualidade da predição dos dados inferidos.

Talvez o teste mais importante e menos implementado seja o de Training/Serving Skew (Monitoramento 3). Esse tipo de erro é responsável por problemas de produção em uma ampla faixa de equipes e, ainda assim, é um dos testes menos implementados . Em parte porque é difícil […].

Apesar de não apresentar uma ordem de priorização nos monitoramentos listados, o paper do Google tem uma chamada clara para a ação, especificamente aplicando seus testes como uma lista de verificação. Concordo plenamente com isso, bem como com aqueles que estejam familiarizados com o cheklist de Atul Gawande.

É importante observar que muitas dessas práticas recomendadas dependem da reprodutibilidade, que Soledade Galli e eu discutimos nesta palestra

5. Compreendendo o espectro de gerenciamento de risco de ML

Em última análise, todos os testes e monitoramentos se resumem em gerenciamento de risco. Ambas são técnicas que usamos para aumentar nossa confiança de que a funcionalidade do sistema acontecerá como esperamos, mesmo quando fazemos alterações no sistema. Existe assim, um espectro de gerenciamento de risco. Em uma extremidade desse espectro, temos o sistema sem testes e sem monitoramento. Este é um sistema com perspectivas futuras incertas (e que dificilmente entrará em operação), mas também é um sistema de fácil manutenção.

Na outra extremidade, temos o sistema amplamente testado com todas as configurações de monitoramento disponíveis. Este é um sistema em que temos um nível muito alto de confiança em seu comportamento, mas que possui um alto custo de manutenção. Desta forma, o teste e o monitoramento apresentam um trade-off. Caso tenha pouca atenção, o sistema estará vunerável. Caso tenha uma ênfase muito grande, mal conseguirá se mover.

Observe também que o valor dos testes e do monitoramento fica cada vez mais aparente com a mudança. A maioria dos Sistemas de ML muda o tempo todo — as empresas crescem, as preferências do cliente mudam e novas leis passam a vigorar.

Fonte: Imagem adaptada da série Testing in Production de Cindy Sridharan.

A figura acima detalha toda a gama de técnicas de mitigação de risco pré e pós-produção que você tem à sua disposição.

Quando falamos em monitoramento, estamos focados nas técnicas de pós-produção. Nosso objetivo é identificar mudanças no comportamento do nosso sistema de ML que conflitam com nossas expectativas.

Em termos gerais, podemos categorizar as maneiras pelas quais nosso sistema de ML pode dar errado em dois grupos:

• Problemas de ciência de dados (monitoramento de dados, monitoramento de previsão).
• Problemas operacionais (monitoramento do sistema em si).

Fonte: Breck et al. (2017)

Como veremos nas próximas seções, para soluções eficazes, essas duas áreas precisam estar alinhadas, mas, à medida que estamos ganhando familiaridade, é útil primeiro considerá-las individualmente.

6. Monitoramento e Ciência de Dados

Naturalmente, estamos interessados na precisão de nosso(s) modelo(s) no ambiente de produção. No entanto, em muitos casos, não é possível saber a precisão de um modelo imediatamente.

Considere o caso de um modelo de detecção de fraudes: sua precisão de previsão só pode ser confirmada em novos casos reais se ocorrer uma investigação aprofundada ou se algumas outras verificações forem realizadas (como uma verificação cruzando dados de clientes com fraudadores conhecidos).

Desafios semelhantes se aplicam em muitas outras áreas onde não recebe-se feedback imediato (por exemplo, previsão no risco de doenças, previsão no risco de crédito, valores futuros de propriedade, previsão do mercado de ações). Dadas essas restrições, se faz lógico monitorar os valores de algum tipo de proxy para modelar a precisão na produção, especificamente um proxy pode ser:

• A distribuição de previsão do modelo (algoritmos de regressão) ou frequências (algoritmos de classificação).
• Distribuição de entrada do modelo (features numéricas) ou frequências (features categóricas), bem como verificações de valores ausentes.
• Versões do modelo.

Monitoramento de entrada do modelo

Dado um conjunto de valores esperados para uma feature de entrada, podemos verificar se:

• a) Os valores de entrada estão dentro de um conjunto permitido (para entradas categóricas) ou faixa (para entradas numéricas)
• b) As frequências de cada valor dentro do conjunto de dados estão alinhadas com o que já vimos no passado.

Por exemplo, para um dado de entrada do modelo que faz menção ao “estado civil”, verificaríamos se as entradas se enquadram nos valores esperados mostrados nesta imagem:

Fonte: https://christophergs.com/

Dependendo da configuração do modelo, permitiremos que certos recursos de entrada sejam nulos ou não. Isso é algo que é possível monitorar. Se os recursos que geralmente esperamos que não sejam nulos começarem a mudar, isso pode indicar uma distorção dos dados ou uma mudança no comportamento do consumidor, o que seria motivo para uma investigação mais aprofundada.

Monitoramento de Predição de Modelo

Em um processo automatizado (mais sobre isso nas próximas seções) ou manual, podemos comparar nossas distribuições de previsão de modelo com testes estatísticos:

Estatística básica: Mediana, Média, Desvio padrão, valores máx. /mín.

Por exemplo, se as variáveis apresentam uma distribuição normal, esperaríamos que os valores médios estivessem dentro do erro padrão do intervalo médio. É claro que esta é uma abordagem estatística muito simplista.

Fonte: https://christophergs.com/

Versões do modelo

Esta é uma área básica a ser monitorada que ainda é frequentemente negligenciada — o intuito aqui é ter certeza de que é possível rastrear facilmente qual a versão do modelo implantada está gerando erros de configuração.

Técnicas avançadas
Também podemos implementar testes estatísticos completos para comparar a distribuição das features. Qual teste? Isso depende das características das features. Se as features forem normalmente distribuídas, poderíamos fazer um Teste t ou ANOVA, se não forem, talvez testes não paramétricos como Kruskall Wallis ou o Kolmogorov Smirnov sejam mais adequados. Aqui, queremos comparar variável por variável se a distribuição da features nos dados de treinamento é semelhante a distribuição dessa mesma features na produção.

De forma prática, implementar testes estatísticos avançados em um sistema de monitoramento pode ser difícil, embora seja teoricamente possível. O mais comum a se fazer é automatizar testes estatísticos básicos (por exemplo, o desvio padrão de entradas/saídas) ao longo do tempo e fazer testes manuais ad-hoc para aplicar verificações mais avançadas. Agora vamos nos aprofundar nas opções de automação.

7. Monitoramento Operacional

O monitoramento no campo da engenharia de software é uma área muito mais bem estabelecida e faz parte do Site Reliability Engineering (SRE) — ou em tradução literal, Confiabilidade do Sistema. Um ótimo livro de referência (gratuito) para este é o Manual SRE do Google. As questões operacionais em torno do nosso Sistema de ML consistem nas seguintes áreas:

• Desempenho do sistema (Latência).
• Desempenho do sistema (IO/Memória/Utilização de disco).
• Confiabilidade do sistema (Tempo de atividade).
• Auditabilidade (Embora isso também se aplique ao modelo em si).

Na engenharia de software, quando falamos sobre monitoramento, estamos falando sobre eventos. Os eventos podem ser quase tudo, incluindo:

• Receber uma solicitação HTTP.
• Enviar uma resposta HTTP 400.
• Inserir uma função (que pode conter código ML ou não).
• Executar a instrução else de uma instrução if.
• A saída de uma função.
• Um usuário fazendo login.
• Gravar dados no disco.
• Ler dados da rede.
• Solicitar mais memória do kernel.

Todos os eventos também têm contexto. Por exemplo, uma solicitação HTTP terá o endereço IP de onde vem e vai, a URL solicitada, os cookies configurados e o usuário que fez a solicitação. Os eventos que envolvem funções têm a pilha de chamadas das funções acima deles e tudo o que acionou essa parte da pilha, como uma solicitação HTTP. Ter todo o contexto para todos os eventos seria ótimo para depurar e entender o desempenho de seus sistemas em termos técnicos e comerciais, mas essa quantidade de dados não é tão prática de se processar e armazenar.

Portanto, o monitoramento é dividido em diferentes áreas, cada uma delas relacionada à redução do volume de dados de forma que essa atividade se torne uma tarefa viável de se desempenhar.

Os chamados três pilares de observação descrevem as principais maneiras pelas quais podemos considerar o contexto do evento e reduzir os dados do contexto em algo útil. Eles são:

1. Métricas.
2. Histórico.
3. Traços Distribuídos

Com alguns membros extras ocasionais, dependendo de quem você pergunta, como (4) Criação de perfil (5) Alerta/Visualização (embora isso geralmente seja incorporado em métricas/logs)

Monitoramento vs. Observação

Então, qual é a diferença entre monitoramento e observação?

De forma simples, a observação é a sua capacidade de responder a quaisquer perguntas sobre o que está acontecendo no interior do seu sistema apenas observando o exterior do sistema. Para uma grande história de observação, eu recomendo este artigo da Cindy Sridharan, bem como seu livro Distributed Systems Observability

Neste ponto, um diagrama de Venn pode expressar melhor o entendimento:

Fonte: https://christophergs.com/

Este diagrama enfatiza dois momentos:

• Testes — O melhor esforço de um time para gatantir a verificação e a correção.
• Monitoramento — O melhor esforço de um time para rastrear falhas previsíveis.

A observação é um conjunto muito mais amplo, que ainda assim engloba as atividades de monitoramento e testes, fornecendo informações sobre modos de falha imprevisíveis que não puderam ser monitorados ou testados.

Monitoramento e alertas são conceitos inter-relacionados que juntos formam a base de um sistema de monitoramento. Um sistema de monitoramento é responsável por armazenamento, agregação, visualização e fornecer respostas automatizadas quando os valores atendem a requisitos específicos.

Fonte: https://christophergs.com/

Quando se trata de monitorar sistemas de ML, as especificações de rastreamento distribuído tendem a ser muito semelhantes à configuração de um sistema que não é de ML, que por sua vez não fazem parte do escopo desse artigo. Para métricas e logs, no entanto, há algumas considerações do sistema de ML que valem a pena ser mencionadas.

8. Unindo Ops e DS — Métricas com Prometheus e Grafana

As métricas representam as medidas brutas da utilização de recursos ou comportamentos que podem ser observadas e coletadas em qualquer sistema. Podem ser relatorios de uso de baixo nível fornecidos pelo sistema operacional ou podem ser tipos de dados de alto nível vinculados à uma funcionalidade específica ou a um componente específico, tal qual solicitações atendidas a cada hora ou saídas inerentes à chamada de uma função.

Pontos positivos das métricas (parafraseando literalmente de Distributed Systems Observability):

• Ao contrário da geração e do armazenamento de logs, a transferência e o armazenamento de métricas têm uma sobrecarga constante.
• Como os números são otimizados para armazenamento, as métricas permitem maior retenção de dados, bem como consultas mais fáceis. Isso torna as métricas adequadas para a criação de dashboards que refletem tendências históricas, que podem ser fatiadas por período de tempo (dias/semanas/meses/anos).
• As métricas são ideais para transformações estatísticas, como amostragem, agregação, resumo e correlação. As métricas também são mais adequadas para acionar alertas, já que executar consultas em memória de um banco de dados que possui uma organização temporal de dados é muito mais eficiente.

Pontos negativos das métricas:

• As métricas permitem que você colete informações sobre eventos de todo o processo, mas geralmente não mais do que um ou dois campos de contexto.
• Problemas de cardinalidade (o número de elementos do conjunto): o uso de valores com alta cardinalidade, por exemplo IDs, como rótulos de métricas pode sobrecarregar os bancos de dados que possuem uma organização temporal de dados.
• Possuem escopo definido de um unico sistema (ou seja, apenas um serviço em uma coleção de microsserviços)

Métricas no aprendizado de máquina

Depois de apresentados os pontos positivos e negativos das métricas, é possível assumir que métricas são uma ótima opção para ambas as questões operacionais do nosso sistema de ML:

• Latência ao chamar pontos de extremidade da API de ML
• Uso de memória / CPU ao realizar a previsão
• Utilização do disco (Se aplicável).

Bem como para as questões centradas em medidas estatísticas básicas:

• Valores medianos e médios de previsão ao longo de um determinado período de tempo.
• Valores de previsão mínimo/máximo.
• Desvio padrão ao longo de um determinado período de tempo.

Fonte: https://christophergs.com/

Implementação prática

Uma das stacks de código aberto mais populares para monitorar métricas é a combinação de Prometheus e Grafana.

Para evitar que esta postagem se transforme em um livro, não vou entrar em uma explicação detalhada dessas tecnologias. O melhor lugar para aprender mais é o livro e os cursos de treinamento de Brian Brazil. Um resumo rápido da documentação:

O Prometheus extrai métricas de jobs, seja diretamente ou por meio de um gateway intermediário para jobs de curta duração. Ele armazena todas as amostras coletadas localmente e executa regras sobre esses dados para agregar e registrar dados existentes ao longo do tempo ou gerar alertas. Grafana ou outro serviço que consome uma API podem ser usados para visualizar os dados coletados.

Fonte: Prometheus documentation

Podemos criar dashboards com Prometheus & Grafana para rastrear as métricas estatísticas mais comuns de um modelo.

Através desses dashboards é possível criar alertas que notificam por meio de e-mail/SMS ou até mesmo Slack, quando as previsões do modelo saem dos intervalos esperados ao longo de um período de tempo específico (ou seja, comportamentos anômalos), adaptando a abordagem descrita aqui para ML. Isso, então, levaria a uma investigação completa, como por exemplo:

• Existe um bug no pipeline?
• Implementamos o modelo de forma errado? (surpreendentemente comum)
• Existe um problema com o conjunto de dados?
• O modelo ficou obsoleto?

9. Unindo Ops e DS — Logs

Um log de eventos é um registro imutável com data e hora de eventos que aconteceram ao longo do tempo.

Pontos positivos dos logs:

• Os registros são muito fáceis de gerar, pois são apenas uma string, um blob de JSON ou pares de valores-chave digitados.
• Os registros de eventos são excelentes quando se trata de fornecer informações valiosas junto com contexto suficiente, fornecendo detalhes que métricas mais comuns, como médias e percentis, não mostram.
• Enquanto as métricas mostram as tendências de um serviço ou aplicativo, os logs se concentram em eventos específicos. O objetivo dos logs é preservar o máximo de informações possíveis sobre uma ocorrência específica. As informações nos logs podem ser usadas para investigar incidentes e ajudar na análise da causa raiz.

Pontos negativos dos logs:

• O registro excessivo tem a capacidade de afetar negativamente o desempenho do sistema.
• Como resultado dessas preocupações com o desempenho, as operações de agregação e consolidaçaõ desses logs podem ser caras e, por esse motivo, os alertas baseados em logs devem ser tratados com cautela.
• No lado do processamento, os logs brutos são quase sempre normalizados, filtrados e processados ​​por uma ferramenta como Logstash, Fluentd, Scribe ou Heka antes de serem persistidos em um armazenamento de dados como Elasticsearch ou BigQuery. Configurar e manter essas ferramentas acarreta um custo operacional significativo.

Logs para aprendizado de máquina

Se considerarmos nossas principais áreas de monitoramento de ML, vimos anteriormente como poderíamos usar métricas para monitorar nossas saídas de predição, ou seja, o próprio modelo. No entanto, investigar os valores de entrada de dados por meio de métricas provavelmente levará a desafios de alta cardinalidade, já que muitos modelos têm várias entradas, incluindo valores categóricos. Embora possamos mensurar métricas em algumas entradas principais, se quisermos rastreá-las sem problemas de alta cardinalidade, é melhor usar registros para rastrear as entradas.

Por exemplo: Se estivéssemos trabalhando com um aplicativo de NLP com entrada de texto, poderíamos ter que nos apoiar mais fortemente no monitoramento de log, pois a cardinalidade da linguagem é extremamente alta.

Fonte: https://christophergs.com/

Verificaríamos se há sinais de alerta de entrada, como por exemplo:

• Uma features que ficou indisponível — (desaparecendo das entradas ou um grande número de NAs).
• Mudanças notáveis na distribuição dos principais valores de entrada, por exemplo, um valor categórico que era relativamente raro nos dados de treinamento se torna mais comum.
• Padrões específicos do seu modelo, por exemplo, em um cenário de NLP, um aumento repentino no número de palavras não vistas nos dados de treinamento

Implementação prática

Kibana é uma plataforma de análise e visualização de código aberto que faz parte da Stack ELK. Normalmente, o Kibana é utilizado para pesquisar, visualizar e interagir com os logs armazenados nos índices do Elasticsearch. Você pode facilmente realizar análises avançadas de dados e visualizar seus registros em uma variedade de gráficos, tabelas e mapas. Esta é uma das stacks de código aberto mais comuns para a construção de sistemas de monitoramento para logs.

Fonte: https://christophergs.com/

No Kibana, você pode configurar dashboards para rastrear e exibir os valores de entrada do modelo de ML, bem como alertas automatizados quando os valores exibem comportamentos inesperados. Esse dashboard pode ter a seguinte aparencia:

Fonte: https://christophergs.com/

Esta é apenas uma opção para um sistema de logs; também há opções mais gerenciaveis, como logz.io e Splunk.

10. A mudança de panorama

Esperamos que este artigo dê uma ideia muito mais clara sobre o que o monitoramento no aprendizado de máquina realmente significa e por que ele é importante. Como espero que tenha ficado claro que esta é uma área que requer esforço e planejamento interdisciplinar para ser eficaz. Será interessante ver como as ferramentas evoluem para atender à crescente frustração de muitas empresas que vivenciam o pico de uma implantação de ML, mas ficam mal equipadas para monitorar essa implantação e se complicam devido a alterações no ambiente alguns meses depois.

Entre os pontos a serem observaod futuramente podemos destacar:

• Os esforços dos big players de IA para melhorar o monitoramento de suas soluções de aprendizado de máquina, por exemplo, a Microsoft introduziu “Data Drift” no Azure ML Studio, ou as melhorias no SageMaker. Naturalmente, a utilização desses recursos tem um vendor-lock in entre outras restrições.
• Startups procuram- construir ferramentas inovadoras para facilitar o monitoramento de modelos, por exemplo, Seldon, Data Robot, MLFlow, superwise.ai e hydrosphere.io, entre outros.
• Iniciativas de código aberto no espaço MLOps. Acreditamos que o KF Serving pode fornecer alguma padronização muito necessária que pode simplificar os desafios da construção de soluções de monitoramento.

A esta altura no próximo ano, esse contexto provavelmente estará muito diferente …

Conclusão

Finalmente, espero que esse material tenha sido útil e faça sentido pra você. É valido mencionar que ao longo do artigo muitos links foram disponibilizados e possuem um conteúdo extremante rico, além disso na seção de referências é possível encontrar mais alguns links uteis que foram utilizados para elaboração desse artigo que pode te ajudar a ampliar seus conhecimentos no tema assim como me ajudaram.

Lembrando que qualquer feedback, seja positivo ou negativo é so entrar em contato através do meu twiter, linkedin ou nos comentário aqui em baixo. Obrigado :)

Referências

• https://christophergs.com/machine%20learning/2020/03/14/how-to-monitor-machine-learning-models/
• https://dl.acm.org/doi/10.5555/2969442.2969519
• https://developers.google.com/machine-learning/guides/rules-of-ml
• https://aws.amazon.com/pt/blogs/aws/amazon-sagemaker-model-monitor-fully-managed-automatic-monitoring-for-your-machine-learning-models/
• https://churrops.io/2017/10/09/o-que-e-sre-site-reliability-engineering/
• https://medium.com/r/?url=https%3A%2F%2Fpapers.nips.cc%2Fpaper%2F5656-hidden-technical-debt-in-machine-learning-systems.pdhttp%3A%2Fmartin.zinkevich.org%2Frules_of_ml%2Frules_of_ml