True ML Talks #4 - Machine Learning Platform @ Salesforce

We zijn terug met een nieuwe aflevering van  True ML Talks. In deze aflevering duiken we diep in het ML Platform van Salesforce, en spreken we met Arpeet Kale.

Arpeet maakte deel uit van het engineering-team bij Salesforce dat het volledige ML-platform heeft gebouwd. Hij is een van de oprichters van Builders Fund, waar hij en zijn collega's investeren in en advies geven aan ML/AI-bedrijven over de hele wereld. En tegelijkertijd is hij head of infrastructure bij Skiff.

📌

Onze gesprekken met Arpeet behandelen de volgende aspecten:
- ML Usecases in Salesforce
- Salesforce ML Team Structure
- Overzicht van Salesforce ML Infrastructure
- Prototyping van ML-modellen bij Salesforce
- Kosten beheren voor grootschalige ML-projecten in de cloud
- Geautomatiseerde flow voor het verplaatsen van modellen
- Het bouwen van een multi-tenant real-time prediction service
- Optimalisatie van modellen voor enterprise AI
- Beveiligings- en betrouwbaarheidsmaatregelen in het Salesforce AI Platform
- ML Infrastructure Platform vs Software Deployment Platform

Bekijk de volledige aflevering hieronder:

Waarom ML belangrijk is voor Salesforce

1. Gepersonaliseerde klantervaringen → ML stelt Salesforce in staat om gepersonaliseerde klantervaringen te bieden, omdat het hen in staat stelt klantgegevens te analyseren en inzichten te genereren om klantinteracties te verbeteren.
2. Automatisering van marketingcampagnes → Het helpt Salesforce-klanten om hun marketingcampagnes te automatiseren door beelden, tekst en social media-data te analyseren, waardoor ze zich kunnen richten op hun klantpersona's en hun marketingstrategie kunnen optimaliseren.
3. Chatbots voor efficiënte klantenservice → De door ML aangedreven chatbots helpen bedrijven hun klantenservice te automatiseren, wat resulteert in kortere wachttijden en lagere kosten voor het bedrijf.
4. Identificeren en beperken van beveiligingsrisico's → ML helpt Salesforce bij het identificeren en beperken van potentiële beveiligingsrisico's door data te analyseren en anomalieën te detecteren.
5. Continu verbeteren van producten en diensten → Door gebruik te maken van ML kan Salesforce zijn producten en diensten continu verbeteren door feedback van klanten te analyseren en die informatie te gebruiken om nieuwe functies en verbeteringen te ontwikkelen.

Salesforce ML Team Structure

Bij Salesforce was het ML-team onderverdeeld in drie teams:

1. Research-team: Het research-team bestond uit honderden onderzoekers die zich richtten op nieuwe onderzoeksvraagstukken en wetenschappelijke artikelen publiceerden
2. Applied science-team: Het applied science-team was verantwoordelijk voor het pure product en de data science-use cases
3. Engineering-team: Het engineering-team was verantwoordelijk voor het bouwen van de ML-platforminfrastructuur die de research- en applied science-teams kon ondersteunen.

We vonden deze interessante blog over hoe ML wordt gebruikt door 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

‍

Overzicht van Salesforce ML Infrastructure

De Salesforce ML-infrastructuur is gebouwd op een tech stack die is gekozen om een schaalbaar en betrouwbaar platform te bieden. Hier zijn enkele van de meest relevante en unieke punten over de infrastructuur:

1. De infrastructuur draaide op AWS, en Kubernetes werd gebruikt om alle compute te beheren. Het gebruik van Kubernetes maakte een eenvoudige deployment van elk type machine learning-framework mogelijk, zoals TensorFlow of PyTorch.
2. Er was een scheiding van clusters tussen het research-team, applied science-team en engineering-team. Dit zorgde voor een beter beheer van de compute-capaciteit en resources.
3. Het platform was gebouwd rondom een orchestrator voor training, een real-time prediction service, een batch prediction service en een front-end API voor het beheren van gebruikersoperaties zoals authenticatie en autorisatie.
4. De infrastructuur bestond uit een gestructureerde SQL-database en een ongestructureerde file store zoals S3, die werden gebruikt voor het beheren van data. Het platform was verantwoordelijk voor het databeheer tussen de twee.
5. Er was een mix van GPU-clusters, afhankelijk van de use case. Dit zorgde voor een efficiënt gebruik van resources en betere prestaties.

📌

De belangrijkste redenen waarom het belangrijk is om clusters te scheiden in een machine learning-infrastructuur zijn:

1. Beveiliging: Het scheiden van clusters vermindert het risico op datalekwijdten en ongeautoriseerde toegang tot gevoelige gegevens. Elk team kan werken in zijn eigen omgeving met de nodige beveiligingsmaatregelen.
2. Data Compliance: Verschillende teams kunnen verschillende vereisten voor data compliance hebben, waaraan voldaan kan worden door clusters te scheiden. Dit zorgt ervoor dat elk team werkt met data die voldoet aan de nodige regelgeving.
3. Resource Beheer: Het scheiden van clusters stelt teams in staat om de resources te hebben die ze nodig hebben om hun taken te voltooien, zonder de resources van andere teams te verstoren. Dit zorgt voor een efficiënt gebruik van resources en voorkomt resource-conflicten.

Prototyping bij Salesforce: Een opinieërende benadering

Bij Salesforce was het prototyping-framework gebouwd rond Jupyter Notebooks, waardoor data scientists kortlopende experimenten interactief en in real-time konden uitvoeren. De experimenten werden vervolgens overgezet naar een langlopende job op een grootschalig cluster, wat real-time metrics opleverde terwijl de job draaide.

De training en experimentation SDK is gebouwd om de complexiteit van het inplannen van jobs, het ophalen en pushen van data, en systeemafhankelijkheden te abstraheren. Data scientists konden een Python API of functie aanroepen om deze taken uit te voeren, en de voortgang van het experiment, metrics, logs en meer volgen in het workbench-dashboard.

Het framework was opinieërend en bood een geabstraheerde oplossing, maar liet toch enige flexibiliteit toe in de manier waarop data scientists ervoor kozen het platform te gebruiken. Het was echter geen volledig vrijblijvend experiment, en er waren interne richtlijnen en standaarden om te volgen.

📌

Uitdagingen bij het hosten van Jupyter Notebooks op schaal met gevoelige data:
Bij het hosten van Jupyter Notebooks op grote schaal met gevoelige data betreffen de grootste uitdagingen de goedkeuringsworkflows voor authenticatie. Data scientists moeten goedkeuring vragen aan een specifieke persoon of manager om toegang te krijgen tot de data. De notebook-omgeving is efemer en wordt vernietigd nadat experimenten zijn voltooid, maar alle gegenereerde artefacten blijven bewaard. De authenticatie is API-gestuurd en geïntegreerd met interne systemen.

Hoe u kosten kunt beheren voor grootschalige Machine Learning-projecten in de cloud

Grootschalige machine learning-projecten kunnen snel kostbaar worden, vooral bij het gebruik van GPU-resources in de cloud. Om de kosten tijdens de prototyping-fase te beheren, kunnen enkele strategieën worden toegepast.

1. Gereserveerde Capaciteit: Als u weet hoeveel capaciteit u nodig heeft, kunt u deze van tevoren reserveren en korting krijgen op de prijs. Dit werkt goed als u een goed beeld heeft van wat uw resource-vereisten op de lange termijn zullen zijn.
2. Auto-Scaling: Als u niet zeker weet hoeveel capaciteit u nodig heeft of als uw resource-vereisten fluctueren, kan auto-scaling helpen. Door resources automatisch op- of af te schalen op basis van de vraag, kunt u voorkomen dat u betaalt voor ongebruikte capaciteit.

Hoewel er andere strategieën zijn om kosten te verlagen, zoals het gebruik van spot instances, vereisen deze vaak veel engineering-inspanning en zijn ze mogelijk niet praktisch voor langlopende jobs. Bovendien zijn spot instances mogelijk niet altijd beschikbaar in regio's met GPU-resources.

Door gebruik te maken van gereserveerde capaciteit en auto-scaling kunt u kosten effectief beheren, terwijl u toch de resources behoudt die u nodig heeft voor uw machine learning-projecten. Deze strategieën blijven vandaag de dag relevant en kunnen worden toegepast op elke public cloud provider.

Geautomatiseerde flow voor het verplaatsen van modellen

De promotie-flow van Salesforce om modellen van de ene omgeving naar de andere te verplaatsen, vertrouwde op het concept van golden datasets voor elk domein. De data scientists konden de prestaties van het model evalueren op deze datasets en ook op gewijzigde/willekeurige datasets om het vermogen van het model te beoordelen om goed te presteren op verschillende typen data. Dit hielp hen te beslissen of ze een model wilden promoveren naar hogere omgevingen of niet.

Het promotieproces werd uitgevoerd via de workbench, maar werd opzettelijk enigszins handmatig gehouden om te garanderen dat het model boven een bepaalde drempel presteerde op n+1 typen datasets. Dit was uitdagend omdat Salesforce een multi-tenant systeem is en elke klant een andere dataset heeft, soms in de honderdduizenden. Salesforce bouwde honderdduizenden modellen, elk specifiek voor een klant en dataset, en automatiseerde het proces zo veel mogelijk.

Over het algemeen was de promotie-flow bij Salesforce ontworpen om ervoor te zorgen dat modellen grondig werden geëvalueerd en goed presteerden op diverse datasets voordat ze werden gepromoveerd naar hogere omgevingen.

Het bouwen van een Multi-Tenant Real-Time Prediction Service voor complexe modellen

Het bouwen van een multi-tenant real-time prediction service is een complexe taak die het in real-time serveren van een groot aantal modellen met verschillende groottes en architecturen omvat, terwijl er aan specifieke SLA-vereisten wordt voldaan. Om deze uitdaging aan te pakken, heeft het engineering-team van Salesforce een serving-laag ontwikkeld die meerdere iteraties heeft ondergaan.

Aanvankelijk vertrouwde het team op een gestructureerde database voor metadata en een file store voor model-artefacten. Deze aanpak was echter niet schaalbaar voor grotere en complexere modellen. Om dit op te lossen, hebben ze hun clusters geshard op basis van de complexiteit van het model en het vereiste type compute. Kleinere modellen draaiden bijvoorbeeld op CPU's, terwijl grotere modellen GPU's nodig hadden. Clusters waren toegewijd aan specifieke typen modellen, zoals NLP-modellen, LSTM-modellen, transformer-modellen, beeldclassificatiemodellen, objectdetectiemodellen en OCR-modellen.

Het team ontwikkelde ook een laag die de deployment van services op verschillende clusters en nodegroups orchestreerde. Ze implementeerden caching om ervoor te zorgen dat frequent aangevraagde modellen lagere latencies hadden. Aanvankelijk mochten data- en research scientists hun voorkeursframework gebruiken, wat het lastig maakte om de modellen uniform te serveren. Het team bracht het aantal frameworks terug naar één of twee en optimaliseerde de modellen voor deze frameworks.

Ten slotte converteerde het team de modellen naar een uniform formaat, ongeacht het oorspronkelijke trainingsframework, waardoor ze de serving-code voor elk modeltype konden optimaliseren. Al met al resulteerden de inspanningen van het team in een schaalbare, efficiënte en betrouwbare real-time prediction service.

The real-time inference was my favorite thing to work on. And I think, by the end of it, we also were able to file a patent on it. So, it was a great engineering feature that we added to the platform. It was the most used feature, actually. We were doing double-digit, millions of predictions per day and so it was very, very satisfying to see that getting used by so many customers.
- Arpeet

We vonden deze interessante blog over ML Lakes en de architectuur van Salesforce's Data Platform:

‍

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

Optimalisatie van modellen voor enterprise AI

Ze voerden uitgebreide benchmarks uit op modellen en streefden ernaar binnen de grenzen van breed ondersteunde operators en andere operaties binnen een framework te blijven om een eenvoudige conversie te garanderen. Custom operators zorgden voor een conversie met veel wrijving en vereisten een intensieve aanpak, maar het team stelde vast dat 95% van de use cases eenvoudig kon worden opgelost met kant-en-klare modellen die geen nieuwe technieken vereisten. Hierdoor konden ze optimaliseren voor de meerderheid van de use cases en tijd besteden aan de resterende 5% van de modellen die niet zo breed werden gebruikt.

Arpeet merkte ook op dat frameworks zoals Onyx, Triton en NVIDIA's Inference Server aanzienlijke vooruitgang hebben geboekt bij het standaardiseren van modelformaten en benchmarking, waardoor ze waardevolle tools zijn voor grootschalige real-time inference use cases.

Beveiligings- en betrouwbaarheidsmaatregelen in het Salesforce AI Platform

1. Approval workflows: Voorafgaand aan de deployment van het model in productie waren er goedkeuringsworkflows rondom de dataset om dataprivacy te waarborgen.
2. Security Isolation: De productie-omgeving was volledig geïsoleerd en beschikte over certificeringen zoals HIPAA- en ISO-compliance.
3. Multi-tenancy: Auth omvatte alle tenants om ervoor te zorgen dat alleen een specifieke klant toegang had tot zijn eigen data.
4. Redundantie en Hoge Beschikbaarheid: Voldoende redundantie- en hoge beschikbaarheidsmaatregelen waren ingebouwd in het platform om betrouwbaarheid te garanderen.

ML Infrastructure Platform vs Software Deployment Platform

Machine learning-infrastructuurplatforms en software deployment-platforms hebben veel gemeen, volgens de discussie tussen Anuraag en Arpeet. Hier zijn de belangrijkste inzichten:

1. Overeenkomsten: Beide vereisen een datalaag, compute-laag, orchestratielaag, auth-service en API-gateway, en een backend-service. De backend-service kan analytics- of data engineering-workloads uitvoeren in een standaardinfrastructuur, terwijl deze in een ML-infrastructuur een ML-workload uitvoert.
2. Verschillen: De ML-infrastructuur kan een data lake of een ML lake hebben voor een ML-workload, terwijl een standaardinfrastructuur dat mogelijk niet vereist. De ML-infrastructuur kan ook gebruikmaken van gespecialiseerde orchestratiesystemen.
3. Tooling: De tooling in beide infrastructuurplatforms is verschillend. ML-infrastructuur kan gespecialiseerde tools vereisen voor orchestratie, terwijl een standaardinfrastructuur eenvoudigere tools kan gebruiken. De deployment-tool voor beide infrastructuurplatforms is in de meeste gevallen echter hetzelfde, vooral bij deployment op een Kubernetes-cluster.

Over het algemeen is er geen aanzienlijk verschil tussen machine learning-infrastructuurplatforms en software deployment-platforms, behalve de aard van de workload en de tooling die nodig is voor orchestratie.

Aanvullende gedachten van Arpeet

MLOps: Bouwen vs Kopen

1. Gebruik beschikbare alternatieven die direct uit de doos veel functies bieden bij het bouwen van een ML-infrastructuur voor middelgrote bedrijven en startups.
2. Gebruik voor startups in een vroeg stadium eenvoudige Python-scripts, train op één machine met meerdere GPU's en implementeer een vorm van orchestratie om kosten te besparen.
3. Gebruik voor gevestigde ML-workflows in kleine tot middelgrote bedrijven direct open-source tools, maar overweg het gebruik van een kant-en-klare oplossing zoals TrueFoundry.

Advies voor ML Engineers

I think I would say that focusing on a niche at this point, in terms of, either operationalizing a large-scale AI workflow is probably going to be the next set of one of difficult challenges.
- Arpeet

Lees onze vorige blogs in de TrueML-serie

‍

‍‍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

‍

Blijf kijken naar de TrueML YouTube-serie en lees de gehele TrueML blogserie.

TrueFoundry is een ML Deployment PaaS op Kubernetes om de workflows van ontwikkelaars te versnellen, terwijl ze de volle flexibiliteit behouden bij het testen en deployen van modellen, en tegelijkertijd volledige beveiliging en controle garanderen voor het infra-team. Via ons platform stellen we Machine Learning-teams in staat om modellen binnen 15 minuten te deployen en monitoren met 100% betrouwbaarheid, schaalbaarheid en de mogelijkheid om in seconden terug te draaien - waardoor ze kosten besparen en modellen sneller naar productie kunnen brengen, wat leid tot echte zakelijke waarde.