# Sauberes Grounding II: Antworten erden

URL: https://www.mikebild.dev/de/blog/sauberes-grounding-antworten-erden/

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](https://www.mikebild.dev/de/blog/von-der-session-zum-system-auftakt/).*

In der [letzten Folge](https://www.mikebild.dev/de/blog/sauberes-grounding-warum-ki-raet/) 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?

## Drei Schichten von Wissen

Wenn ich mir anschaue, was meinen Antworten in der Praxis Boden gibt, lande ich immer wieder bei drei Schichten. Sie unterscheiden sich nicht nur im Inhalt, sondern in ihrem Charakter – und das ist der eigentliche Punkt.

```mermaid
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](https://www.mikebild.dev/de/blog/vergebliche-versuche-instruktionsdateien/) 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. Zehn Regeln, hinter denen das Team steht, wirken. Zweihundert Zeilen angesammelter Hinweise verwässern sich gegenseitig.

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 ist Gold wert, wenn die KI einen Vorschlag machen soll, der zu drei Jahre alten Weichenstellungen passen muss. 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: Sie ist maschinell prüfbar. Eine OpenAPI-Beschreibung, ein per [Introspection](https://graphql.org/learn/introspection/) abgefragtes GraphQL-Schema, ein JSON-Schema, ein Datenbankschema – das ist nicht jemandes Erinnerung an das System, das ist das System selbst, das über sich Auskunft gibt. Ein GraphQL-Server kann über sein eigenes Schema nicht lügen. Wenn das Feld `customer_ref` heißt, dann steht das dort, verbindlich, in der Version von heute. Diese Schicht ist die Wahrheit der Systeme, und sie ist der stärkste Anker, den ich der KI geben kann.

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.
- Schnittstellenbeschreibungen sagen, **was** tatsächlich existiert – Felder, Typen, Endpunkte.

Wer nur die dritte Schicht liefert, bekommt technisch korrekten Code im falschen Stil. 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 schnellsten greifbar wird 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. Er kennt die Typdefinition, liest die echten Felder und bietet mir genau die an – nicht die statistisch wahrscheinlichen. Niemand würde einen Editor akzeptieren, der Felder vorschlägt, „die es bei den meisten Projekten so ähnlich gibt“. Genau das aber lassen wir Sprachmodellen durchgehen, wenn wir sie ohne Erdung arbeiten lassen.

Die gute Nachricht: Die KI kann nachschlagen, wenn man es ihr ermöglicht. Sie kann eine OpenAPI-Datei lesen, ein GraphQL-Schema per Introspection abfragen, eine Typdefinition im Repository aufschlagen. Werkzeuge wie Claude Code oder Cursor tun das im Code-Alltag längst; über offene Anbindungen wie MCP reicht dasselbe Muster inzwischen weit über den Editor hinaus, bis zu den Systemen dahinter. Und sie kann noch einen Schritt weitergehen, der über IntelliSense hinausreicht: Sie 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“. Das ist ein kategorialer Unterschied, kein gradueller.

Ich achte allerdings auf eine Trennlinie, die ich mir früh angewöhnt habe: Probieren heißt lesen. Erkundende Aufrufe gegen ein System sind 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 gehört ans Bauen, nicht in die Ausführung

Das zweite Prinzip hat länger gebraucht, bis es bei mir eingerastet ist, und es ist das mit den größten Konsequenzen: **Wann** wird geerdet? Beim Bauen und Vorbereiten – nicht im kritischen Pfad der Ausführung.

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](https://arxiv.org/abs/2005.11401) beschrieben und längst Standardvokabular – 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. Dafür wurde es gebaut, dafür funktioniert es.

Schief wird es, wenn RAG zum Reflex für alles wird. Denn Retrieval zur Laufzeit hat zwei Eigenschaften, die im Tagesgeschäft wehtun: Latenz und Nichtdeterminismus. 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. Für einen Ablauf, der jede Nacht läuft und auf dessen Ergebnis sich Leute verlassen, ist es Gift.

Deshalb ziehe ich 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 – ins wiederholt Ausgeführte 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 – und er wird fast immer mit dem Vokabular des ersten diskutiert.

## 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, Werkzeugausgaben und Zwischenstände füllen jedes Fenster, und irgendwann wird getrimmt, zusammengefasst, weggelassen. Anthropic hat das unter dem Begriff Context Engineering schön auf den Punkt gebracht: Kontext ist eine endliche Ressource, die man bewirtschaften muss wie ein Budget.

Für das Grounding folgt daraus eine Rangordnung, die ich mir als Frage stelle: Wenn unter Druck etwas aus dem Kontext fliegen muss – was fliegt zuerst, was zuletzt? Zuerst fliegen die Roh-Dokumente: die zwanzig Seiten Runbook, die ich vorhin hineingegeben habe und von denen im Moment nur ein Absatz zählt. Sie sind sperrig, redundant, und ihr Wert pro Zeile ist gering – was aktuell gebraucht wird, kann bei Bedarf erneut nachgeschlagen werden. Zuletzt fliegen die kuratierten Konventionen. Sie sind das Destillat – zehn Regeln, in denen Jahre von Entscheidungen stecken. Wenn die verschwinden, arbeitet die KI zwar weiter, aber sie arbeitet nicht mehr *bei uns*. Sie fällt zurück auf den Durchschnitt ihres Trainings, und genau davor sollte das Grounding ja schützen.

Diese Rangordnung ist der Grund, warum ich die erste Schicht so klein halte. Ein knappes, dichtes Konventionsdokument überlebt jeden Budget-Druck, weil es billig ist, es zu behalten. Ein ausuferndes konkurriert mit den Roh-Dokumenten um Platz – und verliert dann Zeile für Zeile, ohne dass es jemand merkt. Kuratieren ist hier keine Fleißarbeit, sondern die Bedingung dafür, dass das Wichtige im entscheidenden Moment überhaupt noch da ist.

## 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. Es verschiebt die Fehlerquote – deutlich, in meiner Erfahrung um Größenordnungen bei allem, was Felder, Endpunkte und Strukturen betrifft. 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 wer Grounding als Freifahrtschein verkauft, hat das Prinzip nicht verstanden, sondern nur das Wort gelernt.

Bleibt ein Faden, der mich seither nicht loslässt. 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 dass daraus ein Datenfriedhof wird – davon handelt die nächste Folge.

## Weiterführende Quellen

- [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) – Anthropics Engineering-Beitrag zu Kontext als endlicher Ressource
- [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks](https://arxiv.org/abs/2005.11401) – das RAG-Originalpapier von Lewis et al. (2020)
- [GraphQL Introspection](https://graphql.org/learn/introspection/) – wie ein GraphQL-Schema über sich selbst Auskunft gibt
- [OpenAPI Specification](https://spec.openapis.org/oas/latest.html) – der Standard für maschinenlesbare HTTP-API-Beschreibungen
- [Model Context Protocol](https://modelcontextprotocol.io/) – offener Standard, um KI-Werkzeugen echte Datenquellen und Systeme zugänglich zu machen