Die meisten RAG-Implementierungen funktionieren schlecht. Das Modell ist nicht das Problem — Claude oder GPT-5 beantworten Fragen problemlos anhand abgerufener Dokumente. Das Retrieval scheitert: Das System liefert die falschen Chunks, und das Modell erzeugt daraus eine selbstbewusste Antwort auf falscher Grundlage.
Dieser Praxisleitfaden behandelt die drei wirksamsten Korrekturen: Chunking-Strategie, Reranking und hybride Suche. Setzen Sie diese richtig um, verschwinden die meisten Beschwerden, RAG funktioniere im eigenen Anwendungsfall nicht.
Wir überspringen die tiefgehende technische Mathematik und konzentrieren uns stattdessen darauf, was Sie tatsächlich tun sollten.
Warum Retrieval fehlschlägt
Die Standard-RAG-Pipeline:
- Teilen Sie Dokumente in Abschnitte auf.
- Erzeugen Sie Embeddings für jeden Abschnitt.
- Wenn eine Frage kommt, erzeugen Sie ein Embedding und suchen die ähnlichsten Abschnitte (Kosinusähnlichkeit).
- Übergeben Sie diese Chunks an das LLM.
Jeder Schritt besitzt eigene Fehlermöglichkeiten:
Schlechtes Chunking erzeugt Chunks, die zu kurz für einen sinnvollen Kontext oder zu lang für inhaltliche Kohärenz sind. Werden logische Gedanken in der Mitte getrennt, lässt sich keine Hälfte zuverlässig abrufen.
Naive Ähnlichkeitssuche findet Chunks mit gemeinsamem Vokabular, die inhaltlich nicht relevant sind. Die Anfrage „Wie kann ich mein Abonnement kündigen?“ kann jeden Chunk mit dem Wort „Abonnement“ liefern — auch unpassende Marketingtexte.
Kein Reranking bedeutet, dass das LLM das sieht, was das Ähnlichkeitsmaß zurückgibt. Der ähnlichste Abschnitt ist nicht immer der relevanteste.
Reine semantische Suche übersieht wichtige exakte Schlüsselworttreffer. Eine Suche nach „Fehlercode 503“ kann sogar einen Chunk mit genau diesem Text verfehlen, wenn der semantische Vektor der Anfrage nicht zum Gesamtthema des Chunks passt.
Die drei Lösungen — besseres Chunking, Reranking und hybride Suche — adressieren diese Probleme.
Lösung 1: Besseres Chunking
Chunking ist die einflussreichste Einzelentscheidung in einer RAG-Pipeline — und wird häufig erst hinterfragt, wenn die Ergebnisse bereits schlecht sind.
Der einfache Standard vieler No-Code-Werkzeuge teilt Dokumente nach fester Tokenzahl auf, etwa 500 Tokens mit 50 Tokens Überlappung. Das funktioniert grundsätzlich, scheitert aber häufig.
Bessere Strategien:
Semantisches Chunking
Teilen Sie Dokumente an semantischen Grenzen — an Stellen, an denen das Thema wechselt — statt an willkürlichen Tokenzahlen. Die meisten modernen Frameworks (LangChain, LlamaIndex) haben semantische Chunker, die Themenwechsel erkennen und dort aufteilen.
Der Vorteil: Abschnitte enthalten vollständige Ideen. Das Modell erhält kohärente Kontexte statt halb fertiger Argumente.
Strukturbewusstes Chunking
Wenn Ihre Dokumente eine natürliche Struktur haben (Markdown-Überschriften, HTML-Abschnitte, PDF-Kapitel, Code-Funktionsgrenzen), nutzen Sie diese. Teilen Sie nach Abschnitt, nicht nach Token.
Für Markdown:
- Jeder H2-Abschnitt bildet einen Chunk, dem der H1-Kontext vorangestellt wird.
- Längere H2-Abschnitte werden in Unterabschnitte unterteilt, wobei die H2-Überschrift als Kontext wiederholt wird.
Für Code:
- Jede Funktion oder Klasse ist ein Chunk.
- Der Chunk enthält den Dateipfad und alle Importe.
Bei strukturierten Inhalten ist dies deutlich besser als blindes Chunking nach fester Größe.
Hierarchisches Chunking
Ein Muster aus der jüngeren RAG-Forschung erzeugt Chunks auf mehreren Ebenen:
- Kleine Chunks (200–500 Tokens) für präzises Retrieval.
- Mittlere Chunks (1.000–2.000 Tokens) für Kontext.
- Dokumentzusammenfassungen (50–100 Tokens) für hochrangige Übereinstimmung.
Beim Abruf suchen Sie anhand kleiner Chunks, geben aber den umgebenden mittleren Chunk zurück. So erhält das LLM einen präzisen Treffer mit ausreichend Kontext.
Wahl der Chunkgröße
Eine grobe Heuristik nach Inhaltstyp:
| Inhaltstyp | Chunkgröße | Begründung |
|---|---|---|
| Technische Dokumentation / Handbücher | 500–1.000 Tokens | Abgeschlossene Konzepte, mittlere Informationsdichte |
| Code | Eine Funktion/Klasse pro Chunk | Logische Einheiten statt willkürlicher Ausschnitte |
| Lange Artikel / Bücher | 1.000–2.000 Tokens | Gedanken entwickeln sich über mehrere Absätze |
| Kundensupport-Tickets | Ein Ticket = ein Chunk | Kein Aufteilen innerhalb eines Tickets |
| Rechtliche Dokumente / Verträge | Abschnittsbasiert, oft 500–1.500 Tokens | Logische Einheiten; Klauselgrenzen beibehalten |
| Tabellenkalkulationsdaten | Zeile + Überschriften | Jede Zeile als Chunk, mit Spaltenüberschriften |
Wenn ein No-Code-Werkzeug das Chunking verbirgt, testen Sie zehn Fragen, deren Antworten sicher im Korpus enthalten sind. Fehlt der richtige Chunk regelmäßig in den Suchergebnissen, liegt das Problem beim Chunking.
Ein Muster, das gut funktioniert: „Seite oder Abschnitt, dann fragebasiert“
Für die meisten persönlichen RAG-Anwendungen funktioniert das Muster:
- Erstellen Sie Chunks nach Dokumentabschnitten wie Markdown-H2-Überschriften oder PDF-Kapiteln.
- Unterteilen Sie Abschnitte mit mehr als etwa 2.000 Tokens nach Absätzen.
- Stellen Sie jedem Chunk Dokumenttitel und Abschnittsüberschrift als Kontext voran.
- Ergänzen Sie eine kurze Beschreibung der Fragen, die der Chunk beantwortet — beim Indexieren automatisch durch ein schnelles LLM erzeugt.
Der automatisch erzeugte Hinweis „Welche Fragen beantwortet dieser Chunk?“ wird erstaunlich selten genutzt und ist sehr wirksam. Nutzeranfragen sind häufig als Fragen formuliert; der Abgleich mit Metadaten in Frageform ist dann präziser als mit dem unbearbeiteten Dokumenttext.
Lösung 2: Reranking
Ordnen Sie nach dem ersten Abruf — typischerweise 20–50 Chunks anhand der Vektorähnlichkeit — die Ergebnisse mit einem Reranker nach ihrer tatsächlichen Relevanz für die Anfrage.
Ein Reranker ist ein separates, meist kleineres spezialisiertes Modell. Es bewertet Paare aus Anfrage und Chunk mit einem Relevanzwert. Wenden Sie es auf die besten 20–50 Ergebnisse an, sortieren Sie neu und übergeben Sie die besten 3–5 Chunks an das LLM.
Der Vorteil: deutlich bessere Präzision. Vektorsimilarität ist schnell, aber nicht sehr genau; Reranker sind langsamer, aber viel präziser. Die Kombination aus beiden gibt Ihnen schnelles Retrieval mit präziser Sortierung.
Reranker-Optionen im Jahr 2026:
- Cohere Rerank — der etablierte API-basierte Reranker. 2,00 US-Dollar pro 1.000 Suchvorgänge (Listenpreis, geprüft am 2026-07-10).
- Voyage AI rerank-2 — starkes kommerzielles Angebot, oft besser als Cohere in Nischenbereichen.
- bge-reranker-v2-m3 — Open Source, lokal oder auf günstiger Hosting-Infrastruktur betreibbar.
- Jina Reranker — eine weitere leistungsfähige Open-Source-Option.
In einer typischen Pipeline:
- Vektorsuche liefert Top 50 Abschnitte (günstig, schnell).
- Reranker bewertet alle 50 gegen die Abfrage (teurer, langsamer).
- Top 5 nach Rerank-Bewertung werden an das LLM übergeben.
Zusätzliche Latenz: etwa 200–500 ms. Qualitätsgewinn: häufig 20–40 % bei Benchmarks zur Retrieval-Genauigkeit.
Bei No-Code-Werkzeugen ohne integriertes Reranking — NotebookLM und viele einfache n8n-Lösungen — ist dies die wirkungsvollste einzelne Verbesserung. n8n bietet einen Cohere Rerank Node; LangChain und LlamaIndex enthalten native Reranker-Integrationen.
Lösung 3: Hybride Suche
Vektorähnlichkeit erfasst semantische Treffer. Schlüsselwortsuche mit BM25 oder einem ähnlichen Verfahren erfasst exakte Übereinstimmungen. Beide finden Ergebnisse, die das jeweils andere Verfahren übersieht.
Eine Abfrage nach „Wie behebe ich HTTP 503-Fehler an unserem Gateway?“:
- Vektorsuche findet Abschnitte über HTTP-Fehler, Gateway-Probleme, Fehlersuche.
- Die Schlüsselwortsuche findet Chunks, die „503“ ausdrücklich erwähnen — möglicherweise die eigentliche Antwort.
Hybride Suche führt beide Verfahren aus und kombiniert die Ergebnisse. Dazu dient Reciprocal Rank Fusion (RRF): Aus beiden Ranglisten entsteht eine gemeinsame Bewertung, die beide Signale berücksichtigt.
Die Umsetzung in den meisten Tools ist einfach:
- Führen Sie Vektorsuche durch → erhalten Sie eine sortierte Liste A.
- Führen Sie BM25-/Schlüsselwortsuche aus → erhalten Sie die sortierte Liste B.
- Für jeden Abschnitt berechnen Sie seine RRF-Bewertung = 1/(k + rank_in_A) + 1/(k + rank_in_B) (mit k typischerweise 60).
- Sortieren Sie nach kombinierter Bewertung, geben Sie die besten Ergebnisse zurück.
Im Jahr 2026 unterstützen folgende Werkzeuge hybride Suche nativ:
- Weaviate (Vektordatenbank) — hybride Suche ohne Zusatzentwicklung.
- Qdrant — hybride Suche über Filter.
- Pinecone — hybride Suche über Sparse-Vektoren.
- Elastic / OpenSearch — kombinierte Schlüsselwort- und Vektorsuche.
- Die meisten n8n-RAG-Vorlagen — moderne Vorlagen verwenden hybride Suche standardmäßig.
Der Vorteil: deutlich besserer Recall bei Anfragen mit bestimmten Kennungen, Codes, Namen oder Fachbegriffen. Für technische Inhalte wie Code, Fehlercodes, Produktnamen und regulatorische Verweise ist hybride Suche praktisch unverzichtbar.
Enthalten Ihre Anfragen häufig Begriffe mit erforderlicher exakter Übereinstimmung — Zahlen, Namen, Codes oder feste Formulierungen — aktivieren Sie hybride Suche. Der Aufwand ist gering, der Nutzen groß.
Alles zusammenführen
Eine moderne RAG-Pipeline im Jahr 2026:
Query
↓
Query rewriter (optional — clean up the query, expand abbreviations)
↓
Hybrid retrieval: vector + keyword search
↓
Top 30-50 results
↓
Reranker
↓
Top 5 by reranker score
↓
LLM with retrieved chunks + query
↓
Cited answer
Jeder Schritt ist für sich günstig. Zusammen erreichen sie eine Retrieval-Qualität, die sich grundlegend von „Vektorähnlichkeit → Top 5 → LLM“ unterscheidet.
Einige weniger verbreitete, aber wirkungsvolle Ergänzungen:
Abfrageerweiterung. Schreiben Sie die Benutzerabfrage in mehrere Varianten um und suchen Sie jede. Erfasst verschiedene Formulierungen.
Mehrstufiges Retrieval. Führen Sie bei komplexen Fragen mehrere Abrufe durch. Der erste identifiziert Teilfragen, der zweite sucht Antworten für jede Teilfrage.
Konversationsbezogenes Retrieval. Nutzen Sie in einem mehrteiligen Gespräch den bisherigen Verlauf für den Abruf: „Die Person fragte zuvor nach X; priorisiere daher Inhalte zu X.“
Quellfilterung. Verwenden Sie Metadatenfilter, um Retrieval zu begrenzen. „Suchen Sie nur Dokumente mit dem Tag ‚EU-Regelungen‘ und datiert nach 2023.“
Diese Funktionen sind zunehmend in No-Code-RAG-Werkzeugen verfügbar. Stellen Sie jedoch zuerst sicher, dass die drei Grundlagen — gutes Chunking, Reranking und hybride Suche — funktionieren.
So messen Sie die RAG-Qualität
Sie können nichts verbessern, was Sie nicht messen. Einige praktische Bewertungsstrategien:
Test mit Referenzfragen. Wählen Sie 20 Fragen mit bekannten richtigen Antworten. Prüfen Sie monatlich: Wurden die richtigen Chunks abgerufen? Hat das Modell korrekt geantwortet?
Retrieval Recall@K. Bestimmen Sie für jede Referenzfrage die Chunks mit der Antwort. Prüfen Sie dann, ob mindestens einer davon unter den besten K Ergebnissen — 5, 10 oder 20 — liegt, und messen Sie den Anteil.
LLM-as-a-Judge-Bewertung. Lassen Sie ein leistungsfähiges Modell wie Claude Opus oder GPT-5 einen repräsentativen Fragenbestand danach bewerten, ob Antworten korrekt, vollständig, quellengetreu und sauber zitiert sind. Ein eigener Artikel behandelt Evaluationen ausführlich.
Wahrgenommene Nutzerqualität. Ergänzen Sie bei Team- oder Produktionssystemen jede Antwort um eine positive oder negative Bewertung. Analysieren Sie Muster negativer Rückmeldungen; sie häufen sich oft bei bestimmten Fragetypen.
Der größte Fehler ist, die Messung vollständig zu überspringen. „Es fühlt sich okay an“ ist keine Messung. Sie werden nicht wissen, ob Ihre Verbesserungen funktionieren, ohne sie.
Praxisbeispiel: ein schwaches RAG-System verbessern
Angenommen, Sie haben ein persönliches RAG-System für die interne Unternehmensdokumentation erstellt. Die Qualität ist mäßig: Nur etwa 60 % der Fragen erhalten eine nützliche Antwort. Wenden Sie die folgenden Verbesserungen der Reihe nach an:
Prüfen Sie zuerst das Retrieval. Untersuchen Sie bei zehn schlechten Antworten die abgerufenen Chunks. War der richtige dabei, liegt das Problem beim Modell oder Prompt. Andernfalls liegt es beim Retrieval.
Wenn Retrieval das Problem ist:
-
Prüfen Sie das Chunking. Sind die Chunks kohärent? Trennt der Chunker wichtige Gedanken? Wechseln Sie zu semantischem oder strukturbewusstem Chunking.
-
Fügen Sie einen Reranker hinzu. Platzieren Sie bei einfacher Vektorsuche Cohere Rerank oder bge-reranker-v2-m3 zwischen Retrieval und LLM. Der Gewinn ist meist sofort sichtbar; messen Sie ihn dennoch mit Ihrem eigenen Evaluationsbestand statt anhand allgemeiner Prozentangaben.
-
Fügen Sie hybride Suche hinzu. Dies ist besonders wichtig bei Produktnamen, Fehlercodes und Fachbegriffen.
-
Prüfen Sie Ihre Indexierung. Sind die Abschnitte mit Metadaten versehen (Dokumenttyp, Abschnitt, Datum)? Verwenden Sie Metadatenfilter in Retrieval.
Wenn das Modell das Problem ist (richtige Abschnitte abgerufen, falsche Antwort):
-
Präzisieren Sie den Prompt. Weisen Sie ausdrücklich an: „Antworten Sie ausschließlich anhand des bereitgestellten Kontexts. Falls dieser die Frage nicht abdeckt, weisen Sie darauf hin.“
-
Fordern Sie Quellenangaben. Verlangen Sie Zitate aus den konkret verwendeten Chunks. Das erleichtert die Fehlersuche und reduziert Halluzinationen.
-
Verwenden Sie ein stärkeres Modell. Wenn Sie ein kleines schnelles Modell verwenden, probieren Sie Claude Sonnet 4.5 oder GPT-5 aus.
Nach zwei oder drei solchen Analyse- und Korrekturrunden erreichen viele RAG-Implementierungen eine Quote nützlicher Antworten von 85–90 %. Ab diesem Niveau beginnen Nutzer typischerweise, das System anzunehmen und ihm zu vertrauen.
Häufige Fehler
Einige spezifische Dinge, die Menschen immer wieder überraschen:
Falsche Inhalte indexieren. Marketingseiten, veraltete Dokumentation und minderwertige Blogbeiträge werden vom Modell gleichermaßen als maßgeblich behandelt. Kuratieren Sie konsequent.
Den Index nach Dokumentänderungen nicht aktualisieren. Ein RAG-System mit veralteten Inhalten liefert selbstbewusst falsche Antworten. Indexieren Sie regelmäßig neu oder synchronisieren Sie automatisch.
Ignorieren der Bewertung. Die meisten RAGs werden ohne Messung implementiert und nie verbessert. Die Phase „es fühlt sich okay an“ hält ewig. Bauen Sie Bewertung von Anfang an ein.
Retrieval als Blackbox behandeln. „Es funktioniert nicht“ ist keine Diagnose. Untersuchen Sie die zurückgegebenen Chunks; meist wird das Problem sofort sichtbar.
Zu frühes Overengineering. Sie müssen nicht mit einer hochkomplexen Pipeline beginnen. Starten Sie mit NotebookLM oder einfacher Vektorsuche und ergänzen Sie Komplexität erst bei einem konkreten Engpass.
Wann dies wichtig ist
Die drei Lösungen — besseres Chunking, Reranking und hybride Suche — sind besonders wichtig, wenn:
- Der Korpus ist technisch und enthält spezifische Terminologie.
- Abfragen exakte Übereinstimmungen erfordern (Codes, Namen, IDs).
- Präzision ist entscheidend, etwa in Recht, Compliance oder Kundensupport.
- Das System wird in großem Maßstab genutzt — bei 10.000 täglichen Anfragen wirkt sich selbst ein kleiner Qualitätsgewinn stark aus.
Sie sind weniger wichtig, wenn:
- Der Korpus ist klein — weniger als 100 Dokumente — und gut organisiert.
- Abfragen offene Fragen sind („Was ist unsere Haltung zu X“).
- Nutzer verzeihen und iterieren, um die Antwort zu finden.
- Der Anwendungsfall explorativ statt präzise ist.
Für persönliche und kleine Team-RAG-Systeme bietet der Wechsel von einfacher Vektorähnlichkeit zu Vektorsuche plus Reranker meist den größten Hebel. Danach folgt die hybride Suche. Chunking bleibt bei jeder Größenordnung wichtig.
Das Wichtigste
Schlechtes RAG bedeutet fast immer schlechtes Retrieval, und dessen Ursachen liegen meist bei Chunking, Reranking und Suchverfahren. Beheben Sie diese drei Punkte, verschwinden die meisten Qualitätsprobleme.
Sie müssen kein Suchmaschinenexperte sein, um diese Verfahren anzuwenden. Weaviate, Pinecone, Qdrant, n8n-Vorlagen und LangChain-Integrationen machen sie zugänglich. Der Engpass besteht heute vor allem darin, diese Möglichkeiten zu kennen und gezielt einzusetzen.
Wenn Ihr RAG-System nicht funktioniert, geben Sie nicht dem Modell die Schuld. Untersuchen Sie die zurückgegebenen Chunks, korrigieren Sie das Retrieval und evaluieren Sie erneut.
