Muitos de nós, desenvolvedores, conhecemos a sensação de lutar para equilibrar o tempo gasto com os usuários tentando entender suas necessidades e o tempo gasto com o desenvolvimento de software. Isso é ainda mais evidente na ciência data, pois, para criar um sistema eficaz, é necessário muito conhecimento do domínio desse sistema. Nos últimos dois anos, trabalhando como engenheiro de ML com diferentes Ciência data equipes, muitas vezes me pergunto como posso separar as responsabilidades de otimizar a precisão do modelo e criar todo o software necessário para tornar esse modelo funcional. Minha humilde opinião é que os cientistas de data devem priorizar a precisão de seus modelos, enquanto os engenheiros de ML devem priorizar a garantia de que esses modelos possam ser usados pela empresa como um todo.

Como regra geral em projetos científicos data, quanto mais iterações o senhor concluir, melhor. Então, vamos ver por que incluir um engenheiro de ML desde o primeiro dia ajudará o senhor a iterar e, portanto, aumentará suas chances de criar um sistema bem-sucedido. Para abranger todos os aspectos, dividiremos cada motivo em três tópicos principais dos projetos científicos do data: data, modelos e infraestrutura.

Antes de entrar no assunto, deixe-me definir o que quero dizer com iteração. Neste artigo, estou me referindo a iterações de ponta a ponta do produto completo, muitas vezes incluindo etapas de: Ingestão de data, pré-processamento, treinamento e avaliação de modelos, infraestrutura de provisionamento, etc. O que eu não significa é uma iteração rápida do modelo em um notebook com o ajuste de um hiperparâmetro. Se estiver acostumado a trabalhar em uma estrutura ágil, o senhor também pode pensar nessas iterações como sprints de projeto.

Construir um esqueleto sobre o qual o senhor possa iterar é a primeira prioridade e pode ser um processo demorado. Esse esqueleto geralmente é um POC que contém seu modelo de linha de base inicial e uma demonstração de um aplicativo ou forma de explorar o resultado do modelo.

Infraestrutura: A seleção de recursos compatíveis do cloud (VMs, conexões com várias fontes do data) e o projeto da arquitetura do cloud são algumas das considerações iniciais do engenheiro de ML.

Data: obter o data necessário para iniciar a construção de um modelo e garantir a disponibilidade de data de várias fontes com a opção de desenvolver novos fluxos, se necessário.

Modelos: garantir que os modelos que estão sendo testados sejam de fato compatíveis com a arquitetura cloud proposta para a implantação de modelos e requisitos técnicos (por exemplo, latência, computação necessária, requisitos do ambiente de produção).

O engenheiro de ML também pode ajudar nessa fase, definindo as práticas recomendadas de engenharia de software com controle de versão, linting, arquitetura de código, testes etc.

Depois que o senhor consegue essa construção inicial, as primeiras iterações costumam ser difíceis e lentas. Acelerar as iterações permitirá iterações menores com uma única alteração de recurso - uma maneira muito mais eficaz de desenvolver do que alterar muitas coisas em um modelo antes de obter feedback.

Infraestrutura: O tempo pode ser economizado otimizando a infraestrutura de armazenamento e computação. Durante essas iterações, um engenheiro de ML pode procurar versionar a própria infraestrutura, com ferramentas de Infraestrutura como Código (IaC), como Terraform. O uso do IaC permite a automação da implementação da infraestrutura diretamente com pipelines de CI/CD, acelerando a integração de quaisquer alterações que precisem ser feitas na infraestrutura existente e a criação de diferentes ambientes cloud (desenvolvimento, preparação, produção). Além disso, o uso de componentes específicos do cloud pode acelerar seu fluxo de trabalho, por exemplo, a criação de imagens remotamente usando o GCP's Construção na nuvem.

Data: Os pipelines de pré-processamento podem ser criados rapidamente pelas equipes científicas do data para que a modelagem seja feita rapidamente. Um engenheiro de ML pode ajudar nessa fase a simplificar suas consultas de processamento, sejam elas em sql, pandas, pyspark etc. Fazer isso logo no início pode economizar muito tempo em iterações a longo prazo, pois esse código é executado muito.

Modelos: arquiteturas complexas de modelos podem tornar o processo de treinamento demorado. Além disso, quando um cientista do data se refere a um “modelo”, ele pode, na verdade, estar se referindo a um grupo de 100 modelos treinados em diferentes fatias do data, cada um com um explicador SHAP para derivar a importância do recurso. Um engenheiro de ML pode se concentrar em como paralelizar o pipeline de treinamento, seja em uma VM com multiprocessamento em python ou distribuindo sua carga de trabalho em vários nós no cloud. Isso pode ser repetido, mas é possível obter grandes ganhos aqui com um esforço surpreendentemente pequeno. Automatizar a implementação do seu modelo com um CI/CD/CT O pipeline também acelera muito as iterações e garante a repetibilidade.

Ter um engenheiro para monitorar o orçamento do seu projeto cloud é fundamental, especialmente para aplicativos data intensivos.

Infraestrutura: O custo é uma variável importante na equação de seleção da infraestrutura. Depois que a infraestrutura é escolhida, alertas orçamentários podem ser implementados para garantir que os componentes caros sejam monitorados de perto.

Data: As consultas inteligentes e o armazenamento do data também podem reduzir significativamente os custos de cada iteração. Por exemplo, a agregação do data deve ser feita com parcimônia durante as iterações do modelo.

Modelos: A paralelização do pipeline de treinamento também pode economizar o tempo de atividade de máquinas caras ou o tempo de execução de componentes sem servidor.

Conseguir iterações rápidas com um loop de feedback de qualidade em seu projeto é ótimo, mas se o senhor não puder replay cada um desses cenários, não terá muita utilidade. Ter um pipeline repetível significa implicitamente que o senhor deve ter alguma forma de monitorar as execuções do pipeline para identificar as execuções com base em parâmetros específicos ou métricas de desempenho para as quais reverter, se necessário. Configurar isso de forma robusta durante o desenvolvimento ajuda os cientistas data a fazer experimentos livremente (sem a necessidade do infame Untitled12.ipynb) e prepara o pipeline para o monitoramento da produção.

Infraestrutura: Vincular a versão do código de treinamento à versão do código de infraestrutura é a “milha extra” aqui, mas é necessário para fornecer recursos completos de reversão para uma execução anterior. Garantir a repetibilidade e o monitoramento com base em uma execução de pipeline é, para mim, o primeiro nível essencial de ML Ops que as equipes devem buscar. As plataformas de nuvem têm serviços (GCP's Vertex AI por exemplo), que pode ser rápido de configurar, mas o senhor também pode considerar adotar a abordagem “melhor da categoria” usando ferramentas de código aberto. A troca aqui é equilibrar a maior funcionalidade de ferramentas específicas de código aberto com o aumento da complexidade da infraestrutura geral do sistema.

Data: salvar todos os objetos data em cada estágio do pipeline. Dependendo dos volumes, a prioridade é salvar os conjuntos de treinamento/teste de cada execução.

Modelos: como acima, salvando todos os modelos para cada execução com todos os parâmetros e métricas necessários. Outra dica é registrar um comentário em cada execução com o que foi alterado para essa execução específica para registrar todos os experimentos durante o desenvolvimento, como faria com um git commit mensagem.

Quando a ciência do data surgiu, ela era muito exploratória e exigia um grande esforço de um grupo de engenheiros de software para implantar qualquer modelo, uma vez que ele tivesse demonstrado bom desempenho no data histórico. Essa fase de “industrialização” é uma experiência muito dolorosa, pois o ambiente de desenvolvimento (arquivos simples e notebook python) é muito diferente do ambiente de produção (fluxos automatizados de data com data de produção e ambiente de codificação de produção). Os projetos mais bem-sucedidos em que trabalhei foram aqueles em que conseguimos copiar o ambiente de produção o mais próximo possível no desenvolvimento desde o início. Isso reduzirá o tempo até a produção e permitirá que o senhor faça iterações com segurança no desenvolvimento, implementando na produção quando estiver satisfeito com uma iteração.

Infraestrutura: Emular a infraestrutura de produção necessária no desenvolvimento nem sempre é fácil e pode ser caro. É nesse ponto que a infraestrutura como código é útil e pode permitir que o senhor alterne facilmente entre ambientes.

Data: Algo que separa o desenvolvimento científico do data da engenharia de software tradicional ou mesmo da engenharia de data é que os cientistas do data exigem o data de produção no desenvolvimento. O data de sandbox (excluindo alguns data ou incluindo alguns data de teste sintético) para a engenharia regular do data é uma boa prática durante o desenvolvimento, mas pode ser uma grande perda de tempo para a ciência do data e pode ter grandes impactos em todo o pipeline científico do data. Portanto, ter acesso somente de leitura às tabelas de produção é algo que deve ser negociado com a sua equipe de data desde o primeiro dia.

Modelos: Desde o início do projeto, apenas um modelo (ou abordagem de modelagem) deve estar presente em seu código de produção. Todos os experimentos devem ficar em notebooks ou em scripts temporários separados em outra pasta. Isso evita que o senhor acumule código morto em sua base de código de produção e facilita a manutenção ou a integração de outros desenvolvedores.

Em resumo, a criação de modelos e a criação do software que envolve esses modelos devem ser duas prioridades desde o início de cada projeto. Portanto, ter fluxos separados com responsabilidades diferentes pode ajudar as equipes a se concentrarem em ambos em paralelo. A função do engenheiro de ML está evoluindo a cada dia, e eu gostaria de ouvir a opinião dos senhores sobre qualquer coisa que eu tenha deixado passar!