O que Machine Learning pode aprender com DevOps

O fato do desenvolvimento de aprendizado de máquina focar no ajuste de hiperparâmetros e nos pipelines de dados não significa que precisamos reinventar a roda ou procurar uma maneira completamente nova. De acordo com Thiago de Faria, o DevOps estabelece uma base sólida: a mudança de cultura para apoiar a experimentação, a avaliação contínua, o compartilhamento, camadas de abstração, a observabilidade e o trabalho em produtos e serviços.

Thiago de Faria, líder DataOps e IA na LINKIT, falou sobre IA com uma mentalidade de DevOps no Codemotion Berlin 2018.

O desenvolvimento de aplicativos com funções if/else, loops e determinísticas, encapsula a grande maioria dos casos no setor. As ferramentas que construímos para dar suporte ao ecossistema, como depuração e testes... tudo isso foi projetado com esses casos de uso em mente. Uma perspectiva diferente deve surgir para as aplicações de ML, argumentou de Faria.

Os profissionais de data science também devem absorver muitos dos ganhos do setor, um resultado direto da cultura DevOps: artefatos implantáveis, observabilidade, cultura de compartilhamento, experimentação e falha em seu núcleo e também trabalhar em produtos e serviços, destaca de Faria.

Levar as pessoas as "maiores dificuldades das operações", ajuda a melhorar a qualidade dos produtos, argumentou de Faria.

O InfoQ conversou com de Faria sobre a aplicação de aprendizado de máquina com DevOps.

InfoQ: Qual é a sua definição de inteligência artificial e aprendizado de máquina?

Thiago de Faria: Minha definição não é verdadeira nem única. Costumo apontar isso no início das palestras para ter um ponto em comum com o público, porque notei que às vezes o ML, a IA, ciência de dados, deep learning e tudo isso é dado como a mesma coisa.

A Inteligência Artificial (IA) está tornando os computadores capazes de fazer coisas que, quando feitas por um humano, poderiam exigir uma inteligência única. O aprendizado de máquina (ML) é uma das maneiras de construir a parte de inteligência, certificando-se de que essas máquinas possam encontrar padrões sem explicitamente programá-las para isso.

Para torná-lo menos vago, especialmente a parte de ML, podemos imaginar o seguinte:

• As imagens digitais são compostas de valores de RGB em cada pixel, variando de 0 a 255;
• Se quiser criar uma regra para identificar gatos em fotos, pode-se tentar fazer isso com loops tradicionais if/else e regras;
• Quando o quarto pixel tem um valor RGB (24, 42, 255) e o quinto pixel é (28, 21, 214) - é um gato;
• Consegue-se imaginar todas as possibilidades de if/else teria-se que escrever? Infinitas! Além disso, quando se tem uma nova imagem que nunca viu, pegaria ela em uma cláusula? Isso torna o mundo extremamente binário e difícil de se ver;

O aprendizado de máquina nos permite ter algoritmos, que, com base no aprendizado estatístico (um processo em que se tenta encontrar uma função preditiva baseada nos dados que se possui), pode dar a chance de que a essa foto contenha um gato, e serem treinados com base em dados.

InfoQ: Quais são os desafios que vêm com inteligência artificial e aprendizado de máquina em relação à integração com desenvolvimento e implantação?

De Faria: Os desafios são os mesmos que resolvemos para o desenvolvimento tradicional, mas com uma perspectiva diferente agora: controle de versão, empacotamento, implantação, colaboração e servir. A questão principal é que estamos tentando forçar as soluções que usamos antes no desenvolvimento de software para esse ecossistema.

No passado, vimos um aumento significativo no número de produtos (especialmente Open Source) tentando resolver o ciclo de vida de desenvolvimento do ML - o Spark executa em cima do Kubernetes, tensorflow, kubeflow, MLflow, Michelangelo do Uber e provedores de nuvem fornecendo ferramentas que permitem o treinamento e serviço de modelos. Estamos testemunhando a maturação desse ecossistema e é um ambiente em crescimento.

InfoQ: E quanto a erros e testes, como isso funciona com componentes de ML?

De Faria: No que diz respeito aos bugs, é importante manter-se atento aos erros de aprendizado de máquina: Preconceito (Bias), Flutuação (Drift) e Fragilidade.

O preconceito vem da tendência existente nos conjuntos de dados usados ​​para criar o recurso e pode ter resultados catastróficos, especialmente quando usado em modelos semelhantes à caixa preta como no caso do DeepLearning. A ferramenta de IA 'sexista' da Amazon é um exemplo de modelo ML que passou em todos os testes da empresa e ficou conhecida por sua alta qualidade de engenharia. No entanto, ao tentar filtrar e recrutar engenheiros de software, os dados são tendenciosos porque fazemos parte de uma indústria em que as mulheres são um grande grupo sub-representado. Isso significa que o algoritmo estava desfavorecendo as candidatas mulheres, uma vez que não havia muitos casos no grupo de treinamento. Isso também pode acontecer em sistemas de pontuação de hipotecas e em muitos outros negócios. Armas de Destruição Matemática de Cathy O'Neil é um livro de 2016 que levantou muitos desses problemas em algoritmos que tomam decisões importantes sobre contratação, classificação de pessoas e outros.

A flutuação ocorre quando os modelos são construídos, funcionam bem e são implantados. Podemos considerar o trabalho entregue e nada mais, certo? Infelizmente não. O modelo deve ser recalibrado e ressincronizado de acordo com o uso e os dados para manter a precisão. Caso contrário, ele decairá e piorará com o tempo.

A fragilidade está relacionada ao preconceito, mas é mais relacionada a mudanças fora do alcance da equipe. Uma mudança na definição, dados que ficam indisponíveis, um valor nulo que não deveria estar lá. Como seu modelo pode lidar com esses problemas, o quão frágil ele é?

A pior parte é que a maioria desses bugs no ML não pode ser identificada antes da produção. É por isso que o monitoramento e a observabilidade, outros pilares do DevOps, desempenham um papel gigantesco nos componentes de aprendizado de máquina. Deve-se avaliar os proxies que identificam o valor de negócios que seus componentes de ML devem impactar. Por exemplo, se cria um mecanismo de recomendação e está aplicando uma estratégia de teste AB para implantação? Vamos ver a variação do gasto entre os dois grupos. Ou talvez exista um componente de marcação de imagem agora, as pessoas estão usando os recursos em torno dele? Não se pode rastrear diretamente os componentes do ML, mas poderá analisar as medidas do proxy nele. Estes tipos de métricas e com foco na medição podem ajudar a detectar e abordar os bugs do ML desde o início: preconceitos, flutuação e fragilidade.

InfoQ: Você falou sobre a distância entre a ciência de dados e as operações. O que está causando essa distância?

De Faria: O mesmo problema que afetou (e ainda afeta) o mundo dos negócios e "deu origem" ao movimento DevOps, uma distância entre o negócio e a industrialização ou operacionalização do que é construído. Essa lacuna é o resultado de três coisas: lentidão (coisas que vão da ideia à produção tomando um tempo gigantesco), muitas entregas (X fala com o cliente, A escreve a história do usuário, B constrói, C valida, D aprova, E implanta, F opera, G corrige bugs, H reconstrói, etc.) e agrupar equipes trabalhando em projetos, não em produtos. O livro Accelerate e o relatório "State of DevOps" da Dra. Nicole Forsgren, Jez Humble e Gene Kim (co-fundadores da DORA) são bons lugares para investigar isso. Essa distância está ficando mais explícita e mais evidente à medida que as organizações começam a mudar a maneira como abordam o ciclo de vida de desenvolvimento e entrega de software. Por quê? Porque podemos ver muitas vitórias organizacionais na adoção de novas práticas, ferramentas e fazendo o mais difícil: mudar a cultura.

InfoQ: O que podemos fazer para diminuir distâncias e melhorar a colaboração?

De Faria: Novamente, a coisa mais difícil que qualquer organização pode fazer: mudar a cultura. No caso dos engenheiros e cientistas de dados de ML, alguns aspectos culturais podem impactar muito, mas o mais convincente que já vi está relacionado ao histórico dos profissionais. A maioria deles tem um background muito acadêmico, o que significa que eles estão acostumados a passar longos períodos trabalhando em um problema até que seja bom o suficiente para ser aceito em uma publicação. A barra lá, para ser boa o suficiente, é extremamente alta, não apenas em algumas métricas, mas também no design dos experimentos, no rigor matemático e assim por diante. Em um contexto de negócios, isso é importante, mas é menos importante. Isso significa que não há problema em publicar um modelo com precisão de 60% e colocá-lo em um estado implantável. É melhor ter isso pronto e considerar colocá-lo em produção hoje, do que esperar meses para ter algo "bom o suficiente". Talvez em três meses isso não seja mais um problema a ser resolvido. Mover-se rapidamente com possibilidades flexíveis é o melhor caminho a percorrer.

InfoQ: Qual é o seu conselho para empresas que desejam colher os benefícios da aplicação de inteligência artificial e aprendizado de máquina? O que eles devem fazer ou não fazer?

De Faria: Treinar cientistas de dados e gerar valor a partir de técnicas de ML para construir aplicações de IA é extremamente difícil. Para tornar viável, divertido e atrair esses profissionais, precisamos mudar a cultura em torno disso. É difícil criar um caminho para essa "cultura ótima", pois cada empresa tem seu próprio caminho e as interações são difíceis. Algumas características culturais que tenho visto e que suportam um curto período de tempo no mercado e nos quais muito valor é gerado a partir da ciência de dados incluem:

• Ciência de dados: a parte "ciência" indica experimentação e tentativas fracassadas. Nem todos os experimentos são bem-sucedidos, portanto, a ciência de dados não produzirá soluções alucinantes em todos os momentos. Às vezes pode-se entrar em um buraco de coelho. Alternativamente, o negócio pode mudar. Então a questão é: se o colaborador é um cientista de dados trabalhando em um projeto por alguns dias e não vê futuro nisso, ele teria coragem e autonomia para dizer isso ao seu chefe ou stakeholders? Da mesma forma, o inverso, eles podem vir até a liderança a qualquer momento e dizer que o negócio mudou e que devemos pivotar?
• Mais do que CI/CD, precisamos falar sobre CE avaliação contínua. Toda vez que um novo modelo é testado, podem haver novos hiperparâmetros no mesmo algoritmo ou um algoritmo completamente novo, devemos ser capazes de compará-lo com execuções anteriores. Quão preciso foi? Por que o resultado é diferente? Estamos usando o mesmo conjunto de dados? Isso é fundamental para um bom uso dos recursos e uma experiência de aprendizado dentro da empresa. Assim, vamos implementar pipelines CI / CD / CE!
• Não compartilhe apenas seus bons modelos, mas também aqueles que são um fracasso total! Controle o versionamento do seu código e de seus modelos, em todos os momentos! Aprenda a usar o git a cada momento! Por quê? Porque quando alguém vê isso, não tentarão novamente com os mesmos conjuntos de dados e parâmetros, elimine o desperdício!
• Fornecer plataformas e ferramentas para a ciência de dados para abstrair as coisas que eles não conhecem (e eles não precisam saber). Um cientista de dados pode não saber se deseja servir seus modelos em REST ou gRPC, como empacotar o modelo, se ele deve ser implantado no cluster do Kubernetes ou quantas solicitações por segundo ele deve suportar, isso não é sua especialidade. Uma equipe deve fornecer uma plataforma e ter um pipeline para fazer isso e permitir que as decisões sejam tomadas, experimentadas e alteradas. O problema aqui é que as empresas "vendem a plataforma bala de prata". Toda empresa tem seu fluxo, formas de trabalhar e idéias, não faça a cultura se curvar à ferramenta.
• Trabalhar em produtos e serviços, não projetos. Desenvolvedores, especialistas em segurança e SRE's, todos devem estar envolvidos e ajudar. Ao fazer isso, pode-se garantir que tenha artefatos implantáveis ​​desde o primeiro dia! Depois que ele é implantado, o trabalho não acaba. É preciso operar, monitorar, refatorar, calibrar e fazer várias coisas com modelos ML em execução na produção.

Sobre o entrevistado

Thiago de Faria é chefe de engenharia de soluções da LINKIT, na Holanda. Ele começou com Matemática Pura, pulou para predições e percebeu que isso era totalmente dependente da compreensão entre as partes internas do desenvolvimento de software e dos pipelines de dados. Assim, sua principal preocupação mudou: como preencher a lacuna entre ML e produção? Ele é uma parte ativa da comunidade (devopsdays Amsterdam, ITNEXT / Codemotion), compartilhador de conhecimento, pai orgulhoso e fã de Blues. De Faria é patologicamente curioso e um aprendiz contínuo. Ele sabe que as equipes de dados de alto desempenho devem diminuir o tempo de lançamento no mercado e criar aplicativos prontos para produção, sempre!