True ML Talks #4 - Plattform für maschinelles Lernen bei Salesforce

Wir sind zurück mit einer weiteren Folge von True ML Talks. Darin tauchen wir tief ein Salesforce- ML Platform, und wir sprechen mit Arpeet Kale.

Arpeet war Teil des Engineering-Teams von Salesforce, das die gesamte ML-Plattform entwickelte. Er ist einer der Gründer von Fonds für Bauherren, wo er und seine Kollegen ML/KI-Unternehmen auf der ganzen Welt investieren und beraten. Und gleichzeitig ist er Leiter der Infrastruktur bei Skiff.

📌

In unseren Gesprächen mit Arpeet werden wir die folgenden Aspekte behandeln:
- ML-Anwendungsfälle in Salesforce
- Salesforce ML-Teamstruktur
- Überblick über die Salesforce ML-Infrastruktur
- Prototyping von ML-Modellen bei Salesforce
- Verwaltung der Kosten für umfangreiche ML-Projekte in der Cloud
- Automatisierter Ablauf für bewegte Modelle
- Aufbau eines mehrinstanzenfähigen Echtzeit-Prognosedienstes
- Optimierung von Modellen für Unternehmens-KI
- Sicherheits- und Zuverlässigkeitsmaßnahmen in der Salesforce AI Platform
- ML-Infrastrukturplattform im Vergleich zu Softwarebereitstellungsplattform

Sehen Sie sich die ganze Folge unten an:

Warum ist ML wichtig für Salesforce

1. Personalisierte Kundenerlebnisse → ML ermöglicht es Salesforce, personalisierte Kundenerlebnisse zu bieten, da es ihnen ermöglicht, Kundendaten zu analysieren und Erkenntnisse zur Verbesserung der Kundeninteraktionen zu generieren.
2. Automatisierung von Marketingkampagnen → Es hilft Salesforce-Kunden, ihre Marketingkampagnen zu automatisieren, indem es Bilder, Text und Social-Media-Daten analysiert, sodass sie sich auf ihre Kundenpersönlichkeiten konzentrieren und ihre Marketingstrategie optimieren können.
3. Chatbots für effizienten Kundensupport → Die von ML betriebenen Chatbots helfen Unternehmen dabei, den Kundensupport zu automatisieren, was zu kürzeren Wartezeiten und niedrigeren Kosten für das Unternehmen führt.
4. Identifizierung und Minderung von Sicherheitsrisiken → ML unterstützt Salesforce bei der Identifizierung und Minderung potenzieller Sicherheitsrisiken, indem Daten analysiert und Anomalien erkannt werden.
5. Kontinuierliche Verbesserung von Produkten und Dienstleistungen → Durch die Nutzung von ML kann Salesforce seine Produkte und Dienstleistungen kontinuierlich verbessern, indem Kundenfeedback analysiert und diese Informationen zur Entwicklung neuer Funktionen und Verbesserungen verwendet werden.

Salesforce ML-Teamstruktur

Bei Salesforce war das ML-Team in drei Teams aufgeteilt:

1. Forschungsteam: Das Forschungsteam bestand aus Hunderten von Forschern, die sich auf neuartige Forschungsprobleme konzentrierten und Forschungsarbeiten veröffentlichten
2. Team für angewandte Wissenschaft: Das Team für angewandte Wissenschaft war für das reine Produkt, die Anwendungsfälle der Datenwissenschaft, verantwortlich
3. Ingenieurteam: Das Ingenieurteam war für den Aufbau der ML-Plattforminfrastruktur verantwortlich, die die Teams für Forschung und angewandte Wissenschaft unterstützen konnte.

Wir haben diesen interessanten Blog darüber gefunden, wie ML von Salesforce verwendet wird:

‍

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

‍

Überblick über die Salesforce ML-Infrastruktur

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

1. Die Infrastruktur lief auf AWS, und Kubernetes wurde verwendet, um die gesamte Datenverarbeitung zu verwalten. Die Verwendung von Kubernetes ermöglichte die einfache Bereitstellung aller Arten von Frameworks für maschinelles Lernen, egal ob TensorFlow oder Pytorch.
2. Es gab eine Clustertrennung zwischen dem Forschungsteam, dem Team für angewandte Wissenschaft und dem Ingenieurteam. Dies ermöglichte eine bessere Verwaltung der Rechenkapazität und der Ressourcen.
3. Die Plattform basiert auf einem Orchestrator für Schulungen, einem Echtzeit-Prognosedienst, einem Batch-Prognosedienst und einer Frontend-API zur Verwaltung von Benutzervorgängen wie Authentifizierung und Autorisierung.
4. Die Infrastruktur bestand aus einer strukturierten SQL-Datenbank und einem unstrukturierten Dateispeicher wie S3, die für die Verwaltung von Daten verwendet wurden. Die Plattform war für die Verwaltung der Daten zwischen den beiden verantwortlich.
5. Je nach Anwendungsfall gab es eine Mischung aus GPU-Clustern. Dies ermöglichte eine effiziente Nutzung der Ressourcen und eine bessere Leistung.

📌

Die Hauptgründe, warum es wichtig ist, Cluster in der Infrastruktur für maschinelles Lernen zu trennen, sind:

1. Sicherheit: Die Trennung von Clustern reduziert das Risiko von Datenschutzverletzungen und unbefugtem Zugriff auf sensible Daten. Jedes Team kann in seiner eigenen Umgebung mit den erforderlichen Sicherheitsmaßnahmen arbeiten.
2. Datenkonformität: Verschiedene Teams haben möglicherweise unterschiedliche Anforderungen an die Datenkonformität, die durch die Trennung von Clustern erfüllt werden können. Dadurch wird sichergestellt, dass jedes Team mit Daten arbeitet, die die erforderlichen regulatorischen Anforderungen erfüllen.
3. Ressourcenmanagement: Durch die Trennung von Clustern verfügen Teams über die Ressourcen, die sie zur Erledigung ihrer Aufgaben benötigen, ohne die Ressourcen anderer Teams zu beeinträchtigen. Dies gewährleistet eine effiziente Nutzung von Ressourcen und verhindert Ressourcenkonflikte.

Prototyping bei Salesforce: Ein eigenwilliger Ansatz

Bei Salesforce wurde das Prototyping-Framework auf Jupyter Notebooks aufgebaut, sodass Datenwissenschaftler kurzfristige Experimente interaktiv und in Echtzeit durchführen können. Die Experimente wurden dann auf einen Job mit langer Laufzeit auf einem großen Cluster umgestellt, bei dem während der Ausführung des Jobs Echtzeit-Metriken generiert wurden.

Das Schulungs- und Experimentier-SDK wurde entwickelt, um die Komplexität der Planung von Aufträgen, des Abrufs und der Übertragung von Daten sowie der Systemabhängigkeiten zu abstrahieren. Datenwissenschaftler könnten eine Python-API oder -Funktion aufrufen, um diese Aufgaben zu erledigen, und den Fortschritt der Experimente, Metriken, Protokolle und mehr im Workbench-Dashboard verfolgen.

Das Framework war eigensinnig und bot eine abstrakte Lösung, ermöglichte aber dennoch eine gewisse Flexibilität bei der Wahl der Plattform durch Datenwissenschaftler. Es handelte sich jedoch nicht um ein völlig freies Experiment, und es gab interne Richtlinien und Standards, die befolgt werden mussten.

📌

Herausforderungen beim Hosting von Jupyter-Notebooks in großem Maßstab mit sensiblen Daten:
Wenn Jupyter Notebooks in großem Umfang mit sensiblen Daten gehostet werden, bestehen die größten Herausforderungen in den Genehmigungsworkflows für die Authentifizierung. Datenwissenschaftler müssen die Genehmigung einer bestimmten Person oder eines Managers einholen, um auf die Daten zugreifen zu können. Die Notebook-Umgebung ist kurzlebig und wird nach Abschluss der Experimente zerstört, aber alle generierten Artefakte bleiben erhalten. Die Authentifizierung ist API-gesteuert und in interne Systeme integriert.

So verwalten Sie die Kosten für groß angelegte Machine-Learning-Projekte in der Cloud

Große Machine-Learning-Projekte können schnell kostspielig werden, insbesondere wenn GPU-Ressourcen in der Cloud genutzt werden. Um die Kosten während der Prototyping-Phase im Griff zu behalten, gibt es einige Strategien, die angewendet werden können.

1. Reservierte Kapazität: Wenn Sie wissen, wie viel Kapazität Sie benötigen, können Sie diese im Voraus reservieren und erhalten einen Preisnachlass. Das funktioniert gut, wenn Sie eine gute Vorstellung davon haben, wie hoch Ihr Ressourcenbedarf auf lange Sicht sein wird.
2. Automatische Skalierung: Wenn Sie sich nicht sicher sind, wie viel Kapazität Sie benötigen, oder wenn Ihr Ressourcenbedarf schwankt, kann Auto-Scaling helfen. Indem Sie Ressourcen je nach Bedarf automatisch nach oben oder unten skalieren, können Sie vermeiden, für ungenutzte Kapazität zu bezahlen.

Zwar gibt es auch andere Strategien zur Kostensenkung, wie z. B. die Verwendung von Spot-Instances, doch diese erfordern oft einen hohen technischen Aufwand und sind für Jobs mit langer Laufzeit möglicherweise nicht praktikabel. Außerdem sind Spot-Instances in Regionen mit GPU-Ressourcen möglicherweise nicht immer verfügbar.

Durch die Nutzung reservierter Kapazitäten und die automatische Skalierung können Sie Ihre Kosten effektiv verwalten und verfügen gleichzeitig über die Ressourcen, die Sie für Ihre Machine-Learning-Projekte benötigen. Diese Strategien sind auch heute noch relevant und können auf jeden Public-Cloud-Anbieter angewendet werden.

Automatisierter Ablauf für bewegte Modelle

Der Werbeablauf von Salesforce für die Übertragung von Modellen von einer Umgebung in eine andere beruhte auf dem Konzept goldener Datensätze für jede Domain. Die Datenwissenschaftler konnten die Leistung des Modells anhand dieser Datensätze und auch anhand randomisierter Datensätze bewerten, um zu beurteilen, ob das Modell in der Lage ist, bei verschiedenen Datentypen eine gute Leistung zu erzielen. Dies half ihnen bei der Entscheidung, ob sie ein Modell in höheren Umgebungen bewerben sollten oder nicht.

Der Promotion-Prozess wurde über die Workbench durchgeführt, aber bewusst leicht manuell gehalten, um sicherzustellen, dass das Modell bei n+1 Datensatztypen über einen bestimmten Schwellenwert hinaus abschneidet. Dies war eine Herausforderung, da Salesforce ein System mit mehreren Mandanten ist und jeder Kunde über einen anderen Datensatz verfügt, der manchmal zu Hunderttausenden zählt. Salesforce erstellte Hunderttausende von Modellen, jedes für einen Kunden und einen Datensatz spezifisch, und automatisierte den Prozess so weit wie möglich.

Insgesamt wurde der Beförderungsablauf bei Salesforce so konzipiert, dass sichergestellt wurde, dass die Modelle gründlich evaluiert wurden und bei unterschiedlichen Datensätzen gute Ergebnisse erzielten, bevor sie in höhere Umgebungen befördert wurden.

Aufbau eines mehrinstanzenfähigen Echtzeit-Prognosedienstes für komplexe Modelle

Der Aufbau eines mehrinstanzenfähigen Echtzeit-Prognosedienstes ist eine komplexe Aufgabe, bei der eine große Anzahl von Modellen mit unterschiedlichen Größen und Architekturen in Echtzeit bereitgestellt und gleichzeitig bestimmte SLA-Anforderungen erfüllt werden müssen. Um dieser Herausforderung zu begegnen, entwickelte das Engineering-Team von Salesforce eine Serving-Ebene, die mehreren Iterationen unterzogen wurde.

Anfänglich stützte sich das Team auf eine strukturierte Datenbank für Metadaten und einen Dateispeicher für Modellartefakte. Dieser Ansatz war jedoch nicht für größere und komplexere Modelle skalierbar. Um dieses Problem zu lösen, teilten sie ihre Cluster auf der Grundlage der Komplexität des Modells und der Art der erforderlichen Berechnungen auf. Kleinere Modelle liefen beispielsweise auf CPUs, während größere Modelle GPUs benötigten. Cluster waren bestimmten Modelltypen wie NLP-Modellen, LSTM-Modellen, Transformatormodellen, Bildklassifizierungsmodellen, Objekterkennungsmodellen und OCR-Modellen gewidmet.

Das Team entwickelte auch eine Ebene, die die Bereitstellung von Diensten auf verschiedenen Clustern und Knotengruppen orchestrierte. Sie implementierten Caching, um sicherzustellen, dass häufig angeforderte Modelle geringere Latenzen aufwiesen. Anfänglich durften Daten- und Forschungswissenschaftler ihr bevorzugtes Framework verwenden, was es schwierig machte, die Modelle einheitlich bereitzustellen. Das Team grenzte die Frameworks auf ein oder zwei ein und optimierte die Modelle für diese Frameworks.

Schließlich konvertierte das Team die Modelle unabhängig vom ursprünglichen Trainingsframework in ein einheitliches Format, sodass sie den Bereitstellungscode für jeden Modelltyp optimieren konnten. Insgesamt führten die Bemühungen des Teams zu einem skalierbaren, effizienten und zuverlässigen Prognosedienst in Echtzeit.

An der Echtzeit-Inferenz habe ich am liebsten gearbeitet. Und ich denke, am Ende waren wir auch in der Lage, ein Patent darauf anzumelden. Es war also ein großartiges technisches Feature, das wir der Plattform hinzugefügt haben. Es war tatsächlich das am häufigsten verwendete Feature. Wir haben zweistellige, Millionen von Prognosen pro Tag gemacht, und es war sehr, sehr befriedigend zu sehen, wie das von so vielen Kunden genutzt wurde.
- Teppich

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

‍

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

Optimierung von Modellen für Unternehmens-KI

Sie verglichen die Modelle intensiv und zielten darauf ab, innerhalb der Grenzen der breit unterstützten Betreiber und anderer Betriebsabläufe zu bleiben, und zwar innerhalb eines Rahmens, der eine einfache Umstellung gewährleistet. Bei kundenspezifischen Bedienern war die Konvertierung sehr reibungslos und erforderte ein hohes Maß an Fingerspitzengefühl. Das Team stellte jedoch fest, dass 95% der Anwendungsfälle leicht mit Standardmodellen gelöst werden konnten, für die keine neuen Techniken erforderlich waren. Dies ermöglichte es ihnen, für die meisten Anwendungsfälle zu optimieren und Zeit mit den verbleibenden 5% der Modelle zu verbringen, die nicht so häufig verwendet wurden.

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

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

1. Zulassung Arbeitsabläufe: Vor der Bereitstellung des Modells in der Produktion gab es Genehmigungsworkflows rund um den Datensatz, um den Datenschutz zu gewährleisten.
2. Sicherheitsisolierung: Die Produktionsumgebung war vollständig isoliert und verfügte über Zertifizierungen wie HIPAA- und ISO-Konformität.
3. Mehrmandantenfähigkeit: Auth deckte alle Mieter ab, um sicherzustellen, dass nur ein bestimmter Kunde auf seine eigenen Daten zugreifen konnte.
4. Redundanz und Hochverfügbarkeit: Ausreichende Redundanz- und Hochverfügbarkeitsmaßnahmen wurden in die Plattform eingebaut, um die Zuverlässigkeit zu gewährleisten.

ML-Infrastrukturplattform im Vergleich zu Softwarebereitstellungsplattform

Laut der Diskussion zwischen Anuraag und Arpeet haben Infrastrukturplattformen für maschinelles Lernen und Plattformen für die Softwarebereitstellung viele Gemeinsamkeiten. Hier sind die wichtigsten Erkenntnisse:

1. Gemeinsamkeiten: Beide benötigen eine Datenschicht, eine Rechenschicht, eine Orchestrierungsschicht, einen Authentifizierungsdienst und ein API-Gateway sowie einen Backend-Service. Der Backend-Service kann Analyse- oder Datentechnik-Workloads in einer Standardinfrastruktur ausführen, während er in der ML-Infrastruktur einen ML-Workload ausführt.
2. Unterschiede: Die ML-Infrastruktur kann über einen Data Lake oder einen ML Lake für einen ML-Workload verfügen, während dies bei der Standardinfrastruktur möglicherweise nicht erforderlich ist. Die ML-Infrastruktur kann auch spezielle Orchestrierungssysteme verwenden.
3. Werkzeugbau: Die Tools in beiden Infrastrukturplattformen sind unterschiedlich. Für die ML-Infrastruktur sind möglicherweise spezielle Tools für die Orchestrierung erforderlich, während für die Standardinfrastruktur möglicherweise einfachere Tools verwendet werden. Das Bereitstellungstool für beide Infrastrukturplattformen ist jedoch in den meisten Fällen dasselbe, insbesondere bei der Bereitstellung auf einem Kubernetes-Cluster.

Insgesamt gibt es keinen signifikanten Unterschied zwischen Infrastrukturplattformen für maschinelles Lernen und Plattformen für die Softwarebereitstellung, mit Ausnahme der Art der Arbeitslast und der für die Orchestrierung erforderlichen Tools.

Weitere Gedanken von Arpeet

MLOps: Bauen gegen Kaufen

1. Verwenden Sie verfügbare Alternativen, die viele sofort einsatzbereite Funktionen bieten, wenn Sie eine ML-Infrastruktur für mittelständische Unternehmen und Startups aufbauen.
2. Verwenden Sie für Startups in der Frühphase einfache Python-Skripte, trainieren Sie auf einem Computer mit mehreren GPUs und implementieren Sie eine Form der Orchestrierung, um Kosten zu sparen.
3. Verwenden Sie für etablierte ML-Workflows in kleinen und mittleren Unternehmen direkt Open-Source-Tools, ziehen Sie jedoch in Betracht, eine sofort einsatzbereite Lösung wie TrueFoundry zu verwenden.

Beratung für ML-Ingenieure

Ich denke, ich würde sagen, dass die Konzentration auf eine Nische, also entweder die Operationalisierung eines groß angelegten KI-Workflows, wahrscheinlich die nächste schwierige Herausforderung sein wird.
- Teppich

Lesen Sie unsere vorherigen Blogs in der 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

‍

Schaue weiter TrueML YouTube-Serie und lese das ganze TrueML Blog-Serie.

Wahre Gießerei ist ein ML Deployment PaaS über Kubernetes, um die Workflows von Entwicklern zu beschleunigen und ihnen gleichzeitig volle Flexibilität beim Testen und Bereitstellen von Modellen zu bieten und gleichzeitig die volle Sicherheit und Kontrolle für das Infra-Team zu gewährleisten. Über unsere Plattform ermöglichen wir Teams für maschinelles Lernen bereitstellen und überwachen Modelle innerhalb von 15 Minuten mit 100% iger Zuverlässigkeit, Skalierbarkeit und der Möglichkeit, innerhalb von Sekunden rückgängig zu machen. So können sie Kosten sparen und Modelle schneller für die Produktion freigeben, wodurch ein echter Geschäftswert erzielt wird.