Mesmo com uma pilha perfeita de ferramentas MLOps, as equipes ainda lutam para entregar produtos de ML. Então, se as ferramentas não são a única peça do quebra-cabeça, o que resta? Em meu último post , defendo que as peças restantes são Cultura e Processo.

Vamos nos aprofundar no processo de MLOps — em particular, algumas das peças fundamentais que a maioria das equipes erra . Como é um processo de MLOps bem-sucedido e como os profissionais de ML podem ajudar a criar esse processo?

TL;DR

• Comece com um produto, não um modelo
• Pesquise os dados na produção , não no seu warehouse
• Comece simples — com dados e modelos
• Parceria com engenheiros

Comece com um produto de ML

Talvez a prática mais importante que permite projetos de ML bem-sucedidos seja projetar um produto , não um modelo . Uma das maiores armadilhas que vi em dezenas de empresas é entregar “projetos” para equipes de dados, em vez de envolvê-los na fase de design do produto.

Para criar um produto de ML bem-sucedido, três partes interessadas precisam estar envolvidas no design do produto:

• PM / Stakeholder do negócio : Como é o sucesso?
• Pessoa de ML : O que é (provavelmente) possível com ML?
• Engenheiro de Produto : O que é viável e quais são as restrições?

Alguns exemplos de times mal alinhados:

• A pessoa de ML otimiza a precisão do modelo (em vez dos resultados de negócios!)
• Projetos iniciados que podem não ser viáveis ​​para resolver com ML
• O modelo não atende às restrições de desempenho na produção
• Os recursos são desafiadores ou impossíveis de computar na produção

• A pessoa de ML entende as compensações de precisão versus tempo de lançamento no mercado
• Monitoramento construído no dia zero para garantir que os resultados de negócios sejam medidos de forma consistente
• O engenheiro ajuda a pessoa de ML a entender o cenário de dados de produção
• Os SLAs do modelo são claramente definidos e medidos

Este é um exemplo de “bom alinhamento” na última seção, mas merece sua própria seção. Quase todos os construtores de ML que vi iniciam seus projetos de ML com uma pesquisa dos dados disponíveis. O problema? Eles normalmente pesquisam os dados que estão disponíveis para treinamento , não os dados que estarão disponíveis na produção.

Alguns podem perguntar — todos os dados disponíveis para treinamento não deveriam estar disponíveis em um sistema de produção?

Na maioria das vezes, a resposta é sim , mas com um monte de asteriscos. Com que rapidez esses dados estão disponíveis? Quão recentes são esses dados? Quanto pré-processamento precisa ser feito nos dados de produção para torná-los consumíveis? Quem é o dono desses dados?

Muitos projetos de ML param devido a problemas com dados de produção. Tenho visto repetidas vezes que há uma grande desconexão entre a pessoa de ML e o engenheiro de produto. Um exemplo de dois recursos inócuos com requisitos drasticamente diferentes:

• CEP residencial de um usuário : provavelmente muito simples de usar na produção. Consultar um banco de dados.
• A localização média de um usuário nos últimos cinco minutos : provavelmente um PITA! Os dados de localização do usuário estão em um Kafka Stream? Quão fresco precisa ser? Agregações de streaming são difíceis! Provavelmente problemas de distorção de treinamento/atendimento!

Comece simples

Provavelmente o conselho de ML mais comum, mas é um bom conselho. Comece com uma solução simples.

Minha adição — a maioria das pessoas dirá para você começar com um modelo simples , mas é igualmente importante começar com dados simples! Para reproduzir o exemplo acima:

• A localização média de um usuário nos últimos cinco minutos: difícil
• A localização mais recente de um usuário: provavelmente muito mais fácil!

Você provavelmente aceita esse comércio todas as vezes. Você sempre pode criar um V2 com o recurso mais sofisticado e será muito mais fácil criar melhorias incrementais do que enviar algo complicado na primeira vez.

Parceria com engenheiros

É provável que, se você for um cientista de dados, nem todas as perguntas feitas acima sejam óbvias de responder. Quando eu estava construindo modelos de ML pela última vez, não tinha ideia do que eram dados de streaming (muito menos como pensar sobre isso).

A solução é fazer amizade com engenheiros e trabalhar com eles durante o desenvolvimento de um modelo de ML. Construir qualquer projeto de software não pode ser feito em um silo, e ML em um silo é ainda pior. Os engenheiros podem ajudar com “quais dados estão disponíveis”, “quais restrições devo saber”, “quais SLAs são viáveis” e muito mais.

Trabalhe com um engenheiro cedo e frequentemente. Você construirá projetos muito mais rápido.

Conclusão

Essas etapas não são uma visão abrangente de um processo de MLOps — há muitas peças em movimento que levam ao sucesso (revisões de código, CI/CD, monitoramento, …). Este é um ponto de partida. Conforme mencionado acima, a maioria das falhas de ML que vi são problemas de alinhamento. Essas diretrizes de processo destinam-se principalmente a ajudá-lo a alinhar sua equipe para o sucesso.

Você precisa de uma base sólida para construir uma prática excepcional de MLOps.

David Hershey é um investidor da Unusual Ventures , onde investe em aprendizado de máquina e infraestrutura de dados. David iniciou sua carreira na Ford Motor Company, onde iniciou sua equipe de infraestrutura de ML. Recentemente, ele trabalhou na Tecton e na Determined AI , ajudando as equipes de MLOps a adotar essas tecnologias. Se você estiver construindo uma empresa de infraestrutura de dados ou ML, entre em contato com David no LinkedIn .