True ML Talks #2 - Fluxo de Trabalho de Machine Learning @ Stitch Fix

Recebemos uma resposta muito encorajadora ao nosso primeiro episódio do True ML Talks. Nesta série, aprofundamos no pipeline de ML de algumas das principais empresas de ML, e no episódio de hoje, conversaremos com Stefan Krawczyk.

Stefan está construindo a DAGWorks, uma plataforma colaborativa de código aberto para equipes de ciência de dados construírem e manterem pipelines de modelos, integrando-se à infraestrutura de MLOps e dados existente (leia o YC Launch). Ele tem mais de 15 anos de experiência em empresas como Nextdoor, LinkedIn e Stitch Fix na área de dados e machine learning. Ele liderou anteriormente a equipe de Ciclo de Vida de Modelos na Stitch Fix, onde adquiriu vasta experiência na construção de ferramentas de autoatendimento para uma plataforma interna de machine learning MLOps. Ele também é um palestrante frequente em conferências e autor do popular framework de código aberto, Hamilton.

📌

Nossas conversas com Stefan girarão em torno de quatro temas principais:
1. Casos de uso de Machine Learning para o negócio.
2. Como a equipe da Stitch Fix está estruturada para otimizar os resultados de negócio.
3. Desafios enfrentados na construção da pilha de ML, com desafios específicos relacionados à indústria.
4. Uma visão geral das inovações de ponta aplicadas durante o processo de construção e escalonamento da infraestrutura de ML.

Assista ao episódio completo abaixo:

Casos de Uso de ML na Stitch Fix: Um Serviço Online de Estilo Pessoal

1. Sistema de Recomendação → Modelos para previsão e simulação, fornecendo uma análise detalhada de tamanhos e faixas de alocação.
2. Previsão e simulação → Quando os compradores decidem quantas roupas comprar, eles devem determinar os tamanhos e a população a ser atendida. Isso envolve uma cascata de previsão de coisas que as pessoas usam internamente para ajudar a simular ou prever. A equipe de algoritmos da Stitch Fix constrói modelos para esse fim, fornecendo uma análise dos tamanhos e faixas de alocação. Leia mais sobre isso aqui
3. Sistema interno de planejamento de recursos empresariais → A Stitch Fix construiu essencialmente seu próprio sistema ERP interno usando algoritmos. Este sistema ajuda a planejar o inventário, o armazenamento e a otimização das taxas de envio. Leia mais sobre isso aqui.
4. Otimização de rotas no armazém → A Stitch Fix tem uma equipe que otimiza as rotas no armazém, garantindo que o caminho mais curto seja percorrido para coletar os pedidos. Essa otimização ajuda a minimizar o custo e o tempo de processamento dos pedidos.
5. Logística de armazém → A equipe de algoritmos da Stitch Fix também trabalha na otimização do processo de coleta de roupas dos compartimentos para atender aos pedidos. A Stitch Fix pode economizar custos e minimizar os tempos de processamento de pedidos ao acelerar este processo.

Fluxo de Trabalho do Sistema de ML na Stitch Fix

A Stitch Fix tem duas equipes trabalhando em seus sistemas de aprendizado de máquina (ML) - as equipes de ciência de dados e de plataforma.

• Equipe de Ciência de Dados: A equipe de ciência de dados, organizada em verticais que auxiliam diferentes partes do negócio, é encarregada de construir modelos para ajudar outras equipes do negócio a tomar decisões.
• Equipe de Plataforma: A Equipe de Plataforma constrói abstrações e ferramentas para que os cientistas de dados não precisem se dedicar tanto à engenharia para realizar seu trabalho. A equipe é dividida em vários componentes, como Spark, Hadoop, Kafka, infraestrutura, sistema de orquestração e ambientes. Há também uma equipe responsável pela pilha de recomendações e implantação de microsserviços, bem como testes A/B e experimentação. A equipe foca em elementos de operacionalização, como facilitar o treinamento, a implantação e a manutenção de modelos.

👉

A equipe de Ciência de Dados é responsável pelos modelos e pelos resultados. A equipe de Plataforma garante a disponibilidade da infraestrutura de implantação e seus componentes.

Não houve "transferência" do modelo entre a equipe de Ciência de Dados e a equipe de Plataforma. Isso ajuda a obter muito mais iterações com o modelo.

Gerenciamento da Alocação de Infraestrutura

A alocação de infraestrutura é gerenciada pela equipe de Plataforma, que geralmente era responsável pelas cotas do que estava disponível. Cientistas de dados podiam solicitar nós ou outros clusters Spark em uma interface de usuário. É feita alguma contabilidade para garantir que os custos não aumentem descontroladamente sem justificativa. A equipe de plataforma tentou permitir que as pessoas obtivessem o que queriam facilmente, sem muito esforço, e havia equipes que gerenciavam as cotas e garantiam que os custos fossem mantidos sob controle.

Desafios Únicos em Aprendizado de Máquina e MLOps na Stitch Fix

1. Na Stitch Fix, há mais de 100 cientistas de dados trabalhando no desenvolvimento de modelos. Com cada cientista de dados sendo responsável por um modelo que tem uma vida útil média de pelo menos dois anos, havia muitas equipes construindo muitos modelos, e permitir a propriedade para uma equipe era um desafio significativo. A equipe de plataforma da StitchFix desenvolveu muitas soluções internamente e comprou apenas algumas coisas devido à heterogeneidade nas bibliotecas e frameworks utilizados. A padronização teria tornado algumas plataformas mais fáceis, mas equipes diferentes tinham problemas e bibliotecas diferentes que eram mais adequadas para esses problemas. A equipe de plataforma da StitchFix teve que construir suas próprias soluções, como Model Envelope e Hamilton, porque não havia soluções de código aberto que se encaixassem bem em suas necessidades.
2. Embora seja fácil criar modelos, alguém precisa manter todos os ETLs, e se alguém sair da empresa, isso pode causar problemas. Descartar código é um desperdício, e novos membros da equipe são atrasados até que consigam descobrir e entender o que existia antes deles. Além disso, como as pessoas frequentemente constroem sobre os modelos de outras equipes para usar como recursos, existem interdependências entre os ETLs que precisam ser levadas em consideração.

"Uma das razões pelas quais fiquei tanto tempo na Stitch Fix foi precisamente por causa desses desafios e por descobrir como resolvê-los." - Stefan

Inovações na Plataforma de ML da Stitch Fix

1. Model Envelopes: A equipe de Plataforma da Stitch Fix construiu um sistema que permitiu aos cientistas de dados empacotar seus modelos com outros componentes necessários e implantá-los facilmente. É um sistema baseado em API que captura muitas coisas, e com um botão e configuração extra, os cientistas de dados podem implantar seus modelos em produção em menos de uma hora. O sistema também possibilitou trabalhos em lote e facilitou a execução de modelos de forma distribuída no Spark.
2. ETLs Orientados por Configuração: A equipe de Plataforma da Stitch Fix usou YAML e Jinja para permitir que os cientistas de dados descrevessem o processo de ETL, que incluía código SQL e Python para ajuste de modelo. A ideia era abstrair o sistema de orquestração e permitir que a equipe de plataforma trocasse diferentes componentes do contêiner Docker, o que facilitou o gerenciamento e a manutenção da base de código.
3. Hamilton: Hamilton é um micro-framework declarativo para descrever fluxos de dados. A equipe de Plataforma da Stitch Fix o desenvolveu para auxiliar na engenharia de recursos (feature engineering), especialmente para previsão de séries temporais, onde é fácil usar milhares de recursos. Hamilton ajuda a estruturar o problema, semelhante ao DBT para SQL, mas para transformações Python. Ele permite que o fluxo de dados seja descrito sem gerenciar scripts Python. As funções declaram um fluxo de dados, e as definições podem ser facilmente compartilhadas e executadas em contextos offline e online.

👉

Para a troca de componentes Docker, a equipe de plataforma tentou criar uma API "padrão ouro" onde os cientistas de dados podiam descrever o que queriam que acontecesse sem se preocupar com as dependências da plataforma. Isso foi feito através de pipelines de modelo orientados por configuração, onde os cientistas de dados podiam fornecer texto contendo subconjuntos de alterações. A equipe de plataforma podia então alterar as coisas sem exigir que a equipe de cientistas de dados atualizasse ou fizesse upgrade de seus contêineres Docker. A equipe de plataforma também podia atualizar logs ou meta informações sem que os usuários tivessem que reimplantar ou reescrever seus pipelines. Isso eliminou a necessidade de as equipes gerenciarem e atualizarem as coisas e permitiu que a equipe de plataforma gerenciasse e atualizasse as coisas de forma mais eficiente, sem exigir migração da equipe de cientistas de dados.

Melhorando o tempo de construção e depuração de contêineres Docker no desenvolvimento remoto: estratégias empregadas na Stitch Fix

1. Cache para acelerar a criação de contêineres - A equipe de Plataforma da Stitch Fix tentou acelerar a criação de contêineres Docker armazenando em cache bibliotecas e ambientes frequentemente usados. Por exemplo, eles adicionaram cache para garantir que, se os mesmos requisitos fossem necessários novamente, não precisariam ser reinstalados. Eles também salvaram arquivos de ambiente, os compactaram e depois os recuperaram para acelerar o processo.
2. Desenvolvimento local para minimizar o tempo de construção e depuração de contêineres - A equipe de Plataforma da Stitch Fix incentivou os desenvolvedores a desenvolver localmente ou a encontrar maneiras de evitar a espera por um ciclo completo de construção, execução e depuração de contêineres Docker. Eles habilitaram loops locais para executar etapas individuais do ETL, baixando alguns dados para armazená-los em cache para os desenvolvedores, entre outros recursos de usabilidade. Essa abordagem ajudou a acelerar o processo de desenvolvimento e depuração.
3. Explorando novas abordagens para melhorar o tempo de construção e depuração de contêineres - Embora a equipe de Plataforma da Stitch Fix tenha tentado fazer melhorias no tempo de construção e depuração com cache e desenvolvimento local, eles reconheceram que o processo poderia ser mais rápido. Alguns desenvolvedores estão trabalhando em mudanças no Docker para melhorar esse processo, especialmente para modelos. Essa abordagem envolve alterar o Docker e reiniciá-lo para torná-lo melhor e mais eficiente.

Recomendações de Ferramentas MLOps de Stefan Krawczyk

É importante escolher ferramentas com base no impacto nos negócios e nos SLAs. Coisas que podem ser feitas com um único nó devem ser otimizadas com um sistema de orquestração. Para versionamento de dados e registros de modelos, salvar itens no S3 em uma estrutura de caminho organizada e armazenar metadados com eles pode funcionar. Quando se trata de registro de modelos, ferramentas de código aberto como o MLflow devem ajudar, mas também existem soluções de gerenciamento hospedadas como o TrueFoundry.

É importante ter um sistema de teste A/B na pilha para entender o valor que o modelo traz para o negócio. Isso ajudará na tomada de decisões sobre onde investir em práticas de MLOps com base no impacto que o modelo tem.

Recomendação de ferramentas MLOps  

1. Considere a heterogeneidade em bibliotecas e frameworks: Se houver uma heterogeneidade significativa nas bibliotecas e frameworks utilizados, a construção de soluções internas pode ser necessária, pois pode não haver soluções prontas que atendam às suas necessidades.
2. A padronização pode facilitar algumas plataformas: Embora equipes diferentes possam ter problemas diferentes, padronizar certas ferramentas e processos pode tornar plataformas MLOps mais fáceis de construir e manter.
3. Nenhuma solução de código aberto que atenda às suas necessidades? Crie a sua própria: Se não houver soluções de código aberto que se encaixem bem nas suas necessidades, a construção de suas próprias soluções, como Model Envelope e Hamilton, pode ser necessária para atingir seus objetivos de MLOps.

Desafios em torno do ETL em Machine Learning

Em machine learning, o processo de Extração, Transformação e Carregamento (ETL) é fundamental para transformar dados brutos em insights valiosos. No entanto, o ETL em sistemas de machine learning apresenta vários desafios que precisam ser abordados.

Os ETLs em sistemas de machine learning podem ficar inativos devido a mudanças a montante, dificultando para os profissionais de dados rastrear as entradas para o modelo, o que leva a dificuldades na manutenção dos ETLs. A complexidade dos ETLs também aumenta com o tempo, tornando difícil para as equipes acompanharem.

DAGWorks: Uma Plataforma ETL de Código Aberto para Equipes de Ciência de Dados

Para resolver os desafios mencionados na seção anterior, a DAGWorks está construindo uma plataforma ETL de código aberto para equipes de ciência de dados que reduz sua dependência de engenharia; o código aberto é baseado no Hamilton mencionado acima. O Hamilton permite que profissionais de dados sem experiência em engenharia de software escrevam código que vai para produção e gerenciem artefatos ETL de machine learning em sua infraestrutura existente. O Hamilton também fornece um repositório central de definição de recursos e linhagem, o que ajuda a facilitar a depuração e pode ser usado para casos de conformidade.

O Hamilton foi projetado para ser uma camada de abstração que pode ser usada com várias ferramentas de orquestração, como Airflow ou Argo. Stefan acredita que os cientistas de dados não deveriam se preocupar com a topologia de onde as coisas são executadas e, em vez disso, focar na construção de modelos e iterações. A DAGWorks está tentando encontrar maneiras e abstrações para facilitar a mudança de provedores de qualidade de dados sem ter que reescrever as coisas.

Embora o Hamilton complemente ferramentas como o Metaflow, ele não está tentando substituí-las. Em vez disso, ele permite que as pessoas sejam mais produtivas sobre esses sistemas, permitindo-lhes modelar o micro dentro de uma tarefa. No geral, a DAGWorks está tentando facilitar para as equipes de ciência de dados gerenciar e manter artefatos ETL de machine learning.

Abaixo estão algumas leituras interessantes de Stefan e sua equipe:  

O que aprendi construindo plataformas na Stitch Fix

Implantação Gratuita - Uma Plataforma de Machine Learning para Cientistas de Dados da Stitch Fix

A Função, o Contexto e os Dados — Habilitando ML Ops na Stitch Fix

Leia nossa postagem anterior da série

‍

True ML Talks #1 - Machine Learning Workflow @ Gong

Learn how Gong, a revenue intelligence platform, uses machine learning to analyze customer interactions and provide insights to revenue teams. Discover the challenges of managing ML workflows, data privacy, and data security.

TrueFoundry Blog TrueFoundry

‍

Continue assistindo à TrueML série do YouTube e lendo toda a TrueML série do blog.

TrueFoundry é uma PaaS de Implantação de ML sobre Kubernetes para acelerar os fluxos de trabalho dos desenvolvedores, permitindo-lhes total flexibilidade no teste e implantação de modelos, ao mesmo tempo em que garante total segurança e controle para a equipe de Infraestrutura. Através da nossa plataforma, capacitamos as equipes de Machine Learning a implantar e monitorar modelos em 15 minutos com 100% de confiabilidade, escalabilidade e a capacidade de reverter em segundos - permitindo-lhes economizar custos e lançar Modelos para produção mais rapidamente, possibilitando a realização de valor de negócio real.