Das Missverständnis mit dem Kontext-Window
Wenn man von "Kontext" spricht, denken viele zuerst an die Größe des Kontext-Windows. Je größer, desto besser. Diese Intuition ist verständlich, aber sie führt in die falsche Richtung. Ein großes Kontext-Window ist wie ein großes Whiteboard — es hilft nichts, wenn man das Falsche draufschreibt.
Das eigentliche Problem ist nicht die Menge an Information, die man übergeben kann, sondern die Qualität dieser Information. Ein Modell mit präzisem Kontext schlägt ein Modell mit viel Kontext fast immer.
Was ein Modell wirklich braucht
Aus praktischer Erfahrung drei Kategorien, die wirklich helfen:
- Fakten, die nicht ableitbar sind: Eigenheiten deines Systems, das nicht in Dokumentationen steht. Spezifische Constraints. Entscheidungen aus vergangenen Reviews.
- Direkt relevanter Code: Die 30–50 Zeilen, die für die Aufgabe tatsächlich relevant sind — nicht die ganze Datei.
- Das Ziel in einer Zeile: Was soll am Ende anders sein? Präziser als man denkt, dass es nötig ist.
Was du weglassen kannst
Irrelevante Dateien, die "vielleicht relevant sein könnten". Lange Kommentar-Blöcke die den Code beschreiben. Boilerplate-Code ohne Relevanz für die Aufgabe. Wiederholte Erklärungen desselben Sachverhalts.
Jedes Token, das keine Information trägt, verdrängt ein Token, das trägt. Token-Disziplin ist kein Sparmaßnahme — sie verbessert aktiv die Qualität der Antworten.
Halluzinationen durch Kontext verhindern
Die meisten Halluzinationen entstehen nicht aus dem Nichts. Sie entstehen, weil das Modell an einer Stelle, wo Information fehlt, mit einer plausiblen Annahme füllt. Das ist kein Bug, sondern das Modell tut genau das, wofür es trainiert wurde.
Konsequenz: Stellen mit hohem Halluzinations-Risiko sind Stellen, an denen der Kontext lückenhaft ist. Wer diese Lücken identifiziert und füllt, reduziert Halluzinationen effektiver als jede Prompt-Formel.
Persistenter Kontext vs. Session-Kontext
Eine Unterscheidung, die ich zunehmend wichtig finde: Einige Informationen sind für eine Session relevant, andere für alle Sessions. Session-Kontext: der aktuelle Bug, die spezifische Datei, der konkrete Fehler. Persistenter Kontext: Architektur-Entscheidungen, bekannte Eigenheiten, Team-Konventionen.
Wer persistenten Kontext in einer Memory-Datei hält und ihn automatisch beim Session-Start lädt, spart sich Erklärungen und verhindert, dass das Modell in jeder Session von vorn beginnt.