6. Monitoramento contínuo - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

6. Monitoramento contínuo

No monitoramento contínuo, os processos automatizados observam e detectam problemas de desempenho e problemas de modelo. Os proprietários podem então identificar possíveis problemas e ameaças em tempo real para resolvê-los rapidamente.

O monitoramento contínuo revela possíveis problemas de modelo, como qualidade de dados, mudança de distribuição, mudança de conceito de modelo e degradação da qualidade do modelo. O monitoramento contínuo também inclui registros abrangentes de medidas tradicionais do sistema, como saturação, latência, tráfego e erros. Uma estratégia prática de notificação e alerta é configurada para notificar os proprietários quando surgirem problemas.

6.1 Monitoramento do modelo: detecção da qualidade dos dados

O monitoramento baseado em regras existe para saber quando os dados recebidos se desviam dos dados de treinamento do modelo. Esse tipo de monitoramento cria um esquema a partir dos dados de treinamento, define restrições com base nesse esquema e, em seguida, executa exceções quando ocorre uma violação.

6.2 Monitoramento do modelo: mudança de distribuição

O monitoramento é configurado para analisar a distribuição de dados recebidos e verificar se ela não se desviou da distribuição de dados de treinamento do modelo. Por exemplo, os dados recebidos são amostrados como uma janela móvel sobre os dados de inferência. Em seguida, um trabalho é executado para testar a distribuição amostrada e a distribuição do treinamento para ver se elas são iguais.

6.3 Monitoramento do modelo: variação do conceito do modelo

Uma verificação de desvio de conceito busca que a relação entre as entradas de um modelo e a variável alvo permaneça inalterada em relação aos dados de treinamento. Uma verificação adicional é confirmar que as características relativas e sua importância não mudam.

6.4 Monitoramento do modelo: verificação da avaliação do modelo

Essa é uma verificação de monitoramento que avalia se a qualidade do modelo foi degradada. A verificação de avaliação do modelo compara as métricas de avaliação da linha de base do tempo de treinamento com os resultados recebidos para avaliar se o nível de precisão do modelo diminuiu em novos dados. Como calcula métricas de precisão, essa verificação exige que a veracidade básica dos novos dados esteja disponível após a inferência.

6.5 Capturas do sistema: esquemas de entrada

O sistema ML captura o esquema de dados de treinamento, teste e validação. Além de fornecer informações sobre entradas, os esquemas fornecem estatísticas sobre sua distorção e integridade.  Os esquemas são usados para testes imediatos e verificações de monitoramento da qualidade dos dados na produção.

6.6 Capturas do sistema: resultados e estatísticas da avaliação

O sistema ML gera informações precisas sobre dados de validação e treinamento. Ele pode gerar as previsões e os rótulos verdadeiros das execuções de validação e treinamento. Eles são usados como restrições de monitoramento para o modelo de produção ao vivo.

6.7 Capturas do sistema: anomalias

Existe um mecanismo de rastreamento para sinalizar anomalias nos fluxos de dados recebidos. Se ocorrerem discrepâncias nos dados recebidos ou se, durante um período de tempo especificado, a distribuição dos principais recursos mudar, o sistema reconhecerá isso como uma anomalia e a sinalizará.

6.8 Exploração madeireira: saturação e recursos

Existe um login para verificar se o sistema está cheio. As métricas de recursos e saturação devem se concentrar na utilização da CPU, na utilização da unidade de processamento gráfico (GPU), na utilização da memória e na utilização do disco. Essas métricas devem estar disponíveis em formato de série temporal com a capacidade de medir em percentis. Para trabalhos em lotes, isso fornece informações sobre a taxa de transferência, o que mostra quantas unidades de informação o sistema pode processar em cada período de tempo.

6.9 Registro: latência

O registro deve existir para medir o atraso na comunicação de rede ou o tempo necessário para atender a uma solicitação. Um engenheiro deve ser capaz de avaliar quanto tempo os modelos de inferência estão levando para atender às previsões e quanto tempo o modelo leva para carregar.

6.10 Registro: tráfego

A configuração de registro do tráfego mede o volume de tráfego em cada instância. O tráfego é medido pelo número de solicitações HTTP e bytes ou pacotes enviados ou recebidos durante um determinado período de tempo. O registro do tráfego fornece informações sobre a carga de trabalho total colocada em um sistema.

6.11 Registro: erros

A configuração de registro de erros captura o número de solicitações que falham. As falhas são dos seguintes tipos:

  • Explícito (por exemplo, erros HTTP 500)

  • Implícito (por exemplo, uma resposta de sucesso HTTP 200 associada ao conteúdo errado)

  • Política (por exemplo, se você se comprometer com tempos de resposta de um segundo, qualquer solicitação acima de um segundo será um erro)

Quando os códigos de resposta do protocolo são insuficientes para expressar todas as condições de falha, protocolos secundários (internos) podem ser necessários para rastrear os modos de falha parcial.

6.12 Notificações e alertas

Notificações e alertas são configurados a partir do monitoramento. As notificações incluem a capacidade de receber mensagens do Slack, notificações por e-mail, páginas e mensagens do Short Message Service (SMS). Alertar não significa enviar notificações para todas as possíveis violações. Em vez disso, significa definir alertas para exceções específicas que sejam significativas e importantes para a equipe de desenvolvimento. Dessa forma, a fadiga de alerta é evitada.