Sauberes Grounding II: Antworten erden

Diesen Beitrag anhören (13 Min.)

Vor ein paar Wochen saß ich mit einem Kollegen vor einem halbfertigen Integrationsstück. Die KI sollte einen Client für eine interne API schreiben, und sie tat, was sie immer tut: Sie schlug customerId vor. Das Feld heißt bei uns customer_ref – aus historischen Gründen, die niemand mehr verteidigt, aber jeder kennt. Wir hatten das dem Assistenten in dieser Woche schon zweimal erklärt. Diesmal habe ich etwas anderes gemacht: Ich habe ihm nicht widersprochen, sondern die OpenAPI-Beschreibung der API in den Kontext gegeben. Der nächste Vorschlag stimmte. Nicht ungefähr, sondern exakt – inklusive der etwas eigenwilligen Paginierung, die sich kein Modell der Welt hätte ausdenken können, weil sie schlicht eine Entscheidung von uns war. Gleiches Modell, gleicher Tag, gleiche Aufgabe. Der Unterschied: Es musste nicht mehr raten.

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

In der letzten Folge habe ich beschrieben, warum die KI so überzeugend rät: Ein Sprachmodell verweist mit Symbolen auf Symbole, nicht auf meine Systeme. Es kennt tausend APIs, die so ähnlich aussehen wie meine – und genau deshalb erfindet es plausibel. Das war die Diagnose. Diese Folge ist die konstruktive Seite: Wie gebe ich der KI meine Realität mit? Ich nenne das für mich sauberes Grounding – Antworten erden, statt sie in der Schwebe zu lassen. Und wie so oft ist der Kern weniger ein Werkzeug als eine Sortierung: Welches Wissen gibt es überhaupt, wo kommt es her, und wann gehört es in den Kontext?

Mein Arbeitsmodell: drei Wissensschichten

Wenn ich mir anschaue, was meinen Antworten in der Praxis Boden gibt, lande ich immer wieder bei drei Schichten. Das ist meine Sortierung für diese Arbeit, keine allgemeine Taxonomie von Wissen. Die Schichten unterscheiden sich nicht allein im Inhalt, sondern in ihrem Charakter – und das ist der eigentliche Punkt.

flowchart TB
    subgraph Schichten["Drei Wissensschichten"]
        K["Konventionen<br/>wie wir arbeiten<br/>präskriptiv, kuratiert"]
        D["Dokumente<br/>Runbooks, Specs, Entscheidungen<br/>deskriptiv, alternd"]
        S["Schnittstellenbeschreibungen<br/>OpenAPI, GraphQL-Introspection, Schemas<br/>maschinell prüfbar"]
    end
    K --> E["Erdung beim Bauen<br/>und Vorbereiten"]
    D --> E
    S --> E
    E --> A["Geprüftes Arbeitsergebnis<br/>Dokument, Plan, Code, konfigurierter Ablauf"]

Die erste Schicht sind unsere Konventionen und Arbeitsweisen. Das ist präskriptives Wissen: nicht „so ist die Welt“, sondern „so machen wir das hier“. Fehlerbehandlung gehört an den Aufrufer, Migrationen laufen nie automatisch, Commit-Botschaften erklären das Warum, Reviews prüfen zuerst die Schnittstelle. Nichts davon steht in einer API-Beschreibung, und nichts davon kann ein Modell erraten – es sind Entscheidungen, keine Fakten. In Folge 6 habe ich erzählt, wie ich versucht habe, genau dieses Wissen in Instruktionsdateien wie AGENTS.md oder CLAUDE.md zu packen – und wo Empfehlungen an ihre Grenzen kommen. Aufgeben war daraus nicht die Lehre. Diese Schicht muss klein, dicht und kuratiert sein: Eine kurze Liste von Regeln, hinter denen das Team steht, lässt sich befolgen und im Review einfordern. Eine lange Sammlung von Hinweisen konkurriert mit sich selbst um Aufmerksamkeit.

Die zweite Schicht sind unsere Dokumente: Runbooks, Spezifikationen, Architekturentscheidungen, Betriebsnotizen. Das ist deskriptives Wissen – es beschreibt, was bei uns gilt und warum es so gekommen ist. Eine festgehaltene Architekturentscheidung kann verhindern, dass die KI mit ihrem Vorschlag drei Jahre alte Systemgrenzen übergeht. Ein Runbook erklärt, was bei einem bestimmten Alarm wirklich zu tun ist, statt was generisch sinnvoll klingt. Aber ich habe gelernt, dieser Schicht mit einer gewissen Skepsis zu begegnen: Dokumente altern. Sie beschreiben den Zustand von damals, nicht von heute. Ein Runbook, das seit zwei Jahren niemand angefasst hat, kann die KI genauso in die Irre führen wie ihr eigenes Raten – nur klingt die Antwort dann noch überzeugender, weil sie sich auf „unsere Doku“ beruft.

Die dritte Schicht sind echte Schnittstellenbeschreibungen – und sie ist meine liebste, weil sie einen Charakter hat, den die anderen beiden nicht haben: Werkzeuge können ihre Struktur lesen, auch wenn Schema und Laufzeitverhalten auseinanderlaufen können. Eine OpenAPI-Beschreibung, ein per Introspection abgefragtes GraphQL-Schema, ein JSON-Schema, ein Datenbankschema – das ist nicht die Erinnerung eines Kollegen an das System, sondern eine maschinenlesbare Struktur- oder Schnittstellenbeschreibung. Introspection zeigt das angebotene Schema dieser Umgebung zu diesem Zeitpunkt: Wenn das Feld customer_ref heißt, steht es dort. Das beweist weder korrekte Resolver noch die Übereinstimmung mit anderen Deployments oder mit datenabhängigen Antworten. Je nach Artefakt kann ich daraus Feldnamen, Typen oder Endpunkte ablesen, statt sie aus Konventionen oder Dokumenten zu erraten.

Die drei Schichten beantworten unterschiedliche Fragen, und sie ersetzen einander nicht:

Konventionen sagen, wie etwas gebaut werden soll – Stil, Schnitt, Verantwortlichkeiten.
Dokumente sagen, warum die Dinge so sind, wie sie sind – Kontext und Geschichte.
Die jeweilige Schnittstellenbeschreibung nennt Felder, Typen oder Endpunkte. Ob die Implementierung diesem Stand entspricht und funktioniert, muss separat geprüft werden.

Wer nur die dritte Schicht liefert, bekommt Code, der zum beschriebenen Vertrag passt, aber nicht zwingend zur Laufzeit funktioniert. Wer nur die erste liefert, bekommt stilistisch sauberen Code gegen eine erfundene API. Erst zusammen erden sie eine Antwort.

Nachschlagen statt Raten

Das Prinzip hinter allen drei Schichten ist dasselbe, und es ist so unspektakulär, dass man es leicht überliest: nachschlagen statt raten. Am leichtesten versteht man es an einer Analogie, die jeder aus dem Editor kennt: IntelliSense.

Wenn ich in meinem Editor customer. tippe, rät der Editor nicht, welche Felder ein Kunde vermutlich hat. Er schlägt nach. Ein typbasierter Editor leitet Vorschläge aus der verfügbaren Typdefinition ab, nicht aus statistischer Ähnlichkeit. Genau diese Ableitung fehlt einem Sprachmodell, wenn wir es ohne Erdung arbeiten lassen.

Ein Agent mit passenden Werkzeugen und Leserechten kann nachschlagen. Er kann eine OpenAPI-Datei lesen, ein GraphQL-Schema per Introspection abfragen, eine Typdefinition im Repository aufschlagen. Das Model Context Protocol stellt dafür Tools und Kontextquellen über einen Protokollvertrag bereit. Und ein solcher Agent kann noch einen Schritt weitergehen, der über IntelliSense hinausreicht: Er kann Endpunkte probieren. Ein lesender Aufruf gegen die echte API, die tatsächliche Antwortstruktur anschauen, und der nächste Vorschlag basiert auf beobachteten Daten statt auf Erfindung. Aus „dieses Feld gibt es wahrscheinlich“ wird „dieses Feld habe ich gesehen – in dieser Antwort, mit diesen Rechten, in dieser Umgebung und zu diesem Zeitpunkt“. Das ist ein kategorialer Unterschied, kein gradueller, auch wenn eine einzelne Antwort nicht das Verhalten für andere Daten, Rechte, Umgebungen und Zeitpunkte belegt.

Erkundende Lesezugriffe müssen autorisiert sein; ihre fachliche Nebenwirkungsfreiheit muss vorher geklärt werden. Solche Aufrufe sind für die Recherche wertvoll. Schreibende Aufrufe „zum Ausprobieren“ sind ein eigenes Thema mit eigenen Sicherungen – dazu komme ich in dieser Serie noch. Für das Erden von Antworten reicht die lesende Seite fast immer aus.

Grounding wiederholbarer Abläufe gehört ans Bauen

Das zweite Prinzip hat länger gebraucht, bis es bei mir angekommen ist, und es ist das mit den größten Konsequenzen: Wann wird geerdet? Überall dort, wo ein wiederholbarer Ablauf ein vorab prüfbares Artefakt hat, gehört die Erdung ans Bauen und Vorbereiten – nicht in den kritischen Pfad der Ausführung. Entsteht die Frage dagegen erst zur Laufzeit, muss auch die Erdung dort stattfinden.

Die Grafik oben zeigt diesen Fall für ein vorab prüfbares Artefakt.

An dieser Stelle muss ich RAG einordnen, weil es das erste Wort ist, das im Raum steht, sobald jemand „eigenes Wissen“ und „KI“ im selben Satz sagt. Retrieval-Augmented Generation – 2020 von Lewis und Kollegen beschrieben – bedeutet: Zum Zeitpunkt der Anfrage werden passende Textstücke aus einem Korpus gesucht und dem Modell mitgegeben. Das ist genau richtig, wenn die Frage erst zur Laufzeit entsteht und die Antwort aus einem Dokumentbestand kommen muss – ein Assistent, der Fragen zum Handbuch beantwortet, eine Suche über interne Notizen, Support-Fälle. Solche Fälle entsprechen dem im RAG-Papier beschriebenen Muster aus Retrieval und Generierung.

Schief wird es, wenn RAG zum Reflex für alles wird. Denn Retrieval zur Laufzeit hat zwei Eigenschaften, die im Tagesgeschäft wehtun: zusätzliche Latenz und mögliche Ergebnisänderungen bei verändertem Index, Ranking oder Suchverfahren. Jede Ausführung sucht neu, und was gefunden wird, hängt an Einbettungen, Rankings, am Zustand des Index – derselbe Ablauf kann heute andere Textstücke sehen als gestern und sich deshalb anders verhalten. Für eine explorative Frage ist das verschmerzbar. Bei einem Ablauf, der jede Nacht läuft und auf dessen Ergebnis sich Leute verlassen, können wechselnde Treffer zu nicht reproduzierbaren Ergebnissen führen.

Deshalb ziehe ich für solche wiederholbaren Abläufe die Erdung nach vorn. Das Wissen – die Konventionen, die Dokumente, die Schnittstellenbeschreibungen – fließt ein, während etwas entsteht: ein Dokument, ein Plan, ein Stück Code, ein konfigurierter Ablauf. Dieses Arbeitsergebnis wird geprüft, von mir oder von einem Kollegen, und ab dann steht es fest. Die spätere Ausführung würfelt nicht neu, sie führt aus, was geprüft wurde. Der Unterschied ist derselbe wie zwischen einem Programm, das bei jedem Start seine Abhängigkeiten aus dem Netz rät, und einem Build mit festgeschriebenen Versionen: In den flüchtigen, kreativen Moment gehört die ganze Unsicherheit – in das, was danach jede Nacht wieder abläuft, gehört sie nicht.

Das ist keine Absage an RAG, sondern eine Zuständigkeitsklärung. Suche über Dokumente zur Laufzeit, wo die Frage zur Laufzeit entsteht. Erdung beim Bauen, wo das Ergebnis ein Artefakt ist, das Bestand haben soll. In meiner Arbeit ist der zweite Fall der häufigere – diskutiert wird er trotzdem mit dem Vokabular des ersten.

Kontext-Ökonomie: was zuletzt fliegt

Das dritte Prinzip klingt banal und entscheidet in der Praxis erstaunlich viel: Der Kontext ist knapp. Ja, die Fenster sind groß geworden. Aber wer länger mit Agenten-Sessions arbeitet, weiß, dass „groß“ nicht „unerschöpflich“ heißt – lange Sitzungen, gelesene Dateien, Tool-Ausgaben und Zwischenstände füllen jedes Fenster, und irgendwann wird getrimmt, zusammengefasst, weggelassen. Anthropic hat das unter dem Begriff Context Engineering auf den Punkt gebracht: Kontext ist eine endliche Ressource, relevante Informationen werden gezielt gefunden und nur bei Bedarf geladen. Ein großer, ungefilterter Kontext ist kein Qualitätsmerkmal – die für die Aufgabe maßgebliche Quelle gehört zum Zeitpunkt der Bearbeitung hinein.

Für mein Grounding folgt daraus eine Priorisierungsregel: Wenn unter Druck etwas aus dem Kontext fliegen muss, entferne ich zuerst Material, das sich gezielt erneut nachschlagen lässt. Ein langes Runbook bleibt nur mit den gerade relevanten Absätzen im Kontext. Kleine, aufgabenrelevante Konventionen halte ich länger fest, weil ihr Verlust schwerer zu bemerken ist. Bei einer anderen Aufgabe kann diese Reihenfolge anders aussehen; entscheidend sind Relevanz und Wiederbeschaffungskosten, nicht die Bezeichnung der Schicht.

Deshalb halte ich Konventionsdokumente klein und auf die Aufgabe zugeschnitten. Ein ausuferndes Dokument konkurriert mit Quellen und Tool-Ausgaben um Platz. Kuratieren heißt hier, bewusst zu entscheiden, was für den nächsten Schritt im Kontext bleiben muss.

Was Grounding nicht leistet

Zur Ehrlichkeit gehört die Gegenrechnung, und ich will sie nicht ans Ende quetschen, als wäre sie eine Fußnote. Grounding beseitigt das Raten nicht. Beim nächsten Vorschlag traten mit der geladenen OpenAPI-Beschreibung keine erfundenen Feldnamen oder Strukturen auf. Aber ein Sprachmodell bleibt ein Sprachmodell: Es kann eine korrekte Spezifikation im Kontext haben und trotzdem einen Schluss daraus ziehen, der nicht trägt. Es kann zwei Dokumente zusammenlesen, die sich widersprechen, und den Widerspruch elegant überbrücken, statt ihn zu melden. Und es kann an einem gealterten Runbook geerdet sein – dann ist die Antwort sauber begründet und trotzdem falsch, nur schwerer als falsch zu erkennen.

Prüfen bleibt deshalb Pflicht. Das geerdete Arbeitsergebnis ist ein besserer Kandidat, kein fertiges Urteil. Was sich für mich geändert hat, ist die Art der Prüfung: Ich suche seltener nach frei erfundenen Feldern und häufiger nach falschen Schlüssen aus richtigen Quellen. Das ist ein besseres Problem – dieselbe Sorte Problem, die ich auch bei einem menschlichen Kollegen hätte, der sich gewissenhaft eingelesen hat. Aber es ist ein Problem, und Grounding ersetzt weder Konsistenzprüfung noch Tests – ohne solche Prüfungen können falsche Schlüsse unentdeckt bleiben.

Eine Frage lässt mich seither nicht los. Alles, was ich hier beschrieben habe, erdet eine Session: Die Konventionen, die Dokumente, die Schnittstellen fließen in einen Arbeitszusammenhang ein, und am Ende steht ein geprüftes Ergebnis. Aber die Session endet. Das Fenster schließt sich, der Kontext ist weg – und mit ihm alles, was die KI in diesen zwei Stunden über unser System, unsere Eigenheiten, unsere Korrekturen gelernt hat. Morgen erkläre ich customer_ref zum dritten Mal, oder ich habe einen Weg gefunden, dass Wissen die Session überlebt. Wie das aussehen kann – ohne veraltete, unauffindbare oder unbelegte Einträge anzusammeln – davon handelt die nächste Folge.

Weiterführende Quellen

Effective context engineering for AI agents – Anthropics Engineering-Beitrag zu Kontext als endlicher Ressource
Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks – das RAG-Originalpapier von Lewis et al. (2020)
GraphQL Introspection – wie ein GraphQL-Schema über sich selbst Auskunft gibt
OpenAPI Specification – der Standard für maschinenlesbare HTTP-API-Beschreibungen
Model Context Protocol – offener Standard, um KI-Werkzeugen echte Datenquellen und Systeme zugänglich zu machen

Wie fandest du diesen Beitrag?