Meu nome é Alexandra Tsareva. Meus colegas e eu estamos trabalhando em projetos na área de visão computacional no Machine Learning Center da Jet Infosystems. Gostaria de compartilhar nossa experiência no desenvolvimento e implantação de projetos na área de visão computacional.
Neste artigo, falarei sobre como o processo de trabalho de um datasetist em um projeto se parece não de um ponto de vista "espiritual" e, de fato, datasignist, mas mais de um organizacional. E espero que este post seja seguido por vários outros e consiga escrever uma pequena série.
Vou fazer dois pontos importantes imediatamente:
- Essas etapas se aplicam a quase qualquer projeto de conjunto de dados. Mas alguns momentos são causados pelo efeito exagero em torno do CV, alguma glória da "bala de prata" na visão computacional e o desejo do cliente de "tê-lo com a rede neural".
- , , — , - . , , ( , ..) , — - .
: ?
Quando um cliente decide que precisa de datasetists e algum tipo de inteligência artificial que o ajudará, em primeiro lugar, ele precisa entender que problema vai resolver. Nesta fase, um datasigner atua como um “psicanalista” de dados e pergunta detalhadamente sobre os dados, as restrições externas do ponto de vista dos negócios e os problemas que se gostaria de resolver em um mundo ideal. Muitas vezes, o cliente já sabe tudo sobre a tarefa futura - você só precisa ajudá-lo a entender e formalizar esse conhecimento (para entender seu mundo de dados interno, e às vezes - e chegar a um acordo com suas peculiaridades).
Claro, a visão computacional é uma área muito interessante, sempre há algo para contar e fazer com as mãos. Mas tudo isso é bastante caro - tanto em termos de horas de desenvolvimento, quanto no custo dos especialistas, e no equipamento necessário para eles. Não podemos deixar de nos perguntar se a solução ideal para o problema realmente requer currículo. Talvez existam outras ferramentas de aprendizado de máquina que sejam mais adequadas e possam resolver melhor o problema com um tempo de desenvolvimento mais curto e maior precisão?
Vou te mostrar a ideia com um exemplo simples. Um varejista queria implementar o reconhecimento de imagem CCTV para controlar quantas pessoas estão na fila no caixa. Pareceria uma tarefa óbvia - há um arquivo de vídeo, existem até redes neurais pré-treinadas - "contadores". Assine o cronograma, faça.
Mas, a partir de uma conversa com um varejista, o datainter aprende que a tarefa não está relacionada à carga no caixa em um determinado momento no tempo. A tarefa global não é chamar funcionários desnecessários para substituir, mas ao mesmo tempo evitar filas. O varejista tem um grande banco de dados que mostra a quantidade de clientes que visitaram a loja (se você viu os vendedores curvados sobre as esquadrias na saída da loja, viu a implementação mais simples de tal balcão), dados sobre compras no caixa ... E de fato, a tarefa não é conte as pessoas na fila, preveja a carga de trabalho nos caixas e otimize sua programação de trabalho.
Você pode, é claro, resolvê-lo contando as pessoas nos vídeos arquivados. Mas os dados tabulares geralmente são armazenados mais profundamente e mais fáceis de processar. É justo oferecer uma alternativa - talvez o cliente apenas tenha ouvido que o CV é incrível.
Portanto, no primeiro estágio, nos certificamos de que o problema que o cliente deseja resolver é realmente um problema de visão de máquina e que essa tecnologia é a mais adequada para resolvê-lo.
Etapa dois: como resolveremos o problema do CV e avaliaremos o sucesso da solução?
O segundo estágio é a formulação de um problema matemático, a escolha das métricas.
Existem soluções conhecidas, redes neurais, que podem resolver este problema? Talvez até um produto embalado? Se a tarefa for nova - talvez existam publicações nas quais possamos confiar e avaliar preliminarmente a qualidade alcançável?
Nesta fase, discutimos as métricas para resolver o problema do ponto de vista do nosso trabalho, como cientistas de dados, e do ponto de vista do cliente, no contexto da resolução de um problema empresarial.
Trabalhar com dados às vezes começa ao mesmo tempo que chegar a um acordo sobre a solução e as métricas, mas por conveniência, iremos separá-lo em uma etapa separada.
Etapa três: explorar e compreender nossos dados
É muito importante avaliar se temos dados suficientes para resolver a tarefa em questão. Obviamente, pequenos conjuntos de dados serão rejeitados mesmo na fase de configuração, mas no processo de conhecer o problema do negócio, novas nuances podem surgir. As situações são diferentes: podemos ter 1000 imagens, das quais apenas 10 pertencem à classe exigida, e nenhuma tecnologia secreta de visão de máquina nos ajudará.
Talvez compreendamos imediatamente que não é difícil tornar o conjunto de dados existente melhor - pedir aos funcionários que fotografem mais objetos do que são normalmente filmados, coletar alguns dados adicionais por meio de terceirização ou conjuntos de dados abertos.
No mesmo estágio, as deficiências são observadas em termos de aprendizado futuro do modelo, e muitas delas podem nos levar de volta à etapa de rediscutir a capacidade de resolução fundamental do problema. O exemplo mais comum é a baixa diversidade nos dados ou a sub-representação de uma das classes. É possível competir para aumentar a diversidade usando várias técnicas de aumento, mas isso nem sempre nos permite fazer um modelo pronto para o mundo real. No entanto, se nos parece que podemos lidar com as dificuldades dos dados, a quarta etapa vem em seu socorro.
Etapa quatro: desenvolver um modelo de protótipo
Neste estágio, não estamos falando de um modelo pronto para implementação, mas de um protótipo que nos responderá e ao cliente se vale a pena continuar trabalhando nessa direção, se o resultado possível atende às expectativas (nossas e, mais importante, do cliente). Depois de trabalhar com os dados, começamos a desenvolver um modelo piloto e avaliamos sua qualidade. Algumas coisas óbvias: neste estágio, o modelo é validado em relação a um conjunto de dados diferido. As duas opções principais são as imagens que colocamos de lado ou as imagens que nosso cliente digitou enquanto estávamos trabalhando no projeto.
O prazo de trabalho no projeto na fase piloto para o desenvolvimento de um protótipo é de no mínimo um mês. Durante esse tempo, na maioria dos casos, o cliente pode acumular dados para teste. Este é um bom teste para os cientistas de dados sobre a seriedade com que buscam resolver o problema: se pegarmos dados que nunca vimos, verificamos como nosso modelo pode generalizar e se ele se encaixa nas respostas ao conjunto de dados de validação (que, é claro, também é adiado. mas é tarde demais para descobrir que tudo mudou no mundo real desde então, seria uma pena).
Por outro lado, no momento de receber o conjunto de dados diferido, podemos descobrir em que medida os objetos que se enquadram na esfera de interesse do cliente do projeto (e isso também se aplica aos clientes internos) são estáveis e correspondem à amostra usada para treinar e validar o modelo. Afinal, tal situação é bem possível: a visão computacional está sendo implementada como um grande projeto para digitalizar tudo e todos e, no mesmo estágio, mudanças importantes ocorrem na fonte de dados (por exemplo, o transportador principal foi completamente reconstruído e as imagens provenientes dele mudaram fundamentalmente).
A análise dos resultados do piloto ajuda a decidir sobre o futuro do projeto. Pode acontecer que o cliente tenha requisitos muito elevados para o nível de precisão: por exemplo, 99% das respostas devem estar corretas e nas etapas anteriores parecia-nos que isso era fundamentalmente alcançável. Mas no piloto, alcançamos 93% de precisão e, é claro, não podemos prometer um ganho garantido de 6%. É lógico discutir as opções para o desenvolvimento do projeto com os resultados piloto disponíveis com o cliente - sobre como coletar dados adicionais, reduzir a métrica necessária ou mesmo congelar o projeto até novos avanços na esfera de CV.
As primeiras quatro etapas podem ser mostradas com o seguinte diagrama:
Eles levam muito menos tempo do que o desenvolvimento real. No entanto, o sucesso futuro do projeto está definido - o quanto ele atenderá às expectativas do cliente e realmente resolverá seu problema.
Etapa cinco: faça o resto;)
Todo o projeto, desde a confirmação do conceito até a solução implementada, será mais ou menos assim:
O plano e os termos de desenvolvimento do projeto são aproximados. Em projetos reais, sempre surgem nuances diferentes, pois os dados são diferentes para cada pessoa, são coletados em velocidades diferentes, e o estágio de introdução da visão computacional na própria empresa pode ser muito diferente dependendo de como a integração é planejada, de quem a está conduzindo, etc. .P. Afinal, uma coisa é instalar um sistema de identificação para os funcionários que entram no escritório com base em gravações de câmeras de vigilância por um longo período: podemos começar a trabalhar com elas imediatamente. É outra questão se tivermos um pequeno número de imagens de exemplo com as quais faremos uma prova de conceito - verificaremos se o problema está resolvido em princípio e quanto tempo levará para coletar um conjunto de dados completo, não sabemos.
Assim, o slide mostra um período de tempo muito aproximado para um projeto abstrato no vácuo, mas acho útil saber que o ciclo completo da prova de conceito à implementação e implementação leva cerca de um ano. Esses termos podem aumentar para tarefas complexas e diminuir caso a solução “fora da caixa” seja preferível ou o problema seja bem conhecido e não exija trabalho de pesquisa.