Back-End

3 dez, 2018

Aprendizado de Máquina de Escala na Uber com Michelangelo – Parte 02

Publicidade

Hoje, daremos continuidade à primeira parte do artigo do Jeremy, que mostra todo o processo de aprendizado da máquina de escalar com o Michelangelo.

Processo

À medida que as operações de ML da Uber amadurecem, vários processos se mostraram úteis para a produtividade e a eficácia de nossas equipes. Compartilhar as práticas recomendadas de ML (por exemplo, métodos de organização de dados, experimentação e gerenciamento de implantação) e instituir processos mais estruturados (por exemplo, análises de lançamento) são maneiras valiosas de orientar equipes e evitar repetir erros de outras.

Os esforços de construção de comunidades focados internamente e os processos de planejamento transparentes envolvem e alinham as equipes de ML sob objetivos comuns.

Lançando modelos

Projetar processos confiáveis ​​para evitar armadilhas comuns de desenvolvimento e verificar o comportamento pretendido do modelo são fundamentais para dimensionar com segurança o ML em uma organização.

Os sistemas de ML são particularmente vulneráveis ​​a comportamentos não intencionais, casos extremos delicados e problemas legais/éticos/de privacidade complicados.

Na prática, no entanto, os perfis de risco diferem significativamente entre os casos de uso e exigem processos de aprovação e lançamento sob medida.

Por exemplo, o lançamento de uma atualização automatizada para um modelo de previsão de ETA que usa dados anônimos requer menos controle da privacidade do que o lançamento de um novo modelo de determinação de preço.

Por esses motivos, as organizações de produtos (por exemplo, as equipes da Uber Eats ou do Marketplace) possuem os processos de lançamento em torno de seus modelos de ML.

Essas equipes adaptam os processos à sua área de produtos a partir de um manual de lançamento centralizado que aborda os tópicos gerais de produtos, privacidade, legais e éticos relacionados à experimentação e ao lançamento de modelos de ML.

As próprias equipes de produtos compreendem melhor as implicações do comportamento de diferentes modelos no produto e são mais adequadas para consultar especialistas relevantes para avaliar e eliminar riscos.

Planejamento coordenado entre as equipes de ML

Quando os requisitos ultrapassam os roteiros das equipes de plataforma, as equipes de engenharia de produtos podem sentir o desejo de se ramificar e construir seus próprios sistemas adaptados às suas necessidades.

É preciso ter cuidado para garantir que as equipes tenham autonomia para resolver seus próprios problemas, mas também que a empresa esteja fazendo boas compensações de engenharia para evitar a fragmentação e a dívida técnica.

Na Uber, montamos um grupo interno de líderes seniores que supervisiona a evolução das ferramentas de ML em toda a empresa para garantir que estamos fazendo concessões inteligentes e mantendo o alinhamento de arquitetura de longo prazo. Isso tem sido valioso na resolução dessas situações delicadas e às vezes sensíveis.

Comunidade

O escalonamento de ML de alta qualidade em toda a empresa requer uma organização conectada e colaborativa.
Para construir uma comunidade interna, nós hospedamos uma conferência interna anual de ML chamada UberML. Recentemente, recebemos cerca de 500 funcionários e mais de 50 grupos apresentando palestras ou pôsteres sobre seus trabalhos.

Eventos como esse permitem que os profissionais troquem ideias, celebrem conquistas e façam conexões importantes para futuras colaborações. As equipes da Uber também organizam eventos de construção comunitária, incluindo grupos de leitura de ML, séries de palestras e almoços regulares com sacolas de compras para os entusiastas do ML da Uber para aprender sobre alguns dos nossos projetos de ML internos a partir dos indivíduos que os constroem.

Nosso foco na comunidade se estende para além de nossas próprias paredes. Nossa equipe também se envolve fortemente com a comunidade externa de ML por meio de conferências, publicação de artigos, contribuição para projetos de código aberto e colaboração em projetos de ML e pesquisa com outras empresas e universidades.

Ao longo dos anos, essa comunidade se transformou em um esforço global para compartilhar as melhores práticas, colaborar em projetos de ponta e, em geral, melhorar o estado do campo.

Educação

É importante que as equipes de ML estejam sempre aprendendo. Elas precisam se manter atualizados sobre os desenvolvimentos da teoria de ML, acompanhar e aprender a partir de projetos internos de ML, e dominar o uso de nossas ferramentas de ML. Canais apropriados para compartilhar informações com eficiência e educar sobre tópicos relacionados ao ML são críticos.

A educação de ML da Uber começa durante a primeira semana de um funcionário, durante a qual realizamos sessões especiais para os campos de treinamento de ML e Michelangelo para todas as contratações técnicas.

Quando novas funcionalidades importantes são lançadas em Michelangelo, realizamos sessões especiais de treinamento com os funcionários que as utilizam com frequência.

A documentação das principais ferramentas e fluxos de trabalho do usuário também ajudou a incentivar o compartilhamento de conhecimento e a adoção em escala de nossas ferramentas de plataforma.

O horário de expediente também é realizado por diferentes grupos focados em ML na empresa para oferecer apoio quando surgirem dúvidas. Isso também ajuda para que os indivíduos que trabalham em projetos de ML na Uber sejam naturalmente aprendizes curiosos e famintos.

Muitas das iniciativas lideradas pela comunidade mencionadas acima são ótimas maneiras para os membros da equipe acompanharem os desenvolvimentos internos e externos.

Tecnologia

  • Há uma infinidade de detalhes para acertar o lado técnico de qualquer sistema de ML. Na Uber, descobrimos que as seguintes áreas de alto nível são particularmente importantes:
  • Fluxo de trabalho de ponta a ponta: O ML é mais do que apenas modelos de treinamento; você precisa de suporte para todo o fluxo de trabalho de ML: gerenciar dados, treinar modelos, avaliar modelos, implantar modelos e fazer previsões e monitorar previsões.
  • ML como engenharia de software: Descobrimos que é valioso fazer analogias entre o desenvolvimento de ML e o desenvolvimento de software e depois aplicar padrões de ferramentas de desenvolvimento de software e metodologias à nossa abordagem de ML.
  • Velocidade do desenvolvedor do modelo: O desenvolvimento do modelo de aprendizado de máquina é um processo muito interativo – a inovação e os modelos de alta qualidade vêm de muitos e muitos experimentos. Por causa disso, a velocidade do desenvolvedor do modelo é extremamente importante.
  • Modularidade e arquitetura em camadas/hierárquicas: Fornecer fluxos de trabalho de ponta a ponta é importante para lidar com os casos de uso de ML mais comuns, mas para abordar os casos menos comuns e mais especializados, é importante ter componentes primitivos que possam ser montados de maneiras específicas.

Fluxo de trabalho de ponta a ponta

Logo no início, reconhecemos que o ML bem-sucedido em uma grande empresa como a Uber requer muito mais do que apenas o treinamento de bons modelos – você precisa de suporte robusto e escalonável para todo o fluxo de trabalho.

Descobrimos que o mesmo fluxo de trabalho se aplica a uma ampla gama de cenários, incluindo o ML tradicional e o aprendizado profundo; aprendizagem supervisionada, não supervisionada e semi-supervisionada; aprendizagem online; implantações em lote, on-line e móveis; e previsão de séries temporais.

Não é essencial que uma ferramenta forneça tudo (embora seja assim que o fizemos), mas é importante ter um conjunto integrado de ferramentas que possa abordar todas as etapas do fluxo de trabalho.

Gerenciar dados

Essa é tipicamente a parte mais complexa do processo de ML e abrange o acesso a dados, descoberta de recursos, seleção e transformações que ocorrem durante o treinamento de modelo e a produção de pipelines para esses recursos quando o modelo é implantado.

Na Uber, construímos uma loja de recursos que permite às equipes compartilhar recursos de alta qualidade e gerenciar facilmente os pipelines off-line e on-line para esses recursos, à medida que os modelos são treinados e, então, implantados, garantindo consistência entre as versões on-line e off-line.

Treinar modelos

Em Michelangelo, os usuários podem treinar modelos a partir de nossa UI da web ou de Python usando nosso Data Science Workbench (DSW).

No DSW, oferecemos suporte ao treinamento distribuído em larga escala de modelos de aprendizagem profunda em clusters de GPU, modelos de árvore e lineares em clusters de CPU e treinamento de escala menor de uma grande variedade de modelos usando os inúmeros kits de ferramentas Python disponíveis.

Além de treinar modelos simples, os usuários podem compor pipelines de transformação, conjuntos e modelos empilhados mais complexos. Michelangelo também oferece pesquisa hiperparamétrica aleatória e grade escalável, bem como pesquisa hiperparamétrica Bayesiana de caixa preta mais eficiente.

Gerenciar e avaliar modelos

Encontrar a combinação certa de dados, algoritmo e hiperparâmetros é um processo experimental e iterativo. Passar por este processo de forma rápida e eficiente requer automação de todos os experimentos e os resultados.

Ele também se beneficia de boas ferramentas de visualização para entender o desempenho de cada modelo individual, além de poder comparar muitos modelos entre si para ver os padrões de configuração e os dados de recursos que melhoram o desempenho do modelo.

Os modelos gerenciados em Michelangelo são rigorosamente gerenciados, controlados por versão, totalmente reproduzíveis e têm visualizações ricas para precisão e explicabilidade do modelo.

Figura 3: Página de comparação do modelo de Michelangelo mostrando uma comparação do comportamento de dois modelos em diferentes segmentos e recursos.

Implantar modelos e fazer previsões

Depois que um modelo eficaz é treinado, é importante que o desenvolvedor do modelo possa implementar o modelo em um ambiente de preparação ou de produção. Em Michelangelo, os usuários podem implantar modelos através de nossa UI da web por conveniência ou por meio de nossa API para integração com ferramentas externas de automação.

No momento da implantação, o modelo e os recursos relacionados são empacotados e, em seguida, enviados para um trabalho off-line para previsões de lote agendadas ou para contêineres on-line para previsões de resposta de solicitação em tempo real por meio do Thrift.

Para modelos on-line e off-line, o sistema configura automaticamente os pipelines para dados do armazenamento/da loja de recursos.

Monitore dados e previsões

Os modelos são treinados e inicialmente avaliados com base em dados históricos. Isso significa que os usuários podem saber que um modelo teria funcionado bem no passado. No entanto, depois de implantar o modelo e usá-lo para fazer previsões sobre novos dados, muitas vezes é difícil garantir que ele ainda esteja funcionando corretamente.

Modelos podem degradar com o tempo, porque o mundo está sempre mudando. Além disso, pode haver quebras ou erros nas fontes de dados ou nos pipelines de dados de um modelo de produção.

Em ambos os casos, o monitoramento (e alerta) das previsões feitas pelos modelos em produção é crítico.

Temos duas abordagens para monitorar modelos em produção. A abordagem mais precisa é registrar as previsões feitas na produção e, em seguida, juntá-las aos resultados à medida que são coletados pelos nossos pipelines de dados; ao comparar as previsões em relação às reais, podemos calcular métricas de precisão precisas.

Nos casos em que os resultados não são facilmente coletados ou onde não podemos unir facilmente as previsões aos resultados, uma segunda opção é monitorar as distribuições dos recursos e previsões e compará-las ao longo do tempo.

Essa é uma abordagem menos precisa, mas ainda pode detectar mudanças problemáticas em recursos e previsões correspondentes.

ML como engenharia de software

Um princípio importante da abordagem da equipe de Michelangelo é pensar em aprendizado de máquina como engenharia de software. Desenvolver e executar o ML na produção deve ser tão iterativo, rigoroso, testado e metodológico quanto a engenharia de software.

Achamos muito valioso fazer analogias entre o ML e o desenvolvimento de software e aplicar percepções de ferramentas e metodologias de desenvolvimento de software correspondentes e maduras ao ML.

Por exemplo, uma vez que reconhecemos que um modelo é como uma biblioteca de software compilada, fica claro que queremos acompanhar a configuração de treinamento do modelo em um sistema rigoroso controlado por versão, da mesma forma que você controla por versão o código-fonte da biblioteca.

Foi importante acompanhar os recursos e a configuração usados ​​para criar o modelo para que ele possa ser reproduzido (e/ou aprimorado) posteriormente. No caso da transferência de aprendizagem em modelos de aprendizagem profunda, rastreamos toda a linhagem de modo que cada modelo possa ser treinado novamente, se necessário.

Sem bons controles e ferramentas para isso, temos visto casos em que os modelos são construídos e implantados, mas são impossíveis de reproduzir porque a configuração de dados e/ou de treinamento foi perdida.

Além disso, para garantir que o software funcione corretamente, é importante executar testes abrangentes antes que o software seja implantado; da mesma forma, sempre avaliamos modelos contra conjuntos de holdout/redutos antes de implantar.

Da mesma forma, é importante ter um bom monitoramento dos sistemas de software para garantir que eles funcionem corretamente na produção; o mesmo se aplica ao aprendizado de máquina em que você deseja monitorar os modelos na produção, pois eles podem se comportar de maneira diferente daquela na avaliação offline.

Na última parte do artigo, traremos os pontos finais e cruciais para você entender como o Michelangelo funciona aqui na Uber, ensinando máquinas de escala.

***

Este artigo é do Uber Engineering. Ele foi escrito por Jeremy Hermann e Mike Del Balso. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/scaling-michelangelo/