{"id":21638,"date":"2022-08-16T11:04:00","date_gmt":"2022-08-16T09:04:00","guid":{"rendered":"https:\/\/www.sysbus.eu\/?p=21638"},"modified":"2022-08-08T10:55:46","modified_gmt":"2022-08-08T08:55:46","slug":"sieben-mlops-mythen-die-die-verantwortlichen-vor-dem-einsatz-ihrer-ki-projekte-kennen-sollten","status":"publish","type":"post","link":"https:\/\/www.sysbus.eu\/?p=21638","title":{"rendered":"Sieben MLOps Mythen, die die Verantwortlichen vor dem Einsatz ihrer KI-Projekte kennen sollten"},"content":{"rendered":"\n

Autor\/Redakteur: Dr.-Ing. Sebastian Werner von der Everyday AI Plattform Dataiku<\/a>\/gg<\/p>\n\n\n\n

Die Nutzung von K\u00fcnstlicher Intelligenz (KI) beziehungsweise Maschinellem Lernen (ML) im betrieblichen Umfeld gewinnt st\u00e4ndig an Bedeutung. Viele Unternehmen haben bereits erste Erfahrungen in sogenannten Proof-of-Concept (PoC) mit KI gesammelt. Mehr und mehr kommen KI-Projekte auch in den produktiven Einsatz \u2013 ohne klar strukturierte MachineLearning Operations (MLOps) laufen Unternehmen allerdings Gefahr, dass KI-Projekte nie wertbringend eingesetzt werden und somit auch keinen tats\u00e4chlichen Gesch\u00e4ftswert erzielen. Das Problem dabei: Einige Mythen \u00fcber MLOps halten sich hartn\u00e4ckig und erschweren es Unternehmen, maximalen Wert aus ihren ML-Projekten zu generieren. Dieser Artikel erkl\u00e4rt, warum es bei MLOps nicht nur um die Modellierung geht und welche Arbeit nach der Integration von MLOps auf Unternehmen zukommt.<\/p>\n\n\n\n

\"\"<\/a>
Bild: Dataiku<\/figcaption><\/figure>\n\n\n\n\n\n\n\n

Mythos 1: Bei MLOps geht es nur um die Modellierung<\/strong><\/p>\n\n\n\n

Bei der Planung KI-gest\u00fctzter Datenprojekte neigen viele Unternehmen dazu, sich auf das Modell als prim\u00e4res oder sogar einziges Ergebnis des gesamten Projekts zu konzentrieren. Doch um ein Modell produktiv und auch langfristig wertbringend einzusetzen ist deutlich mehr n\u00f6tig – und hier setzt dann MLOps an. Diese Arbeiten gehen weit \u00fcber Modellbildung hinaus und umfassen auch die Datenvorbereitung, Konfiguration, Datenerfassung, Merkmalsextraktion (Feature Engineering), Daten\u00fcberpr\u00fcfung, die Auswahl von Analyse- und Prozessmanagement-Tools, die Verwaltung der Maschinenressourcen und die Bereitstellung der Infrastruktur bis hin zur \u00dcberwachung des Betriebs. Damit ein Modell also auch tats\u00e4chlich erfolgreich in die Produktion gebracht und operationalisiert werden kann, m\u00fcssen alle diese Arbeiten ber\u00fccksichtigt werden. Spannenderweise funktioniert die MLOps Methodik auch bei reinen ETL pipelines oder Dashboards. Denn bei allen \u201cDatenprodukten\u201d gilt: Es ist kein Projekt, das abgeschlossen ist, sondern ein Produkt.<\/p>\n\n\n\n

Mythos 2: Modellentw\u00fcrfe k\u00f6nnen einfach in die Produktionsumgebung kopiert werden<\/strong><\/p>\n\n\n\n

Zu h\u00e4ufig wird beim Entwerfen von Modellen nur eine Trainings \/ PoC Umgebung ber\u00fccksichtigt \u2013 ein ausschlaggebender Faktor f\u00fcr das Scheitern solcher Projekte. Erfahrungsgem\u00e4\u00df ist die Produktionalisierung der mit Abstand schwierigste Schritt: Schlie\u00dflich m\u00fcssen Pipelines und Modelle nicht blo\u00df in der \u201cOffline\u201d-Testumgebung mit sorgsam ausgew\u00e4hlten Testdaten funktionieren, sondern auch in der Produktionsumgebung mit der vollen Realit\u00e4t. Vergessen Entwicklerteams beim Planen der Modelle allerdings, die \u00dcbertragbarkeit dieser in den spezifischen Kontext sicherzustellen, ergeben sich neue Probleme in den Folgeschritten. Wird das Modell anschlie\u00dfend im Modellzustand an die Produktionsteams weitergegeben, k\u00f6nnen diese damit nicht arbeiten und das Projekt wird nicht weiter verfolgt – das Modell bleibt im Proof-of-Concept h\u00e4ngen. Pipelines und Modelle sollten aus diesem Grund in beiden Umgebungen funktionieren und von vornherein so entworfen sein. F\u00fcr das Entwicklerteam bedeutet das, alle Artefakte, die in die Erstellung des Modells eingeflossen sind, ebenfalls zu \u00fcbertragen. Wenn das Modell dann vollst\u00e4ndig trainiert und auf dem neuesten Stand ist, m\u00fcssen die Daten bei jedem einzelnen Schritt bereinigt und gegebenenfalls angepasst werden, um reale Ergebnisse und Vorhersagen m\u00f6glich zu machen.<\/p>\n\n\n\n

Mythos 3: Ist ein Modell in die Produktion integriert worden, ist das Projekt abgeschlossen.<\/strong><\/p>\n\n\n\n

Viele Unternehmen glauben, dass mit der Modellintegration das Projekt abgeschlossen ist. Allerdings geht es bei den meisten MLOps nicht um die Bereitstellung an sich, sondern vielmehr darum, die Projekte im Laufe der Zeit in ihrem Produktionszustand zu erhalten. Bei genauerer Betrachtung f\u00e4llt auf: Modelle sind kein \u201cProjekt\u201d, sondern ein \u201cProdukt\u201d – es gibt also einen Lebenszyklus, und \u201c\u00fcber den Zaun werfen\u201d wird nicht zum Erfolg f\u00fchren. Deshalb ist es wichtig, \u00fcber die Bereitstellung hinaus zu denken und sich mit dem tats\u00e4chlichen Modelllebenszyklusmanagement zu befassen. Selbst wenn der Entwurfsprozess nur ein paar Wochen gedauert hat, wird das Modell \u2013 im besten Fall \u2013  jahrelang laufen. In dieser Zeit sollte es weiterhin skalierbare, relevante Erkenntnisse liefern k\u00f6nnen. Langfristig geht es bei MLOps darum, Parameter immer wieder anzupassen und sorgsam zu \u00fcberwachen und so nachhaltige Erfolge zu erzielen. So kann das Modell im Laufe der Zeit an Genauigkeit und Leistung gewinnen.<\/p>\n\n\n\n

Mythos 4:<\/strong> Genauigkeit ist die einzig wichtige Kennzahl<\/strong><\/p>\n\n\n\n

Oft wird davon ausgegangen, dass Genauigkeit des Modells die wichtigste Kennzahl bei MLOps Projekten ist. Das mag initial vielleicht stimmen, doch spielen die Erkennung von Datendrifts, die Pipeline und die Funktionsf\u00e4higkeit von Services eine auf Dauer wesentlich wichtigere Rolle. Langfristig kommt es auf Robustheit an. Gerade Datendrifts k\u00f6nnen f\u00fcr Projekte ein schwerwiegendes Problem darstellen. Ein Beispiel: In einem Projekt wird ein ML-Modell zur Bilderkennung entwickelt. Das Modell wird darauf trainiert, originale Picasso-Bilder von erwiesenerma\u00dfen gef\u00e4lschten Picasso-Bildern zu unterscheiden. In der Produktion wird das Modell dann erstmals mit einem Van-Gogh Bild konfrontiert. Dieses erkennt es jedoch nicht, da es nur auf Picasso trainiert wurde \u2013 es entsteht ein sogenannter Datendrift. \u200b\u00dcberwachungspraktiken und eine gute Infrastruktur, die eine schnelle Anpassung erm\u00f6glichen, sollten also noch vor der Genauigkeit priorisiert werden.<\/p>\n\n\n\n\n\n\n\n

Mythos 5: Modelle k\u00f6nnen sofort korrigiert werden<\/strong><\/p>\n\n\n\n

Fehlverhalten, oder gar ein \u201cTotalausfall\u201d eines Modells sind zu Beginn der Modellentwicklung bekannterma\u00dfen keine Seltenheit, und auch im produktiven Betrieb mit MLOps nicht immer vermeidbar  \u2013 h\u00e4ufig entstehen sie aufgrund von beispielsweise \u00c4nderungen in einem vorgelagerten System, Daten\u00e4nderungen oder auch Drifts. Da Modelle oftmals nicht einfach repariert werden k\u00f6nnen, ist bei der Umsetzung von MLOps Projekten ein Plan f\u00fcr einen solchen Fall notwendig.  Dieser soll im Falle eines Ausfalls eingesetzt werden und  so den Betrieb aufrechterhalten. Ein Plan kann dabei darin bestehen, Ersatzmodelle bereitzuhalten, die zur \u00dcberbr\u00fcckung eingesetzt werden k\u00f6nnen. Au\u00dferdem muss eine M\u00f6glichkeit geschaffen werden, Modelle mit entsprechenden Tools zu reparieren und aktualisieren, ohne die nachgelagerten Dienste zu unterbrechen.<\/p>\n\n\n\n

Mythos 6: Produktionsteams m\u00fcssen ML Projekte nicht verstehen<\/strong><\/p>\n\n\n\n

Ein h\u00e4ufiger Irrglaube ist, dass die Teams, die operative Verantwortung f\u00fcr ein Modell tragen die entwickelten Modelle einfach \u00fcbernehmen und in die Produktion \u00fcberf\u00fchren k\u00f6nnen, ohne den Zweck und den Prozess des Projekts wirklich zu verstehen. Allerdings k\u00f6nnen \u200b\u200bModelle nicht einfach ohne kontextbezogenes Wissen \u00fcber ihr Design und ihren geplanten Betrieb eingesetzt werden. Wird so gearbeitet, k\u00f6nnen Fehleinsch\u00e4tzungen des Einsatzteams Anomalien im Modellverhalten hervorrufen und sogar zu unerw\u00fcnschten Verzerrungen im System f\u00fchren. Produktionsteams, die das zugrundeliegende Verhalten und die Erwartungen an ein Modell kennen, sind besser in der Lage, Probleme zu beheben und Modelle einzusetzen, die sich wie erwartet verhalten. Allein aus diesem Grund wird empfohlen, dass MLOps-Teams Zugang zu Tools haben, die automatisch eine umfangreiche Modelldokumentation erstellen. Kurzgesagt: MLOps ist ein Teamsport – und schon fr\u00fch gemeinsam \u201ctrainieren\u201d erm\u00f6glicht es, Wissen zu teilen und langfristigen Erfolg zu sichern.<\/p>\n\n\n\n

Mythos 7: Mit MLOps ist KI-Governance \u00fcberfl\u00fcssig<\/strong><\/p>\n\n\n\n

Oft wird angenommen, dass MLOps ein Ersatz f\u00fcr jegliche KI-Governance sind. Zwar \u00fcberwachen sowohl MLOps als auch KI Governance den Betrieb von Projekten in Produktionsumgebungen, dennoch decken sie unterschiedliche Funktionen ab, die sich nicht \u00fcberschneiden. MLOps konzentrieren sich auf die Spezifikation und Nutzung von Service-Levels, um qualitativ hochwertige Ergebnisse zu liefern. KI Governance ist hingegen f\u00fcr das Risikomanagement und die Sicherstellung der Compliance verantwortlich. Sowohl MLOps als auch KI-Governance-Teams wollen \u201cgesunde\u201d und gewinnbringende Projekte, aber die beiden Ans\u00e4tze sind v\u00f6llig unterschiedlich. AI-Governance ist also durch den Einsatz von MLOps nicht redundant, da es sich um zwei f\u00fcr das Unternehmen einzigartige und wesentliche Funktionen handelt, die sich im Wert f\u00fcr Unternehmen erg\u00e4nzen.<\/p>\n\n\n\n

Skalierbare Projekte durch MLOps<\/strong><\/p>\n\n\n\n

Bei der Umsetzung KI-gest\u00fctzter Projekte liefern MLOps einen gro\u00dfen Mehrwert, indem sie Echtzeit-Einsichten zur Verf\u00fcgung stellen. ML-Prozesse werden einfacher, skalierbarer, zuverl\u00e4ssiger und weniger riskant – und damit insgesamt kosteng\u00fcnstiger. Durch die Einbeziehung aller Aspekte von der Planung, Entwicklung, Erstellung, Pr\u00fcfung, Freigabe, Bereitstellung und dem Betrieb bis hin zur \u00dcberwachung stellen MLOps sicher, dass Unternehmen ihre vorhandenen maschinellen Lernressourcen besser nutzen. Au\u00dferdem k\u00f6nnen neue Projekte auf einfache und kontrollierte Weise erstellt und verwaltet werden. Verschiedene Plattformen unterst\u00fctzen bei der Umsetzung, indem sie den gesamten Lebenszyklus eines Projekts kontinuierlich begleiten. Sie \u00fcberwachen Metriken, Daten-Pipelines und Datendrifts und erm\u00f6glichen es Teams, bei Problemen zu handeln. So werden MLOps Projekte strukturierter und \u00fcbersichtlich und somit auch skalierbarer.<\/p>\n","protected":false},"excerpt":{"rendered":"

Die Nutzung von K\u00fcnstlicher Intelligenz (KI) beziehungsweise Maschinellem Lernen (ML) im betrieblichen Umfeld gewinnt st\u00e4ndig an Bedeutung. Viele Unternehmen haben bereits erste Erfahrungen in sogenannten Proof-of-Concept (PoC) mit KI gesammelt. Mehr und mehr kommen KI-Projekte auch in den produktiven Einsatz \u2013 ohne klar strukturierte MachineLearning Operations (MLOps) laufen Unternehmen allerdings Gefahr, dass KI-Projekte nie wertbringend eingesetzt werden und somit auch keinen tats\u00e4chlichen Gesch\u00e4ftswert erzielen. Das Problem dabei: Einige Mythen \u00fcber MLOps halten sich hartn\u00e4ckig und erschweren es Unternehmen, maximalen Wert aus ihren ML-Projekten zu generieren. Dieser Artikel erkl\u00e4rt, warum es bei MLOps nicht nur um die Modellierung geht und welche Arbeit nach der Integration von MLOps auf Unternehmen zukommt.<\/p>\n","protected":false},"author":1,"featured_media":21640,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[8,10036],"tags":[14947,10986,14948,16655,16654],"class_list":["post-21638","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artikel","category-kuenstliche-intelligenz","tag-dataiku","tag-ml","tag-mlops","tag-modellierung","tag-poc"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/21638","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=21638"}],"version-history":[{"count":2,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/21638\/revisions"}],"predecessor-version":[{"id":21642,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/21638\/revisions\/21642"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/media\/21640"}],"wp:attachment":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21638"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21638"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21638"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}