Vector DB
Eine Vector DB speichert Daten als Embeddings — Zahlenlisten, die Bedeutung erfassen — und findet die ähnlichsten Einträge zu einer Anfrage über mathematische Distanz statt über exakte Stichwortübereinstimmung. Sie ist die Abruf-Engine hinter den meisten RAG-Systemen und hinter semantischer Suche.
Klassische Datenbanken gleichen exakte Werte ab; eine Vector DB gleicht Bedeutung ab. Sie wandeln Text, Bilder oder andere Inhalte in Embeddings um, speichern sie, wandeln zur Laufzeit auch die Frage in ein Embedding um und liefern die nächsten Nachbarn. So findet eine Suche nach «wie bekomme ich eine Rückerstattung» einen Abschnitt mit dem Titel «Rückgaberichtlinie», selbst ohne gemeinsame Wörter. Sie ist die Speicher- und Suchschicht, die RAG und semantische Suche in der Breite praktikabel macht.
Beim Bau eines Produkts ist die Vector DB ein Teil der Pipeline, nicht das Ganze — ihre Qualität hängt vom gewählten Embedding-Modell, vom Chunking und oft von einem Reranking-Schritt obendrauf ab. Eine dedizierte Vector DB gegen eine Vektor-Erweiterung einer ohnehin betriebenen Datenbank ist eine echte Abwägung: Betriebseinfachheit schlägt oft die reine Benchmark-Geschwindigkeit. Wir wählen nach Datenvolumen und übrigem Stack, nicht nach Hype.
// faq
Häufige Fragen
- Brauche ich für RAG immer eine dedizierte Vector DB?
- Nein. Für kleine bis mittlere Datenmengen ist eine Vektor-Erweiterung einer ohnehin betriebenen Datenbank (oder sogar ein In-Memory-Index) oft einfacher und schnell genug. Eine dedizierte Vector DB lohnt sich bei großem Maßstab, viel Filterung und hohem Anfragevolumen. Entscheiden Sie zuerst nach Betriebseinfachheit; Embedding-Modell und Chunking beeinflussen die Antwortqualität weit mehr als der gewählte Speicher.