Hinweis: Der folgende Artikel hilft Ihnen dabei: Schritte zur MLOps-Forschung – Software Engineering Ihrer KI – Auf dem Weg zur KI
Ursprünglich veröffentlicht auf Towards AI, dem weltweit führenden Nachrichten- und Medienunternehmen für KI und Technologie. Wenn Sie ein KI-bezogenes Produkt oder eine KI-bezogene Dienstleistung entwickeln, laden wir Sie ein, darüber nachzudenken, KI-Sponsor zu werden. Bei Towards AI helfen wir bei der Skalierung von KI- und Technologie-Startups. Wir helfen Ihnen dabei, Ihre Technologie der breiten Masse zugänglich zu machen.
Schritte zur MLOps-Forschung – Softwareentwicklung Ihrer KI
MLOps ist eine alte Anforderung für ein neues Feld; Die Welt des maschinellen Lernens entwickelt sich weiter, von einem Nischenthema mit den dunkelsten Hintergründen zu einem erstklassigen Bürger in einer Vielzahl von Anwendungsfällen. Aber mit großen Kräften geht auch große Verantwortung einher; Neben dem Hinzufügen neuer, domänenspezifischer Anforderungen (z. B. Erklärbarkeit des Modells, Zusammenarbeit bei der Forschung und deren Lesbarkeit) werden auch traditionellere allgemeine Softwareentwicklungsanforderungen (z. B. Überwachung, API-Bereitstellung und Release-Management) immer wichtiger Auch für KI-Anwendungen von entscheidender Bedeutung. Diese Verfahren sind in der allgemeinen Welt der Softwareentwicklung gut formuliert, sind jedoch im Bereich des maschinellen Lernens recht neu und werden daher einige Zeit brauchen, bis sie vollständig übernommen sind. Aber in der Zwischenzeit kann noch viel getan werden; Der erste Schritt sollte darin bestehen, allgemeine Softwareentwicklungskonzepte zu übernehmen und sie in die Welt des maschinellen Lernens zu integrieren. Kleine Änderungen an der Art und Weise, wie wir unsere KI-Projekte interagieren und verwalten. Nachfolgend finden Sie die wichtigsten Punkte zur Erreichung dieses Ziels. Einfach, aber gleichzeitig entscheidend für dieses Bedürfnis.
Reproduzierbare Forschung – Zugdatensatz aufbewahren
Eines der Hauptphänomene, das uns in der Welt des maschinellen Lernens am meisten stört, sind nicht reproduzierbare Forschungsarbeiten. solche, die extreme Ergebnisse zeigen, aber gleichzeitig ihren Code, ihre Daten oder eine Möglichkeit zur Reproduktion ihrer Ergebnisse nicht teilen. Vergrößern Sie nun Ihre Organisationen. Nehmen wir an, wir haben ein Modell, das eine Zeit lang läuft, unsere Kunden bedient und die Leistung Das Problem besteht darin, dass derjenige, der das Modell erstellt hat, das Projekt verlassen hat bzw. an einem anderen Projekt arbeitet. Jetzt müssen wir das Modell erneut untersuchen, um seine Zahlen besser zu verstehen. Bei solchen Prozessen stoßen wir häufig auf Grenzfälle wie anomale Datenteile, neue potenzielle Merkmale, fehlende Werte oder einfach nur auf unsere einzigartige Sichtweise auf das vorliegende Problem. Jeder dieser Punkte kann uns auf eine lange Reise schicken, nur um Fragen zu beantworten wie: Kennen sich die Modellbauer damit aus? Und wenn ja, haben sie die Dinge anders gemacht? Das Problem ist, dass es leicht Zeitverschwendung sein kann, Geister zu verfolgen, ohne zu wissen, dass es sich dabei um Sackgassen handelt. Aber was wäre, wenn wir in die Zeit zurückspringen könnten, als das Modell ursprünglich trainiert wurde, und diese Fragen validieren könnten? Da große Köpfe gleich denken, wurden viele unserer „neuen faszinierenden“ Ideen höchstwahrscheinlich bereits bewertet! Aber bis man eine Arbeitszeitmaschine entwickelt, ist das Beste, was wir tun können, die ursprüngliche Zugpopulation zu speichern, auf der das Modell trainiert wurde, damit wir die vorliegenden Fragen problemlos validieren können. Durch das systematische Speichern von Zugdatensatz-Snapshots werden viele dieser späteren Anforderungen erleichtert.
Erklärbare Recherche – protokollieren Sie, was Sie tun und was nicht
In Fortsetzung unseres vorherigen Punktes reicht es in manchen Fällen nicht aus, eine Momentaufnahme des Trainingsdatensatzes zu behalten, da einige wichtige Kontextpunkte fehlen. Beantwortung von Fragen wie „Warum verwendet das Modell Feature X nicht für seine Vorhersagen?“ Oder „War es nicht besser, die Daten anders darzustellen?“ ist nicht möglich, wenn nur Schnappschüsse des Zugdatensatzes vorhanden sind. Was uns fehlt, ist der Kontext, der zu einigen dieser Entscheidungen geführt hat und der in den Daten selbst normalerweise nicht sichtbar ist. Eine überaus wichtige Lösung für diesen Bedarf kann darin bestehen, über strukturiertere Forschungsmethoden zu verfügen. Durch die Verwendung von Tools wie iPython-Notebooks können wir leicht verstehen, was getan wurde, warum und wie. Solche Tools sind sogar für den einzelnen Datenwissenschaftler wichtig, der alleine in einer größeren Forschungs- und Entwicklungsorganisation arbeitet. Das Führen gut dokumentierter und aktueller Notizbücher, in denen die von uns durchgeführten Untersuchungen und die von uns getroffenen Entscheidungen beschrieben werden, kann es uns ermöglichen, Fragen und Bedenken, die in der Zukunft auftreten könnten, einfacher zu beantworten. Da es zu einem offenen Buch unserer Forschung wird, kann es sogar dazu führen, dass sich unsere generierten Modelle selbst erklären, wenn es um solche Zukunftsthemen geht.
Softwareentwicklungsforschung – machen Sie daraus ein Projekt und GIT
Nachdem wir uns nun entschieden haben, iPython-Notizbücher als unser wichtigstes Forschungstool zu verwenden, und nachdem wir uns darum bemüht haben, es strukturierter und lesbarer zu machen, ist es verlockend, alle unsere Entwicklungen in dieses Ökosystem zu verlagern und sogar unsere Produktionsskripte als Notizbücher zu verwalten und auszulösen. Persönlich finde ich iPython-Notebooks während der ersten Recherche- und POCing-Phasen äußerst nützlich, aber auch äußerst kontraintuitiv und fehleranfällig, sobald die Recherche durchgeführt wurde. Codeentwicklungsprozesse umfassen üblicherweise Versionen, Fehler, User Stories, Dokumentation und viele andere moderne Software-Engineering-Funktionen. Alle sind gut für den Einsatz von Quellcode-Hosting-Tools wie GIT geeignet, sodass wir den Entwicklungsstand unseres Codes einfach verwalten können. Die Beibehaltung unserer Notebook-Versionen mithilfe von Versionskontrollsystemen ist der erste Schritt in diese Richtung. Aber das reicht nicht aus. Sobald die Recherchephase abgeschlossen ist, ist es wichtig, unsere Notebooks als reguläre Softwareentwicklungsprojekte zu behandeln und sich mit den damit verbundenen relevanten Anforderungen auseinanderzusetzen. Ein Beispiel hierfür ist die Sicherstellung, dass unser Code reproduzierbar ist. Diese Notwendigkeit ist vor allem für zwei Bereiche äußerst wichtig: die Datenerstellungsphase (damit wir Datenfehler leichter untersuchen und beheben können, indem wir den zugehörigen Code klarer und sichtbarer machen und dies auch einfacher machen). Forschung zur Entwicklung des Übergangs) und die Produktionsphase (ermöglicht einen klaren Überblick über die App-Anforderungen, z. B. wie Online-Inferenz unterstützt wird, sowie allgemeine Kontextpunkte wie die prognostizierte Latenz). Solche Funktionen sind weniger sichtbar, wenn unser Code über verschiedene Notebooks hinweg verwaltet wird. Darüber hinaus kann die Notebook-basierte Entwicklung problemlos Code-Anti-Patterns wie Code-Duplikationen tolerieren. Sobald Visualisierung, Lesbarkeit und Recherche weniger wichtig sind, ist es an der Zeit, unsere iPython-Notebook-Snippets so zu verschieben, dass sie als allgemeine Codeprojekte verwaltet werden.
Forschungssoftware-Entwickler— Notizbücher Kontext
Nachdem wir nun erfahren haben, wie wichtig es ist, unseren Code so schnell wie möglich in allgemeine Projekte zu verschieben, sollten wir noch einmal hervorheben, warum wir uns überhaupt für die Verwendung von iPython-Notebooks entschieden haben. Ein kurzer Blick auf KI-Entwicklungen besteht aus zwei Hauptphasen – der Explorations-/allgemeinen Forschungsphase und den spezifischeren Folgemaßnahmen, wenn wir wissen, was zu tun ist, und mit der Umsetzung beginnen. Durch die einfache Visualisierung und Erklärbarkeit sind iPython-Notebooks eindeutig das beste Werkzeug für die Forschungsphase. Während wir zuvor beschrieben haben, warum es wichtig ist, sich nicht zu sehr auf Notebooks zu verlassen, sollte man sich bei der Spiegelung nicht zu sehr auf allgemeine Codeprojekte verlassen; Ähnlich wie zuvor wird es eine Tendenz geben, alle unsere Entwicklungen aus dem Notebook-Ökosystem zu verlagern. Ein solcher üblicher Schritt würde das Refactoring der Notebooks, das Verschieben von Codeausschnitten zum Hosten in Codeprojekten und die Verwendung ihrer Importe (anstelle des einfachen Codes) in unseren Notebooks umfassen. Der versteckte Nachteil ist jedoch die Tatsache, dass Notebooks und allgemeine Codeprojekte unterschiedliche Fortschritts- und Veröffentlichungsprozesse haben – ein erneuter Blick auf unsere Notebooks ein paar Monate später kann die Tatsache verbergen, dass das Notebook zwar mit Importen der Codeversion X generiert wurde, die aktuelle Codebasis jedoch bei ist Version X+m, die für den Notebook-Status, den wir sehen, nicht mehr relevant ist (Fehler wurden behoben, APIs sind defekt usw.). Was uns fehlt, ist ein kombinierter Code-Projekt-Notebook-Status. Dafür gibt es einige mögliche Lösungen, wie etwa das Einfügen von Notizbüchern in Teile der Codeprojekte, die weitere Untersuchungen ermöglichen können, um zu verstehen, auf welche Codeversionen sie sich verlassen haben. Ein einfacherer Ansatz besteht jedoch darin, in den Explorationsnotizbüchern deutlich zu machen, was sie untersuchen wollten und auf welche Assets, Zustände und Versionen sie sich stützten. In manchen Fällen kann sogar (verzeih mir, Gott) das bloße Kopieren des entsprechenden Codes Sinn machen.
Forschungsüberwachung – Modellleistung
Ein wichtiger Punkt, den viele von uns gerne vergessen, ist die Tatsache, dass unsere Arbeit nicht endet, wenn die Forschung, die Entwicklung und auch die Bereitstellung abgeschlossen ist. In einigen Aspekten beginnt es erst, wenn Benutzer beginnen, mit unseren generierten Modellen zu interagieren. Im Allgemeinen beinhaltet die Forschung, die wir durchführen, einen Bedarf und eine relevante These. Um beispielsweise die Kundenzufriedenheit (das Bedürfnis) zu erhöhen, werden wir versuchen, unseren Service zu verbessern, indem wir sicherstellen, dass die Anfragen des Kunden rechtzeitig bearbeitet und gelöst werden, in der Annahme, dass dies zu einer Verbesserung seiner Zufriedenheit führt (die These). Nehmen wir an, wir haben ein Modell für die Supportteams unseres Unternehmens erstellt, das Kundenanfragen hervorhebt, bei denen das Risiko besteht, dass sie nicht rechtzeitig gelöst werden. Sobald Benutzer (die Support-Mitarbeiter) unsere App nutzen, sollten wir einige Kennzahlen im Auge behalten. Erstens: Wenn Kundenanfragen jetzt nicht besser bearbeitet werden, sind weitere Debugging-Maßnahmen erforderlich. Möglicherweise liegt ein Problem mit der UX, den von uns verwendeten Daten oder dem von uns generierten Modell vor. Dann ist es wichtig zu überprüfen, ob unsere These besagt, dass die Zufriedenheit steigen sollte, sobald weitere Anfragen ordnungsgemäß bearbeitet werden. Aus Sicht des Betriebs ist es wichtig, diese Merkmale kontinuierlich zu überprüfen. Eine häufig zu beobachtende Metrik ist die Klassenverteilung – suchen Sie nach plötzlichen Veränderungen (die auf ein Problem hinweisen können) und vergleichen Sie sie mit unseren Forschungsbasiszahlen (vorausgesetzt, unser Modell hat positive X % für die Validierungsaufteilung vorhergesagt und jetzt sind es 3*X % oder X /3 %, kann dies auf ein Problem hinweisen). In einigen Fällen werden unsere Modelle per Definition periodisch sein und von Zeit zu Zeit neu trainiert werden müssen. Für diese Fälle möchten wir die Modelle per Code generieren (und nicht in einmaligen Notebooks). Ein solcher Code kann Teil des allgemeinen CI-CD-Bereitstellungsprozesses sein und sollte automatische Tests umfassen, um zu überprüfen, ob das generierte neue Modell das vorhandene ersetzen soll. Solche Tests werden wahrscheinlich genau die gleichen Metriken analysieren, die wir erwähnt haben, und können daher für diesen Bedarf wiederverwendet werden.
Forschungstests – Datenüberprüfungen
Nachdem wir nun mit der Überwachung unseres Modells begonnen haben, sollten wir die anderen möglichen Tests prüfen, die wir anwenden können. Neben regulären Betriebsmetriken (wie Latenz, verwendeter Speicher, Anforderungsfehler usw.) und den intuitiven Leistungsmetriken (Genauigkeitsraten) würden wir gerne klassischere Tests wie Unit-, Funktions- und Integrationstests verwenden. Angesichts der hohen Bedeutung von Daten für den Erfolg von KI-Anwendungen sollte der erste Bereich, in dem diese Tests angewendet werden, der Datenbereich sein. Darüber hinaus sind wir, wie in vielen Fällen, die Datenkonsumenten (die an anderer Stelle produziert werden) und möchten wichtige Eigenschaften unserer Daten Unit-Tests durchführen und überwachen. Der naive Ansatz besteht darin, Eigenschaften wie Datendefinitionen im Allgemeinen zu überprüfen. Das ist nicht deshalb naiv, weil es an Bedeutung mangelt, sondern weil es sich hierbei um einen nie endenden Aufwand handelt – jedes Datenfeld kann in zahlreichen Aspekten (Nullwerte, Dichte, Bereiche usw.) weiter beschrieben und analysiert werden. Das Testen all dieser Fälle wird schwierig durchzuführen sein und kann leicht zu vielen FP-Warnungen führen. Eine vernünftigere Lösung kann auf umgekehrte Weise aufgebaut werden; Gehen Sie zunächst davon aus, dass alles korrekt funktioniert, und beginnen Sie damit, nur die 911 Fälle zu überprüfen (so dass überhaupt neue Daten eingegangen sind). Erstellen Sie dann neue Datentests erst nach der Identifizierung von Datenfehlern (um diese in Zukunft zu überprüfen). Wenn Sie diesen Ansatz verwenden, stellen Sie sicher, dass Sie nicht zu viele Tests haben, und für die Tests, die Sie haben, wird es eine klare Motivation geben, sicherzustellen, dass sie ordnungsgemäß funktionieren.
Softwareentwicklungsforschung und umgekehrt
Die KI-Forschung kann von den allgemeinen Softwareentwicklungskonzepten nur profitieren. Angesichts des starken Aufstiegs von KI, ML-Ingenieuren und Tools wie iPython-Notebooks kann man davon ausgehen, dass auch das Gegenteil der Fall sein wird und auch allgemeine Softwareentwicklungen von KI-Konzepten profitieren werden. Beginnen Sie beispielsweise damit, Notebooks als DevOps-Tool zu verwenden, um die jeweiligen Umgebungseigenschaften zu beschreiben. Spannende Tage liegen vor uns.
Schritte zur MLOps-Forschung – Software Engineering your AI wurde ursprünglich in Towards AI auf Medium veröffentlicht, wo die Leute das Gespräch fortsetzen, indem sie diese Geschichte hervorheben und darauf reagieren.
Veröffentlicht über Towards AI
