Techblog

Ein KI-System muss Fehler machen dürfen

Von Janina Nuber

16. Dezember 2020

Theoretische Einordnung

KI ist ein enorm weites Feld. Es gibt in der KI Lösungen, die mathematisch beweisbar immer fehlerfrei sind – z.B. Logik-Programme, die mit deklarativer Programmierung entwickelt werden. KI ist daher nicht mit Machine Learning synonym zu setzen, insbesondere nicht im Kontext des Fehlermachens. Wenn wir in diesem Beitrag von KI reden, beziehen wir uns daher nur auf den Teilbereich der KI, der von Machine Learning  (ML) getrieben ist.

Was sind „Fehler“?

Eine Maschine (also im Bereich der KI: ein Computer) hat kein Bewusstsein, keinen Willen, keine persönlichen Ziele und Motivationen. Sie kann daher keine „Fehler“ machen in dem menschlichen Sinne, dass sie aus Absicht, aus Nachlässigkeit oder durch ein Missgeschick etwas „falsch“ macht. In diesem Punkt haben klassische Software, in deren Architektur keine Machine Learning Komponenten enthalten sind, als auch moderne ML-Systeme eines gemeinsam: Sie können keine Fehler machen im Sinne eines versehentlichen oder willentlichen Regelbruchs. Auch die Vorstellung, dass eine Maschine überhaupt eine Fehlberechnung tätigt, ist anzuzweifeln (vgl. "There is no such thing as miscomputation" von Joe Dewhurst). 

Wenn ein ML-Modell ein Katzenbild als Hundebild klassifiziert, nimmt der Mensch das zwar als Fehler wahr. Richtig und falsch ist aber nur relativ dazu, was wir Menschen als Output des Systems erwarten. Wenn wir von Fehler sprechen, meinen wir, dass der Output der Software nicht unseren Erwartungen entspricht.  Unsere Erwartungen drücken wir Data Scientists in technisch-quantitativen Zielen aus (mehr dazu später).

Die eigentliche Frage lautet also nicht: Darf ein ML-System Fehler machen? Sondern besser: Muss ein ML-System unsere Erwartungen jederzeit vollkommen erfüllen? Oder darf es an unseren Zielen scheitern?

Wo liegen die Ursachen für unerfüllte Erwartungen? 

Es gibt einen markanten Unterschied zwischen ML-Systemen und klassischer Software: Bei klassischer Software definiert der Programmierer explizit Wenn-Dann-Regeln, die festlegen, wie ein gegebener Input zu einem Output umgewandelt werden soll. In ML-Systemen, insbesondere in Deep Learning Modellen, muss der Programmierer solche Regeln nicht definieren. Der (hoffentlich) beste Pfad, einen Input zu einem Output zu verarbeiten, wird durch den Algorithmus selbst gelernt (auch dazu später mehr).

Und dennoch haben die Entscheidungen des Programmierers einen erheblichen Einfluss darauf, wie sich das ML-System verhält. Es gibt mehrere Quellen, aus denen sich potenzielle Unsicherheiten in ML-Systemen ergeben:

  • Die Übertragung der real world task in eine machine task, also die grundsätzliche Modellierung des zu lösenden Problems (Klassifikation? Clustering? Vorhersagen?)
  • Die konkrete Modellarchitektur (LSTM/CNN/Regressions-Modelle?)
  • Der Trainingsaufbau (Stichwort Hyperparameter-Tuning)
  • Die Generierung, Auswahl und Vorverarbeitung der Daten (Stichwort Preprocessing)
  • Die inhärente (Nicht)-Ambiguität und (Nicht-)Vollständigkeit der verfügbaren Daten

Lange bevor das ML-System in einem realen Anwendungsfall zum Einsatz kommt, bestimmen diese Faktoren, welchen Weg der Algorithmus während der Trainingsphase lernt, um einen Input zu einem Output zu verarbeiten.

Das bedeutet: Wenn ein ML-System unerwartete Outputs liefert, nachdem es trainiert wurde, den Input-Output-Pfad zu lernen, wurde die Ursache für dieses Verhalten von außen in das System eingebracht. Es kann also nicht das ML-System selbst schuld daran sein, dass es unerwartete Ausgaben liefert, sondern die Entscheidungen und Umstände, die es geprägt haben.

Muss ein KI-System unsere Erwartungen stets erfüllen? 

Doch eines ist eben entscheidend zu verstehen - dass das Fehlermachen ein Teil der Entwicklung von ML-Systemen ist. Machine Learning „lernt“ die Berechnungsregeln und zu jedem Lernprozess gehören Fehler, aus denen das Lernen überhaupt erst möglich ist. Und bei jedem Lernprozess stellt sich die Frage, wann das Lernen vorbei ist - kann etwa ein Mensch eine Fähigkeit je so perfekt beherrschen, dass es wirklich nichts mehr zu lernen gäbe? Kann man ein ML-System so trainieren, dass es keine Fehler mehr macht? 

Das Training von ML-Modellen läuft über eine mathematische Funktion ab („Fehlerfunktion“), die eine mathematischen Differenz zwischen dem erwarteten Modell-Output und dem tatsächlich gelieferten Modell-Output minimiert. Vereinfacht gesagt: Am Ende eines Trainings wird das Modell gewählt, das am seltensten einen unerwarteten Output liefert - also z.B. am wenigsten Hunde als Katzen und Katzen als Hunde klassifiziert. Das Ganze ist ein Minimierungsproblem - mathematisch kann das Modell darauf trainiert werden, die Häufigkeit von unerwarteten Modell-Outputs auf einen möglichst kleinen Wert zu setzen - das bedeutet aber nicht, dass das Modell es schaffen muss, diese Häufigkeit vollständig auf 0 zu setzen.

Es gibt Bemühungen, die Unsicherheit im Output von ML-Modellen zu quantifizieren. Viele ML-Systeme sind so gestaltet, dass sie mehrere mögliche Outputs angeben, denen Wahrscheinlichkeiten oder Confidence-Werte zugeordnet sind. Sie drücken aus, wie sicher sich ein ML-Modell ist, wenn es z.B. ein Stopschild als Stopschild klassifiziert. Ist sich das Modell sehr unsicher, könnte man die Entscheidung dann an den Menschen weitergeben. Es ist jedoch nach wie vor ein nicht vollständig gelöstes Problem, wie man ML-Modelle so gestalten kann, dass sie „elegant versagen“ - d.h., dass sie z.B. im Falle von Input-Daten, auf denen sie nicht trainiert wurden, die Information ausgeben, dass sie keinen verlässlichen Output liefern können.

Um es also deutlich zu sagen: Ein ML-System muss zweifeln dürfen. Mehr noch: Es muss an den Erwartungen, die wir an es setzen, scheitern dürfen. Denn es sind unsere nicht-perfekten Entscheidungen und unsere nicht-perfekten Daten, die das ML-System prägen. Aber wir bestimmen die Ziele, an denen es scheitern darf.

Praktische Lösungsstrategien

Wir planen in unserer praktischen Arbeit mit ML-Modellen also immer unerwartete Ergebnisse mit ein. Unsere Erfolgsstrategie für ML-Projekte besteht dabei aus zwei Teilen, die während des gesamten Projektverlaufs ineinandergreifen: die transparente Kommunikation mit dem Kunden & ein iterativer Arbeitsprozess.

Transparente Kommunikation mit dem Kunden

Verhält sich ein ML-System anders als erwartet, kann das einen negativen Impact haben, noch lange bevor das System überhaupt produktiv zum Einsatz kommt – nämlich auf die Zufriedenheit unserer Kunden noch während der Entwicklungsphase. Bei kaum einer anderen Art von IT-Projekt ist frühzeitiges Erwartungsmanagement mit dem Kunden so wichtig wie bei ML-Projekten. Es ist ein entscheidender Teil unserer Arbeit, den Kunden dazu zu befähigen, ein Verständnis dafür zu entwickeln, dass es in ML-Modellen inhärente Fehler gibt (und wir diese Fehler explizit ausweisen). Von Anfang an ist es also ein Ziel unserer Kommunikation mit dem Kunden, ihn über die Fallstricke von ML-Projekten aufzuklären, um fehlgeleitete Erwartungen in der Wurzel zu verhindern.

Damit geht einher, dass wir zu Projektbeginn gemeinsam mit dem Kunden eine umfassende Anforderungsanalyse und -spezifikation erstellen. In der Anforderungsspezifikation halten wir die Kundenerwartungen und Projektziele fest – damit haben wir eine Kommunikations- und Bewertungsgrundlage für den Erfolg des ML-Projekts während des gesamten Projektverlaufs. Wie wir diese Ziele definieren, ist Teil unseres iterativen Arbeitsprozesses.

Iterative Arbeitsweise nach CRISP-DM

Wir bei MaibornWolff haben das Prozessmodell nach CRISP-DM (Cross-industry standard process for data mining) als Teil unserer Erfolgsstrategie verinnerlicht.

KI muss Fehler machen

 

CRISP-DM ist eines der meistverbreiteten Prozessmodelle im Bereich Data Mining bzw. Data Science. Typischerweise steht und fällt in einem Data Mining Projekt alles damit, die verfügbaren Daten zu explorieren und mit ihnen zu experimentieren. Daher kann man die Ansätze des Data Mining direkt auf ML-Projekte übertragen.

CRISP-DM beschreibt eine zyklische, iterative Folge von sechs Arbeitsschritten, um von einem Business-Problem zu einer datengetriebenen Lösung zu gelangen:

  • Business Understanding (was ist das eigentliche Problem des Kunden in seinem Geschäftskontext)?
  • Data Understanding (wie ist die Qualität und Quantität der verfügbaren Daten?)
  • Data Preparation (welchen finalen Datensatz nutzen wir als Arbeitsgrundlage?)
  • Modeling (welche Modelle probieren wir zur Lösung des Problems?)
  • Evaluation (welches Modell löst das Problem am besten?)
  • Deployment (wie binden wir das Modell in die Produktivumgebung des Kunden ein?)

Die Kundenerwartungen, also die Projektziele und Kriterien für den Projekterfolg, können wir nur dann sinnvoll in der Anforderungsspezifikation festhalten, wenn wir verstehen, was der Kunde aus seiner Business-Perspektive eigentlich erreichen will – die erste Phase des CRISP-DM ist daher maßgeblich. Deshalb ist es ein bedeutender Teil unserer Arbeit, die Business-Ziele des Kunden zu identifizieren, strukturieren und in technische Ziele (nennen wir es: Data-Science-Ziele) zu übersetzen.

Zum Beispiel könnte unser Kunde sagen: "Ich möchte meine Produktionskosten um mindestens 3% senken, indem defekte Teile frühzeitig erkannt werden."

In diesem Fall ist das Business-Ziel also sehr eindeutig: Senkung der Produktionskosten um mindestens 3%. Aber: Business-Ziele sind nicht immer so spezifisch und objektiv messbar. Ein Kunde kann auch mit einer wagen Vorstellung von qualitativen Business-Zielen zu uns kommen, in etwa:

Ich möchte besser verstehen, aus welchen Gründen unsere Kunden in unseren Call-Centers anrufen“.

Unsere kritische Leserschaft mag sich daher an dieser Stelle vermutlich zwei Fragen stellen:

  • Angenommen der Kunde kommt ohne ein spezifisches, vorformuliertes Business-Ziel oder nur mit einer groben Zielvorstellung zu uns - wie genau gehen wir vor, um das Business-Ziel von Grund auf zu identifizieren bzw. mit dem Kunden gemeinsam zu schärfen?
  • Oder aber der Kunde tritt tatsächlich mit einem spezifischen, vorformulierten Business-Ziel an uns heran - wie verifizieren wir, ob es wirklich den Kern des zu lösenden Problems trifft oder ob das wirkliche Business-Ziel ein anderes ist?

Um ehrlich zu sein: Diese Fragen muss man sich für jedes IT-Projektvorhaben stellen – unabhängig davon, ob Machine Learning zum Einsatz kommt. Und die kurze Antwort darauf lautet: Durch Erfahrung, Fachwissen, Intuition, und letztlich durch eine Vielzahl möglicher Lösungsbausteine wie Datenanalysen, Untersuchungsaufträge, Prozessdurchstiche, Schreibtischtests, Anforderungsanalysen, Machbarkeitsstudien und Business Case Analysen.

Aber zurück zum eigentlichen Thema. Angenommen wir haben das treffende Business-Ziel (bzw. auch mehrere Business-Ziele) nun erfolgreich herausgearbeitet (das können quantitative oder qualitative Business-Ziel-Formulierungen sein) - wie genau gehen wir vor, um daraus das Data-Science-Ziel abzuleiten?

Beschäftigen wir uns noch einmal mit dem Kunden, der seine Produktionskosten um 3% senken möchte. Dazu müssen wir zunächst herausfinden und quantifizieren, wie sich defekte Teile auf die Produktionskosten auswirken und damit, wie viele der defekten Teile erkannt werden müssen, um die Produktionskosten um 3% zu senken. Wir stellen uns also die Frage: Wie gut muss ein Modell sein, um das Business-Ziel zu erreichen? Je nach Business-Problem sind andere Modelle und andere Evaluationsmaße nötig. Die passenden Modelle und Evaluationsmaße zu finden ist Teil unseres iterativen Experimentierens während der ersten Iteration im CRISP-DM-Zyklus, und zwar in den Phasen von Data Understanding bis Evaluation. Im letzten Schritt der ersten Iteration, also in der Evaluation, vergleichen wir schließlich die ersten Data-Science-Ergebnisse mit den Business-Zielen. Aus diesen Erkenntnissen können wir dann am Ende der ersten Iteration in der Anforderungsspezifikation das Data-Science-Ziel festhalten: z.B., dass ein Klassifikations-Modell, das defekte Bauteile erkennt, eine Classification Accuracy von mindestens 85% haben muss, um das Business-Ziel zu erreichen.

Erst wenn dann unsere ML-Lösung die so spezifizierten Business-Ziele und Data-Science-Ziele nicht erfüllt, ist es gerechtfertigt, wirklich von „Fehlern“ zu sprechen.

Es bleibt aber die Frage: Wie definieren wir, wann eine ML-Lösung wirklich gut genug ist, um als finale Endlösung an den Kunden abgegeben zu werden? Schließlich geht es immer etwas besser. Ganz einfach: Wenn unser Kunde mit der Lösung glücklich ist. Und wenn der Kunde nicht zufrieden ist, ziehen wir auch in Betracht, einen anderen Lösungsansatz zu wählen, der womöglich gar nichts mit Machine Learning zu tun hat.

Letztlich sind „Fehler“ und nicht erfüllte Erwartungen bei ML-Lösungen wie die berühmten Risiken & Nebenwirkungen bei Medikamenten. Wenn man keine „Fehler“ akzeptieren will, darf man Machine Learning nicht verwenden. Und schließlich gilt: Machine Learning ist trotz inhärenter „Fehler“ die beste Lösung für viele Probleme, die man ohne Machine Learning lange Zeit gar nicht lösen konnte!

Quellen & weiterführende Links:

Dewhurst, Joe  (2020) There Is No Such Thing As Miscomputation.
URL: http://philsci-archive.pitt.edu/id/eprint/17000 (2020-08-13)

https://the-modeling-agency.com/crisp-dm.pdf