RAG im Jahr 2026: hybrides Retrieval, agentisches Suchen oder Long Context?

RAG im Jahr 2026 ist nicht mehr eine Architektur. Retrieval-Augmented Generation bedeutet heute, sich zwischen drei Wegen zu entscheiden, einem Modell eigenes Wissen zu geben: alles in ein Kontextfenster packen, das eine Million Tokens fasst, die richtigen Chunks mit einer hybriden Suchpipeline abrufen oder einen Agenten mit Tools iterativ suchen lassen. Jeder Weg gewinnt in einer anderen Situation, und die falsche Wahl kostet bei jeder Anfrage entweder Genauigkeit oder Geld.

Das ist der Strategie-Teil: wann welcher Ansatz passt, was er pro Anfrage kostet, wo er versagt und wie man die Wahl bewertet. Zur Umsetzung selbst (Parsing, Chunking, BM25, Reciprocal Rank Fusion, Reranking, Quellenangaben) siehe eine RAG-Pipeline in Produktion, Schritt für Schritt.

Was sind die drei Wege, einem LLM eigenes Wissen zu geben?

Die drei Optionen sind Long Context (alles mitsenden), Retrieval (die besten Chunks aus einem Index senden) und agentisches Suchen (das Modell so lange Suchtools aufrufen lassen, bis es genug hat). Sie unterscheiden sich darin, wer entscheidet, was das Modell liest: niemand, eine Ranking-Funktion oder das Modell selbst.

• Long Context. Die gesamte Wissensbasis geht in den Prompt, meist hinter einem Prompt-Cache. Kein Index, kein Chunking, keine Retrieval-Fehler. Stand September 2026 haben die aktuellen Claude-Modelle (Opus 5.5, Sonnet 5, Fable 5.1) ein Kontextfenster von 1M Tokens.
• Hybrides Retrieval. Dokumente werden im Voraus gechunkt und indiziert; jede Frage läuft durch BM25 und Vektorsuche, die Ergebnisse werden fusioniert und rerankt, und die besten Chunks gehen an das Modell. Eine Retrieval-Runde pro Frage.
• Agentisches Suchen. Das Modell bekommt Tools wie grep, Datei-Reads, eine Search-API oder einen SQL-Endpunkt und entscheidet anhand seiner Funde, was es als Nächstes nachschlägt. Mehrere Runden pro Frage.

Wann schlägt ein Kontext mit 1M Tokens das RAG?

Ein Long Context schlägt Retrieval, wenn die gesamte Wissensbasis bequem hineinpasst und sich selten ändert. Anthropic sagt selbst: unter 200.000 Tokens, rund 500 Seiten, kannst du „einfach die gesamte Wissensbasis“ in den Prompt aufnehmen.

Das Preisargument hat sich geändert. Stand September 2026 rechnen Claude 4.6 und neuere Modelle das volle 1M-Token-Fenster zu regulären Tarifen ab; die Preisseite formuliert es so: „eine 900k-token request wird zum gleichen Token-Preis abgerechnet wie eine 9k-token request“. Ein bisschen Rechnen mit den Listenpreisen: ein 200.000-Token-Präfix auf Claude Opus 5.5 ($4 pro Million Input-Tokens) kostet $0.80 pro ungecachte Anfrage und $0.04, wenn es mit $0.20 pro Million aus dem Prompt-Cache gelesen wird. Auf Sonnet 5 ($2 Input, $0.20 Cache-Reads) kostet der Cache-Read ebenfalls $0.04. Zu diesem Preis ist es eine ernsthafte Option, auf den Retrieval-Stack zu verzichten.

Das Genauigkeitsargument hat nicht ganz aufgeholt. Chromas Studie Context Rot (Juli 2025, 18 Modelle) fand, dass „Modelle nutzen ihren Kontext nicht gleichmäßig; stattdessen wird ihre Leistung immer unzuverlässiger, je länger die Eingabe“, und dass es schneller abfällt, wenn Frage und Antwort wenige gemeinsame Wörter haben. Das ältere Ergebnis „Lost in the Middle“ zeigt in dieselbe Richtung: Informationen in der Mitte eines langen Kontexts werden schlechter genutzt als Informationen am Anfang oder am Ende. Ein Long Context beseitigt also Retrieval-Fehler, fügt aber Ablenkung hinzu. Am besten funktioniert er bei breit gefassten Fragen („fasse unsere Rückgaberichtlinie über diese Dokumente zusammen“) und am schlechtesten bei nadelartigen Suchen in großen, redundanten Korpora.

Warum ist hybrides Retrieval bei großen Korpora immer noch der Default?

Sobald ein Korpus weit über das hinausgeht, was in den Kontext passt, oder Fragen präzise Nachschläge brauchen, bleibt Retrieval die zuverlässigste und günstigste Option. Das stärkste veröffentlichte Rezept kombiniert kontextuelle Chunks, BM25 plus Embeddings und einen Reranker.

Anthropics Beitrag Contextual Retrieval hat gemessen, was jede Schicht an der Top-20-Retrieval-Fehlerrate ausmacht. Ein kurzer, vom Modell geschriebener Kontext, der jedem Chunk vor dem Embedding vorangestellt wird („contextual embeddings“), senkte sie von 5.7% auf 3.7%. Kontextuelles BM25 brachte sie auf 2.9%, ein Reranker auf 1.9% – insgesamt eine Senkung um 67%. Die einmaligen Vorverarbeitungskosten lagen bei rund $1.02 pro Million Dokument-Tokens mit Prompt-Caching.

Zwei Dinge machen das zum Default. Erstens sind die Kosten pro Frage klein und konstant: ein Embedding-Call, zwei Index-Lookups, ein Rerank und ein Prompt von ein paar tausend Tokens. Zweitens ist der Retrieval-Schritt nachvollziehbar. Du kannst loggen, welche Chunks zurückkamen, Recall gegen gelabelte Fragen berechnen und Berechtigungen in der Query durchsetzen. Für einen Prompt mit einer Million Tokens gilt beides nicht.

Was ist agentisches Suchen, und wann schlägt es Vektoren?

Agentisches Suchen gibt dem Modell Suchtools und lässt es iterieren: fragen, lesen, verfeinern, nochmal fragen. Es schlägt einen Vektorindex, wenn sich der Korpus ständig ändert, eine starke Struktur hat (Pfade, Identifier, Schemata) und die Frage mehrere Sprünge braucht.

Coding-Agenten sind der klarste Fall. Eine Community-Beschreibung des agentischen Suchmusters zitiert Anthropics Cat Wu zu Claude Code: „Wir haben anfangs durchaus Vektor-Embeddings verwendet. Die sind wirklich mühsam zu pflegen, weil man sie fortlaufend neu indexieren muss… Claude ist wirklich gut im agentischen Suchen.“ Eine Codebasis ändert sich mit jedem Commit, Identifier sind exakte Strings, die grep zuverlässig findet, und der Agent kann einem Import von Datei zu Datei folgen. Ein Index wäre immer leicht veraltet, auch was noch nicht committet ist.

Dieselbe Beschreibung listet die Kosten ehrlich auf: mehr Tokens über die Iterationen, höhere Latenz bei komplexen Fragen, schwächeres semantisches Matching („authentication“ gegen „login“) und die Notwendigkeit leistungsfähiger Modelle. Agentisches Suchen verlagert außerdem die Abbruchentscheidung zum Modell, es braucht also ein Budget; die Mechanik steht in die Agentenschleife, erklärt. Ein pragmatischer Mittelweg: dem Agenten ein hybrides Suchtool als eines seiner Tools geben. Dann bekommt er semantischen Recall, wenn er ihn braucht, und sonst exakte Treffer.

Wie verhalten sich Kosten und Latenz über die drei Ansätze?

Retrieval hat die niedrigsten und planbarsten Kosten pro Frage; Long Context ist nur so lange günstig, wie der Cache warm ist; agentisches Suchen kostet am meisten und schwankt am stärksten. Die Tabelle ist qualitativ, außer wo ein Preis genannt wird.

Prompt-Caching macht die Long-Context-Spalte überhaupt erst brauchbar, und seine Details (5-Minuten- gegen 1-Stunden-Cache, was ihn invalidiert) entscheiden über die echte Rechnung. Das steht in LLM-Kosten und Latenz mit Caching, Routing und Batching senken.

Abwägung: wo jeder Ansatz versagt

Jede Option hat eine Fehlerart, die die anderen vermeiden. Gut zu wählen heißt zu wissen, welchen Fehler deine Nutzer zuerst bemerken würden.

• Long Context scheitert an Größe, Berechtigungen und Präzision. Er hört auf zu funktionieren, wenn der Korpus über das Fenster hinauswächst, er kann Nutzer mit unterschiedlichen Zugriffsrechten nicht aus einem gecachten Prompt bedienen, und nadelartige Fragen leiden unter Context Rot.
• Hybrides Retrieval versagt still. Ist der richtige Chunk nicht in den Top k, antwortet das Modell aus den falschen – und klingt genauso selbstsicher. Nur eine Retrieval-Metrik fängt das ab.
• Agentisches Suchen scheitert an Kosten und Abbruch. Die Tokens wachsen mit jeder Runde, und das Modell kann nach dem ersten plausiblen Treffer aufhören oder weitersuchen, obwohl es die Antwort schon hat.
• Keine davon kann aggregieren. „Wie viele Bestellungen wurden im letzten Quartal verspätet versandt“ ist eine SQL-Abfrage. Gib dem Modell ein Query-Tool statt Dokumenten.

Wie bewertest du die Wahl?

Bewerte das Retrieval getrennt von der Generierung, und zwar mit demselben gelabelten Fragenkatalog für jede Option. Wenn du nur Endantworten bewertest, kannst du einen Retrieval-Fehler nicht von einem Generierungsfehler unterscheiden.

Sammle ein paar Dutzend echte Fragen, labelle die Passagen, die sie beantworten, und nimm auch Fragen ohne Antwort auf. Für das Retrieval misst du recall@k (Anthropics Fehlerrate ist 1 minus recall@20). Für Long Context, wo es keinen Retrieval-Schritt gibt, prüfst du, ob die Antwort die richtige Passage zitiert. Für agentisches Suchen loggst du die Tool-Aufrufe und misst, ob überhaupt die richtige Datei oder Zeile gelesen wurde, dazu die Anzahl der Runden und der Tokens. Dann bewertest du die Antworten mit einem validierten Grader. Wie man Grader baut und validiert, steht in Evals für LLM-Produktfeatures.

Eine Entscheidungscheckliste

1. Zähle deinen Korpus in Tokens mit dem Tokenizer des Anbieters, nicht in Seiten oder Wörter.
2. Unter ~200K Tokens und stabil: Probiere zuerst Long Context mit Prompt-Caching und miss die Antwortqualität.
3. Verschiedene Nutzer sehen verschiedene Dokumente: Nimm Retrieval mit Berechtigungsfiltern in der Query.
4. Großer oder wachsender Korpus: hybrides Retrieval mit kontextuellen Chunks, BM25 plus Vektoren und einem Reranker.
5. Code oder strukturierte Dateien, die sich ständig ändern: agentisches Suchen mit grep, Reads und einem Runden-Budget.
6. Zähl- und Aggregationsfragen: Gib dem Modell ein SQL- oder API-Tool, keine Dokumente.
7. Logge für jede Antwort, was das Modell gelesen hat: Chunk-IDs, Dateien oder die Version des Cache-Präfixes.
8. Bewerte Retrieval und Antworten getrennt an einem gelabelten Fragenkatalog – vor und nach jeder Änderung.

Wenn du für ein Produkt zwischen diesen Optionen wählst und das durchsprechen willst, findest du mehr unter KI-Engineering.

Quellen

1. Anthropic: Introducing Contextual Retrieval (2024)
2. Chroma: Context Rot – How Increasing Input Tokens Impacts LLM Performance (2025)
3. Liu et al., Lost in the Middle: How Language Models Use Long Contexts (2023)
4. Claude docs: Pricing (Long Context, Prompt-Caching, Tokenizer)
5. Claude docs: Models overview
6. Awesome Agentic Patterns: Agentic search over vector embeddings