RAG unter der Haube: Warum Embeddings allein selten für gute Suchergebnisse reichen
Kurz gesagt
Reine Embedding-Suche findet semantische Ähnlichkeit gut, tut sich aber mit exakten Begriffen, Namen und Artikelnummern schwerer. Belastbare RAG-Systeme kombinieren deshalb dichte Embeddings mit klassischer Volltextsuche (Hybrid Search) und setzen zusätzlich ein Reranking-Modell ein, das die besten Kandidaten präzise sortiert. Mindestens ebenso wichtig wie diese Suchtechnik ist eine saubere Datenaufnahme – schlechtes Chunking oder fehlende Metadaten lassen sich durch keine noch so gute Suche mehr ausgleichen.
Dense, Sparse und Hybrid: drei Suchverfahren mit unterschiedlichen Stärken
Dichte Embeddings (Dense Embedding) bilden einen Text auf einen oder wenige dichte Vektoren ab. Ihre Stärke liegt in semantischer Ähnlichkeit und Paraphrasen – sie erkennen, dass "Rechnung stornieren" und "Zahlung rückgängig machen" verwandt sind. Ihre Schwäche: exakte, seltene Begriffe wie Artikelnummern oder Eigennamen können untergehen. Sparse beziehungsweise lexikalische Verfahren arbeiten dagegen mit Termgewichten und sind bei exakten Begriffen, Namen und Produktnummern stärker. Multi-Vector- oder Late-Interaction-Verfahren bilden mehrere Vektoren pro Textabschnitt und ermöglichen eine feinere Interaktion zwischen Suchanfrage und Textpassage – auf Kosten von höherem Index- und Rechenaufwand. Hybrid-Suche kombiniert mehrere dieser Signale und ist robuster gegenüber unterschiedlichen Arten von Suchanfragen als ein einzelnes Verfahren allein.
Warum Volltextsuche in RAG-Systemen nicht vorschnell ersetzt werden sollte
Klassische Volltextsuche verarbeitet Begriffe, Wörterbücher, Rangfolgen und Phrasen und ist besonders wertvoll für Eigennamen, Artikelnummern, Paragraphen, Zitate und exakte Fachbegriffe. In RAG-Systemen sollte sie deshalb nicht vorschnell durch reine Embedding-Suche ersetzt werden – gerade in Branchen mit vielen exakten Bezeichnungen, etwa Artikelnummern oder Gesetzesparagraphen, bleibt sie ein wichtiger, ergänzender Suchweg.
Reranking: schnellen Recall von präziser Reihenfolge trennen
Reranking trennt zwei unterschiedliche Aufgaben: Ein erster, schneller Retriever liefert eine größere Menge an Kandidaten (hoher Recall). Ein genaueres, aber langsameres Modell – etwa ein Cross-Encoder oder ein Sprachmodell selbst – bewertet diese Kandidaten anschließend präziser und sortiert sie neu. Der Nutzen ist besonders dann relevant, wenn nur wenige Top-Treffer tatsächlich in den Antwortkontext übernommen werden oder wenn mehrere ähnliche Dokumentversionen im Bestand existieren, zwischen denen fein unterschieden werden muss.
Ergänzende Verfahren: Query Expansion und iteratives Retrieval
Weiterentwickelte Ansätze erzeugen zunächst ein hypothetisches Antwortdokument und nutzen dessen Embedding für die eigentliche Suche, oder ergänzen adaptive Bewertungs- und Korrekturschritte während des Retrievals. Diese Verfahren zeigen, dass Retrieval selbst ein iterativer Prozess sein kann – sie erhöhen aber die Zahl der nötigen Modellaufrufe und benötigen eigene, dafür passende Testverfahren, bevor sie produktiv eingesetzt werden.
Der unterschätzte Teil: Datenaufnahme vor der Suche
Die Suchqualität eines RAG-Systems hängt mindestens ebenso stark von der Datenaufnahme (Ingestion) wie von der eigentlichen Such- und Modelltechnik ab. Typische Fehlerquellen entstehen schon vor der ersten Suchanfrage:
- Veraltete Dokumentenkopien oder unklare Gültigkeit, weil Quelle und Eigentümer nicht sauber erfasst wurden
- Vertauschte Tabellenspalten, verlorene Tabellenstrukturen oder Texterkennungsfehler beim Extrahieren
- Zerschnittene Textabschnitte, bei denen Überschrift und zugehöriger Inhalt getrennt werden (schlechtes Chunking)
- Fehlende Filter- und Rechtefelder wie Quelle, Datum, Zugriffsberechtigung, Sprache oder Status
Originaldokument, extrahierter Inhalt, Textabschnitt, Embedding und Indexeintrag sind dabei getrennte, aber miteinander verbundene Bestandteile. Diese Verbindung sollte nachvollziehbar bleiben, damit sich ein Treffer bis zur ursprünglichen Fundstelle zurückverfolgen lässt und bei einer Dokumentänderung gezielt neu indexiert werden kann, statt den gesamten Bestand neu aufzubauen.
Was vor dem produktiven Einsatz geklärt sein sollte
Vor dem Livegang eines RAG-Systems lohnt sich die Prüfung entlang klarer Fragen: Funktioniert das gewählte Embedding-Modell zuverlässig in Sprache, Fachgebiet und typischer Textlänge des eigenen Bestands? Bleibt beim Zuschnitt der Textabschnitte die fachliche Einheit erhalten, ohne zu viel irrelevanten Kontext mitzuschleppen? Wie verhalten sich Anfragen mit Nummern oder Namen im Vergleich zu rein semantischen Fragen? Verbessert ein Reranking-Schritt das Ergebnis genug, um die zusätzlichen Kosten und die zusätzliche Antwortzeit zu rechtfertigen? Und: Werden Zugriffsrechte, Mandantentrennung, Version und Gültigkeit vor jeder Ausgabe konsequent angewendet?