Die Antwort — und die Frage, die dabei meist falsch gestellt wird
Kurz gefasst: Ein einzelnes Dokument — oder ein kleiner, für alle gleicher Satz von Dokumenten — gehört direkt ins Kontextfenster, ganz ohne Suchpipeline. Eine Suche brauchen Sie, wenn das Material groß ist, sich häufig ändert oder je nach Fragesteller unterschiedlich aussieht. Diese Faustregel stimmt, und wenn Sie nur die Regel wollten, können Sie hier aufhören.
Interessant sind die nächsten acht Minuten wegen der Begründung. Denn das übliche Argument — „ein Kontextfenster mit einer Million Token fasst Ihre 40 GB SharePoint trotzdem nicht“ — ist das am wenigsten brauchbare Kriterium. Viele reale Bestände passen sehr wohl hinein. Der komplette Servicehandbuchsatz eines Maschinenbauers liegt vielleicht bei 300.000 Token, die Versicherungsbedingungen einer Sparte bei 80.000. Beides passt bequem, und irgendjemand wird Ihnen raten, das einfach vollständig in den Prompt zu legen.
Das bessere Kriterium fragt nach der Form, nicht nach der Menge: Ist der Anfang des Prompts bei jeder einzelnen Anfrage Byte für Byte identisch? Wenn ja, ist langer Kontext oft erstaunlich günstig. Wenn nein, ist er erstaunlich teuer — und keine Fehlermeldung wird Sie warnen, weil Sie die Grenze des Kontextfensters nie erreichen.
Was ein langer Prompt tatsächlich kostet
Ein Long-Context-Ansatz schickt das Dokument nicht einmal, sondern bei jeder Frage erneut. Zehntausend Serviceanfragen gegen einen Handbuchsatz von 200.000 Token sind zwei Milliarden Eingabe-Token, nicht zweihunderttausend. Das ist die Rechnung, die übersprungen wird — und der Grund, warum die vermeintlich einfachere Architektur still und leise die teurere wird. Wo bei einem KI-Projekt sonst noch Geld hingeht, steht an anderer Stelle; hier interessiert nur dieser eine Posten pro Anfrage.
Prompt-Caching ändert die Rechnung — bis es das nicht mehr tut
Alle großen Anbieter bieten inzwischen Prompt-Caching an, und erst das hat langen Kontext wirtschaftlich tragfähig gemacht, nicht nur technisch möglich. Die Mechanik bei Anthropic ist repräsentativ: Ein Cache-Lesezugriff kostet grob ein Zehntel des normalen Eingabepreises, das Schreiben des Caches 1,25× (fünf Minuten Haltedauer) beziehungsweise 2× (eine Stunde). Schon zwei Anfragen auf denselben zwischengespeicherten Prompt-Anfang sind günstiger, als ihn zweimal ungecacht zu schicken.
Auf das Servicebeispiel angewandt: Der Handbuchsatz wird nicht mehr zehntausendmal zum vollen Preis abgerechnet, sondern zu etwa einem Zehntel, zuzüglich eines erneuten Schreibvorgangs, sobald der Cache abgelaufen ist. Das ist kein Rabatt, sondern ein Unterschied der Größenordnung — und der Grund, warum „das Handbuch einfach in den Prompt legen“ vom naiven zum vertretbaren Vorgehen geworden ist.
Der Haken steckt in einem Wort: Anfang. Caching funktioniert über einen Präfix-Abgleich. Der Schlüssel entsteht aus den exakten Bytes des Prompts von Position null bis zur Cache-Markierung. Ändert sich in diesem Bereich ein einziges Byte, ist alles danach ungültig — Sie zahlen wieder den vollen Preis, ohne Fehler, ohne Warnung, ohne Logeintrag. Auffallen wird es auf der Rechnung.
Berechtigungen sind es, die den Cache still zerstören
Das ist der Fehler, den ich am häufigsten sehe, und er fällt fast immer erst nachträglich auf. Der Prototyp legt sämtliche Dokumente in den Prompt, das Caching greift wunderbar, die Zahlen sehen gut aus. Dann stellt jemand die naheliegende Produktivfrage: Darf ein Mitglied des Betriebsrats dieselben Unterlagen sehen wie ein Schichtleiter? Sieht die Niederlassung München die Verträge aus Hamburg?
Also filtert das Team die Dokumente vor dem Zusammenbauen des Prompts nach Nutzer. Architektonisch fühlt sich das nach einer Kleinigkeit an — gleicher Aufbau, ein Filterschritt mehr. Wirtschaftlich ist es ein anderes System. Jeder Nutzer hat jetzt einen eigenen Prompt-Anfang, also einen eigenen Cache-Eintrag, und jeder dieser Einträge muss erst zu 1,25× geschrieben werden, bevor er überhaupt zu 0,1× gelesen werden kann. Bei ein paar hundert Nutzern mit je einer Handvoll Fragen laufen die meisten Einträge ab, bevor sie ein zweites Mal gelesen werden. Sie haben den Schreibaufschlag bezahlt und den Leserabatt nie kassiert.
Ein Suchindex kennt dieses Problem nicht: Berechtigungen sind dort Metadatenfilter auf der Anfrage, und der teure Teil — Einbetten und Indexieren — ist einmalig offline für alle passiert. Das ist das Argument für RAG, das jede Vergrößerung des Kontextfensters überlebt, weil es gar nicht von Kapazität handelt.
Der nutzbare Kontext ist kürzer als die Zahl auf der Packung
Neben den Kosten steht die Qualitätsfrage — und die Marketingzahl ist nicht ihre Antwort. Ein Modell mit einem Kontextfenster von einer Million Token schließt nicht über alle Million Token gleich gut.
Drei Ergebnisse sollten Sie namentlich kennen. Liu et al. zeigten 2023 in Lost in the Middle, dass die Trefferquote am höchsten ist, wenn die relevante Stelle nahe am Anfang oder am Ende der Eingabe steht, und messbar abfällt, wenn sie in der Mitte vergraben liegt. NVIDIAs Benchmark RULER ergänzte Aufgaben mit mehrstufiger Verkettung und Aggregation und stellte fest, dass die meisten Modelle deutlich vor ihrer beworbenen Länge unter eine brauchbare Qualitätsschwelle fallen. Am schärfsten ist NoLiMa von Adobe Research (ICML 2025): Dort wird die wörtliche Überschneidung zwischen Frage und gesuchter Stelle entfernt, das Modell muss den Zusammenhang also erschließen statt den Wortlaut der Frage wiederzufinden — und unter dieser Bedingung fallen viele Modelle schon bei 32.000 Token unter die Hälfte ihres Kurzkontext-Werts.
Warum die Demo besteht und der Produktivbetrieb nicht
Genau dieses NoLiMa-Detail erklärt einen Fehlerverlauf, den ich mehrfach beobachtet habe. In der Demo formuliert der Vorführende seine Fragen im Vokabular des Dokuments — er hat die Demo ja nach dem Lesen gebaut. Die Suche über Wortüberschneidung ist trivial, das Modell findet die Stelle, alles wirkt gelöst. Im Betrieb tippt ein Servicetechniker „Anlage bleibt beim Nullpunktsuchen hängen“, und im Handbuch steht „Zeitüberschreitung Achsreferenzierung“. Kein gemeinsames Wort, kein Anker, hundert Seiten Abstand. Das System, das in der Sitzung fehlerfrei war, beginnt plausibel klingende Antworten zu erfinden.
Das ist kein Argument dafür, dass eine Suchpipeline immun wäre — ein Einbettungsmodell, das Ihr Fachvokabular nie gesehen hat, scheitert an derselben Frage, weshalb die Wahl der Textabschnitte und eine zusätzliche Stichwortsuche so viel ausmachen. Der Punkt ist enger: Ein langes Kontextfenster beseitigt das Suchproblem nicht. Es verlagert es ins Modell hinein, wo Sie es weder einsehen noch protokollieren noch mit einem Metadatenfilter reparieren können.
Was ein Prompt nicht kann und ein Index schon
Unabhängig von Kosten und Qualität bleiben drei praktische Lücken — und die entscheiden die meisten Projekte.
Aktualität. Ein Prompt besteht aus dem, was Ihr Code zum Zeitpunkt der Anfrage geladen hat. Wenn sich heute Morgen eine Preisliste geändert hat, weiß Ihr Zusammenbau das entweder und liest die Datei neu ein — dann haben Sie eine kleine, unversionierte Datenübernahme geschrieben, ohne es zuzugeben — oder Sie liefern die Preise von gestern aus. Ein Index hat einen definierten Aktualisierungsweg und einen definierten Zeitpunkt, ab dem neue Inhalte sichtbar sind.
Nachvollziehbarkeit. Wenn eine Suche fünf Textstellen auswählt, wissen Sie welche fünf, aus welchen Dokumenten, mit welcher Bewertung. Sie können die Quelle anzeigen, die Auswahl protokollieren und Monate später rekonstruieren, warum das System so geantwortet hat. Legen Sie 200 Seiten in den Prompt, ist die Auswahl des Modells unsichtbar. „Stand irgendwo im Kontext“ ist kein Prüfnachweis und wird niemanden zufriedenstellen, der eine Entscheidung im Nachhinein bewerten muss.
Löschen. Ein Dokument aus einer Liste zu streichen, aus der der Prompt gebaut wird, ist trivial; es aus einer Vektordatenbank zu entfernen, ist deutlich schwerer als es aussieht. Diese Asymmetrie ist real und spricht ehrlicherweise für den langen Kontext — aber nur, solange Sie gar keinen Index betreiben. Die meisten Systeme haben am Ende beides, und dann gehört Ihnen das Löschproblem ohnehin.
Was ich tatsächlich baue — und was nicht
In der Praxis liegen die interessanten Systeme nicht an den Enden dieser Achse. Was funktioniert: großzügig suchen, großzügig übergeben. Holen Sie dreißig oder fünfzig Kandidaten statt der klassischen drei, denn das Fenster verträgt es — aber suchen Sie weiterhin, damit die Auswahl explizit bleibt, nach Berechtigung filterbar ist und im Fehlerfall prüfbar. Das größere Kontextfenster hat Ihnen Spielraum gekauft, in der Rangfolge weniger präzise sein zu dürfen; es hat Ihnen nicht das Recht gekauft, diesen Schritt wegzulassen. Es ist dieselbe Architektur, die ich unter RAG-Pipelines erklärt beschreibe, nur mit einem sehr viel breiteren Trichter als vor zwei Jahren bezahlbar war.
Wo ich die Suche wirklich weglasse: ein einzelner Vertrag in der Prüfung, ein Ausschreibungsdokument, ein Störungsbericht, ein Codemodul. Überall dort, wo ein Mensch den Umfang bereits auf ein Artefakt eingegrenzt hat. Eine Suchpipeline ist dort reine Kulisse — Sie indexieren einen Bestand von genau einem Dokument.
Wo ich langen Kontext nicht einsetzen würde, obwohl er funktionieren würde: bei nutzerabhängigen Zugriffsrechten, bei stündlich wechselnden Quelldaten und überall dort, wo Sie belegen müssen, aus welcher Quelle eine Antwort stammt. In diesen Fällen ist die Prompt-Variante nicht einfacher, sondern dieselbe Komplexität an einer Stelle, an der Sie sie nicht sehen.
Und die ehrliche Einschränkung zum Ganzen: Das sind Kosten- und Verhaltenseigenschaften der heutigen Modelle und der heutigen Preise. Beides bewegt sich. Was sich nicht bewegt, ist der strukturelle Punkt — Zugriffsrechte, Aktualität und Nachvollziehbarkeit sind Eigenschaften Ihrer Daten, nicht des Modells, und keine Länge eines Kontextfensters ändert daran etwas.
Wo Tippel ins Spiel kommt
Meistens wird diese Entscheidung stillschweigend getroffen — von demjenigen, der den Prototyp gebaut hat — und erst wieder aufgemacht, wenn die erste Monatsrechnung oder die erste Frage des Betriebsrats eintrifft. Deutlich günstiger ist es, sie bewusst zu treffen — mit Ihren echten Dokumenten, Ihren echten Zugriffsregeln und Fragen von den Menschen, die sie später wirklich stellen.
Genau das leistet der KI-Readiness-Check: ein Anwendungsfall, Ihre Daten, ein festes Zeitfenster und ein ehrliches Urteil am Ende — einschließlich des Urteils, dass die einfachste Variante genügt und Sie keine Pipeline brauchen. Wenn Sie die Abwägung lieber erst besprechen möchten, nehmen Sie Kontakt auf.