True ML Talks #4 - Plataforma de Machine Learning @ Salesforce

Estamos de volta com mais um episódio do True ML Talks. Neste, vamos aprofundar em da Salesforce Plataforma de ML, e vamos conversar com Arpeet Kale.

Arpeet fez parte da equipe de engenharia da Salesforce que construiu toda a plataforma de ML. Ele é um dos fundadores da Builders Fund, onde ele e seus colegas investem e aconselham empresas de ML/IA em todo o mundo. E, ao mesmo tempo, ele é o chefe de infraestrutura na Skiff.

📌

Nossas conversas com Arpeet abordarão os seguintes aspectos:
- Casos de Uso de ML na Salesforce
- Estrutura da Equipe de ML da Salesforce
- Visão Geral da Infraestrutura de ML da Salesforce
- Prototipagem de modelos de ML na Salesforce
- Gerenciamento de Custos para Projetos de ML em Grande Escala na Nuvem
- Fluxo Automatizado para Movimentação de Modelos
- Construindo um Serviço de Previsão em Tempo Real Multi-Tenant
- Otimização de modelos para IA empresarial
- Medidas de Segurança e Confiabilidade na Plataforma de IA da Salesforce
- Plataforma de Infraestrutura de ML vs Plataforma de Implantação de Software

Assista ao episódio completo abaixo:

Por que o ML é Importante para a Salesforce

1. Experiências personalizadas para o cliente → O ML permite que a Salesforce ofereça experiências personalizadas aos clientes, pois possibilita a análise de dados do cliente e a geração de insights para melhorar as interações.
2. Automação de campanhas de marketing → Ajuda os clientes da Salesforce a automatizar suas campanhas de marketing, analisando imagens, texto e dados de mídias sociais, permitindo que se concentrem em suas personas de cliente e otimizem sua estratégia de marketing.
3. Chatbots para suporte ao cliente eficiente → Os Chatbots impulsionados por ML ajudam as empresas a automatizar o suporte ao cliente, o que resulta na redução dos tempos de espera e na diminuição dos custos para o negócio.
4. Identificação e mitigação de riscos de segurança → O ML auxilia a Salesforce na identificação e mitigação de potenciais riscos de segurança, analisando dados e detectando anomalias.
5. Melhoria contínua de produtos e serviços → Ao aproveitar o ML, a Salesforce pode aprimorar continuamente seus produtos e serviços, analisando o feedback dos clientes e usando essas informações para desenvolver novos recursos e melhorias.

Estrutura da Equipe de ML da Salesforce

Na Salesforce, a equipe de ML foi dividida em três equipes:

1. Equipe de Pesquisa: A equipe de pesquisa era composta por centenas de pesquisadores que se dedicavam a problemas de pesquisa inovadores e publicavam artigos científicos
2. Equipe de ciência aplicada: A equipe de ciência aplicada era responsável pelos casos de uso de produto puro e ciência de dados.
3. Equipe de engenharia: A equipe de engenharia era responsável por construir a infraestrutura da plataforma de ML que pudesse dar suporte às equipes de pesquisa e ciência aplicada.

Encontramos este blog interessante sobre como o ML é usado pela Salesforce:

‍

How Machine Learning is Building Better Salesforce Systems

Rather than simply automating activities such as data processing, machine learning attempts to reproduce how humans think.

AppExchange and the Salesforce Ecosystem Steve Pogrebivsky

‍

Visão Geral da Infraestrutura de ML da Salesforce

A infraestrutura de ML da Salesforce foi construída sobre uma pilha de tecnologia escolhida para fornecer uma plataforma escalável e confiável. Aqui estão alguns dos pontos mais relevantes e únicos sobre a infraestrutura:

1. A infraestrutura estava rodando na AWS, e o Kubernetes era usado para gerenciar todo o processamento. O uso do Kubernetes permitia a fácil implantação de qualquer tipo de framework de aprendizado de máquina, seja TensorFlow ou Pytorch.
2. Havia uma separação de clusters entre a equipe de pesquisa, a equipe de ciência aplicada e a equipe de engenharia. Isso permitia uma melhor gestão da capacidade de processamento e dos recursos.
3. A plataforma foi construída em torno de um orquestrador para treinamento, um serviço de previsão em tempo real, um serviço de previsão em lote e uma API de front-end para gerenciar operações de usuário, como autenticação e autorização.
4. A infraestrutura consistia em um banco de dados SQL estruturado e um armazenamento de arquivos não estruturado como o S3, que eram usados para gerenciar dados. A plataforma era responsável por gerenciar os dados entre os dois.
5. Havia uma mistura de clusters de GPU, dependendo do caso de uso. Isso permitia o uso eficiente de recursos e um melhor desempenho.

📌

As principais razões pelas quais é importante separar clusters na infraestrutura de aprendizado de máquina são:

1. Segurança: Separar clusters reduz o risco de violações de dados e acesso não autorizado a dados sensíveis. Cada equipa pode trabalhar no seu próprio ambiente com as medidas de segurança necessárias.
2. Conformidade de Dados: Equipas diferentes podem ter requisitos de conformidade de dados distintos, que podem ser atendidos pela separação de clusters. Isso garante que cada equipa esteja a trabalhar com dados que cumprem os requisitos regulamentares necessários.
3. Gestão de Recursos: Separar clusters permite que as equipas tenham os recursos de que necessitam para concluir as suas tarefas sem interferir com os recursos de outras equipas. Isso garante o uso eficiente dos recursos e evita a contenção de recursos.

Prototipagem na Salesforce: Uma Abordagem Determinada

Na Salesforce, a estrutura de prototipagem foi construída em torno de Jupyter Notebooks, permitindo que os cientistas de dados executassem experiências de curto prazo de forma interativa e em tempo real. As experiências eram então transicionadas para um trabalho de longa duração num cluster de grande escala, produzindo métricas em tempo real à medida que o trabalho era executado.

O SDK de treino e experimentação foi construído para abstrair a complexidade do agendamento de tarefas, da extração e envio de dados, e das dependências do sistema. Os cientistas de dados podiam chamar uma API ou função Python para cuidar destas tarefas e acompanhar o progresso da experiência, métricas, registos e muito mais no painel do workbench.

A estrutura era determinada, fornecendo uma solução abstrata, mas ainda permitindo alguma flexibilidade na forma como os cientistas de dados escolhiam usar a plataforma. No entanto, não era uma experiência de estilo completamente livre, e havia diretrizes e padrões internos a seguir.

📌

Desafios de Hospedar Jupyter Notebooks em Escala com Dados Sensíveis:
Ao hospedar Jupyter Notebooks em grande escala com dados sensíveis, os principais desafios envolvem fluxos de trabalho de aprovação para autenticação. Os cientistas de dados devem obter aprovação de uma determinada pessoa ou gestor para aceder aos dados. O ambiente do notebook é efémero e destruído após a conclusão das experiências, mas todos os artefactos gerados são persistidos. A autenticação é baseada em API e integrada com sistemas internos.

Como Gerir Custos em Projetos de Machine Learning em Grande Escala na Nuvem

Projetos de machine learning em grande escala podem rapidamente tornar-se dispendiosos, especialmente ao utilizar recursos de GPU na nuvem. Para gerir os custos durante a fase de prototipagem, existem algumas estratégias que podem ser empregadas.

1. Capacidade Reservada: Se souber quanta capacidade precisa, pode reservá-la com antecedência e obter um desconto no preço. Isso funciona bem se tiver uma boa ideia de quais serão os seus requisitos de recursos a longo prazo.
2. Autoescalamento: Se você não tem certeza de quanta capacidade precisará ou se seus requisitos de recursos flutuam, o autoescalonamento pode ajudar. Ao escalar automaticamente os recursos para cima ou para baixo com base na demanda, você pode evitar pagar por capacidade não utilizada.

Embora existam outras estratégias para reduzir custos, como a utilização de instâncias spot, estas frequentemente exigem muito esforço de engenharia e podem não ser práticas para trabalhos de longa duração. Além disso, as instâncias spot podem nem sempre estar disponíveis em regiões com recursos de GPU.

Ao utilizar capacidade reservada e autoescalonamento, você pode gerenciar custos de forma eficaz, mantendo os recursos necessários para seus projetos de aprendizado de máquina. Essas estratégias continuam relevantes hoje e podem ser aplicadas a qualquer provedor de nuvem pública.

Fluxo Automatizado para Movimentação de Modelos

O fluxo de promoção da Salesforce para mover modelos de um ambiente para outro dependia da noção de conjuntos de dados "golden" para cada domínio. Os cientistas de dados podiam avaliar o desempenho do modelo nesses conjuntos de dados e também em conjuntos de dados aleatórios para avaliar a capacidade do modelo de ter um bom desempenho em diferentes tipos de dados. Isso os ajudou a decidir se promoviam ou não um modelo para ambientes superiores.

O processo de promoção era feito através do workbench, mas foi intencionalmente mantido ligeiramente manual para garantir que o modelo tivesse um desempenho acima de um certo limite em n+1 tipos de conjuntos de dados. Isso era desafiador porque a Salesforce é um sistema multi-inquilino, e cada cliente tem um conjunto de dados diferente, às vezes na casa das centenas de milhares. A Salesforce construiu centenas de milhares de modelos, cada um específico para um cliente e conjunto de dados, e automatizou o processo o máximo possível.

No geral, o fluxo de promoção na Salesforce foi projetado para garantir que os modelos fossem minuciosamente avaliados e tivessem um bom desempenho em diversos conjuntos de dados antes de serem promovidos para ambientes superiores.

Construindo um Serviço de Previsão em Tempo Real Multi-inquilino para Modelos Complexos

Construir um serviço de previsão em tempo real multi-inquilino é uma tarefa complexa que envolve servir um grande número de modelos com diferentes tamanhos e arquiteturas em tempo real, ao mesmo tempo em que atende a requisitos específicos de SLA. Para enfrentar esse desafio, a equipe de engenharia da Salesforce desenvolveu uma camada de serviço que passou por várias iterações.

Inicialmente, a equipe dependia de um banco de dados estruturado para metadados e de um armazenamento de arquivos para artefatos de modelo. No entanto, essa abordagem não era escalável para modelos maiores e mais complexos. Para resolver isso, eles fragmentaram seus clusters com base na complexidade do modelo e no tipo de computação necessária. Por exemplo, modelos menores rodavam em CPUs, enquanto modelos maiores precisavam de GPUs. Os clusters eram dedicados a tipos específicos de modelos, como modelos de PNL, modelos LSTM, modelos transformer, modelos de classificação de imagem, modelos de detecção de objetos e modelos OCR.

A equipe também desenvolveu uma camada que orquestrava a implantação de serviços em diferentes clusters e grupos de nós. Eles implementaram cache para garantir que os modelos frequentemente solicitados tivessem latências mais baixas. Inicialmente, cientistas de dados e pesquisadores podiam usar sua estrutura preferida, o que tornava desafiador servir os modelos de forma uniforme. A equipe reduziu as estruturas para uma ou duas e otimizou os modelos para essas estruturas.

Finalmente, a equipe converteu os modelos para um formato uniforme, independentemente da estrutura de treinamento original, permitindo otimizar o código de serviço para cada tipo de modelo. No geral, os esforços da equipe resultaram em um serviço de previsão em tempo real escalável, eficiente e confiável.

A inferência em tempo real era a minha coisa favorita para trabalhar. E eu acho que, no final, também conseguimos registrar uma patente sobre ela. Então, foi um ótimo recurso de engenharia que adicionamos à plataforma. Foi o recurso mais usado, na verdade. Estávamos fazendo dezenas de milhões de previsões por dia e, por isso, foi muito, muito gratificante ver isso sendo usado por tantos clientes.
- Arpeet

Encontramos este blog interessante sobre ML Lakes e a arquitetura da Plataforma de Dados da Salesforce:

‍

ML Lake: Building Salesforce’s Data Platform for Machine Learning - Salesforce Engineering Blog

Explore some unique challenges Salesforce has in the realm of data management and learn how ML Lake addresses them.

Salesforce Engineering Blog Eli Levine, Laura Lindeman

Otimização de modelos para IA empresarial

Eles fizeram muitos benchmarks de modelos e procuraram permanecer dentro dos limites de operadores amplamente suportados e outras operações dentro de uma estrutura para garantir uma fácil conversão. Operadores personalizados eram uma conversão de alta fricção e exigiam uma abordagem de alto contato, mas a equipe descobriu que 95% dos casos de uso eram facilmente resolvidos por modelos prontos que não exigiam técnicas inovadoras. Isso lhes permitiu otimizar para a maioria dos casos de uso e dedicar tempo aos 5% restantes de modelos que não eram tão amplamente utilizados.

Arpeet também observou que frameworks como Onyx, Triton e o Inference Server da NVIDIA fizeram avanços significativos na padronização de formatos de modelo e benchmarking, tornando-os ferramentas valiosas para casos de uso de inferência em tempo real em larga escala.

Medidas de Segurança e Confiabilidade na Plataforma de IA da Salesforce

1. Aprovação fluxos de trabalho: Antes de implantar o modelo em produção, havia fluxos de trabalho de aprovação relacionados ao conjunto de dados para garantir a privacidade dos dados.
2. Isolamento de Segurança: O ambiente de produção era completamente isolado e possuía certificações como conformidade com HIPAA e ISO.
3. Multi-locação: A autenticação abrangia todos os locatários para garantir que apenas um cliente específico pudesse acessar seus próprios dados.
4. Redundância e Alta Disponibilidade: Medidas suficientes de redundância e alta disponibilidade foram incorporadas à plataforma para garantir a confiabilidade.

Plataforma de Infraestrutura de ML vs. Plataforma de Implantação de Software

Plataformas de infraestrutura de aprendizado de máquina e plataformas de implantação de software têm muito em comum, de acordo com a discussão entre Anuraag e Arpeet. Aqui estão os principais pontos:

1. Semelhanças: Ambos exigem uma camada de dados, camada de computação, camada de orquestração, serviço de autenticação e gateway de API, e serviço de backend. O serviço de backend pode executar cargas de trabalho de análise ou engenharia de dados em uma infraestrutura padrão, enquanto na infraestrutura de ML, ele executa uma carga de trabalho de ML.
2. Diferenças: A infraestrutura de ML pode ter um data lake ou um ML lake para uma carga de trabalho de ML, enquanto a infraestrutura padrão pode não exigir isso. A infraestrutura de ML também pode usar sistemas de orquestração especializados.
3. Ferramentas: As ferramentas em ambas as plataformas de infraestrutura são diferentes. A infraestrutura de ML pode exigir ferramentas especializadas para orquestração, enquanto a infraestrutura padrão pode usar ferramentas mais simples. No entanto, a ferramenta de implantação para ambas as plataformas de infraestrutura é a mesma na maioria dos casos, especialmente ao implantar em um cluster Kubernetes.

No geral, não há diferença significativa entre plataformas de infraestrutura de aprendizado de máquina e plataformas de implantação de software, exceto pela natureza da carga de trabalho e pelas ferramentas necessárias para a orquestração.

Considerações Adicionais de Arpeet

MLOps: Construir ou Comprar

1. Utilize alternativas disponíveis que ofereçam muitos recursos prontos para uso ao construir infraestrutura de ML para empresas de médio porte e startups.
2. Para startups em estágio inicial, use scripts Python simples, treine em uma máquina com várias GPUs e implemente alguma forma de orquestração para economizar custos.
3. Para fluxos de trabalho de ML estabelecidos em empresas pequenas e de médio porte, use ferramentas de código aberto diretamente, mas considere usar uma solução pronta para uso como o TrueFoundry.

Conselhos para Engenheiros de ML

Acho que diria que focar em um nicho neste momento, em termos de operacionalizar um fluxo de trabalho de IA em larga escala, provavelmente será um dos próximos conjuntos de desafios difíceis.
- Arpeet

Leia nossos blogs anteriores da Série TrueML

‍

‍‍True ML Talks #3 - Machine Learning Platform @ Facebook

In this blog, we dive deep into Facebook’s ML Platform FBLearner Flow. Understand how it solved both Software and ML deployment and understand its architecture‍TrueFoundry discussing ML platform in Meta

TrueFoundry Blog TrueFoundry

‍

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

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 em produção mais rapidamente, possibilitando a realização de valor de negócio real.