Socio-Technical Anti-Patterns in Building ML-Enabled Software: Insights from Leaders on the Forefront
Dieses Paper präsentiert die größte qualitative empirische Studie über soziotechnische Herausforderungen bei der Produktionierung von ML-Modellen, indem es 66 Stunden an MLOps-Community-Talks analysiert, um 17 Anti-Patterns zu identifizieren, die in organisatorischen Problemen verwurzelt sind, und handlungsorientierte Empfehlungen zu deren Überwindung bereitzustellen.
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 ein Unternehmen vor, das versucht, ein hochmodernes, selbstfahrendes Auto zu bauen. Sie haben brillante Ingenieure, die den Motor (das Machine-Learning-Modell) entwerfen können, aber das Auto verlässt die Straße nie. Es steht einfach nur in der Garage und setzt Staub an.
Dieses Paper ist wie eine Detektivgeschichte, die untersucht, warum diese „smarten“ Autos ständig scheitern, auf die Straße zu kommen. Die Autoren, Alina Mailach und Norbert Siegmund, haben nicht nur nach den Motorteilen (dem Code) gesucht; sie haben sich die Menschen, das Management und die Büropolitik angesehen. Sie hörten über 66 Stunden Vorträge von Experten aus der „MLOps-Community“ (einer riesigen Gruppe von über 11.000 Fachleuten), um herauszufinden, was wirklich schiefläuft.
Sie entdeckten, dass das Problem meistens nicht die Technologie selbst ist. Stattdessen ist es eine Sammlung von 17 „Anti-Patterns“ – schlechte Gewohnheiten und organisatorische Fehler – die wie Schlaglöcher auf dem Weg zum Erfolg wirken.
Hier ist eine einfache Aufschlüsselung ihrer Erkenntnisse, unter Verwendung einiger alltäglicher Analogien:
1. Das „Zwei-Teams-Tauziehen“ (Organisatorische Silos)
Stellen Sie sich ein Team von Köchen (Data Scientists) vor, die ein köstliches neues Suppenrezept (das Modell) kreieren, und ein Team von Kellnern (Softwareentwickler), die diese Suppe den Kunden servieren müssen.
- Das Problem: Die Köche schreiben das Rezept in einem Geheimcode, auf Servietten, ohne Mengenangaben. Die Kellner sprechen diese Sprache nicht. Wenn die Köche versuchen, die Suppe zu übergeben, sagen die Kellner: „Ich kann das nicht servieren; das ist ein Chaos!“ Die Köche sagen: „Es ist perfekt; ihr versteht es nur nicht!“
- Das Ergebnis: Die Suppe wird nie serviert. Die Köche bleiben stecken, während sie versuchen zu lernen, wie man am Tisch serviert, und die Kellner bleiben steckengeblieben, während sie versuchen, das Rezept von Grund auf neu zu schreiben.
- Die Lösung: Sie brauchen eine Speisekarte (ein Model Registry), die das Rezept in klare Anweisungen übersetzt, oder sie müssen die Köche und Kellner in dieselbe Küche stellen (cross-funktionale Teams), damit sie während der Arbeit miteinander sprechen können.
2. Das „Daten-Horten“ (Produzent vs. Konsument)
Stellen Sie sich einen Bauern (Datenproduzent) vor, der Mais anbaut, und einen Bäcker (Datenkonsument), der diesen Mais braucht, um Brot zu backen.
- Das Problem: Der Bauer denkt: „Warum sollte ich dir meinen Mais geben? Es ist nicht meine Aufgabe, dir beim Backen zu helfen.“ Der Bäcker muss um den Mais betteln, und manchmal ändert der Bauer die Maissorte, ohne es dem Bäcker zu sagen. Der Bäcker endet mit einem Brot, das schrecklich schmeckt, weil sich die Zutaten geändert haben.
- Das Ergebnis: Der Bäcker backt schlechtes Brot, und der Bauer weiß nicht, warum sein Mais verschwendet wird.
- Die Lösung: Sie brauchen einen Gemeinschaftsmarkt (eine zentrale Datenplattform), auf dem der Bauer den Mais mit klaren Etiketten listet und der Bäcker genau weiß, was er bekommt.
3. Das „Neuerfinden des Rades“ (Redundante Entwicklung)
Stellen Sie sich ein Unternehmen vor, in dem Team A eine Leiter baut und Team B, drei Stockwerke tiefer, eine andere Leiter für denselben Zweck baut.
- Das Problem: Niemand weiß, dass das andere Team eine Leiter gebaut hat. Also verschwenden alle Zeit und Geld damit, Leitern zu bauen, die bereits existieren. Schlimmer noch: Wenn Team A eine Sprosse an ihrer Leiter repariert, ist die Leiter von Team B immer noch kaputt.
- Das Ergebnis: Chaos, verschwendetes Geld und „Shadow IT“ (Teams, die ihre eigenen geheimen, unsicheren Werkzeuge bauen).
- Die Lösung: Ein zentraler Geräteschuppen, in dem jeder sehen kann, welche Leitern existieren, und sie stattdessen ausleihen kann, anstatt neue zu bauen.
4. Die „Blinden Bosse“ (Führungsvakuum)
Stellen Sie sich einen Kapitän (Management) vor, der nicht weiß, wie man ein Schiff steuert, und der versucht, eine Crew für eine neue Reise einzustellen.
- Das Problem: Der Kapitän sieht den Jobtitel „Data Scientist“ und stellt 10 Leute ein, in der Annahme, dass das alles lösen wird. Aber er hat Leute eingestellt, die gut in Mathe sind, aber keinen Motor reparieren können. Oder er stellt jemanden für eine spezifische Aufgabe ein und vergisst dann, was diese Aufgabe war, wodurch der Mitarbeiter ohne Aufgabe dasteht.
- Das Ergebnis: Das Schiff ist voll von Menschen, die nicht segeln können, und der Kapitän ist verwundert, warum das Schiff sich nicht bewegt.
- Die Lösung: Der Kapitän muss die Grundlagen des Segelns lernen (Bildung) und basierend auf Fähigkeiten einstellen (kannst du den Motor reparieren?), nicht nur nach schicken Jobtiteln.
5. Das „Lebenslauf-Rennen“ und der „Hype-Zug“
- Lebenslauf-getriebene Entwicklung (Resume-Driven Development): Stellen Sie sich einen Bauherrn vor, der darauf besteht, Goldene Nägel zu verwenden, nur weil sie auf seinem Lebenslauf gut aussehen, obwohl das Haus eigentlich Stahlnägel benötigt. Das Haus sieht für einen Moment fantastisch aus, aber es bricht zusammen, weil die Materialien nicht zum Job passen.
- Hype-getriebene Kreation (Hype-Driven Creation): Stellen Sie sich einen Restaurantbesitzer vor, der beschließt, Drachenfleisch zu servieren, nur weil alle darüber reden, obwohl er gar keinen Drachen hat und die Kunden eigentlich nur einen Burger wollen. Er gibt sein ganzes Geld aus, um einen Drachen zu finden, nur um dann festzustellen, dass er einfach nur bessere Burger hätte machen sollen.
- Das Ergebnis: Projekte bleiben im „Proof of Concept Hell“ stecken – endlose Experimente, die niemals zu echten Produkten werden.
Das große Fazrazit
Die Autoren fanden heraus, dass die Technologie selten der wahre Bösewicht ist. Die wahren Bösewichte sind:
- Silos: Teams, die nicht miteinander kommunizieren.
- Verwirrung: Manager, die die Arbeit nicht verstehen, und Mitarbeiter, die die Geschäftsziele nicht verstehen.
- Schlechtes Recruiting: Die falschen Leute aus den falschen Gründen einzustellen.
Die Lösung? Es geht nicht darum, bessere Software zu kaufen. Es geht um eine bessere Organisation. Unternehmen müssen:
- Mauern zwischen Teams einreißen.
- Manager lehren, was Machine Learning tatsächlich ist.
- Leute nach ihren tatsächlichen Fähigkeiten einstellen, nicht nach ihren Jobtiteln.
- Sicherstellen, dass alle zustimmen, warum sie etwas bauen, bevor sie mit dem Bau beginnen.
Kurz gesagt: Man kann den besten Motor der Welt haben, aber wenn der Fahrer nicht weiß, wie man lenkt und die Passagiere sich über die Karte streiten, kommt das Auto nirgendwo an.
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.