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 performance e 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 do modelo e degradação da qualidade do modelo. O monitoramento contínuo também inclui registros em log 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 de modelo. Esse tipo de monitoramento cria um esquema 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 de modelo. Por exemplo, os dados recebidos são amostrados como uma janela móvel |
6.3 Monitoramento do modelo: desvio de 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 de modelo |
É uma verificação de monitoramento que avalia se a qualidade do modelo foi degradada. A verificação de avaliação de 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 ela calcula as métricas de precisão, essa verificação exige que a verdade de referência dos novos dados esteja disponível após a inferência. |
6.5 Capturas do sistema: esquemas de entrada |
O sistema de 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 de 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 Registro em log: saturação e recursos |
Existe um registro em log para verificar se o sistema está cheio. As métricas de recursos e saturação devem se concentrar na utilização da CPU, da unidade de processamento gráfico (GPU), da memória e 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 o throughput, o que mostra quantas unidades de informação o sistema pode processar em cada período de tempo. |
6.9 Registro em log: latência |
O registro em log 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 em log: tráfego |
A configuração de registro em log 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 em log do tráfego fornece insights sobre a workload total imposta a um sistema. |
6.11 Registro em log: erros |
A configuração de registro em log de erros captura o número de solicitações que falham. As falhas são dos seguintes tipos:
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 com base no monitoramento. As notificações incluem a capacidade de receber mensagens via Slack, notificações por e-mail, páginas e mensagens 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. |
