Mike Bild
Blog

Sauberes Grounding I: Warum die KI so überzeugend rät

Warum Sprachmodelle plausible Dinge erfinden, weshalb mehr Training das Problem nicht zuverlässig beseitigt und was Grounding damit zu tun hat.

≈ 9 Min. Lesezeit
SoftwareKIMethodikDelivery
Markdown In Claude öffnenIn ChatGPT öffnen

Diesen Beitrag anhören (11 Min.)

MP3 herunterladen

Vor ein paar Wochen saß ich in einem Review über generiertem Code. Der Assistent hatte eine Retry-Logik für unseren internen HTTP-Client vorgeschlagen – einen Client, den es nur bei uns gibt, eine dünne TypeScript-Schicht über fetch mit ein paar hauseigenen Konventionen. Der Vorschlag: client.withRetry({ backoff: "exponential", maxAttempts: 3 }). Sauber benannt, im Stil unserer Codebasis, mit einem Kommentar, warum exponentielles Backoff hier die richtige Wahl sei. Dazu eine kurze Erklärung im Chat, wie sich die Methode zu unserem Timeout-Handling verhält.

Die Methode existiert nicht. Sie hat nie existiert. Unser Client konfiguriert Retries an einer ganz anderen Stelle, beim Erzeugen der Instanz, nicht am Aufruf. Aber das Erschreckende war nicht der Fehler. Fehler mache ich auch. Das Erschreckende war die Qualität der Erfindung: Der Name passte perfekt zu unseren Konventionen, die Signatur sah aus wie von uns, die Begründung war fachlich einwandfrei. Wäre die Methode von einem Menschen vorgeschlagen worden, hätte ich gesagt: Der kennt unseren Code richtig gut. Nur dass der Vorschlag komplett geraten war – und mit derselben Souveränität vorgetragen wurde wie die zwanzig korrekten Vorschläge davor.

Teil 7 der Serie „Von der Session zum System“ – hier geht es zum Auftakt.

Wer ernsthaft mit Copilot, Claude Code oder Cursor arbeitet, kann so etwas erleben. Ich habe solche Fehler anfangs wie einen Bug betrachtet, der mit der nächsten Modellgeneration verschwinden müsste. Heute verlasse ich mich nicht darauf. Bessere Modelle können Halluzinationen reduzieren, beseitigen sie aber nicht zuverlässig – und seit mir das klar geworden ist, arbeite ich anders mit diesen Systemen.

Das Modell kennt seine Wissensgrenze nicht zuverlässig

Um zu verstehen, warum die Erfindung so überzeugend klang, musste ich mir klarmachen, was ein Sprachmodell eigentlich tut: Es setzt Text fort. Aus Milliarden von Beispielen hat es gelernt, welche Fortsetzung nach einem gegebenen Anfang wahrscheinlich ist. Das ist keine abwertende Vereinfachung, sondern der Mechanismus – und er ist erstaunlich mächtig, wie ich in Folge 2 dieser Serie beschrieben habe. Aber er hat eine Eigenschaft, die man nicht wegdiskutieren kann: Wahre und falsche Aussagen entstehen beide als wahrscheinliche Fortsetzungen; eine Wahrheitsprüfung folgt aus diesem Mechanismus nicht automatisch.

Ein menschlicher Entwickler hat – bei aller Fehlbarkeit – ein Gefühl dafür, ob er etwas weiß oder vermutet. Wenn ich einen Kollegen nach einer Methode unserer internen Bibliothek frage, antwortet er entweder „die heißt so“ oder „ich müsste nachschauen“. Dieses Nachschauen-Müssen ist Metakognition: Wissen über das eigene Wissen, ein Gespür für die eigene Unsicherheit. Genau diese Instanz fehlt dem Modell. Es hat keinen inneren Zustand, der zwischen „das stand tausendfach im Trainingskorpus“ und „das klingt so, wie es klingen müsste“ unterscheidet.

Deshalb ist die Souveränität, die uns so irritiert, keine Anmaßung, sondern ein Artefakt. Der Ton eines Textes ist Teil der Fortsetzung. Technische Dokumentation, Stack-Overflow-Antworten, Code-Kommentare – das Material, aus dem das Modell gelernt hat, ist überwiegend im Ton der Gewissheit geschrieben. Niemand dokumentiert eine API mit „ich glaube, diese Methode gibt es“. Also klingt auch die erfundene Methode nach Dokumentation. Der überzeugte Ton ist kein Signal für Korrektheit. Er war es nie.

Zwei Arbeiten stützen Teile dieser Erklärung. Ziwei Xu und Kollegen haben 2024 formal argumentiert, dass Halluzinationen für große Sprachmodelle nicht vollständig eliminierbar sind. Und OpenAI beschreibt in einer eigenen Veröffentlichung – Stand August 2026 online abrufbar – einen zweiten Mechanismus: Trainings- und Evaluationsanreize können Modelle zum Raten statt zum Eingestehen von Unsicherheit bewegen. Ein Modell, das bei Unsicherheit „weiß ich nicht“ sagt, kann in Benchmarks, die richtige Antworten belohnen, Enthaltungen aber nicht angemessen berücksichtigen, schlechter abschneiden als eines, das selbstbewusst rät – so wie ein Multiple-Choice-Test Studenten beibringt, bei Unwissen auf gut Glück anzukreuzen, statt das Feld leer zu lassen.

Symbole, die auf Symbole verweisen

Es gibt noch eine tiefere Ebene, und sie ist älter als die aktuellen Modelle. 1990 – lange vor heutigen großen Sprachmodellen – hat der Kognitionswissenschaftler Stevan Harnad das Symbol Grounding Problem formuliert. Seine Frage: Wie kommt Bedeutung in ein System, das nur Symbole nach formalen Regeln manipuliert? Sein Bild: Man versuche, Chinesisch ausschließlich aus einem Chinesisch-Chinesisch-Wörterbuch zu lernen. Jedes Zeichen wird durch andere Zeichen erklärt, diese wiederum durch weitere Zeichen – man dreht sich im Kreis, ohne je bei der Sache selbst anzukommen. Symbole verweisen auf Symbole, nirgends berührt das System die Welt.

Ich zögere normalerweise, Paper aus der Kognitionswissenschaft in Alltagsdebatten zu ziehen, weil dabei oft mehr Nebel als Klarheit entsteht. Aber hier passt die Analogie unangenehm gut. Ein Sprachmodell kennt Text über die Welt, nicht die Welt. Es hat gelesen, was Menschen über HTTP-Clients, über Retries, über exponentielles Backoff geschrieben haben – und daraus statistische Zusammenhänge zwischen Token gelernt. Die Antwort in meiner Eingangsszene lieferte jedenfalls keinen Hinweis auf eine Prüfung an der Sache selbst: kein Compiler, der den Aufruf ablehnt, kein Test, der rot wird, keine Produktion, die um drei Uhr nachts alarmiert. Wo ich als Entwickler meine Begriffe an Erfahrung geeicht habe, hat das Modell seine Begriffe an anderen Begriffen geeicht. Das Wörterbuch erklärt sich selbst, und es erklärt sich flüssig.

Man muss Harnads Problem nicht in voller philosophischer Schärfe übernehmen, um den praktischen Kern zu sehen: Ein System, dessen gesamtes „Wissen“ aus Textstatistik besteht, kann eine plausible Erfindung nicht von einer Tatsache unterscheiden, weil beide aus demselben Stoff sind. withRetry war für das Modell genauso real wie jede Methode, die es wirklich gibt – ein wahrscheinliches Symbol unter anderen Symbolen.

Warum größere Modelle das Problem mildern, aber nicht lösen

Der Einwand liegt nahe: Die Modelle sind doch besser geworden. In meiner Arbeit erwische ich aktuelle Modelle im öffentlichen, gut dokumentierten Wissen jedenfalls nur noch selten bei freien Erfindungen.

Aber „seltener“ heißt nur „weniger oft“, nicht „grundsätzlich anders“. Der Mechanismus bleibt derselbe: Ein größeres Modell hat feinere statistische Zusammenhänge gelernt – es rät seltener, weil es mehr gesehen hat, nicht weil es aufgehört hätte zu raten. An der Stelle, wo sein Material endet, produziert es weiterhin die wahrscheinlichste Fortsetzung, im selben souveränen Ton. Die Grenzlinie zwischen Wissen und Vermutung verschiebt sich nach außen, aber sie verschwindet nicht, und das Modell zeigt sie mir nach wie vor nicht an. Genau das macht die restlichen Fälle so tückisch: Je seltener der Fehler, desto weniger rechne ich mit ihm – und desto ungeprüfter geht der Vorschlag durch.

Ohne interne Quellen bleiben organisationsspezifische Fakten Vermutung

Und damit zu dem Punkt, der mich in meiner täglichen Arbeit am meisten beschäftigt. Alles bisher Gesagte gilt für öffentliches Wissen – React, PostgreSQL, die AWS-APIs. Dort erlebe ich selten, dass das Modell rät – das öffentliche Material ist riesig. In dem Moment aber, in dem ich die Tür zu einer konkreten Organisation aufmache, kippt das Verhältnis. Denn was dort zählt, ist dem Modell ohne bereitgestellte interne Quellen nicht verlässlich zugänglich:

  • die internen Bibliotheken und Services mit ihren tatsächlichen Signaturen und Eigenheiten
  • die hauseigenen Konventionen – wie Fehler behandelt werden, wie Module geschnitten sind, was ein Deployment durchlaufen muss
  • die Begriffe der Fachdomäne, die im Unternehmen etwas Präzises bedeuten und außerhalb etwas anderes oder gar nichts

Wie weit das geht, hat mir der Fall aus der Eingangsszene gezeigt. Das Modell hat unseren HTTP-Client nie gesehen, also hat es ihn erfunden – und zwar so, wie ein solcher Client typischerweise aussieht. Deshalb war der Vorschlag so gut: Er war die Idealform eines internen HTTP-Clients, destilliert aus öffentlichen Mustern. Nur eben nicht unserer. Ohne interne Quelle waren die tatsächlichen Signaturen für das Modell nicht verlässlich ableitbar; die Erfindung lag nahe und sah dem echten Wissen zum Verwechseln ähnlich, weil das Modell so gut darin ist, den Stil einer Codebasis fortzusetzen.

Das erklärt im Nachhinein auch, warum meine Versuche mit Instruktionsdateien so ernüchternd verliefen – ich habe das in der letzten Folge ausführlich erzählt. Damals dachte ich noch, das Problem sei die Verbindlichkeit: Die KI hält sich nicht an unsere Regeln, also müssen die Regeln klarer, strenger, prominenter formuliert werden. Aber selbst wenn eine AGENTS.md perfekt befolgt würde – sie beantwortet die falsche Frage. Eine Instruktion sagt dem System, wie es sich verhalten soll. Sie kann ihm nicht geben, was es tatsächlich nicht hat: die Fakten. „Erfinde keine Methoden“ ist eine hilflose Anweisung an ein System, das nicht merkt, wann es erfindet. Dem Modell fehlt nicht der Wille, es fehlt das Material. Ich habe an der Motivation eines Systems gearbeitet, das kein Motivationsproblem hat, sondern ein Wissensproblem.

Grounding: interne Fakten im Arbeitskontext bereitstellen

Für diese Antwort auf das Wissensproblem verwende ich hier den Begriff Grounding – das Erden von Antworten in überprüfbaren Fakten. Die Idee ist im Kern einfach. Wenn das Modell meine Realität nicht aus dem Training kennen kann, dann muss ich sie ihm zum Zeitpunkt der Arbeit mitgeben: die echte Signatur statt der wahrscheinlichen, das tatsächliche Schema statt des typischen, unsere Konvention statt der branchenüblichen. Nicht als Verhaltensregel, sondern als Material. Das Modell soll nachschlagen können statt raten zu müssen – ungefähr so, wie mich eine gute IDE mit Typinformationen davon abhält, Methodennamen aus dem Gedächtnis zu tippen.

Hier verwende ich Grounding für die Bereitstellung konkreten Quellenmaterials im Arbeitskontext und unterscheide es damit von bloßen Instruktionen, die Verhaltensregeln formulieren. Grounding ist kein Produkt und kein Feature, das man einschaltet. Es ist zunächst eine Einsicht über die Arbeitsteilung: Das Modell liefert Sprachverständnis, Mustererkennung, Syntheseleistung – die Fakten über meine Welt muss meine Welt selbst liefern. Und es ist, ehrlich gesagt, auch keine vollständige Lösung. Ein geerdetes Modell kann die mitgegebenen Fakten immer noch falsch verknüpfen, und wer schon einmal versucht hat, „einfach alle Dokumente“ in den Kontext zu kippen, weiß, dass man sich damit neue Probleme einhandelt. Der Unterschied ist ein anderer: Bei einem geerdeten System streite ich über die Qualität meiner Quellen. Ohne Quellen prüfe ich freie Ergänzungen aus allgemeinen Mustern.

Damit steht die Konsequenz dieser Folge fest, auch wenn sie niemandem Arbeit erspart: Bessere Modelle und strengere Anweisungen beseitigen überzeugende Falschantworten nicht zuverlässig. Grounding stellt dort konkretes Quellenmaterial bereit, wo das System sonst aus allgemeinen Mustern ergänzen müsste. Womit die eigentliche Arbeit beginnt – denn „interne Fakten mitgeben“ ist schnell gesagt. Welche Fakten eigentlich, in welcher Form, an welcher Stelle des Arbeitsflusses? Das ist keine rhetorische Frage, sondern die nächste Folge.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare