Eine Vektordatenbank ist ein Speicher für Embeddings, der zu einer Anfrage die ähnlichsten gespeicherten Einträge zurückgibt. Sie löst damit eine Aufgabe, für die klassische Datenbankindizes nicht ausgelegt sind: die Suche nach Nähe in einem Raum mit hunderten oder tausenden Dimensionen.
Warum ein normaler Index nicht reicht
Ein klassischer Index beschleunigt die Suche nach exakten Werten oder Bereichen. Beides setzt eine Ordnung voraus, die es in einem hochdimensionalen Vektorraum nicht gibt: Es gibt kein sinnvolles Sortieren nach Ähnlichkeit, weil Nähe erst im Verhältnis zu einer konkreten Anfrage entsteht. Ohne spezialisierten Index müsste jede Anfrage mit jedem gespeicherten Vektor verglichen werden — bei grossen Beständen unbrauchbar langsam.
Approximative Suche als Normalfall
Vektordatenbanken lösen das über approximative Verfahren. Sie geben nicht garantiert die exakt ähnlichsten Treffer zurück, sondern mit hoher Wahrscheinlichkeit sehr ähnliche — dafür um Grössenordnungen schneller. Dieser Kompromiss wird über Parameter gesteuert, die zwischen Geschwindigkeit und Trefferqualität abwägen. Für die meisten Anwendungen ist er unproblematisch, weil ein knapp verfehlter drittbester Treffer keine Rolle spielt. Wo Vollständigkeit zählt, muss der Kompromiss bewusst anders gesetzt werden.
Metadaten sind der eigentliche Hebel
Reine Ähnlichkeitssuche liefert selten das, was gebraucht wird. In der Praxis kommt fast immer eine Einschränkung dazu: nur Dokumente dieses Mandanten, nur die aktuelle Version, nur Inhalte ab einem bestimmten Datum. Diese Filterung über Metadaten ist bei vielen Anwendungen wichtiger als die Ähnlichkeitsberechnung selbst — und sie ist der Punkt, an dem sich Systeme in der Praxis unterscheiden. Insbesondere bei mandantenfähigen Anwendungen ist die Filterung nach Mandant kein Komfortmerkmal, sondern eine Sicherheitsanforderung.
Eigenständige Datenbank oder Erweiterung
Es gibt zwei Wege. Spezialisierte Vektordatenbanken sind auf diese eine Aufgabe optimiert und skalieren entsprechend weit. Erweiterungen bestehender relationaler Datenbanken bringen Vektorsuche in ein System, das ohnehin schon läuft. Für viele Anwendungen ist der zweite Weg der pragmatischere: Die Vektoren liegen dann neben den Geschäftsdaten, Filterung über Metadaten ist eine gewöhnliche Bedingung in derselben Abfrage, und es kommt kein zweites System mit eigenem Betrieb, eigener Sicherung und eigener Konsistenzfrage dazu.
Die Konsistenzfrage
Wo Vektoren in einem separaten System liegen, entsteht ein Synchronisationsproblem: Wird ein Dokument gelöscht oder geändert, muss der zugehörige Vektor mitgelöscht oder neu berechnet werden. Geschieht das nicht zuverlässig, liefert die Suche Treffer auf Inhalte, die es nicht mehr gibt — bei personenbezogenen Daten ein Löschproblem und nicht nur ein Qualitätsproblem.
Praktische Konsequenz
Die Wahl der Vektordatenbank ist selten die wichtigste Entscheidung in einem RAG-System. Wichtiger sind Chunking, Metadatenmodell und die Frage, ob Vektoren und Geschäftsdaten konsistent bleiben. Wer klein anfängt, fährt mit einer Erweiterung der bestehenden Datenbank meist besser als mit einem zusätzlichen System.