Testansätze für Amazon SageMaker ML-Modelle

Neuauflage von Plato

Verfolger: 0

Dieser Beitrag wurde gemeinsam mit Tobias Wenzel, Software Engineering Manager für die Intuit Machine Learning Platform, verfasst.

Wir alle wissen um die Bedeutung eines qualitativ hochwertigen und zuverlässigen Modells für maschinelles Lernen (ML), beispielsweise beim autonomen Fahren oder bei der Interaktion mit Alexa. ML-Modelle spielen auch auf weniger offensichtliche Weise eine wichtige Rolle – sie werden von Geschäftsanwendungen, dem Gesundheitswesen, Finanzinstituten, amazon.com, TurboTax und mehr verwendet.

Da ML-fähige Anwendungen zum Kernstück vieler Unternehmen werden, müssen Modelle der gleichen Kraft und Disziplin folgen wie Softwareanwendungen. Ein wichtiger Aspekt von MLOps besteht darin, eine neue Version des zuvor entwickelten ML-Modells in der Produktion bereitzustellen, indem etablierte DevOps-Praktiken wie Tests, Versionierung, kontinuierliche Bereitstellung und Überwachung verwendet werden.

Es gibt mehrere präskriptiv Richtlinien rund um MLOps, und dieser Beitrag gibt einen Überblick über den Prozess, dem Sie folgen können, und welche Tools Sie zum Testen verwenden sollten. Dies basiert auf Kooperationen zwischen Intuit und AWS. Wir haben zusammengearbeitet, um die in diesem Beitrag erläuterten Empfehlungen in die Praxis und in großem Umfang umzusetzen. Intuits Ziel, ein KI-gesteuerte Expertenplattform hängt stark von einer Strategie ab, die Geschwindigkeit der anfänglichen Modellentwicklung sowie das Testen neuer Versionen zu erhöhen.

Voraussetzungen:

Im Folgenden sind die Hauptbereiche aufgeführt, die bei der Bereitstellung neuer Modellversionen zu berücksichtigen sind:

Modellgenauigkeitsleistung - Es ist wichtig, dass Bleib dran von Modellbewertungsmetriken wie Genauigkeit, Präzision und Wiedererkennungswert, und stellen Sie sicher, dass die objektiven Metriken relativ gleich bleiben oder sich mit einer neuen Version des Modells verbessern. In den meisten Fällen ist die Bereitstellung einer neuen Version des Modells nicht sinnvoll, wenn sich die Erfahrung der Endbenutzer nicht verbessert.
Testen Sie die Datenqualität – Daten in Nicht-Produktionsumgebungen, ob simuliert oder Point-in-Time-Kopie, sollten in Bezug auf Volumen oder Verteilung repräsentativ für die Daten sein, die das Modell bei vollständiger Bereitstellung erhält. Andernfalls sind Ihre Testprozesse nicht repräsentativ und Ihr Modell kann sich in der Produktion anders verhalten.
Merkmalswichtigkeit und -parität – Die Bedeutung der Funktionen in der neueren Version des Modells sollte relativ zum älteren Modell vergleichbar sein, obwohl möglicherweise neue Funktionen eingeführt werden. Dadurch soll sichergestellt werden, dass das Modell nicht verzerrt wird.
Testen von Geschäftsprozessen – Es ist wichtig, dass eine neue Version eines Modells Ihre erforderlichen Geschäftsziele innerhalb akzeptabler Parameter erfüllen kann. Eine der Geschäftsmetriken kann beispielsweise sein, dass die End-to-End-Latenz für einen Dienst nicht mehr als 100 Millisekunden betragen darf oder dass die Kosten für das Hosten und Umschulen eines bestimmten Modells nicht mehr als 10,000 US-Dollar pro Jahr betragen dürfen.
Kosten – Ein einfacher Testansatz besteht darin, die gesamte Produktionsumgebung als Testumgebung zu replizieren. Dies ist eine gängige Praxis in der Softwareentwicklung. Ein solcher Ansatz im Fall von ML-Modellen ergibt jedoch je nach Datengröße möglicherweise nicht den richtigen ROI und kann das Modell in Bezug auf das Geschäftsproblem, das es angeht, beeinflussen.
Sicherheit – Von Testumgebungen wird oft erwartet, dass sie Beispieldaten anstelle von echten Kundendaten enthalten, und daher können die Datenhandhabungs- und Compliance-Regeln weniger streng sein. Genau wie die Kosten könnten Sie jedoch Sicherheits- und Compliance-Risiken einführen, wenn Sie die Produktionsumgebung einfach in eine Testumgebung duplizieren.
Skalierbarkeit des Feature-Stores – Wenn eine Organisation aus Kosten- oder Sicherheitsgründen beschließt, keinen separaten Testfunktionsspeicher zu erstellen, müssen die Modelltests im Produktionsfunktionsspeicher durchgeführt werden, was zu Skalierbarkeitsproblemen führen kann, da der Datenverkehr während des Testzeitraums verdoppelt wird.
Online-Modellleistung – Online-Bewertungen unterscheiden sich von Offline-Bewertungen und können in einigen Fällen wie Empfehlungsmodelle wichtig sein, da sie die Benutzerzufriedenheit in Echtzeit und nicht die wahrgenommene Zufriedenheit messen. Aufgrund von Saisonabhängigkeit oder anderem Benutzerverhalten ist es schwierig, echte Verkehrsmuster außerhalb der Produktion zu simulieren, sodass die Onlinemodellleistung nur in der Produktion erfolgen kann.
Betriebliche Leistung – Da Modelle immer größer werden und zunehmend dezentral auf unterschiedlicher Hardware bereitgestellt werden, ist es wichtig, das Modell auf die gewünschte Betriebsleistung wie Latenz, Fehlerrate und mehr zu testen.

Die meisten ML-Teams verfolgen einen mehrgleisigen Ansatz für das Testen von Modellen. In den folgenden Abschnitten bieten wir Möglichkeiten, diese Herausforderungen in verschiedenen Testphasen anzugehen.

Offline-Modelltests

Das Ziel dieser Testphase ist es, neue Versionen eines bestehenden Modells hinsichtlich Genauigkeit zu validieren. Dies sollte offline erfolgen, um keine Vorhersagen im Produktionssystem zu beeinträchtigen, die Echtzeitvorhersagen bereitstellen. Indem sichergestellt wird, dass das neue Modell für anwendbare Bewertungsmetriken besser abschneidet, adressiert dieser Test Herausforderung 1 (Modellgenauigkeitsleistung). Durch die Verwendung des richtigen Datensatzes können diese Tests auch die Herausforderungen 2 und 3 (Qualität der Testdaten, Wichtigkeit der Merkmale und Parität) angehen, mit dem zusätzlichen Vorteil, Herausforderung 5 (Kosten) anzugehen.

Diese Phase wird in der Staging-Umgebung durchgeführt.

Sie sollten den Produktionsdatenverkehr erfassen, den Sie zur Wiedergabe in Offline-Backtests verwenden können. Es ist vorzuziehen, früheren Produktionsdatenverkehr anstelle von synthetischen Daten zu verwenden. Das Amazon SageMaker-Modellmonitor Datenerfassungsfunktion ermöglicht es Ihnen, den Produktionsdatenverkehr für gehostete Modelle zu erfassen Amazon Sage Maker. Auf diese Weise können Modellentwickler ihre Modelle mit Daten von Spitzengeschäftstagen oder anderen wichtigen Ereignissen testen. Die erfassten Daten werden dann stapelweise mit der neuen Modellversion wiedergegeben Sagemaker-Batch-Transformation. Das bedeutet, dass der Batch-Transformationslauf in nur wenigen Stunden Tests mit Daten durchführen kann, die über Wochen oder Monate gesammelt wurden. Dies kann den Modellbewertungsprozess erheblich beschleunigen, verglichen mit der Ausführung von zwei oder mehr Versionen eines Echtzeitmodells nebeneinander und dem Senden doppelter Vorhersageanforderungen an jeden Endpunkt. Neben der schnelleren Suche nach einer leistungsstärkeren Version werden bei diesem Ansatz auch die Rechenressourcen für einen kürzeren Zeitraum verwendet, wodurch die Gesamtkosten gesenkt werden.

Eine Herausforderung bei diesem Testansatz besteht darin, dass sich der Funktionsumfang von einer Modellversion zur anderen ändert. In diesem Szenario empfehlen wir, ein Feature-Set mit einer Obermenge von Features für beide Versionen zu erstellen, damit alle Features auf einmal abgefragt und durch die Datenerfassung aufgezeichnet werden können. Jeder Vorhersageaufruf kann dann nur an den Funktionen arbeiten, die für die aktuelle Version des Modells erforderlich sind.

Als zusätzlichen Bonus durch die Integration Amazon SageMaker klären In Ihren Offline-Modelltests können Sie die neue Version des Modells auf Verzerrungen überprüfen und auch die Merkmalszuordnung mit der vorherigen Version des Modells vergleichen. Mit Pipelines können Sie den gesamten Workflow so orchestrieren, dass nach dem Training ein Qualitätsprüfungsschritt stattfinden kann, um eine Analyse der Modellmetriken und der Wichtigkeit der Funktionen durchzuführen. Diese Metriken werden in gespeichert SageMaker-Modellregistrierung zum Vergleich im nächsten Trainingslauf.

Integrations- und Leistungstests

Integrationstests sind erforderlich, um End-to-End-Geschäftsprozesse sowohl aus funktionaler als auch aus Laufzeitleistungsperspektive zu validieren. Innerhalb dieses Prozesses sollte die gesamte Pipeline getestet werden, einschließlich Abrufen und Berechnen von Features im Feature Store und Ausführen der ML-Anwendung. Dies sollte mit einer Vielzahl unterschiedlicher Payloads erfolgen, um eine Vielzahl von Szenarien und Anforderungen abzudecken und eine hohe Abdeckung für alle möglichen Codeläufe zu erreichen. Dies adressiert die Herausforderungen 4 und 9 (Testen von Geschäftsprozessen und Betriebsleistung), um sicherzustellen, dass keiner der Geschäftsprozesse mit der neuen Version des Modells unterbrochen wird.

Diese Tests sollten in einer Staging-Umgebung durchgeführt werden.

Sowohl Integrationstests als auch Leistungstests müssen von einzelnen Teams mithilfe ihrer MLOps-Pipeline implementiert werden. Für die Integrationstests empfehlen wir die bewährte Methode, eine funktional gleichwertige Vorproduktionsumgebung aufrechtzuerhalten und mit wenigen unterschiedlichen Payloads zu testen. Der Testablauf kann wie in gezeigt automatisiert werden diese Werkstatt. Für den Leistungstest können Sie verwenden Amazon SageMaker Inference Recommender, die einen guten Ausgangspunkt bietet, um zu bestimmen, welcher Instance-Typ und wie viele dieser Instances verwendet werden sollen. Dazu müssen Sie ein Lastgenerator-Tool verwenden, z. B. die Open-Source-Projekte perfsizesagemaker und Lochgröße die Intuit entwickelt hat. Perfsizesagemaker ermöglicht Ihnen das automatische Testen von Modell-Endpunktkonfigurationen mit einer Vielzahl von Nutzlasten, Reaktionszeiten und Anforderungen an Spitzentransaktionen pro Sekunde. Es generiert detaillierte Testergebnisse, die verschiedene Modellversionen vergleichen. Perfsize ist das begleitende Tool, das verschiedene Konfigurationen ausprobiert, wobei nur die Spitzentransaktionen pro Sekunde und die erwartete Reaktionszeit angegeben werden.

A / B-Tests

In vielen Fällen, in denen eine Benutzerreaktion auf die sofortige Ausgabe des Modells erforderlich ist, wie z. B. bei E-Commerce-Anwendungen, ist die funktionale Bewertung des Offline-Modells nicht ausreichend. In diesen Szenarien müssen Sie Modelle in der Produktion A/B testen, bevor Sie die Entscheidung treffen, Modelle zu aktualisieren. A/B-Tests haben auch ihre Risiken, da es zu echten Kundenauswirkungen kommen kann. Diese Testmethode dient als abschließende ML-Leistungsvalidierung, eine Plausibilitätsprüfung des Leichtbaus. Diese Methode adressiert auch die Herausforderungen 8 und 9 (Online-Modellleistung und operative Exzellenz).

A/B-Tests sollten in einer Produktionsumgebung durchgeführt werden.

Mit SageMaker können Sie ganz einfach A/B-Tests an ML-Modellen durchführen, indem Sie es ausführen mehrere Fertigungsvarianten auf einem Endpunkt. Der Datenverkehr kann schrittweise an die neue Version weitergeleitet werden, um das Risiko zu verringern, dass ein sich schlecht verhaltendes Modell die Produktion beeinträchtigen könnte. Wenn die Ergebnisse des A/B-Tests gut aussehen, wird der Datenverkehr an die neue Version weitergeleitet, die schließlich 100 % des Datenverkehrs übernimmt. Wir empfehlen die Verwendung von Deployment Guardrails für den Übergang von Modell A zu B. Für eine umfassendere Diskussion über die Verwendung von A/B-Tests Amazon personalisieren Modelle als Beispiel finden Sie unter Verwenden von A / B-Tests zur Messung der Wirksamkeit von Empfehlungen, die von Amazon Personalize generiert wurden.

Online-Modelltest

In diesem Szenario unterscheidet sich die neue Version eines Modells erheblich von derjenigen, die bereits Live-Traffic in der Produktion bedient, sodass der Offline-Testansatz nicht mehr geeignet ist, um die Wirksamkeit der neuen Modellversion zu bestimmen. Der wichtigste Grund dafür ist eine Änderung der Merkmale, die zur Erstellung der Vorhersage erforderlich sind, sodass zuvor aufgezeichnete Transaktionen nicht zum Testen des Modells verwendet werden können. In diesem Szenario empfehlen wir die Verwendung von Schattenbereitstellungen. Schattenbereitstellungen bieten die Möglichkeit, eine Schatten- (bzw Herausforderer) Modell neben der Produktion (bzw Champion)-Modell, das derzeit Vorhersagen bereitstellt. Auf diese Weise können Sie die Leistung des Schattenmodells im Produktionsdatenverkehr bewerten. Die Vorhersagen des Schattenmodells werden der anfordernden Anwendung nicht bereitgestellt; Sie werden für die Offline-Auswertung protokolliert. Mit dem Schattenansatz zum Testen gehen wir die Herausforderungen 4, 5, 6 und 7 an (Testen von Geschäftsprozessen, Kosten, Sicherheit und Skalierbarkeit des Funktionsspeichers).

Online-Modelltests sollten in Staging- oder Produktionsumgebungen durchgeführt werden.

Diese Methode zum Testen neuer Modellversionen sollte als letzter Ausweg verwendet werden, wenn alle anderen Methoden nicht verwendet werden können. Wir empfehlen dies als letzten Ausweg, da das Duplexing von Aufrufen an mehrere Modelle eine zusätzliche Last für alle nachgelagerten Dienste in der Produktion erzeugt, was zu Leistungsengpässen sowie erhöhten Kosten in der Produktion führen kann. Die offensichtlichste Auswirkung hat dies auf der Feature-Serving-Schicht. Für Anwendungsfälle, die Funktionen aus einem gemeinsamen Pool physischer Daten gemeinsam nutzen, müssen wir in der Lage sein, mehrere Anwendungsfälle zu simulieren, die gleichzeitig auf dieselbe Datentabelle zugreifen, um sicherzustellen, dass vor dem Übergang in die Produktion keine Ressourcenkonflikte bestehen. Wo immer möglich, sollten doppelte Abfragen an den Feature Store vermieden werden, und Features, die für beide Versionen des Modells benötigt werden, sollten für die zweite Inferenz wiederverwendet werden. Feature-Stores basierend auf Amazon DynamoDB, wie es Intuit gebaut hat, implementieren kann Amazon DynamoDB-Beschleuniger(DAX) zwischenspeichern und eine Verdopplung der E/A an die Datenbank vermeiden. Diese und andere Caching-Optionen können Herausforderung 7 (Skalierbarkeit des Funktionsspeichers) entschärfen.

Um Herausforderung 5 (Kosten) sowie 7 zu bewältigen, schlagen wir vor, Schattenbereitstellungen zu verwenden, um den eingehenden Datenverkehr zu testen. Dies gibt Modellbesitzern eine weitere Kontrollebene, um die Auswirkungen auf die Produktionssysteme zu minimieren.

Die Shadow-Bereitstellung sollte in die integriert werden Modellmonitor Angebote genau wie die regulären Produktionsbereitstellungen, um die Verbesserungen der Challenger-Version zu beobachten.

Zusammenfassung

Dieser Beitrag veranschaulicht die Bausteine zum Erstellen eines umfassenden Satzes von Prozessen und Tools, mit denen verschiedene Herausforderungen beim Modelltesten angegangen werden können. Obwohl jede Organisation einzigartig ist, sollte Ihnen dies beim Einstieg helfen und Ihre Überlegungen bei der Implementierung Ihrer eigenen Teststrategie eingrenzen.

Über die Autoren

Tobias Wenzel ist Software Engineering Manager für die Intuit Machine Learning Platform in Mountain View, Kalifornien. Er arbeitet seit ihrer Gründung im Jahr 2016 an der Plattform und hat sie von Grund auf mitgestaltet und aufgebaut. In seinem Job hat er sich auf die operative Exzellenz der Plattform konzentriert und sie erfolgreich durch das saisonale Geschäft von Intuit gebracht. Darüber hinaus ist er leidenschaftlich daran interessiert, die Plattform kontinuierlich mit den neuesten Technologien zu erweitern.

Shivanshu Upadhyay ist Principal Solutions Architect in der Gruppe AWS Business Development and Strategic Industries. In dieser Funktion hilft er den fortgeschrittensten Anwendern von AWS, ihre Branche durch die effektive Nutzung von Daten und KI zu transformieren.

Alan Tan ist Senior Product Manager bei SageMaker und leitet die Bemühungen zur Inferenz großer Modelle. Er setzt sich leidenschaftlich für die Anwendung von maschinellem Lernen im Bereich Analytics ein. Außerhalb der Arbeit genießt er die Natur.