Parabéns! Você implantou o modelo de unicórnio. Seu modelo deve ser executado 24 horas por dia, 7 dias por semana, sem problemas. Para garantir que isso aconteça, monitore seu pipeline de machine learning (ML).
Escrever um esquema de dados para validar dados brutos
Para monitorar seus dados, você deve verificá-los continuamente em relação ao valores estatísticos ao escrever regras que os dados precisam atender. Esta coleção de regras é chamado de esquema de dados. Defina um esquema de dados seguindo estas etapas:
Entenda o alcance e a distribuição dos seus atributos. Para categóricos atributos, entenda o conjunto de valores possíveis.
Codifique seu entendimento no esquema de dados. Veja a seguir exemplos de regras:
- Verifique se as avaliações enviadas pelos usuários estão sempre no intervalo de 1 a 5.
- Verifique se a palavra the aparece com mais frequência (para um texto em inglês) ).
- Verificar se cada atributo categórico está definido como um valor de um conjunto fixo de valores possíveis.
Teste seus dados em relação ao esquema de dados. Seu esquema deve capturar dados erros como:
- Anomalias
- Valores inesperados de variáveis categóricas
- Distribuições de dados inesperadas
Criar testes de unidade para validar a engenharia de atributos
Os dados brutos podem passar pelo esquema de dados, mas o modelo não é treinado com base em dados brutos. Em vez disso, o modelo é treinado com dados projetada. Por exemplo, o modelo é treinado com atributos numéricos normalizados em vez de dados numéricos brutos. Como a engenharia de atributos pode ser diferente dos dados de entrada brutos, você precisa verificar os dados de engenharia de atributos separadamente das verificações dos dados brutos de entrada.
Crie testes de unidade com base no seu entendimento dos dados de engenharia de atributos. Por exemplo, é possível programar testes de unidade para verificar condições como a seguintes:
- Todos os atributos numéricos são dimensionados, por exemplo, entre 0 e 1.
- Codificação one-hot vetores contêm apenas zeros 1 e N-1.
- As distribuições de dados após a transformação estão em conformidade com as expectativas. Por exemplo, se você normalizou usando pontuação Z, a média dos Os escores Z devem ser 0.
- Outliers são processados, como por escalonamento ou recorte.
Verificar importantes frações de dados das métricas
Um todo bem-sucedido às vezes oculta um subconjunto malsucedido. Em outras palavras, um modelo com ótimas métricas gerais ainda pode fazer previsões péssimas em determinadas situações. Exemplo:
No geral, seu modelo unicórnio tem um bom desempenho, mas não tem um bom desempenho quando fazendo previsões para o deserto do Saara.
Se você é o tipo de engenheiro satisfeito com uma ótima AUC geral, talvez você não note os problemas do modelo no deserto do Saara. Se fizer boas previsões para todas as regiões é importante, então você precisa rastrear o desempenho de cada região. Subconjuntos de dados, como o que corresponde ao deserto do Saara, são chamadas de fatias de dados.
Identifique frações de dados de interesse. Em seguida, compare as métricas do modelo dessas frações de dados com as métricas do seu o conjunto de dados inteiro. Verificar se o modelo tem um bom desempenho em todas as frações de dados ajuda a remover vieses. Consulte Imparcialidade: avaliação de vieses para mais informações.
Use métricas reais
As métricas do modelo não medem necessariamente o impacto do modelo no mundo real. Por exemplo, alterar um hiperparâmetro pode aumentar a AUC do modelo, mas a mudança afetou a experiência do usuário? Para medir o impacto no mundo real, você precisa para definir métricas separadas. Por exemplo, faça uma pesquisa com os usuários do seu modelo para confirmar que realmente viram um unicórnio quando o modelo previu que eles faria.
Verificar se há desvio de treinamento/disponibilização
Desvio de treinamento/disponibilização significa que os dados de entrada durante o treinamento são diferentes dos dados de entrada na disponibilização. A tabela a seguir descreve dois tipos importantes de desvio:
| Tipo | Definição | Exemplo | Solução |
|---|---|---|---|
| Desvio de esquema | Os dados de entrada para treinamento e exibição não estão em conformidade com o mesmo esquema. | O formato ou a distribuição dos dados de exibição mudam enquanto o modelo continua treinando com dados antigos. | Use o mesmo esquema para validar os dados de treinamento e disponibilização. Verifique separadamente as estatísticas não verificadas pelo seu esquema, como a fração dos valores ausentes |
| Desvio de atributos | Há diferenças entre o treinamento e a disponibilização dos dados projetados. | O código de engenharia de atributos difere entre treinamento e disponibilização, para produzir diferentes dados de engenharia. | Assim como no desvio de esquema, aplique as mesmas regras estatísticas em todo o treinamento e disponibilização de dados de engenharia. Rastrear número de atributos distorcidos detectados e a proporção de exemplos distorcidos por atributo. |
As causas do desvio entre treinamento e disponibilização podem ser sutis. Sempre considere quais dados estão disponíveis para o modelo no momento da previsão. Durante o treinamento, use apenas os atributos que você vai ter disponíveis durante a disponibilização.
Exercício: testar seu conhecimento
Imagine que você tem uma loja on-line e quer prever a quantidade de dinheiro que você vai ganhar em um determinado dia. Sua meta de ML é fazer previsões diárias receita usando o número de clientes como um atributo.
Resposta:o problema é que você não sabe o número de clientes no momento da previsão, antes que as vendas do dia sejam concluído. Portanto, esse recurso não é útil, mesmo que seja é altamente preditivo da sua receita diária. De modo relacionado, quando você está treinar um modelo e conseguir métricas de avaliação incríveis (como 0,99 AUC). procure esses tipos de características que possam se misturar ao seu marcador.
Conferir se há vazamento de rótulos
Vazamento de rótulos significa que seu rótulos de informações empíricas que você tentar prever, entraram inadvertidamente nos atributos de treinamento. Rótulo vazamento às vezes é muito difícil de detectar.
Exercício: testar seu conhecimento
Suponha que você tenha criado um modelo de classificação binária para prever se um novo paciente do hospital tem câncer. Seu modelo usa recursos como os seguintes:
- Idade do paciente
- Gênero do paciente
- Condições médicas anteriores
- Nome do hospital
- Sinais vitais
- Resultados do teste
- Hereditariedade
O rótulo é o seguinte:
- Booleano: o paciente tem câncer?
Você particiona os dados com cuidado, garantindo que seu conjunto de treinamento esteja bem isolados dos conjuntos de validação e teste. O modelo realiza muito bem no conjunto de validação e no conjunto de teste; as métricas são fantástica. Infelizmente, o modelo tem um desempenho terrível com novos pacientes. no mundo real.
Resposta:um dos atributos do modelo é o nome do hospital. Alguns hospitais são especializados no tratamento do câncer. Durante o treinamento, a rapidamente aprendeu que pacientes atribuídos a certos hospitais provavelmente tinha câncer. Então, o nome do hospital se tornou um atributo altamente ponderado.
No momento da inferência, a maioria dos pacientes ainda não havia sido designada a um hospital. Afinal, o objetivo do modelo era diagnosticar a presença ou ausência de câncer e usar esse diagnóstico para atribuir ao paciente ao hospital adequado. Consequentemente, durante a inferência, o O recurso de nome do hospital ainda não estava disponível, e o modelo foi forçado a depender de outros recursos.
Monitorar a idade do modelo em todo o pipeline
Se os dados de disponibilização evoluem com o tempo, mas o modelo não é treinado de novo regularmente, vai notar uma queda na qualidade do modelo. Monitorar o tempo desde que o modelo foi treinados novamente com novos dados e definir uma idade limite para alertas. Além de monitorar a idade do modelo na disponibilização, monitore a idade dele ao longo do pipeline para detectar interrupções de pipeline.
Testar se os pesos e as saídas do modelo são numericamente estáveis
Durante o treinamento de modelo, os pesos e as saídas da camada não podem ser NaN (não é um número) ou Inf (infinito). Crie testes para verificar os valores NaN e Inf dos pesos e das saídas da camada. Além disso, teste se mais da metade das saídas de uma camada não são zero.
Monitorar o desempenho do modelo
Seu preditor de aparência de unicórnio está mais popular do que o esperado! Você está recebe muitas solicitações de previsão e ainda mais dados de treinamento. Você pensa o que é ótimo até você perceber que o modelo está ocupando mais memória e tempo de treinamento. Você decide monitorar o desempenho do modelo seguindo estas etapas:
- Rastreie o desempenho do modelo por versões de código, modelo e dados. Esse rastreamento permite identificar a causa exata de qualquer degradação do desempenho.
- Teste as etapas de treinamento por segundo para uma nova versão do modelo em relação com a versão anterior e com um limite fixo.
- Identifique vazamentos de memória definindo um limite de uso de memória.
- Monitore os tempos de resposta da API e os percentis. Enquanto a resposta da API podem estar fora do seu controle, respostas lentas podem causar métricas do mundo real ruins.
- Monitore o número de consultas respondidas por segundo.
Testar a qualidade do modelo ativo nos dados veiculados
Você validou seu modelo. Mas e se cenários reais, como um unicórnio, comportamento, mudar depois de registrar seus dados de validação? Então, a qualidade do seu o modelo disponibilizado vai se degradar. No entanto, testar a qualidade na veiculação é difícil porque dados reais nem sempre são rotulados. Se os dados de veiculação não estiverem rotulados, considere estes testes:
Investigue os modelos que mostram um viés estatístico significativo nas previsões. Consulte Classificação: previsão Viés.
Rastreie métricas reais para seu modelo. Por exemplo, se você está classificando compare suas previsões com as denúncias de spam feitas pelos usuários.
Reduzir a possível divergência entre os dados de treinamento e de disponibilização ao disponibilizar uma nova versão do modelo em uma fração das consultas. Ao validar seu novo modelo de exibição, mude gradualmente todas as consultas para a nova versão.
Ao usar esses testes, lembre-se de monitorar a degradação repentina e lenta em na qualidade da previsão.
Randomização
Torne seu pipeline de geração de dados reproduzível. Digamos que você queira adicionar um recurso para saber como isso afeta a qualidade do modelo. Para um experimento justo, seus conjuntos de dados devem idênticos, exceto por este novo recurso. Com isso em mente, certifique-se de que qualquer ordem aleatória na geração de dados possa ser feita determinista:
- Propagar seus geradores de números aleatórios (RNGs, na sigla em inglês). A propagação garante que o RNG gera os mesmos valores na mesma ordem sempre que é executado, recriando conjunto de dados.
- Use chaves de hash invariantes. O hash é uma maneira comum de dividir ou dados de amostra. É possível gerar hash de cada exemplo e usar o número inteiro resultante para decidir em qual divisão colocar o exemplo. As entradas para sua função hash não deve mudar toda vez que você executar o programa de geração de dados. Não use o campo a hora atual ou um número aleatório no hash, por exemplo, se quiser recriar seus hashes sob demanda.
As abordagens anteriores se aplicam à amostragem e à divisão dos dados.
Considerações sobre hash
Imagine novamente que você estava coletando consultas de pesquisa e usando hashing para incluir ou excluir consultas. Se a chave de hash só usasse a consulta, Em seguida, entre vários dias de dados, você sempre incluirá essa consulta ou sempre a exclui. Sempre incluindo ou sempre excluindo uma consulta é ruim porque:
- Seu conjunto de treinamento vai receber um conjunto menos diversificado de consultas.
- Seus conjuntos de avaliação serão artificialmente complicados, porque não se sobreponham aos dados de treinamento. Na verdade, no momento da disponibilização, parte do tráfego em tempo real nos dados de treinamento, e avaliação precisa refletir isso.
Em vez disso, você pode gerar hash de consulta + data, o que resultaria em um hash diferente todos os dias.
