Von Thomas Pin – Data Scientist

PagerDuty verfügt über ein Frühwarnsystem (EWS), das den Abteilungen Customer Success und Vertrieb hilft, den Gesundheitszustand bestehender PagerDuty Kunden anhand der Produktnutzung und externer Geschäftsfaktoren zu ermitteln. Dieses Frühwarnsystem ist zu einer kritischen Infrastruktur geworden und bildet die erste Verteidigungslinie bei der Erkennung von mangelhafter Produktnutzung, die zu Kundenabwanderung führen kann. Der Erfolg des Frühwarnsystems und die großen Anstrengungen der Abteilung Customer Success haben unsere riskante Produktnutzung reduziert. Bei einem so kritischen Modell in der Produktion ist es von größter Bedeutung, dass es stets genaue Ergebnisse liefert und regelmäßig aktualisiert wird.

Im Januar 2021 veröffentlichte das Frühwarnsystem-Modell aufgrund einer vorgelagerten Änderung einen ungenauen Kundenrisiko-Score. Dieser war einige Tage lang fehlerhaft. Erst als uns einer unserer Customer Success Manager wegen der Verwechslung kontaktierte, konnten wir das Modell sofort diagnostizieren und reparieren. Das Data Platform and Business Intelligence-Team, intern DataDuty genannt, war entschlossen, eine Lösung zu finden, um ähnliche Pannen in Zukunft zu vermeiden.

Das oben aufgeführte Problem betrifft nicht nur PagerDuty. In der Data-Science-Community wäre dies ein Beispiel für Modelldrift und es gibt mehr Formen als nur Upstream-Datenänderungen. Das DataDuty-Team war entschlossen, die Auswirkungen dieses Phänomens durch automatisierte Tests zu minimieren und PagerDuty -Warnmeldungen wenn diese Probleme auftreten.

PagerDuty

Das Produkt von PagerDuty ist das entscheidende Puzzleteil, um proaktiv Modelldrift zu vermeiden. Da Machine-Learning-Modelle mehrere Plattformen nutzen, ist es ohne spezielle Software zur Vorfallstriage wie PagerDuty unmöglich, die Protokolle mehrerer Plattformen zu erfassen, Vorfälle zu erstellen, prioritätsbasiert zu eskalieren und Anwender zu alarmieren. Unabhängig davon, wie robust unsere automatisierten Tests sind, nützt dies nichts, wenn wir die Ergebnisse nicht zur richtigen Zeit an die richtige Person übermitteln können. PagerDuty hat den Erfolg unserer Strategie ermöglicht, und wir konnten schädliche Änderungen erkennen, bevor ein Modellanwender sie bemerkte.

Modelldrift

Modelldrift kann in drei Kategorien unterteilt werden: Konzept, Daten und Upstream, wobei jede Kategorie einen anderen Lösungsansatz erfordert.

Konzept : Definition des Ziels der Modelländerungen

Daten : Signifikante Inputs verlieren ihre Bedeutung

Stromaufwärts : Änderungen der zugrunde liegenden Upstream-Daten

Konzept-Drifttests

Es ist schwierig, einen Test zu schreiben, um Konzeptänderungen zu erkennen, da es sich dabei um ein Konstrukt handelt, das von Datenwissenschaftlern und Stakeholdern entwickelt wurde. Im Fall des Frühwarnsystemmodells ist das Ziel jedoch „Churn“, was eine einfache Definition hat. Bei PagerDuty wird „Churn“ als die Aktivierung oder Deaktivierung eines Kontos definiert, und diese Definition ist unverändert geblieben.

Um zu messen, ob das Frühwarnsystemmodell den Kundenrisikowert richtig vorhersagt, werden einige Komponententests durchgeführt:

1. Vor dem Frühwarnsystem lag die monatliche Abwanderungsrate von PagerDuty zwischen x % und y %. Liegt die monatliche Abwanderungsrate über z %, wird dies als Problem angesehen.
2. Die Gesamtbewertungen des Frühwarnsystems haben sich in den letzten Jahren stabilisiert, wobei die Bewertungen einzelner Konten im Laufe der Zeit steigen oder fallen können. PagerDuty erwartet jedoch, dass 25* % der Konten ein niedriges Kundenrisiko aufweisen, 25* % ein mittleres bis niedriges Kundenrisiko aufweisen, 25* % ein mittleres Kundenrisiko aufweisen und 25* % ein hohes Kundenrisiko aufweisen. * Keine tatsächlichen Zahlen
3. Der monatliche Durchschnittswert des Frühwarnsystems liegt historisch gesehen innerhalb einer Toleranz von 2,5 % des mittleren Frühwarnsystemwerts.

Sollte einer dieser Tests fehlschlagen, würde dies als hohe Priorität eingestuft und PagerDuty würde eine Warnung an einen der diensthabenden Datenwissenschaftler von DataDuty senden, um zu untersuchen, ob die Definition des Modells für „Churn“ zutreffend war und ob eine Aktualisierung erforderlich war.

Datendrifttests

Im Laufe der Zeit können Modellmerkmale für die Bewertung des Frühwarnsystems relevanter oder weniger relevant werden. PagerDuty hat Tests entwickelt, um diese Risiken zu minimieren. Eine der wichtigsten Kennzahlen im letzten Jahr war beispielsweise der Prozentsatz der „bestätigten“ Vorfälle ( Vorfallbestätigungsrate ). Dies war ein relevantes Merkmal für die Vorhersage der Abwanderungswahrscheinlichkeit eines Kontos. Kürzlich wurde jedoch festgestellt, dass die Bestätigungsrate von Vorfällen mit hoher Dringlichkeit war relevanter und ersetzte den ursprünglichen Vorfall Bestätigungsrate PagerDuty führt die folgenden Tests durch, um die Relevanz einer Funktion in unserem Feature Store zu bestimmen:

1. Cohens d schätzt die Effektgröße zwischen zwei Mittelwerten. Die Modell-Engine des Frühwarnsystems basiert auf Merkmalen, die einen signifikanten Abstand zwischen den Mittelwerten der Kundenverteilung und der Verteilung der abgewanderten Kunden aufweisen.
2. Kurtosis misst die „Schwanzigkeit“ zwischen zwei Verteilungen. Der Schwanz der Verteilungen von Kunden und abgewanderten Kunden sollte eine signifikante Lücke aufweisen.
3. Kolmogorov-Smirnov-Test ist ein nichtparametrischer Test auf die Gleichheit kontinuierlicher, eindimensionaler Wahrscheinlichkeitsverteilungen, der zum Vergleich einer Stichprobe mit einer Referenzwahrscheinlichkeitsverteilung oder zum Vergleich zweier Stichproben verwendet werden kann. Das Frühwarnsystemmodell vergleicht die beiden Verteilungen für Kunden und abgewanderte Kunden.
4. T-Test ist eine Inferenzstatistik, die verwendet wird, um zu bestimmen, ob ein signifikanter Unterschied zwischen den Mittelwerten zweier Gruppen besteht und wie diese miteinander zusammenhängen. Wenn alles andere fehlschlägt, berechnen Sie die Signifikanz für Merkmale.

Die Funktionen sollten innerhalb der festgelegten Grenzwerte bleiben. Andernfalls erstellt PagerDuty einen Vorfall und weist ihn einem der diensthabenden Datenwissenschaftler von DataDuty zu, der die Diskrepanz untersucht. Darüber hinaus werden diese Kennzahlen vierteljährlich überprüft, um zu prüfen, ob dem Frühwarnsystemmodell eine neue Funktion hinzugefügt werden sollte.

Upstream-Datendrift

Dem Frühwarnsystemmodell vorgelagert sind die aggregierten Datentabellen, die relevante Messdaten für eine mögliche Verwendung speichern. Derzeit gibt es neun zu überwachende Hauptaggregattabellen sowie über fünfzig Basistabellen, aus denen die Aggregattabellen schöpfen. Um die Datenintegrität und Verfügbarkeit zu gewährleisten, umfasst der PagerDuty Technologie-Stack: Snowflake zur Datenspeicherung, Monte Carlo zur Aufrechterhaltung der Datenintegrität, Apache Airflow zur Jobplanung, Databricks zum Erstellen und Durchführen von Experimenten mit dem Modell und PagerDuty zur Vorfallstriage bei auftretenden Problemen. Wenn beispielsweise eine „falsche Datenlast“ das Frühwarnsystemmodell beeinträchtigt, erstellt PagerDuty einen Vorfall und benachrichtigt den diensthabenden Dateningenieur von DataDuty.

PagerDuty und Modelldrift-Beispiel

Das Folgende ist ein reales Beispiel für einen PagerDuty Alarm, den ein Mitglied des DataDuty-Teams während seiner Bereitschaft erhielt.

Der Datenwissenschaftler erhielt als Erster eine Warnung, dass mit den Werten des Frühwarnsystem-Modells möglicherweise etwas nicht stimmte, da diese Tests zur Erfassung von Konzeptdrift konzipiert waren. Die Ursache des Problems war die Quelle „ews_unittest“, in der die Modelldrifttests gespeichert sind. Anschließend überprüfte der Datenwissenschaftler den failed_text und stellte fest, dass alle Kundenrisiko-Score-Zuweisungen unter den erwarteten Toleranzen lagen und eine der Metriken keine große Variation aufwies. Aus Erfahrung schloss der Datenwissenschaftler, dass die Metrik im failed_text höchstwahrscheinlich „auf Null“ gesetzt wurde, weil die Aggregattabelle nicht aktualisiert wurde. Nach einigen Minuten der Untersuchung bestätigte sich, dass dies die Ursache des Problems war. Er wies den Vorfall einem Dateningenieur zu und fügte einen Hinweis hinzu, die Aggregattabelle, aus der die problematische Metrik stammte, neu zu laden und die Modellberechnungen erneut auszuführen. Innerhalb von 30 Minuten gab das Modell „Entwarnung“, und die korrekten Werte wurden in die Produktion übernommen, bevor einer der Customer Success Manager das Problem bemerkte. Dank dieser automatisierten Tests und PagerDuty gelang es dem DataDuty-Team, den Vorfall zu diagnostizieren und zu beheben, bevor er den Betrieb der Organisation beeinträchtigte, und zwar mit minimaler Unterbrechung der täglichen Arbeit des Dateningenieurs und Datenwissenschaftlers von DataDuty.

Wenn Data-Science-Modelle zu einer kritischen Infrastruktur für ein Unternehmen werden, in dem Genauigkeit und Verfügbarkeit entscheidend sind, sollten Data-Science-Teams Tests einführen, die Modellabweichungen überwachen und die entsprechenden Stakeholder bei ersten Anzeichen von Problemen alarmieren. Vertrauen unter den Datenmodell-Anwendern ist entscheidend für den Erfolg von Business-Machine-Learning-Modellen. Wie Kevin Plank einmal sagte: „Vertrauen wird tröpfchenweise aufgebaut und eimerweise verloren.“ Lassen Sie also nicht zu, dass Modellabweichungen das Vertrauen in Ihre Modelle beeinträchtigen.