Vector Database für RAG: Wann SQLite, pgvector oder ein Spezialdienst passt

Für das redaktionelle Retrieval von AISyndicate hätte ich früh eine spezialisierte Vector Database für RAG wählen können. Stattdessen musste zuerst die einfachere Architektur gegen echte Fragen bestehen: ein lokales Embedding-Modell, SQLite und eine kleine Vektorerweiterung. Der Test zeigte keinen belegten Engpass, den ein zusätzlicher Datenbankdienst gelöst hätte. Damit wurde Weglassen zur technischen Entscheidung, nicht zum Provisorium.

Eine Vector Database kann für RAG sehr nützlich sein. Sie ist aber weder die Definition von RAG noch automatisch dessen Herzstück. Entscheidend ist, welche Suche der Korpus braucht, wie stark gefiltert wird, wie häufig Inhalte wechseln und welche Last tatsächlich entsteht. Wer diese Fragen vor der Produktauswahl beantwortet, entdeckt oft eine einfachere Architektur.

Die Kurzentscheidung: Braucht RAG eine Vector Database?

Keine Vektorsuche ist nötig, wenn exakte Begriffe, Dokumentnummern, Produktcodes oder strukturierte Felder dominieren. Volltextsuche, SQL und Metadatenfilter sind dafür häufig präziser und leichter erklärbar. Auch ein kleiner, bereits ausgewählter Dokumentbestand kann direkt in ein ausreichend grosses Kontextfenster passen.

Eine eingebettete Lösung wie SQLite plus sqlite-vec passt zu einem kontrollierten Korpus, geringer Parallelität und einem System, das als einzelne Einheit gesichert und verschoben werden soll. Der Vorteil ist nicht magische Suchqualität, sondern wenig zusätzliche Infrastruktur.

pgvector wird interessant, wenn PostgreSQL bereits Daten, Rechte und Metadaten trägt. Vektoren bleiben dann nahe an den Datensätzen, Transaktionen und Filtern. Das vermeidet ein zweites Datenbanksystem, verlangt aber weiterhin Messungen zu Index, Filterselektivität und Last.

Ein bestehender Elastic- oder OpenSearch-Index ist plausibel, wenn Volltextsuche, Rechtefilter und Betrieb dort schon gelöst sind. Semantische Suche ergänzt dann eine vorhandene Retrieval-Schicht. Ein dedizierter Vector-Service lohnt sich erst, wenn Grössenordnung, Parallelität, Mandantentrennung, Filter oder Betriebsmodell den zusätzlichen Dienst rechtfertigen. Eine universelle Zeilen- oder Vektorgrenze gibt es dafür nicht.

Vektorsuche und Vector Database sind zwei verschiedene Dinge

Embeddings übersetzen Text, Bilder oder andere Daten in Zahlenvektoren. Ähnliche Inhalte sollen in diesem Raum näher beieinanderliegen. Bei einer Anfrage erzeugt dasselbe Modell einen Query-Vektor; die Suche ordnet gespeicherte Vektoren nach einer Distanzfunktion. Das ist Vektorsuche.

Eine Vector Database verpackt diese Suche in Speicher, Indizes, Filter, Aktualisierung, Replikation, Zugriff und APIs. Diese Produktmerkmale können wichtig sein, erzeugen aber keine Relevanz aus sich heraus. Ein schlechtes Embedding-Modell, unpassendes Query-Instruct oder fehlerhaftes Chunking bleibt auch in einer skalierbaren Datenbank schlecht.

Für kleine Bestände kann eine exakte Suche jeden Vektor vergleichen. Mit wachsendem Bestand werden ungefähre Nearest-Neighbor-Indizes attraktiv. Die pgvector-Dokumentation beschreibt den Tausch offen: HNSW und IVFFlat beschleunigen Abfragen, können gegenüber exakter Suche aber Recall verlieren. HNSW benötigt typischerweise mehr Speicher und Bauzeit; IVFFlat hängt stärker von Listen- und Probe-Einstellungen ab. Das sind Startpunkte für Messungen, keine allgemeine Rangliste.

Die Architekturleiter: von FTS bis Spezialdienst

Die einfachste Stufe ist klassische Volltextsuche. Sie ist stark bei Eigennamen, Aktenzeichen, Fehlermeldungen und seltenen Fachbegriffen. Semantische Ähnlichkeit kann solche exakten Signale verwässern. Deshalb sollte eine Vector Database nie gegen eine absichtlich schwache Stichwort-Baseline gewinnen dürfen.

SQLite plus sqlite-vec fügt einer portablen Datenbank Vektoroperationen hinzu. Das passt zu lokalen Anwendungen, redaktionellen Korpora und Edge-Systemen mit begrenzter Gleichzeitigkeit. Die Grenzen gehören zur Entscheidung: komplexe Join- und Filterpläne sind nicht mit einem ausgewachsenen Datenbanksystem gleichzusetzen, und grosse verteilte Last ist nicht das Ziel dieser Architektur.

PostgreSQL plus pgvector verbindet relationale Daten, Metadaten und Vektorsuche. Exakte Suche ist möglich; für ungefähre Suche stehen HNSW und IVFFlat bereit. Besonders wichtig ist das Zusammenspiel mit Filtern. Bei einem ANN-Index kann ein nachgelagerter Filter zu weniger Treffern führen als erwartet. Partielle Indizes, Partitionierung oder iterative Scans können helfen, müssen aber gegen reale Prädikate getestet werden.

Bestehende Suchsysteme bilden die nächste Stufe. Elastic beschreibt Hybrid Search als gemeinsame Abfrage aus Volltext- und Vektorsuche; Reciprocal Rank Fusion führt getrennte Ranglisten zusammen. OpenSearch unterstützt zusätzlich scorebasierte Normalisierung und rangbasierte Fusion in Suchpipelines. Das ist sinnvoll, wenn exakte und semantische Treffer beide zählen. Es ist keine Garantie, dass Hybrid Search immer gewinnt: Gewichtung, Kandidatenzahl und Query-Klassen bleiben Teil des Goldsets.

Erst danach folgt der Spezialdienst. Er kann horizontale Skalierung, verwalteten Betrieb, Replikation, Namespaces oder komplexe Filter vereinfachen. Dafür entstehen ein zusätzlicher Datenpfad, neue Kostenlogik und Exit-Arbeit. Massgeblich ist, welche Stufe die gemessenen Anforderungen mit dem kleinsten tragfähigen Betriebsmodell erfüllt, nicht welches Logo den besten Benchmark zeigt.

Retrieval-Qualität entsteht vor der Datenbankwahl

Chunking bestimmt, was überhaupt als Treffer zurückkommen kann. Zu kleine Abschnitte verlieren Voraussetzungen und Ausnahmen; zu grosse Abschnitte bringen irrelevanten Text in den Modellkontext. Dokumenttypen brauchen unterschiedliche Schnitte. Ein Vertrag, eine API-Dokumentation und ein Ticketsystem lassen sich nicht sinnvoll mit derselben starren Zeichenzahl behandeln.

Das Embedding-Modell definiert den Suchraum. Sprache, Fachdomäne und der Vertrag zwischen Query- und Passage-Format beeinflussen die Ergebnisse. Ein Modellwechsel verlangt deshalb eine Neuindexierung und einen erneuten Test. Eine Modellkarte oder ein öffentlicher Benchmark ersetzt diese Prüfung nicht. BEIR zeigte bereits, wie stark Retriever über Aufgaben und Domänen variieren. Die Qwen-Modellübersicht ordnet Embedding- und Reranker-Modelle getrennt von Chatmodellen ein.

Hybrid Search schützt vor der falschen Annahme, semantische Ähnlichkeit könne jedes exakte Signal ersetzen. Metadatenfilter schützen vor falscher Version, Sprache, Rechtsordnung oder Berechtigungszone. Ein Re-Ranker kann die erste Kandidatenliste verbessern, kostet aber Latenz und kann auf dem eigenen Korpus sogar schaden. Jede zusätzliche Stufe muss gegen die einfachere Pipeline gewinnen.

Wenn sehr verschiedene Anfragen immer dieselben populären Dokumente zurückgeben, ist das ein messbares Warnsignal. Dafür braucht es keinen grossen Namen wie «Retrieval Collapse». Relevant sind die Überlappung der Top-k-Listen, die fehlenden erwarteten Belege und die Query-Klassen, in denen der Retriever seine Unterscheidungskraft verliert.

Vier Fehlerbilder sollten getrennt sichtbar werden. Erstens kann die relevante Passage fehlen, obwohl das Dokument im Korpus liegt. Zweitens kann sie gefunden, aber hinter vielen ähnlichen Treffern verborgen werden. Drittens kann ein Filter die richtigen Kandidaten ausschliessen oder nach einer ungefähren Suche zu wenige Ergebnisse übrig lassen. Viertens kann die Trefferliste gut sein, während das Sprachmodell den Beleg später ignoriert. Nur die ersten drei Fehler sprechen unmittelbar über Retrieval und Datenbankarchitektur.

Auch Aktualisierung ist mehr als ein erfolgreicher Schreibvorgang. Gelöschte, ersetzte und neu berechtigte Dokumente müssen im Suchindex denselben Zustand besitzen wie in der Quelle. Ein schneller ANN-Index mit veralteten Chunks ist betrieblich falsch, selbst wenn seine Recall-Werte auf einem alten Testset gut aussehen. Deshalb gehören Löschpfad, Re-Indexierung und Rechtefilter in denselben Abnahmetest wie Latenz und Relevanz.

Fallstudie: Warum AISyndicate bei SQLite blieb

Das redaktionelle Retrieval von AISyndicate verwendet lokal Qwen3-Embedding-4B mit 2’560 Dimensionen. Die Vektoren und Dokumentmetadaten liegen in SQLite; sqlite-vec übernimmt die Vektorsuche. Für Embeddings existiert im Abfragepfad kein Cloud-Fallback. Diese Eigenschaft trägt die Architekturentscheidung direkt: Ein Ausfall darf nicht stillschweigend einen neuen externen Datenweg öffnen.

Diese Architektur ist keine Vorlage für jedes RAG-System. Sie passt zum aktuellen, kontrollierten redaktionellen Korpus und seinem Lastprofil. Der relevante Befund ist die Entscheidungsfolge: zuerst ein Goldset aus echten Fragen, dann Embedding-Vertrag und Retrieval messen, erst danach Infrastruktur erweitern. Eine dedizierte Vector Database hätte derzeit zusätzlichen Betrieb geschaffen, ohne einen belegten Qualitätsgewinn zu lösen.

Ein getesteter lokaler Re-Ranker wurde ebenfalls nicht übernommen. Er ordnete eine eingefrorene Top-20-Kandidatenliste des hybriden Retrievers neu. Auf 39 positiven Goldfragen sank Recall@5 von 94,9 auf 89,7 Prozent, MRR von 0,868 auf 0,849 und nDCG@5 leicht von 0,728 auf 0,725. Das ist eine Eigenmessung dieser Pipeline und kein Urteil über Re-Ranker als Klasse. Sie zeigt, warum ein zusätzlicher Modellschritt eine Hypothese ist und keine automatische Verbesserung.

Goldset statt Bauchgefühl

Ein Retrieval-Goldset besteht aus echten Nutzerfragen und erwarteten Belegstellen. Es enthält leichte, mehrdeutige und absichtlich schwierige Fälle: Abkürzungen, Versionskonflikte, exakte Nummern, mehrsprachige Formulierungen und Fragen ohne Beleg. Erst damit lässt sich eine Architektur vergleichen.

Recall@k beantwortet, ob ein relevanter Treffer unter den ersten k Ergebnissen liegt. MRR gewichtet, wie früh der erste relevante Treffer erscheint. NDCG kann abgestufte Relevanz und Rangfolge berücksichtigen. Keine dieser Metriken erklärt allein die spätere Antwortqualität. Sie lokalisiert aber, ob ein Fehler bereits vor dem Sprachmodell entsteht.

Verglichen werden sollte stufenweise: Volltextsuche, Vektorsuche, Hybrid Search, Filter und danach optional Re-Ranking. Jede Stufe erhält dieselben Fragen und denselben Korpusstand. Zusätzlich werden Latenz, Indexzeit, Aktualisierung und Betrieb erfasst. So wird sichtbar, ob ein Spezialdienst ein echtes Problem löst oder nur eine weitere Komponente verwaltet.

Der breite Grundlagenartikel RAG mit eigenen Dokumenten behandelt Dokumentqualität, Rechte, Zitierbarkeit und die Entscheidung, ob RAG überhaupt nötig ist. Dieser DeepDive beginnt bewusst eine Ebene später: bei der gemessenen Sucharchitektur.

Migration und Exit gehören zum Design

Embeddings sind an Modell, Dimension und Normalisierung gebunden. Ein Wechsel kann bedeuten, den gesamten Korpus neu zu berechnen. Metadaten, Chunk-IDs und Quellverweise sollten deshalb unabhängig vom Datenbankprodukt exportierbar bleiben. Sonst wird ein Retrieval-Experiment zum Lock-in.

Für einen Wechsel braucht es ein reproduzierbares Goldset, einen eingefrorenen Korpusstand und parallele Messungen. Erst wenn die neue Architektur relevante Qualität, Latenz oder Betriebskosten verbessert, wird umgestellt. Ein erfolgreiches Health-Check-Signal oder eine schnelle Demo beweist noch keine semantische Gleichwertigkeit.

Fazit

Eine Vector Database für RAG ist eine Architekturentscheidung, kein Pflichtkauf. Volltextsuche genügt für viele exakte Aufgaben. SQLite/sqlite-vec passt zu kompakten lokalen Systemen, pgvector zu Postgres-nahen Daten und Filtern, ein bestehender Suchindex zu hybriden Beständen. Ein Spezialdienst beginnt dort, wo Last, Verteilung oder Betriebsanforderungen seinen zusätzlichen Datenpfad rechtfertigen.

Die Reihenfolge bleibt schlicht: Korpus und Query-Klassen definieren, eine einfache Baseline bauen, Retrieval getrennt messen und erst dann skalieren. Wer so vorgeht, wählt keine Datenbank nach Versprechen. Er wählt sie nach einem nachweisbaren Engpass.