Monitorando ML em produção

06/05/2022 20:38 Monitorando Modelos de Aprendizado de Máquina em Produção | by Toni Esteves | Medium
Open in app
Toni Esteves Follow
Aug 25, 2021 · 26 min read
Save
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
l b h k b h h
https://estevestoni.medium.com/monitorando-modelos-de-aprendizado-de-máquina-em-produção-9d4f83a3dbfa 1/30
learn about other works by the author.

Open in app
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.

Open in app
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

Open in app
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
Open in app
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

q
06/05/2022 20:38
ç
Monitorando Modelos de Aprendizado de Máquina em Produção | by Toni Esteves | Medium
Open in app
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:
o te ttps //c stop e gs co /
Open in app
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
Open in app
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

2. Que é importante definir bem esses termos para evitar confusão.
Open in app
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
Open in app
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
p
06/05/2022 20:38
q p
treinamento […] um modelo que está tentando mostrar Open in app
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 39
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)
Open in app
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
seresm 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
d ”
sistema de ML. ”
Open in app
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: Omodelo 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: Omodelo 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.
Open in app
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.
Q d f l it t t f d té i d
https://estevestoni.medium.com/monitorando-modelos-de-aprendizado-de-máquina-em-produção-9d4f83a3dbfa
ó d ã N 14/30
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
Open in app
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).
06/05/2022 20:38
f Monitorando Modelos de Aprendizado de Máquina em Produção | by Toni Esteves | Medium
Open in app
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:
Dependendo da configuração do modelo, permitiremos que certos recursos de entrada sejam

Open in app
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.
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
é í bá l d d
https://estevestoni.medium.com/monitorando-modelos-de-aprendizado-de-máquina-em-produção-9d4f83a3dbfa d d íd 17/30
é automatizar testes estatísticos básicos (por exemplo, o desvio padrão de entradas/saídas)

Open in app
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
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 in app
Open
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 tareda 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:
Open in app
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.
Open in app
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
p
06/05/2022 20:38
ç q ,q p
por período de tempo (dias/semanas/meses/anos).

Open in app
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.
Open in app
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.
Open in app
Fonte: Prometheus documentation
Podemos criar dashboards com Prometheus & Grafana para rastrear as métricas estatísticas
mais comuns de um modelo.
é d d hb d é í l l f
https://estevestoni.medium.com/monitorando-modelos-de-aprendizado-de-máquina-em-produção-9d4f83a3dbfa d l 24/30
Através desses dashboards é possível criar alertas que notificam por meio de e-mail/SMS ou
Open
até mesmo Slack, quando as previsões do modelo saem dos intervalos esperados ao in app
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
Open in app
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.
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.
Open in app
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.
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:
Open in app
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.
Open in app
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
Get an email whenever Toni Esteves publishes.

Open in app
Emails will be sent to jeydsonl@gmail.com.

Subscribe
Not you?

Monitorando ML em produção

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Monitorando ML em produção

Enviado por

Direitos autorais:

Formatos disponíveis

06/05/2022 20:38 Monitorando Modelos de Aprendizado de Máquina em Produção | by Toni Esteves | Medium

Toni Esteves Follow

Aug 25, 2021 · 26 min read

Monitorando Modelos de Aprendizado de Máquina

Photo by Ibrahim Boran on Unsplash

learn about other works by the author.

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.

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

Martin Fowler popularizou o conceito de Continuous Delivery for Machine Learning

1. Construção do modelo: Entendimento do problema, preparação de dados, feature

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

3. Produtização do Modelo: Preparar o código de utilizado na etapa da prototipação e

No diagrama mostrado anteriormente, observe o aspecto cíclico, onde as informações

Você pode considerar as duas primeiras fases do diagrama (“construção de modelo” e

O primeiro cenário é simplesmente a implantação de um modelo totalmente novo. O

Independentemente da situação, a etapa de monitoramento é como validamos se as

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

Um ponto importante a se esclarecer com relação ao artigo mencionado acima é que, ao

The model is a tiny fraction of an overall ML system —

Fonte: Sculley et al. 2015

Quando se trata de uma solução de ML, nos preocupamos fundamentalmente em rastrear 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,

Sem uma maneira de entender e rastrear essas alterações de

Emaranhamento: Quando um recurso de entrada é alterado, então a importância, pesos

Configuração: Como os hiperparâmetros, versões e recursos do modelo são

Felizmente, começa a ficar claro que as soluções de ML são complexas em sua

Soluções de ML abrangem várias equipes (também podem

Antes de continuarmos discutindo a etapa de monitoramento, é importante mencionar que

Engenheiros e DevOps: Aqui a palavra “monitoramento”, faz referência a integridade do

Enquanto no desenvolvimento de software tradicional as etapas de monitoramento e

2 Que é importante definir bem esses termos para evitar confusão

O monitoramento deve ser planejado juntamente com a solução durante a etapa de

3. Por que é necessário monitorar

“Ao falhar em se preparar, você está se preparando para

Distorções nas distribuições

Existem vários motivos pelos quais isso pode acontecer:

Projetamos os dados de treinamento incorretamente: As distribuições das variáveis ​​

Incompatibilidade nos dados de prototipação e dados reais: Os dados que usamos

Mudanças no comportamento do consumidor: As preferências do cliente mudam,

Cenários adversos: Os famosos Bad Users (fraudadores, criminosos, governos

Loops de Feedback Negativos

“Precisamos ter muito cuidado sobre como os modelos que

treinamento […] um modelo que está tentando mostrar Open in app

aos usuários um conteúdo que o próprio modelo presumiu

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

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

As melhores práticas costumam ser abordagens cinza.

Os requisitos regulamentares estão mudando o tempo todo (LGPD).

Existem alguns papers detalhando as melhores práticas em torno de design de sistema,

O artigo do Google se concentra mais em estratégias de teste e monitoramento de soluções

Projetamos os dados de treinamento incorretamente: As distribuições das variáveis