Os experimentos orientam a viabilidade de um projeto. Elas são hipóteses testáveis e reproduzíveis. Durante a execução de experimentos, o objetivo é fazer melhorias contínuas e incrementais avaliando uma variedade de arquiteturas e recursos de modelo. Durante os testes, faça o seguinte:
Determine o desempenho de referência. Comece estabelecendo uma métrica de valor de referência. A linha de base atua como uma barra de medição para comparar experimentos.
Em alguns casos, a solução atual que não é de ML pode fornecer a primeira métrica de referência. Se nenhuma solução existir no momento, crie um modelo de ML com uma arquitetura simples, alguns recursos e use as métricas dele como valor de referência.
Faça pequenas mudanças. Faça apenas uma pequena alteração por vez, por exemplo, nos hiperparâmetros, na arquitetura ou nos recursos. Se a mudança melhorar o modelo, as métricas dele se tornarão o novo valor de referência para comparar experimentos futuros.
Confira a seguir exemplos de experimentos que fazem uma única alteração pequena:
- incluem o recurso X.
- use 0,5 dropout na primeira camada escondida.
- use a transformação de registro do atributo Y.
- mudamos a taxa de aprendizado para 0,001.
Registre o progresso dos experimentos. Provavelmente, você precisará fazer muitos experimentos. Experimentos com qualidade de previsão ruim (ou neutra) em comparação com o valor de referência ainda são úteis para rastreamento. Eles sinalizam quais abordagens não funcionam. Como o progresso normalmente não é linear, é importante mostrar que você está trabalhando no problema destacando todas as maneiras como você encontrou que não funcionam, além do progresso em aumentar a qualidade de referência.
Como cada treinamento completo em um conjunto de dados real pode levar horas (ou dias), considere realizar vários experimentos independentes ao mesmo tempo para explorar o espaço rapidamente. Ao continuar a iterar, você vai se aproximar cada vez mais do nível de qualidade necessário para a produção.
Ruído nos resultados do experimento
Talvez você encontre ruído nos resultados experimentais que não são de mudanças no modelo ou nos dados, o que dificulta determinar se uma alteração feita realmente melhorou o modelo. Confira a seguir exemplos de coisas que podem produzir ruído nos resultados experimentais:
Embaralhamento de dados: a ordem em que os dados são apresentados ao modelo pode afetar o desempenho dele.
Inicialização da variável: a maneira como as variáveis do modelo são inicializadas também pode afetar o desempenho.
Paralelismo assíncrono: se o modelo for treinado usando paralelismo assíncrono, a ordem em que as diferentes partes do modelo são atualizadas também pode afetar o desempenho dele.
Conjuntos de avaliação pequenos: se o conjunto de avaliação for muito pequeno, talvez não seja representativo do desempenho geral do modelo, produzindo variações desiguais na qualidade dele.
Realizar um experimento várias vezes ajuda a confirmar os resultados.
Alinhar as práticas de experimentação
Sua equipe precisa ter uma compreensão clara do que é exatamente um "experimento", com um conjunto definido de práticas e artefatos. Você precisará de uma documentação que descreve o seguinte:
Artefatos. Quais são os artefatos de um experimento? Na maioria dos casos, um experimento é uma hipótese testada que pode ser reproduzida, geralmente ao registrar os metadados, como os recursos e hiperparâmetros, que indicam as mudanças entre os experimentos e como elas afetam a qualidade do modelo.
Práticas de programação. Todos usarão os próprios ambientes experimentais? Será que será possível (ou fácil) unificar o trabalho de todos em bibliotecas compartilhadas?
Reprodutibilidade e rastreamento. Quais são os padrões de reprodutibilidade? Por exemplo, a equipe deve usar as mesmas práticas de pipeline de dados e controle de versões ou exibir apenas gráficos? Como os dados experimentais serão salvos como consultas SQL ou snapshots do modelo? Onde os registros de cada experimento serão documentados: em um documento, uma planilha ou um CMS para gerenciar experimentos?
Previsões incorretas
Nenhum modelo real é perfeito. Como o sistema lidará com previsões erradas? Comece a pensar cedo em como lidar com eles.
Uma estratégia de práticas recomendadas incentiva os usuários a rotular corretamente previsões erradas. Por exemplo, apps de e-mail capturam e-mails classificados incorretamente registrando os e-mails que os usuários movem para a pasta de spam e vice-versa. Ao capturar rótulos de informações empíricas dos usuários, é possível criar ciclos de feedback automatizados para coleta de dados e retreinamento de modelos.
Embora as pesquisas incorporadas à interface capturem o feedback do usuário, os dados geralmente são qualitativos e não podem ser incorporados aos dados de retreinamento.
Implemente uma solução completa
Enquanto sua equipe faz testes com o modelo, é uma boa ideia começar a criar partes do pipeline final, se você tiver os recursos para fazer isso.
Estabelecer diferentes partes do pipeline, como entrada de dados e retreinamento do modelo, facilita a migração do modelo final para produção. Por exemplo, ter um pipeline completo para ingerir dados e exibir previsões pode ajudar a equipe a começar a integrar o modelo ao produto e realizar testes de usuários em estágio inicial.
Solução de problemas de projetos parados
Você pode estar em cenários em que o progresso de um projeto para. Talvez sua equipe esteja trabalhando em um experimento promissor, mas não tenha sucesso na melhoria do modelo há semanas. O que você deve fazer? Confira algumas abordagens possíveis:
Estratégica. Talvez você precise reformular o problema. Depois de passar um tempo na fase de experimentação, você provavelmente entende melhor o problema, os dados e as possíveis soluções. Com um conhecimento mais profundo do domínio, você provavelmente pode enquadrar o problema com mais precisão.
Por exemplo, talvez você quisesse inicialmente usar a regressão linear para prever um valor numérico. Infelizmente, os dados não eram bons o suficiente para treinar um modelo de regressão linear viável. Talvez outras análises revelem que o problema pode ser resolvido prevendo se um exemplo está acima ou abaixo de um valor específico. Assim, é possível transformar o problema em uma classificação binária.
Se o progresso for mais lento do que o esperado, não desista. Melhorias incrementais ao longo do tempo podem ser a única maneira de resolver o problema. Como observado anteriormente, não espere o mesmo progresso a cada semana. Muitas vezes, conseguir uma versão pronta para produção de um modelo requer uma quantidade significativa de tempo. A melhoria do modelo pode ser irregular e imprevisível. Períodos de progresso lento podem ser seguidos por picos de melhoria ou o inverso.
Técnico. Dedique seu tempo a diagnosticar e analisar previsões erradas. Em alguns casos, o problema pode ser encontrado isolando algumas previsões erradas e diagnosticando o comportamento do modelo nessas instâncias. Por exemplo, é possível descobrir problemas com a arquitetura ou com os dados. Em outros casos, conseguir mais dados pode ajudar. Você pode receber um sinal mais claro que sugere que você está no caminho certo ou pode produzir mais ruído, indicando que outros problemas existem na abordagem.
Se você estiver trabalhando em um problema que requer conjuntos de dados rotulados por humanos, pode ser difícil conseguir um conjunto de dados rotulado para avaliação de modelo. Encontre recursos para receber os conjuntos de dados necessários para a avaliação.
Talvez nenhuma solução seja possível. Defina um cronograma da abordagem, parando caso não tenha feito progressos dentro do período. No entanto, se você tem uma boa declaração de problema, ela provavelmente justifica uma solução.