Alle Beiträge

Daten & RAG-Architektur

RAG 2026: Hybrid-Suche, Reranking, GraphRAG

Baybora Gülec24. Juni 20268 Min.

TL;DR

  • Naives RAG ist 2026 abgelöst. "Text zerstückeln, einbetten, die Top-Treffer ins Kontextfenster kippen" liefert mittelmäßige Ergebnisse — der Standard ist heute mehrstufig.
  • Der Mythos "das große Kontextfenster macht RAG überflüssig" stimmt nicht. 1-Million-Token-Fenster sind real, verlieren aber Inhalte in der Mitte. Das Produktionsmuster bleibt: erst gezielt abrufen, dann verarbeiten.
  • Gute Wissensbasen brauchen 2026 Hybrid-Suche + Reranking als Minimum — der größte Hebel für ein internes KI-System, das verlässliche Antworten gibt.

Worum es geht

Die meisten Mittelstands-Use-Cases für KI laufen früher oder später auf dieselbe Sache hinaus: eine interne Wissensbasis, die zuverlässig Fragen beantwortet — aus Verträgen, Handbüchern, Tickets, Mails. Die Technik dahinter heißt RAG (Retrieval-Augmented Generation): Statt das Modell raten zu lassen, ruft man relevante Dokumente ab und gibt sie ihm als Kontext mit. Das Prinzip ist einfach. Die Umsetzung hat sich 2025/26 stark weiterentwickelt — und wer noch das Lehrbuch-RAG von 2023 baut, lässt Qualität liegen.

Was "naives RAG" ist — und warum es nicht reicht

Die erste Generation funktionierte so: Dokumente in Stücke schneiden, jedes Stück in einen Vektor einbetten, bei einer Frage die ähnlichsten Stücke heraussuchen, sie ins Kontextfenster legen. Das liefert brauchbare Demos — und enttäuschende Produktion. Typische Schwächen: Die reine Vektor-Ähnlichkeit verfehlt exakte Begriffe (Artikelnummern, Eigennamen, Fehlercodes), und die abgerufenen Stücke sind oft ähnlich, aber nicht die relevantesten.

Vom Lehrbuch-RAG zum Standard

Naives RAG (2023)?Produktions-RAG 2026Hybrid: Vektor + BM25Reranking nach RelevanzContextual RetrievalAgentic RAG, iterativVektor verfehlt exakte Begriffe · ähnliche statt relevanteste Treffer · alles ins Kontextfenster kippen
Naives Zerstückeln-und-Einbetten liefert Demos, keine Produktion — der 2026-Standard ruft mehrstufig ab, bevor das Modell überhaupt liest.

Der Standard 2026: mehrstufiger Abruf

Produktionsreife Wissensbasen kombinieren heute mehrere Techniken:

  • Hybrid-Suche — semantische Vektorsuche plus klassische Stichwortsuche (BM25), deren Ergebnisse fusioniert werden (wie BM25 und Dense-Retrieval zusammenspielen). So findet das System sowohl sinnverwandte Treffer als auch exakte Begriffe.
  • Reranking — ein zweites, spezialisiertes Modell sortiert die Kandidaten neu nach echter Relevanz, bevor sie ins Kontextfenster gehen (Reranking-Patterns und wie man sie evaluiert). Dieser Schritt ist der mit dem besten Aufwand-Wirkung-Verhältnis.
  • Kontext anreichern — Anthropics "Contextual Retrieval" etwa stellt jedem Textstück eine kurze, generierte Einordnung voran. Das senkt die Fehlerrate beim Abruf laut Anthropic um knapp die Hälfte — und in Kombination mit Reranking um rund zwei Drittel.
  • GraphRAG — bei stark vernetztem Wissen (wer-gehört-zu-was, Abhängigkeiten) hilft ein Wissensgraph statt reiner Textstücke, um Fragen zu beantworten, die mehrere Quellen verbinden.

Reranking und Retrieval 2026: was der Stand der Technik wirklich ist

Die Reranker-Landschaft ist groß, aber gut vermessen. Laut dem Reranker-Leaderboard von Agentset (Stand Februar 2026) liegen Zerank-2 und Cohere Rerank 4 Pro nahezu gleichauf an der Spitze; Voyage rerank-2.5 folgt mit geringem Qualitätsabstand bei etwa halber Latenz und gilt deshalb vielfach als bester Kompromiss für den Produktionsbetrieb. Für Self-Hosting und strenge Datenschutzanforderungen haben sich die Open-Source-Modelle bge-reranker-v2-m3 und Jina Reranker v2 etabliert. Wichtig zur Einordnung: Das sind Anbieter- und Community-Benchmarks, keine peer-reviewten Zahlen — auf dem eigenen Korpus nachmessen bleibt Pflicht.

Eine eigene Klasse bilden Late-Interaction-Modelle wie ColBERT: Statt ein Dokument in einen einzigen Vektor zu pressen, speichern sie Vektoren pro Token und vergleichen feinkörnig (MaxSim-Operator). Das war lange ein Forschungsthema — inzwischen ist es Produktionsrealität: Qdrant unterstützt Multivector-Retrieval nativ, ColBERTv2 mit PLAID hat die Skalierung bewiesen, und die ECIR 2026 widmet dem Thema einen eigenen Workshop (arXiv:2511.00444).

Auch vor dem Reranking hat sich etwas bewegt: Late Chunking — erst das ganze Dokument einbetten, dann teilen, damit jedes Stück den Dokumentkontext behält — ist laut Praxisberichten nicht mehr experimentell (nativ in Jina-Embeddings v3/v4, Integrationen für Elasticsearch, Milvus, Qdrant). Matryoshka-Embeddings vierteln die Index-Speicherkosten bei nur wenigen Prozent Präzisionsverlust, und multimodale Modelle wie Cohere embed-v4 betten Text und Bilder in denselben Raum und ersetzen zunehmend separate OCR-Pipelines.

GraphRAG: wann der Graph sich lohnt — und wann nicht

GraphRAG hatte lange ein Kostenproblem: Beim Indexieren extrahiert ein LLM Entitäten und Beziehungen aus jedem Dokument — mächtig, aber teuer. Ein dokumentierter Fall bezifferte die Indexierung eines Datensatzes Anfang 2024 auf rund 33.000 US-Dollar. Genau hier setzt Microsofts LazyGraphRAG an: Es verschiebt die LLM-Arbeit vom Indexieren in die Abfrage. Laut Microsoft Research liegen die Indexierungskosten damit auf dem Niveau von gewöhnlichem Vektor-RAG — etwa 0,1 Prozent der Kosten des vollen GraphRAG — bei vergleichbarer Antwortqualität und um Größenordnungen niedrigeren Abfragekosten als die globale GraphRAG-Suche. LazyGraphRAG steckt seit Mitte 2025 in Microsoft Discovery und Azure Local; eine Open-Source-Veröffentlichung ist angekündigt. Daneben existieren Alternativen wie LightRAG oder Neo4j Graphiti.

Damit fällt das Kostenargument gegen den Graph weitgehend weg — die Architekturfrage bleibt. Der Konsens der Produktions-Guides:

  • Graph lohnt sich, wenn Fragen mehrere Quellen über Beziehungen verbinden müssen (Multi-Hop: wer liefert an wen, was hängt woran), wenn "globale" Fragen über den ganzen Korpus beantwortet werden sollen (Trends, Zusammenfassungen) oder wenn nachvollziehbare Beziehungs-Trails gefordert sind (Compliance).
  • Graph ist Overkill beim klassischen Fakten-Lookup ("Was steht in Vertrag X zu Kündigungsfristen?"), bei kleinen Korpora — und bei schnell wechselnden Daten, weil der Graph-Index bei jeder Änderung nachgezogen werden muss.

Faustregel: erst die Baseline aus Hybrid-Suche und Reranking bauen und messen — der Graph ist der nächste Schritt, wenn Antworten genau daran scheitern, Wissen aus mehreren Dokumenten zu verknüpfen.

Der Mythos vom Riesen-Kontextfenster

Eine populäre These lautet: "Modelle mit 1 Million Token Kontext brauchen kein RAG mehr — man wirft einfach alles rein." Die Realität ist differenzierter. Große Kontextfenster sind real und nützlich. Aber Modelle leiden unter dem "lost in the middle"-Effekt: Inhalte am Anfang und Ende des Kontexts werden zuverlässiger erinnert als die in der Mitte. Schüttet man wahllos alles hinein, sinkt die Trefferqualität — und die Kosten steigen mit jedem Token.

Das Produktionsmuster bleibt deshalb retrieve-then-reason: erst gezielt die relevanten Stücke abrufen, dann das Modell darüber nachdenken lassen. Das große Kontextfenster ersetzt den Abruf nicht — es ergänzt ihn.

Neu: Abruf als Werkzeug des Agenten

Die jüngste Entwicklung verbindet RAG mit dem Agenten-Trend: Statt einmal vorab abzurufen, wird die Suche als Werkzeug bereitgestellt, das der Agent bei Bedarf mehrfach und iterativ aufruft — nachfragen, verfeinern, nachschlagen, bis die Antwort steht ("Agentic RAG"). Für komplexe Fragen, die mehrere Schritte brauchen, ist das ein deutlicher Qualitätssprung gegenüber dem einmaligen Top-k-Abruf.

Agentic Retrieval: der eigentliche Sprung

Der oben beschriebene Wandel — Abruf als Werkzeug des Agenten — hat inzwischen ein eigenes Forschungsfeld: Deep Research. Eine Survey zu autonomen Recherche-Agenten (arXiv:2508.12752) beschreibt das Kernmuster: Der Agent zerlegt eine komplexe Frage in Teilfragen, formuliert Suchanfragen, bewertet die Treffer, formuliert um und ruft erneut ab — so lange, bis die Beweislage steht. Retriever, Hybrid-Suche und Reranker werden dabei vom fest verdrahteten Schritt zum Werkzeugkasten, aus dem der Agent je nach Frage wählt. Gemessen wird das inzwischen mit eigenen Benchmarks — etwa DeepResearch Bench (Berichts-Treue, Zitatgenauigkeit) oder BrowseComp (Recherche im offenen Web).

Die Infrastrukturseite dieses Musters ist standardisiert: Über das Model Context Protocol werden Retrieval-Systeme als Tools angebunden, die jeder Agent gleich aufruft — die Wissensbasis wird ein Baustein unter mehreren (MCP als Industrie-Infrastruktur). Die Abgrenzung dabei: RAG beantwortet "Was haben wir indexiert?", ein Live-Tool "Was ist jetzt der Stand?" — gute Agenten-Systeme brauchen beides. Der neue Engpass ist ebenfalls beschrieben: Dutzende Tools verstopfen den Kontext des Agenten mit Beschreibungen; die Forschung antwortet mit Retrieval über die Tools selbst (etwa ScaleMCP, NeurIPS 2025, arXiv:2505.06416). Abruf ist damit keine Pipeline-Stufe mehr, sondern eine Fähigkeit des Systems.

Häufige Fragen zu RAG 2026

Ist RAG tot?

Nein — gestorben ist nur das naive RAG von 2023. Die Debatte spaltet Entwickler zwar hörbar, aber in Produktion hat sich die Frage verschoben: nicht ob Abruf, sondern wie — mehrstufig, mit Hybrid-Suche, Reranking und zunehmend agentisch. Wissensbasen über private, aktuelle Dokumente funktionieren ohne Abruf schlicht nicht.

RAG oder großes Kontextfenster — was ist wirtschaftlicher?

Für wiederkehrende Anfragen gegen einen großen Korpus: RAG, deutlich. Eine Modellrechnung des Blogs byteiota beziffert den Unterschied pro Anfrage auf gut drei Größenordnungen zugunsten des gezielten Abrufs. Das volle Kontextfenster gewinnt nur bei kleinen, statischen Beständen von grob unter hundert Dokumenten.

Wann brauche ich GraphRAG?

Wenn Antworten Wissen aus mehreren Quellen über Beziehungen verknüpfen müssen (Multi-Hop) oder "globale" Fragen über den ganzen Korpus gestellt werden. Für reinen Fakten-Lookup ist der Graph Overkill. Das frühere Kostenargument gegen GraphRAG trägt seit LazyGraphRAG kaum noch — die Indexierung liegt laut Microsoft Research auf Vektor-RAG-Niveau.

Welches Embedding-Modell sollte man 2026 wählen?

Stand Juli 2026 führt auf dem englischen MTEB-Leaderboard Gemini Embedding 001; multilingual liegen KaLM- und Qwen3-Modelle vorn, für multimodale Korpora ist Cohere embed-v4 etabliert. Aber: Leaderboard-Ränge verschieben sich monatlich und übertragen sich nicht eins zu eins — entscheidend ist ein kleiner Benchmark auf dem eigenen Korpus mit echten Nutzerfragen.

Brauche ich einen Reranker?

In Produktion: ja, fast immer. Der 2026-Konsens ist Hybrid-Retrieval plus Cross-Encoder-Rerank der Top 50–100 Kandidaten — der Schritt mit dem besten Aufwand-Nutzen-Verhältnis. Gehostet sind Voyage rerank-2.5 oder Cohere Rerank 4 übliche Wahlen, für Self-Hosting bge-reranker-v2-m3.

Stand: Juli 2026.

Was das für ein Projekt heißt

ReifegradAufbau
Lehrbuch (2023)Vektorsuche → Top-k → ins Kontextfenster
Solide Baseline (2026)Hybrid-Suche (Vektor + Stichwort) → Reranking → Kontext anreichern
FortgeschrittenAgentic RAG (iterativer Abruf) und/oder GraphRAG bei vernetztem Wissen

Die gute Nachricht für den Mittelstand: Der Sprung von "nett, aber unzuverlässig" zu "produktiv vertrauenswürdig" ist 2026 kein Hexenwerk mehr — er liegt in der Architektur, nicht in einem teureren Modell. Wer eine interne Wissensbasis ernsthaft betreiben will, sollte Hybrid-Suche und Reranking als Minimum einplanen.

So bauen wir bei azena Wissens- und Assistenz-Systeme, die belastbare Antworten geben statt plausibel klingender — mehr dazu unter KI-Beratung für den Mittelstand. Ein Wort der Vorsicht: Genau diese Wissensbasis ist die Hauptangriffsfläche für indirekte Prompt-Injection — un-vertrauter Text, der wie Wahrheit behandelt wird. Wenn ihr eine interne Wissensbasis plant, sprecht mit uns.

Stand: Mitte 2026. Faktenbasis quellengeprüft (u. a. Anthropic Engineering, Microsoft Research). Architekturmuster, herstellerneutral.

Baybora Gülec· Gründer, Azena

Nächster Schritt

Passt das auf Ihren Fall?

30-Min-Erstgespräch, kostenfrei und unverbindlich. Wir gehen Ihren konkreten Fall durch — und sagen ehrlich, wenn nichts passt.

Teilen LinkedIn Per E-Mail