So validieren wir AI Skills für AIOS und testen auf Resilienz und Robustheit.

Der Schutz von Privatsphäre, die Förderung von Fairness und Diversität sowie Gewährleistung von technischer Robustheit bzw. Resilienz sind Auszüge aus den ethischen Leitlinien der europäischen Union, die Leftshift One als Basis für die eigene Ethic-Policy heranzieht.

Während bzgl. der Relevanz dieser Punkte Konsens herrscht, ist es noch ungeklärt, wie die Einhaltung dieser Punkte sichergestellt werden kann. In diesem Artikel wird aufgezeigt, wie Leftshift One an diese Aufgabenstellung herangeht. Erfahren Sie wie Skills gesamtheitlich getestet werden können und was Fraktale mit Skill-Validierung zu tun haben.

Als Skills bezeichnen wir abstrakte Konstrukte, welche innerhalb des AI Operating Systems ausgeführt werden können. Aufgrund ihres flexiblen Aufbaus können diese für die unterschiedlichsten Aufgabenstellungen verwendet werden.

Diese Flexibilität resultiert aus dem Ansatz, das Skills aus den drei Aspekten Daten, Code, sowie AI/ML zusammengesetzt werden können. Diese Flexibilität bei der Erstellung von Skills setzt eine gesamtheitliche Betrachtung bei der Validierung von Skills voraus.

Wenn es darum geht die Anzahl sowie den Umfang von Softwaretests zu beschreiben, wird meist die Testpyramide als Anhaltspunkt genannt. Eine Testpyramide visualisiert den Ansatz, dass bestimmte Testkategorien häufiger als andere Kategorien bei der Validierung von Softwarekomponenten eingesetzt werden sollen.

Info: Skills sind polyglot und können somit in den unterschiedlichsten Programmiersprachen erstellt werden. In diesem Artikel werden ausschließlich mit Python erstellte Skill-Bestandteile dargestellt.

Der Ansatz einer klassischen Testpyramide setzt jedoch eine gewisse Homogenität der Problemstellungen der zu testenden Softwarekomponenten voraus. Da Skills flexibel aus den drei Bausteinen erstellt werden können, benötigen diese drei Aspekte jedoch auch unterschiedliche Teststrategien.

Um diese Anforderung erfüllen zu können, ist es notwendig, für jeden Aspekt des Skills sowie dem Skill als Gesamtes eine eigene Teststrategie zu definieren. Aus einer klassischen Testpyramide wird somit ein Fraktal, genauer ein Sierpiński-Dreieck, welches jedem Aspekt des Skills sowie dem Skill als Ganzes eine eigene Teststrategie zuteilt.

Im Falle von Compound Skills (Skill, der mehrere Skills gruppiert) können diese Sierpiński-Dreiecke auch zu einem großen Fraktal zusammengebaut werden. Prinzipiell lässt sich ein Compound Skill als eine Verkettung mehrerer Skills definieren.

compoundSkill = skill(skill(x))

Somit lässt sich auch die gesamte Teststrategie eines Compound Skills als Kombination der einzelnen Skill-Strategien darstellen. Sowohl die einzelnen kleinen Dreiecke wie auch die größeren Dreiecke unterliegen denselben Teststrategien.

1.) Die Daten-Perspektive

Als Daten betrachten wir hier jene Informationen, welche herangezogen werden, um AI/ML-Modelle trainieren zu können. AI/ML-Modelle sind nur so gut, wie die Daten, mit denen diese trainiert wurden, es zulassen.

Oft verhindern Datenschiefstände oder Vorurteile (Bias) in den Daten nicht nur, dass ein Modell fair ist, sondern auch, dass es ausreichend generalisiert. Es gibt noch keinen einheitlichen Weg, um dieses Problem zu lösen. Für uns hat sich jedoch herausgestellt, dass wir die Problemstellung auf technischer und organisatorischer Ebene angehen können.

Auf der technischen Seite geht es darum, Mechanismen und Konzepte bereitzustellen, welche die Fairness und Diversität von AI-Modellen dauerhaft gewährleisten. Diesbezüglich haben wir ein Trainingssystem entwickelt, welches es uns ermöglicht, AI-Modelle über den gesamten Entwicklungsprozess von der Definition bis zur Ausführung hinsichtlich der Einhaltung der gewünschten Charakteristika zu überprüfen.

Das Trainingssystem sieht Integrationspunkte vor, bei denen Validierungslogiken eingebracht werden können. Sofern diese Validierungen der entsprechenden Signatur entsprechen, können beliebige Frameworks, Libraries und Konzepte für die Validierung eingesetzt werden.

Info: Skills werden in einem GIT System in einer entsprechenden Struktur abgelegt. Damit Skill Tests vom AIOS gefunden werden, müssen diese im test Folder abgelegt werden. Für Python Skills sieht die Struktur folgendermaßen aus:

1.1) Schema Tests

Ein großer Anteil der Datenvalidierung ist die Gewährleistung der Datenkonsistenz mittels Schema Tests. Hierbei geht es darum, dass Daten durchgehend einheitliche Informationen ausweisen. Ein Schema definiert die erwarteten Eigenschaften der Daten. Diese Eigenschaften sind:

  • Welche Features sind notwendig?
  • Welche Datentypen haben die Features?
  • Welche Restriktionen haben einzelne Features?

Schema-Definitionen beschreiben somit einen korrekten Datensatz und können deshalb verwendet werden, um Fehler in Daten zu erkennen.

Diese Konsistenz muss zudem über alle Batches sowie Splits (Test, Train, Validation) einheitlich sein. Bei der Implementierung von Tests dieser Kategorie setzen wir auf unsere in-house Library DataRiot. Mittels dieser Softwarebibliothek ist es u.a. möglich, Schema Files zu erstellen, welche in weiterer Folge gegen die Daten angewendet werden können.

Diese Schema Files können auch mittels Schema Evolution nachträglich angepasst werden, sodass nachträgliche Änderungen der Datenstruktur unterstützt werden.

Der Einsatz der Schema Tests führt auch zu einem mentalen Shift hin zu einer daten-zentrischen Sicht auf Machine Learning, bei der ein Schema nicht nur für die Datenvalidierung, sondern darüber hinaus auch zur Dokumentation von Features verwendet wird.

Ausgehend von einem Schema können (a) die Daten eines Datensets als gesamtes oder (b) einzelne Datenpunkte aus dem Datenset validiert werden. Somit ist es möglich, die Korrektheit eines Datensets zu überprüfen. Unter anderem können mit dieser Vorgehensweise schon vorab einige Probleme mit Daten entdeckt werden:

  • Unerwartete Features
  • Fehlende Features
  • Out of domain Values für Feature-Kategorien
  • Zu geringer Anteil an Beispielen mit bestimmten Features
  • Ungültiger Datentyp
  • Nichteinhaltung von Datenrestriktionen

Einige Fehler in den Daten zeigen sich erst beim Vergleich über verschiedene Datasets. Aus diesem Grund bietet die DataRiot Library neben der Funktionalität, Daten gegen ein Schema zu validieren, auch die Möglichkeit, Datenschiefstände (Skew) bzw. Datenabweichungen (Drift) zu identifizieren.

Bei der Drift-Erkennung wird für kategorische Merkmale und zwischen aufeinanderfolgenden Datensets unterstützt, z.B. zwischen verschiedenen Trainingstagen. Die Drift-Erkennung wird mittels einer L-infinity-Distanz bemessen. Damit ist man in der Lage, in relativen Angaben den Schwellenabstand zu bestimmen. Die Einstellung des richtigen Abstands ist typischerweise ein iterativer Prozess, der Domänenwissen und Experimente erfordert.

Datenschiefständen werden in DataRiot in die Kategorien Schema-Skew, Feature-Skew und Distribution-Skew unterteilt. Ein Schema-Skew tritt auf, wenn die Trainings- und Inferenz-Daten nicht dem gleichen Schema entsprechen. Alle erwarteten Abweichungen zwischen den beiden Datensets (z.B., dass das Label-Feature in den Trainingsdaten) sollten mittels Namespaces im Schema angegeben werden.

Ein Feature-Skew tritt auf, wenn die Feature-Werte, auf denen ein Modell trainiert wurde, sich von den Feature-Werten unterscheiden, die es zum Zeitpunkt der Inferenz sieht. Dies kann zum Beispiel passieren, wenn:

  • eine Datenquelle zwischen dem Training und der Inferenz geändert wird.
  • Unterschiede bei der Logik für die Erzeugung von Merkmalen zwischen Training und Inferenz bestehen.

Eine Distribution-Skew tritt auf, wenn sich die Verteilung des Trainingsdatensatzes signifikant von der Verteilung des Inferenz-Datensatzes unterscheidet. Eine der Hauptursachen für die Verteilungsverschiebung ist die Verwendung unterschiedlichen Codes oder unterschiedlicher Datenquellen zur Generierung des Trainingsdatensatzes. Ein weiterer Grund ist ein fehlerhafter Stichprobenmechanismus, der eine nicht repräsentative Teilstichprobe der Aufschlagdaten zum Training auswählt.

1.2) Data Analysis Tests

Die zweite Testkategorie in der Daten-Testpyramide umfasst Data Analysis Tests. Hierbei geht es darum, dass sichergestellt werden soll, dass Vorurteile aus den Datensets weitestgehend entfernt wurden. Vorurteile in Datensets können in den unterschiedlichen Formen auftreten. Zu den häufigsten Data Bias-Typen zählen:

  • Confirmation Bias
    Ein Confirmation Bias tritt auf, wenn die Person, die die Datenanalyse durchführt, eine vorgegebene Annahme beweisen will. Sie sucht dann so lange in den Daten, bis diese Annahme bewiesen werden kann. Z.B. durch absichtliches Ausschließen bestimmter Variablen aus der Analyse.
  • Selection Bias
    Ein Selection Bias tritt auf, wenn Daten subjektiv ausgewählt werden. Infolgedessen spiegelt die verwendete Stichprobe die Grundgesamtheit nicht gut wider.
  • Outlier
    Ein Outlier ist ein extremer Datenwert, der viel höher oder viel niedriger als die Region (fast) aller anderen Werte ist. Diese Ausreißer können Resultate von ML-Modellen stark verfälschen, da Entscheidungen evtl. auf der Grundlage eines falschen “Durchschnitts” getroffen werden.
  • Scheinkorrelation
    Eine Scheinkorrelation kann zu der Annahme führen, dass es eine Ursache-Wirkungs-Beziehung zwischen zwei Variablen gibt, wenn tatsächlich eine andere Variable hinter dem Phänomen steht.

Die beiden Bias-Typen Confirmation Bias und Selection Bias lassen sich nur durch organisatorische Maßnahmen in den Griff bekommen. Auf organisatorischer Seite geht es darum, Diversität in den Entwicklungsprozess zu bringen. Diesbezüglich haben wir das Thema Diversität in vier Aspekte aufgeteilt.

  • Diversity-of-people
    Darunter versteht man, dass unterschiedlichste Charaktere in unterschiedlichen Altersgruppen und kulturellen Backgrounds im Team beteiligt sein sollten, um mehrere Perspektiven auf das Problem zu bekommen.
  • Diversity-of-data
    Datensätze müssen repräsentativ, fair und ethisch korrekt sein.
  • Diversity-of-modeling
    Hierbei geht es im Grunde darum, dass man unterschiedlichste Ansätze zur Erstellung eines Modells in Betracht ziehen soll. Auch sind Kombinationen von unterschiedlichen Modellen in Form eines Ensemble-Modells einzelnen Modellen vorzuziehen.
  • Diversity-of-mind-set
    Hierbei nehmen Mitarbeiter mithilfe von Kreativitätstechniken unterschiedliche Perspektiven auf dieselbe Problemstellung ein.

Die Bias-Typen Outlier sowie Scheinregression lassen sich schwer in einem generalisierten Ansatz überprüfen. Aufgrund der verschiedenen Art und Weisen wie diese Bias-Typen in Daten beinhaltet sein können obliegt es dem Skill Engineer, entsprechende Data Exploration vorzunehmen.

Diesbezüglich werden von einem Entwickler implementierte Testklassen in das Trainingssystem eingebracht. Beispielsweise könnten Outlier mithilfe einer Outlier Detection einfach erkannt werden. Des Weiteren können weitere Machine Learning-Mechanismen angewendet werden, um Scheinregressionen finden zu können.

2.) Die Code-Perspektive

Die Flexibilität von Skills erlaubt es, diese gänzlich ohne AI-Aspekte, beispielsweise bei der Implementierung von algorithmischen Skills, zu erstellen. Algorithmische Skills repräsentieren somit Softwarebausteine, welche mit der klassischen Testpyramide getestet werden können.

Aus diesem Grund werden aus Code-Perspektive Unit Tests sowie Integration Tests für die Validierung der Code-Bestandteile von Skills herangezogen. Der Unterschied zwischen auf Skill basierenden Unit Tests und Integration Tests besteht darin, dass bei der Integration Test-Variante die Einbettung in das AIOS simuliert wird.

Betrachten wir als Beispiel einen auf spacy basierenden Skill, welcher die Tokens des Payload-Textes wieder als Rückgabewert zurück liefert.

Eine UnitTest Implementierung für diesen Skill könnte folgendermaßen aussehen:

Und eine Integration Test-Implementierung folgendermaßen:

3.) Die AI/ML-Perspektive

Im Gegensatz zu den Data Tests werden bei den Model Tests nicht die Daten an sich, sondern die Modelle, welche mit den Daten trainiert wurden, validiert. Die Erstellung von Modellen ist meist eine Black Box für die übrigen Teile der Plattform, einschließlich des Datenvalidierungssystems.

Dies kann problematisch für die Qualität der Modellergebnisse sein, da während des Trainings weitere Datenverarbeitungen durchgeführt werden können.

Ein Bias kann nicht nur aufgrund von Daten, sondern auch aufgrund von falschen algorithmischen Entscheidungen in ein Modell trainiert werden. Beispielsweise könnten bei einer Trainingspipeline eines AI/ML-Modells Designentscheidungen getroffen werden, welche in weiterer Folge zu impliziten Annahmen führen, welche gegen die Schema-Repräsentation der Daten sprechen.

Beispiele hierfür sind weiteres Preprocessing der Daten oder auch die Auswahl der AI/ML-Architektur bzw. der Hyperparameter-Einstellungen, wie der Lossfunction (z.B. L1 Loss vs. L2 Loss). Um diese Fehler aufzuzeigen, werden auf der untersten Ebene der AI/ML-Testpyramide Fuzzy Tests ausgeführt. Dabei werden basierend vom Schema synthetische Eingabedaten generiert, welche dann dem Modell als Eingabedaten überreicht werden.

Dabei können sowohl schema inbound (Daten entsprechen dem Schema) als auch schema outbound (Daten entsprechen nicht dem Schema) Fuzzy Tests generiert werden.

Bei den Bias & Fairness Tests erstellen Skill Engineers je zu überprüfender Kategorie Testcases, welche die Precision sowie Recall-Metrik als Basis heranziehen, um zu bestimmen, ob das Modell fair und vorurteilsfrei agiert.

Diese Vorgehensweise kann gut anhand eines plakativen Beispiels illustriert werden. Stellen wir uns ein fiktives HR-System für einen Technologiekonzern vor, der anhand der Bewerbungsunterlagen entscheidet, ob ein Bewerber zu einem Gespräch eingeladen werden sollte oder nicht. Die einzelnen Bewerber können hierbei in die Kategorien A bzw. B eingeteilt werden.

Alle Bewerber

True Positive:      7.324False Positive:     1416
True Negative:    6.207False Negative:   1.212

Precision=83,8%, Recall=85,8%

Bewerber Kategorie A

True Positive:      1.202False Positive:     780
True Negative:    1.154False Negative:   732

Precision=60,6%, Recall=62,1%

Bewerber Kategorie B

True Positive:      6.122False Positive:     636
True Negative:    5.053False Negative:   480

Precision=90,6%, Recall=92,7%

Wie man anhand dieses fiktiven Beispiels erkennen kann, werden Bewerber von der Kategorie A von dem Modell benachteiligt. Ein derartiges System muss somit überarbeitet werden und darf nicht für die Produktion freigeschalten werden.

4.) Die Skill-Perspektive

Wenn die Daten, das Modell sowie der Code eines Skills durch alle Testinstanzen gekommen sind, wird abschließend noch der Skill als gesamte Einhalt validiert. Hierbei werden im konkreten zwei Testarten unterschieden.

Bei der ersten Testart handelt es sich um Compliance Tests. Compliance Tests validieren Skills als gesamte Einheit und werden wiederum in drei Kategorien eingeteilt:

  • Ground Truth Tests
    Testcases welche unbedingt erfolgreich durchlaufen müssen, damit ein Skill als verwendbar deklariert wird. Beispielsweise könnten für kritische Anwendungen die Must-Have Cases abgetestet werden.
  • Non-Functional Tests
    Hierbei werden Anforderungen an die Memory Auslastung oder dem Laufzeitverhalten im generellen validiert. Diesbezüglich werden Tresholds definiert, welche nicht überschritten werden dürfen. Diese können auch relativ zwischen Skill Versionen definiert werden.
  • Baseline Tests
    Baseline Tests stellen sicher, dass Skill-Version zunehmend besser werden. Dies ist vor allem für das Continuous Online Training von Skills relevant. Das AIOS kann so konfiguriert werden, dass Laufzeitinformationen eines Skills in einen Feedbackmechanismus hinsichtlich der Erstellung einer neuen Skill-Version zurückgespielt werden können. Somit ist es möglich, dass ein Skill einerseits automatisch laufend weiter verbessert wird und andererseits die neue Skill-Version laufend mit den neuen Feedbackdaten validiert wird. Standardmäßig ist eine Benutzerinteraktion erforderlich, um ein neues Modell für die Produktion freizugeben (Human-in-the-loop). Diese Vorgehensweise kann auch umkonfiguriert werden, sodass ein Benutzer informiert wird, wenn das System eine neue Skill-Version einspielt.

Baseline Tests werden durchgeführt, indem unterschiedliche Skill-Versionen gegen sich selbst antreten. Zu Beginn wird ein initiales Baseline-Modell verwendet. Sofern ein geeignetes Baseline-Modell existiert, kann dieses verwendet werden.

Alternativ wird ein Random Baseline-Modell herangezogen. Sobald ein Skill Release erstellt wurde, wird die vorherige Version als Baseline für die nächste Skill-Version verwendet. So wird sichergestellt, dass ein Skill stets besser als seine Vorversionen ist.

Contract Tests

Analog wie die Daten eines Skills unterliegen auch Skills als Gesamtes einem Schema. Dieses Schema gibt an, welche Daten an einen Skill geschickt werden und welche Daten dieser Skill wieder zurück liefert.

Nach dem erfolgreichen Durchlauf aller Testschritte ist ein Skill bereit, in das Produktivsystem deployed zu werden. Während der Skill-Validierung wurden nicht nur funktionale, sondern auch nicht funktionale Anforderungen überprüft.

Besonders ist hierbei auch die Validierung von ethischen Anforderungen hervorzuheben. Neben dem Vorteil der Gewährleistung ethischer Wertevorstellungen wird dadurch auch eine schnellere Innovation ermöglicht.