Contextual Retrieval: RAG-Chunks mit Kontext und lokalem LLM

Die Trefferqualität eines RAG-Systems messbar verbessern? WZ-IT baut RAG-Systeme auf eigener Infrastruktur, mit lokalem Modell, hybrider Suche und nachvollziehbaren Quellen. Der RAG Proof of Value misst einen abgegrenzten Wissensbestand mit vereinbarten Referenzfragen, vor und nach zwei Optimierungszyklen. RAG Proof of Value ansehen · Interne KI-Assistenten

Ein RAG-System zerlegt Dokumente in Abschnitte, sogenannte Chunks, und sucht bei jeder Frage die passenden heraus. Dabei geht Kontext verloren: Ein Chunk mit dem Satz „Der Umsatz stieg um 3 % gegenüber dem Vorquartal" sagt nicht, welche Firma und welches Quartal gemeint sind. Contextual Retrieval setzt vor jeden Chunk einen kurzen, maschinell erzeugten Kontext und macht ihn damit auffindbar. Anthropic hat das Verfahren beschrieben und mit Claude umgesetzt. Dieser Artikel erklärt es auf Deutsch und zeigt, wie es mit einem lokalen Modell über vLLM oder Ollama funktioniert. Stand September 2026.

Inhaltsverzeichnis

• Das Problem: Chunks ohne Kontext
• Wie Contextual Retrieval funktioniert
• Was die Messungen von Anthropic zeigen
• Der Preis: ein Modellaufruf pro Chunk
• Prefix Caching in vLLM als lokales Gegenstück
• Ollama und llama.cpp
• Umsetzung mit lokalem LLM
• Kombination mit BM25 und Reranking
• Grenzen und Betriebsfragen

Das Problem: Chunks ohne Kontext

Ein klassisches RAG-System verarbeitet den Bestand in drei Schritten (Was ist RAG?): Dokumente in Chunks zerlegen, jeden Chunk mit einem Embedding-Modell in einen Vektor übersetzen, die Vektoren in einer Datenbank wie Qdrant oder pgvector ablegen. Viele Systeme ergänzen einen lexikalischen Index mit BM25, weil Vektoren exakte Kennungen wie Fehlercodes, Aktenzeichen oder Artikelnummern schlecht treffen.

Beide Indizes sehen aber nur den Chunk. Was im Dokument davor steht, also Titel, Kapitel, Vertragspartner, Geltungsbereich oder Stichtag, fehlt im Chunk. Typische Fälle in deutschen Unternehmensdokumenten:

Wie Dokumente sinnvoll geschnitten werden, damit solche Brüche seltener auftreten, beschreibt Chunking für RAG. Contextual Retrieval setzt danach an: Der Schnitt bleibt, jeder Chunk bekommt seinen Kontext zurück.

Wie Contextual Retrieval funktioniert

Anthropic hat das Verfahren im September 2024 veröffentlicht (Anthropic, Introducing Contextual Retrieval). Es besteht aus zwei Teilen: Contextual Embeddings und Contextual BM25. In beiden Fällen wird vor jeden Chunk ein chunk-spezifischer, erklärender Kontext gesetzt, bevor er eingebettet und in den BM25-Index geschrieben wird.

Den Kontext erzeugt ein Sprachmodell. Es erhält das Gesamtdokument und den einzelnen Chunk und soll einen kurzen Kontext formulieren, der den Chunk im Dokument einordnet. Anthropic hat dafür diesen Prompt mit Claude 3 Haiku verwendet:

<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.

Der erzeugte Kontext umfasst laut Anthropic meist 50 bis 100 Tokens. Aus dem Beispiel der Quelle wird so aus „The company's revenue grew by 3% over the previous quarter." ein Chunk, dem vorangestellt ist, dass er aus einer SEC-Meldung zur ACME Corp für Q2 2023 stammt und der Umsatz im Vorquartal 314 Millionen US-Dollar betrug.

Abgegrenzt davon sind verwandte Ansätze: generische Dokumentzusammenfassungen an jedem Chunk (laut Anthropic nur sehr begrenzte Verbesserungen), Hypothetical Document Embeddings und zusammenfassungsbasierte Indizes (in Anthropics Tests schwache Ergebnisse). Der Unterschied liegt darin, dass der Kontext für jeden Chunk einzeln erzeugt wird.

Was die Messungen von Anthropic zeigen

Anthropic hat über mehrere Wissensdomänen gemessen (Codebasen, Belletristik, ArXiv-Paper, wissenschaftliche Veröffentlichungen). Metrik ist 1 minus Recall@20, also der Anteil relevanter Dokumente, die nicht unter den Top-20-Chunks landen. Die Durchschnittswerte beziehen sich auf die beste Embedding-Konfiguration im Test, Gemini Text 004.

Beim Reranking hat Anthropic die Top 150 aus der ersten Suche an einen Reranker (Cohere) gegeben und die Top 20 an das Modell weitergereicht. Weitere Befunde aus derselben Quelle: Embeddings mit BM25 schlagen Embeddings allein, 20 Chunks im Prompt funktionierten besser als 10 oder 5, und die Effekte addieren sich.

Zwei Einschränkungen gehören zur Einordnung. Die Messung stammt vom Anbieter des verwendeten Modells, und die Datensätze sind englisch. Übertragbar ist die Richtung, nicht die Zahl. Ob und wie stark der eigene Bestand profitiert, zeigt nur eine Messung mit eigenen Referenzfragen, siehe RAG-Qualität messen.

Der Preis: ein Modellaufruf pro Chunk

Contextual Retrieval verschiebt Rechenaufwand in die Indexierung. Für jeden Chunk läuft ein Modellaufruf, und jeder Aufruf enthält das ganze Dokument. Bei der Suchanfrage selbst entsteht kein zusätzlicher Modellaufruf.

Anthropic rechnet mit 800-Token-Chunks, 8.000-Token-Dokumenten, 50 Tokens Anweisung und 100 Tokens Kontext pro Chunk und kommt mit Prompt Caching auf einmalig 1,02 US-Dollar pro Million Dokument-Tokens. Das bezieht sich auf die Preise von Claude 3 Haiku zum Zeitpunkt der Veröffentlichung.

Bei einem lokalen Modell fallen keine Token-Preise an, der Aufwand zeigt sich in GPU-Zeit. Mit denselben Annahmen ergibt sich pro Dokument (eigene Rechnung):

Ohne Cache liest das Modell jedes Dokument so oft, wie es Chunks hat. Mit Cache wird das Dokument einmal verarbeitet, danach nur noch der jeweilige Chunk und die Anweisung. Die Erzeugung der Kontexte selbst (Decoding) bleibt gleich.

Prefix Caching in vLLM als lokales Gegenstück

vLLM bringt mit Automatic Prefix Caching (APC) das Gegenstück zum Prompt Caching der Cloud-APIs mit. APC speichert den KV-Cache bereits verarbeiteter Anfragen. Beginnt eine neue Anfrage mit demselben Präfix, überspringt vLLM die Berechnung des gemeinsamen Teils (vLLM, Automatic Prefix Caching). Die Dokumentation nennt als typischen Anwendungsfall genau das Muster von Contextual Retrieval: viele Anfragen zum selben langen Dokument.

Daraus folgen drei Regeln für die Pipeline:

1. Das Dokument steht am Anfang des Prompts. Anthropics Prompt ist bereits so aufgebaut: erst das Dokument, dann der Chunk, dann die Anweisung. Alles, was sich von Chunk zu Chunk ändert, gehört hinter das Dokument.
2. Der Präfix muss Token für Token gleich sein. Systemprompt, Chat-Template und Dokumenttext bleiben für alle Chunks eines Dokuments identisch. Eine Chunk-Nummer oder ein Zeitstempel vor dem Dokument verhindert jeden Cache-Treffer.
3. Aufträge nach Dokument gruppieren. Werden die Chunks eines Dokuments zusammen abgearbeitet, liegt dessen Präfix noch im Cache. Eine über den ganzen Bestand gemischte Warteschlange riskiert, dass der Präfix vor dem nächsten Chunk verdrängt wurde.

Ob der Cache greift, zeigen die Prometheus-Metriken vllm:prefix_cache_queries und vllm:prefix_cache_hits (vLLM, Metrics). Wie vLLM grundsätzlich arbeitet, erklärt Was ist vLLM?.

Ollama und llama.cpp

Mit Ollama lässt sich Contextual Retrieval ebenfalls umsetzen, zwei Punkte sind aber zu beachten.

Das Kontextfenster. Ollama verwendet standardmäßig ein Kontextfenster von 4.096 Tokens (Ollama FAQ). Ein Dokument mit 8.000 Tokens passt nicht hinein. Das Fenster wird über die Umgebungsvariable OLLAMA_CONTEXT_LENGTH oder den API-Parameter num_ctx erhöht. Der Speicherbedarf steigt mit OLLAMA_NUM_PARALLEL mal Kontextlänge; der Standard für parallele Anfragen je Modell ist 1.

Das Caching. Ollama dokumentiert kein konfigurierbares Prefix Caching wie vLLM. Der llama.cpp-Server, auf dessen Technik Ollama ursprünglich aufbaut, hat die Option cache_prompt (standardmäßig aktiv): Der Prompt wird mit der vorherigen Anfrage verglichen, und nur der abweichende Rest wird neu verarbeitet (llama.cpp Server README). Das hilft bei aufeinanderfolgenden Chunks desselben Dokuments, ist aber an einen Slot gebunden und nicht mit dem blockbasierten Cache von vLLM vergleichbar.

Für die einmalige Indexierung eines großen Bestands ist vLLM deshalb meist die bessere Wahl, für kleine Bestände und Tests reicht Ollama. Den Vergleich der Inferenz-Server insgesamt zeigt vLLM vs. Ollama.

Umsetzung mit lokalem LLM

Die Pipeline braucht keinen eigenen Dienst. Sie ist ein zusätzlicher Schritt zwischen Chunking und Einbettung, der gegen eine OpenAI-kompatible Schnittstelle läuft.

Ein Modell mit OpenAI-kompatibler API in vLLM starten, hier als Beispiel ein kleines Instruct-Modell unter Apache-2.0-Lizenz:

vllm serve Qwen/Qwen3-4B-Instruct-2507 --max-model-len 32768

Der Aufruf pro Chunk, mit einem deutschen Prompt für deutsche Dokumente, damit der Kontext dieselben Fachbegriffe verwendet wie die späteren Fragen:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="local")

def kontext(dokument: str, chunk: str) -> str:
    prompt = (
        f"<document>\n{dokument}\n</document>\n"
        "Hier ist der Abschnitt, den wir im Gesamtdokument einordnen wollen:\n"
        f"<chunk>\n{chunk}\n</chunk>\n"
        "Formuliere einen kurzen Kontext, der diesen Abschnitt im Gesamtdokument "
        "einordnet, um ihn bei der Suche besser auffindbar zu machen. "
        "Antworte nur mit dem Kontext."
    )
    antwort = client.chat.completions.create(
        model="Qwen/Qwen3-4B-Instruct-2507",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=150,
        temperature=0,
    )
    return antwort.choices[0].message.content.strip()

Zur Modellwahl: Anthropic hat mit Claude 3 Haiku bewusst ein kleines Modell genutzt. Die Aufgabe verlangt Leseverständnis über lange Texte und kurze Ausgaben, keine tiefe Argumentation. Entscheidend sind ein Kontextfenster, das die längsten Dokumente aufnimmt, und gute Deutschkenntnisse. Modelle mit Denkmodus sollten für diese Aufgabe ohne ihn laufen, sonst wachsen Ausgabelänge und Laufzeit. Anthropic empfiehlt zudem, den Prompt an die Domäne anzupassen, etwa durch ein Glossar mit Begriffen, die nur in anderen Dokumenten definiert sind.

Welche Hardware für welches Modell reicht, beschreibt GPU & VRAM dimensionieren. Die Indexierung läuft typischerweise auf derselben Hardware wie der Chatbetrieb, zum Beispiel nachts.

Kombination mit BM25 und Reranking

Contextual Retrieval ersetzt die hybride Suche nicht, es verbessert beide Teile. Der Kontext enthält oft genau die Begriffe, die BM25 braucht: Firmenname, Vertragsbezeichnung, Paragraf, Produktnummer. Ein Chunk, der vorher nur „die Gesellschaft" sagte, ist danach auch über den Namen auffindbar.

Wie hybride Suche und Reranking im Detail aufgebaut werden, beschreibt Hybrid Search und Reranking. Welches Embedding-Modell für deutsche Texte passt, vergleicht der Beitrag Embedding-Modelle für Deutsch.

Bei der Antwortgenerierung empfiehlt Anthropic, dem Modell den kontextualisierten Chunk zu übergeben und dabei zu kennzeichnen, was Kontext und was Originaltext ist. Die Quellenangabe für den Nutzer bezieht sich immer auf den Originaltext, weil der erzeugte Kontext nicht im Dokument steht.

Grenzen und Betriebsfragen

Kleine Bestände brauchen kein RAG. Anthropic nennt rund 200.000 Tokens (etwa 500 Seiten) als Grenze, unter der der ganze Bestand direkt in den Prompt passt. Lokal hängt die Grenze vom Kontextfenster des Modells und vom Grafikspeicher ab.

Lange Dokumente sprengen das Kontextfenster. Ein Handbuch mit 300 Seiten passt nicht in jeden Prompt. Dann wird statt des Gesamtdokuments das umgebende Kapitel übergeben, ergänzt um Titel und Inhaltsverzeichnis. Das ist eine Abweichung vom Originalverfahren und sollte gemessen werden.

Änderungen wirken auf das ganze Dokument. Der Kontext eines Chunks hängt vom Gesamtdokument ab. Ändert sich ein Abschnitt, wird das Dokument komplett neu kontextualisiert. Die Indexierung muss daher dokumentweise versionieren, nicht chunkweise.

Der Kontext kann falsch sein. Das Modell kann einen Chunk falsch einordnen, etwa einer falschen Fassung zuordnen. Stichproben der erzeugten Kontexte gehören in die Abnahme, und die Anzeige für Nutzer zeigt den Originaltext.

Berechtigungen gelten auch für den Kontext. Der Kontext enthält Informationen aus dem Gesamtdokument. Er erbt deshalb die Zugriffsrechte des Dokuments, genau wie der Chunk (RAG mit Berechtigungen). Teilen sich mehrere Mandanten einen vLLM-Server, trennt cache_salt die Caches.

Indexgröße und Chunklänge steigen. Jeder Chunk wird um 50 bis 100 Tokens länger. Das betrifft Speicher im Index und die Zahl der Tokens, die bei jeder Antwort in den Prompt gehen.

Was das für Ihr Projekt heißt

Contextual Retrieval ist ein Indexierungsschritt, kein Produktwechsel. Er lässt sich in eine bestehende Pipeline einfügen, braucht keine Cloud-API und läuft mit einem lokalen Modell auf derselben Hardware wie der Assistent, auf einem AI Cube im eigenen Netzwerk oder auf einem Managed GPU-Server von WZ-IT. Der Aufwand liegt in der GPU-Zeit bei der Indexierung, und Prefix Caching in vLLM senkt ihn deutlich.

Ob sich der Schritt lohnt, entscheidet eine Messung: dieselben Referenzfragen vor und nach der Kontextualisierung, bewertet mit Recall@k und Antwortqualität. Genau diesen Vergleich von Ausgangswert und Optimierung sieht der RAG Proof of Value vor, mit Support, Beratung und Implementierung durch WZ-IT.

Die Grundlagen stehen in Was ist RAG?, der Schritt davor in Chunking für RAG, der Schritt danach in Hybrid Search und Reranking. Wie die Wirkung belastbar gemessen wird, zeigt RAG-Qualität messen, und welche Vektordatenbank die hybride Suche trägt, vergleicht Qdrant vs. pgvector.

Quellen

• Anthropic, Introducing Contextual Retrieval (19.09.2024)
• Anthropic Cookbook, Contextual Embeddings
• vLLM, Automatic Prefix Caching
• vLLM, Design: Automatic Prefix Caching
• vLLM, Engine-Argumente
• vLLM, Metrics
• vLLM, CacheConfig im Quellcode
• Ollama FAQ
• llama.cpp Server README
• Hugging Face, Qwen3-4B-Instruct-2507
• Hugging Face, BGE-M3
• Hugging Face, bge-reranker-v2-m3
• Hugging Face, Qwen3-Reranker-0.6B