Monitorizar o modelo implementado

Implementar o modelo de ausência em segurança permite-o entrar em produção, mas é na produção que o verdadeiro comportamento do modelo, e os dados que vê, podem começar a divergir do que a equipa de ciência de dados concebeu. A monitorização é a forma de detetar isso.

Monitorize a saúde operacional do endpoint

Os endpoints online do Azure Machine Learning emitem métricas para o Azure Monitor, incluindo latência de pedidos, contagem de pedidos, taxa de erro e a utilização da CPU e memória do cálculo da implementação. Visualiza-os no Estúdio do Azure Machine Learning, ou constrói alertas e dashboards diretamente no Azure Monitor. Se a taxa de erro do endpoint disparar ou a latência aumentar, esse padrão aponta para um problema de infraestrutura ou no processo de scoring que deve ser investigado, independentemente de as previsões do modelo continuarem corretas.

Se uma implantação falhar ao aprovisionar ou processar pedidos de pontuação, comece por separar os problemas de configuração dos problemas em tempo de execução. Teste o modelo localmente sempre que possível, reveja o estado de implementação e os detalhes do erro, e inspecione os registos do contentor. Os registos podem revelar dependências em falta, comportamentos de pontuação inválidos, falhas de imagem ou restrições de recursos e quotas.

Configurar monitorização para as previsões do modelo

As métricas dizem que o endpoint está a responder; Não dizem se as suas previsões continuam a ser válidas à medida que os dados do mundo real mudam. O Azure Machine Learning fornece monitorização de modelos para isso, mas é uma funcionalidade que se configura. Por predefinição, uma implantação não é monitorizada em termos de qualidade das previsões. Para o usar, primeiro ativas a recolha de dados na implementação online para que os pedidos e respostas recebidos sejam registados, depois crias um monitor que compara esses dados de produção com um conjunto de dados de referência, normalmente os dados em que o modelo foi treinado ou validado.

Um monitor de modelo calcula sinais como estes num cronograma que define:

Decida quando investigar ou voltar a treinar

Um sinal de monitorização que ultrapassa o seu limiar configurado é um prompt para investigar, não uma correção automática. No caso do modelo de ausência da Proseware, um alerta de desvio de dados sobre o prazo de antecedência das consultas pode significar que a clínica alterou a sua política de agendamento, o que vale a pena analisar mais de perto antes de decidir se é necessário requalificar. Um sinal sustentado de desvio nas previsões, aliado ao feedback da equipa da clínica de que as consultas assinaladas não são, na realidade, de maior risco, constitui um argumento mais forte para treinar novamente o modelo com dados mais recentes e recolocá-lo em produção pelo mesmo pipeline que automatizou anteriormente neste módulo.

Escolha entre reversão e novo treino

O rollback é adequado quando um problema começa com uma nova implementação e o modelo anterior se mantém saudável. Redirecione o tráfego para a implantação mantida primeiro, e depois investigue a nova versão. O retraining é mais apropriado quando os dados de produção ou o comportamento no mundo real mudaram o suficiente para que o modelo anterior tivesse a mesma limitação. A monitorização fornece provas para a decisão; Não deverá desencadear nenhuma das respostas sem avaliação.