Deine Dokumente lesen

Die Grenze, die der Kontext nicht lösen kann

Stell dir vor, du willst einen Assistenten bauen, der Fragen zur gesamten internen Dokumentation deines Unternehmens beantworten kann — 50.000 Seiten, wöchentlich aktualisiert.

Selbst mit einem Fenster von 1 Million Tokens kannst du nicht alles hineinstecken. Und wenn du es könntest, wären die Kosten prohibitiv und die Qualität der Antworten würde sich verschlechtern: Modelle haben Schwierigkeiten, präzise Informationen aus sehr langen Kontexten zu extrahieren.

Es braucht einen anderen Ansatz. Das ist RAG — Retrieval-Augmented Generation.

Die grundlegende Idee

Statt dem Modell das gesamte Dokument zu geben, gibst du ihm nur die für seine Frage relevanten Passagen. Dafür brauchst du zwei Dinge:

1. Einen Index: eine Vektordarstellung all deiner Dokumente, im Voraus gespeichert.
2. Eine semantische Suchmaschine: Wenn eine Frage ankommt, findet sie die semantisch nächsten Passagen.

Die gefundenen Passagen werden dann in den Kontext des LLM mit der Frage injiziert. Das Modell antwortet auf Basis dieser Auszüge.

Das ist genau das, was semantische Suche mit den Embeddings tut, die du bereits seit Kapitel 03 kennst — aber auf echte Dokumente angewendet.

Die Pipeline in drei Schritten

1. Die Indexierung (einmalig)

Das Dokument wird in Chunks aufgeteilt — Auszüge von einigen hundert Tokens (mit leichter Überlappung zwischen ihnen, um den Sinn an der Grenze nicht zu durchschneiden).

Jeder Chunk wird dann von einem Embedding-Modell in einen Vektor umgewandelt. Diese Vektoren werden in einer Vektordatenbank gespeichert (Pinecone, Chroma, pgvector…).

Dieser Schritt erfolgt einmalig oder bei jeder Dokumentenaktualisierung.

2. Die Suche (bei jeder Frage)

Wenn eine Frage ankommt, wird sie mit demselben Embedding-Modell in einen Vektor umgewandelt.

Man berechnet die Kosinus-Ähnlichkeit zwischen diesem Fragen-Vektor und allen Chunk-Vektoren in der Datenbank. Die k nächsten Chunks werden abgerufen — in der Regel 3 bis 5.

Das ist semantische Suche: „nah" bedeutet nicht „enthält dieselben Wörter", sondern „drückt einen ähnlichen Sinn aus".

3. Die Generierung

Die abgerufenen Chunks werden in einem Prompt zusammengestellt:

Auszüge aus dem Dokument:
[Auszug 1 — ...]
[Auszug 2 — ...]
[Auszug 3 — ...]

Frage: {Frage des Nutzers}

Dieser Prompt wird an den LLM gesendet, der eine Antwort generiert und sich dabei auf die Auszüge stützt. Das Modell hat das Dokument nicht auswendig gelernt — es liest es in dem Moment, wo die Frage gestellt wird.

Visualisierung der Pipeline

Hier ist das System in Aktion auf einem Mini-Korpus über Planetologie. Wähle eine Frage — beobachte, welche Chunks im Vektorraum abgerufen werden und wie sie als Kontext zusammengestellt werden.

Wähle eine Frage: sie wird embedded, mit den Chunks des Korpus verglichen, und die relevantesten werden vor der Generierung in den Prompt injiziert. Genau dieser Umweg lässt einen LLM Fragen zu Dokumenten beantworten, die er nie im Training gesehen hat.

Die Chunk-Größe: eine echte Engineering-Entscheidung

Das Aufteilen in Chunks ist nicht trivial. Es ist oft die erste Quelle von Problemen in einem RAG-System.

Zu kleine Chunks: Jeder Chunk ist zu wenig informativ. Man ruft Fragmente ab, die, aus dem Kontext gerissen, dem Modell keine korrekte Antwort ermöglichen.

Zu große Chunks: Man überschreitet die Präzision des Embeddings. Ein Vektor, der 2.000 Tokens repräsentiert, ist ein verschwommener Durchschnitt — er wird für manche Fragen abgerufen, aber der relevante Inhalt ist im Text ertränkt.

Eine Faustregel: Chunks von 200 bis 500 Tokens mit einem Overlap von 10–15 %. Der richtige Parameter hängt von der Struktur deiner Dokumente ab.

Welches Embedding-Modell solltest du verwenden?

Nicht jede Frage führt mit demselben Embedding zu den richtigen Chunks. Ein Modell, das auf allgemeines Englisch trainiert wurde, findet Python-Code schlecht; ein auf Code trainiertes Modell findet medizinische Konversationen schlecht.

Die Optionen, die in der Praxis immer wieder auftauchen:

• text-embedding-3-small / -large (OpenAI) — solide Qualität, generalistisch, mehrsprachig. Die Standardwahl beim Einstieg.
• bge-large / bge-m3 (BAAI) — Open Source, hervorragend mehrsprachig, Top-Plätze auf der MTEB-Bestenliste 2024.
• all-MiniLM-L6-v2 (Sentence-Transformers) — klein, schnell, lokal einsetzbar. Gutes Preis-Leistungs-Verhältnis für einfache Anwendungsfälle.
• Domänenspezialisierte Modelle (Code, Biomedizin, Recht) — immer besser in ihrer Nische, schwächer überall sonst.

Eine Faustregel: Teste zwei oder drei Modelle auf deinen Daten und deinen Fragen. Das MTEB-Ranking sagt nur wenig über deinen konkreten Anwendungsfall aus.

Der Reranker: der zweite Durchlauf

Die Vektorsuche hat einen Schwachpunkt: Sie ist schnell, aber grob. Ein Embedding mit einigen hundert Dimensionen ist ein verschwommener Durchschnitt eines Textes. Viele „ungefähr relevante" Chunks schwimmen oben, und die wirklich guten gehen manchmal unter.

Daher ist eine Stufe in ernsthaften RAG-Systemen Standard geworden: der Reranker.

Die Idee in zwei Phasen:

1. Erster Durchlauf (Vektorsuche) — die 50 oder 100 nächsten Chunks abrufen. Schnell.
2. Zweiter Durchlauf (Reranking) — ein kleines Modell (oft ein Cross-Encoder) bewertet jedes Paar (Frage, Chunk) gemeinsam, gibt einen präzisen Score und behält die Top 5–10. Pro Chunk langsam, aber wir machen das nur auf den 50 Kandidaten des ersten Durchlaufs.

Der Reranker sieht die Frage und den Chunk gleichzeitig, was das Embedding nicht tut. Er erfasst semantische Feinheiten, die die Vektorsuche verpasst. Cohere, Jina AI und BAAI bieten gebrauchsfertige Reranker an.

Ohne Reranker stagniert dein RAG. Mit einem springt die Qualität eine Stufe höher, ohne den Rest der Pipeline zu ändern.

Warum nicht Volltextsuche?

Eine berechtigte Frage: Warum nicht einfach eine Schlüsselwortsuche wie eine klassische Suchmaschine durchführen?

Vektorsuche ist ergänzend, kein Ersatz. Sie findet semantisch nahe Passagen, auch wenn die Formulierung anders ist. „Welcher Planet dreht sich am langsamsten?" kann einen Chunk finden, der über „Umlaufperiode" spricht, ohne dass diese Wörter in der Frage vorkommen.

In der Praxis kombinieren die besten Systeme beide: Hybrid Search — ein Score, der Vektorähnlichkeit und Schlüsselwortübereinstimmung (BM25) kombiniert.

Die Grenzen von RAG

RAG ist nicht magisch. Hier sind die häufigsten Probleme:

Der falsch zerschnittene Chunk. Wenn sich eine Antwort über zwei Chunks erstreckt und die Zerschneidungsgrenze an der falschen Stelle liegt, reicht keiner der beiden Chunks allein aus.

Das „Lost in the Middle" innerhalb des Chunks. Wenn der Chunk zu lang ist, können wichtige Informationen in der Mitte landen und vom Modell ignoriert werden.

Die mehrdeutige Frage. Wenn die Frage vage ist, ist der Fragen-Embedding-Vektor weit von den meisten relevanten Chunks entfernt. Lösung: Die Frage umformulieren oder mehrere Varianten generieren.

Halluzinationen auf den Auszügen. Der LLM kann über das hinaus extrapolieren, was die Chunks sagen. RAG reduziert Halluzinationen, eliminiert sie aber nicht.

Was RAG in der Praxis ändert

RAG ist heute die Referenztechnik, um einen LLM mit privaten oder aktuellen Daten zu verbinden. Fast alle Unternehmens-Chatbots, Dokumentationsassistenten und Monitoring-Tools stützen sich darauf.

Aber es ist noch eine „passive" Architektur: Das Modell empfängt eine Frage, sucht Chunks, antwortet. Für komplexere Aufgaben — suchen, dann basierend auf dem Ergebnis handeln, dann wieder suchen — muss man einen Schritt weiter gehen.

Aktualisiert am 10. Mai 2026