👇🏻 😁 🌥️ Por que precisamos do DevOps no campo de dados ML 🦐 🧘🏾 🏊

A implantação do aprendizado de máquina (ML) na produção não é uma tarefa fácil, mas, na verdade, é uma ordem de magnitude mais difícil do que a implantação de software convencional. Como resultado, a maioria dos projetos de ML nunca verá a luz do dia - e a produção - já que a maioria das organizações desiste e desiste de tentar usar o ML para promover seus produtos e atender os clientes.

Até onde podemos ver, o obstáculo fundamental para a maioria das equipes criar e implantar ML na produção na escala esperada é que ainda não conseguimos introduzir práticas de DevOpsno aprendizado de máquina. O processo de criação e implantação de modelos de ML é parcialmente divulgado pelas soluções MLOps que já foram lançadas, mas elas não têm suporte de um dos aspectos mais difíceis dos ML: dados.

Neste artigo, discutimos por que o setor precisa de soluções DevOps para dados de ML e como as dificuldades exclusivas dos dados de ML dificultam os esforços para colocar em prática o ML e implementá-lo na produção. O artigo descreve o vácuo no atual ecossistema de infraestrutura de ML e sugere preenchê-lo com o Tecton, uma plataforma de dados centralizada para aprendizado de máquina. Clique aqui para ler um artigo do meu co-fundador Mike para obter mais detalhes sobre o lançamento do Tecton.

A Tecton foi criada por uma equipe de engenheiros que criou plataformas internas de ML para empresas como Uber, Google, Facebook, Twitter, Airbnb, AdRoll e Quora. Os investimentos significativos dessas empresas em ML permitiram o desenvolvimento de processos e ferramentas para o uso extensivo de ML em suas organizações e produtos. As lições apresentadas neste artigo, bem como a própria plataforma Tecton, são amplamente baseadas na experiência de nossa equipe de implantação de ML em produção nos últimos anos.

Lembra da época em que a versão do software foi longa e dolorosa?

O processo de desenvolvimento e implantação de software há vinte anos e o processo de desenvolvimento de aplicativos ML de nossos dias têm muito em comum: os sistemas de feedback se tornaram incrivelmente longos e, quando você chegou ao lançamento do produto, seus requisitos e design iniciais já haviam se tornado obsoletos. E então, no final dos anos novatos, surgiu um conjunto de práticas recomendadas para o desenvolvimento de software na forma de DevOps , fornecendo métodos para gerenciar o ciclo de vida do desenvolvimento e permitindo melhorias contínuas e rápidas.

A abordagem do DevOps permite que os engenheiros trabalhem em uma base de código comum bem definida. Quando uma alteração em fases está pronta para implantação, o engenheiro a valida por meio de um sistema de controle de versão. O processo de integração e entrega contínuas (CD / CI) realiza as alterações mais recentes, realiza testes de unidade, cria documentação, realiza testes de integração e, como resultado, de maneira controlada libera alterações na produção ou prepara uma liberação para distribuição.

FIG. 1: processo típico do DevOps

Recursos principais do DevOps:

Os programadores possuem seu código do início ao fim. Eles são capacitados e totalmente responsáveis por todas as linhas de código em produção. Esse senso de propriedade geralmente melhora a qualidade do código, bem como a disponibilidade e a confiabilidade dos programas.
As equipes são capazes de repetir rapidamente os processos e não são limitadas pelos ciclos de meses do modelo em cascata. Em vez disso, eles são capazes de testar novos recursos com usuários reais quase imediatamente.
Problemas de desempenho e confiabilidade são rapidamente detectados e analisados. Se as métricas de desempenho caírem imediatamente após a última implantação, uma reversão automática será acionada e as alterações que causaram a implantação no código provavelmente causarão a queda das métricas.

Atualmente, muitas equipes de desenvolvimento adotam uma abordagem tão integrada como base.

... Em geral, a implantação do ML ainda é longa e dolorosa

Ao contrário do desenvolvimento de software, não há processos bem definidos e totalmente automatizados para produção rápida em análise de dados. O processo de criação de um aplicativo ML e sua implantação em um produto consiste em várias etapas:

Fig. 2: especialistas em análise de dados precisam coordenar seu trabalho entre várias equipes em diferentes áreas

Descoberta e acesso aos dados de origem. Os especialistas em ciência de dados na maioria das empresas gastam até 80% do tempo pesquisando dados de origem para modelar seu problema. Isso geralmente requer coordenação interfuncional com os engenheiros de dados e a equipe de regulamentação.
. , . , , .
. . ( ).
Implantação e integração do modelo. Essa etapa geralmente envolve a integração com um serviço que usa o modelo para previsão. Por exemplo, o aplicativo móvel de um varejista on-line que usa um modelo de recomendação para prever ofertas de produtos.
Monitorando a configuração. Mais uma vez, para garantir que o modelo de ML e os processos de dados funcionem corretamente, é necessária a ajuda dos programadores.

Como resultado, as equipes de ML enfrentam os mesmos problemas que os programadores enfrentaram vinte anos atrás:

Os especialistas em ciência de dados não possuem a propriedade total do ciclo de vida de modelos e funcionalidades. Para implantar suas edições e apoiá-las na produção, elas precisam confiar em outras.
data science . . . , , data science, , , , , .

. 3: ,

. data science, . , , , .

DevOps ML . DevOps ML data

Essas plataformas MLOps , como a Sagemaker Kubeflow, se movem na direção certa para ajudar as empresas a simplificar a produção de ML, para que possamos observar como o MLOps introduz princípios e ferramentas de DevOps no ML. Para começar, eles precisam de investimentos iniciais bastante decentes, mas após a integração adequada, eles podem expandir os recursos dos especialistas em ciência de dados no campo de treinamento, gerenciamento e produção de modelos de ML.

Infelizmente, a maioria das ferramentas MLOps tende a se concentrar no fluxo de trabalho em torno do próprio modelo (treinamento, implementação, gerenciamento), o que cria várias dificuldades para os MLs existentes. Os aplicativos de ML são definidos por código, modelos e dados.. O sucesso deles depende da capacidade de criar dados ML de alta qualidade e entregá-los à produção com rapidez e estabilidade ... caso contrário, esse é outro "lixo para dentro, lixo para fora". O diagrama a seguir, especialmente selecionado e adaptado do trabalho do Google sobre dívida técnica em ML, ilustra os elementos "centralizado em dados" e "centralizado em modelo" nos sistemas de ML. Hoje, as plataformas MLOps ajudam com muitos elementos "centrados no modelo", mas apenas com alguns elementos "centrados nos dados" ou nem sequer os afetam:

Fig. 4: Modelo e elementos atacêntricos dos sistemas ML. Hoje, os elementos centrados no modelo são amplamente cobertos pelos sistemas MLOps.

A próxima seção demonstra alguns dos testes mais difíceis que encontramos na simplificação da produção de ML. Eles não são exemplos abrangentes, mas foram projetados para mostrar os problemas que encontramos durante o gerenciamento do ciclo de vida dos dados do ML (funções e rótulos):

Acesso a fontes de dados de origem corretas
Criando funções e etiquetas a partir dos dados de origem
Combinando funções nos dados de treinamento
Cálculo e emissão de funções em produção
Rastreamento de produção

Um pequeno lembrete antes de mergulharmos mais: a função ML é os dados que servem como entrada para o modelo para tomar uma decisão. Por exemplo, um serviço de entrega de comida deseja mostrar o tempo de entrega esperado em sua aplicação. Para fazer isso, é necessário prever a duração da preparação de um prato específico, em um restaurante específico, em um horário específico. Um dos sinais convenientes para a criação de tal previsão - um proxy da ocupação do restaurante - será a "conta final" dos pedidos recebidos nos últimos 30 minutos. A função é calculada com base no fluxo dos dados iniciais da ordem de pedido:

Fig. 5: Os dados iniciais são alterados pela transformação da função em valores da função

Data do Teste # 1: Acessando os Dados de Origem Corretos

Para criar qualquer função ou modelo, um especialista em ciência de dados precisa primeiro encontrar a fonte de dados correta e obter acesso a ela. Existem vários obstáculos ao longo do caminho:

Descoberta de dados: os profissionais precisam saber onde estão os dados de origem. Uma ótima solução são os sistemas de catalogação de dados (como o Amundsen da Lyft ), mas eles ainda não são usados tão universalmente. Frequentemente, os dados necessários simplesmente não existem e, portanto, devem primeiro ser criados ou catalogados.
Aprovação do acesso: Frequentemente, circular entre as autoridades para obter permissões para acessar dados que resolverão problemas é uma etapa obrigatória no caminho dos especialistas em ciência de dados.
: , , . , .

- #2:

Os dados de origem podem vir de várias fontes, cada uma com suas próprias propriedades importantes que afetam os tipos de funções extraídas delas. Essas propriedades incluem suporte da fonte de dados para tipos de transformação , relevância dos dados e a quantidade de arquivamento de dados disponível :

Fig. 6: Diferentes fontes de dados têm abordagens diferentes para diferentes tipos de transformação de dados e fornecem acesso a diferentes quantidades de dados, dependendo da relevância.É

importante levar essas propriedades em consideração, uma vez que os tipos de fontes de dados determinam os tipos de funções que um especialista em ciência de dados pode obter dos dados de origem:

( Snowflake Redshift) ( ). , , « ».
( MongoDB MySQL) . , 24 .
( Kafka) ( ). . , « 30 ».
Os dados da consulta de previsão são os dados iniciais dos eventos que ocorrem em tempo real, pouco antes da previsão da ML, por exemplo, uma consulta inserida pelo usuário na barra de pesquisa. Mesmo que esses dados sejam limitados, geralmente são "frescos" o máximo possível e contêm um sinal facilmente previsível. Esses dados são fornecidos com uma solicitação de previsão e podem ser usados em cálculos em tempo real, como a pesquisa de estimativas de similaridade entre a consulta de pesquisa de um usuário e os documentos em uma matriz de pesquisa.

No futuro, chamamos atenção para: combinar dados de diferentes fontes com características complementares permite criar funções realmente boas. Essa abordagem requer a implementação e o gerenciamento de transformações mais avançadas de funções.

Data do Teste # 3: Combinando Funções em Dados de Treinamento

A formação de conjuntos de dados de treinamento ou teste requer a combinação dos dados das funções correspondentes. Nesse caso, é necessário rastrear muitos detalhes que podem ter efeitos críticos no modelo. Os dois mais insidiosos são:

Fuga de dados: Os especialistas em ciência de dados precisam garantir que seu modelo seja treinado nas informações corretas e não permitir o "vazamento" de informações indesejadas nos dados de treinamento. Esses dados podem ser: dados de uma suíte de testes, dados da verdade básica, dados do futuro ou informações que violam processos preparatórios importantes (por exemplo, anonimização).
: — . ( ). , data science , .

- #4:

Depois que o modelo é colocado em operação em tempo real, para criar previsões corretas e relevantes, ele precisa fornecer constantemente novos dados de função - geralmente em larga escala e com tempo de espera mínimo.

Como devemos passar esses dados para os modelos? Diretamente da fonte? Receber e transferir dados do armazenamento pode levar minutos, dias, horas ou até dias, o que é muito longo para a saída de dados em tempo real e, portanto, na maioria dos casos, é impossível.

Nesses casos, o cálculo de funções e o consumo de funções devem ser desativados. Para cálculo preliminar (pré-cálculo)funções e seu envio para o data warehouse de produção otimizado para entrega, é necessário usar processos ETL. Esses processos criam dificuldades adicionais e exigem novos custos de manutenção:

Procure o compromisso ideal entre relevância e rentabilidade: a desconexão do cálculo e consumo de funções confere prioridade à urgência. Freqüentemente, devido ao aumento no custo, os processos de funções podem ser executados com mais frequência e, como resultado, produzir dados mais relevantes. O compromisso correto varia de acordo com a função e o caso de uso. Por exemplo, a função de agregação de uma janela de fatura final de entrega de trinta minutos fará sentido se for atualizada com mais frequência do que uma função semelhante com uma janela de fatura final de duas semanas.

Integração de processos funcionais:Acelerar a produção de funções requer a obtenção de dados de várias fontes diferentes e, como resultado, resolver os problemas associados a isso é mais complicado do que quando se trabalha com apenas uma fonte de dados, que discutimos anteriormente. A coordenação de tais processos e a integração de seus resultados em um único vetor de funções requer uma abordagem séria da engenharia de dados.

Prevenção de distorção no treinamento ( training / serving-skew ):Discrepâncias entre os resultados dos processos de aprendizagem e de trabalho podem levar a distorções na aprendizagem. As distorções durante o treinamento são bastante difíceis de detectar, e sua presença pode tornar inutilizáveis as previsões do modelo. O modelo pode se comportar caoticamente ao tirar conclusões com base em dados gerados de maneira diferente daqueles em que foi treinado. Por si só, a questão da distorção e do trabalho com eles merece uma série separada de artigos. No entanto, vale destacar dois riscos típicos:

: ( ) , . Null? ? . .

. 7 ,

́ : - ( ). , , , . , , . — , , , .

FIG. 8: O gráfico mostra a conta final de pedidos: em (1) são mostrados os valores da função emitida para a previsão e atualizada a cada 10 minutos; em (2) são mostrados dados de treinamento que exibem incorretamente os valores reais muito mais claramente em comparação com as funções emitidas para produção

Data do teste # 5: Rastreando recursos na produção

Algo irá quebrar, apesar de todas as tentativas de contornar corretamente os problemas acima. Quando um sistema de ML falha, quase sempre acontece devido a uma "violação de integridade de dados". Esse termo pode indicar vários motivos diferentes, cada um dos quais requer rastreamento. Exemplos de violações da integridade dos dados:

: , , . , , . , .
: , . , , (, ), .
: . , (, , ) .
Responsabilidade pouco clara pela qualidade dos dados: No caso em que as funções podem receber dados de origem de várias fontes de distribuição diferentes, quem é o principal responsável pela qualidade da função? O especialista em ciência de dados que criou a função? Especialista em ciência de dados que treinou o modelo? Proprietário do canal de alimentação de dados? O programador que realizou a integração do modelo na produção? Nos casos em que as responsabilidades não são claras, os problemas permanecem sem solução por muito tempo.

Tais testes criam uma pista de obstáculos quase intransponível até para as equipes mais avançadas no campo da ciência de dados e engenharia de ML. Resolvê-los requer algo melhor do que o status imutável da maioria das empresas, quando soluções personalizadas individuais permanecem a única resposta para um subconjunto desses problemas.

Apresentando o Tecton: uma plataforma de aprendizado de máquina do Date

Na Tecron, estamos criando uma plataforma de aprendizado de máquina de data para fornecer assistência com os problemas mais comuns e mais difíceis no campo da ciência de dados.

Em um nível alto, a plataforma Tecron tem:

Processos de funções para transformar seus dados de origem em funções e rótulos
Repositório de funções para armazenar dados de tags e funções arquivadas
Servidor de funções para emitir os valores mais recentes de funções para produção
SDK para dados de treinamento e manipulação de processos funcionais
UI da Web para monitorar e rastrear recursos, rótulos e conjuntos de dados
Mecanismo de monitoramento para determinar a qualidade dos dados ou problemas de desvio e alertas

FIG. 9: Sendo a plataforma central de dados para ML, a Tecton fornece funções em ambientes de desenvolvimento e produção.A

plataforma permite que as equipes de ML tragam práticas de DevOps para dados de ML:

Planejamento: os recursos do Tecron são armazenados em um repositório central. Isso permite que os especialistas em ciência de dados compartilhem, localizem e usem os trabalhos uns dos outros.
Código: Tecton permite que os usuários configurem processos de transformação de funções simples e flexíveis.
Build: O Tecton compila funções em tarefas de processamento de dados de alto desempenho.
Teste: O Tecton suporta testes funcionais e de integração de funções.
Lançamento: Tecton integra-se firmemente ao git. Todas as descrições de funções têm controle de versão e são fáceis de reproduzir.
: Tecton ( Spark). Tecron.
: Tecton data science , .
: Tecton .

Obviamente, os dados de ML sem um modelo de ML não fornecerão uma implementação prática do ML. Portanto, a Tecton fornece APIs flexíveis e integra-se às plataformas de ML existentes. Começamos com Databricks, SageMaker e Kuberflow e continuamos a integrar com componentes complementares do ecossistema.

Por que precisamos do DevOps no campo de dados ML