Stabile KI-Systeme aufbauen (Teil 2)

IN Machine Learning — 31 July, 2017

Ein stabiles System für künstliche Intelligenz (KI) aufzubauen, ist eine anspruchsvolle Aufgabe. Im vorherigen Blogartikel haben wir die eher technischen Aspekte behandelt – von der Datenverarbeitung und -speicherung über die Datenqualität bis zur Bereitstellung von KI-Modellen und operativer Exzellenz. 

Das technische Setup zur Erstellung von Milliarden Prognosen, die optimale Entscheidungen liefern, muss fehlertolerant und redundant sein, um leicht wieder hergestellt werden zu können, sollte einmal etwas schiefgehen. Da Prognosen in der Regel innerhalb eines engen Zeitfensters benötigt werden, muss das Setup den hohen Anforderungen des Kunden entsprechen und Service-Level-Vereinbarungen erfüllen. Eine technisch ausgefeilte Einrichtung ist jedoch „nur“ die Hälfte dessen, was benötigt wird, um ein stabiles KI-System aufzubauen. In diesem zweiten Teil konzentrieren wir uns auf das KI-Modell selbst und darauf, was es bei der Entwicklung eines robusten Prognosemodells zu beachten gilt.

build_robust_ai_systems_v1_0_01

 

Davor ist aber zu klären, was wir mit dem Begriff „stabile KI-Systeme“ überhaupt meinen. Die Software zur Implementierung des Modells sollte sorgfältig programmiert und getestet werden. Das gilt sowohl für das KI-Framework (wie z. B. TensorFlow, Torch, CNTK oder Eigenentwicklungen) als auch für das KI-Modell selbst. Selbstverständlich sollten die „üblichen Best Practices“ für die Entwicklung eines sauberen Codes sowie regelmäßige oder kontinuierliche Unit- und Integrationstests etc. angewendet werden. Neben diesen technischen Anforderungen sollte das KI-Modell selbst immer sinnvolle Prognosen erstellen. Was „sinnvoll“ bedeutet, hängt dabei vom jeweiligen Kontext ab, für den das Modell entwickelt wurde. So sollte ein KI-System, das für die Warendisposition einer Supermarktkette aufgesetzt wurde, keine Bestellung von Tausenden Kisten teuren Champagners auslösen, wenn üblicherweise nur ein paar Flaschen pro Woche verkauft werden. Es kann natürlich vorkommen, dass ein besonders guter Kunde eine Sammelbestellung aufgibt – das ist aber normalerweise eine Ausnahme, die durch den manuellen Eingriff eines Mitarbeiters in das System abgedeckt wird.

Wie kann ein Prognosesystem so „verwirrt“ werden, dass es seltsame und unnormale Prognosen auswirft?

Zunächst einmal können unpassende Algorithmen und Machine-Learning-Modelle mit inadäquaten Lernverfahren zum Übertrainieren führen und dadurch nicht mehr verallgemeinerbar sein. Das bedeutet, dass zu komplexe Vorhersagemodelle mit zu vielen freien Parametern sich alle Informationen merken, die sie während des Lernvorgangs erhalten. Während solche Modelle die Trainingsdaten zwar perfekt reproduzieren können, lernen sie aber nicht die darunter liegenden statistisch relevanten Abhängigkeiten und liefern, wenn neue oder unbekannte Daten hinzukommen, schlechtere Prognosen. Ein Best-Practice-Beispiel, um dieses Problem zu vermeiden, ist die Integration ausgefeilter Regularisierungskonzepte oder Ensemble-Methoden. Dabei werden viele verschiedene Modelle kombiniert, um ein besseres und verallgemeinerbares Ergebnis zu erhalten, als es ein einzelner Algorithmus allein liefern könnte.

Wie können Prognosemodelle robuster gemacht werden?

L. Breiman hat das sogenannte Bagging (Bootstrap aggregating) entwickelt, eine Methode, die verschiedene Versionen der gleichen Modellkomponente auf unterschiedlichen, zufällig gewählten Teilmengen der vorhandenen Daten trainiert. Im Allgemeinen werden gesonderte Stichproben und Überprüfungen durchgeführt, um das Verhalten des Modells zu beobachten und einzuschätzen, ob es mit neuen und unbekannten Daten gut funktioniert.

Es gibt dabei allerdings eine Kehrseite: Viele Variablen, die als Input für die Machine-Learning-Modelle genutzt werden, hängen von einer ganzen Reihe von Parametern ab. Diese werden „Hyperparameter“ genannt und haben nichts mit den Parametern zu tun, die später das Machine Learning an sich definieren. So nutzt zum Beispiel ein Machine-Learning-Modell einen gewichteten gleitenden Mittelwert des bisherigen Verkaufs eines bestimmten Artikels als Eingabevariable. Die Gewichtung dieses Durchschnittswerts muss jedoch ebenfalls ermittelt werden. Nur in wenigen Fällen ist ein natürlicher Wert vorhanden, der im Wesentlichen durch die Eigenschaften des Systems bestimmt wird, das er beschreibt. Meistens muss der Durchschnittswert aus den Daten errechnet werden. Die Frage ist: Welche Daten? Wenn die Trainingsdaten genutzt werden, die auch zur Optimierung des Machine-Learning-Modells zum Einsatz kommen, werden die Daten zweimal verwendet und die beiden Parametersätze – die Hyperparameter der Variablen und die Parameter des Machine-Learning-Modells – sind nicht länger völlig unabhängig voneinander. Werden jedoch die Hyperparameter der Variablen aus der unabhängigen Testprobe zur Überprüfung des Machine-Learning-Modells entnommen, könnten einige Informationen aus dieser Testprobe implizit für das Training des Modells genutzt werden. Um dieses Problem zu lösen, müsste eigentlich eine dritte Datenprobe verwendet werden, also eine, welche die Hyperparameter für die Variablen ermittelt, eine zum Training des Machine-Learning-Modells und eine zur Validierung des gesamten Modells. Doch selbst im Zeitalter von Big Data sind dafür nicht immer genügend Daten vorhanden. Man könnte meinen, dass einer Supermarktkette mit den historischen Verkaufsdaten der letzten drei Jahre sehr viele Daten vorliegen, vor allem, wenn man bedenkt, dass viele Supermarktketten Zehntausende Produkte führen, die in Hunderten Filialen täglich verkauft werden. Teilt man diese Daten jedoch in drei Datenproben auf, wären besondere Ereignisse wie Weihnachten, Ostern oder saisonale Trends jeweils nur in einem der Datensets vorhanden – kaum genug für das Machine-Learning-Modell, um tatsächlich daraus lernen zu können. Methoden wie die Kreuzvalidierung zielen darauf ab, dieses Problem zu mildern, sind aber nur schwer auf autokorrelierende Daten wie Zeitreihen oder historische Verkaufsmuster anwendbar.

Fehler finden und tolerieren?

Trotz aller Bemühungen, die beste Datenqualität sicherzustellen, sind immer noch fehlerhafte Daten möglich. Ein Beispiel: Ein Aspekt einer neuen Datenlieferung enthält einen Fehler, der bisher nicht entdeckt wurde und durch die automatische Prüfung rutscht. Auch in diesem Fall müssen die Vorhersagen, die vom KI-Modell berechnet werden, vernünftig sein und sinnvolle Ergebnisse liefern anstatt den Prozess oder das System zum Absturz zu bringen oder – schlimmer noch – eine falsche Prognose zu liefern. Obwohl die Administratoren und Data Scientists automatisch über jeden Vorfall benachrichtigt werden sollten, muss das System zuverlässig laufen, auch wenn ein Fehler aufgetreten ist. Es ist wichtig, sich um solche Vorkommnisse zu kümmern und zum Beispiel den Fehler in den Daten zu beheben und eine weitere automatische Prüfung zu implementieren. Wenn aber mehrere Milliarden Prognosen und Entscheidungen in einem engen Zeitrahmen berechnet werden müssen, ist eine gewisse Fehlertoleranz von höchster Wichtigkeit. Weit verbreitete Methoden wie die lineare Regression oder noch anspruchsvollere Maximum-Likelihood-Techniken sind besonders anfällig dafür, falsche Ergebnisse zu liefern, wenn sie mit Sonderfällen oder fehlerhaften Daten konfrontiert werden.

Adversarial Samples – eine Achillesferse für KI-Systeme?

Ein weitere Möglichkeit, KI- und Machine-Learning-Algorithmen zu „verwirren“, ist durch die sogenannten Adversarial Samples, wie sie I. Goodfellow et al. 2014 vorgestellt haben. Diese sind eigens entwickelte Datenpunkte, die KI- oder Machine-Learning-Modells dazu bringen, eine Prognose zu erstellen, die von der Wahrheit weit entfernt ist. Betrachten Sie das folgende Bild, das dem Vorabdruck von Goodfellows Veröffentlichung entnommen ist: Das Originalbild zeigt einen Pandabären, der vom KI-Algorithmus richtig als solcher erkannt wird. Durch das Hinzufügen eines ganz kleinen „adversarial component“ klassifiziert das KI-Modell den Panda fälschlicherweise als Gibbon, einen Primaten – auch wenn das menschliche Auge den Unterschied zwischen den beiden Bildern nicht wahrnehmen kann.

In einer anderen Studie haben Nguyen et al. ihren Forschungsschwerpunkt auf unkenntliche Bilder gelegt, die zu Prognosen durch das KI-System führen, auch wenn Menschen darin nichts erkennen können. Interessierte können den Code hier einsehen. Diese Beispiele befassen sich zwar mit komplexen Deep-Learning-KI-Systemen, allerdings haben N. Papernot et al. gezeigt, dass andere, viel einfachere Machine-Learning-Algorithmen wie Entscheidungsbäume genauso anfällig für Adversarial Samples sind. Wie wiederum J. H. Metzen et al. erforscht haben, können solche Bilder verheerende und sogar tödliche Auswirkungen haben. Die Forschungsarbeit konzentriert sich auf die Bedeutung, die aus Bildern erschlossen wird, welche in selbstfahrenden Autos zum Einsatz kommen. Insbesondere versuchten die Forscher die KI-Systeme so „irrezuleiten“, dass sie Fußgänger auf einer Straße nicht mehr „wahrnehmen“ konnten. Es braucht nicht viel Fantasie, um sich vorzustellen, was passieren kann, wenn ein autonomes Fahrzeug in eine Gruppe von Kindern fährt, weil es sie nicht „sehen“ kann. Adversarial Samples finden sich auch in anderen Bereichen, z. B. der automatischen Textgenerierung (Natural Language Generation – NLG), wie die neuste Forschung von S. Rajeswar et al. beweist.

In ihrem Blog weisen Goodfellow und Papernot darauf hin, wie schwer es ist, sich gegen Adversarial Samples zu schützen, weil wir zurzeit noch kein wirklich gutes theoretisches Verständnis des Herstellungsprozesses dieser Muster haben – und weil KI-Modelle mit einer beliebigen Anzahl von Dateneingaben konfrontiert werden können. Es wurden schon viele Ansätze zur Verteidigung gegen Adversarial Samples untersucht. W. He et al. zeigen, dass auch ein Ensemble von schwachen Abwehrmaßnahmen nicht zu einer starken Verteidigung führt.

Adversarial Samples können auch verwendet werden, um neue, simulierte Daten zu kreieren, die sich (fast) nicht von den Daten unterscheiden lassen, die zur Schulung des Machine-Learning-Modells verwendet werden. Diese spezifische Deep-Learning-Technik nennt sich Generative Adversarial Networks (GAN) und wurde 2014 von I. Goodfellow et al. vorgeschlagen. Das Grundkonzept basiert auf der Spieltheorie, kurz gesagt: Zwei Netzwerke treten gegeneinander an. Das generative (G) Netzwerk kreiert einen synthetischen Datensatz und das diskriminierende (D) Netzwerk schätzt die Wahrscheinlichkeit, mit welcher der Input von den Originaldaten statt von den durch G produzierten synthetischen Daten kommt. So wurde beispielsweise GANGogh auf Basis von 100.000 Bildern von WikiArt trainiert und genutzt, um neue Kunstwerke zu erstellen. In der Teilchenphysik ist es für jede Analyse zur Entdeckung neuer physikalischer Phänomene unerlässlich, Zugriff auf eine sehr große Menge von hochwertigen simulierten Ereignissen zu haben. Einer der teuersten Schritte, was Rechenleistung angeht, ist die Simulation des Verhaltens der Teilchen, die den Kalorimeter durchqueren. Dieser wird verwendet, um die Teilchenenergie zu messen. In einer aktuellen Studie beschreiben M. Paganini et al., wie dieser Schritt durch die Nutzung eines „Generative Adversarial Networks“ deutlich optimiert werden kann.

Die erste Verteidigungslinie gegen potenziell schädliche Prognosen sollte sein, von Natur aus anfällige Techniken wie die lineare Regression zu vermeiden und Regularisierungskonzepte, Ensemble-Methoden und andere Techniken anzuwenden, um ein Übertraining zu vermeiden. Durch die potenzielle Anfälligkeit für Adversarial Samples ist es jedoch unerlässlich, Kontextinformationen zu nutzen, um das System weiter zu optimieren. Es ist wichtig zu fragen: Sind die Prognosen sinnvoll? Sind die Entscheidungen, die sich daraus ergeben, vernünftig? Unternehmen, die KI-basierte Entscheidungen einsetzen, geht es vor allem darum, dass diese in Bezug auf ihre Kennzahlen optimal sind und jederzeit zuverlässig geliefert werden.

Dr. Ulrich Kerzel Dr. Ulrich Kerzel

earned his PhD under Professor Dr Feindt at the US Fermi National Laboratory and at that time made a considerable contribution to core technology of NeuroBayes. He continued this work as a Research Fellow at CERN before he came to Blue Yonder as a Principal Data Scientist.