Vector Database erklärt: Warum RAG ohne gute Suche scheitert

Eine Vector Database ist im RAG-System kein schneller Speicher für Embeddings. Sie entscheidet, welche Textstellen ein Sprachmodell überhaupt sieht. Unser Pillar-Artikel zu RAG beschreibt, warum der Retrieval-Teil der schwierigere ist. Hier geht es weiter: Warum simple Vektorsuche oft nicht genügt, wo Naive RAG zusammenbricht und welche Datenbank-Wahl über Produktreife oder ewigen Proof-of-Concept entscheidet.

Die Architektur: Was eine Vector Database im RAG-System leistet

Die heutige RAG-Architektur trennt zwei Dinge sauber: das parametrische Wissen des Sprachmodells und eine externe Wissensbasis im Vektorindex. Der Vorteil dieser Trennung: Die Wissensbasis lässt sich austauschen, ohne das gesamte Modell neu zu trainieren.

Die Pipeline besteht aus drei Phasen:

Indexing: Dokumente werden in Chunks zerlegt, in Embeddings (hochdimensionale Vektoren) umgewandelt und in der Vektordatenbank gespeichert. Jeder Chunk repräsentiert einen semantischen Ausschnitt.

Retrieval: Eine Nutzeranfrage wird ebenfalls in einen Vektor umgewandelt. Die Datenbank sucht die ähnlichsten Vektoren mittels Approximate Nearest Neighbor (ANN). Vereinfacht: Sie prüft nicht jeden gespeicherten Vektor exakt gegen jeden anderen. Sie nutzt einen Index, der sehr schnell gute Näherungstreffer findet. Das Ergebnis: eine Handvoll Chunks, die als Kontext ans LLM gehen.

Generation: Das LLM beantwortet die Frage unter Einbeziehung dieser Chunks. Wenn der Retriever gute Arbeit geleistet hat. Wenn nicht, ist das Modell auf sich allein gestellt.

Wo Naive RAG scheitert

Das grösste Qualitätsproblem liegt meist in der Retrieval-Phase, nicht im Sprachmodell. Naive RAG versagt auf drei Ebenen:

Falsche Chunks (Low Precision): Der Retriever holt Passagen, die semantisch ähnlich klingen, aber die eigentliche Frage nicht beantworten. Das LLM konstruiert daraus eine Antwort und produziert plausibel klingende Halluzinationen.

Fehlende Chunks (Low Recall): Die relevante Information existiert im Korpus, wird aber nicht gefunden, weil sie sprachlich anders formuliert ist als die Anfrage. Lexikalische Ähnlichkeit greift hier nicht. Embedding-Ähnlichkeit auch nicht immer.

Retrieval Collapse: Besonders heimtückisch. Wenn der Retriever unabhängig von der Eingabe immer dieselben populären Dokumente zurückgibt, fällt das RAG-System faktisch auf ein normales LLM ohne Kontextbindung zurück. Die Vektordatenbank ist technisch aktiv, leistet inhaltlich aber nichts.

Dazu kommt: Nicht jedes scheinbar passende Dokument hilft dem Modell. Ein thematisch naher, aber inhaltlich falscher Chunk kann den Prompt stärker vergiften als ein offensichtlich irrelevanter Treffer. Klassische Suchqualität reicht deshalb nicht. Retrieval muss für RAG separat evaluiert werden.

Was produktionsreife Systeme anders machen

Produktionsreife RAG-Systeme setzen an jeder dieser Schwächen an:

Hybrid Search: Kombination aus Vektorsimilarität und lexikalischer Suche. Das fängt Präzisionslücken ab, die reines Embedding-Retrieval offen lässt. Relevante Begriffe, Produktnamen oder Paragrafen gehen nicht verloren.

Chunking-Strategie: Starre Chunkgrössen sind ein Ausgangspunkt, kein Optimum. Sliding Windows mit Überlappung, semantisches Chunking nach Absätzen oder hierarchisches Chunking liefern je nach Dokumenttyp bessere Ergebnisse. Ein universelles Rezept gibt es nicht.

Re-Ranking: Nach dem ersten Retrieval-Pass bewertet ein separates Cross-Encoder-Modell die Chunks neu. Der Cross-Encoder berechnet Relevanz für jedes Chunk-Query-Paar einzeln. Das ist teurer als ANN, aber deutlich präziser. Nur die gefilterten Top-k-Ergebnisse landen im LLM-Kontext.

Metadatenfilter: Chunks werden beim Indexing mit strukturierten Metadaten angereichert (Datum, Dokumenttyp, Abteilung, Sprache). Der Retrieval-Query filtert diese Attribute vor der Vektorsuche. Das hilft bei heterogenen Korpora und verhindert, dass ein veraltetes Dokument einen aktuellen Chunk verdrängt.

Query-Optimierung: HyDE (Hypothetical Document Embeddings) generiert erst eine hypothetische Antwort und sucht dann nach Vektoren, die dieser ähneln. Der kurze Nutzer-Query wird nicht direkt vektorisiert. Das kompensiert die semantische Asymmetrie zwischen kurzer Anfrage und langen Dokumentpassagen.

Wie Retrieval-Qualität gemessen werden sollte

Ein produktives RAG-System braucht zwei getrennte Messungen: Retrieval-Qualität und Antwortqualität. Wer nur die finale Antwort bewertet, sieht nicht, ob das LLM gut argumentiert oder ob der Retriever zufällig brauchbaren Kontext geliefert hat. Derselbe Fehler wie bei KI-Halluzinationen: Das Symptom liegt im Text, die Ursache vorher in der Pipeline.

Für Retrieval zählen andere Fragen. Findet das System die relevante Passage überhaupt? Liegt sie unter den ersten fünf Treffern oder irgendwo auf Platz 37? Kommen mehrere fast identische Chunks zurück, obwohl unterschiedliche Belege nötig wären? Typische Metriken sind Recall@k, MRR und NDCG. Sie sind nicht perfekt, aber sie zwingen Teams, den Suchteil messbar zu machen.

Zusätzlich braucht es ein Goldset: echte Nutzerfragen, erwartete Dokumentstellen und Beispiele für schwierige Fälle. Kurze Fragen mit Fachabkürzungen, mehrdeutige Formulierungen, alte und neue Dokumentversionen, unterschiedliche Sprachen und Fälle, in denen Metadatenfilter zwingend greifen müssen. Erst dann zeigt sich, ob Chunking, Embedding-Modell, Hybrid Search, Re-Ranking und Datenbankwahl zusammen funktionieren.

Der wichtigste Betriebsindikator ist Stabilität über Query-Klassen hinweg. Wenn der Retriever bei einfachen Fragen glänzt, aber bei regulatorischen, technischen oder mehrsprachigen Fragen kollabiert, ist das System nicht produktionsreif. Eine Vector Database kann nur so gut sein wie die Evaluierung, die ihre Trefferqualität sichtbar macht.

Die Vektordatenbank-Wahl: Kein rein technisches Problem

Die Datenbankwahl ist nicht akademisch. Sie bestimmt Betriebskosten, Skalierungsgrenzen, Datenschutzarchitektur und Wartungsaufwand. Die richtige Frage lautet nicht: Welche Vektordatenbank ist objektiv die beste? Sondern: Welche Retrieval-Architektur passt zum realen Korpus, zum Team und zu den Betriebsanforderungen?

pgvector (PostgreSQL-Extension): Für Teams mit vorhandener PostgreSQL-Infrastruktur ist pgvector oft der pragmatischste Einstieg. Nicht weil pgvector jede spezialisierte Vektordatenbank schlägt. Sondern weil Postgres ohnehin betrieben wird und pgvector den ersten produktiven RAG-Ausbau vereinfachen kann. Latenz, Filterlogik und Skalierung müssen trotzdem am eigenen Korpus gemessen werden.

Qdrant (Rust-basiert): Qdrant wird dann interessant, wenn Metadatenfilter zur Kernanforderung werden. Gefilterte ANN-Suche ist schwieriger als reine Vektorsuche: Wer erst nach der Suche filtert, verliert relevante Treffer; wer zu stark vorfiltert, riskiert Skalierungs- und Genauigkeitsprobleme. Für mandantenfähige Systeme, Compliance-Zonen oder grosse Dokumentkorpora mit vielen Attributen ist das ein Architekturpunkt, nicht nur ein Performance-Detail.

Milvus: Milvus gehört in grösseren Setups auf die Shortlist. Die Stärke liegt in Skalierung, Multi-Vector-Suche, Filtern und dem Betrieb grosser Vektorbestände. Für Teams, die eine dedizierte Vektordatenbank selbst oder über Zilliz betreiben wollen, ist Milvus oft näher am Enterprise-Betrieb als an einem einfachen Entwickler-Tool. Der Preis dafür: mehr Architekturarbeit, mehr Betriebsverantwortung und weniger Plug-and-play als bei reinen Managed-Angeboten.

Pinecone: Pinecone ist primär als Managed Service positioniert. Der Vorteil liegt weniger in einem einzelnen Algorithmusversprechen als im Betriebsmodell: keine eigene Datenbankadministration, Cloud-Konsole, Skalierung über Service- und Verbrauchsmodelle. Das ist für Teams ohne Datenbankbetrieb attraktiv, verlangt aber Kostenmodellierung vor dem Rollout. Pinecone ist damit eine bewusste Outsourcing-Entscheidung mit Anbieterbindung, keine rein technische Geschmacksfrage.

Weaviate: Weaviate liegt zwischen Entwicklerfreundlichkeit und Sucharchitektur. Es kann managed oder selbst betrieben werden und bringt Hybrid Search direkt als Produktmuster mit: Vektorsuche plus BM25F, gewichtet über einen gemeinsamen Suchpfad. Der Unterschied zu Pinecone liegt weniger im Managed-Versprechen, sondern in der stärker sichtbaren Suchmodellierung. Der Unterschied zu Qdrant liegt weniger bei Filtern, sondern bei der hybriden Suchlogik als Kernfeature.

Elasticsearch/OpenSearch: Für viele Teams ist das der naheliegendste Hybrid-Pfad. Wenn Elasticsearch oder OpenSearch bereits als Suchinfrastruktur läuft, kann dense_vector beziehungsweise Vector Search eine pragmatische Brücke sein: klassische Volltextsuche, Filter, Rechte- und Indexlogik bleiben im bestehenden Stack, semantische Suche kommt dazu. Das ist nicht automatisch die beste Vektordatenbank. Aber es ist oft der kürzeste Weg zu Hybrid Search, ohne eine zweite Retrieval-Infrastruktur aufzubauen.

Die Entscheidung zwischen pgvector, Qdrant, Milvus, Pinecone, Weaviate und Elasticsearch/OpenSearch wird für viele DACH-Unternehmen zur Infrastruktur-Lock-in-Frage. Einmal integrierte RAG-Systeme migriert kaum jemand. Eine frühe, undurchdachte Entscheidung zieht sich durch den gesamten Lebenszyklus.

Antipatterns & Systemische Risiken

"Wir haben eine Vektordatenbank, also läuft RAG gut." Die Datenbank ist das Speichermedium, nicht die Retrieval-Qualität. Top-K-Retrieval aus einem schlecht gechunkten Korpus mit generischen Embeddings liefert schlechte Ergebnisse, egal ob die DB pgvector, Qdrant oder Pinecone heisst.

Retrieval nie isoliert evaluiert. Der häufigste Fehler: Teams evaluieren End-to-End (Frage → Antwort) und machen das Qualitätsproblem unlokalisierbar. Retrieval muss separat bewertet werden, mit eigenen Metriken (Recall@k, MRR, NDCG), nicht nur über LLM-Output-Qualität.

Embedding-Modell als Nachgedanke. Das Embedding-Modell bestimmt die semantische Trennschärfe des Vektorraums. Ein generisches Modell, das nicht auf den Dokumententyp (juristisch, technisch, medizinisch) abgestimmt ist, produziert schwache Vektoren. Keine Datenbankwahl kompensiert das.

Metadaten nicht beim Indexing definiert. Nachträgliches Re-Indexing grosser Korpora ist kostspielig. Wer die Metadatenstruktur am Anfang nicht durchdenkt, baut einen Retriever, der nicht sauber filtert und auf einen Korridor schlechter Ergebnisse festgelegt ist.

Die praktische Konsequenz: Eine Vektordatenbank sollte nicht nach Logo, Benchmark-Grafik oder Cloud-Bequemlichkeit ausgewählt werden. Entscheidend ist das eigene Lastprofil: Wie viele Dokumente liegen vor? Wie stark wird gefiltert? Wie oft ändern sich Inhalte? Wie teuer ist ein falscher Treffer? Erst diese Fragen machen aus einer Tool-Auswahl eine belastbare Architekturentscheidung.