Langer Kontext vs. Retrieval: einfach das ganze PDF reinkippen?

Die Versuchung von 2026

Jahrelang war das Kontextfenster die harte Grenze dafür, was man ein Modell über ein Dokument fragen konnte. Diese Decke ist gefallen. 2026 werben Spitzen- und Open-Weight-Modelle mit Kontextfenstern von 128K, 200K, sogar einer Million Tokens, und eine Million Tokens entsprechen grob ein paar tausend Seiten Text. Daraus folgt eine naheliegende Frage: Wenn das Modell den ganzen Dokumentenbestand auf einmal lesen kann, warum dann überhaupt Retrieval bauen? Warum nicht einfach das gesamte PDF (oder das ganze Regal voller PDFs) in den Prompt kippen und die Frage stellen?

Das ist eine berechtigte Frage. Die ehrliche Antwort lautet „manchmal". In diesem Artikel geht es darum, die beiden Fälle auseinanderzuhalten, denn die falsche Standardentscheidung wird schnell teuer.

Warum „alles reinkippen" so verlockend ist

Der Reiz ist real, und er besteht vor allem aus Einfachheit.

• Es gibt keine Pipeline zu bauen. Keine Chunking-Strategie, keine Embeddings, keine Vektordatenbank zu betreiben, kein Re-Indexing-Job zu planen. Man verkettet den Text und schickt ihn ab.
• Das Modell sieht alles. Nichts wurde durch einen Retrieval-Schritt herausgefiltert, der ausgerechnet die eine benötigte Passage hätte verwerfen können. Das vollständige Dokument liegt direkt vor dem Modell.
• Es ist der kürzeste Weg zu einer Antwort. Für eine einzelne Datei und eine einmalige Frage ist das Reinkippen tatsächlich der richtige Zug.

Wenn das Einfachste funktioniert, mach das Einfachste. Der Haken: „Alles reinkippen" hört in dem Moment auf, das Einfachste zu sein, in dem der Anwendungsfall über ein Dokument und eine Frage hinauswächst.

Warum es oft verliert

Die Kosten skalieren mit jeder Anfrage. Bei einer Cloud-API zahlt man pro Input-Token, und zwar bei jeder einzelnen Anfrage. Wenn das Corpus 300K Tokens umfasst und man vierzig Fragen am Tag stellt, liest man diese 300K Tokens vierzig Mal neu, egal ob die Antwort in einem einzigen Absatz stand. Nur den relevanten Abschnitt abzurufen macht daraus ein paar tausend Tokens pro Anfrage. Der Unterschied summiert sich rasch.

Die Latenz skaliert ebenfalls. Ein Modell muss den gesamten Input verarbeiten, bevor es das erste Ausgabe-Token erzeugt: der Prefill-Schritt. Mehr Input bedeutet längeres Warten. Bei einem Cloud-Endpoint ist das spürbar; auf lokaler Hardware, wo man gemietete GPUs gegen eigene tauscht, kann das Prefill einer Viertelmillion Tokens pro Frage über den Unterschied zwischen einem flüssigen Werkzeug und einem entscheiden, das niemand benutzen will.

Lost in the Middle. Das ist der subtile Punkt. Modelle achten nicht gleichmäßig über einen langen Kontext hinweg. Ein gut dokumentierter Befund (oft „Lost in the Middle"-Effekt genannt) besagt, dass Informationen, die in der Mitte eines sehr langen Inputs vergraben sind, weniger zuverlässig abgerufen werden als dieselbe Information am Anfang oder Ende. Die praktische Folge: Der nutzbare Teil eines langen Kontextfensters ist meist kleiner als die plakative Zahl. Ein 200K-Fenster garantiert keine 200K Tokens mit gleicher Aufmerksamkeit. Context Engineering behandelt das als erstrangige Designvorgabe, nicht als Fußnote.

Keine Herkunft, kein Determinismus. Wenn man ein ganzes Corpus in den Prompt kippt und eine Antwort zurückbekommt, kann man oft nicht sagen, welche Passage sie begründet hat. Das ist aus zwei Gründen wichtig. Erstens Zitate: regulierte Arbeit (Recht, Medizin, Finanzen) muss auf den genauen Quelltext zeigen, und ein Voll-Kontext-Dump macht das schwer rekonstruierbar. Zweitens Zählen: Fragt man „wie viele Rechnungen überschreiten den Schwellenwert?", schätzt ein Modell, das einen riesigen Kontext überfliegt, womöglich. Gezieltes Retrieval grenzt den Input auf die relevanten Datensätze ein und ermöglicht eine deterministische Zählung darüber. (Die tiefere Variante dieses Arguments, bei der das Modell die Struktur findet und der Code zählt, ist ein eigenes Thema.)

Wann langer Kontext wirklich gewinnt

Fair gegenüber der Gegenseite: Es gibt echte Fälle, in denen alles reinzukippen die richtige Wahl ist.

• Ein einzelnes, mittelgroßes Dokument. Ein Vertrag, ein Paper, ein Bericht, der bequem ins Fenster passt. Dafür Retrieval-Infrastruktur zu bauen wäre Over-Engineering.
• Globale Synthese. „Fasse die Argumentation dieses ganzen Buches zusammen", „finde jede Stelle, an der sich diese zwei Kapitel widersprechen", „wie ist der Gesamtton?" Hier muss das Modell das gesamte Dokument auf einmal halten. Retrieval, das per Definition Teile holt, ist hier das falsche Werkzeug.
• Einmalige Fragen. Wenn man dies einmal fragt und nie wieder, sind Kosten und Latenz eines Voll-Kontext-Durchlaufs irrelevant. Es gibt nichts, wogegen sich eine Pipeline amortisieren ließe.

Langer Kontext ist eine echte Fähigkeit, keine Falle. Der Fehler besteht darin, ihn als Ersatz für Retrieval zu behandeln statt als Ergänzung dazu.

Wann Retrieval gewinnt

Das Gleichgewicht kippt, sobald Skala oder Wiederholung ins Spiel kommen.

• Große oder wachsende Corpora. Eine ganze Wissensbasis passt in kein Fenster, und selbst wenn sie es fast tut, untergräbt Lost in the Middle den Nutzen.
• Wiederholte Anfragen. Stellt man demselben Corpus hundert Fragen, ist es reine Verschwendung, es hundert Mal neu zu lesen. Hol stattdessen jedes Mal nur den relevanten Ausschnitt.
• Exakte, zitierte, prüfbare Antworten. Wenn man zeigen muss, welcher Satz eine Aussage stützt, liefert Retrieval die Herkunft per Konstruktion.
• Begrenztes, strukturiertes Wissen. Ein konvertiertes Handbuch, ein Richtliniensatz, eine Produktspezifikation, alle so organisiert, dass eine gezielte Suche jedes Mal auf dem richtigen Abschnitt landet. Das ist das Regime, in dem Retrieval ohne Vektordatenbank glänzt: grep und direkte Lesezugriffe über einfache Dateien, kein Index zu pflegen.

Die Haltung von pdf2okf

pdf2okf steht klar auf der Seite „das Fenster bewusst nutzen". Es wandelt ein PDF in OKF-kompatibles Markdown um (strukturierte Konzeptdateien, die ein Agent nach Dateiname und Überschrift durchsuchen kann) und gibt dem Modell nur die Konzepte, die eine Frage tatsächlich berührt, samt der relevanten Abbildungen. Es gibt keine Vektordatenbank; Retrieval ist schlicht grep über einfache Dateien. (OKF ist Googles Open-Knowledge-Format-Standard; pdf2okf ist damit kompatibel, nicht dessen Urheber.)

Das Ergebnis ist das Beste aus beiden Welten. Antworten bleiben exakt und zitiert, weil das Modell in konkreten Passagen verankert ist, nicht in einem probabilistischen Schleier des ganzen Corpus. Man zahlt nicht dafür, bei jeder Anfrage alles neu zu lesen. Und weil das Retrieval gezielt ist, wird das Kontextfenster für Signal statt Füllmaterial verwendet. Genau so vermeidet man Lost in the Middle. Wenn eine Anfrage tatsächlich mehrere Konzepte durchlaufen muss, liest agentisches Retrieval sie nacheinander und synthetisiert daraus.

Langer Kontext und Retrieval sind keine Rivalen. Der lange Kontext ist der Raum; das Retrieval entscheidet, was hineinkommt. Die Lehre aus 2026 lautet nicht „das Fenster ist groß genug, hör auf mit Retrieval", sondern „das Fenster ist groß genug, dass nun wie man es füllt das eigentliche Spiel ist". Ein größeres Kontextfenster ist ein Grund, bewusster damit umzugehen, was hineinkommt, nicht weniger bewusst. pdf2okf nutzt es bewusst, niemals als Abladeplatz.