Os dados são tão importantes para os desenvolvedores de ML quanto o código para os programadores tradicionais. Esta lição se concentra nos tipos de perguntas que você precisa fazer sobre seus dados.
Resumo da aula sobre vídeo
O comportamento de um sistema de ML depende do comportamento e das qualidades dos recursos de entrada. Os dados de entrada desses atributos também mudam, assim como o modelo. Às vezes, a mudança é desejável, mas não é.
No desenvolvimento de software tradicional, você se concentra mais no código do que nos dados. No desenvolvimento de machine learning, embora a programação ainda faça parte do job, seu foco precisa ser ampliado para incluir dados. Por exemplo, em projetos de desenvolvimento de software tradicionais, é recomendável programar testes de unidade para validar o código. Em projetos de ML, também é preciso testar, verificar e monitorar continuamente os dados de entrada.
Por exemplo, é preciso monitorar continuamente seu modelo para remover os recursos não utilizados (ou pouco usados). Imagine um determinado atributo que contribui pouco ou nada para o modelo. Se os dados de entrada desse recurso mudarem abruptamente, o comportamento do seu modelo também pode mudar abruptamente de maneira indesejável.
Confiabilidade
Algumas perguntas a serem feitas sobre a confiabilidade dos dados de entrada:
- O sinal vai estar sempre disponível ou é de uma
fonte não confiável? Exemplo:
- O sinal está vindo de um servidor que falha sob carga pesada?
- O sinal vem de humanos que vão de férias todos os anos?
Controle de versões
Algumas perguntas a serem feitas sobre o controle de versões:
- O sistema que calcula esses dados muda? Nesse caso, faça o seguinte:
- Com que frequência?
- Como você sabe quando esse sistema muda?
Às vezes, os dados vêm de um processo upstream. Se esse processo mudar abruptamente, seu modelo pode sofrer.
Considere criar sua própria cópia dos dados recebidos do processo upstream. Em seguida, avance para a próxima versão dos dados upstream quando tiver certeza de que é seguro fazer isso.
Necessidade
A seguinte pergunta pode lembrar você de regularização:
- A utilidade do recurso justifica o custo de inclusão?
É sempre tentador adicionar mais atributos ao modelo. Por exemplo, suponha que você encontre um novo atributo com uma adição que torne seu modelo um pouco mais preciso. Uma precisão certa é melhor do que com menos precisão. No entanto, agora você acabou de aumentar a carga da manutenção. Esse recurso pode ser degradado inesperadamente, portanto, é preciso monitorá-lo. Pense com cuidado antes de adicionar recursos que levem a pequenas vitórias de curto prazo.
Correlações
Alguns atributos estão correlacionados (positiva ou negativamente) com outros. Faça esta pergunta:
- Existe algum recurso tão complexo que é preciso chamar a atenção para outras estratégias?
Ciclos de feedbacks
Às vezes, um modelo pode afetar os próprios dados de treinamento. Por exemplo, os resultados de alguns modelos, por sua vez, são atributos de entrada direta ou indiretas para esse mesmo modelo.
Às vezes, um modelo pode afetar outro. Por exemplo, considere dois modelos para prever preços de ações:
- Modelo A, que é um modelo preditivo inadequado.
- Modelo B.
Como o modelo A tem bugs, ele decide comprar um estoque estocado por engano. Essas compras impulsionam o preço da ação X. O modelo B usa o preço do estoque X como atributo de entrada, portanto, o modelo B pode facilmente chegar a algumas conclusões falsas sobre o valor do estoque X. O modelo B, portanto, poderia comprar ou vender ações da bolsa X com base no comportamento com bugs do modelo A. O comportamento do modelo B, por sua vez, pode afetar o modelo A, possivelmente acionando uma mania de tulipas ou um slide no inventário da empresa X