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 |
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:
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. |