Eine Vektordatenbank speichert Daten als hochdimensionale numerische Vektoren und ruft Datensätze nach Ähnlichkeit ab, nicht nach einem exakten Wert. Statt „Finde die Zeile, in der id = 42“ fragt man: „Finde die Zeilen, die dieser Anfrage am ähnlichsten sind.“ Damit ist sie die Standardspeicherschicht für semantische Suche, Empfehlungssysteme und Retrieval-Augmented Generation.
Warum Vektoren statt Zeilen
Die meisten Daten, die in KI-Pipelines eine Rolle spielen, Texte, Bilder, Audio, haben keinen natürlichen Primärschlüssel, gegen den man abgleichen könnte. Was man wissen möchte, ist: Welche gespeicherten Einträge sind bedeutungsmäßig nah an dieser neuen Eingabe?
Ein Embedding-Modell wandelt jeden Eintrag in einen Vektor um: eine Liste von Zahlen, oft hunderte oder tausende Dimensionen lang, wobei die Position in diesem Raum die semantische Bedeutung codiert. Zwei Sätze, die dasselbe mit verschiedenen Worten ausdrücken, erzeugen Vektoren, die nah beieinander liegen. Zwei Sätze mit entgegengesetzter Bedeutung liegen weit auseinander.
Eine Vektordatenbank indiziert diese Vektoren so, dass Nearest-Neighbour-Abfragen selbst über Millionen oder Milliarden von Datensätzen in Millisekunden ausgeführt werden.
Wie die Ähnlichkeitssuche funktioniert
Das gebräuchlichste Ähnlichkeitsmaß ist die Kosinus-Ähnlichkeit: der Winkel zwischen zwei Vektoren. Weitere Maße sind das Skalarprodukt und die euklidische Distanz. Eine exakte Nearest-Neighbour-Suche über große Datensätze ist rechenintensiv, weshalb die meisten Systeme Approximate-Nearest-Neighbour-(ANN-)Algorithmen verwenden. Diese tauschen eine kleine, kontrollierbare Menge an Trefferquote gegen deutliche Geschwindigkeitsgewinne ein. Gängige Indizierungsstrategien sind HNSW (Hierarchical Navigable Small World) und IVF (Inverted File Index).
In der Regel lässt sich die Vektorähnlichkeit mit herkömmlichen Filtern kombinieren: „Finde die zehn ähnlichsten Dokumente, aber nur aus den Daten dieses Mandanten, veröffentlicht nach diesem Datum.“ Diese hybride Abfrage ist die in der Praxis am häufigsten verwendete Nutzungsweise von Vektordatenbanken in Produktivsystemen.
Wo Vektordatenbanken im Produktivbetrieb eingesetzt werden
- RAG-Pipelines. Abgerufene Textabschnitte, die anhand der semantischen Ähnlichkeit zur Nutzerfrage ausgewählt werden, werden einem Sprachmodell als Kontext übergeben. Die Vektordatenbank sorgt dafür, dass der Abruf schnell und relevant ist. Unter Was ist RAG finden Sie eine ausführlichere Erläuterung.
- Semantische Suche. Produktkataloge, Support-Wissensdatenbanken, Dokumentenarchive für Rechtsfragen: überall dort, wo die Schlüsselwortsuche versagt, weil Nutzer Dinge anders formulieren, als sie in den Dokumenten stehen.
- Empfehlungen. Nutzer- und Objekt-Embeddings werden gespeichert; die Ähnlichkeitssuche findet Objekte, die dem entsprechen, womit ein Nutzer interagiert hat.
- Deduplizierung und Clustering. Nahezu doppelte Datensätze werden gefunden oder ähnliche Objekte gruppiert, ohne dass eine exakte Zeichenkettenübereinstimmung erforderlich ist.
Dedizierte Systeme im Vergleich zu Erweiterungen
Manche Teams setzen auf speziell entwickelte Vektordatenbanken. Andere greifen auf eine Vektorerweiterung zurück, die einer bereits betriebenen relationalen Datenbank hinzugefügt wird. Beide Ansätze sind produktiv im großen Maßstab im Einsatz. Die richtige Wahl hängt vom Abfragevolumen, den Latenzanforderungen, der Frage, ob starke Transaktionsgarantien für dieselben Datensätze benötigt werden, und der Vertrautheit mit dem Betrieb ab. Eine universelle Antwort gibt es nicht.
Der Zusammenhang mit dem Kontextfenster
Vektorsuche ist zum Teil ein Workaround für die Grenzen von Kontextfenstern. Eine gesamte Wissensbasis lässt sich einem Sprachmodell nicht übergeben; stattdessen werden die relevanten Ausschnitte abgerufen und weitergegeben. Mit wachsenden Kontextfenstern verschiebt sich diese Abwägung, aber der Abruf bleibt schneller und kostengünstiger als alles in einen Prompt zu packen, und die Quelle der Wahrheit bleibt außerhalb des Modells.
Was wir prüfen
Engineers, die an RAG- oder Semantic-Search-Pipelines arbeiten, müssen wissen, wie man eine Vektordatenbank-API aufruft. Wichtiger ist, dass sie beurteilen können, ob das Retrieval tatsächlich funktioniert: ob die gewählten Embeddings passen, ob die Chunking-Strategie den Recall beeinflusst und wann ein modellbasierter Ansatz das falsche Werkzeug ist. Unsere Prüfung umfasst Evaluationsdesign und die Beurteilung der Retrieval-Qualität als Teil des Assessments für KI-Entwickler. Alle Details finden Sie unter So prüfen wir.
Kurze Antworten
Was ist der Unterschied zwischen einer Vektordatenbank und einer herkömmlichen Datenbank?
Eine reguläre Datenbank ruft Datensätze anhand exakter Werte oder Bereiche ab. Eine Vektordatenbank ruft anhand von Ähnlichkeit ab: Welche gespeicherten Vektoren liegen einem Abfragevektor am nächsten? Sie beantworten unterschiedliche Fragen und werden in einem System häufig gemeinsam eingesetzt.
Benötigen Sie eine dedizierte Vektordatenbank, oder genügt eine relationale Datenbank?
Beide Ansätze funktionieren im Produktivbetrieb. Dedizierte Systeme bieten bei hohem Abfragevolumen in der Regel bessere Performance. Relationale Erweiterungen sind betrieblich einfacher, wenn Sie diese Datenbank bereits nutzen. Die richtige Wahl hängt von der Skalierung, den Latenzanforderungen und den Kenntnissen des Teams ab.
Ist eine Vektordatenbank dasselbe wie eine RAG-Pipeline?
Nein. Eine Vektordatenbank ist eine Komponente innerhalb einer RAG-Pipeline. RAG umfasst außerdem ein Embedding-Modell, eine Chunking-Strategie, ein Sprachmodell und eine Orchestrierungsschicht. Die Datenbank übernimmt Speicherung und Abruf; der Rest der Pipeline verarbeitet und verwendet das Ergebnis.
