ML Ops: Machine Learning como Disciplina de Engenharia

À medida que o ML evolui da pesquisa para soluções de negócios aplicadas, precisamos melhorar a maturidade de seus processos operacionais.

10 min readJan 8, 2020

(Este artigo foi originalmente publicado em inglês)

Sua empresa decidiu investir em Machine Learning. Você tem uma talentosa equipe de cientistas de dados produzindo modelos para resolver problemas importantes, que estavam fora de alcance apenas alguns anos atrás. Todas as métricas de desempenho estão ótimas, as demos deixam todos de queixo caído e os executivos perguntam em quanto tempo você pode ter um modelo em produção.

Deve ser bem rápido, você pensa. Afinal, você já resolveu todos os problemas avançados de ciência e matemática, então tudo o que resta é um trabalho rotineiro de TI. Quão difícil isso pode ser?

Aparentemente, é bem difícil. O site Deeplearning.ai relata que “apenas 22% das empresas que usam machine learning implantaram com sucesso um modelo”. O que torna torna isso tão difícil? E o que precisamos fazer para melhorar a situação?

Vamos começar examinando as raízes do problema.

Desafios

No mundo do desenvolvimento tradicional de software, um conjunto de práticas conhecidas como DevOps tornou possível colocar software em produção em minutos, e mantê-lo funcionando de maneira confiável. O DevOps inclui ferramentas, automação e fluxos de trabalho para abstrair a complexidade acidental e permitir que os desenvolvedores se concentrem nos problemas reais que precisam ser resolvidos. Essa abordagem tem sido tão bem-sucedida que muitas empresas já são adeptas dela; então, por que não podemos simplesmente continuar fazendo a mesma coisa em ML?

A causa principal é que há uma diferença fundamental entre o ML e o software tradicional: o ML não é apenas código, é código mais dados . Um modelo de ML, o artefato que você efetivamente coloca em produção, é criado aplicando um algoritmo a uma massa de dados de treinamento, o que afetará o comportamento do modelo em produção. Além disso, o comportamento do modelo também depende dos dados de entrada que ele receberá no momento da previsão, que você não pode conhecer antecipadamente.

Enquanto o código é criado em um ambiente de desenvolvimento controlado, os dados vêm dessa fonte interminável de entropia conhecida como “o mundo real”. Ele nunca para de mudar, e você não tem como controlar como ele muda. Uma maneira de pensar nesse relacionamento é como se o código e os dados vivessem em planos separados, que compartilham a dimensão do tempo, mas são independentes em todas as outras. O desafio de um processo de ML é criar uma ponte entre esses dois planos de maneira controlada.

Código e dados evoluem de forma independente. Podemos pensar neles como planos separados, com uma dimensão de tempo em comum.

Essa desconexão causa vários desafios importantes que precisam ser resolvidos por quem quer colocar um modelo de ML em produção, por exemplo:

● Implantação lenta, frágil e inconsistente

● Falta de reproducibilidade

● Redução de desempenho (training-serving skew)

Como a palavra “dados” já foi usada várias vezes neste artigo, você pode estar pensando em outra disciplina que poderia ajudar a resolver esses desafios: a Engenharia de Dados . E você estaria certo: a Engenharia de Dados fornece ferramentas e conceitos importantes que são indispensáveis para resolver o quebra-cabeça da ML na produção. Para decifrá-lo, precisamos combinar práticas do DevOps e Data Engineering, adicionando algumas que são exclusivas do ML.

Assim, ML Ops pode ser definido por esta interseção:

ML Ops é a interseção de Machine Learning, DevOps e Engenharia de Dados

Portanto, poderíamos definir ML Ops da seguinte maneira:

O ML Ops é um conjunto de práticas que combina Machine Learning, DevOps e Engenharia de Dados, que visa implantar e manter sistemas de ML em produção de maneira confiável e eficiente.

Vamos agora ver o que isso realmente significa com mais detalhes, examinando as práticas individuais que podem ser usadas para atingir os objetivos das operações de ML.

Práticas

Equipes Híbridas

Já vimos que a produção de um modelo de ML requer um conjunto de habilidades que até agora eram consideradas separadas. Para sermos bem-sucedidos, precisamos de uma equipe híbrida que, em conjunto, cubra essa gama de habilidades. Sempre é possível que uma única pessoa seja boa o suficiente em todas elas e, nesse caso, poderíamos chamá-la de uma engenheira de ML Ops completa. Mas o cenário mais provável, por enquanto, é que uma equipe de sucesso inclua uma cientista de dados ou engenheira de ML, uma engenheira de DevOps e uma engenheira de dados.

A composição, organização e títulos exatos da equipe podem variar, mas a parte essencial é perceber que uma cientista de dados sozinha não pode alcançar os objetivos de ML Ops. Mesmo que uma organização inclua todas as habilidades necessárias, não será bem-sucedida se elas não trabalharem juntas.

Outra mudança importante é que os cientistas de dados devem ter proficiência em habilidades básicas de engenharia de software, como modularização de código, reutilização, testes e versionamento; conseguir um modelo que funciona bem em um notebook desorganizado não é suficiente. É por isso que muitas empresas estão adotando o título de engenheiro/a de ML, que enfatiza essas habilidades. Em muitos casos, os engenheiros de ML estão, na prática, realizando muitas das atividades necessárias para as operações de ML.

Pipelines de ML

Um dos conceitos principais da engenharia de dados é o pipeline de dados. Um pipeline de dados é uma série de transformações aplicadas aos dados entre sua origem e um destino. Eles geralmente são definidos como um grafo, no qual cada nó é uma transformação e as arestas representam dependências ou ordem de execução. Existem muitas ferramentas especializadas que ajudam a criar, gerenciar e executar esses pipelines. Os pipelines de dados também podem ser chamados de pipelines ETL (extração, transformação e carregamento, em inglês).

Os modelos de ML sempre exigem algum tipo de transformação de dados, que geralmente é feita através de scripts ou mesmo células em um notebook, dificultando o gerenciamento e a confiabilidade de execução. Passa a usar pipelines de dados adequados oferece muitas vantagens na reutilização de código, visibilidade em tempo de execução, gerenciamento e escalabilidade.

Como o treinamento em ML também pode ser considerado uma transformação de dados, é natural incluir as etapas específicas de ML no próprio pipeline de dados, transformando-o em um pipeline de ML. A maioria dos modelos precisará de duas versões do pipeline: uma para treinamento e outra para predição. Isso ocorre porque, geralmente, os formatos de dados e a maneira de acessá-los são muito diferentes entre esses dois momentos, especialmente para modelos que servem requisições em tempo real (em contraste com as execuções de previsão em lote).

Representação visual de um pipeline de ML em Kubeflow Pipelines

O pipeline de ML é um artefato de código puro, independente de instâncias de dados específicas. Isso significa que é possível gereciar suas versões em um sistema de versionamento de código e automatizar sua implantação com um pipeline de CI/CD, uma prática essencial do DevOps. Isso nos permite conectar os planos de código e de dados de maneira estruturada e automatizada:

Os pipelines de ML conectam dados e código para produzir modelos e previsões

Observe que existem dois pipelines ML distintos: o pipeline de treinamento e o pipeline de predição. O que eles têm em comum é que as transformações de dados que eles executam precisam produzir dados no mesmo formato, mas suas implementações podem ser muito diferentes. Por exemplo, o pipeline de treinamento geralmente é executado em arquivos em lote que contêm todas as features, enquanto o pipeline de predição geralmente é executado on-line e recebe apenas parte das features nas solicitações, buscando o restante de um banco de dados.

Entretanto, é importante garantir que esses dois pipelines sejam consistentes; portanto, tente reutilizar código e dados sempre que possível. Algumas ferramentas podem ajudar nesse objetivo, por exemplo:

● Frameworks de transformação como o TensorFlow Transform podem garantir que os cálculos baseados nas estatísticas do conjunto de treinamento, como médias e desvios padrão para normalização, sejam consistentes.

● Feature Stores são bancos de dados que armazenam valores que não fazem parte de uma requisição de predição, por exemplo, features calculadas sobre o histórico de um usuário.

Versionamento de Modelos e Dados

Para se ter reproducibilidade, é essencial o rastreamento consistente de versões. No mundo de software tradicional, versionar o código é suficiente, porque todo o comportamento do sistema é definido por ele. Em ML, também precisamos rastrear as versões do modelo, juntamente com os dados usados para treiná-lo e algumas metainformações, como hiperparâmetros de treinamento.

Modelos e metadados podem ser rastreados em um sistema de controle de versão padrão, como o Git, mas os dados geralmente são muito grandes e mutáveis para que isso seja eficiente e prático. Também é importante evitar vincular o ciclo de vida do modelo ao ciclo de vida do código, pois o treinamento do modelo geralmente ocorre em um ritmo diferente. Também é necessário versionar os dados e vincular cada modelo treinado às versões exatas de código, dados e hiperparâmetros usados. A solução ideal seria uma ferramenta criada especificamente para esse fim, mas até o momento não existe um consenso claro no mercado e muitos esquemas são usados, a maioria baseada em convenções de storage de arquivo/objeto e bancos de dados de metadados.

Validação de modelos

Outra prática padrão do DevOps é a automação de testes, geralmente na forma de testes de unidade e testes de integração. A aprovação nesses testes é um pré-requisito para a implantação de uma nova versão. Ter testes automatizados abrangentes pode dar bastante confiança a um time de desenvolvimento, acelerando drasticamente o ritmo das implantações em produção.

Os modelos de ML são mais difíceis de testar, porque nenhum modelo fornece resultados 100% corretos. Isso significa que os testes de validação de modelo precisam ser necessariamente de natureza estatística, em vez de ter um status binário de aprovação/reprovação. Para decidir se um modelo é bom o suficiente para implantação, é preciso decidir sobre as métricas corretas a se utilizar e seus limites aceitáveis, geralmente empiricamente, e geralmente em comparação com modelos ou benchmarks anteriores.

Também não é suficiente rastrear uma única métrica para a totalidade do conjunto de validação. Assim como bons testes de unidade devem testar vários casos, a validação do modelo precisa ser feita individualmente para segmentos relevantes dos dados, conhecidos como fatias. Por exemplo, se o gênero puder ser uma característica relevante de um modelo, direta ou indiretamente, rastrear métricas separadas para homens, mulheres e outros gêneros. Caso contrário, o modelo pode ter problemas de justiça ou ter um desempenho inferior em segmentos importantes.

Se você conseguir validar os modelos de maneira automatizada e confiável, juntamente com o restante do pipeline de ML, poderá fechar o loop e implementar o treinamento on-line de modelos, se isso fizer sentido para o caso de uso.

Validação de dados

Um bom pipeline de dados geralmente começa validando os dados de entrada. As validações comuns incluem formato e tamanho do arquivo, tipos de dados das colunas, valores nulos ou vazios e valores inválidos. Tudo isso é necessário para o treinamento e a previsão de ML; caso contrário, você pode acabar com um modelo que se comporta mal e se perder procurando o motivo. A validação de dados é análoga ao teste de unidade no domínio do código .

Além das validações básicas que qualquer pipeline de dados executa, os pipelines ML também devem validar propriedades estatísticas da entrada. Por exemplo, se a média ou desvio padrão de uma feature mudar consideravelmente entre um conjunto de dados de treinamento e outro, provavelmente afetará o modelo treinado e suas previsões. Isso pode refletir uma mudança real nos dados, ou pode ser uma anomalia causada pela maneira como os dados são processados. Por isso, é importante verificar e descartar erros sistêmicos como causas que podem contaminar o modelo, e corrigi-los se necessário.

Um exemplo de perfil de dados estatísticos no TensorFlow Data Validation

Monitoramento

O monitoramento de sistemas de produção é essencial para mantê-los funcionando bem. Para sistemas de ML, o monitoramento se torna ainda mais importante, porque seu desempenho depende não apenas de fatores sobre os quais temos algum controle, como infraestrutura e nosso próprio software, mas também dos dados, sobre os quais temos muito menos controle. Portanto, além de monitorar métricas padrão como latência, tráfego, erros e saturação , também precisamos monitorar o desempenho das previsões do modelo.

Um desafio óbvio ao monitorar o desempenho de modelos é que geralmente não temos um rótulo verificado para comparar com as previsões do nosso modelo, já que o modelo funciona com dados novos. Em alguns casos, podemos ter alguma maneira indireta de avaliar a eficácia do modelo, por exemplo, medindo a taxa de cliques para um modelo de recomendação. Em outros casos, podemos ter que confiar em comparações entre períodos de tempo, por exemplo, calculando uma porcentagem de classificações positivas por hora e alertando se ela se desvia em mais de alguns por cento da média desse período.

Assim como na validação do modelo, também é importante monitorar métricas entre fatias, e não apenas globalmente, para detectar problemas que afetam segmentos específicos.

Conclusão

À medida que o ML amadurece da pesquisa às soluções de negócios aplicadas, precisamos melhorar a maturidade de seus processos operacionais. Felizmente, podemos estender muitas práticas de disciplinas anteriores à ML.

A tabela a seguir resume as principais práticas do ML Ops e como elas se relacionam com as práticas de DevOps e Engenharia de Dados:

Essa é uma disciplina nova e empolgante, com ferramentas e práticas que provavelmente continuarão evoluindo muito rapidamente. Certamente há muitas oportunidades no desenvolvimento e aplicação de técnicas de produção para ML.