Durante um ano e meio, tenho mantido o cargo de principal desenvolvedor de ML na minha empresa. Seis meses, gerencio uma equipe pequena. Ganhei experiência que quero compartilhar. Farei isso no formato de um top de erros e possíveis dificuldades.
Queremos uma rede neural!
Muitas pessoas ouviram pelo menos algo sobre inteligência artificial e as conquistas das redes neurais. Algumas pessoas querem usar redes neurais nos negócios apenas porque são populares. Então, você resolveu uma pequena tarefa de análise de texto e pode declarar com segurança para todos que sua empresa usa as mais modernas tecnologias de inteligência artificial.
Além disso, quase ninguém entende os pontos fortes e fracos das redes neurais. De fato, devido ao alto consumo de recursos, eles estão longe de ser sempre o modelo ideal.
Frequentemente, algoritmos como boosting, vizinhos mais próximos k ou svm podem mostrar indicadores de qualidade mais altos na solução de problemas de negócios (se estamos falando sobre os recursos clássicos de script -> valor) do que as redes neurais. Isso apesar do fato de serem muito mais leves.
Se um cliente lhe disser: “Precisamos de uma rede neural para resolver esse e aquele problema”, provavelmente ele simplesmente não sabe quais são as melhores ferramentas para resolver esse problema. Mas parece-lhe que alguns algoritmos complicados são necessários aqui e a única coisa que vem à sua mente é uma rede neural.
Então você pode resolver o problema através de um modelo mais leve.
Parece óbvio, mas, de fato, após uma solicitação do cliente, você pode passar um tempo classificando várias arquiteturas de redes neurais antes de perceber que a tarefa pode ser resolvida com muito mais facilidade.
Dados da manhã, noite estimeyta
Frequentemente, você será solicitado a fornecer prazos para a realização de experimentos / implementação de soluções no produto. Além disso, como base para essas estimativas, podemos fornecer apenas uma descrição abstrata do problema. Por exemplo: “Queremos uma rede neural que, de acordo com imagens médicas, diagnostique uma pessoa com uma doença. Quanto tempo vai demorar? Pessoas que não trabalharam com ML (e às vezes trabalharam) têm pouco entendimento do conceito de experimentos. Muitos abordam o desenvolvimento de soluções de ML como desenvolvimento de software padrão. Mas todos esses são erros. O desenvolvimento do ML está mais próximo da ciência do que do desenvolvimento (especialmente nos estágios iniciais). Na maioria das vezes é necessário para análise de dados e experimentos. E as pessoas raramente entendem isso.
Se você tiver sorte e tiver, por exemplo, um gerente de projeto experiente, não precisará lidar com esses problemas. Ele mesmo explicará tudo ao cliente. Mas acontece o contrário - quando o próprio gerente entende mal as especificidades da ML, se inclina sob o cliente e começa a chutá-lo junto com ele, exigindo os prazos alguns dias ou uma semana após receber uma solicitação do cliente. Às vezes, mesmo antes de receber dados. Então, você provavelmente terá que nomear algumas datas (bem, ou alterar o local de trabalho, o que também é uma boa opção nessa situação). Mas tome cuidado se você decidir fazer uma estimativa da linha do tempo sem informações suficientes. Tire um tempo para experimentar a margem.
Precisão do modelo no experimento preliminar 99.99999%
Mesmo se você recebeu métricas altas nas experiências preliminares ou ao testar o protótipo, esse não é um motivo para comunicá-las imediatamente ao cliente. Mas tudo o que você diz pode ser usado contra você.
Se você obtiver altos valores de estimativas de qualidade do modelo em experimentos preliminares, poderá dizer ao cliente que o problema é exclusivamente solucionável, mas não deve encantá-lo com números antecipados, o que pode não ser tão bom em novos dados. Ou você pode ligar para métricas, mas com a reserva obrigatória, não é possível garantir que, em outras condições, a qualidade permaneça a mesma. Pode melhorar e piorar. Sempre há a opção de você estar brega demais ao realizar experimentos (gerador gravado incorretamente, por exemplo, e alguns dados vazaram do treinamento para o teste).
Como alternativa, você pode fixar pagamentos diferentes no contrato para diferentes qualidades finais do seu modelo.
De um modo geral, as pessoas geralmente confiam mais em exemplos concretos do que em números abstratos. Uma pequena demonstração do seu modelo dará ao cliente mais confiança do que declarações com precisão de 99%.
Se você está resolvendo um problema, por exemplo, de detecção / classificação usando técnicas neurais convolucionais e é hora de escrever um relatório sobre o sucesso da equipe por um período condicional, gaste 30 minutos extras e faça algumas fotos bonitas: brinque com a visualização de filtros convolucionais em altos níveis de abstração ou em camadas ocultas totalmente conectadas, faça mapas de calor das aulas, etc.
Não haverá problemas com os servidores
Em algum momento, comecei a perceber que o trabalho do modelo geralmente se baseia em seu tamanho. Por exemplo, quando você precisa criar um classificador para 5 milhões de classes, mesmo os modelos mais simples podem consumir muitos recursos. Então, naturalmente, surge a pergunta sobre a especificação do servidor, que o cliente pode descartar com algo como: "Não haverá problemas com os servidores - escolheremos algo nos serviços em nuvem".
O problema é que ele pode não representar a escala do modelo. Por exemplo, um conjunto de dados pesa 2 terabytes e a matriz de peso do modelo treinado é de outros 500 gigabytes. Para usar esse modelo, você precisa de 68 a 128 GB de RAM. Alugar um carro assim pode custar a um cliente de vários milhares a várias dezenas de milhares de dólares por mês (se forem necessárias mais GPUs). E aqui, muitos não concordam em pagar por esses servidores.