Orientações adicionais para o pipeline de treinamento

Esta seção detalha o pipeline de treinamento.

Otimizar o pipeline de entrada

Resumo: as causas e intervenções de pipelines vinculados à entrada dependem muito da tarefa. Use um criador de perfil e procure problemas comuns.

Use um criador de perfis adequado, como um dos seguintes, para diagnosticar pipelines vinculados à entrada:

• Perfetto para JAX
• TensorFlow Profiler para TensorFlow.

Em última análise, as causas e intervenções específicas dependem muito da tarefa. Considerações de engenharia mais amplas (por exemplo, minimizar a ocupação de disco) podem prejudicar o desempenho do pipeline de entrada.

Confira abaixo causas comuns de pipelines vinculados à entrada:

• Os dados não são colocados com o processo de treinamento, causando latência de E/S. Por exemplo, a leitura de dados de treinamento em uma rede pode causar latência de E/S.
• Pré-processamento de dados on-line caro. Considere pré-processar uma vez off-line e salvar os resultados.
• Barreiras de sincronização não intencionais que interferem na pré-busca do pipeline de dados. Por exemplo, ao sincronizar métricas entre o dispositivo e o host em CommonLoopUtils.

Sugerimos as seguintes intervenções para pipelines vinculados à entrada:

• Instrumente o pipeline de entrada para pré-buscar exemplos (por exemplo, tf.data.Dataset.prefetch).
• Remova recursos e metadados não utilizados de cada um o quanto antes no pipeline.
• Aumente a replicação do número de jobs que geram exemplos para o pipeline de entrada, por exemplo, usando o serviço tf.data.

Como avaliar o desempenho do modelo

Resumo: execute a avaliação com tamanhos de lote maiores do que o treinamento. Execute avaliações em intervalos regulares de etapas, não de tempo.

Configurações de avaliação

Use as seguintes configurações para avaliar a performance dos seus modelos:

• Avaliação on-line: coleta métricas quando o modelo está veiculando previsões em um ambiente de produção. A avaliação on-line geralmente oferece a avaliação mais realista da qualidade do modelo porque corresponde à maneira como ele será usado.
• Avaliação off-line: coleta métricas quando o modelo é executado em conjuntos de treinamento, validação ou teste off-line representativos do ambiente de produção. Dependendo do problema, a avaliação off-line pode ser bastante complexa e cara do ponto de vista computacional.
• Avaliações periódicas: colete métricas durante o treinamento do modelo que podem ser um proxy para a avaliação off-line e/ou em um subconjunto dos dados usados na avaliação off-line. As avaliações periódicas são a opção mais prática e econômica, mas podem não representar totalmente o ambiente de produção. Use um proxy conveniente da avaliação off-line sem sacrificar a confiabilidade do indicador recebido durante o treinamento.

Como configurar avaliações periódicas

Recomendamos executar avaliações periódicas durante o treinamento pelos seguintes motivos:

• Para monitorar o progresso do treinamento em tempo real.
• Para facilitar a seleção retrospectiva de checkpoints de modelos.
• Examinar as curvas de treinamento no final do treinamento.

A configuração mais simples é realizar o treinamento e as avaliações periódicas na mesma instância de computação, alternando periodicamente entre treinamento e avaliação. Nesse caso, o tamanho do lote usado para realizar avaliações precisa ser pelo menos tão grande quanto o tamanho do lote usado para treinamento. Isso porque não é necessário manter as ativações do modelo durante a avaliação, o que reduz os requisitos computacionais por exemplo.

Faça avaliações periódicas em intervalos regulares de etapas, não de tempo. A avaliação com base em intervalos de tempo pode dificultar a interpretação das curvas de treinamento, especialmente quando o treinamento pode sofrer de interrupções dos jobs de treinamento, problemas de latência de rede e assim por diante.

A periodicidade nas métricas de validação e teste (ao usar um conjunto de treinamento, validação e teste embaralhados) pode indicar bugs de implementação, como:

• Dados de teste que se sobrepõem aos dados de treinamento.
• Os dados de treinamento não estão sendo embaralhados corretamente.

A avaliação em intervalos regulares de etapas pode facilitar a identificação desses problemas.

Lotes parciais podem ocorrer quando os conjuntos de avaliação não são divisíveis pelo tamanho do lote. Verifique se os exemplos com padding estão ponderados corretamente (como na média ponderada sobre exemplos que calculam a perda média no lote) para evitar que a função de perda seja influenciada por eles. Muitas vezes, é possível atribuir um peso zero a esses exemplos com padding.

Salve informações suficientes por avaliação para oferecer suporte à análise off-line. O ideal é salvar previsões em uma seleção de exemplos individuais, já que elas podem ser muito úteis para depuração. A geração de artefatos como SavedModels simplifica a inspeção de modelos ad hoc após a conclusão dos jobs de avaliação.

Como escolher uma amostra para avaliação periódica

O job de avaliação periódica pode não ser executado rápido o suficiente para calcular métricas no conjunto completo de avaliação off-line em um período razoável. Esse problema geralmente exige a amostragem de dados para avaliação periódica. Ao construir um conjunto de dados amostrado, considere problemas com o tamanho da amostra e questões especiais em conjuntos de dados desequilibrados.

Tamanho da amostra

Verifique se a performance calculada no conjunto de dados amostrado usado pelo job periódico corresponde à performance em todo o conjunto de avaliação off-line. Ou seja, garanta que não haja distorção entre o conjunto de dados amostrado e o completo.

O conjunto de dados usado para avaliação periódica precisa ser:

• Pequeno o suficiente para gerar previsões de modelo com facilidade em toda a extensão.
• Grande o suficiente para fazer o seguinte:
  • Medir com precisão as melhorias no modelo. Ou seja, as medições não podem ser afetadas pelo ruído de rótulo.
  • Acomodar várias avaliações desse tipo em testes em sequência e ainda produzir estimativas precisas. Ou seja, grande o suficiente para evitar o "ajuste" adaptativo ao conjunto de validação ao longo do tempo de uma forma que não seja generalizada para um conjunto de teste retido. No entanto, essa consideração raramente é um problema prático.

Conjuntos de dados desequilibrados

Em conjuntos de dados desequilibrados, o desempenho em classes minoritárias raras costuma ser ruidoso. Para conjuntos de dados com apenas um pequeno número de exemplos de minoria, registre o número de exemplos previstos corretamente para ter mais insights sobre melhorias na acurácia. Por exemplo, uma melhoria de sensibilidade de 0,05 parece incrível, mas será que ela ocorreu apenas porque um exemplo a mais estava correto?

Salvar checkpoints e selecionar retrospectivamente o melhor checkpoint

Resumo: execute o treinamento para um número fixo de etapas e escolha retrospectivamente o melhor checkpoint da execução.

A maioria dos frameworks de aprendizado profundo oferece suporte ao checkpointing de modelos. Ou seja, o estado atual do modelo é salvo periodicamente no disco. O checkpoint permite que o job de treinamento seja resiliente a interrupções da instância de computação. O melhor checkpoint geralmente não é o último, principalmente quando o desempenho do conjunto de validação não continua aumentando com o tempo, mas sim flutua em torno de um valor específico.

Configure o pipeline para acompanhar os N melhores checkpoints vistos até agora durante o treinamento. Ao final do treinamento, a seleção de modelo significa simplesmente escolher o melhor checkpoint. Chamamos essa abordagem de seleção retrospectiva de checkpoint ideal. Normalmente, não é necessário oferecer suporte à parada antecipada prospectiva, porque você está pré-especificando um orçamento de teste e preservando os N melhores checkpoints vistos até agora.

Configurar o acompanhamento de experimentos

Resumo: ao acompanhar diferentes experimentos, acompanhe vários elementos essenciais, como a melhor performance de um ponto de verificação no estudo e uma breve descrição dele.

Recomendamos acompanhar os resultados do experimento em uma planilha. Nossas planilhas geralmente contêm as seguintes colunas:

• Nome do estudo
• Um link para o local em que a configuração do estudo está armazenada.
• Observações ou uma breve descrição do estudo.
• Número de testes executados
• Performance no conjunto de validação do melhor checkpoint no estudo.
• Comandos de reprodução específicos ou observações sobre quais mudanças não enviadas foram necessárias para iniciar o treinamento.

Encontre um sistema de rastreamento conveniente que capture pelo menos as informações listadas acima. Experimentos não rastreados são como se não existissem.

Detalhes da implementação da normalização em lote

Resumo: hoje em dia, é possível substituir a normalização em lote por LayerNorm. No entanto, quando isso não é possível, há detalhes complicados ao mudar o tamanho do lote ou o número de hosts.

A normalização em lote normaliza as ativações usando a média e a variância no lote atual. No entanto, na configuração de vários dispositivos, essas estatísticas são diferentes em cada dispositivo, a menos que sejam sincronizadas explicitamente. Relatos anedóticos (principalmente no ImageNet) indicam que o cálculo dessas estatísticas de normalização usando apenas cerca de 64 exemplos funciona melhor na prática. Consulte a descrição da normalização de lote fantasma em Treinar por mais tempo, generalizar melhor: fechando a lacuna de generalização em treinamento de lote grande de redes neurais. Separar o tamanho total do lote e o número de exemplos usados para calcular as estatísticas de normalização em lote é particularmente útil para comparações de tamanho do lote.

As implementações de normalização de lote fantasma nem sempre processam corretamente o caso em que o tamanho do lote por dispositivo é maior que o tamanho do lote virtual. Nesse caso, é necessário fazer uma subamostragem do lote em cada dispositivo para ter o número adequado de exemplos de estatísticas de normalização em lote.

As médias móveis exponenciais (EMAs, na sigla em inglês) usadas na normalização em lote do modo de teste são apenas uma combinação linear de estatísticas de treinamento. Portanto, só é necessário sincronizar essas EMAs antes de salvá-las em pontos de verificação. No entanto, algumas implementações comuns de normalização em lote não sincronizam essas EMAs e salvam apenas a EMA do primeiro dispositivo.

Considerações sobre pipelines de vários hosts

Resumo: para geração de registros, avaliações, RNGs, criação de pontos de verificação e fragmentação de dados, o treinamento em vários hosts pode facilitar muito a introdução de bugs.

Faça o seguinte para pipelines de vários hosts:

• Verifique se o pipeline está apenas registrando e criando checkpoints em um host.
• Sincronize as estatísticas de normalização em lote entre hosts antes de avaliar ou criar pontos de verificação.
• Fragmentar arquivos de dados entre hosts geralmente melhora o desempenho.

Importante:verifique se você tem seeds de RNG iguais em todos os hosts (para inicialização do modelo) e diferentes em todos os hosts (para embaralhamento/pré-processamento de dados). Portanto, marque-os corretamente.