Orientações adicionais para o pipeline de treinamento

Nesta seção, detalhamos o pipeline de treinamento.

Como otimizar o pipeline de entrada

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

Use um criador de perfil apropriado, como um dos seguintes, para diagnosticar pipelines vinculados à entrada:

• Perfetto para JAX
• TensorFlow Profiler para o TensorFlow.

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

Veja a seguir causas comuns dos pipelines vinculados à entrada:

• Os dados não são colocalizados 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 caro de dados on-line. Pense em fazer o pré-processamento uma vez off-line e salvar os resultados.
• Barreiras de sincronização não intencionais que interferem na pré-busca de pipeline de dados. Por exemplo, ao sincronizar métricas entre o dispositivo e o host no CommonLoopUtils.

Sugerimos as seguintes intervenções para pipelines com limite de entrada:

• Instrumentar o pipeline de entrada para exemplos de pré-busca (por exemplo, tf.data.Dataset.prefetch).
• Remova recursos e metadados não utilizados de cada um o mais cedo possível 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: faça a avaliação em tamanhos de lote maiores do que o treinamento. Execute avaliações em intervalos de passos regulares, não em intervalos de tempo regulares.

Configurações de avaliação

Use as configurações a seguir para avaliar o desempenho dos modelos:

• Avaliação on-line: colete métricas quando o modelo estiver exibindo prediçõ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 o modelo será usado.
• Avaliação off-line: colete métricas quando o modelo for executado em conjuntos de treinamento, validação ou teste off-line que representem o ambiente de produção. Dependendo do problema, a avaliação off-line pode ser bastante cara e computacionalmente cara.
• Avaliações periódicas: colete métricas durante o treinamento de modelo que possam ser um proxy para a avaliação off-line e/ou em um subconjunto dos dados usados na avaliação off-line. Avaliações periódicas são a escolha mais prática e econômica, mas podem não representar completamente o ambiente de produção. Tente usar um proxy conveniente da avaliação off-line, sem sacrificar a confiabilidade do sinal 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 do ponto de controle do modelo retrospectivo.
• Para analisar as curvas de treinamento ao final do treinamento.

A configuração mais simples é realizar treinamentos e 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 usado para treinamento. Isso ocorre porque você não precisa manter ativações de modelo durante a avaliação, o que reduz os requisitos computacionais por exemplo.

Realize avaliações periódicas em intervalos regulares de passos, não em intervalos 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 com preempçõ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 aleatório, um conjunto de validação, uma divisão de teste) pode indicar bugs de implementação, como:

• Os dados de teste se sobrepõem aos de treinamento.
• Os dados de treinamento não estão em ordem aleatória.

Avaliar em intervalos regulares pode facilitar a detecção desses problemas.

Os lotes parciais podem ocorrer quando os conjuntos de avaliação não são divisíveis pelo tamanho do lote. Certifique-se de que os exemplos preenchidos sejam ponderados corretamente (como na média ponderada sobre os exemplos que calculam a perda média no lote) para evitar que a função de perda seja enviesada por eles. Muitas vezes, você pode dar peso zero a esses exemplos preenchidos.

Salvar informações suficientes por avaliação para dar suporte à análise off-line. O ideal é salvar predições com base em uma seleção de exemplos individuais, já que eles podem ser valiosos para depuração. A geração de artefatos como SavedModels simplifica a inspeção do modelo 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 de avaliações off-line completo em um período razoável. Esse problema geralmente requer dados de amostragem para a avaliação periódica. Ao criar um conjunto de dados de amostra, considere problemas com tamanho de amostra e preocupações especiais em conjuntos de dados desequilibrados.

Tamanho da amostra

Verifique se o desempenho calculado no conjunto de dados de amostra usado pelo job periódico corresponde ao desempenho em todo o conjunto de avaliações off-line. Ou seja, verifique se não há distorções entre o conjunto de dados de amostra e o conjunto de dados completo.

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

• Pequeno o suficiente para gerar facilmente previsões de modelo em sua totalidade.
• Grande o suficiente para:
  • Avalie com precisão as melhorias no modelo, ou seja, as medições não podem ser sobrecarregadas pelo ruído do rótulo.
  • Acomode várias avaliações desse tipo em testes em sequência e ainda produza estimativas precisas. Ou seja, grande o suficiente para evitar o "ajuste" adaptável ao conjunto de validação ao longo do tempo de uma maneira que não generaliza com um conjunto de testes retidos. No entanto, essa consideração raramente é uma preocupação prática.

Conjuntos de dados desequilibrados

Para conjuntos de dados desequilibrados, o desempenho em classes raras de minoria geralmente é barulhento. Para conjuntos de dados com apenas um pequeno número de exemplos minoritários, registre o número previsto de exemplos corretamente para receber mais insights sobre melhorias de precisão. Por exemplo, a melhoria da sensibilidade de 0,05 parece emocionante, mas ela foi devido a mais um exemplo correto?

Como salvar checkpoints e selecionar retroativamente o melhor checkpoint

Resumo: faça o treinamento para um número fixo de etapas e escolha retrospectivamente o melhor ponto de verificação da execução.

A maioria dos frameworks de aprendizado profundo é compatível com pontos de verificação de modelo. Ou seja, o estado atual do modelo é salvo periodicamente no disco. O checkpoint permite que o job de treinamento seja resiliente para calcular interrupções da instância. O melhor checkpoint geralmente não é o último, especialmente quando o desempenho do conjunto de validação não continua aumentando com o tempo, mas flutua em torno de um valor específico.

Configure o pipeline para rastrear os N melhores checkpoints vistos até o momento durante o treinamento. Ao final do treinamento, a seleção do modelo significa simplesmente escolher o melhor checkpoint. Chamamos essa abordagem de seleção otimizada de ponto de verificação retrospectiva. O suporte a possíveis paradas antecipadas geralmente não é necessário porque você está especificando um orçamento de teste e preservando os N melhores checkpoints vistos até agora.

Como configurar o acompanhamento de experiências

Resumo: ao acompanhar diferentes experimentos, acompanhe uma série de itens essenciais, como o melhor desempenho de um checkpoint no estudo e uma breve descrição do estudo.

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
• Desempenho no conjunto de validação do melhor ponto de verificação do estudo.
• Comandos ou anotações de reprodução específicos sobre quais alterações 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. Experiências não acompanhadas podem não existir.

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

Resumo: atualmente, normalmente é possível substituir a normalização em lote por LayerNorm, mas nos casos em que não é possível fazer essa substituição, há detalhes complicados ao alterar 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 delas. No entanto, na configuração de vários dispositivos, essas estatísticas são diferentes em cada dispositivo, a menos que sejam explicitamente sincronizadas. Os relatórios pontuais (principalmente no ImageNet) indicam que o cálculo dessas estatísticas de normalização usando apenas cerca de 64 exemplos realmente funciona melhor na prática. Consulte a descrição da normalização em lote do Ghost em Treinar mais, generalize melhor: preenchendo a lacuna de generalização no treinamento em lote de redes neurais. A separação do tamanho total do lote e do número de exemplos usados para calcular as estatísticas da norma de lote é particularmente útil para comparações de tamanho de lote.

As implementações de normalização em lote fantasma nem sempre processam corretamente o caso em que o tamanho do lote por dispositivo é maior que o do lote virtual. Nesse caso, você precisa criar uma subamostra do lote em cada dispositivo para receber o número adequado de exemplos de estatísticas de norma de lote.

As médias móveis exponencials (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, você só precisa sincronizar essas EMAs antes de salvá-las em checkpoints. No entanto, algumas implementações comuns de normalização em lote não sincronizam essas EMAs e apenas salvam a EMA do primeiro dispositivo.

Considerações sobre pipelines de vários hosts

Resumo: para registro, avaliações, RNGs, checkpoint e fragmentação de dados, o treinamento de vários hosts pode facilitar a introdução de bugs.

Para pipelines de vários hosts, faça o seguinte:

• Verifique se o pipeline está apenas registrando e verificando um único host.
• Sincronize as estatísticas de normalização em lote em hosts antes de avaliar ou criar checkpoints.
• Fragmentar arquivos de dados entre hosts, já que isso geralmente melhora o desempenho.

Crítico: certifique-se de ter sementes de RNG iguais nos hosts (para inicialização de modelos) e sementes que sejam diferentes em hosts (para embaralhamento de dados/pré-processamento). Portanto, marque-os adequadamente.