Einbettungsfreie Retrieval-Augmented Generation: RAG ohne Vektor-Datenbanken

Retrieval-Augmented Generation (RAG) hat sich als Standardmethode etabliert, um großen Sprachmodellen verlässlichen, externen Kontext bereitzustellen. Der klassische RAG-Ansatz basiert auf Embeddings (numerischen Vektorrepräsentationen von Text) in Kombination mit einer Vektor-Datenbank, die semantische Suche ermöglicht.

Typischerweise werden Dokumente in kleinere Abschnitte zerlegt, mithilfe von Embedding-Modellen in hochdimensionale Vektoren umgewandelt, in einer Vektor-Datenbank gespeichert und per Nearest-Neighbor-Suche durchsucht, um den relevantesten Kontext für ein LLM zu finden. Dadurch können Modelle Informationen nach Bedeutung abrufen, statt sich an exakte Formulierungen zu binden.

Trotzdem bringt die Kombination aus „Vektor-DB + Embeddings“ häufig spürbare Nachteile bei Kosten, betrieblicher Komplexität und Performance mit sich. Aus diesen Gründen rückt der Fokus zunehmend auf Alternativen, die komplett ohne embedding-basierte Retrieval-Mechanismen auskommen. Forschende entwickeln immer häufiger Systeme, die RAG ohne Embedding-Modelle und ohne Vektorsuche umsetzen. In diesem Artikel erklären wir, was einbettungsfreies RAG bedeutet, warum es aktuell an Bedeutung gewinnt und wie es sich von klassischen Ansätzen mit Vektor-Datenbanken unterscheidet.

Zentrale Erkenntnisse

• Klassische RAG-Systeme setzen auf Embeddings und Vektor-Datenbanken. Inhalte werden in Chunks aufgeteilt, in hochdimensionale Vektoren umgewandelt und per Nearest-Neighbor-Suche in einer Vektor-Datenbank indexiert, um LLMs semantischen Kontext zu liefern.
• Vektorsuche bringt Grenzen mit sich, etwa semantische Lücken, geringere Präzision bei der Retrieval-Trefferquote und wenig Interpretierbarkeit. Diese Schwächen sind besonders problematisch in Bereichen, in denen präzise Antworten nötig sind, weil Embeddings Passagen liefern können, die zwar ähnlich klingen, aber keine Antwort enthalten.
• Embedding-basiertes RAG verursacht Infrastrukturaufwand und hohe Kosten. Das Erstellen von Embeddings, der Betrieb einer Vektor-Datenbank und das Re-Indexieren bei Datenänderungen können erhebliche Rechen- und Speicherressourcen erfordern.
• Einbettungsfreies RAG kann Embeddings und Vektorsuche durch andere Verfahren ersetzen. Dazu zählen keyword-basierte Suche (BM25), LLM-gesteuerte iterative Retrieval-Strategien (ELITE), wissensgraphbasierte Ansätze (GraphRAG) sowie prompt-basierte Retrieval-Methoden (Prompt-RAG), um semantische und operative Grenzen zu reduzieren.
• RAG ohne Embeddings kann die Nachvollziehbarkeit erhöhen, Latenzen verringern, Speicherbedarf senken und sich besser an spezielle Domänen anpassen. Das ist besonders relevant für Felder wie Gesundheitswesen, Recht und Finanzen sowie für Anwendungsfälle, in denen Transparenz oder dokumentübergreifendes Schlussfolgern wichtig ist.

Klassisches RAG und Vektor-Datenbanken

Im klassischen RAG-Design bilden Embeddings und Vektorsuche das Herzstück des Retrieval-Schritts.

In der Offline-Indexierung werden Quelldokumente in Chunks aufgeteilt, und jeder Chunk wird mithilfe eines Embedding-Modells in eine vektorbasierte Repräsentation überführt. Diese Vektoren werden anschließend in einer Vektor-Datenbank gespeichert, die für schnelle Nearest-Neighbor-Abfragen optimiert ist.

image

In der Online-Phase wird eine eingehende Nutzeranfrage ebenfalls in denselben Vektorraum eingebettet. Anschließend durchsucht das System den Vektor-Store und liefert die Top-k Chunk-Vektoren mit der geringsten Distanz zurück. Die Text-Chunks, deren Embeddings dem Query-Embedding am ähnlichsten sind, werden dann zusammen mit der Anfrage als Kontext an das LLM übergeben, damit es eine Antwort mit unterstützenden Informationen generieren kann.

Der zentrale Vorteil dieses Ansatzes liegt darin, dass Embeddings semantische Ähnlichkeit abbilden. So kann eine Frage auch dann mit passenden Textstellen verknüpft werden, wenn andere Wörter verwendet werden, der Inhalt aber dieselbe Bedeutung hat. Vektor-Datenbanken sind zudem darauf ausgelegt, hochdimensionale Ähnlichkeitssuche effizient auszuführen, wodurch die Retrieval-Latenz auch bei Korpora mit Millionen von Chunks beherrschbar bleibt.

Grenzen von Embeddings & Vektorsuche

Auch wenn der Ansatz weit verbreitet ist, hat vektor-basiertes RAG mehrere deutliche Schwachstellen. Schauen wir uns einige der wichtigsten an:

Semantische Lücken

Semantische Lücken treten bei Embedding-/Vektor-Retrieval häufig auf. Dichte Vektor-Ähnlichkeit kann eher thematische Nähe widerspiegeln als tatsächliche Antwortrelevanz. Dadurch können Systeme Passagen zurückgeben, die semantisch passend wirken, aber die gesuchte Information nicht enthalten – insbesondere dann, wenn Genauigkeit von exakten Zahlen, konkreten Daten oder Negationen abhängt. Embeddings können außerdem Schwierigkeiten mit domänenspezifischen Begriffen, seltenen Entitäten oder Multi-Hop-Fragen haben, bei denen Informationen über mehrere Dokumente hinweg verknüpft werden müssen.

Retrieval-Genauigkeit

Diese semantischen Probleme können in realen RAG-Einsätzen zu schwacher Retrieval-Genauigkeit führen. Wenn das Embedding-Modell die Verbindung zwischen Frage und korrekter Antwort nicht abbildet, enthalten die Top-Treffer der Vektorsuche möglicherweise nicht die stützende Passage. Einige Berichte deuten darauf hin, dass viele RAG-Pipelines Schwierigkeiten haben, den richtigen Evidenztext zu finden. Ein Practitioner berichtete, dass selbst nach Optimierung der „Chunking + Embedding + Vector Store“-Pipeline die Trefferquote für die richtigen Chunks „meist unter 60%“ liegt. In solchen Fällen können RAG-Systeme falsche oder unvollständige Antworten geben, weil der bereitgestellte Kontext nicht wirklich relevant ist.

Mangelnde Interpretierbarkeit und Steuerbarkeit

Embedding-basiertes Retrieval macht es zudem schwer nachzuvollziehen, warum eine Antwort verfehlt wurde oder warum eine falsche Passage ausgewählt wurde, da die Vektorlogik nicht transparent ist. Das Retrieval wird zu einem Black-Box-Prozess. Das gezielte Anpassen des Retrieval-Verhaltens – etwa um bestimmte Keywords oder Datenfelder stärker zu gewichten – ist schwierig, wenn das System ausschließlich auf gelernten Embedding-Repräsentationen basiert.

Infrastrukturkomplexität und Kosten

Embedding-Workflows verursachen sowohl Offline- als auch Online-Kosten. Offline erfordert das Erzeugen von Embeddings für tausende Dokumente Zeit und Rechenressourcen, oft unter Einsatz von GPUs. Online kann der Betrieb eines Vektor-Datenbankdienstes teuer sein, insbesondere weil dieser häufig viel Arbeitsspeicher benötigt. Für Teams ohne spezialisierte Infrastruktur kann das eine große Hürde sein. Hinzu kommen fortlaufende Wartungskosten des Indexes, da aktualisierte Daten eine erneute Embedding-Generierung und ein Re-Indexing notwendig machen können.

Klassisches RAG mit Vektor-Datenbanken hat erheblichen Nutzen gebracht, indem es semantische Suche für LLMs ermöglicht hat. Dennoch haben die genannten Grenzen Forschende dazu motiviert, Retrieval-Augmentierung über Vektor-Datenbanken hinaus weiterzudenken.

Was ist RAG ohne Embeddings?

RAG ohne Embeddings bezeichnet jeden RAG-Ansatz, der nicht auf Vektor-Embeddings als primären Mechanismus zur Kontextbeschaffung für die Generierung setzt. Damit entfällt der typische Schritt „Query und Dokumente embedden und anschließend Nearest-Neighbor-Vektorsuche ausführen“.

Wie lässt sich relevante Information ohne Embeddings finden? Es entstehen mehrere neue Ansätze:

Lexikalisches oder Keyword-basiertes Retrieval

Eine der direktesten Strategien für einbettungsfreies RAG ist lexikalische Keyword-Suche, auch Sparse Retrieval genannt.

Statt kontinuierliche Vektoren zu vergleichen, sucht das System nach überlappenden Keywords oder Tokens zwischen Query und Dokumenten, beispielsweise mit BM25. Obwohl diese Methode als „old school“ gilt, kann sie sehr wirkungsvoll sein und in vielen Szenarien konkurrenzfähig bleiben – teils auf Augenhöhe mit modernen vektor-basierten Ansätzen oder nur knapp dahinter.

Keyword-Suche bleibt in der Praxis wettbewerbsfähig. So zeigte ein XetHub-Benchmark, dass BM25 „nicht viel schlechter“ als moderne OpenAI-Embeddings abschneidet. Laut diesem Researcher könnte das Erreichen von 85% Recall relevanter Dokumente bei Embeddings und Vektorsuche 7 zurückgegebene Ergebnisse erfordern, während der klassische Keyword-Ansatz 8 Ergebnisse benötigt. Dieser kleine Genauigkeitsunterschied wurde als „unbedeutend“ beschrieben, wenn man die Kosten für den Betrieb einer Vektor-Datenbank und eines Embedding-Services berücksichtigt.

Anders gesagt: Eine gut abgestimmte Keyword-Suche kann einen großen Teil des Nutzens von Retrieval-Augmentierung liefern, ohne dass der Aufwand einer Vektor-Datenbank erforderlich ist.

Um das umzusetzen, kann aus dem User Prompt eine optimierte Suchanfrage erstellt werden – möglicherweise mit Unterstützung eines LLM, um die wichtigsten Begriffe zu extrahieren – und anschließend gegen eine Full-Text-Suchmaschine wie Elasticsearch oder einen SQL-Full-Text-Index ausgeführt werden.

image

Das LLM kann die so abgerufenen Texte anschließend als Kontext nutzen. Dieser Ansatz profitiert von dem starken Präzisionssignal lexikalischer Treffer, da die gefundenen Dokumente sehr wahrscheinlich die Suchbegriffe oder nahe Entsprechungen enthalten. In manchen Fällen kann dies relevanteren Kontext liefern als dichte Embeddings.

LLM-basierte iterative Suche (Reasoning als Retrieval)

Eine weitere embedding-freie RAG-Strategie besteht darin, das LLM selbst als Retrieval-Mechanismus über Reasoning und Inferenz zu nutzen. Statt Vektor-Ähnlichkeit zu bewerten, „fragt“ das System das LLM im Kern, wo die Antwort am wahrscheinlichsten zu finden ist. So könnte ein LLM-Agent beispielsweise eine Liste von Dokumenttiteln oder Zusammenfassungen erhalten und darüber nachdenken, welches Dokument am ehesten die Antwort enthält, um es anschließend gezielt abzurufen und zu prüfen.

Diese Idee bildet die Grundlage von Agent-based RAG: Ein LLM-Agent „nutzt“ Tools, um einen Dokumentkatalog anhand von Titel oder Metadaten zu durchsuchen, bevor eine detaillierte Analyse erfolgt.

In dieselbe Richtung geht ein Research-Framework namens ELITE (Embedding-Less Retrieval with Iterative Text Exploration), das einem LLM ermöglicht, relevante Textstellen iterativ einzugrenzen. ELITE verwendet ein eigenes Importance-Maß, um die Suche zu steuern.

image

Das Diagramm oben zeigt einen embedding-freien RAG-Loop. Die Nutzeranfrage wird an ein LLM gesendet, das Hinweise erzeugt, um einen Textausschnitt aus dem Korpus abzurufen. Dieser Ausschnitt wird anschließend mit einem Importance-Maß bewertet, um zu entscheiden, auf welches Textfenster als Nächstes fokussiert werden soll. Dieser neue, gezieltere Fokus wird dem LLM wieder zugeführt, und der Prozess wiederholt sich in einer Schleife, bis die Stoppbedingung erreicht ist und das System die finale Antwort zurückgibt.

Diese Methode nutzt das Sprachverständnis und die logische Schlussfolgerung des Modells, um Retrieval durchzuführen. Statt Retrieval an einen Embedding-Index auszulagern, übernimmt das LLM selbst das Identifizieren und schrittweise Verfeinern des Suchpfads.

Strukturiertes Wissen und graphbasiertes Retrieval

Anstatt eine Wissensbasis als unstrukturierte Text-Chunks in einem Vektorindex abzulegen, organisiert dieser Ansatz die Daten in einem Wissensgraphen oder einer anderen symbolischen Datenstruktur.

In einem graph-orientierten RAG werden Entitäten (zum Beispiel Personen, Orte oder Konzepte) als Knoten dargestellt, während Beziehungen als Kanten modelliert werden. Diese Strukturen werden aus dem Ausgangstext oder einer zugrunde liegenden Datenbank abgeleitet. Als Reaktion auf eine Nutzeranfrage ruft das System relevante Knoten ab und folgt den Kanten, um eine Sammlung von Fakten oder zusammenhängenden Informationen zusammenzustellen. Dieses strukturierte Ergebnis wird anschließend an das LLM übergeben.

Microsoft hat kürzlich GraphRAG vorgestellt, das „keeps the good bits of RAG but slips a knowledge graph between the indexer and the retriever“.

image

Bei GraphRAG werden nicht einfach nur „Chunks zurückgegeben, die ähnlich aussehen“ wie die Query. Stattdessen liefert der Retriever einen Subgraphen mit relevanten Entitäten und Beziehungen. Dadurch erhält das LLM eine strukturierte „Gedächtnispalast“-Darstellung, die abbildet, wie Fakten miteinander verbunden sind.

Das ist besonders wertvoll bei komplexen Fragen, die Multi-Hop-Reasoning oder das Zusammenführen von Fakten über verschiedene Quellen hinweg erfordern (zum Beispiel zu erkennen, dass Person A, die X getan hat, mit Person B verbunden ist, die an anderer Stelle erwähnt wird).

Einige GraphRAG-Implementierungen nutzen weiterhin Embeddings an bestimmten Stellen der Pipeline (etwa indem der Text des Kontextes eines Knotens eingebettet wird, um innerhalb der Nachbarschaft eine Ähnlichkeitssuche durchzuführen). Dennoch bleibt der Kernpunkt: Der Graph erzwingt eine symbolische, relationale Struktur, die in reiner Vektor-Suche fehlt.

Prompt-basiertes Retrieval (Embedding-freies Prompt RAG)

Ein weiterer, neu aufgekommener Forschungsstrang untersucht, ob sich Retrieval auch ohne explizite Vektoren über die Prompting-Fähigkeiten von LLMs umsetzen lässt. Ein Beispiel dafür ist Prompt-RAG, das in einem Paper aus dem Jahr 2024 für den Anwendungsbereich der koreanischen Medizin vorgestellt wurde.

Anstatt einen Vektorindex aufzubauen, erstellt Prompt-RAG aus den Dokumenten ein strukturiertes Inhaltsverzeichnis (Table of Contents, ToC). Das System fordert das LLM dann per Prompt dazu auf, jene Abschnitte (Überschriften) auszuwählen, die zur Anfrage passen.

image

Die Inhalte unter den ausgewählten Überschriften werden anschließend als Kontext zusammengeführt. Das LLM übernimmt dabei direkt die Aufgabe, die Anfrage zu interpretieren, die Dokumentstruktur zu verstehen und zu entscheiden, welche Inhalte abgerufen werden sollen. Embedding-Vektoren sind dafür nicht erforderlich. In dieser spezifischen Domäne konnte gezeigt werden, dass der Ansatz eine klassische embedding-basierte RAG-Variante übertrifft. Das deutet darauf hin, dass prompt-gesteuertes Retrieval eine starke Alternative sein kann, wenn Embeddings die Semantik einer Domäne nicht zuverlässig abbilden. RAG ohne Embeddings ersetzt den Vektorsuch-Schritt entweder durch klassische Information-Retrieval-Methoden oder durch LLM-getriebenes Reasoning. In gewisser Weise kehrt es den Trend der letzten Jahre um. Wir bewegen uns „zurück“ zu Symbolen und Text als Grundlage des Retrievals – jedoch unterstützt durch die stärkeren Reasoning-Fähigkeiten moderner LLMs.

Vorteile von embedding-freiem RAG

Warum sollte man diese Alternativen überhaupt in Betracht ziehen? Es gibt mehrere potenzielle Vorteile von RAG ohne Embeddings. Wenn wir an die zuvor beschriebenen Einschränkungen denken, lassen sich viele davon mit diesen anderen Techniken adressieren:

Wichtig ist: Diese Vorteile entstehen nicht automatisch. Alternative Methoden bringen oft andere Herausforderungen mit sich (zum Beispiel die Rechenkosten wiederholter LLM-Aufrufe oder den Engineering-Aufwand für Aufbau und Pflege eines Wissensgraphen). Dennoch kann der Verzicht auf eine Vektor-Datenbank viele der typischen Schwachstellen aktueller RAG-Systeme beseitigen.

Anwendungsfälle und Vergleiche

Wann sollte man eine embedding-freie RAG-Architektur der klassischen Vektor-Datenbank-Variante vorziehen? Das hängt von der Aufgabe, den Daten, den Rahmenbedingungen und vielen weiteren Faktoren ab. Im Folgenden einige Szenarien und wie sich die Ansätze jeweils gegenüberstehen:

Tipp: Viele Teams setzen auf Hybrid-Ansätze – zuerst schnelle lexikalische Filter, dann Vektorsuche, anschließend LLM Re-Ranking; für komplexe Multi-Hop- oder regulierte Queries wird auf Graph-/Agent-Retrieval zurückgegriffen

Zukunft von RAG-Architekturen

Werden embedding-freie Methoden Vektor-Datenbanken in RAG überholen oder ersetzen? Ein realistischeres Szenario ist Koexistenz und komplementäre Nutzung. Im Folgenden einige Trends und Prognosen, wohin sich RAG-Architekturen entwickeln könnten:

Vector DBs bleiben stark für semantische Ähnlichkeitssuche im großen Maßstab. Embedding-freie Methoden sind besser für Reasoning, Struktur und Interpretierbarkeit. Die Zukunft deutet auf hybride, adaptive Systeme hin, die jeden Ansatz dort einsetzen, wo er am besten passt.

FAQ SECTION

Warum setzt traditionelles RAG auf Embeddings und Vektor-Datenbanken?

Traditionelles RAG funktioniert so, dass Text-Chunks zunächst in einen Vektorraum eingebettet und diese Embeddings anschließend in einer Vektor-Datenbank gespeichert werden. Bei einer Anfrage wird auch die Nutzer-Query in denselben Vektorraum eingebettet und per Nearest-Neighbor-Suche abgefragt. Die abgerufenen Passagen werden dann als Kontext für die Beantwortung genutzt. Dadurch kann RAG Passagen finden, deren Bedeutung zur Query passt, selbst wenn die exakte Wortwahl abweicht.

Was sind die wichtigsten Grenzen von Embeddings und Vektorsuche in RAG?

Auch wenn Embeddings und Vektorsuche sehr nützlich sind, bringen sie weiterhin Einschränkungen mit sich. Sie leiden unter semantischen Lücken. Unter den abgerufenen Passagen ist oft nur ein Teil tatsächlich antworttragend, während viele nur thematisch ähnlich sind. Das reduziert die Retrieval-Genauigkeit, besonders in präzisionssensitiven Domänen wie Recht oder Healthcare. Vektorsuche ist außerdem eine Black Box, wodurch schwer nachvollziehbar ist, warum eine Passage abgerufen wurde. Zusätzlich verursachen Speicherung und Wartung von Embeddings und Vektor-Datenbanken hohe Infrastrukturkosten und Komplexität, einschließlich der Notwendigkeit, bei jeder Änderung eines Dokuments neu zu indexieren.

Wie funktioniert RAG ohne Embeddings und welche Vorteile bietet es?

RAG ohne Embeddings nutzt andere Retrieval-Mechanismen als Vektorsuche. Dazu zählen keyword-basiertes Retrieval, iterative LLM-gesteuerte Suche sowie graph- oder prompt-basiertes Retrieval. Diese Methoden können die Retrieval-Präzision erhöhen und den Indexierungs-Overhead senken. Außerdem können sie Compute-Kosten reduzieren und die Interpretierbarkeit verbessern. Embedding-freies RAG ist besonders vielversprechend in spezialisierten oder Low-Data-Domänen (Healthcare, Finance, Legal), in denen Embeddings häufig nicht in der Lage sind, domänenspezifische Semantik zuverlässig abzubilden.

Fazit

Embedding-freies RAG entwickelt sich zu einer wichtigen Alternative zu klassischen Vektor-Datenbank-Ansätzen. In vielen Situationen sind Embeddings und Vektorsuche weiterhin die beste Wahl für semantisches Retrieval im großen Maßstab. Gleichzeitig bringen sie jedoch Komplexität, Kosten und Genauigkeitsprobleme mit sich.

Im Gegensatz dazu sind Keyword-Suche, Wissensgraphen sowie LLM-basiertes Reasoning und Interpretation verbreitete embedding-freie RAG-Techniken. Sie können einfacher, schneller und besser nachvollziehbar sein.

Vektor-Datenbanken liefern schnelle semantische Ähnlichkeitssuche, stoßen jedoch bei Reasoning-lastigen und domänenspezifischen Problemen an Grenzen. In diesen Bereichen schneidet embedding-freies RAG oft besser ab. Hybride Systeme können die Stärken beider Ansätze kombinieren, um adaptive Pipelines zu bauen, die die Genauigkeit erhöhen, Latenz reduzieren und mehr Vertrauen schaffen.

Viele der hier beschriebenen Konzepte (wie ELITEs iteratives Retrieval oder GraphRAG) haben Open-Source-Implementierungen oder sind als Service verfügbar. Es ist möglich, diese Systeme auf den eigenen Daten auszuführen, um zu evaluieren, wie sie sich im Vergleich zu einem Vektorsuche-Baseline verhalten.