Es genügt nicht, nur die Algorithmen zu analysieren
Zum nächsten TÜV-Termin nehme ich ein Blatt Papier mit einem Rezept für die Entwicklung meines Autos mit. Der Inhalt des Rezepts: Meine Scouts analysieren alle zugelassenen Autos in Deutschland und suchen dann jene Bauteile heraus, die am besten funktionieren und am wenigsten kosten. Daraus baue ich mein Auto. Und dieses Auto soll mir der TÜV dann schon mal vorab auf Basis des Rezeptes zulassen. Klingt absurd? Ich glaube auch nicht, dass der TÜV da mitmacht. Was bei Autos merkwürdig klingt, soll bei Software so funktionieren. Einen „Algorithmen-TÜV“ fordern immer wieder kluge Menschen in der deutschen Debatte über Software (zum Beispiel Bundesjustizminister Heiko Maas).
Trainingsdaten machen Software klug.
Wer beurteilen will, ob eine Software gut oder schlecht handelt, muss mehr tun als alle paar Monate oder Jahre Algorithmen zu prüfen. Denn es ist nicht Algorithmen allein zu verdanken, dass Software heute recht gut übersetzt, Sprache verschriftlicht, Risiken abschätzt, Nachrichtenrelevanz beurteilt, Go und Schach spielt. Die Verfügbarkeit großer Trainingsdatensätze dürfte dafür mindestens ebenso wichtig sein. Einige Hinweise darauf führt der Mathematiker Alexander Wissner-Gross an:
- 2005 feierte Google große Fortschritte seiner Übersetzungssoftware beim Übertragen aus Mandarin in Englische. Der zugrunde liegende Algorithmus war 1988 veröffentlicht worden. Doch den 1,8 Billionen Elemente umfassende Trainingsdatensatz hatte Google erst im selben Jahr zusammengetragen.
-
2011 schlug die IBM-Software Watson menschliche Gegenspieler in der Spielshow „Jeopardy“. Die Watson zugrunde liegenden Algorithmen waren seit 1991 öffentlich, die aus Wikipedia und anderen Quellen gefüllte Wissensdatenbank hatte IBM 2010 fertiggestellt.
Es ist also kompliziert.
Um das Handeln von Software zu analysieren, muss man ihr Lernmaterial kennen.
Das Bild „Algorithmen-TÜV“ erscheint sehr sinnvoll, wenn man sich Entscheider-Software wie ein Auto oder wie ein Kuchenrezept vorstellt. Also als etwas, das einmal fertig gestellt ist und dann nur noch in Intervallen weiterentwickelt wird – wenn überhaupt. Ans Auto kommt ein neuer Spoiler? Ab zum TüV. Beim Kuchenrezept verdoppeln wir die Zuckermenge? Besser prüfen. Um dieses Bild von Software aus dem Kopf zu kriegen, muss man andere Analogien lesen. Denn lernende Software funktioniert anders.
Der estnische Informatik-Doktorand Tambet Matiisen beschreibt lernende Software in diesem Essay über einen Vergleich mit menschlichem Lernen: Positive Erfahrungen verstärken trainierte Muster:
„Reinforcement learning is an important model of how we (and all animals in general) learn. Praise from our parents, grades in school, salary at work – these are all examples of rewards. Credit assignment problems and exploration-exploitation dilemmas come up every day both in business and in relationships. (…) But deep Q-networks still continue to amaze me. Watching them figure out a new game is like observing an animal in the wild – a rewarding experience by itself.“
Diese Analogie veranschaulicht zwei Dinge: Lernende Software entwickelt sich ständig fort. Und: Wie sie sich entwickelt, hängt davon ab, mit welchem Lehrmaterial sie konfrontiert ist und welche Anreize ihre Entwickler vorgeben.
Wir brauchen neue Analogien für Entscheider-Software
Eine andere großartige Analogie für die Entwicklung lernender Software hat Suresh Venkatasubramanian erdacht. Der Mann lehrt Informatik an der University of Utah. Er vergleicht lernende Software mit einem Rezept für die indische Linsensuppe Sambar. Die heute wohl weit verbreitete Vorstellung ist, dass ein Algorithmus einem Rezept nach diesem Muster entspricht: Man nehme 500 Gramm Linsen, einen Teelöffel Curry und noch etwas hiervon und etwas davon, dann koche man es so und so lange. So arbeitet lernende Software aber nicht.
Programme, die heute übersetzten, Menschen auf Fotos erkennen, Nachrichten einordnen und so weiter gleichen eher einem Verfahren, um überhaupt erst zu einem Linsensuppenrezept zu kommen. Venkatasubramanian beschreibt es so: Lernenende Software gleicht jemandem, der nur eine vage Ahnung davon hat, welche Zutaten in eine Sambar-Linsensuppe gehören. Der Koch lädt Freunde ein und lässt sie wieder und wieder nach immer neuen Konfigurationen gekochte Sambar-Varianten probieren. Er fragt die Gäste nach ihren Rezepten. Er probiert auch diese aus. Aus den Reaktionen der Gäste leitet er ab, welche Zutaten in welcher Dosis gut ankommen. Nach vielen Durchgängen wird der Koch ein Rezept für Sambar-Linsensuppe haben.
Nun stellen Sie sich vor, derselbe Koch hätte dieses Experiment in Tokio, Aarhus und Rio gemacht. Wie sehr sich die Rezepte wohl unterscheiden würden? Das ist die Stärke dieser Analogie: Sie zeigt, wie sehr es auf den Input ankommt.
Venkatasubramanians kommt zum Fazit: Algorithmen analysieren allein bringt nichts. Auf dieser Basis wird man nicht beurteilen können, was eine Entscheider-Software tut. Der Informatiker schreibt:
“Yes, we could just “look at the code”, but what we see is a mysterious alchemy in which each individual step might be comprehensible, but any “explanation” of why the code does what it does requires understanding how it evolved and what “experiences” it had along the way. And even then, you’d be hard-pressed to explain why the algorithm did what it did. If you don’t believe me, try looking at a neural network sometime.”
Eine vierte Gewalt muss Input, Output und Verarbeitung analysieren
Das sollte eine unabhängige Aufsicht lernender Software leisten:
- Überprüfen, ob die Software den Maßgaben folgt, die der Betreiber offenlegt.
-
Unerwünschte Verhaltensweisen und Folgen erkennen, die trotz Einhaltung der Maßgaben entstehen.
-
Beabsichtigte Manipulationen durch Dritte erkennen.
Um das zu leisten, genügt es sicher nicht, bloß Algorithmen zu analysieren. Man muss zudem auch die Trainingsdaten und alle von der Software getroffenen Entscheidungen einbeziehen. Es gibt einige Kontrollansätze, die mit den Input und den Output lernender Software analysieren. Beide Ansätze liefern Hinweise auf die Diskriminierung von Minderheiten – Amerikaner asiatischer Abstammung zahlen mehr für Nachhilfe, Menschen in mehrheitlich von Schwarzen bewohnten Vierteln waren länger auf Dienstleistungen und so weiter.
Was mir bei beiden Ansätzen auffällt: Sie können nur funktionieren, wenn genügend Daten offen zugänglich sind. Um lernende Software zu prüfen und alternative Entscheidungen zu kennen, müssen Trainingsdaten offen zugänglich sein.
- Auf Twitter teilen
- Auf Facebook teilen
- Auf LinkedIn teilen
- Auf Pinterest teilen
- Per E-Mail teilen
- Link kopieren
