Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

IT-Security

Produktentwicklung

Weitere Leistungen...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Consultant Data & AI

ITSpektrum

Künstliche Intelligenz

KI von der Stange – ein Beispiel aus der Industrie. KI-out-of-the-box-Lösungen gezielt einsetzen

Für das ITSpektrum hat Berthold Schulte untersucht, wie sich KI-Lösungen gezielt in der Industrie einsetzen lassen.

KI von der Stange – ein Beispiel aus der Industrie. 

Machine-Learning-Modelle bewerten – die Crux mit der Metrik

<p><br /> Machine-Learning-Technologien lassen sich erfolgreich und praxisnah im Unternehmensumfeld einsetzen. Ein konkreter, überschaubarer Anwendungsfall und somit fokussierter Einsatz von Machine-Learning-Modellen kann dabei echten Mehrwert generieren. Dieser Mehrwert hängt natürlich vom Anwendungsfall und der Performance der trainierten Modelle ab. Das heisst, es gilt zu klären wie gut ein Modell die jeweilige Herausforderung eigentlich unterstützten kann. In diesem Artikel möchte ich daher erläutern, wie sich die Bewertung der Performance gestaltet, insbesondere abhängig davon wie viele Testdaten überhaupt zur Verfügung stehen oder stehen sollten.</p><h2>Testdatenumfang</h2><p>Mit Hilfe eines zurückbehaltenen repräsentativen Test-Sets und verschiedener Metriken lassen sich Scores berechnen und die Modelle bewerten sowie vergleichen. Das Test-Set wird dabei vor dem Training zurückgelegt und zur Optimierung des Models weitere Validierung-Sets aus den verbleibenden Daten erzeugt.<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EW7apzh9Qnu6zlijabfR"><img width="916" height="439" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EW7apzh9Qnu6zlijabfR" alt="Train-Test-Split beim trainieren von Machine Learning Modellen" /></a> <br /> Sind für den jeweiligen Anwendungsfall sinnvolle Metriken gefunden und zu erreichende Zielwerte definiert, stellt sich die Frage, inwieweit man den erreichten Werten eigentlich vertrauen kann. Schließlich können diese nur auf einer reduzierten Menge von Beispieldaten basieren. Wie viele Testdaten nun für eine aussagekräftige Bewertung nötig sind hängt von dem zu erreichenden Score und dem gewünschten Vertrauen in die Bewertung ab.<br /> Allerdings sind für das Sammeln und im Falle des Supervised Learning, das Labeln der Daten, oft manuelle Schritte nötig und stellen unter Umständen einen nicht zu unterschätzende Kostenfaktor dar. Das heisst, es gilt einen guten Trade-Off zwischen Vertrauen in die Bewertung und den zu erwartenden Kosten für das Sammeln und Aufbereiten der Testdaten zu finden.</p><h2>Anwendungsfall</h2><p>Zur weiteren Erläuterung greife ich auf das Beispiel des Artikels: <a href="/wissens-hub/blog/machine-learning-modelle-bewerten-die-crux-mit-der-metrik" target="_blank">Machine Learning Modelle bewerten – die Crux mit der Metrik</a>  zurück.</p><p>„<em>Ein Hersteller von Trinkgläsern möchte in seiner Produktion defekte Gläser erkennen und aussortieren. Dazu soll ein Modell zur Bildklassifikation trainiert und eingesetzt werden. Die Datenbasis besteht aus Bildern von unversehrten und defekten Gläsern.</em>“ <a href="/wissens-hub/blog/machine-learning-modelle-bewerten-die-crux-mit-der-metrik" target="_blank">[1]</a> </p><p>Die Anzahl der Bilder von defekten Gläsern sei hier sehr beschränkt, so dass mit gewissem Aufwand erst nach einiger Zeit Bilder von ca. 500 unversehrten und 500 defekten Gläsern zum Training und Testen der Modelle zur Verfügung stehen – insbesondere weil defekte Gläser in der Produktion eher selten auftreten. Aus diesen 1000 Bildern wird dann ein repräsentatives Test-Set vor dem Training zurückgelegt.</p><p>Wieviele Testdaten sind nun für eine aussagekräftige Bewertung nötig? Bzw. was bedeutet aussagekräftig in diesem Zusammenhang? Sind 10 % bis 20 % der Datenbasis in diesem Falle 100 bis 200 Bilder ausreichend?<br /> Sei nun in diesem Beispiel die Metrik <em>Accuracy</em> gewählt und das Modell erreicht nach ein wenig Training und Optimierung eine Performance von 80 % korrekter Klassifizierungen – auf einer Basis von 100 Testbildern.<br /> Zur Abschätzung wie vertrauenswürdig dieses Ergebnis eigentlich ist, können Bordmittel der Statistik zum Einsatz kommen.</p><h2>Vertrauensbereich</h2><p>Ob ein Bild vom Modell richtig bewertet wurde oder nicht, lässt sich als ein Experiment mit den zwei möglichen Ergebnissen <em>Erfolg</em> oder <em>Misserfolg</em> auffassen. Das Testen eines Models ist ferner eine Serie von gleichartigen unabhängigen Versuchen, so dass die Binominalverteilung bzw. deren Annäherung <a href="https://de.wikipedia.org/wiki/Satz_von_Moivre-Laplace" target="_blank">[2]</a>  an die Normalverteilung zur Einschätzung des Ergebnisses anwendbar ist.<br /> Inwieweit man nun dem ermittelten Wert „vertrauen“ kann, lässt sich mit Hilfe eines Vertrauensbereichs, dem Konfidenzintervall, darstellen.<br /> Der Nutzen eines Konfidenzintervalles liegt in der Möglichkeit, die Unsicherheit einer Stichprobe, beispielsweise ein Testlauf auf 100 Bildern, und der daraus resultierenden Schätzung zu quantifizieren. Schätzung deshalb, weil die Testdaten nur einen kleinen Teil der möglichen Datenmenge bzw. Grundgesamtheit darstellen und somit das Modell nur mit einem kleinem Teil von Daten und nicht mit allen jemals möglicherweise vorkommenden Daten getestet wurde.</p><p>„<em>Das Konfidenzintervall gibt den Bereich an, der bei unendlicher Wiederholung eines Zufallsexperiments mit einer gewissen Wahrscheinlichkeit (dem Konfidenzniveau) die wahre Lage des Parameters einschließt.</em>“ <a href="https://de.wikipedia.org/wiki/Konfidenzintervall" target="_blank">[3]</a> </p><p>Die Darstellung des Intervalls erfolgt dabei mit Hilfe eines unteren und oberen Grenzwertes und der Annahme die Testläufe seien ziemlich oft auf verschiedenen unabhängigen Testdaten-Sets gleicher Größe wiederholt worden. Sodass beispielsweise im Mittel in 95 % der gedachten Testdurchläufe die resultierenden Grenzwerte den ermittelten Score einschließen.</p><h2>Intervalle berechnen</h2><p>Die Grenzwerte lassen sich beispielsweise wie folgt berechnen <a href="https://de.wikipedia.org/wiki/Konfidenzintervall_für_die_Erfolgswahrscheinlichkeit_der_Binomialverteilung" target="_blank">[4]</a> :</p><p><img height="75" width="242" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Vpfu08UoQ6iTlqZ1OfUB" alt="Konfidenzintervall"/> </p><p>Wobei <em>p=1/Score</em>, <em>n</em> die Anzahl der Daten und <em>z</em> eine Konstante ist, die für das gewünschte „Vertrauen“ (Konfidenzniveau), aus der Standardnormalverteilungstabelle abgelesen werden kann. Gängige Werte sind beispielsweise:</p><table><tr><td><strong>Niveau</strong></td><td>90 %</td><td>95 %</td><td>97 %</td><td>99 %</td><td>99,5 %</td></tr><tr><td><strong>z</strong></td><td>1,28</td><td>1,64</td><td>1,96</td><td>2,33</td><td>2,58</td></tr></table><p>Das heisst, für das Konfidenzniveau 95 % ergibt sich bei 100 Testdatensätze und einem gemessenen Score des Modells von 80 % das Intervall: 72 % bis 88 %. Diese Spanne ist schon recht groß und für manche Anwendungsfälle wohl nicht genau genug.</p><h2>Die Crux</h2><p>Aber selbst bei der Verdoppelung der Testdaten auf 200 Datensätze ist das resultierende Intervall: 74 % bis 86 % nicht viel kleiner. Im folgenden Diagramm sind für das Konfidenzniveau 95 % ein paar weitere Beispiele für die Accuracy Scores von 80 %, 90 %, 95 % und 99 % sowie für die Testdatengröße 100, 200, 1000, 10000 dargestellt. Ab 10000 Datensätze berechnet sich ein Rahmen von +-1% und ist vielleicht akzeptabel für eine Score von 80 %.<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6pPbgPlvS8qI2Po6GjXE"><img loading="lazy" width="700" height="502" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6pPbgPlvS8qI2Po6GjXE" alt="Machine Learning Modelle testen – Intervalle pro Score und Test-Set Größe" /></a> </p><p>Allerdings berechnet sich für ein Ergebnis von 85 % auf Basis von 100 Testdaten das Intervall zu 78 % bis 92 %. Es überdeckt damit auch einen Wert von 80 %. Das legt den Gedanken nahe, dass es unter Umständen möglich ist, mit weniger Trainingsdaten zu arbeiten und das Testdaten-Set besser auszustatten. Es ist schließlich möglich, dass bei einem schlechteren Score, beispielsweise durch ein Training auf weniger Daten, die Grenzwerte des Konfidenzintervalles den ursprünglich besseren Score immer noch mit einschließen.<br /> Ferner kann das Fokussieren auf die letzten Promille Verbesserung, ermittelt auf Basis einen kleines Tests-Sets, ein nicht zielführendes Unterfangen sein. Oder gar der Effekt eintreten, dass nach Aufstockung der Testdaten ein vorher vielleicht nicht so gut erscheinendes Modell besser abschneidet, als das durch einen unwesentlich höhere Score ursprünglich präferierte.<br /> Das heisst, eine Aussage über die Performance des Modells und Abgrenzung gegenüber anderen Modellen auf Basis einer überschaubaren Anzahl von Testdaten ist nur bedingt möglich.<br /> Allgemein gilt: Je größer die Stichprobe, aus der die Schätzung gezogen wurde, desto präziser ist die Schätzung und desto kleiner und besser das Konfidenzintervall.</p><h2>Fazit</h2><p>Letztendlich sollte die Bewertung eines Modells mit Augenmaß erfolgen und die Größe eines Test-Sets in die Bewertung mit einfließen. Gerade bei Ergebnissen, die sich nicht wesentlich unterscheiden, muss die Auswahl eines Modells nur anhand dieser Bewertungen nicht immer erfolgsvorsprechend sein. Ein Feldtest von mehreren, nicht eindeutig abgrenzbaren Modellen in der Praxis, beispielsweise durch A/B-Testing, kann dabei eine Entscheidung unterstützen.</p><h2>Referenzen:</h2><p>[1] codecentric blog, <a href="/wissens-hub/blog/machine-learning-modelle-bewerten-die-crux-mit-der-metrik" target="_blank">Machine Learning Modelle bewerten – die Crux mit der Metrik</a> <br /> [2] Wikipedia, <a href="https://de.wikipedia.org/wiki/Satz_von_Moivre-Laplace" target="_blank">Satz von Moivre-Laplace</a> <br /> [3] Wikipedia, <a href="https://de.wikipedia.org/wiki/Konfidenzintervall" target="_blank">Konfidenzintervall</a> <br /> [4] Wikipedia, <a href="https://de.wikipedia.org/wiki/Konfidenzintervall_für_die_Erfolgswahrscheinlichkeit_der_Binomialverteilung" target="_blank">Konfidenzintervall für die Erfolgswahrscheinlichkeit der Binomialverteilung</a> </p>

Machine-Learning-Modelle bewerten – die Crux mit den Testdaten

<p>Die Qualität bzw. Nützlichkeit von Machine-Learning-Modellen lässt sich mit Hilfe von Testdaten und Metriken bewerten. Allerdings in welchem Umfang? Manuell, automatisiert, einmalig, regelmäßig? Manuell lassen sich die ersten Modelle als Ergebnis eines Proof of Concepts sicherlich noch überschaubar bewerten und vergleichen. Steigt die Anzahl der Modelle je nach Anwendungsfall in die Dutzende oder gar Hunderte und sind diese zudem noch beständig neu zu trainieren, skaliert das manuelle Vorgehen eher nicht mehr.<br /> Die Vorbereitung der Daten, das Training der Modelle sowie deren Bewertung lässt sich in Form von Machine-Learning-Pipelines automatisieren. Eine qualifizierte Bewertung der Daten oder eine Bewertung der Vorhersagegüte eines Modells hat aber seine Tücken – insbesondere in automatisierter Form.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/u1DthoCTBaUSlhtMWTqM"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/u1DthoCTBaUSlhtMWTqM" alt="Beispiel einer einfachen Machine-Learning Pipeline" width="1024" height="290" /></a> <p>Beispiel einer einfachen Machine-Learning-Pipeline</p></div><p>In der klassischen Softwareentwicklung haben sich zur Qualitätssicherung Unit-Test, Integration-Test, End2End-Tests etc. innerhalb von CI/CD-Pipelines etabliert. Bei der Erstellung von Machine-Learning-Modellen sind ebenso Maßnahmen nötig. Diese könne den Prozess vom Aufarbeiten der Rohdaten bis zum Ausliefern eines Modells begleiten und die Qualität eines Modells gewährleisten.</p><h2>Quality Gate</h2><p>Der Begriff ‚Quality Gate‘ stammt aus dem Projektmanagement und beschreibt die Einführungen von ‚Prüfpunkten‘ in den Projektablauf. Ziel ist es, die Projektlaufzeit in kürzere, überschaubare Abschnitte einzuteilen, um somit den Fortschritt nachhalten zu können. Dabei sind vorab pro Gate prüfbare Erfolgskriterien festzulegen.<br /> Ein Gate beinhaltet beispielsweise eine Liste von Zielen oder Qualitätsansprüchen an die resultierenden Artefakte am Ende einer Projektphase. Diese müssen erfüllt sein, bevor der nächste Abschnitt im Prozessablauf gestartet wird. Gegebenenfalls kann es beim Prüfen des Status allerdings auch zum Abbruch des Projekts kommen. Denn es wird transparent, dass wesentliche Eigenschaften nicht erreicht wurden oder sehr wahrscheinlich auch gar nicht mehr erreicht werden. Durch einen frühzeitigen Stopp eines Projekts lassen sich somit unter Umständen auch Zeit, Ressourcen und Geld sparen.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/PacRfeuTgGG1JYoDV8fB"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/PacRfeuTgGG1JYoDV8fB" alt="Quality Gates im Projektablauf" width="1024" height="368" /></a> <p>Quality-Gates im Projektablauf</p></div><p>Im Machine-Learning-Kontext können Quality Gates als dezidierte Checks zwischen den einzelnen Schritten einer automatisierten Pipeline integriert werden und somit die Qualität der Artefakte im Prozess nachhalten und monitoren. Typische Artefakte sind hier die Roh- und aufbereiteten Daten sowie die trainierten Modelle.</p><h2>Daten</h2><p>Die Qualität der Daten ist die Grundlage, um überhaupt erfolgreich Machine-Learning-Modelle trainieren zu können. Die ersten Quality Gates widmen sich daher den Daten und stellen sicher, dass das Training der Modelle auf einer sinnvollen Datenbasis geschieht. Zunächst lassen sich die Rohdaten prüfen. Sie müssen den bisherigen Annahmen/Statistiken und Ausprägungen entsprechen, da sonst gegebenenfalls Korrekturen im Setup des Modells und Trainings nötig werden können.<br /> In der Regel ist die Aufbereitung der Rohdaten höchst individuell und unter Umständen aufwendig. Das heisst, es sind gegebenenfalls weitere Prüfpunkte zwischen den Aufbereitungsschritten, hier nicht dargestellt, einzusetzen.<br /> Darüberhinaus kann beispielsweise die Verteilung der Daten in den resultierenden Datensets getestet werden. Eine faire und repräsentative Verteilung der Daten sowie eine ausreichende Menge an Datensätzen in den Sets sollte gewährleistet sein. Ansonsten ist die Auswertungen auf möglichen Validierungs- und Testsets nur bedingt aussagekräftig <a href="/wissens-hub/blog/machine-learning-modelle-bewerten-die-crux-mit-den-testdaten">[1]</a> .<br /> Eine unzureichende Datenbasis führt eher nicht zu den erhofften qualitativ möglichst guten Modellen. Falls diese Gates nicht passiert werden, kann ein frühzeitiger Abbruch schon zu Beginn der Pipeline Zeit, Ressourcen und Geld sparen. Insbesondere, wenn diese Gates mit überschaubarem Aufwand eingeführt werden können.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/xGvsEd3BTIqOxKtHwWbb"><img loading="lazy" width="1024" height="307" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/xGvsEd3BTIqOxKtHwWbb" alt="Bespiele für Daten-Quality-Gates innerhalb einer Machine-Learning-Pipeline" /></a> <p>Bespiele für Daten-Quality-Gates</p></div><h2>Metriken</h2><p>Um die Qualität der Vorhersagen eines Modells in einer Pipeline bewerten zu können, ist ein Set an automatisch auswertebaren Kriterien obligatorisch. Idealerweise kommen dazu numerische Metriken zum Einsatz. Diese können auf Vorhersagen des Modells auf dem zurückgelegten Testset ausgewertet werden.<br /> Dabei hängen die möglichen Metriken sowie Grenzwerte natürlich vom jeweiligen Anwendungsfall ab. Beispielsweise gilt es bei einer Klassifikation einen guten Tradeoff zwischen Abdeckung und Präzision zu finden und zu definieren, ab welcher Vorhersagesicherheit eine Klasse als erkannt gilt <a href="/wissens-hub/blog/machine-learning-modelle-bewerten-die-crux-mit-der-metrik">[2]</a> . Sind adequate Metriken aber erstmal ausgewählt und die zu erreichende Resultate bzw. Grenzwerte definiert, können die Kriterien in einem ersten Quality Gate für das Modell automatisiert geprüft werden.<br /> Allerdings stellt sich natürlich die Frage: Lohnt der ganze Aufwand überhaupt, komplizierte Machine-Learning-Modelle einzuführen? Oder gibt es nicht auch einfacherer Alternativen, um die Anforderungen zu erfüllen?</p><h2>Baselines</h2><p>Eher rudimentäre Lösungen lassen sich mit Hilfe von einfacheren Modellen meist günstig und schnell realisieren. Diese Modelle können durch Heuristiken, einfachen Statistiken oder gar einer schlichten Generierung von Zufallswerten erstellt werden und sind in einem Test zu schlagen. Durch den Vergleich mit Baseline-Modellen bekommt man eine Idee davon, welche Leistung einfach zu erreichen ist. Dazu können Prognosen der Baseline und einem Modellkandidaten auf demselben Testset erstellt und mit den ausgewählten Metriken verglichen werden. Wie groß der Unterschied zu einer einfacheren Lösung ist, lässt sich somit verdeutlichen.<br /> Es sollte schon einen gewissen, letztendlich vorab zu definierenden Unterschied in der Leistungsfähigkeit zu Gunsten des komplexeren Modells geben, um den Einsatz zu rechtfertigen. Besteht Klarheit darüber, ab welchem Unterschied ein echter Mehrwert des ML-Ansatzes vorliegt, lässt sich dies als Kriterium nutzen und damit ein weiteres Gate in den Prozess integrieren. Wird die Baseline nicht geschlagen, sind weitere Optimierungen an den Daten oder dem Training nötig oder gar der gewählte Ansatz zu überdenken.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jd2d7GLTfeWchjFQnFQ6"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jd2d7GLTfeWchjFQnFQ6" alt="Beispiele für Model Quality Gates innerhalb einer Machine-Learning-Pipeline" width="1024" height="426" /></a> <p>Beispiele für Model Quality Gates</p></div><h2>A/B-Tests</h2><p>Die eigentliche Performance des Models wird sich aber wohl erst in einer realen Situation, beispielsweise mit Hilfe von A/B-Tests, zeigen. <i>„Der A/B-Test (auch <em>split test</em>) ist eine Testmethode zur Bewertung zweier Varianten eines Systems, bei der die Originalversion gegen eine leicht veränderte Version getestet wird.“</i> <a href="https://de.wikipedia.org/wiki/A%2FB-Test" target="_blank">[3]</a> . Wenn die Infrastruktur es zulässt, können A/B-Tests ausgeführt werden und hilfreiche Einblicke liefern.<br /> Beispielsweise sind Korrelationen zwischen den zuvor geprüften Offline-Metriken und den Ergebnissen der Online-Metriken der A/B-Tests möglich. Es lässt sich damit einschätzen, inwiefern die Offline-Metriken die Performance der Modelle überhaupt vorhersagen können, bzw. welche am ehesten in Betracht gezogen werden sollten.<br /> Was unter Umständen vorab schon mal manuell ausgeführt und begutachtet werden kann ist ein A/B-Test zwischen einem ersten trainierten Modell und der Baseline.<br /> Darüber hinaus kann, wenn weitere Modell-Ansätze zu testen sind, natürlich auch das jeweils letzt beste Modell mit einem neuen potentiell besseren Modell verglichen werden. Der A/B-Test lässt sich damit auch als Quality Gate vor dem Deployment am Ende der Pipeline integrieren. Wobei A/B-Tests gegebenenfalls zeitaufwändig und somit automatisiert nicht immer praktikabel sind.</p><h2>Produktion</h2><p>Ein Unterschied zum Projektmanagement-Ansatz ist allerdings, dass der typische ML-Prozess in Zyklen verläuft. Letztendlich ist das Messen der Qualität eines Modells in den verschiedenen Gates innerhalb einer Machine-Learning-Pipeline nur eine Wette auf die Zukunft.<br /> Ist das Modell erst einmal in Produktion, unterliegt es einer gewissen Degeneration, welche je nach Domäne verschieden ausgeprägt und unterschiedlich schnell eintreten kann. Das heisst, Modelle veralten mit der Zeit und müssen gegebenenfalls an neue Gegebenheiten respektive Daten quasi angepasst werden. Dies kann beispielsweise durch erneutes oder weiteres Trainieren der Modelle erreicht werden, womit der Prozess von vorne beginnt.<br /> Quality Gates sind daher auch während des Betriebs der Modelle einzusetzen um festzustellen, ob das Modell in einer sich beständig ändernden Umgebung adequate Ergebnisse liefert bzw. weiterhin liefern kann.<br /> So können sich im Falle eines ‚Data Drift‘ zum einen die Daten ändern, beispielsweise die Verteilung oder Wertebereich der Daten bzw. Features. Oder die Muster, die das Modell gelernt hat, sind nicht mehr gültig und unterliegen einem Concept Drift <a href="https://en.wikipedia.org/wiki/Concept_drift" target="_blank">[4]</a> . Zum Beispiel können saisonale Effekte oder wie gerade geschehen in Zeiten einer Pandemie unerwartete Effekte die Vorhersagequalität von Modellen beeinflussen <a href="https://fortune.com/2020/09/23/a-i-algorithms-had-to-change-when-covid-19-changed-consumer-behavior" target="_blank">[5]</a> .<br /> Auch im Betrieb des Modells kann daher ein weiteres Gate regelmäßig neue Daten prüfen und verifizieren, dass sie den Annahmen noch entsprechen.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DdGU46q6QGGGTAWLgecV"><img loading="lazy" width="1024" height="397" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/DdGU46q6QGGGTAWLgecV" alt="MachineLearning Quality-Gates-Kette" /></a> <p>Machine Learning Quality-Gates-Kette inklusive Monitoring der aktuellen Modellqualität</p></div><p>Wie oft ein Modell neu trainiert werden muss und welche Änderungen vorzunehmen sind, hängt vom Anwendungsfall und der Ausprägung der neuen Gegebenheiten ab. Ob es sich ferner überhaupt lohnt ist ebenso abzuschätzen, da gegebenenfalls die Kosten um neue Modelle zu trainieren nicht unerheblich sein können.<br /> Dieser Trade-Off zwischen Kosten und Nutzen oder sogar Kritikalität des Modells stellt ebenso ein Gate dar. Das Gate wird aber kurioserweise nur zum nächsten Schritt, des erneuten Trainings, geöffnet, wenn das Modell ’schlecht‘ genug ist.</p><h2>Fazit</h2><p>Wie hier beispielhaft dargestellt lassen sich Quality Gates an verschiedenen Stellen in einer Pipeline integrieren, um die Qualität der jeweiligen Artefakte eines Teilprozesses sicher zu stellen. Dazu müssen Erfolgskriterien, die zum Passieren eines Gates zu erfüllen sind, vorab definieret werden und automatisiert prüfbar sein.<br /> Ein frühzeitiger Stopp einer Machine-Learning-Pipeline kann Zeit, Ressourcen und Geld sparen. Denn durch das Fehlschlagen eines Gates ist absehbar, dass am Ende eine ausreichende Vorhersagegüte des Modells nicht mehr gewährleistet werden kann.<br /> Letztendlich sind Modelle auch in der Produktion zu überwachen, um eine mögliche Modell-Degeneration frühzeitig zu erkennen und entsprechend darauf reagieren zu können.<br /> Darüber hinaus können eine Reihe weitere Gates und Tests in Betracht gezogen werden, um zu gewährleisten, dass das Ökosystem rund um den Machine-Learning-Ansatz in der Praxis besteht. Dies geht allerdings über den Rahmen dieses Artikels hinaus, soll hier aber nicht unerwähnt bleiben <a href="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/aad9f93b86b7addfea4c419b9100c6cdd26cacea.pdf" target="_blank">[6]</a> .</p><h2>Referenzen</h2><p>[1] <a href="/wissens-hub/blog/machine-learning-modelle-bewerten-die-crux-mit-den-testdaten">codecentric Blog – Machine-Learning-Modelle bewerten: die Crux mit den Testdaten</a> </p><p>[2] <a href="/wissens-hub/blog/machine-learning-modelle-bewerten-die-crux-mit-der-metrik">codecentric Blog – Machine-Learning-Modelle bewerten – die Crux mit der Metrik</a> </p><p>[3] <a href="https://de.wikipedia.org/wiki/A%2FB-Test">wikipedia – AB-Test</a> </p><p>[4] <a href="https://en.wikipedia.org/wiki/Concept_drift">wikipedia – Concept_drift</a> </p><p>[5] <a href="https://fortune.com/2020/09/23/a-i-algorithms-had-to-change-when-covid-19-changed-consumer-behavior">Fortune – A.I. algorithms had to change when COVID-19 changed consumer behavior</a> </p><p>[6] <a href="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/aad9f93b86b7addfea4c419b9100c6cdd26cacea.pdf">Google, Inc. – The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction</a> </p>

Machine-Learning-Modelle bewerten – Quality Gates etablieren

<p>Auf dem Weg von einem Monolithen oder einer grünen Wiese zu einer Landschaft von Microservices sind viele Pfade zu beschreiten und Design-Entscheidungen zu treffen. Neben dem Aufbau fachlich sinnvoll abgegrenzter Serviceeinheiten gilt ein Augenmerk der Kommunikation der Services untereinander. Schließlich soll verhindert werden, dass am Ende nicht doch wieder ein Weg eingeschlagen wird, der zu einem Monolithen aus Services führt, der dann verteilt und fest verdrahtet im Rechenzentrum ruht. Womit das eigentliche Ziel, die lose Kopplung der Services zu erreichen, konterkariert wird.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6ltySSYRm2Df1z2F7r0d"><img width="700" height="249" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6ltySSYRm2Df1z2F7r0d" alt="Unter Umständen ungünstige Entkopplung von Komponenten einer Applikation" /></a> <p>Unter Umständen ungünstige Entkopplung von Komponenten einer Applikation</p></div><p>Eine Variante der fest verdrahteten und komplexen Kommunikation zwischen den Services zu begegnen liegt im Einsatz eines Mediators und der asynchronen Kommunikation zwischen den Services. Im Kontext einer Systemintegration kommt dabei als Mediator in der Regel ein Message Broker zum Einsatz. Das Request/Response Pattern, wie es bei gängigen Ansätzen (beispielsweise RESTful Services) Anwendung findet, wird ersetzt durch eine Nachrichten-basierte Kommunikation. Die Services übergeben einem Broker ihre Nachrichten und der Broker stellt den Empfängern die Nachrichten für eine definierte Zeit zur Verfügung. Wann und vom wem die Nachricht verarbeitet wird ist für den Nachrichtensender dabei völlig intransparent. Ferner erwartet der Sender auch keine Antwort, wie es bei einem synchronen Request/Response Verfahren der Fall wäre <a href="http://www.enterpriseintegrationpatterns.com/patterns/messaging/Introduction.html" target="_blank">[1]</a> .</p><h2>Event-Channel</h2><p>Diese asynchrone Kommunikation ist die Basis einer Event-driven Architecture (EDA) und wird durch einen Message Broker und das Publish/Subscribe Pattern als Event-Channel realisiert.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/veagLw0RVC3zKnrSzoIg"><img loading="lazy" width="700" height="339" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/veagLw0RVC3zKnrSzoIg" alt="Event-Channel" /></a> <p>Event-Channel zur Entkopplung der Komponenten und deren direkten Kommunikation miteinander – nicht zu verwechseln mit einem ESB</p></div><p>Der Publish/Subscribe-Ansatz ermöglicht darüberhinaus, dass eine Nachricht nicht nur von einem Service oder sonstigen Komponente gelesen wird, sondern von mehreren Konsumenten.</p><h2>Events vs. Commands</h2><p>Die übertragenen Nachrichten respektive Events enthalten keine Anweisungen bzw. explizite Kommandos wie es beispielsweise beim CRUD-Ansatz und dem direkten Ausführen von Aktionen der Fall wäre. Vielmehr beschreibt ein Event was geschehen ist.</p><blockquote><p> An event is a notable thing that happens inside or outside your business. </p></blockquote><p>So wird in einem E-Commerce Shop das Event <em>Customer Tom did a purchase.</em><br /> an einen Message Broker übermittelt, aber nicht eine Kette von Requests an RESTful Services abgesetzt, die Aktionen wie:</p><ol><li><em>Create a Cart Object for Customer Tom</em></li><li><em>Create an Address Object for Customer Tom</em></li><li><em>et cetera</em></li></ol><p> realisieren.<br /> Darüberhinaus sind folgende Aspekte und Bedingungen zu beachten:</p><ul><li>Ein Event enthält all die relevanten Daten, die von möglichen Kandidaten von Konsumenten benötigt werden um das Event sinnvoll verarbeiten zu können. So benötig ein Invoice-Service, der Toms Adresse auf die Rechnung schreiben muss, die Daten der Adresse.</li><li>Ein Konsument muß die Daten die er benötigt, selber vorhalten und aktualisieren. Das heist, der Invoice-Service wird Toms Rechnungsadresse bei einem Address-Service nicht explizit erfragen müssen – falls ein dedizierter Address-Service in dem System überhaupt existiert.</li><li>Die Konsumenten müssen Idempotenz gewährleisten, damit, falls ein Event mehrfach gelesen wird, es nicht zweimal berücksichtigt wird.</li><li>Die Daten in einem Event sind <em>immutable</em> – sie werden nicht geändert. Falls sich der Status der Daten ändert, ist ein neues Event zu erzeugen, das den neuen Datensatz inklusive der Änderungen beinhaltet.</li></ul><h2>Mindshift</h2><p>Die Einführung einer Architektur basierend auf <a href="https://www.codecentric.de/leistungen/loesungen/technologie-treibt-veraenderung/microservices/" target="_blank">Microservices</a>  erfordert schon ein gewisses Umdenken bei der Frage, wie welche Probleme zu lösen sind. Beispielsweise ist vom kanonischen Datenmodell Abstand zu nehmen, Bounded Contexts sind bei der Modellierung zu bevorzugen und Datenduplizierung kein No-go mehr.<br /> Bis zur Etablierung einer EDA sind, wie oben schon für Events beschrieben, eine Reihe Paradigmen und Gewohnheiten aufzugeben, mit ebenso großem Einfluß auf die Entwicklung. Insbesondere existiert:</p><ul><li>keine direkte Kommunikation – es wird nur durch Events kommuniziert was geschah. Der Sender weiß nicht, wer sein Event empfängt und wie der Empfänger den Inhalt nutzt.</li><li>keine Interaktionen basierend auf einem Callstack – es gibt keine zentrale Instanz, die durch synchrone Aufrufe von Subroutinen Prozesse Schritt für Schritt abarbeitet und den aktuellen Status in einem Prozess vorhält <a href="http://www.enterpriseintegrationpatterns.com/docs/EDA.pdf" target="_blank">[3]</a> </li><li>keine Service-Orchestration, sie wird abgelöst durch eine Service-Choreographie</li></ul><p>Allerdings ist eine EDA natürlich auch nur wieder eine weitere Möglichkeit Softwaresysteme aufzubauen und nicht der Weisheit letzter Schluß um jedwede Softwarelösung mit Hilfe dieses Architekturansatzes zu realisieren. Die finale Architektur wird eher polyglotter Natur sein und die EDA zum Beispiel nur einen Blick in die Systemlandschaft und Aktivitäten zur Laufzeit ermöglichen.</p><h2>Complex Event Processing & Event Stream Processing</h2><p>Liegt der Fokus beim Aufbau eine Systems aus Microservices zunächst nur darauf, die lose Kopplung mit Hilfe einer EDA zu arrangieren, geht allerdings ein nicht unwesentlicher Aspekt des EDA-Ansatzes unter – Complex Event Processing (CEP).</p><blockquote><p>Complex event processing is a new technology for extracting information from message-based systems. – David Luckham and Brian Frasca, 1998</p></blockquote><p>Die Möglichkeit, Events auf einer höheren Abstraktionsstufe ableiten zu können, sie regelbasiert zu verarbeiten oder Eventströme in Echtzeit zu monitoren, sind zentrale Merkmale die diesen Architekturansatz charakterisieren und antreiben.</p><table><caption>Eigenschaft einer Event-driven Architecture mit Complex Event Processing [4]</caption><tbody><tr><th>Eigenschaft</th><th>EDA mit CEP</th></tr><tr><td>Perspektive</td><td>Echtzeitfähigkeit</td></tr><tr><td>Ereignisverarbeitung</td><td>einfache und komplexe Ereignismuster (<em>event pattern matching</em>), unter Einbeziehung von Kontextinformationen (<em>content enrichment</em>)</td></tr><tr><td>Abstraktionsgrad</td><td>Abstraktion von einfachen zu fachlich höherwertigen Ereignissen ergibt Abstraktionshierarchie</td></tr><tr><td>Mengengerüst</td><td>Verarbeitung von Massenereignisdaten aus mehreren Ereignisströmen</td></tr><tr><td>Wissensrepräsentation</td><td>explizit in CEP-Komponente; Wissen über Ereignisverarbeitung deklarativ in Form von Regeln formuliert</td></tr></tbody></table><p>Der Begriff <em>Complex Event Processing</em> wurde dabei schon in den 1990er geprägt, wobei der heutzutage gern ins Spiel gebrachte Begriff, <em>Event Stream Processing</em> erst später aufkam und einen etwas anderen Fokus hat:</p><blockquote><p>Event stream processing is focused more on high-speed querying of data in streams of events and applying mathematical algorithms to the event data. Some of the first commercial applications were to stock-market feeds in financial systems and algorithmic trading. CEP is focused more on extracting information from clouds of events created in enterprise IT and business systems. CEP includes event data analysis, but places emphasis on patterns of events, and abstracting and simplifying information in the patterns. The idea is to support as wide an area of enterprise management decision making as possible. The first commercial applications were in the Business Activity Monitoring, for example monitoring conformance to service level agreements. <a href="http://www.complexevents.com/2006/08/01/what’s-the-difference-between-esp-and-cep/" target="_blank">[5]</a> </p></blockquote><p>Im folgenden soll Complex Event Processing den Ansatz des Event Stream Processing mit umfassen.</p><h3>Eventstruktur</h3><p>Um CEP zu ermöglichen, ist allerdings die Definition und Einführung systemweit gültiger Spezifikationen nötig. Zum Beispiel wird, wenn die asynchrone Kommunikation erst mal etabliert, Kommandos eliminiert und Nachrichten eingeführt sind, im nächsten Schritt eine zentrale Eventstruktur sowie ein Eventmodel zum Einsatz kommen müssen. Andernfalls ist eine regelbasierte Verarbeitung von Events nur umständlich zu erreichen.<br /> So sind zum Beispiel neben der eigentlichen Payload domänenunabhängige Meta-Daten wie:</p><ul><li>eine Event-Id – gewährleistet die eindeutige Unterscheidung von Events,</li><li>ein Event-Type – spezifziert den fachlichen Inhalt/Payload des Events,</li><li>ein Timestamp – Zeitpunkt des Auftretens des Events,</li><li>die Source – Komponente die das Event erzeugt hat</li></ul><p>unabdingbar, um ein Event für die Weiterverarbeitung einordnen zu können.<br /> Diese zentrale Struktur schränkt die gerade eingeführte Flexibilität bei der Interfacegestaltung der einzelnen Microservices aber schon wieder ein. Es ist daher abzuwägen inwieweit es sinnvoll ist, sich auf ein zentrales Konzept und Strukturen zur Verarbeitung von Events einzulassen – insbesondere wenn die „Autonomie“ der Services als ein hohes Gut betrachtet wird. Im Rahmen einer Makroarchitektur für ein System sind solche Strukturen aber durchaus diskutierbar. Insbesondere verlassen sich die Konsumenten neben den Meta-Daten schon auf eine feste Struktur; die der eigentlichen Payload. Durch die Struktur der Payload besteht weiterhin eine Kopplung zwischen einem Sender und den Empfängern seiner Nachricht.</p><h3>CEP-Lösungen</h3><p>Eine Übersicht über den derzeitigen Markt an CEP-Lösungen würde den Rahmen dieses Artikels sprengen, aber eine, insbesondere auch historische Übersicht, befindet sich auf complexevents.com <a href="http://www.complexevents.com/2016/05/12/cep-tooling-market-survey-2016/" target="_blank">[6]</a> .<br /> Die Einführung einer CEP-Enterpriselösung im großen Stil ist mit Aufwänden verbunden, die fachlich wie technisch zu rechtfertigen sind, und den Schritt hin zur EDA mit CEP und deren Vorteilen lohnen müssen.<br /> Das heisst es wird nicht immer sinnvoll sein, auf eine Enterpriselösung komplett umzustellen, insbesondere wenn der fachliche Kontext es gar nicht hergibt.</p><h3>Lightweight CEP – Beispiel</h3><p>Stehen die Events in einem Event-Channel zur Verfügung und besitzen diese die oben genannten Meta-Daten, ist der nächste Schritt, mit „komplexen“ Events zu arbeiten, nicht mehr weit.<br /> Der Aufbau einer leichtgewichtigen CEP-Lösung lässt sich dabei reduzieren auf die Komponenten [7]:</p><ul><li>Event processing agent (EPA) (event processing component, event mediator): A software module that processes events.</li><li>Event processing network (EPN): A set of event processing agents (EPAs) and a set of event channels connecting them.</li><li>Event processing language (EPL): A high-level computer language for defining the behavior of event processing agents.</li></ul><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/sSMMdtEUTeuFuHvteDii"><img loading="lazy" width="700" height="852" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/sSMMdtEUTeuFuHvteDii" alt="Event Processing Agent and Network" /></a> <p>Event Processing Agents verarbeiten fachlich klar definierte Teilaufgaben und sind als ein Event Processing Network strukturierbar</p></div><p>Das folgende Beispiel basiert auf dem Open-Source-Projekte Esper <a href="http://www.espertech.com/esper-enterprise-edition/" target="_blank">[8]</a>  und Apache Camel <a href="http://camel.apache.org" target="_blank">[9]</a> . Esper stellt eine Processing Engine und eine Event Processing Language (EPL) zur Verfügung, um Events auf Event-Strömen beispielsweise filtern, aggregieren oder joinen zu können. Apache Camels Esper-Komponente ermöglicht eine standardisierte Integration der Esper Processing Engine um Events aus verschiedenen Quellen lesen und schreiben zu können. Ein Event Processing Agent lässt sich somit schon recht einfach realisieren und beispielsweise als Spring-Boot-Applikation deployen.<br /> Der folgende Sourcecodeausschnitt beschreibt eine Camel Route, die Events des Typs <em>CartCreatedEvent</em> beständig aus einem Eventstream ausliest und in einem Zeitfenster von fünf Sekunden auswertet. Falls der mittlere Umsatz während der fünf Sekunden geringer als 700 ist, wird ein neues Event <em>LowConversion</em> erzeugt und an den Event-Channel gesandt.</p><div>

```java5
from("esper://esper?eql=insert into de.codecentric.LowConversionEvent(avgTotalAmount) 
       select 
          avg(totalAmount) as avgTotalAmount 
       from 
          de.codecentric.CartCreatedEvent.win:time_batch(5 sec)
       having 
          avg(totalAmount) < 700
    ")
.to("seda:eventChannel");
```

</div><p>Die SQL-ähnlichen Queries sind dabei statisch und nur die Daten im Stream ändern sich. Das Vorgehen ist quasi umgekehrt zu einem Datenverarbeitungsansatz basierend auf einem RDBMS und SQL, bei dem die Queries meist recht variabel und die Daten eher statisch sind.<br /> Der Event-Channel ist hier realisiert als ein Topic eines Kafka-Brokers. Eine Camel-Route ließt die Events aus dem Topic und stellt sie der Esper Processing Engine als Objekte zur Verfügung (hier nicht dargestellt). Der Sourcecode sowie weitere Beispiele, inklusive Testdatenerzeugung und Kafka-Server-Einrichtung sind im GitHub Repository [10] verfügbar. Der Code enthält dabei natürlich nur die für die Beispiele relevanten Teile und Attribute und ist für einen produktiven Einsatz nicht ausreichend.</p><h3>Business Monitoring</h3><p>Sind die Events erst einmal im Event-Channel, lassen sich diese auch nach verschiedenen Kriterien monitoren und visualisieren – zum Beispiel mit dem Elastic-Stack, ehemals ELK Stack genannt <a href="https://www.elastic.co/de/products" target="_blank">[11]</a> . Dazu kann die Logstash-Komponente des Stacks die Events aus dem Kafka-Topic auslesen und dem Elastic Server zur Verfügung stellen. Die Events lassen sich dann nach verschiedenen Kriterien auswerten und mit Hilfe der Komponente Kibana visualisieren.<br /> Im folgenden Screenshot stellt das Tortendiagramm die Häufigkeit der einzelnen Events in Relation. Das Balkendiagramm zeigt einen Durchschnittswert über die <em>avgTotalAmount</em> der LowConversion Events und der Graph beschreibt einen Mittelwert der Umsätze der letzten Einkäufe. Automatische Aktionen zum Beispiel beim Über- oder Unterschreiten von bestimmten Grenzwerten sind dabei ebenso schon mit Esper Event-Listener und den Camel Routen realisierbar.<br /></p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KRcZ9D3nTpe5HaQrbEXS"><img loading="lazy" width="700" height="500" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/KRcZ9D3nTpe5HaQrbEXS" alt="Kibana Screenshot" /></a> <p>Visualisierung von Events mit hilfe des ELK Stacks</p></div><p></p><h3>Performance</h3><p>Um der Herausforderung der möglichen schieren Masse an auftretenden Events und Performanceengpässen Herr zu werden, spielt die fachliche Aufbereitung eine nicht unwesentliche Rolle.<br /> Durch Event Processing Networks lassen sich komplexe fachliche Aufgaben strukturieren und in kleinere, fachlich klar definierte Teilaufgaben zerlegen. Diese Teilaufgaben sind dann durch leichtgewichtige skalierbare Agenten realisierbar. Ferner läßt sich durch das Filtern von Events und einer geschickten Strukturierung die Masse der zu verarbeitenden Events Schritt für Schritt reduzieren – was der Performance zuträglich sein wird. Darüberhinaus existieren mittlerweile eine ganze Reihe von Lösungen auch im Open-Source-Bereich, die gerade den Performance- und High-Availability-Aspekt adressieren [6] – siehe Distributed Stream Computing Platform (DSCP).</p><h3>Geht’s noch komplexer?</h3><p>Der Mitte der 90er Jahre aufgekommene EDA-Ansatz, damals in Kombination mit einer Service orientierten Architektur, kann als Kommunikationsbasis für Microservices zu einer weiteren Entkopplung der Services führen und Stabilität ins System bringen. Complex Event Processing ermöglicht darüberhinaus die Informationsverarbeitung auf neue Füße zu stellen und einen Einblick ins System zur Laufzeit zu geben. Das Design der Systeme wird aber unter Umständen komplexer, da ein kontrollierbarer Callstack nicht existiert und die Zusammenarbeit der Services nicht mehr orchestrierbar ist. Und somit mehr Aufwand entsteht den aktuellen Status eines inhärenten Prozessablaufs zu ermitteln.</p><h2>Referenzen</h2><p>[1] <a href="http://www.enterpriseintegrationpatterns.com/patterns/messaging/Introduction.html" target="_blank">EIP – Messaging</a>  <br /> [3] <a href="http://www.enterpriseintegrationpatterns.com/docs/EDA.pdf" target="_blank">Programming Without a Call Stack – Event-driven Architectures</a> <br /> [4] Event-Driven Architecture: Softwarearchitektur für ereignisgesteuerte Geschäftsprozesse, Xpert.press, ISBN 978-3-642-02439-9<br /> [5] <a href="http://www.complexevents.com/2006/08/01/what%E2%80%99s-the-difference-between-esp-and-cep/" target="_blank">Real Time Intelligence & Complex Event Processing</a> <br /> [6] <a href="http://www.complexevents.com/2016/05/12/cep-tooling-market-survey-2016/" target="_blank">CEP Tool Market</a> <br /> [7] Event Processing for Business: Organizing the Real-Time Enterprise, John Wiley & Sons, ISBN 978-0470534854<br /> [8] <a href="http://www.espertech.com/esper-enterprise-edition/" target="_blank">EsperTech</a> <br /> [9] <a href="http://camel.apache.org" target="_blank">Apache Camel</a> <br /> [10] <a href="https://github.com/codecentric/event-processing-sample">Event Processing Sample</a> <br /> [11] <a href="https://www.elastic.co/de/products" target="_blank">ELK Stack</a> </p>

Event-driven Microservices & Event Processing

<p><br /> Once a model has been trained, it can be evaluated in different ways and with more or less complex and meaningful procedures and metrics. However, the number and possible criteria for evaluating machine learning models can initially be quite confusing to someone who is just starting to deal with the field of machine learning.</p><p>For example, it depends on whether the learning is un-supervised or supervised. In the case of supervised learning it also depends on whether we are dealing with a regression or classification, the underlying use case, and so on – to name just a few criteria. I would like to start with supervised learning and classification. In this article I will introduce seven common metrics and methods for evaluating machine learning models using one example throughout this post. However, a detailed discussion would be beyond the scope of this introduction, so I will only touch only briefly on the mathematics underlying the metrics.</p><h2>Use case</h2><p>A manufacturer of drinking glasses wants to identify and sort out defective glasses in his production. A model for image classification is to be trained and used for this purpose. The database consists of images of intact and defective glasses. Intact glasses are represented by 0 in this binary classification; accordingly, defective glasses are represented by 1.</p><p>In the following test data (y_true), for example, eight defective and two intact glasses are present and seven of them are correctly classified as defective by the model (y_pred).</p>

```

# Test data  
y_true: [0, 1, 1, 1, 0, 1, 1, 1, 1, 1]

# Forecast/prediction of the model
y_pred: [0, 0, 1, 1, 0, 1, 1, 1, 1, 1] 

```

<h2>Accuracy</h2><p>Accuracy is probably the most easily understood metric and compares the number of correct classifications to all the classifications to be made.<br /> <img height="50"  src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/mMby3pjoROSlcrL8X2Kz" alt="Accuracy" /><br /> In the following example, only one value was wrongly predicted and therefore an accuracy of 90% was achieved.</p>

```

y_true:   [0, 0, 0, 0, 0, 1, 1, 1, 1, 1]  
y_pred:   [0, 1, 0, 0, 0, 1, 1, 1, 1, 1]  
Accuracy: 90%.

```

<p>If the classes in the data are extremely unevenly distributed, viewing the accuracy alone can unfortunately lead to wrong conclusions. For example, if one class exists nine times more often in the data than the other, simply predicting the more frequent class is enough to achieve 90% accuracy – although the model may not be able to predict the other class. Whether the model is able to distinguish defective glasses from intact glasses is not assessable with this metric and a class distribution, since it always seems to predict a defective glass, as seen in the following example.</p>

```

y_true:   [0, 1, 1, 1, 1, 1, 1, 1, 1, 1]  
y_pred:   [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]  
Accuracy: 90%.

```

<p>In addition to such imponderables, it naturally also depends on the use case which metrics can be used for evaluating machine learning models.</p><h2>Binary classification</h2><p>First, a binary classification [1] can distinguish four cases:</p><ul><li> The class was predicted – which is correct (hit, true positive)</li><li> The class was not predicted – which is correct (reject, true negative)</li><li> The class was predicted – which is wrong (false alarm, false positive)</li><li> The class was not predicted – which is wrong (miss, false negative)</li></ul><p>For these four cases, however, different designations are common [2]. Since <em>hit</em>, <em>correct reject</em>, <em>false alarm</em> and <em>miss</em> seem to be most descriptive to me, I will use them here.</p><h2>Trade-Off between coverage and precision</h2><p>If, for example, it is important to recognize a class in the data as comprehensively as possible, the coverage (recall, hit rate, true positive rate) can be used as a quality criterion. Recall represents the number of <em>hit</em> in relation to the sum of <em>hit</em> and <em>miss</em>, i.e. all defective glasses to be detected:<br /> <img height="50"  src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/I2oWtxzOSwCpIDDEBEoG" alt="Recall" /><br /> If the model as above simply predicts a defective glass, i.e. only one class, the coverage is of course still hit=9 and miss=0 and thus Recall=9/\(9+0\)=1.</p><p>In contrast to this, precision describes the ratio of the number of <em>hit</em> to the sum of <em>hit</em> and <em>false alarm</em>, i.e. all glasses supposedly detected as defective:<br /> <img loading="lazy" height="50px" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/PlIjHDjfTpK7cTSvrLro" alt="Precision" /><br /> At this point, predicting only one class would of course increase the number of <em>false alarm</em> to 1 and thus result in less precision – (Precision=9/\(9+1\)=0,9.</p><p>Finally, the coverage describes how many supposed hits there were and the precision how many were correct. Achieving both complete coverage and high precision is desirable. In practice, however, this will not always be possible and the focus will not always be on both. The F-measurement can be evaluated so that the two metrics do not have to be checked and weighed up against each other at the same time.</p><h2>F-measurement / F1-Score</h2><p>The F-measurement describes the harmonic mean between recall and precision and combines the two metrics to one value [3].<br /> <img loading="lazy" height="50"  src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2AldbfclRQm7v7TyNYBh" alt="F1-Score" /><br /> The use of the harmonic mean means that the metric is somewhat more ‘sensitive’ to the smaller of the two values than it would be in the arithmetic mean.<br /> For example, a recall value of (1,0) and a precision value of (0,1) results in an arithmetic mean of 0,55 – which intuitively does not do justice to the small value of precision. However, the harmonic mean is calculated to 0,18 and points to a worse model.</p><p>The F1 score is derived from a more general variant, the F-beta score.<br /> <img loading="lazy" height="50"  src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/OzmPZIrShsy0eIRjiYIg" alt="F1-Beta Score" /><br /> With the F1 score, *beta* is set to 1 and thus recall and precision are weighted equally. If the application requires it, Recall and Precision can also be weighted differently. A (beta) value between 0 and 1 weights the precision more strongly, a value greater than 1 weights the recall more strongly.</p><p>However, even in this metric an unequal distribution of the classes in the data can falsify the result. In addition, the case <em>correct recject</em> is not considered in the F measure. A method would be desirable that considers all above mentioned cases of a binary classification, proves to be robust against unbalanced class distributions and is easy to represent.</p><h2>Confusion Matrix</h2><p>The comparison of the model’s predictions and the correct values in the form of a contingency table provides a more detailed insight into the model’s performance. For each case, the number of times it occurred in the result is counted, and the number is entered into a contingency table. The rows describe the predictions and the columns show the correct values. In the binary case this table is also called Confusion Matrix [2].<br /> The four cases can be found in this matrix, for example:<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/h1E1nzN1T9aHTzCAwtYQ"><img width="250" height="177" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/h1E1nzN1T9aHTzCAwtYQ" alt="confusion matrix" /></a> </p><p>In the following example, the classes are not distributed equally but are in the ratio (7:3).</p>

```

y_true: [0, 0, 0, 1, 1, 1, 1, 1, 1, 1] 
y_pred: [0, 1, 1, 0, 1, 1, 1, 1, 1, 1]

hit = 6, false alarm = 2, miss = 1, correct reject = 1

```

<p>The model has six defective glasses correctly detected (hit) and one correctly classified as correct reject. However, two intact glasses were detected as defective (false alarm) and one defective glass was not detected (miss). The aim is to achieve the highest possible values in the matrix on the diagonal from top left to bottom right – i.e. high values only for <em>hit</em> and <em>correct reject</em>.</p><p>The matrix considers all cases, but keeping track is not always easy, and a statement about the performance of the model is intuitively not possible on the fly. Nevertheless, one gets an impression of how the results relate to each other. For example, the values that influence Recall and Precision can be found directly in the matrix.<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/sRIAzwPRDmxrzjCjbQCt"><img loading="lazy" width="250" height="177" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/sRIAzwPRDmxrzjCjbQCt" alt="recall precision" /></a> </p><h2>Matthews Correlation Coefficient (MCC)</h2><p>A metric that summarizes all cases and is considered suitable for application to data sets with unbalanced class distributions is Matthews Correlation Coefficient [4,5,6]. It can be read and calculated from the Confusion Matrix as follows:</p><p><img loading="lazy" height="50" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/2Lqr0BC5Rn2Iycx4Z6VA" alt="Matthew’s Correlation Coefficient" /></p><p>The value range of the metric is between -1 and 1. The value 1 is desirable, 0 is random, and negative values indicate a contradictory assessment of the model. However, the MCC is not defined if one of the four sums in the denominator is 0.</p><h2>The crux</h2><p>The values for Accuracy, Precision and Recall in the above example of the Confusion Matrix are:</p>

```

Accuracy:  0.70
Precision: 0.75
Recall:    0.86

```

<p>If we compare this model to another only on the basis of accuracy, this could already lead to the exclusion of the model at this point.<br /> A model with good accuracy and bad values for recall and precision could be preferable, but not necessarily the best model for this application. In this case, the metrics Recall and Precision, for example, would be more interesting, since they deal more precisely with the requirements and thus the model can be better assessed and compared.<br /> This means that pure confidence in accuracy can again lead to unfavorable conclusions about the performance of a model, depending on the application. This phenomenon is commonly known as the Accuracy Paradox [7].</p><p>In addition, depending on the distribution of classes in the data, some metrics may not represent changes in the predictions or may tend in different directions. The following examples give another small impression of how different the ratings can be.</p>

```

y_true:   [0, 1, 1, 1, 1, 1, 1, 1, 1, 1]   
y_pred:   [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]   
Accuracy: 0.90
F1 score: 0.95 (0.9474)
Matthews CC: 0.00

```

<p>With a value of >= 0.90, F1 and Accuracy already seem to be a quite good model. However, the Matthews Correlation Coefficient clouds the picture of the model and points to randomly correct predictions, since the intact glasses are extremely underrepresented and this one was even wrongly classified.</p><p>In the following case, undamaged glasses are more often present in the data and thus allow for a better evaluation.</p>

```

y_true:   [0, 0, 1, 1, 1, 1, 1, 1, 1, 1]
  y_pred:   [1, 0, 1, 1, 1, 1, 1, 1, 1, 1]  
Accuracy: 0.90  
F1 score: 0.94 (0.9412)
Matthews CC: 0.67 (0.6667)

```

<p>Matthews Correclation Coefficient now points to a better model with a value of 0.67, since one of the two intact glasses was recognized correctly at least once. Accuracy and F1 do not react at all or only slightly to the change and they are calculated to the same or quite similar values as in the previous example. But will the decisions still be made by chance? After all, the two intact glasses are classified right in one case and once wrong in the other.</p><p>In the following example, three good glasses have been predicted twice correctly and once wrongly, so that the performance of the model can be evaluated even better. Matthews Correlation Coefficient acknowledges this with an increase from 0.67 to 0.76 and F1 with a further devaluation from 0.94 to 0.93.</p>

```

y_true:   [0, 0, 0, 1, 1, 1, 1, 1, 1, 1]  
y_pred:   [1, 0, 0, 1, 1, 1, 1, 1, 1, 1]  
Accuracy: 0.90  
F1 score: 0.93 (0.9333)
  Matthews CC: 0.76 (0.7638)

```

<p>This means that it is advisable to use the values of several metrics when comparing models and especially in case of unbalanced class distributions and to determine in advance which metrics are relevant for the application case.</p><p>However, what is the minimum score that we can be satisfied with regarding this model? This, of course, depends on the use case or the requirements and is often difficult to assess if there are no comparative variables such as the reliability of a human decision maker.<br /> Further graphical presentation of the performance of a model can be instructive and help achieve a good trade-off.</p><h2>Trade-Off between hit and false alarm rate</h2><p>While the glass manufacturer’s sales department strives to achieve the highest possible throughput in production, the quality and legal department will be more eager to minimize the number of defective glasses going on sale. This means that the sales department wants to avoid waste consisting of glasses unnecessarily classified as defective (false alarm). The quality assurance department, on the other hand, insists on recognising all defective glasses (hits) – even if this means that a few intact glasses cannot be sold.</p><h2>Receiver Operating Characteristic</h2><p>The Receiver Operating Characteristic curve (ROC curve) [8] compares the proportion of objects correctly classified as positive, i.e. the hit rate, with the proportion of objects falsely classified as positive, i.e. the false alarm rate, in a diagram. The false alarm rate describes the ratio of the number of glasses falsely detected as defective to the number of glasses detected as intact.<br /> <img loading="lazy" height="50" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/vGF5YwjkRKqlfPm0z1ea" alt="False Alarm Rate" /></p><p>This means that the proportion of glasses correctly identified as defective is compared with the proportion of glasses falsely identified as defective.</p><p><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4peAKHTkQHX5GsXoRFZn"><img loading="lazy" width="250" height="188" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/4peAKHTkQHX5GsXoRFZn" alt="ROC Curve" /></a> </p><p>Additionally it is also a matter of optimizing a threshold value. Depending on the method used, the predictions of a model will not always only output the numbers 0 and 1 for classification. Rather, the values lie between 0 and 1 and thus describe a probability of belonging to a class, which is then to be interpreted. This means at what value do you want to accept that a class has been recognized?</p><p>The values of the hit rate are entered on the vertical per threshold value and the values of the false alarm rate on the horizontal. The diagonal from bottom left to top right describes the random limit. That means curves that tend far above this limit and into the upper left corner represent a good evaluation. The hit rate there is as high as possible and the false alarm rate very low at the same time. The result is this typical curve (black in the diagram) on which you can now decide which trade-off to enter, or – if you enter several models – which model can be used with which threshold value, or whether to continue training.</p><p>With the model in the following example (orange curve in the diagram), a hit rate of 0.86 could be achieved if a false alarm rate of 0.33 is accepted and a threshold value of 0.3 is applied. The thresholds themselves are not shown in the curve, but are listed in the following table.</p>

```

y_true: [0    0    0    1    1    1    1    1    1    1   ] 
y_pred: [0.22 0.24 0.40 0.23 0.30 0.42 0.70 0.50 0.60 0.80]

Hit rate:         [0.00 0.14 0.71 0.71 0.86 0.86 1.00 1.00]
 False alarm rate: [0.00 0.00 0.00 0.33 0.33 0.67 0.67 1.00] 
Thresholds:       [1.80 0.80 0.42 0.40 0.30 0.24 0.23 0.22]

```

<p>If you insist on a false alarm rate of 0, a hit rate of 0.71 is possible. For this purpose, the threshold value must be set to at least 0.42. In practice, of course, there are more data records available and correspondingly much finer gradations from which a threshold value can be selected. In addition, the area under the curve <em>Area Under Curve</em> AUC can be interpreted with a value between 0 and 1. In this case, 1 once again represents the best value and 0.5 represents the coincidence or in this case also the worst value [9]. The AUC values for the curves are listed in the key of the diagram.</p><h2>Evaluating machine learning models – Conclusion</h2><p>In general, you can try to train a model that achieves the best possible values for all metrics. In practice, however, the effort required to achieve the last per mille of improvement often does not justify the actual benefit. A pragmatic, application-oriented approach is more likely to lead to success and provides the necessary leeway to achieve a meaningful trade-off. After all, with the test results and the resulting metric values, the models can only be compared with each other. How good a model really is will then be shown in practice and a justification as to how the model came to its decision has not yet been given, but in some areas it may well be necessary [10].</p><p>But how much test data is actually necessary for a meaningful evaluation?<br /> Read in: <a href="/wissens-hub/blog/evaluating-machine-learning-models-test-data-sets">Evaluating machine learning models: The issue with test data sets</a> ,<br /> what influence the size of the test data set can have on the comparability of models.</p><h2>References</h2><p>1] Wikipedia, <a href="https://de.wikipedia.org/wiki/Beurteilung_eines_bin%C3%A4ren_Klassifikators" target="_blank">Evaluation of a binary classifier</a> <br /> [2] Wikipedia, <a href="https://en.wikipedia.org/wiki/Confusion_matrix" target="_blank">Confusion Matrix</a> <br /> [3] TYutaka Sasaki, 2007, The truth of the F-measure  <br /> 4] Boughorbel S, Jarray F, El-Anbari M (2017) Optimal classifier for imbalanced data using Matthews Correlation Coefficient metric. PLoS ONE 12(6): e0177678. <a href="https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177678" target="_blank">doi.org/10.1371/journal.pone.0177678</a> <br /> [5] Davide Chicco, 2017, Ten quick tips for machine learning in computational biology. <a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5721660/" target="_blank">doi:10.1186/s13040-017-0155-3</a> <br /> [6] Wikipedia, <a href="https://en.wikipedia.org/wiki/Matthews_correlation_coefficient">Matthews correlation coefficient</a> <br /> [7] Wikipedia, <a href="https://en.wikipedia.org/wiki/Accuracy_paradox" target="_blank">Accuracy paradox</a> <br /> [8] Tom Fawcett, 2005, An introduction to ROC analysis, <a href="https://people.inf.elte.hu/kiss/11dwhdm/roc.pdf" target="_blank">doi.org/10.1016/j.patrec.2005.10.010</a> <br /> [9] Wikipedia, <a href="https://de.wikipedia.org/wiki/Receiver_Operating_Characteristic" target="_blank">Receiver Operating Characteristic</a> <br /> [10] Shirin Elsinghorst, Explanability of Machine Learning Methods, The Softwerker Vol. 13, <a href="https://www.codecentric.de/wissen/softwerker/" target="_blank">The Softwerker Vol. 13</a> </p>

Evaluating machine learning models: How to tackle metrics

<p><br /> Machine learning technologies can be used successfully and practically in a corporate environment. A concrete, manageable use case and thus focused application of machine learning models can generate real added value. This added value naturally depends on the use case and the performance of the trained models. Therefore it is important to clarify how well a model can actually support the respective challenge. In this article I would like to explain how the evaluation of the performance could be interpreted, especially depending on how much test data is or should be available.</p><h2>Test data scope</h2><p>By using a retained representative test set and various metrics, scores can be calculated and the models can be evaluated and compared. But the test set is not used in the training. To optimize the model, further validation sets are only generated from the remaining data.<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EW7apzh9Qnu6zlijabfR"><img width="916" height="439" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EW7apzh9Qnu6zlijabfR" alt="Train-Test-Split when training Machine Learning models" /></a> <br /> Once meaningful metrics have been found for the respective use case and target values to be achieved have been defined, the question arises as to what extent the values achieved can actually be trusted. After all, these values can only be based on a reduced amount of example data. How much test data is necessary for a meaningful evaluation depends on the score to be achieved and the desired confidence in the evaluation.<br /> However, collecting and, in the case of supervised learning, labeling the data often requires manual steps and may be a cost factor that should not be underestimated. A good trade-off must be found between confidence in the assessment and the expected costs of collecting and preparing the test data.</p><h2>Use case</h2><p>For further explanation, I will use the example of the article: <a href="/wissens-hub/blog/7-common-metrics-evaluating-machine-learning-models" target="_blank">Evaluating machine learning models: How to tackle metrics</a> .</p><p>“<em>A manufacturer of drinking glasses wants to identify and sort out defective glasses in his production. A model for image classification is to be trained and used for this purpose. The database consists of images of intact and defective glasses.</em>” <a href="/wissens-hub/blog/7-common-metrics-evaluating-machine-learning-models" target="_blank">[1]</a> </p><p>The number of pictures of defective glasses is very limited here, so that, with some effort, pictures of about 500 intact and 500 defective glasses will be available for training and testing of the models only after some time – especially because defective glasses occur rather rarely in production. From these 1000 pictures a representative test set is then retained before training.</p><p>How much test data is required for a meaningful evaluation of a machine learning model? Or what does “meaningful” mean in this context? Is 10% to 20% of the data base, in this case 100 to 200 images, sufficient?<br /> In this example, the metric <em>accuracy</em> is selected and after a little training and optimization, the model will achieve a performance of 80% of correct classifications – on a basis of 100 test images.<br /> To estimate how trustworthy this result actually is, you can use standard tools of statistics.</p><h2>Confidence interval</h2><p>Whether an image has been classified correctly by the model can be seen as an experiment with the two possible results <em>success</em> or <em>failure</em>. Testing a model is also a series of similar independent experiments, so that the binomial distribution or its approximation <a href="https://en.wikipedia.org/wiki/De_Moivre–Laplace_theorem" target="_blank">[2]</a>  to the normal distribution can be used to estimate the result.<br /> The extent to which one can now “trust” the determined value can be shown with the help of a confidence interval.<br /> The benefit of a confidence interval is the possibility of quantifying the uncertainty of a sample, for example a test run on 100 images, and the resulting estimate. Estimation because the test data represent only a small part of the possible data set or population, and thus the model has only been tested with a small part of data and not with all data that may ever occur.</p><p>“<em>The confidence interval indicates the range which, with infinite repetition of a random experiment, includes the true location of the parameter with a certain probability (the confidence level).</em>” <a href="https://de.wikipedia.org/wiki/Konfidenzintervall" target="_blank">[3]</a> </p><p>The interval is represented by a lower and an upper limit value and the assumption that the test runs have been repeated quite often on different independent test data sets of the same size. This means, for example, that on average in 95 % of the imaginary test runs the resulting limit values include the determined score.</p><h2>Calculating intervals</h2><p>The limit values can be calculated as follows, for example <a href="https://en.wikipedia.org/wiki/Binomial_proportion_confidence_interval" target="_blank">[4]</a> :</p><p><img height="75" width="242" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/BbmHrSPEQU6uIgnEjfej" alt="Confidenzinterval"/> </p><p>With <em>p=1/score</em>, <em>n</em> is the number of data and <em>z</em> is a constant that can be read from the standard normal distribution table for the desired “confidence” (confidence level). Common values are, for example:</p><table><tr><td><strong>level</strong></td><td>90 %</td><td>95%</td><td>97%</td><td>99%</td><td>99.5 %</td></tr><tr><td><strong>z</strong></td><td>1.28</td><td>1.64</td><td>1.96</td><td>2.33</td><td>2.58</td></tr></table><p>In case of the 95% confidence level, with 100 test data sets and a measured score of the model of 80%, the interval is 72% to 88%. This range seems to be quite large and probably not accurate enough for some applications.</p><h2>The crux</h2><p>But even when doubling the test data to 200 data sets, the resulting interval: 74% to 86% is not much smaller. The following diagram shows a few more examples of accuracy scores of 80%, 90%, 95% and 99% for the 95% confidence level and for the test data size 100, 200, 1000, 10000. On a basis of 10000 data sets, the range is +-1% and could be acceptable for a score of 80%.<br /> <a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6pPbgPlvS8qI2Po6GjXE"><img loading="lazy" width="250" height="204" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/6pPbgPlvS8qI2Po6GjXE" alt="confidence intervals per score" /></a> </p><p>However, for an accuracy of 85% determined on basis of 100 test data, the interval would be 78% to 92%. It therefore also covers a score value of 80%. This suggests that it may be possible to work with less training data and better equip the test data set. Finally, it is possible that if a poorer score is obtained, for example by training on less data, the confidence interval limits will still include the originally better score.<br /> Furthermore, focusing on the last per mil improvement, determined on the basis of a small test set, may not be a goal-oriented endeavour. Or even the effect may occur that after increasing the test data, a model that may not have appeared to be so good before may perform better than the model that was originally preferred due to an insignificantly higher score.<br /> This means that a statement about the performance of the model and differentiation from other models on the basis of a manageable number of test data is only possible to a limited extent.<br /> In general, the larger the sample from which the estimate was drawn, the more precise is the estimate and the smaller and better is the confidence interval.</p><h2>Conclusion</h2><p>Ultimately, the evaluation of a model should be done with a sense of proportion and the size of a test set should be included in the evaluation. Particularly with results that do not differ significantly, the selection of a model based solely on these evaluations may not always be promising. A field test in practice, for example by A/B testing, with several models that cannot be clearly distinguished, can support a decision.</p><h2>References:</h2><p>[1] codecentric blog, <a href="/wissens-hub/blog/7-common-metrics-evaluating-machine-learning-models" target="_blank">Evaluating machine learning models: How to tackle metrics</a> <br /> [2] Wikipedia, <a href="https://en.wikipedia.org/wiki/De_Moivre–Laplace_theorem" target="_blank">De Moivre–Laplace theorem</a> <br /> [3] Wikipedia, <a href="https://de.wikipedia.org/wiki/Konfidenzintervall" target="_blank">Confidence interval (German version)</a> <br /> [4] Wikipedia, <a href="https://en.wikipedia.org/wiki/Binomial_proportion_confidence_interval" target="_blank">Binomial proportion confidence interval</a> </p>

Evaluating machine learning models: The issue with test data sets

<p>The quality or usefulness of machine learning models can be evaluated using test data and metrics. However, to what extent? Manually, automated, once, regularly? Manually, the first models as the result of a proof of concept can certainly still be evaluated and compared in a manageable way. If the number of models increases into the dozens or even hundreds, depending on the use case and whether they also have to be constantly retrained, the manual procedure no longer tends to scale.<br /> The preparation of the data, the training of the models and their evaluation can be automated in the form of machine learning pipelines. However, a qualified evaluation of the data or an evaluation of the predictive quality of a model has its pitfalls – especially in automated form.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YBObm2wRSqROEd8qcOjd"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YBObm2wRSqROEd8qcOjd" alt="Example of a simple machine learning pipeline" width="1024" height="290" /></a> <p>Example of a simple machine learning pipeline</p></div><p>In classic software development, unit tests, integration tests, end-to-end tests etc. have become established within CI/CD pipelines for quality assurance. However, to create machine learning models, measures that ensure the quality of a model are also necessary. These should accompany the process from the preparation of raw data to the delivery of a model. They can ideally be integrated into the pipeline as well.</p><h2>Quality gate</h2><p>The term ‘quality gate’ originates from project management and describes the introduction of ‘checkpoints’ into the project process. The aim is to divide the project duration into shorter, manageable sections in order to be able to track progress. In this context, verifiable success criteria are to be defined in advance for each gate.<br /> For example, a gate contains a list of goals or quality requirements for the resulting artifacts at the end of a project phase. These must be met before the next stage in the process flow is started. However, checking the status can also lead to the project being aborted – because it becomes transparent that essential characteristics have not been achieved or will very likely not be achieved at all. Stopping a project at an early stage may therefore also save time, resources and money.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/oBnm3kOHQMmjSCrYMl2s"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/oBnm3kOHQMmjSCrYMl2s" alt="Quality gates in the project process" width="1024" height="368" /></a> <p>Quality gates in the project process</p></div><p>In the machine learning context, quality gates can be integrated as dedicated checks between the individual steps of an automated pipeline. Thus, they can track and monitor the quality of the artifacts in the process. Typical artifacts are the raw and processed data as well as the trained models.</p><h2>Data</h2><p>The quality of the data is the basis for being able to successfully train machine learning models at all. Therefore, the first quality gates are dedicated to the data and they ensure that the training of the models happens on a meaningful data basis. First, the raw data can 
be checked. They must correspond to the previous assumptions/statistics and characteristics, otherwise corrections in the setup of the model and training may become necessary.<br /> In general, the preparation of the raw data is highly individual and may be costly. This means that further test points, which are not shown here, may have to be used between the preparation steps.<br /> In addition, the distribution of the data in the resulting data sets can be tested. A fair and representative distribution of the data as well as a sufficient number of data sets in the sets should be guaranteed. Otherwise, the 
evaluations on possible validation and test sets are only of limited value <a href="/wissens-hub/blog/evaluating-machine-learning-models-test-data-sets">[1]</a> .<br /> There is a tendency that an insufficient data basis does not lead to the high-quality models we aim for. If these 
gates are not passed, an early termination already at the beginning of the pipeline can save time, resources and money, especially if these gates can be introduced with manageable effort.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/slpcVQw4STqthyuYHf5M"><img loading="lazy" width="1024" height="307" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/slpcVQw4STqthyuYHf5M" alt="Examples of data quality gates within a machine learning pipeline." /></a> <p>Examples of data quality gates</p></div><h2>Metrics</h2><p>In order to evaluate the quality of a model’s predictions in a pipeline, a set of automatically evaluable criteria is mandatory. Ideally, numerical metrics are used for this purpose. These can be evaluated on predictions of the model on the retained test set.<br /> Of course, the possible metrics and threshold values depend on the particular application. For example, in case of a classification it is necessary to find a good tradeoff between coverage and precision and it has to be defined from which prediction certainty a class is considered to be recognized <a href="/wissens-hub/blog/7-common-metrics-evaluating-machine-learning-models">[2]</a> . But once adequate metrics have been selected and the results or threshold values to be achieved have been defined, these criteria can be checked automatically in an initial quality gate for the model.<br /> However, the question arises of course: Is it worth all the effort to introduce complicated machine learning models? Or aren’t there simpler alternatives to meet the requirements?</p><h2>Baselines</h2><p>Rather rudimentary solutions can usually be implemented cheaply and quickly using simpler models. These models can be created by heuristics, simple statistics or even a simple generation of random values and have to be beaten in a test. By comparing them with baseline models, one gets an idea of what performance is easy to achieve. To do this, predictions of the baseline and a candidate model can be generated on the same test set and compared to the selected metrics. How big the difference is to a simpler solution can thus be illustrated.<br /> There should already be a certain performance difference in favor of the more complex model to justify its use. If it is clear at which difference there is a real added value of the ML approach, this can be used as a criterion and thus another gate can be integrated into the process. If the baseline 
is not beaten, further optimization of the data or the training is necessary or even the chosen approach has to be reconsidered.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9J4jBKeXSmKpWzuy8ITG"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/9J4jBKeXSmKpWzuy8ITG" alt="Examples for Model Quality Gates within a Machine Learning Pipeline" width="1024" height="426" /></a> <p>Examples of Model Quality Gates</p></div><h2>A/B tests</h2><p>However, the actual performance of the model will probably only become apparent in a real-life situation, for example with the help of A/B tests. <i>The A/B test (also <em>split test</em>) is a test method for evaluating two variants of a system, in which the original version is tested against a slightly modified version.</i> <a href="https://de.wikipedia.org/wiki/A%2FB-Test" target="_blank">[3]</a> . If the infrastructure supports A/B tests, these can be run and provide helpful insights.<br /> For example, correlations between the previously tested offline metrics and the results of the online metrics of the A/B tests might exist. This makes it possible to assess to what extent the offline metrics can predict the performance of the models at all, or which ones should most likely be considered.<br /> What can be done and assessed manually in advance is an A/B test between a first trained model and the baseline.<br /> In addition, if further model approaches are to be tested, the last best model can of course also be compared with a new potentially better model. Thus A/B testing can also be integrated as a quality gate before deployment at the end of the pipeline. However, A/B tests might be time-consuming and therefore not always practical in an automated way.</p><h2>Production</h2><p>One difference, compared to the project management approach, however, is 
that the typical ML process runs in cycles. Ultimately, measuring the quality of a model in the various gates within a machine learning pipeline is just a bet on the future.<br /> Once the model is in production, it is subject to some degeneration, which can vary in degree and speed depending on the domain. This means that models become obsolete over time and may need to be quasi-adapted to new circumstances or data. This can be achieved, for example, by renewing or further training the models, which starts the process all over again.<br /> Quality gates are therefore also to be used during the operation of the models in order to determine whether the model delivers or can continue delivering adequate results in a constantly changing environment.<br /> In the case of a ‘data drift’ the data could have been changed, like the distribution or value ranges of the data or features. Or the patterns that the model 
has learned are no longer valid and are subject to a concept drift. <a href="https://en.wikipedia.org/wiki/Concept_drift" target="_blank">[4]</a> . For example, seasonal effects or, as just happened in times of a pandemic, unexpected effects can influence the prediction quality of models <a href="https://fortune.com/2020/09/23/a-i-algorithms-had-to-change-when-covid-19-changed-consumer-behavior" target="_blank">[5]</a> .<br /> Therefore, even when the model is running, a further gate can regularly check new data and verify that it still matches the assumptions.</p><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RmA8O3V7Snmx5gt3ZdLa"><img loading="lazy" width="1024" height="397" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/RmA8O3V7Snmx5gt3ZdLa" alt="Machine Learning Quality Gates Chain" /></a> <p>Machine Learning quality gates chain including monitoring of current model quality</p></div><p>How often a model has to be retrained and which changes have to be made depends on the application and the characteristics of the new conditions. Whether it is worthwhile at all is also to be estimated, since if necessary the costs around new models to train can be not insignificant.<br /> This trade-off between cost and benefit or even criticality of the model is also a gate. But that gate is only opened for the next step, the new training, if the model is ‘bad’ enough.</p><h2>Conclusion</h2><p>As exemplified here, quality gates can be integrated at various points in a pipeline to ensure the quality of the respective artifacts of a sub-process. For this purpose, success criteria that must be met in order to pass a gate must be defined in advance and can be checked automatically.<br /> Stopping a machine learning pipeline early can save time, resources and money. After all, if a gate fails, it is foreseeable that in the 
end a sufficient prediction quality of the model can no longer be guaranteed.<br /> Finally, models must also be monitored in production to detect potential model degeneration at an early stage and respond accordingly.<br /> In addition, a number of other gates and tests can be considered to ensure that the ecosystem around the machine learning approach works in practice. However, this is beyond the scope of this article, but should not go unmentioned here <a href="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/aad9f93b86b7addfea4c419b9100c6cdd26cacea.pdf" target="_blank">[6]</a> .</p><h2>References</h2><p>[1] <a href="/wissens-hub/blog/evaluating-machine-learning-models-test-data-sets">codecentric Blog – Evaluating machine learning models: The issue with test data sets</a> </p><p>[2] <a href="/wissens-hub/blog/7-common-metrics-evaluating-machine-learning-models">codecentric Blog – Evaluating machine learning models: How to tackle metrics</a> </p><p>[3] <a href="https://de.wikipedia.org/wiki/A%2FB-Test">wikipedia – AB-Test</a> </p><p>[4] <a href="https://en.wikipedia.org/wiki/Concept_drift">wikipedia – Concept drift</a> </p><p>[5] <a href="https://fortune.com/2020/09/23/a-i-algorithms-had-to-change-when-covid-19-changed-consumer-behavior">Fortune – A.I. algorithms had to change when COVID-19 changed consumer behavior</a> </p><p>[6] <a href="https://storage.googleapis.com/pub-tools-public-publication-data/pdf/aad9f93b86b7addfea4c419b9100c6cdd26cacea.pdf">Google, Inc. – The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction</a> </p>

Evaluating machine learning models: Establishing quality gates

Sprich uns an

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

KI von der Stange – ein Beispiel aus der Industrie. KI-out-of-the-box-Lösungen gezielt einsetzen

Aus dem Inhalt:

Jetzt für unseren Newsletter anmelden