Totgesagte leben länger
2024 und 2025 war es Mode, das Ende von Retrieval-Augmented Generation auszurufen. Die Argumentation: Wenn ein Modell eine Million Tokens auf einmal verarbeiten kann, kippt man eben den ganzen Korpus in den Kontext und spart sich die ganze Vektor-Datenbank-Akrobatik.
In der Praxis ist nichts davon eingetreten. Lange Kontexte sind teuer, langsam und – das wird oft übersehen – qualitativ nicht so robust, wie die Marketingfolien suggerieren. Modelle finden im 800.000-Token-Heuhaufen die Nadel zwar erstaunlich oft, aber sie reasonen schlechter über das, was sie finden, je mehr Müll daneben liegt.
Trotzdem ist RAG, wie wir es 2023 gebaut haben, fast überall obsolet. Naives Top-k-Vektor-Search liefert schlechtere Ergebnisse als die neuen Patterns – und ist nicht einmal billiger. Was sich verändert hat, ist nicht die Existenzberechtigung von RAG, sondern das Rezept.
Was naives RAG einmal war
Zur Erinnerung, weil immer noch viele Systeme so aussehen: Dokumente werden in 500-Token-Chunks zerschnitten, jeder Chunk wird durch ein Embedding-Modell geschickt, die Vektoren landen in einer Datenbank. Bei einer Anfrage wird die Frage selbst eingebettet, die fünf nächsten Nachbarn werden geholt, in den Prompt gestopft, fertig.
Dieses Rezept funktioniert für simple FAQ-Bots. Für alles andere bricht es an den Kanten:
Verlorener Kontext zwischen Chunks: Der entscheidende Satz steht in Chunk 3, die Definition des Begriffs in Chunk 1. Top-k holt Chunk 3, das Modell halluziniert die Definition.
Falsche Nachbarn: Vektor-Ähnlichkeit ist nicht semantische Relevanz. Eine Frage zu „Kündigungsfristen" findet Absätze über Kündigung von Mitarbeitern, weil sie lexikalisch nah sind, obwohl es im Vertragsrecht um etwas völlig anderes geht.
Brüchigkeit gegenüber Formulierungen: Wer „Wie storniere ich?" fragt, bekommt andere Treffer als bei „Rückgaberecht" – obwohl die Antwort dieselbe sein müsste.
Keine Iteration: Ein einzelner Suchschritt sieht nur das, was die ursprüngliche Frage hergibt. Komplexe Recherchen brauchen mehrere Anläufe.
Die Patterns, die 2026 tragen
Agentic Retrieval
Statt einmal zu suchen und das Ergebnis zu verbraten, lassen wir das Modell selbst entscheiden, wann und wonach es sucht. Die Suche wird zum Tool, das der Agent so oft aufruft, wie er muss. Eine erste Suche liefert grobe Hinweise, das Modell formuliert daraus präzisere Folgeanfragen, drillt sich tiefer.
Das ist deutlich teurer pro Anfrage – und deutlich besser bei nicht-trivialen Fragen. Für Recherche-Aufgaben, juristische Prüfungen oder technischen Support ist es inzwischen der Standard.
Hierarchische Retrieval
Wir indexieren auf zwei Ebenen: Zusammenfassungen pro Dokument und die Volltexte. Die Suche läuft zuerst über die Zusammenfassungen – das ist schnell und liefert die richtigen Dokumente. Erst danach wird in den ausgewählten Dokumenten gezielt nachgeschaut.
Der Effekt: Das Modell verliert nie den Überblick darüber, woher ein Snippet stammt, und der Kontext eines Absatzes geht nicht verloren. Bei strukturierten Korpora – Verträgen, Handbüchern, wissenschaftlicher Literatur – ist das ein riesiger Qualitätssprung.
Hybride Suche mit Reranker
Vektor-Suche allein verliert gegen klassische BM25-Suche, sobald Eigennamen, Aktenzeichen oder seltene Begriffe ins Spiel kommen. Wer „Urteil 4 AZR 123/24" sucht, will keinen Embedding-Abgleich – er will einen exakten Treffer.
Die Lösung ist einfach und alt: BM25 und Vektor-Suche parallel laufen lassen, die Ergebnisse zusammenführen, dann einen Reranker drüberlaufen lassen. Reranker sind kleinere Modelle, die für ein Frage-Dokument-Paar einen Relevanzwert bestimmen. Sie kosten Latenz, sortieren aber die wirklich relevanten Treffer nach oben. In jedem Projekt, in dem wir Reranker eingebaut haben, ist die Antwortqualität spürbar gestiegen.
Ganze Dokumente statt Chunks
Wenn das Kontextfenster es zulässt, holen wir keine Chunks mehr, sondern ganze Dokumente. Ein 30-Seiten-Vertrag passt komfortabel in 200.000 Tokens. Das Modell sieht den Vertrag, wie ihn auch ein Anwalt sehen würde – mit Präambel, Definitionen und Kleingedrucktem.
Das eliminiert die größte Schwäche klassischen RAGs: den verlorenen Kontext. Voraussetzung ist, dass die Retrieval-Schicht das richtige Dokument findet. Genau dafür sind hierarchische und hybride Suche da.
Context Caching für stabile Korpora
Anbieter wie Anthropic und Google rechnen gecachten Input deutlich günstiger ab als frischen. Bei Korpora, die sich kaum verändern – Produkthandbücher, juristische Standardwerke, Code-Bases – kann man große Teile dauerhaft im Cache halten und zahlt nur einen Bruchteil pro Anfrage.
In zwei laufenden Projekten haben wir damit die Inferenzkosten um zwischen 60 und 80 Prozent gesenkt, ohne die Architektur grundsätzlich zu ändern. Context Caching ist eine der unterschätzten Hebel des Jahres.
Die Entscheidungsmatrix
Wann nimmt man was? Die Faustregel, die wir intern verwenden:
Long Context, wenn: Der relevante Korpus klein und stabil ist, jede Anfrage potenziell auf alles zugreifen muss und Latenz toleriert wird. Beispiel: ein 50-seitiges Whitepaper, über das ein Bot Auskunft gibt.
RAG, wenn: Der Korpus zu groß ist, häufig geändert wird oder pro Anfrage nur ein kleiner, dynamisch wählbarer Teil relevant ist. Beispiel: ein interner Wissens-Hub mit zehntausenden Dokumenten.
Fine-Tuning, wenn: Es nicht um Faktenwissen geht, sondern um Stil, Format oder Verhalten. Fine-Tuning ist erstaunlich schlecht darin, neue Fakten beizubringen, und erstaunlich gut darin, ein Modell konsistent in einem bestimmten Ton schreiben zu lassen.
In den meisten echten Systemen kombiniert man zwei oder drei davon. Reine RAG-Systeme oder reine Long-Context-Systeme sind die Ausnahme.
Häufige Fehler
Vektor-Datenbank-Verklärung: Die Wahl der Vektor-DB ist fast nie der Engpass. Pinecone vs. Weaviate vs. Postgres mit pgvector – das macht in der Antwortqualität praktisch keinen Unterschied. Was zählt, ist die Retrieval-Logik darüber.
Jagd nach besseren Embeddings: Ein neues Embedding-Modell bringt vielleicht zwei bis fünf Prozent Verbesserung in Benchmarks. Hierarchische Retrieval, ein Reranker oder ein zweiter Suchschritt bringen oft das Zehnfache.
Eval als Nachgedanke: Ohne Evaluierungs-Set gegen reale Fragen wird jede Optimierung zum Bauchgefühl. Hundert handgepflegte Frage-Antwort-Paare aus dem echten Anwendungsfall sind mehr wert als jedes synthetische Benchmark.
Chunking-Überoptimierung: Stunden in die perfekte Chunk-Größe zu investieren, bringt weniger als einen halben Tag in eine bessere Index-Struktur. Chunks sind ein Implementierungsdetail, kein Architekturfundament.
Wir bei nh labs
Wir bauen RAG-Systeme inzwischen praktisch nie als reines Top-k-Vektor-Setup. Der Standard-Stack ist hierarchische Retrieval mit hybrider Suche, Reranker, agentic Loop für komplexere Anfragen und Context Caching für die Teile des Korpus, die sich nicht oft ändern. Das klingt komplexer als es ist – die meisten Komponenten sind heute einsatzbereite Bibliotheken oder Managed Services.
Wichtiger als der Stack ist die Disziplin bei der Evaluierung. Ohne ein Set echter Fragen, gegen das jede Änderung gemessen wird, baut man im Nebel. Mit Eval ist die Iteration schnell und die Verbesserungen sind messbar.
Fazit
RAG ist nicht tot, aber das Rezept von 2023 ist es. Lange Kontextfenster haben den Werkzeugkasten erweitert, nicht ersetzt. Wer heute neu baut, sollte mit hierarchischer Retrieval, hybrider Suche und einem Reranker starten – und Long Context als gezielte Ergänzung verstehen, nicht als Ablösung. Die Systeme, die 2026 in Produktion gut funktionieren, sind nicht die mit dem größten Kontextfenster oder dem teuersten Embedding-Modell. Es sind die mit der durchdachtesten Retrieval-Logik und einer ehrlichen Evaluierung. Beides hat man auch schon vor zwei Jahren gebraucht – nur fällt es jetzt stärker ins Gewicht.