True ML Talks #2 - Arbeitsablauf für maschinelles Lernen @ Stitch Fix

Auf Geschwindigkeit ausgelegt: ~ 10 ms Latenz, auch unter Last
Unglaublich schnelle Methode zum Erstellen, Verfolgen und Bereitstellen Ihrer Modelle!
- Verarbeitet mehr als 350 RPS auf nur 1 vCPU — kein Tuning erforderlich
- Produktionsbereit mit vollem Unternehmenssupport
Wir haben eine sehr ermutigende Resonanz auf unsere erste Folge von True ML Talks erhalten. In dieser Serie tauchen wir tief in die ML-Pipeline einiger führender ML-Unternehmen ein, und in der heutigen Folge sprechen wir mit Stefan Krawczyk.
Stefan baut DAGWorks, eine kollaborative Open-Source-Plattform für Data-Science-Teams zum Aufbau und zur Wartung von Modell-Pipelines, die sich in bestehende MLOps und Dateninfrastrukturen einfügt (lesen Sie ihre YC-Markteinführung). Er verfügt über mehr als 15 Jahre Erfahrung bei Unternehmen wie Nextdoor, LinkedIn und Stitch Fix im Bereich Daten und maschinelles Lernen. Zuvor leitete er das Model Lifecycle-Team bei Stitch Fix, wo er umfangreiche Erfahrung in der Entwicklung von Self-Service-Tools für eine interne MLOps-Plattform für maschinelles Lernen sammelte. Er ist auch ein regelmäßiger Konferenzredner und Autor des beliebten Open-Source-Frameworks Hamilton.
📌
Unsere Gespräche mit Stefan werden sich um vier Hauptthemen drehen:
1. Anwendungsfälle für maschinelles Lernen für Unternehmen.
2. Wie das Team von Stitch Fix strukturiert ist, um die Geschäftsergebnisse zu optimieren.
3. Herausforderungen beim Aufbau des ML-Stacks mit spezifischen Herausforderungen, die sich auf die Branche beziehen.
4. Ein Überblick über die neuesten Innovationen, die beim Aufbau und der Skalierung der ML-Infrastruktur zum Einsatz kamen.
Sehen Sie sich die ganze Folge unten an:
ML Usecases @Stitch Fix: Ein persönlicher Online-Styling-Service
- Empfehlungssystem → Modelle für Prognose und Simulation, die eine Aufschlüsselung der Größen- und Allokationsbereiche bieten.
- Prognose und Simulation → Wenn Käufer entscheiden, wie viele Kleidungsstücke sie kaufen möchten, müssen sie die Größe und die Anzahl der zu bedienenden Kleidungsstücke festlegen. Dabei handelt es sich um eine ganze Reihe von Dingen, die Menschen intern verwenden, um sie bei der Simulation oder Prognose zu unterstützen. Das Algorithmus-Team von Stitch Fix erstellt zu diesem Zweck Modelle, die eine Aufschlüsselung der Größen- und Zuordnungsbereiche bieten. Lesen Sie mehr darüber hier
- Internes System für Unternehmensressourcenplanung → Stitch Fix hat im Wesentlichen sein eigenes internes ERP-System mithilfe von Algorithmen aufgebaut. Dieses System hilft bei der Planung von Inventar, Lagerung und Optimierung der Versandtarife. Lesen Sie mehr darüber hier.
- Routenoptimierung durch das Lager → Stitch Fix hat ein Team, das die Routen durch das Lager optimiert und sicherstellt, dass der kürzeste Weg zur Kommissionierung der Bestellungen genommen wird. Diese Optimierung hilft dabei, die Kosten und die Bearbeitungszeit für Bestellungen zu minimieren.
- Lagerlogistik → Das Algorithmus-Team von Stitch Fix arbeitet auch daran, den Prozess der Kommissionierung von Kleidung aus Mülleimern zu optimieren, um Bestellungen zu erfüllen. Stitch Fix kann Kosten sparen und die Bearbeitungszeiten von Bestellungen minimieren, indem dieser Prozess beschleunigt wird.
ML-System-Arbeitsablauf bei Stitch Fix
Stitch Fix hat zwei Teams, die an ihren Systemen für maschinelles Lernen (ML) arbeiten — das Data Science- und das Plattformteam.
- Team für Datenwissenschaft: Das Data-Science-Team, das nach Branchen organisiert ist, um verschiedenen Teilen des Unternehmens zu helfen, hat die Aufgabe, Modelle zu erstellen, die anderen Teams im Unternehmen helfen, Entscheidungen zu treffen.
- Plattform-Team: Das Plattformteam erstellt Abstraktionen und Tools, sodass die Datenwissenschaftler nicht so viel entwickeln müssen, um ihre Arbeit zu erledigen. Das Team ist in mehrere Komponenten wie Spark, Hadoop, Kafka, Infrastruktur, Orchestrierungssystem und Umgebungen unterteilt. Es gibt auch ein Team, das für den Empfehlungsstapel und die Bereitstellung von Microservices sowie für A/B-Tests und Experimente verantwortlich ist. Das Team konzentriert sich auf Elemente der Operationalisierung, wie z. B. die Vereinfachung des Trainings, der Bereitstellung und der Wartung von Modellen.
👉
Das Data Science-Team ist dafür verantwortlich, die Modelle und die Ergebnisse zu besitzen. Das Plattformteam stellt die Verfügbarkeit der Bereitstellungsinfrastruktur und ihrer Komponenten sicher.
Es gab keine „Übergabe“ des Modells zwischen dem Data Science-Team und dem Platform-Team. Dies hilft dabei, viele weitere Iterationen mit dem Modell durchzuführen.
Bearbeitung der Infrastrukturzuweisung
Die Zuweisung der Infrastruktur erfolgt durch das Plattformteam, dem in der Regel die verfügbaren Kontingente gehörten. Datenwissenschaftler könnten Knoten oder andere Spark-Cluster auf einer Benutzeroberfläche anfordern. Ein Teil der Rechnungslegung wird durchgeführt, um sicherzustellen, dass die Kosten nicht ohne Begründung in die Höhe schnellen. Das Plattformteam versuchte, es den Leuten zu ermöglichen, auf einfache Weise das zu bekommen, was sie wollten, ohne zu viel Arbeit in Kauf nehmen zu müssen. Und es gab Teams, die für die Kontingente zuständig waren und dafür sorgten, dass die Kosten unter Kontrolle gehalten wurden.
Einzigartige Herausforderungen im Bereich maschinelles Lernen und MLOps bei Stitch Fix
- Bei Stitch Fix arbeiten über 100 Datenwissenschaftler an der Entwicklung von Modellen. Da jeder Datenwissenschaftler ein Modell mit einer durchschnittlichen Lebensdauer von mindestens zwei Jahren besitzt, gab es viele Teams, die viele Modelle entwickelten, und es war eine große Herausforderung, einem Team die Eigenverantwortung zu übertragen. Das Plattformteam von StitchFix hat viele Lösungen intern entwickelt und aufgrund der Heterogenität der verwendeten Bibliotheken und Frameworks nur wenige Dinge gekauft. Eine Standardisierung hätte einige Plattformen einfacher gemacht, aber verschiedene Teams hatten unterschiedliche Probleme und Bibliotheken waren für diese Probleme besser geeignet. Das Plattformteam von StitchFix musste seine eigenen Lösungen wie Model Envelope und Hamilton entwickeln, da es keine Open-Source-Lösungen gab, die ihren Bedürfnissen gut entsprachen.
- Es ist zwar einfach, Modelle zu erstellen, aber jemand muss alle ETLs verwalten, und wenn jemand das Unternehmen verlässt, kann dies zu Problemen führen. Code wegzuwerfen ist verschwenderisch, und neue Teammitglieder werden verlangsamt, bis sie herausfinden und verstehen können, was vor ihnen da war. Da Mitarbeiter häufig auf Modellen anderer Teams aufbauen, um sie als Funktionen zu verwenden, gibt es außerdem Interdependenzen zwischen ETLs, die berücksichtigt werden müssen.
„Ein Grund, warum ich so lange bei Stitch Fix geblieben bin, waren genau diese Herausforderungen und die Frage, wie man sie lösen kann.“ - Stefan
Innovationen in der Stitch Fix ML-Plattform
- Modell-Umschläge: Das Plattformteam von Stitch Fix entwickelte ein System, das es Datenwissenschaftlern ermöglichte, ihre Modelle mit anderen erforderlichen Komponenten zu verpacken und sie einfach zu versenden. Es handelt sich um ein API-basiertes System, das viele Dinge erfasst. Mit einer Taste und einer zusätzlichen Konfiguration können Datenwissenschaftler ihre Modelle in weniger als einer Stunde in der Produktion einsetzen. Das System ermöglichte auch Batch-Jobs und erleichterte die verteilte Ausführung von Modellen auf Spark.
- Konfigurationsgesteuerte ETLs: Das Plattformteam von Stitch Fix nutzte YAML und Jinja, um es Datenwissenschaftlern zu ermöglichen, den ETL-Prozess zu beschreiben, der SQL- und Python-Code für die Modellanpassung umfasste. Die Idee war, das Orchestrierungssystem zu abstrahieren und es dem Plattformteam zu ermöglichen, verschiedene Komponenten aus dem Docker-Container auszutauschen, was die Verwaltung und Wartung der Codebasis vereinfachte.
- Hamilton: Hamilton ist ein deklaratives Mikroframework zur Beschreibung von Datenflüssen. Das Plattformteam von Stitch Fix hat es entwickelt, um beim Feature-Engineering zu helfen, insbesondere für Zeitreihenprognosen, bei denen es einfach ist, Tausende von Features zu erfassen. Hamilton hilft bei der Strukturierung des Problems, ähnlich wie DBT für SQL, aber für Python-Transformationen. Es ermöglicht die Beschreibung des Datenflusses, ohne Python-Skripte verwalten zu müssen. Funktionen deklarieren einen Datenfluss, und die Definitionen können einfach gemeinsam genutzt und in Offline- und Online-Kontexten ausgeführt werden.
👉
Für den Austausch von Docker-Komponenten versuchte das Plattformteam, eine goldene API zu erstellen, in der Datenwissenschaftler beschreiben konnten, was passieren sollte, ohne sich Gedanken über Plattformabhängigkeiten machen zu müssen. Dies geschah mithilfe konfigurationsgesteuerter Modell-Pipelines, in denen Datenwissenschaftler Text mit Teilmengen der Änderungen bereitstellen konnten. Das Plattformteam konnte dann Dinge ändern, ohne dass das Datenwissenschaftlerteam seine Docker-Container aktualisieren oder aktualisieren musste. Das Plattformteam könnte auch Protokolle oder Metainformationen aktualisieren, ohne dass die Benutzer ihre Pipelines erneut bereitstellen oder neu schreiben müssen. Dadurch mussten die Teams Dinge nicht mehr verwalten und aktualisieren, und das Plattformteam konnte Dinge effizienter verwalten und aktualisieren, ohne dass eine Migration durch das Datenwissenschaftlerteam erforderlich war.
Verbesserung der Build- und Debugging-Zeit von Docker-Containern in der Remote-Entwicklung: Strategien, die bei Stitch Fix zum Einsatz kommen
- Caching zur Beschleunigung der Container-Erstellung - Das Plattformteam von Stitch Fix versuchte, die Erstellung von Docker-Containern zu beschleunigen, indem es Bibliotheken und Umgebungen zwischenspeicherte, die häufig verwendet wurden. Zum Beispiel fügten sie Caching hinzu, um sicherzustellen, dass dieselben Anforderungen nicht erneut installiert werden mussten, wenn dieselben Anforderungen erneut benötigt würden. Sie speicherten auch Umgebungsdateien, komprimierten sie und zogen sie dann zurück, um den Vorgang zu beschleunigen.
- Lokale Entwicklung zur Minimierung der Zeit für das Erstellen und Debuggen von Containern - Das Plattformteam von Stitch Fix ermutigte Entwickler, lokal zu entwickeln oder Wege zu finden, um nicht auf einen vollständigen Zyklus des Builds-, Run- und Debug-Zyklus des Docker-Containers zu warten. Sie ermöglichten die Ausführung lokaler Schleifen für einzelne Schritte des ETL, indem sie einige Daten herunterluden, um sie für Entwickler zwischenspeichern zu können, neben anderen Funktionen zur Benutzerfreundlichkeit. Dieser Ansatz trug dazu bei, den Entwicklungs- und Debugging-Prozess zu beschleunigen.
- Erforschung neuer Ansätze zur Verbesserung der Build- und Debug-Zeit von Containern - Das Plattformteam von Stitch Fix versuchte zwar, die Build- und Debugging-Zeit durch Caching und lokale Entwicklung zu verbessern, räumte jedoch ein, dass der Prozess schneller sein könnte. Einige Entwickler arbeiten an Änderungen an Docker, um diesen Prozess zu verbessern, insbesondere für Modelle. Bei diesem Ansatz wird Docker geändert und neu gestartet, um es besser und effizienter zu machen.
MLOpS-Werkzeugempfehlungen von Stefan Krawczyk
Es ist wichtig, Tools zu verwenden, die auf den geschäftlichen Auswirkungen und den SLAs basieren. Dinge, die mit einem einzelnen Knoten erledigt werden können, sollten mit einem Orchestrierungssystem optimiert werden. Für die Versionierung von Daten und Modellregistrierungen kann es funktionieren, Dinge in einer strukturierten Pfadstruktur in S3 zu speichern und dort Metadaten zu speichern. Wenn es um die Modellregistrierung geht, sollten Open-Source-Tools wie MLflow helfen, aber es gibt auch gehostete Verwaltungslösungen wie TrueFoundry.
Es ist wichtig, ein A/B-Testsystem im Stack zu haben, um den Wert zu verstehen, den ihr Modell für ihr Unternehmen hat. Dies hilft bei der Entscheidungsfindung darüber, wo in MLOp-Praktiken investiert werden soll, basierend auf den Auswirkungen, die ihr Modell hat.
Empfehlung für MLOPS-Tools
- Berücksichtigen Sie die Heterogenität von Bibliotheken und Frameworks: Wenn die verwendeten Bibliotheken und Frameworks eine erhebliche Heterogenität aufweisen, kann es erforderlich sein, interne Lösungen zu entwickeln, da es möglicherweise keine Standardlösungen gibt, die Ihren Anforderungen entsprechen.
- Standardisierung kann einige Plattformen einfacher machen: Während verschiedene Teams unterschiedliche Probleme haben können, kann die Standardisierung auf bestimmte Tools und Prozesse dazu führen, dass MLOps-Plattformen einfacher zu bauen und zu warten.
- Keine Open-Source-Lösungen, die Ihren Bedürfnissen entsprechen? Entwickeln Sie Ihre eigenen: Wenn es keine Open-Source-Lösungen gibt, die Ihren Anforderungen gut entsprechen, müssen Sie möglicherweise Ihre eigenen Lösungen wie Model Envelope und Hamilton entwickeln, um Ihre MLOps-Ziele zu erreichen.
Herausforderungen rund um ETL beim maschinellen Lernen
Beim maschinellen Lernen ist ETL (Extract, Transform, Load) ein entscheidender Prozess zur Umwandlung von Rohdaten in wertvolle Erkenntnisse. ETL in Systemen für maschinelles Lernen birgt jedoch mehrere Herausforderungen, die angegangen werden müssen.
ETLs in Systemen für maschinelles Lernen können aufgrund vorgelagerter Änderungen verstummen, was es den Datenpraktikern erschwert, Eingaben in das Modell zurückzuverfolgen, was zu Schwierigkeiten bei der Wartung von ETLs führt. Die Komplexität von ETLs nimmt mit der Zeit ebenfalls zu, was es für Teams schwierig macht, Schritt zu halten.
DAGWorks: Eine Open-Source-ETL-Plattform für Data-Science-Teams
Um die im vorherigen Abschnitt genannten Herausforderungen zu lösen, entwickelt DAGWorks eine Open-Source-ETL-Plattform für Data-Science-Teams, die ihre Abhängigkeit von der Technik reduziert. Die Open-Source-Plattform basiert auf Hamilton, wie oben erwähnt. Hamilton ermöglicht es Datenexperten ohne Hintergrund in der Softwareentwicklung, Code zu schreiben, der in die Produktion geht, und ETL-Artefakte für maschinelles Lernen in ihrer vorhandenen Infrastruktur zu verwalten. Hamilton bietet auch einen zentralen Feature-Definitionsspeicher und eine zentrale Abstammung, was das Debuggen erleichtert und für Compliance-Fälle verwendet werden kann.
Hamilton ist als Abstraktionsebene konzipiert, die mit verschiedenen Orchestrierungstools wie Airflow oder Argo verwendet werden kann. Stefan ist der Ansicht, dass Datenwissenschaftler sich nicht um die Topologie kümmern müssen, wo Dinge ablaufen, sondern sich stattdessen auf die Erstellung von Modellen und Iterationen konzentrieren sollten. DagWorks versucht, Wege und Abstraktionen zu finden, um es einfacher zu machen, den Datenqualitätsanbieter zu wechseln, ohne Dinge neu schreiben zu müssen.
Hamilton ergänzt zwar Tools wie Metaflow, versucht aber nicht, sie zu ersetzen. Stattdessen ermöglicht es den Mitarbeitern, auf diesen Systemen produktiver zu arbeiten, indem es ihnen ermöglicht, das Mikro innerhalb einer Aufgabe zu modellieren. Insgesamt versucht DAGWorks, Data-Science-Teams die Verwaltung und Wartung von ETL-Artefakten für maschinelles Lernen zu erleichtern.
Im Folgenden finden Sie einige interessante Lektüre von Stefan und seinem Team:
Was ich gelernt habe: Plattformen bauen bei Stitch Fix
Die Funktion, der Kontext und die Daten — Aktivierung von ML Ops bei Stitch Fix
Lesen Sie unseren vorherigen Beitrag in der Serie
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.
TrueFoundry AI Gateway bietet eine Latenz von ~3—4 ms, verarbeitet mehr als 350 RPS auf einer vCPU, skaliert problemlos horizontal und ist produktionsbereit, während LiteLM unter einer hohen Latenz leidet, mit moderaten RPS zu kämpfen hat, keine integrierte Skalierung hat und sich am besten für leichte Workloads oder Prototyp-Workloads eignet.
Der schnellste Weg, deine KI zu entwickeln, zu steuern und zu skalieren













.png)




.png)






.webp)

.webp)



