Retrieval schlägt ein 1M-Token-Fenster für Ihre Codebasis noch immer

Vor einigen Wochen debuggte ich einen Auth-Bug in einem Nebenprojekt – ein TypeScript-Backend, ungefähr 140 Dateien, bequem unter einer Million Token. Ich hatte ein 1M-Token-Modell vor mir, also tat ich das Bequeme: Ich warf den gesamten src/-Baum in einen einzigen Prompt und bat den Agenten, herauszufinden, wo das Session-Token aktualisiert wurde und warum es manchmal nicht aktualisiert wurde.

Er las alles. Das kostete mich für diesen einen Zug eine stattliche Summe an Eingabe-Token. Und er wies mich zuversichtlich auf einen refreshToken-Helper hin, der richtig aussah – aber falsch war. Es gab zwei davon, in verschiedenen Modulen, und der ausgewählte befand sich nicht auf dem Pfad, der ausgeführt wurde. Ich hatte ihm den ganzen Heuhaufen gegeben, und er griff eine plausible Nadel aus der Mitte.

Dann schloss ich diese Sitzung, öffnete eine neue mit demselben Modell und ließ es auf die übliche Weise arbeiten: Baum auflisten, nach refreshToken grep'en, die drei übereinstimmenden Dateien lesen, den Importen folgen. Es fand den echten Bug in etwa einem Viertel der Token und einem Drittel der Echtzeit. Dasselbe Modell. Dasselbe Repository. Der Unterschied lag vollständig darin, wie ich ihm den Code übergeben hatte.

Kurzfassung: Für eine echte Codebasis ist es meistens der schlechtere Schritt, alles in ein riesiges Kontextfenster zu werfen – nicht weil das Fenster zu klein ist, sondern weil Modelle messbar unzuverlässiger werden, je mehr man es füllt, und Code ist der schlechteste Input für dieses Versagen. Gezieltes Retrieval – grep, Symbol-Indexierung, abhängigkeitsbewusstes Lesen – gewinnt bei Kosten, Latenz und Genauigkeit für die meisten Code-Aufgaben. Langer Kontext gewinnt in einigen spezifischen Fällen, und ich gebe Ihnen die Regel am Ende.

Die Fensterzahl ist real; der nutzbare Teil nicht

Zunächst der Teil, der stimmt: Die großen Zahlen existieren. Stand Juni 2026 bieten die drei führenden Coding-Modelle – Claude Opus 4.8, GPT-5.5 und Gemini 3.1 Pro – alle ein 1M-Token-Fenster, und mehr als dreizehn gehostete Frontier-Modelle bewerben 1M oder mehr (Morph's Context-Window-Vergleich). Anthropic und OpenAI haben sogar den Aufpreis für langen Kontext abgeschafft, sodass jetzt die gleiche Gebühr pro Token im gesamten Fenster berechnet wird.

Das Problem ist, dass beworben und nutzbar unterschiedliche Zahlen sind. Unabhängige Recall-Tests im Jahr 2026 zeigen immer wieder, dass die tatsächliche Kapazität deutlich unter dem Etikett liegt – eine Zusammenfassung setzt die effektive Kontextlänge auf etwa 50–65 % des Nominalwerts und berichtet von MRCR-Multi-Nadel-Werten, die in der zweiten Fensterhälfte einbrechen: Gemini 3.1 Pro hält ~84,9 % Recall im 128K–256K-Band und bricht auf 26,3 % im 512K–1M-Band ein (CodingFleet's "context window lie"-Analyse). Behandeln Sie die genauen Prozentzahlen als Richtungswerte – es sind Hersteller-Benchmark-Zahlen, keine kontrollierte Studie – aber die Form ist überall konsistent: Der Recall nimmt ab, bevor das Fenster voll ist.

Dieser Abfall hat einen Namen und eine Forschungsgeschichte, und er ist für Code wichtiger als für fast alles andere.

Warum Code der schlechteste Input für ein volles Fenster ist

Zwei gut replizierte Effekte arbeiten gegen Sie, wenn Sie ein Repository in einen einzigen Prompt stopfen.

Im Mittelfeld verloren. Die Liu et al.-Studie (veröffentlicht in TACL) zeigte, dass die Modellgenauigkeit eine U-förmige Funktion davon ist, wo die relevanten Informationen stehen: am höchsten, wenn sie am Anfang oder Ende des Kontexts stehen, und um mehr als 30 % schlechter, wenn sie in der Mitte vergraben sind – und das galt über sechs Modellfamilien bei Multi-Dokument-QA und Schlüssel-Wert-Retrieval. Eine Codebasis ist nichts anderes als "relevante Informationen in der Mitte." Die Funktion, die Sie brauchen, ist selten die erste oder letzte Datei, die Sie eingefügt haben.

Kontext-Fäulnis. Chroma's Studie von 2025 testete 18 Frontier-Modelle – Claude Opus 4 / Sonnet 4 / 3.7 / 3.5 / Haiku 3.5, OpenAI o3 und die GPT-4.1-Familie, Gemini 2.5 Pro/Flash und drei Qwen3-Größen – und stellte fest, dass die Leistung mit wachsender Eingabelänge abnimmt, sogar bei trivialen Aufgaben wie dem Finden eines Strings oder dem Replizieren wiederholter Wörter (Chroma's "Context Rot"-Bericht). Der Befund, der jeden Code-Agent-Entwickler beunruhigen sollte: Bei der LongMemEval-Aufgabe schnitt jedes Modell mit der vollständigen ~113k-Token-Historie schlechter ab als mit einem fokussierten ~300-Token-Auszug desselben relevanten Inhalts. Mehr Token des richtigen Materials, in Masse präsentiert, erzielten niedrigere Werte als ein kleiner kuratierter Ausschnitt.

Es gibt ein Detail in diesem Bericht, das fast lustig ist, wenn man Code schreibt: Modelle schnitten schlechter ab, wenn der Heuhaufen "einen logischen Gedankenfluss bewahrte" als wenn er durchmischt war. Ein Repository ist maximal logisch strukturiert – Imports, Call-Graphen, Typdefinitionen, geordnete Module. Sie geben dem Modell genau die Input-Form, mit der es am schlechtesten umgeht.

Und Code bestraft das Versagen härter als Prosa. Wenn ein Chatbot einen Satz eines langen Dokuments übersieht, gibt er eine etwas vage Antwort. Wenn ein Code-Agent die echte refreshToken-Definition übersieht, schreibt er Code, der eine Methode aufruft, die nicht existiert, oder die falsche Funktion repariert – und er tut das zuversichtlich. Wie es in einer Analyse des Agenten-Retrieval formuliert wurde: "Die Fehlerart von RAG in Coding-Kontexten ist still und kumulativ" (MindStudio). Falsches Retrieval gibt keinen Fehler. Es wird deployt.

Was "Retrieval" für Code bedeutet (meistens keine Embeddings)

Wenn Menschen "Retrieval" hören, denken sie an eine Vektordatenbank. Für Code greifen die Agenten, die tatsächlich in die Produktion gehen – Claude Code, Cursor, Devin – meistens nicht zuerst darauf zurück. Sie navigieren so, wie es ein erfahrener Entwickler tun würde: Dateibaum anschauen, nach einem Symbol grep'en, die spezifischen übereinstimmenden Dateien lesen, der Import-Kette folgen (MindStudio). Das primäre Suchwerkzeug von Claude Code ist ripgrep – schnelles, exaktes, zeilennummeriertes Textmatching, das auf jedem Repository ohne Vorverarbeitung funktioniert.

Es gibt einen guten Grund, warum Vektoren nicht der Standard für Code sind, und es ist keine Nostalgie. Ein nützlicher Rahmen sind drei Schichten, mit Eskalation nur bei Bedarf (Code-Suche für KI-Agenten):

• Lexikalisch (ripgrep): Exakte Übereinstimmung, Millisekunden, gitignore-aware. Ihr Standard.
• Strukturell (ast-grep): AST-Muster-Matching – "jede async-Funktion finden", "jedes catch-and-rethrow" – Dinge, die Regex nicht sauber ausdrücken kann. Hier eskalieren, wenn die Anfrage über Form geht, nicht über Strings.
• Semantisch (Embeddings / Repo-Map): Konzeptuelle Anfragen in natürlicher Sprache. Letzter Ausweg.

Warum ist Semantik der letzte Ausweg und nicht der erste? Weil die Anfragen, die ein Code-Agent tatsächlich generiert, kurz und symbolförmig sind – auth flow, user service, refreshToken – und das ist genau das Format, das die Embedding-Suche zum Scheitern bringt. Der CoREB-Benchmark stellte fest, dass kurze Schlüsselwortanfragen "fast jedes getestete semantische Modell auf nahezu null nDCG@10 kollabieren lassen." Embeddings erfassen Bedeutungsähnlichkeit; Code ist ein Graph von Abhängigkeiten, Importen und Typdefinitionen, und Ähnlichkeit ist nicht die Beziehung, die Sie abfragen. Zwei Funktionen können semantisch nahezu identisch und strukturell unverbunden sein; die, die Sie brauchen, ist die im Aufrufpfad, nicht die ähnlich klingende.

Das macht semantische Indexierung nicht nutzlos – es macht sie zum Spezialisten. Wenn sie ihren Platz verdient, embedden gute Implementierungen keine willkürlichen Textfenster. Sie parsen mit tree-sitter in echte Einheiten – Funktionen, Klassen, Interfaces mit ihren Docstrings – halten diese Chunks ganz und kombinieren Vektorähnlichkeit mit BM25-Schlüsselwortmatching plus Call-Graphen-Werkzeuge für Abhängigkeitsverfolgung und Blast-Radius-Analyse (opencode-codebase-index). Das ist das ganze Spiel beim Code-Retrieval: Abhängigkeitsbewusstes Chunking an Symbolgrenzen mit Schlüsselwort-Fallback – nicht "die Datei alle 512 Token aufteilen und hoffen."

Die Kosten- und Latenz-Mathematik, die niemand macht

Stellen Sie die Genauigkeit kurz beiseite und rechnen Sie nur die Rechnung durch. Nehmen wir an, ein mittleres Repository hat 600K Token. Es in einem Zug einzuwerfen bedeutet, 600K Eingabe-Token bei jedem Zug des Gesprächs zu bezahlen, es sei denn, Sie cachen sorgfältig – und selbst beim Caching tragen Sie die Latenz des Modells, das auf alles davon achtet. Ein Retrieval-Durchlauf sendet stattdessen den Baum (ein paar KB), ein grep-Ergebnis (ein paar hundert Token) und vielleicht vier Dateien, die Sie tatsächlich lesen (~15K Token). Das ist kein Rundungsfehler-Unterschied; das sind ein bis zwei Größenordnungen pro Zug, multipliziert mit jedem Zug in einer Debug-Sitzung.

Die Latenz folgt der gleichen Kurve. Ein Modell, das über 600K Token nachdenkt, ist langsamer bis zum ersten Token und insgesamt als dasselbe Modell, das über 18K nachdenkt. In einer interaktiven Schleife, in der Sie zwanzig Züge machen, um einem Bug zu folgen, summiert sich das zu Minuten nutzlosen Wartens. Retrieval hält jeden Zug klein, sodass jeder Zug schnell ist, sodass die Schleife straff bleibt.

Und es gibt einen stilleren Preis: das Aufmerksamkeitsbudget. Jede irrelevante Datei im Fenster ist ein Ablenkungsfaktor, und Chroma zeigte, dass Ablenkungsfaktoren die Genauigkeit messbar nach unten ziehen – ein Ablenkungsfaktor schadete, vier verschlimmerten es. Ein vollständiges Repository im Kontext sind Tausende von Ablenkungsfaktoren für jede gegebene Frage. Sie zahlen nicht nur mehr, um langsamer zu sein; Sie zahlen mehr, um langsamer und ungenauer zu sein.

Wann langer Kontext tatsächlich gewinnt

Das ist kein "immer Retrieval." Es gibt einen echten Bereich, in dem alles einzuwerfen die richtige Wahl ist, und er wird durch die Repository-Größe und die Aufgabenform bestimmt, nicht durch die Größe des Fensters, für das Sie zahlen.

Langer Kontext gewinnt, wenn:

• Das gesamte Repository mit Spielraum passt – sagen wir unter ~150K Token, gut im hochrekall-Bereich des Fensters – und die Aufgabe dateiübergreifendes Reasoning erfordert, das schwer stückweise abzurufen ist. Ein kleines Repository, bei dem alles wichtig ist, ist genau der Fall, den Retrieval verkompliziert.
• Sie Ganz-Datei- oder Ganz-Modul-Reasoning auf einmal benötigen – eine einzige große Datei, die Sie vollständig refaktorieren möchten, eine Sicherheitsprüfung eines Moduls von oben nach unten, eine Architekturüberprüfung, bei der das Modell die Beziehungen gleichzeitig im Blick haben muss. Retrieval fragmentiert das; Kontext bewahrt es.
• Es ein einmaliger, lesender Durchlauf ist, keine iterative Schleife. Ein einzelner "Diesen PR prüfen"- oder "Zusammenfassen, wie dieser Dienst funktioniert"-Aufruf amortisiert die Kosten über einen Zug. Die Wirtschaft, die langen Kontext tötet – das volle Fenster bei jedem Zug zu bezahlen – greift nicht, wenn es nur einen Zug gibt.

Retrieval gewinnt überall sonst, was in der Praxis der Großteil der Arbeit ist: jedes Repository, das nicht komfortabel passt, alles Iterative, alles, wo Sie eine spezifische Definition statt eines allgemeinen Verständnisses benötigen, und alles, wo still-falsches Retrieval kaputten Code ausliefern würde.

Eine grobe Regel, die ich tatsächlich verwende: Wenn die relevante Scheibe der Aufgabe kleiner als das Repository ist, retrieven Sie. Wenn die Aufgabe das gesamte Repository ist und das Repository in die ersten ~15 % des Fensters passt, laden Sie es. Die meisten Tage ist die Scheibe kleiner als das Repository.

Die Quintessenz

Das 1M-Token-Fenster ist eine echte Fähigkeit, und es lohnt sich, die aufschlagsfreien Preise für die Aufgaben zu nutzen, bei denen es gut ist – einmalige Überprüfungen von Code, der passt, Ganz-Modul-Reasoning, das gelegentliche kleine Repository, bei dem alles relevant ist. Aber es ist kein Ersatz dafür zu wissen, wo Ihr Code lebt. Für einen funktionierenden Code-Agenten ist der langweilige Stack – Baum auflisten, Symbol grep'en, die vier übereinstimmenden Dateien lesen, Importen folgen, erst zu AST oder Embeddings eskalieren, wenn die Schlüsselwortsuche leer zurückkommt – günstiger, schneller und genauer als der beeindruckende. Die große Zahl auf dem Datenblatt ist eine Option, keine Anweisung. Meistens füllen Sie sie nicht aus.