Bewertung der Produktionsreife und der technischen Schulden von ML-Systemen

Machine Learning (ML) revolutioniert verschiedene Branchen und Anwendungen, von der Gesundheitsversorgung und dem Finanzwesen bis hin zu selbstfahrenden Autos und der Betrugserkennung. Die Bereitstellung von ML-Systemen in Produktionsumgebungen ist jedoch aufgrund verschiedener Faktoren wie technischer Schulden und mangelnder Produktionsreife eine Herausforderung. Technische Schulden sind ein fortlaufendes Problem für ML-Systeme und beziehen sich auf die kumulativen Kosten von Design-, Implementierungs- und Wartungsentscheidungen, die getroffen werden, um Software schneller zu liefern – mit dem Versprechen, sie später zurückzuzahlen. Alle sich ansammelnden technischen Schulden können erhebliche Kosten in Bezug auf Zeit, Geld und Leistung verursachen. Das Konzept der technischen Schulden im Bereich ML wurde erstmals in dem Paper „Machine Learning: The high-interest credit card of technical debt“ von Sculley, Holt et al. im Jahr 2014 vorgeschlagen. Produktionsreife bezieht sich auf die Gesamtheit der Praktiken, Prozesse und Technologien, die sicherstellen, dass das ML-System zuverlässig, skalierbar, wartbar und sicher ist.

„Technische Schulden sind wie eine Kreditkarte. Man sammelt sie leicht an, aber es ist schwer, sie abzubezahlen.“ – Chris Granger.

Die Bewertung der Produktionsreife und der technischen Schulden eines ML-Systems ist entscheidend, um sicherzustellen, dass das System in Produktionsumgebungen effektiv und effizient arbeiten kann. In diesem Blog werden wir einen modifizierten ML System Robustness Score definieren, eine Rubrik zur Bewertung der Produktionsreife und der technischen Schulden von ML-Systemen, mit Erkenntnissen, die vom Paper „The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction“ von Eric Breck et al. inspiriert sind. Wir werden die verschiedenen Parameter/Kategorien untersuchen, aus denen sich der von uns formulierte ML System Robustness Score zusammensetzt, sowie die Tests, die Sie in jeder Kategorie durchführen können.

ML System Robustness Score

Der ML System Robustness Score zielt darauf ab, einen umfassenden Evaluierungsrahmen für ML-Systeme zu bieten und potenzielle Probleme mit technischen Schulden zu identifizieren. Wir unterteilen die Bewertung in 6 Hauptkategorien mit 22 Unterkategorien, auf die wir im Folgenden näher eingehen:

1. Datenqualität und -vorbereitung
2. Modelltraining und -leistung
3. Modellevaluierung und -interpretierbarkeit
4. Modellbereitstellung und -überwachung
5. Infrastruktur und Betrieb
6. Sicherheit und Compliance

Datenqualität und -vorbereitung

„Wir haben keine besseren Algorithmen. Wir haben einfach mehr Daten.“
- Peter Norvig (amerikanischer Informatiker)

Das Zitat von Peter Norvig fasst die Bedeutung von Daten in ML-Modellen treffend zusammen. Die Qualität der Daten, die zum Trainieren und Testen des ML-Modells verwendet werden, hat einen direkten Einfluss auf dessen Leistung. Es ist essenziell sicherzustellen, dass die Daten relevant, genau und repräsentativ für den Problembereich sind. Nachfolgend sind die wichtigsten Unterkategorien der Evaluierung aufgeführt:

Modelltraining und -leistung

Die Bedeutung von Modelltraining und -leistung für das Erreichen der gewünschten Ergebnisse kann nicht genug betont werden. Die ständige Weiterentwicklung von ML-Modellen und die zunehmende Größe von Datensätzen haben zu einer wachsenden Nachfrage nach leistungsfähigerer Hardware für deren Training geführt. Das Aufkommen von Large Language Models (LLMs) hat das Feld der Verarbeitung natürlicher Sprache grundlegend verändert.

Um sicherzustellen, dass die Modelle weiterhin eine gute Leistung erbringen, ist es entscheidend, sie regelmäßig mit neuen Daten neu zu trainieren und Systeme zu bauen, die verschiedene Arten von Hardware unterstützen. Durch diesen Ansatz können Entwickler sicherstellen, dass die von ihnen erstellten ML-Modelle aktuell, effizient und in der Lage sind, zunehmend komplexe und größere Datensätze zu verarbeiten. Die Evaluierung der Modellleistung kann in mehrere Unterkategorien unterteilt werden, darunter die unten aufgeführten:

1. Modellleistungsmetriken: Sind die Leistungsmetriken an den geschäftlichen Anforderungen ausgerichtet?
2. Modellauswahl und -tuning: Wurden die geeigneten Modelle ausgewählt und feineingestellt (Fine-Tuning)?
3. Modellstabilität und Reproduzierbarkeit: Ist das Modell über die Zeit stabil und reproduzierbar?

Modellevaluierung und -interpretierbarkeit

Die Bewertung der Leistung eines ML-Modells anhand eines Satzes von Metriken ist ein integraler Bestandteil der Modellevaluierung, der genaue Vorhersagen sicherstellt. Auf der anderen Seite ist die Modellinterpretierbarkeit ebenso wichtig, da sie es Entwicklern und Stakeholdern ermöglicht, das innere Funktionieren des Modells zu verstehen und fundierte Entscheidungen auf der Grundlage seiner Ausgaben zu treffen. Mangelnde Interpretierbarkeit kann dazu führen, dass das Modell als „Blackbox“ angesehen wird, was es erschwert, seinen Ausgaben zu vertrauen.

Um die Leistung des Modells genau zu evaluieren, müssen Unternehmen mehrere Unterkategorien berücksichtigen, darunter die unten aufgeführten:

1. Modellinterpretierbarkeit: Können die Ausgaben des Modells leicht verstanden und erklärt werden? Ist das Modell transparent und fair?
2. Feature-Wichtigkeit und -Beitrag: Können die Features des Modells nach Wichtigkeit und Beitrag eingestuft werden?
3. Evaluierungsumgebung: Sind die Evaluierungsdaten repräsentativ für die Produktionsdaten und ist die Umgebung der Produktionsumgebung ähnlich?
4. Kontrafaktische Erklärungen: Kann das Modell Erklärungen für kontrafaktische Szenarien liefern?

Modellbereitstellung und -überwachung

Eine effektive Modellbereitstellung und -überwachung kann Organisationen dabei helfen, optimale ML-Test-Scores zu erzielen und sicherzustellen, dass ihre Modelle im Laufe der Zeit weiterhin Wert liefern. Berücksichtigen Sie diese Unterkategorien:

1. Bereitstellungsinfrastruktur: Ist die Bereitstellungsinfrastruktur skalierbar und zuverlässig?
2. A/B-Tests und Experimentieren: Wird das Modell in kontrollierten Experimenten getestet und validiert? Verläuft der Rollout-Prozess des Modells reibungslos, um Ausfallzeiten zu vermeiden?
3. Monitoring und Alerting: Gibt es eine Logging-Infrastruktur? Gibt es Mechanismen zur Überwachung der Modellleistung und zur Alarmierung bei Problemen?
4. Modellaktualisierung: Aktualisiert das System Modelle automatisch, sobald neue Daten und Features verfügbar sind?

Infrastruktur und Betrieb

Wir haben bereits in der Kategorie Training und Leistung über Infrastruktur gesprochen; Infrastruktur spielt nicht nur eine kritische Rolle dabei, sicherzustellen, dass ML-Modelle effizient und genau trainiert werden, sondern auch im Betrieb. Nachfolgend sind die zu berücksichtigenden Unterkategorien aufgeführt:

1. Ressourcenzuweisung und -optimierung: Werden die Ressourcen zugewiesen und optimiert, um die Effizienz zu maximieren und die Kosten zu minimieren?
2. Containerisierung und Orchestrierung: Werden die Container und Dienste auf skalierbare und effiziente Weise verwaltet?
3. Continuous Integration und Deployment: Werden Änderungen am Codebase automatisch getestet, gebaut und bereitgestellt?
4. ROI-Messung: Können Sie die geschäftlichen Auswirkungen des ML-Modells messen, sobald es in der Produktion eingesetzt wird?

Sicherheit, Fehlerbehandlung und Compliance

Dies ist die letzte und eine der wichtigsten Kategorien, unterteilt in die folgenden Unterkategorien:  

1. Zugriffskontrolle und Autorisierung: Sind Zugriffskontrollen und Autorisierungsrichtlinien vorhanden, um vor unbefugtem Zugriff zu schützen?
2. Compliance und regulatorische Anforderungen: Entspricht das System den relevanten Vorschriften und Anforderungen?
3. Fehlerbehandlung und Wiederherstellung: Kann sich das ML-System sauber von Ausfällen erholen und Fehler aufgrund von Drift in den Systemen behandeln?
4. Datenschutz und Verschlüsselung: Werden sensible Daten bei der Übertragung und im Ruhezustand geschützt und verschlüsselt?

Berechnung Ihres ML System Robustness Score

Für die finale Bewertung kann ein Unternehmen ein Bewertungssystem auf einer Skala von 0-4 verwenden. Das Bewertungssystem entspricht der folgenden Tabelle.

1. Ein Wert von <25 bedeutet, dass das ML-System wahrscheinlich nicht bereit ist und viele Herausforderungen angegangen werden müssen.
2. Ein Wert im Bereich von 25-40 ist ein Indikator dafür, dass das aktuelle System ausreichend ist, aber bei einer Skalierung Schwachstellen entstehen könnten.
3. Ein Wert im Bereich von 40+ spiegelt eine Lösung wider, die robust ist und auch bei Skalierung der Systeme funktioniert.
4. Alles über 60 steht für eine erstklassige Best-in-Class-Lösung in Ihrem Unternehmen.

Das Beantworten dieser Fragen und das Durchführen der Tests können eine umfassende Bewertung der Produktionsreife eines ML-Systems liefern sowie potenzielle technische Schulden identifizieren, die während der Entwicklung und Bereitstellung des ML-Systems entstehen können. Durch die frühzeitige Identifizierung dieser Probleme können Schritte unternommen werden, um sie zu mildern oder zu beseitigen, wodurch die technischen Gesamtschulden des Systems reduziert werden.

Bewertung technischer Schulden ähnlich wie bei Softwaresystemen

Während wir die ML-Testrubrik als Grundlage für das obige Bewertungssystem verwenden, gibt es auch andere Frameworks zur Bewertung der Reife von ML-Systemen.

1. Ein älteres Framework ist der Ansatz zum Softwaretest von Machine-Learning-Anwendungen, der von C. Murphy im Jahr 2007 festgelegt wurde und die Bedeutung von Tests und Validierungen während der gesamten Entwicklung und Bereitstellung von ML-Systemen ähnlich wie bei Softwaresystemen betont. Dieser Ansatz kombiniert traditionelle Softwaretestmethoden wie Unit-Tests und Integrationstests mit speziellen ML-Testmethoden wie Modellvalidierung und Datenvalidierung.
2. Ein weiteres neueres Framework wird in den Technology Readiness Levels (TRLs) für Machine-Learning-Systeme vorgeschlagen, die von A. Lavin und Lee im Okt. 2022 vorgestellt wurden. Die TRLs bieten eine systematische und detaillierte Möglichkeit, die Reife und Einsatzbereitschaft von ML-Systemen von der Konzeptphase bis zur Betriebsphase zu bewerten.

Fazit

Zusammenfassend lässt sich sagen, dass die Bewertung der Produktionsreife und der technischen Schulden von ML-Systemen für eine erfolgreiche Bereitstellung und Wartung unerlässlich ist. Der ML Test Score bietet eine umfassende Rubrik zur Bewertung dieser Faktoren und deckt Aspekte wie Datenqualität, Modellleistung, Evaluierungspraktiken, Betrieb und Überwachung ab. Die TRLs für Machine-Learning-Systeme und andere Frameworks können ebenfalls ergänzende Bewertungen der Reife und Einsatzbereitschaft des Systems liefern. Eine kontinuierliche Überwachung und Wartung sowie gründliche Tests und Validierungen sind entscheidend, um technische Schulden zu minimieren und sicherzustellen, dass das ML-System produktionsreif bleibt.

👉

PS: Lassen Sie eine kostenlose Diagnose Ihres ML-Systems durchführen!
Wenn Sie an einer Diagnose Ihrer gesamten ML-Infrastruktur interessiert sind, schreiben Sie uns an founders@truefoundry.com, und wir senden Ihnen einen Vorab-Fragebogen zu; anschließend vereinbaren wir 30 Minuten, um einige Fragen durchzugehen, die uns helfen, das System zu verstehen.

Danach arbeiten wir mit Ihnen zusammen, um Ihnen innerhalb einer Woche eine kostenlose Diagnose und ein Benchmarking Ihres ML-Systems zur Verfügung zu stellen.

Referenzen

1. C. Murphy, G. E. Kaiser, und M. Arias, „An approach to software testing of machine learning applications.“ in SEKE. Citeseer, 2007
2. D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, und M. Young, „Machine learning: The high interest credit card of technical debt,“ in SE4ML: Software Engineering for Machine Learning (NIPS 2014 Workshop), 2014
3. A. Lavin, C. Lee Et Al, „Technology Readiness levels for Machine Learning Systems,“ im Okt. 2022
4. Eric Breck, Shanqing Cai, Eric Nielsen, Michael Salib, D. Sculley Google, Inc, „The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction“, 2017