Vector Database

Eine Vector Database (deutsch Vektordatenbank) ist ein Datenbanksystem, das auf die Suche nach ähnlichen Vektoren ausgelegt ist. Statt einen exakten Wert nachzuschlagen, beantwortet sie die Frage, welche gespeicherten Vektoren einem gegebenen am nächsten liegen.

Zusammenfassung

Die Aufgabe klingt einfach und ist es in kleinen Beständen auch: Man rechnet jeden Abstand aus und wählt die kleinsten. Bei Millionen von Vektoren mit je tausend Dimensionen ist dieser Weg zu langsam.

Die Lösung ist ein Tausch. Näherungsverfahren geben die Garantie auf, die tatsächlich nächsten Nachbarn zu finden, und liefern dafür sehr schnell sehr wahrscheinlich richtige Ergebnisse. Übliche Systeme finden über 95 Prozent der wahren Nachbarn in einem Bruchteil der Zeit.

Bekannt wurde die Kategorie mit Retrieval-Augmented Generation ab 2023. Der Bedarf, große Dokumentenbestände für Sprachmodelle durchsuchbar zu machen, brachte eigene Anbieter hervor.

Ob es sich um eine eigene Produktkategorie handelt, ist umstritten. Etablierte Datenbanken haben die Fähigkeit inzwischen als Erweiterung nachgerüstet.

Begriffsgeschichte

Die Suche nach nächsten Nachbarn ist ein klassisches Problem der Informatik. Für wenige Dimensionen gibt es seit den 1970er Jahren wirksame Baumverfahren.

Diese Verfahren versagen bei hohen Dimensionszahlen. Der Grund ist ein Effekt, der als Fluch der Dimensionalität bekannt ist: Ab einigen Dutzend Dimensionen unterscheiden sich die Abstände zwischen zufälligen Punkten kaum noch, und jede Aufteilung des Raums verliert ihren Nutzen.

Daraus folgte die Wende zur Näherung. Ab den 2000er Jahren entstanden Verfahren, die schnelle, aber nicht garantiert vollständige Antworten liefern – zunächst über Verfahren, die ähnliche Punkte absichtlich auf dieselben Behälter abbilden.

2016 beschrieben Juri Malkow und Dmitri Jaschunin mit HNSW ein Verfahren, das die Vektoren in einem mehrstufigen Nachbarschaftsgraphen anordnet. Es gilt seither als Standard und liegt den meisten heutigen Systemen zugrunde.

Praktische Verbreitung fand die Technik zunächst als Bibliothek. FAISS, 2017 bei Facebook AI Research entstanden, machte die Suche auf Beschleunigern verfügbar. Eigenständige Datenbankprodukte folgten ab etwa 2019, die breite Aufmerksamkeit erst mit den Sprachmodellen.

Methodische Grundlagen

Der mehrstufige Nachbarschaftsgraph. Die Vektoren werden zu einem Graphen verbunden, in dem obere Ebenen weite Sprünge und untere Ebenen feine Schritte erlauben. Die Suche beginnt oben und steigt ab – vergleichbar mit einem Register, das von grob nach fein führt.

Verdichtung der Vektoren. Um Speicher zu sparen, werden Vektoren in Abschnitte zerlegt und jeder Abschnitt durch einen Stellvertreter ersetzt. Das verringert den Bedarf erheblich, kostet aber Genauigkeit.

Abstandsmaß. Üblich sind Kosinusähnlichkeit, euklidischer Abstand und Skalarprodukt. Welches Maß richtig ist, bestimmt das Embedding-Modell und nicht die Datenbank – eine häufige Fehlerquelle bei der Einrichtung.

Kombinierte Suche. In der Praxis wird die Vektorsuche mit klassischer Stichwortsuche verbunden, weil beide unterschiedliche Fehler machen. Exakte Bezeichner, Namen und Fachbegriffe findet die Stichwortsuche zuverlässiger.

Filter neben der Ähnlichkeit. Anfragen verlangen oft Einschränkungen – nach Datum, Zugriffsrecht, Quelle. Filter und Näherungssuche sauber zu verbinden, ist technisch anspruchsvoll, weil der Filter die Nachbarschaftsstruktur zerreißen kann.

Anwendungsfelder

Abrufgestützte Antworten. Der Anwendungsfall, der die Kategorie bekannt machte. Der Bestand liegt als Vektoren vor, die Frage wird ebenso dargestellt, und die nächsten Abschnitte gehen an das Sprachmodell.

Bild- und Tonsuche. Der Ansatz ist nicht auf Text beschränkt. Bilder, Tonaufnahmen und Videos lassen sich ebenso als Vektoren darstellen und vergleichen.

Empfehlung und Dublettenerkennung. Ähnlichkeit als Abstand ist die Grundlage von Empfehlungen und von der Erkennung inhaltsgleicher Einträge in großen Beständen.

Gedächtnis für Agenten. Systeme mit langem Lauf legen Zwischenergebnisse als Vektoren ab und holen bei Bedarf zurück, was zum aktuellen Schritt passt.

Kontroversen und Kritik

Fragliche Eigenständigkeit. Der häufigste Einwand lautet, es handle sich um eine Funktion und nicht um eine Produktgattung. Verbreitete relationale und dokumentorientierte Datenbanken haben Vektorsuche nachgerüstet, sodass für viele Anwendungen kein zusätzliches System nötig ist.

Fehlende Reife. Junge Systeme bringen die Eigenschaften nicht mit, die von Datenbanken erwartet werden: Transaktionen, feingranulare Rechte, verlässliche Sicherung, Betrieb über Standorte hinweg.

Näherung ohne ausgewiesene Fehlerrate. Dass ein Ergebnis unvollständig sein kann, ist Teil des Entwurfs. In der Praxis wird die Trefferquote selten gemessen, sodass unklar bleibt, wie viele Treffer die Suche übersieht.

Kosten der Neuberechnung. Ein Wechsel des Embedding-Modells macht den gesamten Bestand ungültig. Die Datenbank speichert Vektoren, deren Bedeutung an ein bestimmtes Modell gebunden ist.

Datenschutz. Vektoren gelten oft als unkritisch, weil sie wie Zahlenkolonnen aussehen. Untersuchungen zeigen, dass sich Ausgangstexte teilweise rekonstruieren lassen – ein ausgelagerter Vektorbestand ist damit kein anonymisierter Bestand.

Die Speicherung ist nicht das Problem

Die Aufmerksamkeit für Vektordatenbanken hat einen Schwerpunkt gesetzt, der von der eigentlichen Schwierigkeit ablenkt.

Die Suche selbst ist gelöst. Die zugrunde liegenden Verfahren sind seit Jahren stabil, quelloffen verfügbar und in ihrer Leistung gut vermessen. Ob ein System diese Verfahren als eigenständiges Produkt oder als Erweiterung anbietet, ändert am Ergebnis wenig.

Was über die Güte eines Abrufsystems entscheidet, liegt davor und danach: wie die Dokumente zerlegt wurden, wie gut das Embedding-Modell den Fachbereich abbildet, ob eine Stichwortsuche daneben steht, und ob jemand misst, was die Suche übersieht.

Die Wahl der Datenbank ist demgegenüber eine Frage des Betriebs – wichtig für Kosten und Wartung, aber selten der Grund, warum ein System gute oder schlechte Antworten gibt.

Quellenangaben

Johnson, Jeff / Douze, Matthijs / Jégou, Hervé (Facebook AI Research) (2017): Billion-Scale Similarity Search with GPUs. arXiv: 1702.08734.
Malkov, Yury A. / Yashunin, Dmitry A. (2016): Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs. arXiv: 1603.09320.
Lewis, Patrick u. a., 2020. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. In: Advances in Neural Information Processing Systems 33 (NeurIPS 2020), S. 9459–9474. arXiv: 2005.11401.

← Zurück zur Lexikon-Übersicht

Zuletzt bearbeitet: 10. August 2026

Zusammengestellt, formuliert, lektoriert und korrigiert mit KI-Unterstützung. Kuratiert von Nils Brauer. Alle Angaben ohne Gewähr.