Vielleicht kennen Sie das aus der Arbeit mit generativer KI: Etwas funktioniert, und Sie wissen nicht, warum. Ein generiertes Stück Code läuft durch, eine vorgeschlagene Lösung trägt, eine Diagnose stimmt. Das Ergebnis liegt überprüfbar und brauchbar vor Ihnen, nur den Weg dorthin könnten Sie nicht rekonstruieren, nicht einmal grob nacherzählen.

Mir selbst erschien das lange als Nebensächlichkeit, als bloßer Preis der Bequemlichkeit. Inzwischen halte ich es für die eigentlich interessante Frage. Denn was sich hier verschiebt, ist nicht nur die Geschwindigkeit, mit der Lösungen entstehen, sondern das Verhältnis zwischen einem Ergebnis und dem Verständnis, das wir früher mit ihm zusammen erworben haben. Es lohnt sich zu fragen, ob dieser Verlust ein Problem ist – und falls ja, wo genau.

Das funktionierende Ergebnis ohne den Weg dorthin

Wer ein Problem selbst löst, bekommt traditionell zwei Dinge auf einmal: die Lösung und das Verständnis, wie sie zustande kommt. Von beiden ist das Verständnis der haltbarere Teil. Die konkrete Lösung gilt für genau diesen einen Fall, das Verständnis trägt zum nächsten, leicht anderen Fall.

Mit generativer KI fallen diese beiden Dinge auseinander. Ich erhalte die Lösung, ohne das Verständnis gleich mitzubekommen. Ein kniffliger regulärer Ausdruck, eine Build-Konfiguration, die plötzlich durchläuft, ein Fehler, der durch einen akzeptierten Vorschlag verschwindet: Das Resultat steht, der Weg bleibt im Dunkeln.

Das ist nicht dasselbe wie der Gebrauch einer Bibliothek oder das Vertrauen in einen Compiler. Dort hat jemand verstanden, was geschieht, und die Abstraktion ist dokumentiert, stabil und nachlesbar. Bei einem generierten Ergebnis ist die Herleitung selbst im Prinzip undurchsichtig, und sie fällt bei jeder Anfrage ein wenig anders aus.

Der entscheidende Unterschied liegt in der Übertragbarkeit. Ein Ergebnis ist ein Einzelstück, Verständnis ist wiederverwendbar. Wo mir das Verständnis fehlt, fehlt mir die Fähigkeit, den nächsten Fall aus eigener Kraft zu lösen. Ich bleibe auf das Werkzeug angewiesen, nicht weil es bequemer ist, sondern weil ich es selbst nicht mehr könnte.

Das Tückische ist, dass sich das Übernehmen eines Ergebnisses anfühlt wie Lernen. Schließlich habe ich etwas geschafft, das ich vorher nicht konnte. Aber der Eindruck täuscht: Was zugenommen hat, ist die Zahl der erledigten Aufgaben, nicht die Tiefe dessen, was ich selbst beherrsche. Geliehene Kompetenz fühlt sich an wie eigene, solange das Werkzeug zur Hand ist.

Lange galt die Mühe, ein Problem zu durchdringen, als lästiger Umweg auf dem Weg zur Lösung. Tatsächlich war sie der Weg, auf dem das Verständnis überhaupt erst entstand. Wer sich durch einen Fehler gekämpft hat, kennt danach nicht nur die Lösung, sondern das Terrain darum herum: die Sackgassen, die falschen Fährten, die Stellen, an denen es noch einmal kippen könnte. Genau dieses Nebenwissen entfällt, wenn die fertige Lösung geliefert wird.

Diese Reibung war also kein Mangel, sondern ein Teil des Ertrags. Sie zu beseitigen, klingt nach Fortschritt, kostet aber etwas, das auf der Rechnung zunächst nicht auftaucht.

Ein Zug, den niemand erklären kann

Im März 2016 schlug AlphaGo den Go-Profispieler Lee Sedol in einem Match mit 4:1. Berühmt wurde nicht das Ergebnis, sondern ein einzelner Zug: der 37. Zug in der zweiten Partie, in die Go-Geschichte als „Move 37“ eingegangen. Kein Mensch hätte ihn gespielt; die Wahrscheinlichkeit, dass ein menschlicher Profi ihn wählt, lag bei etwa eins zu zehntausend. Er war fremd, und er war brillant.

Den Gegenpol lieferte Lee Sedol selbst. In der vierten Partie spielte er den 78. Zug, in Korea als „göttlicher Zug“ gefeiert, ebenso unwahrscheinlich und sein einziger Sieg gegen die Maschine. Der Unterschied liegt nicht in der Genialität, sondern dahinter: Hinter Move 78 steht eine Idee, die ein Mensch erklären kann, ein geschickter taktischer Zug, im Go Tesuji genannt. Hinter Move 37 steht eine Wahrscheinlichkeitsverteilung über Millionen selbst gespielter Partien.

Profispielerinnen und -spieler haben AlphaGo studiert und einzelne Züge übernommen; die frühe Invasion am 3-3-Punkt etwa wurde populär, nachdem die Maschine sie bevorzugte. AlphaGo Zero lernte 2017 ganz ohne menschliche Partien, allein aus dem Spiel gegen sich selbst, und übertraf die ursprüngliche Version deutlich.

AlphaGo beruht auf neuronalen Netzen, und alles, was es im Training gelernt hat, steckt in deren Gewichten, den vielen Zahlenwerten, die ein solches Netz ausmachen. Dort liegt das Wissen, das die Maschine überlegen macht, und nirgends sonst. Es liegt in keinem Lehrbuch, in keinem Kommentar, in keinem Kopf. Man kann der Maschine beim Spielen zusehen und die Ergebnisse bestaunen, aber die zugrunde liegende Strategie bleibt eingeschlossen in einer Form, die sich nicht in menschliche Begriffe übersetzen lässt.

Bezeichnend ist, dass nicht einmal die Fachleute hinter AlphaGo den Zug im üblichen Sinn erklären konnten. Sie konnten beschreiben, wie das System trainiert wurde, und sie konnten zeigen, dass es Move 37 einen hohen Wert beimaß. Warum gerade dieser Zug der richtige war, ließ sich daraus nicht ableiten. Die Erklärung endete bei der Mechanik des Lernens, nicht beim Sinn des Ergebnisses.

Doch einen Zug zu übernehmen heißt nicht, ihn zu verstehen. Man imitiert, was sich als stark erweist, ohne das Warum rekonstruieren zu können. Die Maschine spielt übermenschliches Go und hinterlässt keine lehrbare Theorie davon. Genau das ist die Struktur, der ich bei generativer KI wieder begegne: ein Ergebnis auf hohem Niveau, das sich kopieren, aber nicht als Einsicht erben lässt.

Lässt sich die Blackbox wirklich öffnen?

Die naheliegende Hoffnung lautet, man müsse die Modelle eben erklärbar machen. Explainable AI, erklärbare KI, ist ein ernstzunehmendes Forschungsfeld. Aber die gängigen Verfahren erklären im Nachhinein: Sie zeigen, welche Eingaben besonders ins Gewicht fielen oder welche Teile des Netzes ansprachen. Das ergibt plausible Geschichten und Näherungen, aber keine getreue Auskunft darüber, was die Gewichte tatsächlich berechnen.

Schlimmer noch: Eine plausible Erklärung kann in die Irre führen. Sie klingt überzeugend, deckt sich mit unseren Erwartungen und suggeriert ein Verständnis, das gar nicht trägt. Eine Erklärung, die nicht treu wiedergibt, was im Modell geschieht, ist im Zweifel gefährlicher als gar keine, weil sie ein falsches Sicherheitsgefühl erzeugt.

Für die tägliche Arbeit folgt daraus wenig Tröstliches. Eine Hervorhebung, welche Zeilen ein Assistent als relevant betrachtet hat, sagt nichts darüber, ob der erzeugte Code korrekt ist. Die Erklärung beschreibt bestenfalls, woran das Modell sich orientiert hat, nicht, ob das Ergebnis stimmt. Beides zu verwechseln, ist der bequemste und zugleich gefährlichste Fehler im Umgang mit diesen Werkzeugen.

Ein jüngerer Zweig, die mechanistische Interpretierbarkeit, versucht, die innere Rechnung eines Modells regelrecht zurückzuentwickeln. Das ist vielversprechend, steckt aber in den Anfängen. Bei Modellen mit Milliarden von Parametern ist man von einer vollständigen Erklärung weit entfernt.

Verständlich von Grund auf sind nur einfache Modelle. Ein Entscheidungsbaum ist eine lesbare Folge von Wenn-dann-Verzweigungen, die man Schritt für Schritt nachvollziehen kann. Sobald man jedoch die Genauigkeit steigern will und zu Ensembles übergeht, zu Random Forests oder Gradient Boosting, ist die Durchschaubarkeit wieder dahin. Die Informatikerin Cynthia Rudin hat daraus die Forderung abgeleitet, bei folgenreichen Entscheidungen lieber von vornherein interpretierbare Modelle einzusetzen, statt Blackboxes nachträglich zu erklären.

Dahinter steht ein unbequemer Zusammenhang: Die leistungsfähigsten Modelle sind zugleich die am wenigsten durchschaubaren. Erklärbarkeit und Leistungsfähigkeit ziehen in entgegengesetzte Richtungen. Diese Undurchschaubarkeit ist dabei von anderer Art als die prinzipiellen Grenzen, die ich in einem früheren Beitrag beschrieben habe: Dort geht es darum, was Sprachmodelle grundsätzlich nicht leisten können; hier darum, wie wenig wir verstehen, wie sie das leisten, was sie leisten.

Verständnis, das vielleicht nirgends mehr existiert

Nun könnte man einwenden, dass wir uns längst auf vieles verlassen, das wir nicht verstehen. Ich vertraue dem Compiler, der TLS-Bibliothek, den Bremsen meines Autos, ohne ihre Interna zu durchdringen. Das stimmt, und es ist auch gut so. Niemand kann alles selbst verstehen.

Doch es gibt einen Unterschied. Bei diesen Beispielen existiert das Verständnis irgendwo. Es sitzt in den Entwicklerinnen und Entwicklern des Compilers, in der Spezifikation des Protokolls, in der Konstruktionszeichnung der Bremse. Ich kann der Kette im Prinzip folgen, bis ich bei jemandem ankomme, der erklären kann, warum die Sache funktioniert.

Es ist der Unterschied zwischen dem Wissen, dass etwas funktioniert, und dem Wissen, warum es funktioniert. Das erste genügt, um ein Ergebnis zu benutzen. Das zweite ist nötig, um es zu verändern, auf neue Fälle zu übertragen oder im Streitfall dafür einzustehen. Über lange Zeit lagen beide oft eng beieinander, nun lassen sie sich entkoppeln.

Wissenschaft und Technik haben über Jahrhunderte funktioniert, weil Wissen eine übertragbare Form annahm: Sätze, Beweise, Konstruktionspläne, die andere prüfen, lehren und weiterentwickeln konnten. Das Wissen eines großen Modells liegt dagegen in Milliarden von Zahlen, die für sich genommen nichts erklären. Es ist Wissen, das wirkt, ohne sich mitteilen zu lassen. Damit fehlt ihm genau die Eigenschaft, die menschliches Wissen anschlussfähig macht.

Bei der Ausgabe eines großen Sprachmodells kann die Kette ins Leere laufen. Niemand hat Move 37 entworfen, niemand kann auf die Überlegung dahinter zeigen, weil es keine gibt. Das Verständnis liegt nicht woanders, es existiert womöglich gar nicht, in niemandem. Das ist neu, und es ist mehr als ein akademischer Unterschied.

Sichtbar wird das überall dort, wo jemand für ein Ergebnis geradestehen muss. Eine Ärztin, die einer Diagnose folgt, eine Entwicklerin, die eine generierte Komponente ausliefert, ein Team, das ein System betreibt: Sie alle übernehmen Verantwortung für etwas, dessen Zustandekommen sie nicht vollständig durchschauen. Solange alles gutgeht, fällt das nicht auf. Es fällt auf, sobald etwas schiefgeht und die Frage nach dem Warum sich nicht länger aufschieben lässt.

Für Software wird dieser Unterschied konkret. Software ist kein einmaliges Ergebnis, das man entgegennimmt und beiseitelegt. Sie muss gewartet, erweitert, im Fehlerfall durchdrungen und über Jahre verantwortet werden. Dass der eigentliche Engpass der Entwicklung nie das Schreiben von Code war, sondern das Verstehen des Problems, habe ich an anderer Stelle ausgeführt. Ein Ergebnis, das niemand versteht, ist vor diesem Hintergrund keine Ersparnis, sondern eine Hypothek auf jede künftige Änderung.

Verlässlichkeit ersetzt kein Verstehen

Ist der Verlust an Verständnis also ein Problem? Die ehrliche Antwort lautet: Es kommt darauf an, und die Trennlinie verdient es, genau gezogen zu werden. Es gibt Fälle, in denen Verlässlichkeit der völlig richtige Maßstab ist und Verständnis nichts hinzufügt.

Wenn ein Ergebnis ein Einzelfall ist, billig zu überprüfen und ohne große Folgen, dann brauche ich seine Herleitung nicht zu durchschauen. Einen regulären Ausdruck kann ich gegen meine Beispiele testen, ein kleines Wegwerfskript an seinem Resultat messen. Hier auf Verständnis zu bestehen, wäre eine Romantisierung; was zählt, ist, dass das Ergebnis nachweislich stimmt.

Sobald ich aber ein System verantworte und es weiterentwickeln muss, kehrt sich der Maßstab um. Dann ist ein Ergebnis, das ich nicht verstehe, keine Einsparung, sondern eine verschobene Rechnung. Jede spätere Änderung, jeder Fehler, jede Anpassung verlangt genau das Verständnis nach, das ich beim ersten Mal übersprungen habe. Verlässlichkeit allein trägt nicht mehr, wo ich nicht nur ein Resultat brauche, sondern eine Grundlage, auf der ich weiterbauen kann.

Hinzu kommt, dass Verlässlichkeit selbst ein wackliger Maßstab ist, solange das Verständnis fehlt. Prüfen kann ich nur, woran ich gedacht habe. Welche Fälle überhaupt zu testen sind, welche Randbedingungen heikel werden, wo ein Ergebnis kippen könnte: Das verrät kein Test, sondern allein das Verständnis der Sache. Wer nicht versteht, prüft im Zweifel das Falsche und hält das Ergebnis trotzdem für gesichert.

In der Praxis zeigt sich das spätestens, wenn ein generiertes Modul Monate später in Produktion bricht und niemand im Team sagen kann, welche Annahmen ihm zugrunde liegen. Dann beginnt die Arbeit, die beim ersten Mal vermeintlich entfallen ist: die Software zu lesen, zu durchdringen, zu verstehen. Nur geschieht das jetzt unter Zeitdruck und ohne den Kontext, der bei der Entstehung noch greifbar gewesen wäre.

Diese Rechnung lässt sich nicht streichen, nur verlagern. Entweder ich erarbeite das Verständnis am Anfang, wenn der Kontext frisch und der Druck gering ist, oder ich hole es später nach, teurer und unter schlechteren Bedingungen. Verschwinden tut es nie.

Deshalb hebt generative KI den Wert des Verstehens nicht auf. Sie verschiebt nur den Zeitpunkt, zu dem wir dafür bezahlen. Sie verlagert das Problem, sie löst es nicht. Die Fähigkeit, die dadurch wichtiger wird statt unwichtiger, ist das Urteilsvermögen: zu erkennen, in welchem der beiden Fälle ich gerade bin, und zu entscheiden, ob ein Ergebnis Vertrauen verdient, ohne verstanden zu sein.

AlphaGo hat uns ein Jahrzehnt früher gezeigt, wie sich das anfühlt: eine Brillanz, die wir bewundern und kopieren, aber nicht als Einsicht erben können. Ob wir am Ende nur noch bedienen, was wir gebaut haben, oder es weiterhin verstehen, entscheiden nicht die Werkzeuge. Es entscheidet sich daran, wo wir weiterhin auf Verständnis bestehen.

(mro)