Die Zeit hat mein ML-Model getötet!

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 alle haben die Statistik gehört, dass 90%, 88%, 87%, 85% oder ein verrückter Prozentsatz der ML-Modelle schafft es nie in die Produktion. Um ganz ehrlich zu sein, habe ich keine Ahnung, wie das jemand berechnet hat und ich bin genauso verwirrt wie diese Person. Aber das ist nebensächlich. Im Idealfall ist diese Zahl viel weniger wichtig als warum viele Unternehmen haben Schwierigkeiten, aus maschinellem Lernen einen Geschäftswert zu ziehen- noch!
Um dies zu verstehen, hatten wir einstündige Gespräche mit über 200 Personen in einer 1:1 -Umgebung, um den Arbeitsablauf beim Erstellen von ML-Modellen zu verstehen, einschließlich der Entwicklung von Geschäftsanforderungen, Übersetzung in Sprints, Datenerfassung, Modellbildung, Produktionsreife, Bereitstellung, Umschulung, A/B-Tests, Debugging, Überwachung, Beobachtbarkeit usw. und schließen Sie die Schleife von einem Schritt zurück zu einem beliebigen Schritt in dieser Sequenz. Dazu gehören vielfältige Perspektiven von Geschäftsführern, technischen Führungskräften, Produktmanagern, Datenwissenschaftlern, Devops, Dateningenieuren und ML-Ingenieuren! Nach diesen qualitativen Gesprächen haben wir auch eine objektive Umfrage durchgeführt, um einen umfassenderen Überblick über die vorherrschenden Probleme zu erhalten, deren Ergebnisse hier eingesehen werden können hier.
Obwohl angewandtes maschinelles Lernen ein relativ neues Gebiet ist und Probleme in praktisch jedem einzelnen Teil der Pipeline bestehen, gab es ein durchschlagendes und herausragendes Thema, das sich aus unseren Gesprächen herauskristallisierte:
Die Zeitverzögerung zwischen jedem Schritt der Entwicklung und Markteinführung von ML-Modellen verringert das Selbstvertrauen und die Moral von Ingenieur- und Führungsteams, die ML-Modelle töten!
In der Welt der Software sind wir es gewohnt, datengestützte Entscheidungen zu treffen. Wir wollen schnell Ergebnisse sehen, A/B-Tests durchführen, die Kosten rechtfertigen und, wenn ein Projekt keinen ausreichenden ROI erzielt, angemessen Zeit- uns wird beigebracht, ihm in den Kopf zu schießen. Und Zeit ist eine Sache, die ML sehr braucht! Dies gilt für Unternehmen des gesamten Spektrums, wenn auch aus unterschiedlichen Gründen-
- Startups in der Frühphase (Start bis Serie C)
- Traditionelle Giganten wie Walgreens, Target, Siemens
- Technologiegiganten wie Uber, Amazon, Netflix usw.
Lassen Sie uns das im Detail untersuchen.
Startups in der Frühphase
Oft erfordert der Aufbau und die Bereitstellung von Pipelines für maschinelles Lernen unterschiedliche Fähigkeiten.
- Den geschäftlichen Anwendungsfall verstehen — in der Regel Produktmanager
- Pipelines zur Datenprotokollierung und -verarbeitung — in der Regel Data Engineers
- Experimentieren und Erstellen von Modellen — typischerweise Data Scientists
- Erstellung und Bereitstellung von Inferenz-APIs — in der Regel ML Engineers
- Modellskalierung, Staging, Prod-Pipelines — typischerweise DevOps-Team
- A/B-Test-Frameworks, Überwachung und Beobachtbarkeit, Weiterbildungspipelines
Sehr häufig verfügen Startups nicht über die Ressourcen, um verschiedene Mitarbeiter einzustellen, um das gesamte Kompetenzspektrum abzudecken. Startups glauben naiv, dass sie 1—2 wirklich kluge Leute einstellen können, die das getan hätten war dort, habe das gemacht und können all die oben genannten Probleme lösen — aber sie erkennen nicht, dass solche Fabelwesen außerhalb der Träume des Gründers nicht wirklich existieren!
Am Ende versucht der Data Scientist oder ML Engineer, welcher auch immer eingestellt wurde, dem gängigen Sprichwort zu folgen: „In einem Startup tust du alles, um Dinge zu erledigen“. Aber die Lernkurve der Technologien in diesem Bereich (die sich rasant verändert) ist wirklich steil und endet dauert lange um jeden dieser verschiedenen Teile zu lernen und umzusetzen. Natürlich sind die von diesem Neuling gebauten Pipelines oft nicht narrensicher und brechen an verschiedenen Stellen, was eine Reihe von Patchwork-Projekten in Gang setzt — ein klassischer Grund für die Erschöpfung der technischen Ressourcen! An diesem Punkt nimmt der frustrierte Gründer eine harte Entscheidung entgegen-“Okay, wir sind noch nicht bereit für maschinelles Lernen. Lassen Sie uns ein einfaches, leicht zu wartendes, regelbasiertes System erstellen, das einfach funktioniert — zurück zu den Grundlagenwir!“
Traditionelle Giganten wie Walgreens & Target
In großen Unternehmen ist der Grund, warum ML-Modelle am Ende zu viel Zeit in Anspruch nehmen, ebenso organisatorischer (oder sogar noch mehr) wie technischer Natur. In der Regel beendet ein Geschäftsanwender — vielleicht aus einem Customer Success- oder Vertriebsteam — einen Kundenanruf und entwickelt eine Idee für ein Machine-Learning-Projekt. Dazu gehören Übersetzungen durch Produktmanager, Besprechungen zur Ressourcenzuweisung und zur Sprint-Planung, bevor es schließlich in die Hände eines Datenwissenschaftlers fällt. Nehmen wir an, diese Idee war eine der einfacheren, bei der das Unternehmen bereits über die Daten verfügte, die in das Modell eingespeist werden mussten (sagen wir, der Benutzer klickt auf einen Stream).
Der Datenwissenschaftler erstellt dann das Modell, hat aber keine Möglichkeit, schnelles Feedback vom Geschäftsanwender zu erhalten, weil-
- Das Notizbuch ist zu technisch für Geschäftsleute
- In Excel-Tabellen gespeicherte Ergebnisse sind nicht interaktiv
- Datenwissenschaftler verfügen in der Regel nicht über die Fähigkeiten, um das Modell schnell zu hosten und eine API bereitzustellen.
Woher weiß der DS ohne das Feedback des Geschäftsanwenders...
- Löst ihr Modell das Problem, nach dem der Geschäftsanwender gefragt hat, oder ist die Absicht bei der Übersetzung verloren gegangen?
- Fehlen ihnen einige wichtige Randbedingungen, die den Kunden wütend machen würden, wenn sie nicht eingehalten würden?
- Verwenden sie Datenquellen, die zu Verzerrungen im Modell führen oder einem Nutzersegment nachteilig schaden könnten?
Selbst wenn alle oben genannten Punkte zutreffen — wer weiß mit Sicherheit, ob die anfängliche Vermutung des Geschäftsanwenders richtig war? Das ultimative Feedback würde nur vom Endbenutzer kommen. Aber wie bekommt man das Modell in die Hand des Endbenutzers?
Ja, Sie haben es richtig erraten - Sie müssen das Engineering- und Produktteam einbeziehen. Es wird wieder Besprechungen zur Ressourcenzuweisung geben, es wird eine Sprint-Planung geben und schließlich wird das Modell in das Produkt integriert. Dies kann Monate dauern, und bis dahin könnte der Geschäftsanwender erkennen, dass sich die Priorität des Produkts geändert hat! Und dann kommt die schreckliche Aussage-“Es macht keinen Sinn, mehr Ressourcen in dieses Projekt zu investieren — lassen Sie uns nicht gutes Geld hinter schlechtes Geld setzen!“
Technologiegiganten wie Uber und Amazon
Es erübrigt sich zu erwähnen, dass diese Unternehmen ihrer Zeit am weitesten voraus sind und sich sehr häufig nicht die Zeit in der Größenordnung von Monaten nehmen, um ML Models zur Serienreife zu bringen. Aber selbst bei diesen Top-Unternehmen ist das keine Seltenheit. Und sie haben in diesem Zusammenhang ein ganz besonderes Problem.
Sehr häufig entwickeln große Technologiegiganten ihre eigene MLOps-Plattform, die alles erledigt, vom Aufbau von Feature-Stores über Algorithmusimplementierungen bis hin zum Abhängigkeitsmanagement, zur Bereitstellung, zur Modellinferenz und mehr. Der Aufbau solcher generischen Plattformen, die für alle Anwendungsfälle funktionieren, ist ein schwieriges technisches Problem, und diese Systeme gehen am Ende von Annahmen in der folgenden Form aus
- Dies sind die gängigsten Bibliotheken, von denen wir erwarten, dass Datenwissenschaftler sie verwenden
- Solange der Data Scientist „sofort einsatzbereite“ Algorithmen verwendet, funktioniert alles reibungslos, aber wenn er sein eigenes Modell entwickeln möchte, muss er X-, Y- und Z-Schritte ausführen.
Lassen Sie uns diese Annahmen untersuchen und klarstellen, dass diese Annahmen nicht praktikabel sind — ML-Algorithmen und Tools werden ständig verbessert, und für die aktuellen Probleme, an denen diese Unternehmen arbeiten, sind innovative Lösungen erforderlich. Das heißt, je mehr das Unternehmen versucht, ML-lastig zu sein, desto mehr wird es maßgeschneiderte Lösungen benötigen und desto größer ist der Bedarf an dedizierten technischen Ressourcen!
Aus genau diesem Grund geben sich Data-Science-Teams sehr häufig mit sofort einsatzbereiten Lösungen zufrieden, was mit enormen Opportunitätskosten verbunden ist. Wenn der Datenwissenschaftler oder das Unternehmen beschließen, den schwierigeren Weg zu gehen, d. h. ihre Plattform weiterzuentwickeln und die Entwicklung maßgeschneiderter fortschrittlicher Lösungen zu ermöglichen — raten Sie mal, Sie müssen einen Geschäftsszenario aufstellen, die richtigen Ressourcen beschaffen und mit Mitarbeitern aus vielen Organisationen sprechen. Ob das nun zu einer verbesserten Plattform führt oder nicht, es kommt auf jeden Fall zu Verzögerungen!
Und wenn nach vielen dieser Investitionen die Dinge nicht wie geplant funktionieren, wenn sie dem Benutzer zur Verfügung gestellt werden, gibt es eine Verstärkung, um den einfacheren Out-of-Box-Weg für das nächste Projekt einzuschlagen.
Fazit und nächste Schritte
Dieses Thema nimmt ML-Modelle auf“zu viel Zeit“ kam aus verschiedenen Gründen in all unseren Benutzergesprächen deutlich zum Vorschein.
- Ein Startup, das nicht über alle Humanressourcen und das gesamte Toolkit verfügt und nicht zu viel Zeit hat, um zu iterieren und die optimale Lösung zu finden — begnügen Sie sich mit regelbasierten Systemen, wenn Sie ML-Projekte verschrotten!
- Große traditionelle Unternehmen mit organisatorischen Herausforderungen verwerfen ML-Projekte, weil sie zu lange gedauert haben, bis sie realisiert wurden, und häufig keine vertretbaren Auswirkungen auf das Geschäft haben.
- Moderne Technologieunternehmen mit MLOps-Plattformen optimiert für die Produktion, aber nicht so sehr für Experimente mit offenem Ende. Am Ende gab man sich mit sofort einsatzbereiten Algorithmen und Bibliotheken zufrieden. Andernfalls wird es zu viel Zeit in Anspruch nehmen, das volle Potenzial des maschinellen Lernens auszuschöpfen.
Wir waren erstaunt, dieses gemeinsame Thema in einem so breiten Spektrum von Unternehmen zu sehen.
ML-Modelle nehmen zu viel Zeit in Anspruch und verzögern geschäftliche Auswirkungen und Feedback-Zyklen. Das ist einer der Hauptgründe, warum viele ML-Modelle nicht das Licht der Welt erblicken.
Wir sind der Meinung, dass eine Lösung, die eine nahtlose Kommunikation zwischen Geschäftsanwendern und Datenwissenschaftlern sowie ein schnelles Feedback der Verbraucher ermöglicht, um die Auswirkungen auf das Geschäft zu überprüfen, bevor viele organisatorische Ressourcen für ML-Lösungen aufgewendet werden, das Vertrauen und die Investitionen in maschinelles Lernen stärken — und diese Investitionen auch viel fruchtbarer machen werden.
Wir behaupten noch nicht, eine vollständige Lösung für das Problem zu haben, aber wir arbeiten daran. Wir sprechen mit klugen Leuten und finden heraus, wie wir dieses Problem lindern, wenn nicht sogar vollständig lösen können.
Wir sind der festen Überzeugung, dass ein so großes Problem unterschiedliche Sichtweisen erfordert. Wenn Sie sich mit diesem Problem identifizieren oder Gedanken haben, die Sie teilen möchten, Ideen zur Lösung des Problems haben oder unsere Ideen hören möchten, freuen wir uns über Ihre Kommentare oder kommen Sie mit uns ins Gespräch.
Ich bin persönlich erreichbar unter- nikunjbjj@gmail.com. Und hier ist das LinkedIn für mich und meine Mitbegründer-
Dieser Blog wurde zuerst auf Medium veröffentlicht unter https://medium.com/@nikunjbajaj/time-killed-my-ml-model-48521fad6c4 am 30. August 2021
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)



