True ML Talks #4 – Machine Learning Platform bei Salesforce

Wir sind zurück mit einer weiteren Episode von  True ML Talks. In dieser Folge tauchen wir tief in die ML Platform von Salesforce ein und sprechen mit Arpeet Kale.

Arpeet war Teil des Engineering-Teams bei Salesforce, das die gesamte ML-Plattform aufgebaut hat. Er ist einer der Gründer von Builders Fund, wo er gemeinsam mit seinen Kollegen weltweit in ML/AI-Unternehmen investiert und diese berät. Gleichzeitig ist er Head of Infrastructure bei Skiff.

📌

Unsere Gespräche mit Arpeet decken die folgenden Aspekte ab:
- ML-Anwendungsfälle bei Salesforce
- Die Struktur des ML-Teams bei Salesforce
- Überblick über die ML-Infrastruktur von Salesforce
- Prototyping von ML-Modellen bei Salesforce
- Kostenmanagement für groß angelegte ML-Projekte in der Cloud
- Automatisierter Flow für das Verschieben von Modellen
- Aufbau eines mandantenfähigen Echtzeit-Vorhersagedienstes
- Optimierung von Modellen für Enterprise AI
- Sicherheits- und Zuverlässigkeitsmaßnahmen in der Salesforce AI Platform
- ML Infrastructure Platform vs. Software Deployment Platform

Sehen Sie sich die vollständige Episode unten an:

Warum ML für Salesforce wichtig ist

1. Personalisierte Kundenerlebnisse → ML ermöglicht Salesforce die Bereitstellung personalisierter Kundenerlebnisse, da Kundendaten analysiert und Erkenntnisse zur Verbesserung von Kundeninteraktionen gewonnen werden können.
2. Automatisierung von Marketingkampagnen → Es hilft Salesforce-Kunden, ihre Marketingkampagnen zu automatisieren, indem Bilder, Texte und Social-Media-Daten analysiert werden. So können sie sich auf ihre Kunden-Personas konzentrieren und ihre Marketingstrategie optimieren.
3. Chatbots für effizienten Kundensupport → ML-gestützte Chatbots helfen Unternehmen bei der Automatisierung des Kundensupports, was zu kürzeren Wartezeiten und geringeren Kosten für das Unternehmen führt.
4. Erkennung und Minimierung von Sicherheitsrisiken → ML unterstützt Salesforce bei der Identifizierung und Vermeidung potenzieller Sicherheitsrisiken durch Datenanalyse und Anomalieerkennung.
5. Kontinuierliche Verbesserung von Produkten und Dienstleistungen → Durch den Einsatz von ML kann Salesforce seine Produkte und Dienstleistungen kontinuierlich verbessern, indem Kundenfeedback analysiert und zur Entwicklung neuer Funktionen und Verbesserungen genutzt wird.

Struktur des ML-Teams bei Salesforce

Bei Salesforce war das ML-Team in drei Bereiche unterteilt:

1. Research Team: Das Forschungsteam bestand aus hunderten von Forschern, die sich auf neuartige Forschungsfragen konzentrierten und wissenschaftliche Arbeiten veröffentlichten.
2. Applied Science Team: Das angewandte Wissenschaftsteam war für das reine Produkt und Data-Science-Anwendungsfälle verantwortlich.
3. Engineering Team: Das Engineering-Team war für den Aufbau der ML-Plattform-Infrastruktur zuständig, die das Research- und Applied-Science-Team unterstützte.

Wir haben diesen interessanten Blogbeitrag darüber gefunden, wie ML bei Salesforce eingesetzt wird:

‍

Wie Machine Learning bessere Salesforce-Systeme aufbaut

Statt einfach nur Aktivitäten wie die Datenverarbeitung zu automatisieren, versucht Machine Learning, das menschliche Denken nachzubilden.

AppExchange und das Salesforce-Ökosystem Steve Pogrebivsky

‍

Überblick über die ML-Infrastruktur von Salesforce

Die Salesforce-ML-Infrastruktur wurde auf einem Tech-Stack aufgebaut, der ausgewählt wurde, um eine skalierbare und zuverlässige Plattform zu bieten. Hier sind einige der relevantesten und einzigartigsten Punkte zur Infrastruktur:

1. Die Infrastruktur lief auf AWS, und Kubernetes wurde zur Verwaltung der gesamten Compute-Ressourcen genutzt. Der Einsatz von Kubernetes ermöglichte das einfache Deployment jeder Art von Machine-Learning-Framework, egal ob TensorFlow oder PyTorch.
2. Es gab eine Trennung der Cluster zwischen dem Research Team, dem Applied Science Team und dem Engineering Team. Dies ermöglichte eine bessere Verwaltung von Compute-Kapazitäten und Ressourcen.
3. Die Plattform war um einen Orchestrator für das Training, einen Echtzeit-Vorhersagedienst, einen Batch-Vorhersagedienst und ein Frontend-API zur Verwaltung von Benutzeroperationen wie Authentifizierung und Autorisierung herum aufgebaut.
4. Die Infrastruktur bestand aus einer strukturierten SQL-Datenbank und einem unstrukturierten Dateispeicher wie S3 zur Datenverwaltung. Die Plattform war für die Datenverwaltung zwischen beiden Systemen verantwortlich.
5. Je nach Anwendungsfall kam eine Mischung aus GPU-Clustern zum Einsatz. Dies ermöglichte eine effiziente Ressourcennutzung und eine bessere Leistung.

📌

Die Hauptgründe, warum die Trennung von Clustern in einer Machine-Learning-Infrastruktur wichtig ist:

1. Sicherheit: Das Trennen von Clustern verringert das Risiko von Datenpannen und unbefugtem Zugriff auf sensible Daten. Jedes Team kann in seiner eigenen Umgebung mit den erforderlichen Sicherheitsmaßnahmen arbeiten.
2. Data Compliance: Verschiedene Teams haben möglicherweise unterschiedliche Anforderungen an die Data Compliance, die durch die Trennung von Clustern erfüllt werden können. So wird sichergestellt, dass jedes Team mit Daten arbeitet, die den notwendigen regulatorischen Vorgaben entsprechen.
3. Ressourcenmanagement: Die Trennung von Clustern ermöglicht es Teams, die benötigten Ressourcen zur Erledigung ihrer Aufgaben zu nutzen, ohne die Ressourcen anderer Teams zu beeinträchtigen. Das sorgt für eine effiziente Ressourcennutzung und verhindert Ressourcenkonflikte.

Prototyping bei Salesforce: Ein meiningstarker Ansatz

Bei Salesforce war das Prototyping-Framework um Jupyter Notebooks herum aufgebaut, sodass Data Scientists kurzfristige Experimente interaktiv und in Echtzeit ausführen konnten. Die Experimente wurden anschließend in langlebige Jobs auf einem groß angelegten Cluster überführt, die während der Laufzeit Echtzeit-Metriken lieferten.

Das Trainings- und Experimentier-SDK wurde entwickelt, um die Komplexität der Job-Planung, des Daten-Pullings und -Pushings sowie der Systemabhängigkeiten zu abstrahieren. Data Scientists konnten ein Python-API oder eine Funktion aufrufen, um diese Aufgaben zu erledigen und den Fortschritt des Experiments, Metriken, Logs und mehr im Workbench-Dashboard zu verfolgen.

Das Framework war klar strukturiert ("opinionated") und bot eine abstrahierte Lösung, erlaubte aber dennoch Flexibilität bei der Nutzung der Plattform durch die Data Scientists. Es handelte sich jedoch nicht um völlig freie Experimente; es gab interne Richtlinien und Standards zu beachten.

📌

Herausforderungen beim Hosting von Jupyter Notebooks im großen Maßstab mit sensiblen Daten:
Beim Hosting von Jupyter Notebooks im großen Maßstab mit sensiblen Daten bestehen die größten Herausforderungen in den Freigabeworkflows für die Authentifizierung. Data Scientists müssen die Genehmigung einer bestimmten Person oder eines Managers einholen, um auf die Daten zugreifen zu können. Die Notebook-Umgebung ist ephemeral und wird nach Abschluss der Experimente gelöscht, wobei alle erzeugten Artefakte persistent gespeichert werden. Die Authentifizierung erfolgt API-gesteuert und ist in interne Systeme integriert.

Kostenmanagement für groß angelegte Machine-Learning-Projekte in der Cloud

Groß angelegte Machine-Learning-Projekte können schnell kostspielig werden, insbesondere bei der Nutzung von GPU-Ressourcen in der Cloud. Um die Kosten während der Prototyping-Phase zu steuern, können verschiedene Strategien eingesetzt werden.

1. Reservierte Kapazität: Wenn Sie wissen, wie viel Kapazität Sie benötigen, können Sie diese im Voraus reservieren und Rabatte auf die Preise erhalten. Das funktioniert gut, wenn Sie langfristig eine genaue Vorstellung von Ihren Ressourcenanforderungen haben.
2. Auto-Scaling: Wenn Sie nicht sicher sind, wie viel Kapazität Sie benötigen, oder wenn Ihre Ressourcenanforderungen schwanken, hilft Auto-Scaling. Durch automatisches Hoch- oder Herunterskalieren der Ressourcen je nach Bedarf vermeiden Sie Zahlungen für ungenutzte Kapazitäten.

Obwohl es weitere Strategien zur Kostenreduzierung gibt, wie die Nutzung von Spot-Instanzen, erfordern diese oft erheblichen Engineering-Aufwand und sind für lang laufende Jobs möglicherweise nicht praktikabel. Zudem sind Spot-Instanzen in Regionen mit GPU-Ressourcen nicht immer verfügbar.

Durch die Nutzung von reservierter Kapazität und Auto-Scaling können Sie Kosten effektiv verwalten und gleichzeitig die benötigten Ressourcen für Ihre Machine-Learning-Projekte bereitstellen. Diese Strategien sind auch heute noch relevant und lassen sich auf jeden Public Cloud Provider anwenden.

Automatisierter Flow für das Verschieben von Modellen

Der Promotion-Flow von Salesforce für das Verschieben von Modellen von einer Umgebung in eine andere basierte auf dem Konzept von Golden Datasets für jede Domain. Data Scientists konnten die Leistung des Modells auf diesen Datasets sowie auf zufällig ausgewählten Datasets evaluieren, um zu beurteilen, wie gut das Modell auf unterschiedlichen Datentypen funktioniert. Das half bei der Entscheidung, ob ein Modell in höhere Umgebungen überführt werden sollte oder nicht.

Der Promotion-Prozess wurde über die Workbench durchgeführt, war jedoch bewusst leicht manuell gehalten, um sicherzustellen, dass das Modell über einen bestimmten Schwellenwert hinaus auf n+1 Typen von Datasets funktionierte. Dies war eine Herausforderung, da Salesforce ein mandantenfähiges System ist und jeder Kunde ein anderes Dataset besitzt – oft in Hunderttausenden von Variationen. Salesforce erstellte Hunderttausende von Modellen, jeweils spezifisch für einen Kunden und ein Dataset, und automatisierte den Prozess so weit wie möglich.

Insgesamt war der Promotion-Flow bei Salesforce so konzipiert, dass Modelle gründlich evaluiert wurden und auf vielfältigen Datasets gut funktionierten, bevor sie in höhere Umgebungen übernommen wurden.

Aufbau eines mandantenfähigen Echtzeit-Vorhersagedienstes für komplexe Modelle

Der Aufbau eines mandantenfähigen Echtzeit-Vorhersagedienstes ist eine komplexe Aufgabe. Sie umfasst die Bereitstellung einer großen Anzahl von Modellen unterschiedlicher Größe und Architektur in Echtzeit bei gleichzeitiger Einhaltung spezifischer SLA-Anforderungen. Um dieser Herausforderung zu begegnen, entwickelte das Engineering-Team bei Salesforce eine Serving-Schicht, die mehrere Iterationen durchlief.

Anfangs verließ sich das Team auf eine strukturierte Datenbank für Metadaten und einen Dateispeicher für Modell-Artefakte. Dieser Ansatz war jedoch für größere und komplexere Modelle nicht skalierbar. Um das zu lösen, shardeten sie ihre Cluster basierend auf der Komplexität des Modells und der benötigten Compute-Art. Beispielsweise liefen kleinere Modelle auf CPUs, während größere Modelle GPUs benötigten. Cluster wurden für bestimmte Modelltypen dediziert, darunter NLP-Modelle, LSTM-Modelle, Transformer-Modelle, Bildklassifizierungsmodelle, Objekterkennungsmodelle und OCR-Modelle.

Das Team entwickelte auch eine Schicht, die das Deployment von Services auf verschiedenen Clustern und Node-Gruppen orchestrierte. Sie implementierten Caching, um für häufig angefragte Modelle niedrigere Latenzen zu gewährleisten. Zu Beginn durften Data und Research Scientists ihre bevorzugten Frameworks nutzen, was eine einheitliche Bereitstellung der Modelle erschwerte. Das Team reduzierte die Frameworks auf ein bis zwei und optimierte die Modelle für diese Frameworks.

Schließlich konvertierte das Team die Modelle in ein einheitliches Format, unabhängig vom ursprünglichen Trainings-Framework. Dadurch konnte der Serving-Code für jeden Modelltyp optimiert werden. Insgesamt führten die Bemühungen des Teams zu einem skalierbaren, effizienten und zuverlässigen Echtzeit-Vorhersagedienst.

Die Echtzeit-Inferenz war mein Lieblingsprojekt. Am Ende konnten wir dazu sogar ein Patent anmelden. Es war also ein großartiges Engineering-Feature, das wir der Plattform hinzugefügt haben. Tatsächlich war es die am meisten genutzte Funktion. Wir haben zweistellige Millionenbeträge an Vorhersagen pro Tag verarbeitet, und es war sehr befriedigend zu sehen, dass es von so vielen Kunden genutzt wurde.
- Arpeet

Wir haben diesen interessanten Blogbeitrag über ML Lakes und die Architektur der Data Platform von Salesforce gefunden:

‍

ML Lake: Der Aufbau der Data Platform für Machine Learning bei Salesforce – Salesforce Engineering Blog

Entdecken Sie einige der einzigartigen Herausforderungen von Salesforce im Bereich Datenmanagement und erfahren Sie, wie ML Lake diese löst.

Salesforce Engineering Blog Eli Levine, Laura Lindeman

Optimierung von Modellen für Enterprise AI

Sie führten umfangreiche Benchmarks für Modelle durch und zielten darauf ab, sich im Rahmen weitgehend unterstützter Operatoren und Operationen innerhalb eines Frameworks zu bewegen, um eine einfache Konvertierung zu gewährleisten. Benutzerdefinierte Operatoren verursachten einen hohen Konvertierungsaufwand und erforderten eine manuelle Betreuung. Das Team stellte jedoch fest, dass 95 % der Anwendungsfälle problemlos durch Standardmodelle gelöst werden konnten, die keine neuartigen Techniken benötigten. Dadurch konnten sie die Mehrheit der Anwendungsfälle optimieren und Zeit für die verbleibenden 5 % der Modelle aufwenden, die weniger verbreitet waren.

Arpeet merkte auch an, dass Frameworks wie Onyx, Triton und der Inference Server von NVIDIA erhebliche Fortschritte bei der Standardisierung von Modellformaten und Benchmarking gemacht haben, was sie zu wertvollen Werkzeugen für große Echtzeit-Inferenz-Anwendungsfälle macht.

Sicherheits- und Zuverlässigkeitsmaßnahmen in der Salesforce AI Platform

1. Approval Workflows: Vor dem Deployment des Modells in der Produktion gab es Freigabeworkflows rund um das Dataset, um den Datenschutz zu gewährleisten.
2. Sicherheitsisolierung: Die Produktionsumgebung war vollständig isoliert und verfügte über Zertifizierungen wie HIPAA- und ISO-Compliance.
3. Mandantenfähigkeit (Multi-tenancy): Authentifizierung deckte alle Mandanten ab, um sicherzustellen, dass nur ein bestimmter Kunde auf seine eigenen Daten zugreifen konnte.
4. Redundanz und Ausfallsicherheit: In die Plattform wurden ausreichende Redundanz- und High-Availability-Maßnahmen eingebaut, um Zuverlässigkeit zu garantieren.

ML Infrastructure Platform vs. Software Deployment Platform

Machine Learning Infrastructure Platforms und Software Deployment Platforms haben laut der Diskussion zwischen Anuraag und Arpeet viel gemeinsam. Hier sind die wichtigsten Erkenntnisse:

1. Gemeinsamkeiten: Beide benötigen einen Data Layer, Compute Layer, Orchestration Layer, Auth Service, API Gateway und Backend Service. Der Backend Service kann in einer Standardinfrastruktur Analytics- oder Data-Engineering-Workloads ausführen, während er in einer ML-Infrastruktur einen ML-Workload ausführt.
2. Unterschiede: Die ML-Infrastruktur kann ein Data Lake oder ein ML Lake für einen ML-Workload aufweisen, was in einer Standardinfrastruktur möglicherweise nicht erforderlich ist. Die ML-Infrastruktur kann zudem spezialisierte Orchestrierungssysteme nutzen.
3. Tooling: Das Tooling in beiden Infrastrukturplattformen unterscheidet sich. Eine ML-Infrastruktur erfordert möglicherweise spezialisierte Tools für die Orchestrierung, während eine Standardinfrastruktur einfachere Tools verwendet. Das Deployment-Tool für beide Infrastrukturplattformen ist jedoch in den meisten Fällen dasselbe, insbesondere beim Deployment auf einem Kubernetes-Cluster.

Insgesamt gibt es keinen wesentlichen Unterschied zwischen Machine Learning Infrastructure Platforms und Software Deployment Platforms, abgesehen von der Natur des Workloads und dem für die Orchestrierung erforderlichen Tooling.

Zusätzliche Gedanken von Arpeet

MLOps: Selbst bauen vs. Kaufen (Build vs. Buy)

1. Nutzen Sie verfügbare Alternativen, die viele Funktionen out-of-the-box bieten, wenn Sie eine ML-Infrastruktur für mittelständische Unternehmen und Startups aufbauen.
2. Für Startups in der Frühphase empfiehlt es sich, einfache Python-Skripte zu nutzen, auf einer Maschine mit mehreren GPUs zu trainieren und eine Form der Orchestrierung zu implementieren, um Kosten zu sparen.
3. Für etablierte ML-Workflows in kleinen bis mittelständischen Unternehmen sollten Sie Open-Source-Tools direkt nutzen oder den Einsatz einer schlüsselfertigen Lösung wie TrueFoundry in Betracht ziehen.
Ratschläge für ML-Ingenieure

Ich denke, ich würde sagen, dass die Spezialisierung auf eine Nische zum jetzigen Zeitpunkt – etwa die Operationalisierung eines groß angelegten AI-Workflows – wahrscheinlich die nächste Welle schwieriger Herausforderungen sein wird.
- Arpeet

Lesen Sie unsere bisherigen Blogs in der TrueML-Serie

‍

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

In diesem Blog tauchen wir tief in die ML Platform FBLearner Flow von Facebook ein. Verstehen Sie, wie sie sowohl Software- als auch ML-Deployment gelöst hat, und lernen Sie ihre Architektur kennen. TrueFoundry im Gespräch über die ML-Plattform bei Meta.

TrueFoundry Blog TrueFoundry

‍

Schauen Sie weiterhin die TrueML YouTube-Serie und lesen Sie alle Beiträge der TrueML Blog-Serie.

TrueFoundry ist ein ML Deployment PaaS auf Kubernetes, um Entwickler-Workflows zu beschleunigen und ihnen gleichzeitig volle Flexibilität beim Testen und Bereitstellen von Modellen zu bieten – bei vollständiger Sicherheit und Kontrolle für das Infra-Team. Über unsere Plattform ermöglichen wir Machine-Learning-Teams, Modelle in 15 Minuten mit 100 % Zuverlässigkeit, Skalierbarkeit und der Möglichkeit zu Rollbacks in Sekundenschnelle zu deployen und zu überwachen. So können Kosten gespart, Modelle schneller in Produktion gebracht und echter Geschäftswert realisiert werden.