How are MLOps Frameworks Used in Open Source Projects? An Empirical Characterization
Diese Arbeit charakterisiert empirisch die Nutzung von acht populären Open-Source-MLOps-Frameworks durch die Analyse ihrer Adaption in GitHub-Projekten und korreliert tatsächliche API-Nutzungsmuster mit gemeinschaftlichen Funktionsanfragen, wobei sie aufzeigt, dass Entwickler diese Werkzeuge vorwiegend über APIs anpassen, statt sie direkt einsatzbereit zu nutzen, während sie gleichzeitig Verbesserungen bei der Kernfunktionalität, der API-Exposition und der CI/CD-Integration suchen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie sind ein Chefkoch, der versucht, ein riesiges, hochtechnologisches Restaurant zu führen. Sie haben ein brillantes Rezept (das Machine Learning Modell), aber es ist ein Albtraum, dieses Rezept von der Küche perfekt bis zum Tisch des Kunden zu bringen. Sie müssen die Zutaten verfolgen, die Garzeiten überwachen, sicherstellen, dass das Essen nicht verdirbt, und den Servierprozess automatisieren.
MLOps-Frameworks sind wie diese „intelligenten Küchensysteme“, die dabei helfen sollen, dieses Chaos zu bewältigen. Es sind Software-Tools, die versprechen, den gesamten Lebenszyklus Ihrer KI-Rezepte zu verwalten – vom Anmischen des Teigs bis zum Servieren des Gerichts.
Dieses Paper ist wie eine forensische Untersuchung darüber, wie 969 reale „Restaurants“ (Open-Source-Softwareprojekte) diese intelligenten Küchensysteme tatsächlich nutzen. Die Forscher haben acht der populärsten Systeme (wie MLFlow, Wandb und BentoML) untersucht, um drei große Fragen zu beantworten: Wie werden sie verwendet? Welche Teile werden tatsächlich genutzt? Und worüber beschweren sich die Leute oder was fordern sie ein?
Hier ist das, was sie herausgefunden haben, in einfachen Worten aufgeschlüsselt:
1. Der „Out-of-the-Box“-Mythos
Die Erwartung: Sie kaufen ein intelligentes Küchensystem, stecken es ein und drücken auf einen „Start“-Knopf. Die Maschine erledigt alles für Sie.
Die Realität: Das Paper fand heraus, dass fast niemand diese Tools so nutzt. Entwickler nutzen sie selten einfach über eine Befehlszeile oder richten sie in einem automatisierten Workflow ein (wie ein Roboterarm, der sich einfach nur einschaltet).
Stattdessen behandeln Entwickler diese Frameworks wie Lego-Sets. Sie nutzen nicht einfach das vorgefertigte Schloss; sie nehmen die Steine (die Code-APIs) und bauen ihre eigenen, individuellen Strukturen. Sie schreiben ihre eigenen Skripte, um die Tools mit ihren spezifischen Bedürfnissen zu verbinden, anstatt das Tool die schwere Arbeit automatisch erledigen zu lassen.
2. Das „Schweizer Taschenmesser“ vs. das „Spezialwerkzeug“
Die Forscher stellten fest, dass Entwickler oft mehrere Werkzeuge gleichzeitig verwenden, so wie ein Koch ein spezielles Messer für Fisch, ein anderes für Gemüse und ein Thermometer für den Ofen benutzt.
- Die Tracker: Tools wie MLFlow und Wandb sind am beliebtesten. Sie sind wie die „Ergebnistafeln“ und „Notizbücher“ der Küche. Entwickler nutzen sie, um aufzuschreiben, welche Zutaten sie verwendet haben, wie das Gericht geschmeckt hat, und um eine Historie jeder Version des Rezepts zu führen.
- Die Erbauer: Tools wie Kedro und Prefect sind wie die Leiter der Fließbandproduktion. Sie helfen dabei, die Schritte des Kochprozesses zu organisieren.
- Die Qualitätsprüfer: Tools wie Deepchecks und Evidently AI sind die Lebensmittelkontrolleur. Sie prüfen, ob die Zutaten schlecht geworden sind oder ob sich der Geschmack über die Zeit verändert hat.
Die Studie fand heraus, dass Menschen diese oft kombinieren. Zum Beispiel nutzen sie vielleicht eine „Ergebnistafel“ (MLFlow), um das Rezept zu verfolgen, ein „Fließband“ (Prefect), um die Kochschritte auszuführen, und einen „Lebensmittelkontrolleur“ (Evidently AI), um sicherzustellen, dass das Essen sicher ist. Sie tun dies, weil kein einzelnes Tool alles perfekt macht.
3. Das „Fehlende Handbuch“-Problem
Die Forscher haben auch die „Beschwerdeboxen“ (Issue-Tracker) untersucht, in denen Nutzer den Tool-Machern mitteilen, was sie wollen. Sie fanden ein klares Muster:
- Die Leute wollen bessere „Ergebnistafeln“: Nutzer fragen nach besseren Wegen, um ihre Experimente zu verfolgen und ihre Modelle zu überwachen.
- Die Leute wollen einfachere „Plug-ins“: Da Entwickler ihre eigenen individuellen Strukturen bauen (unter Verwendung der APIs), fordern sie, dass die Tools einfacher mit ihren individuellen Konstruktionen zu verbinden sind. Sie wollen, dass die „Lego-Steine“ leichter zusammenklicken.
- Die Leute wollen bessere Automatisierung: Obwohl sie diese Tools noch nicht „Out-of-the-Box“ nutzen, fragen sie nach besseren Wegen, um diese Tools in ihre automatisierten Kochlinien (CI/CD-Pipelines) zu integrieren.
Das große Fazit
Das Paper kommt zu dem Schluss, dass diese „intelligenten Küchensysteme“ zwar existieren und leistungsstark sind, aber nicht als einfache, fertige Lösungen verwendet werden. Stattdessen basteln Entwickler sie sich zusammen, um maßgeschneiderte Lösungen zu bauen, weil die Tools ihre spezifischen Bedürfnisse noch nicht ganz erfüllen.
Die Nutzer sagen: „Wir lieben die Kernfunktionen (wie Tracking und Monitoring), aber bitte macht es einfacher, diese Tools mit unseren individuellen Arbeitsabläufen zu verbinden, und helft uns bitte dabei, die langweiligen Teile besser zu automatisieren.“
Kurz gesagt: Die MLOps-Welt befindet sich derzeit in einer Phase, in der jeder seine eigenen individuellen Küchengeräte mit demselben Satz an Werkzeugen baut, anstatt einfach nur ein fertiges Haushaltsgerät zu kaufen. Die Tool-Maker müssen auf die Erfinder hören, um die nächste Generation von Gadgets einfacher zu machen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.