Kontextbasiertes Abrufen für RAG: Was die 67%-Zahl verbirgt, was sie kostet und wann sie versagt.

„Der Umsatz des Unternehmens stieg im Vergleich zum Vorquartal um 3 Prozent.“ Eine Vektordatenbank kann Tausende solcher Sätze speichern, wobei jeder einzelne von ihnen funktional nutzlos ist, solange nicht klar ist, um welches Unternehmen und welches Quartal es sich handelt.

Das Problem liegt nicht beim Modell, das die endgültige Antwort erstellt. Es liegt vielmehr an einem Datensatz, der ohne Identifikationsmerkmal in den Index aufgenommen wurde. Jeder RAG-Pipeline, der auf Unterlagen, Verträgen, technischer Dokumentation oder Quellcode basiert, ist anfällig, da diese Korpora dieselben sprachlichen Muster an Dutzenden Stellen wiederholen und dem Suchalgorithmus keine Möglichkeit bieten, diese Wiederholungen voneinander zu unterscheiden.

Die Heilmethode ist günstig. Ihr Preis wird in Dollar pro Million Token angegeben, und es wird nur ein einmal generierter Satz benötigt, der während des Aufbaus des Index geschrieben wird. In den Tests von Anthropic verringerte ein solcher Präfix fehlerhafte Abfragen um bis zu 67 %. Diese Schlagzeilenzahl verbirgt eine bestimmte Struktur, und der gewählte Anwendungsfall zur Darstellung hat seitdem ein Gegenbeispiel hervorgebracht. Zudem gibt es vier Einstellungen, bei denen die damit verbundenen Kosten schwer zu rechtfertigen sind.

Die Kernidee kurz zusammengefasst

Wenn ein Index Dokumente in Blöcke von einigen hundert Token aufteilt, verlieren einige dieser Blöcke ihr Thema sowie ihren Zeitrahmen. Der Satz „Der Umsatz stieg um 3 %“ nennt weder ein Unternehmen noch ein Quartal, und kein Embedding-Modell kann dies wiederherstellen, da die Informationen nicht im Text enthalten sind.

Die kontextbasierte Abrufmethode löst das Problem einmalig bei der Indizierung. Ein Sprachmodell erhält das gesamte Dokument zusammen mit einem Teilabschnitt und erstellt anschließend ein kurzes, situatives Präfix von fünfzig bis hundert Token, das angibt, um was es im Teilabschnitt geht, wen er betrifft und zu welchem Zeitpunkt.

Ein zweiter Schritt wird in vielen Zusammenfassungen übersprungen – und er ist der wichtige. Der erweiterte Text wird an den Vektorindex sowie an den BM25-Index weitergeleitet, einen lexikalischen Rangierer, der den Embeddings vorausging und exakte Wörter und nicht die Bedeutung abgleicht. Eine solche Maßnahme behebt somit beide Komponenten des Suchstacks – zu einem einmaligen Indizierungskostenaufwand und nicht zu zusätzlichen Kosten pro Abfrage.

In Anthropics Bewertungen führte bereits das Embedding-Präfix allein zu einer Reduzierung fehlgeschlagener Abrufe um 35 %. Der vollständige Ansatz mit BM25 und erneutem Rangieren verringerte diese Fehler um 67 %. Die Prompt-Caching-Technik sorgt dafür, dass die Kosten gering bleiben, da das gesamte Dokument nur einmal gelesen wird und nicht für jeden Teilabschnitt von vorn an.

Die Technik ist nicht universell – und genau das macht sie interessant. Zunächst der Mechanismus sowie der Prompt selbst.

Ein Präfix, das einem Chunk seine Identität verleiht

Die Intuition kommt vor der Mechanik. Ein aus einem Dokument ausgeschnittener Chunk ist wie eine aus einem Ordner gerissene Seite, ohne Überschrift, Aktenzeichen oder Datum. Wenn man ihn isoliert liest, kann man nicht erkennen, bei welchem Unternehmen die Einnahmen gestiegen sind oder wann. Ein Embedding-Modell steht vor derselben Leere – nur dass es keine Möglichkeit hat, dies anzugeben.

Der Mechanismus stellt die fehlende Überschrift wieder her. Bei der Indexierung erhält das Modell zwei Eingaben: das vollständige Queldokument sowie einen Chunk daraus, und seine einzige Aufgabe besteht darin, einen kurzen Kontext zu schreiben, der diesen Chunk in den Gesamtzusammenhang einordnet.

Anthropics Prompt passt in wenige Zeilen:

<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the
overall document for the purposes of improving search retrieval of the
chunk. Answer only with the succinct context and nothing else.

Wenn man dies auf den Beispielabschnitt anwendet, könnte die Ausgabe so aussehen: „Dieser Abschnitt stammt aus einer SEC-Meldung über die Leistung von ACME Corp im zweiten Quartal 2023; der Umsatz im vorherigen Quartal betrug 314 Millionen Dollar.“ Unmittelbar danach folgt der ursprüngliche Satz über das Wachstum von 3 %. Etwa hundert Tokens verwandeln einen isolierten Fragment in einen Eintrag mit einem Schlüssel.

Der erweiterte Text wird anschließend in zwei Indizes geschrieben. Einer ist der Embedding-Index (Contextual Embeddings), der andere der Schlüsselwort-Index (Contextual BM25). Da ACME in jedem Abschnitt ausgeschrieben wird, kann BM25 das Unternehmen auf jeder Seite des Berichts finden, während zuvor nur das Titelblatt darauf verwies.

Auch war dies nicht die erste ausprobierte Idee. Anthropic berichtete bereits über frühere Experimente mit allgemeinen Dokumentzusammenfassungen, die den Blöcken zugeordnet wurden, was „sehr begrenzte Verbesserungen“ ergab, sowie über HyDE und indexbasierte Zusammenfassungen, die ebenfalls nicht sehr wirksam waren (Anthropic, September 2024). Übrig blieb nur das Präfix.

Was eine Zusammenfassung von einem Präfix unterscheidet, ist mechanischer Natur. Eine Zusammenfassung wird von allen Blöcken eines Dokuments geteilt, sodass sie keinen Unterschied zwischen Block A und Block B im selben Jahresbericht erkennen kann, während jedes spezifische Präfix für seine eigene Position im Dokument erstellt wird.

Korpora, die aus Unterlagen, Verträgen, technischer Dokumentation oder Codebasen bestehen, in denen sich ein sprachliches Muster an vielen Stellen wiederholt, sind genau die Bereiche, in denen Blöcke heutzutage verloren gehen. Allein das Präfix zur Einbettung führt bereits zu einer 35-prozentigen Fehlerreduzierung – und das ist erst die erste Stufe.

Ein Treppenhaus in einer Zahl

„67 %“ wird oft als Effekt einer einzigen Technik angegeben. Die veröffentlichte Tabelle zeigt etwas anderes – sie lässt sich besser als eine Stufenleiter denn als einen einzigen Sprung interpretieren.

Die Ergebnisse werden als Eins minus Recall@20 gemessen: Der Anteil der Abfragen, bei denen der korrekte Teiltext nicht zu den zwanzig besten gehörte. Anthropic bezeichnet dies als Fehlerquote und gibt sie für Codebasen, Fiktion, arXiv-Papiere sowie wissenschaftliche Veröffentlichungen an.

Vier Konfigurationen bauen aufeinander auf:

• Baseline mit einfachen Embeddings für Roh-Teiltexte: 5,7 % der Abfragen scheitern.
• Nur mit kontextuellen Embeddings: 3,7 %, was einer Reduzierung von 35 % allein durch das Präfix entspricht.
• Mit zusätzlichem kontextuellen BM25: 2,9 %, was einer kumulativen Reduzierung von 49 % entspricht, wobei der Schlüsselwortindex den zusätzlichen Vorteil liefert.
• Mit zusätzlichem Reranking: 1,9 % – von hier stammt die Angabe von 67 %, dank der letzten Ebene.

Ein Reranker ist ein zweites Modell, das die Abfrage sowie einen Kandidatenabschnitt gemeinsam verarbeitet. Es ist zwar langsamer als die erste Verarbeitungsrunde, aber deutlich genauer. Hier reduzierte es 150 Kandidaten auf zwanzig. Alle vier Werte beschreiben die leistungsstärkste Embedding-Einstellung im Test, Gemini Text 004, und stellen keine Durchschnittswerte aller von Anthropic getesteten Embedding-Modelle dar.

Die Aufschlüsselung verändert die Entscheidung – und nicht nur die Darstellung der Ergebnisse. Ein Team, das bereits hybride Suchverfahren sowie Reranking in der Produktion einsetzt, sollte erwarten, dass allein die Kontextualisierung zu einem Wert nahe 35 Prozent statt 67 Prozent führt, da die anderen beiden Komponenten bereits bezahlt werden. Es ist ein leichter Fehler, die Zahl als einzigen Einflussfaktor zu betrachten; ein großer Teil der Reduzierung resultiert aus den üblichen Aufgaben der Standard-Abrufkomponenten.

In einem Thread auf Hacker News wird eine wichtige Einschränkung erwähnt: Niemand hat veröffentlicht, wie sich die einfache BM25-Methode ohne jegliche Kontextinformationen in derselben Testumgebung schlägt. Ohne diese Angabe lässt sich nicht feststellen, wie viel des Anstiegs auf 49 Prozent auf den Kontext im lexikalischen Index und wie viel auf die einfache hybride Suche zurückzuführen ist.

Eine Falle bei der Zitierung der Zahlen

Jeder, der diese Ergebnisse zitiert, kann ebenfalls in eine Rechenfalle tappen. Anthropics Leitfaden enthält ein kleineres Datensatz mit neun Codebasen und 248 Abfragen, bewertet mit einer anderen Messgröße: Pass@20 steigt von 90 Prozent im Basisszenario auf 97 Prozent beim vollständigen Stack. Verschiedenes Korpus, verschiedene Metrik – daher ist die Vermischung dieser Zahlen mit den früheren einfach ein Fehler.

Die Reduzierung kommt nicht umsonst. Sie kostet Geld bei der Indizierung, doch ein Mechanismus hält diese Kosten bei etwa einem Dollar statt bei tausend.

Warum ein Dollar und nicht tausend

Betrachten wir den naiven Ansatz. Ein Dokument mit 8.000 Tokenen wird in zehn Teile aufgeteilt. Ohne jegliche Optimierung liest jeder Aufruf das gesamte Dokument erneut, wodurch derselbe Text zehnmal verarbeitet wird, um zehn verschiedene Absätze zu beschreiben.

Genau dieses Kostenprofil hat die Idee jahrelang blockiert. Die Leute betrachteten sie als reinen Brute-Force-Ansatz und lehnten sie bei der Budgetplanung ab, lange bevor der Qualitätsvorteil überhaupt gemessen werden konnte.

Prompt-Caching ändert die Rechnung an einer Stelle. Das Dokument wird einmal als fester Präfix gesendet. Der erste Aufruf kostet etwa 1,25 Mal den Basispreis für einen Cache-Write, während jeder folgende Aufruf für dasselbe Dokument nur etwa ein Zehntel des Basispreises für einen Cache-Read kostet.

Unter Annahme typischer Größen von Textblöcken und Dokumenten beträgt die Kontextualisierungskosten einmalig 1,02 US-Dollar pro Million Token des Quelltextes. Diese Zahl wird zusammen mit den zugrunde liegenden Werten angegeben – 800-Token-Blöcken und 8.000-Token-Dokumenten – deren Kostenangaben selten veröffentlicht werden. Dadurch ist es möglich, die Berechnungen mit lokalen Zahlen neu durchzuführen, anstatt blind darauf zu vertrauen.

In einem Beispiel aus einem Kochbuch, das 737 Blöcke umfasst, stammten fast 62 Prozent der Eingabetoken aus dem Cache. Die Gesamtkosten sanken dabei von etwa 9,20 US-Dollar auf etwa 2,85 US-Dollar. Ein besseres Modell war nicht für die Ersparnis von zwei Dritteln verantwortlich – vielmehr lag es daran, dass das Dokument nur einmal gelesen wurde.

Die Reihenfolge – der entscheidende Faktor

Ein praktisches Detail bestimmt, ob etwas davon Wirklichkeit wird. Caching funktioniert anhand von Präfixübereinstimmungen, sodass alle Teile eines Dokuments nacheinander verarbeitet werden müssen, um einen einzigen Cache-Eintrag wiederverwenden zu können. Parallelisierung zwischen Dokumenten ist in Ordnung – ein Worker pro Dokument – doch das Mischen von Teilen mehrerer Dokumente in einer einzigen Warteschlange ist nicht zulässig. Ein typischer, naiver Pipeline verteilt die Teile über einen gemeinsamen Thread-Pool, wodurch der Cache nur gelegentlich angegriffen wird und somit der volle Preis anfällt.

Auch die Angabe in der Abbildung erfordert eine Warnung: 1,02 Dollar spiegeln die Preise des Modells aus dem Jahr 2024 wider und sind keine konstanten Werte. Die nächste Generation dieses Modells kostet viermal so viel für die Eingabe, weshalb die Wiederholung dieser Zahl ohne Neuberechnung der Angebote einen veralteten Preis darstellt.

Die wirtschaftlichen Aspekte sehen für SEC-Unterlagen, dem genannten Dokumenttyp als Leitbeispiel, hervorragend aus. Dennoch hat jemand genau diesen Dokumenttyp getestet und das Gegenteil festgestellt.

Ein Leuchtturmbeispiel, das seinen eigenen Test nicht bestehen kann

Hier beginnt der Teil, den die meisten Zusammenfassungen überspringen.

Die Abbildung nutzte einen Auszug aus einer SEC-Meldung, doch die Liste der untersuchten Domänen lässt die Meldungen außer Acht. Sie nennt Codebasen, Fiktion, arXiv und wissenschaftliche Veröffentlichungen – wodurch finanzielle Dokumente lediglich als narratives Beispiel dienen und kein getestetes Korpus bilden.

Andere haben diese Lücke geschlossen und ein anderes Ergebnis erzielt. Die Ingenieure von Snowflake (Tarakad, Yu, Samdani, Merrick, März 2025) verwendeten etwa 23.000 echte 10-K- und 10-Q-Meldungen als Korpus und bewerteten ihr Verarbeitungssystem anhand von rund 500 manuell verfassten Abfragen.

Durch die Ergänzung jedes Auszugs mit einer umfangreichen, einzigartigen, vom Modell verfassten Zusammenfassung – was das Team selbst als kontextbasierte Abrufmethode bezeichnete – sanken die Bewertungswerte bei einem Modell um 5,8 Punkte und beim anderen um 0,4 Punkte. Das Ergebnis war ein Verlust bei deutlich höheren Rechenausgaben.

Wenn billige Metadaten einem teuren Modell überlegen sind

Die interessantere Erkenntnis ist, was im selben Experiment funktioniert hat. Durch das Hinzufügen von Metadaten auf Dokumentenebene – nämlich des Firmennamens, des Einreichungsdatums und des Formtyps – stieg die Genauigkeit der Antworten von etwa 50 auf 60 Prozent auf einen Bereich von 72 bis 75 Prozent, ohne dass überhaupt ein Sprachmodell verwendet wurde.

Der Kontrast verdeutlicht die Lektion. Das Problem war tatsächlich vorhanden, da der jeweilige Dokumententeil tatsächlich seinen Firmennamen nicht kannte. Dennoch übertraf die günstigste Lösung die teuerste, weil der Firmenname während der gesamten Einreichung konstant bleibt und seine Anhängung kein Modell erfordert.

Der Vergleich ist keine saubere Wiederholung, und das sollte offen gesagt werden. Snowflake verwendete seinen eigenen Prompt, sein eigenes Embedding-Modell, eine andere Chunk-Größe sowie eine andere Bewertungsmethode, weshalb die Ergebnisse nicht direkt miteinander verglichen werden können, als kämen sie von derselben Methode. Dennoch beziehen sie sich auf denselben Dokumententyp, weshalb sie relevant sind.

Zwei weitere Ergebnisse dämpfen die Begeisterung. Eine im Jahr 2026 durchgeführte Benchmark basierend auf T²-RAGBench, unabhängig von der Snowflake-Studie, prüfte die Kontextualisierung bei Finanzdokumenten mit Tabellen. Dabei wurden bei dichter Informationsauswertung Gewinne von 2,8 Prozentpunkten bei recall@5 sowie 2,2 Prozentpunkte bei hybrider Informationsauswertung festgestellt (arXiv). Der Gewinn ist echt und reproduzierbar, liegt aber bei weitem nicht bei 67 %.

Diese gleiche Benchmark, die 23.000 Abfragen in 7.318 Dokumenten umfasst, weist außerdem eine Erkenntnis auf, die alle, die mit Berichten arbeiten, beunruhigen sollte: Die meisten verbleibenden Fehler sind Unstimmigkeiten in der Tabellengestalt. Ein Textpräfix kann dabei nicht helfen, da es lediglich einen unlesbaren Abschnitt korrekt kennzeichnet.

Der zweite Punkt betrifft die Rechenleistung. ConTEB (2025) verglich die anthroptische Methode mit einem dafür trainierten Embedding-Modell. Das trainierte Modell erzielte im Durchschnitt leicht höhere Ergebnisse und verarbeitete jedes Dokument etwa hundertmal schneller (arXiv). Die Qualitätsunterschiede sind gering, da der Präfixansatz in einigen Datensätzen, wie beispielsweise einem Versicherungskorpus, deutlich vorteilhaft ist, in anderen hingegen nur knapp. Was das trainierte Modell tatsächlich bietet, ist eine geringere Rechenkostenlast.

Es existiert auch ein konkurrenzfähiges Design. Late Chunking (Jina AI, September 2024) befasst sich mit demselben Problem auf einer niedrigeren Ebene, indem das gesamte Dokument eingebettet wird und erst nach dem Transformer in Teile zerlegt wird, ohne dass ein Sprachmodell aufgerufen wird. Seine strukturelle Schwäche besteht darin, dass nichts zum Schlüsselwortindex hinzugefügt wird, wodurch die Hälfte der Vorteile, die Contextual BM25 bietet, verloren geht.

Für die meisten Unternehmenskorpora entscheidet diese Asymmetrie, mehr als der Metrikunterschied, wahrscheinlich über die Wahl. Das ist eine Ermessensfrage, und der zitierte ConTEB-Benchmark prüft sie nicht direkt, da BM25 nicht zu den von ihm bewerteten Komponenten gehört.

Sobald sich herausstellt, dass das Beispiel ein Gegenbeispiel aufweist, wird die wichtige Frage, wo die Methode versagt und wie ein bestimmtes Korpus innerhalb von fünf Minuten überprüft werden kann.

Fünf Minuten Testing vor jeder Ausgabe

Beginnen Sie mit einem Test und nicht mit einer Implementierung. Nehmen Sie zehn zufällige Abschnitte aus dem Index und lesen Sie jeden einzeln. Wenn man sagen kann, worum es in jedem Abschnitt geht und woher er stammt, enthalten die Abschnitte bereits Kontext – ein Präfix würde lediglich weitere Token hinzufügen, aber keine Informationen.

Der Test erfordert keinen Code und dauert fünf Minuten. Er ist außerdem der einzige Beweis, der sich auf die tatsächlichen Daten bezieht und nicht auf die von jemand anderem.

Vier dokumentierte Fälle, in denen die Technik nicht hilft:

• Ein Korpus mit weniger als zweihunderttausend Tokens. Anthropics eigener Rat bei dieser Größenordnung ist, die gesamte Wissensbasis in die Anfrage aufzunehmen und die Abrufung ganz zu überspringen. Die Kontextualisierung dient dazu, wenn das Korpus nicht mehr in das Kontextfenster passt.
• Blöcke, die bereits für sich stehen. FAQ-Paare, Produktkarten und Wörterbucheinträge geben bereits ihr eigenes Thema an, wodurch ein Präfix lediglich dessen Wiederholung darstellt.
• Ein Korpus, das sich häufig ändert. Die Kosten entstehen nur einmal, wenn die Dokumente stabil sind. Dokumente, die wöchentlich überarbeitet werden, müssen jede Woche erneut bezahlt werden.
• Tabellen und Finanzberichte. Wenn die Tabelleneinteilung das Problem darstellt und kein Firmenname fehlt, wird der Block zwar genau beschrieben, bleibt aber unlesbar.

Die Darstellung passt in drei Zeilen. Ein kleines, stabiles Korpus eignet sich für lange Kontexte mit Caching. Ein großes Korpus mit mehrdeutigen Abschnitten eignet sich für kontextbasiertes Abrufen. Kurze, eigenständige Einträge eignen sich für eine einfache hybride Suche ohne zusätzliche Kosten.

Die Reihenfolge der Einführung ist wichtig und führt am häufigsten zu Enttäuschungen. Die Kontextualisierung erhöht den Wert der hybriden Suche, ersetzt sie aber nicht. Ein Team ohne BM25 und Reranking sollte diese zuerst hinzufügen – wenn man diese Reihenfolge überspringt, kauft man das dritte Niveau, obwohl das erste noch fehlt.

Berechnen Sie die Kosten vor der Implementierung und nicht danach. Die Formel ist veröffentlicht, die Größen der Abschnitte und Dokumente sind bekannt, und das einzige wirkliche Unbekannte ist, ob der Prozess tatsächlich auf den Cache zugreift.

Was in die Design-Überprüfung einfließen sollte

Zur ersten Aussage zurück: „Der Umsatz stieg um 3%“ war nie falsch. Sie enthielt keinen Subjektbezug. Die Lösung bestand weder in einem intelligenteren Modell noch in einer besseren Einbettung, sondern lediglich darin, einmal zum Zeitpunkt der Indizierung ein Header hinzuzufügen.

• Egal wie stark das Antwortgenerierungsmodell auch ist, ein ohne Kontext stehender Textabschnitt ist nutzlos. Die Ursache liegt in der Indizierung, nicht in Halluzinationen.
• Drei Eingriffe zusammen ergeben die 67%-Marke, nicht nur einer. Allein der Präfix ist bereits nahe bei fünfunddreißig Prozent, und die hybride Suche mit Neubewertung liefert den Rest.
• Prompt-Caching machte die Technik kostengünstig – nicht ein stärkeres Modell – und die Ersparnis verschwindet ohne die Verarbeitung von Dokument zu Dokument.
• Der in der Darstellung verwendete Dokumenttyp weist ein dokumentiertes Gegenbeispiel auf: In SEC-Unterlagen übertrafen günstige Dokumentmetadaten einen teuren Modellaufruf pro Textabschnitt.
• Eine fünfminütige Überprüfung eines echten Indexes ist wichtiger als jede Schlagzeile. Lesen Sie die zehn Abschnitte einzeln.

In der Praxis reduziert sich das auf drei Schritte in dieser Reihenfolge: Führen Sie den Zehn-Abschnitte-Test durch, überprüfen Sie, ob das Korpus zu einem der vier negativen Fälle gehört, und erst danach berechnen Sie die Indexierungskosten mit der veröffentlichten Formel. Nur der dritte Schritt erfordert einen Budgetplan, während die ersten beiden entscheiden, ob es sich lohnt, einen anzufordern.

Eine Einschränkung lässt sich nicht umgehen. Anthropic veröffentlichte die Aufschlüsselung der Ergebnisse in einem Anhang als statisches PDF und nicht als Rohdatensatz, und unabhängige Teams, die versuchten, die Zahlen nachzuvollziehen, weisen dies als Reproduzierbarkeitsproblem aus. Echte Bewertungen an Korpora in Sprachen außerhalb des Englischen sind ebenfalls selten. Solange diese Lücken bestehen, stammen alle hier aufgeführten Werte aus einer bestimmten Konfiguration und nicht aus einem physikalischen Gesetz, und am meisten fehlen derzeit Messungen in nicht-englischen Korpora.