Vektordatenbank

Warum gibt es Vektordatenbanken?

Viele moderne KI-Anwendungen repräsentieren Inhalte als hochdimensionale Vektoren. Ein einzelnes Text-Embedding kann mehrere hundert oder tausend Zahlen enthalten. Sollen aus Millionen solcher Vektoren die ähnlichsten Kandidaten gefunden werden, reicht ein naiver Vergleich mit jedem Datensatz häufig nicht aus.

Vektordatenbanken beziehungsweise Datenbanksysteme mit Vektorunterstützung kombinieren Speicherung, Indexierung und Abfragefunktionen speziell für solche Ähnlichkeitssuchen.

Fachliche Grundlage: Vektorsuche ist älter als der aktuelle KI-Boom

Pan, Wang und Li geben 2024 im VLDB Journal einen Überblick über Vector Database Management Systems. Sie zeigen, dass embedding-basierte Anwendungen die Nachfrage stark beschleunigt haben, die zugrunde liegenden Probleme der Ähnlichkeitssuche und des Vektordatenmanagements aber deutlich älter sind.

Der Survey beschreibt mehrere systemische Herausforderungen: hochdimensionale Vektoren benötigen viel Speicher, Ähnlichkeitsvergleiche sind teuer, eine natürliche Partitionierung fehlt häufig und hybride Abfragen müssen Vektorkriterien mit klassischen Attributfiltern verbinden.

Wie funktioniert die Suche?

Eine Anfrage wird zunächst in denselben Vektorraum wie die gespeicherten Objekte eingebettet. Anschließend sucht das System nach den nächstgelegenen Vektoren. Exakte Nearest-Neighbor-Suche kann bei sehr großen Datenmengen aufwendig sein. Deshalb verwenden Systeme häufig Approximate Nearest Neighbor (ANN): Sie akzeptieren eine kontrollierte Näherung, um die Suche erheblich zu beschleunigen.

Die konkrete Indexstruktur beeinflusst Speicherbedarf, Latenz, Recall und Update-Verhalten. Deshalb gibt es nicht den einen „besten“ Index für jeden Anwendungsfall.

Was wird in einer Vektordatenbank gespeichert?

In der Praxis besteht ein Eintrag nicht nur aus dem Vektor. Typisch sind:

• Embedding-Vektor,
• eindeutige ID,
• Originaltext oder Referenz auf den Inhalt,
• Metadaten wie Dokumenttyp, Datum, Produkt oder Mandant,
• Berechtigungsinformationen beziehungsweise Filterattribute.

Gerade Metadaten sind für Unternehmensanwendungen wichtig. Ein semantisch passender Treffer darf beispielsweise nicht angezeigt werden, wenn der Nutzer keine Berechtigung für das zugrunde liegende Dokument besitzt.

Vektordatenbank und RAG

In RAG-Systemen wird häufig jeder relevante Chunk eines Dokumentbestands als Embedding gespeichert. Bei einer Nutzerfrage werden ähnliche Chunks gesucht und als Kontext an ein LLM übergeben. Die Vektordatenbank ist dabei lediglich eine Komponente der Retrieval-Pipeline.

Sie entscheidet nicht selbst, ob ein Dokument fachlich korrekt, aktuell oder für den Nutzer zulässig ist. Ebenso erzeugt sie nicht die Embeddings. Die Gesamtqualität entsteht aus Dokumentaufbereitung, Embedding-Modell, Index, Filtern, Retrieval-Strategie, Re-Ranking und Generierung.

Native Vektordatenbank oder bestehende Datenbank erweitern?

Unternehmen müssen nicht automatisch ein zusätzliches Spezialprodukt einführen. Der VLDB-Survey unterscheidet native Vektorsysteme und bestehende Datenbanksysteme, die Vektorfunktionen ergänzen. Welche Variante sinnvoll ist, hängt unter anderem von Datenvolumen, Abfragemustern, bestehender Infrastruktur, Betriebsanforderungen und Skalierung ab.

Für ein kleines internes RAG-System kann ein vorhandenes relationales System mit Vektorunterstützung ausreichend sein. Bei sehr großen Datenmengen oder hohen Durchsatzanforderungen können spezialisierte Systeme Vorteile bieten.

Wichtige Auswahlkriterien

• Recall und Latenz: Wie zuverlässig werden relevante Nachbarn bei gewünschter Geschwindigkeit gefunden?
• Filter: Können Vektor- und Metadatenfilter effizient kombiniert werden?
• Mandantentrennung und Rechte: Wie werden Zugriffsgrenzen umgesetzt?
• Updates: Wie schnell können neue oder geänderte Daten berücksichtigt werden?
• Betrieb: Backup, Monitoring, Hochverfügbarkeit und Kosten.
• Ökosystem: Integration in vorhandene Entwicklungs- und Datenplattformen.

Ein häufiger Denkfehler

„Wir brauchen RAG, also brauchen wir eine Vektordatenbank“ ist zu kurz gedacht. Je nach Daten und Suchintention kann klassische Volltextsuche, BM25, eine relationale Abfrage oder Hybrid Search geeigneter oder ergänzend notwendig sein. Produktcodes, exakte Namen oder IDs sind beispielsweise oft lexikalisch leichter zu treffen als semantisch.

Was sollte vor der Einführung geklärt werden?

Vor der Produktauswahl sollte das Retrieval-Szenario messbar sein: Wie viele Vektoren entstehen? Wie oft ändern sich Dokumente? Müssen Ergebnisse innerhalb weniger Millisekunden vorliegen? Welche Metadatenfilter und Mandantengrenzen sind notwendig? Muss die Infrastruktur On-Premises betrieben werden?

Erst danach lässt sich beurteilen, ob eine zusätzliche spezialisierte Vektordatenbank sinnvoll ist oder ob vorhandene Infrastruktur genügt. Diese Reihenfolge verhindert, dass ein neues Datenbanksystem allein aufgrund eines KI-Prototyps dauerhaft in die Architektur aufgenommen wird.

Fazit

Vektordatenbanken lösen ein konkretes Infrastrukturproblem: hochdimensionale Repräsentationen performant speichern und nach Ähnlichkeit durchsuchen. Sie sind ein wichtiger Baustein moderner KI- und Suchsysteme, aber kein Qualitätsgarant. Eine gute Architektur wählt Datenbank und Index passend zur tatsächlichen Suchaufgabe – nicht zum aktuellen Technologietrend.