Vektordatenbank

Was ist Vektordatenbank?

Eine Vektordatenbank ist ein Datenspeicher, gebaut, um Embeddings zu halten, die numerischen Vektoren, die die Bedeutung von Text, Bildern, oder Code repräsentieren, und um Ähnlichkeitsabfragen darüber schnell zu beantworten. Gegeben einen Query-Vektor, gibt sie die gespeicherten Elemente zurück, die in der Bedeutung am nächsten sind, was sie zum Retrieval-Rückgrat von RAG-Systemen, semantischer Suche, und Agent Memory macht.

Die wichtigsten Punkte

• Die Kernoperation ist Approximate Nearest Neighbor Search: die ähnlichsten Vektoren unter Millionen in Millisekunden finden, indem ein kleiner Teil Recall gegen enorme Geschwindigkeit getauscht wird.
• Vektoren allein genügen nicht. Produktions-Retrieval hängt von den daneben gespeicherten Metadaten ab, für Berechtigungsfilterung, Mandantenisolation, Aktualität, und Hybrid-Keyword-Scoring.
• Die Kategorie umfasst dedizierte Engines und Erweiterungen bestehender Datenbanken, am prominentesten pgvector innerhalb von Postgres, und die Erweiterungsroute gewinnt standardmäßig bei kleinem und mittlerem Maßstab.
• Eine Vektordatenbank gibt ähnliche Elemente zurück, nicht korrekte Antworten. Retrieval-Qualität wird stromaufwärts durch Chunking und das Embedding-Modell bestimmt, nicht durch die Datenbank.

So funktioniert es

Ein Embedding-Modell verwandelt jedes Stück Inhalt in ein Vektor-Embedding, eine Liste von Hunderten oder Tausenden Fließkommazahlen, positioniert so, dass ähnliche Bedeutungen nahe beieinander landen. Die Datenbank speichert diese Vektoren mit einer ID, dem Quelltext oder einem Verweis darauf, und strukturierten Metadaten. Eine Anfrage kommt als weiterer Vektor an, und die Datenbank gibt die k nächsten gespeicherten Vektoren zurück, gerankt nach Kosinus-Ähnlichkeit oder Skalarprodukt.

Die Anfrage gegen jeden Vektor zu vergleichen, ein Brute-Force-Scan, ist exakt, skaliert aber linear und wird jenseits einiger hunderttausend Einträge zu langsam. Vektordatenbanken bauen daher Approximate-Nearest-Neighbor-Indizes. Die dominante Struktur ist HNSW, ein geschichteter Graph, gierig von grob zu fein navigiert; IVF-artige Indizes, die den Raum in Cluster partitionieren, sind die andere gängige Familie, und Quantisierungstechniken verkleinern Vektoren, um Speicher zu sparen. Diese Indizes antworten in Millisekunden, auf Kosten des gelegentlichen Verpassens eines echten Nachbarn, mit Recall abstimmbar gegen Latenz. Die Skalierungsobergrenzen wurden Jahre vor der aktuellen KI-Welle etabliert: Metas Faiss-Bibliothek demonstrierte 2017 GPU-Ähnlichkeitssuche 8,5x schneller als der vorherige State of the Art, baute einen hochgenauen k-NN-Graphen über 1 Milliarde Vektoren in unter 12 Stunden auf vier GPUs auf [1]. Microsofts DiskANN zeigte dann bei NeurIPS 2019, dass ein Milliarden-Punkte-Index auf einer einzelnen Workstation mit 64GB RAM und einer SSD leben kann, während er über 5.000 Anfragen pro Sekunde bei unter 3ms mittlerer Latenz mit 95%+ Recall bedient [2].

Die Features, die ein Produktionssystem von einer Demo unterscheiden, leben größtenteils außerhalb des Index. Gefilterte Suche wendet Metadaten-Prädikate an, etwa Mandanten-ID oder Dokumentberechtigungen, ohne den Recall auszuweiden, was echt schwer ist und nur von ausgereiften Engines gut gehandhabt wird. Hybrid-Suche fusioniert Vektor-Scores mit Keyword-Scoring, sodass exakte Identifikatoren weiterhin matchen. Dann kommen die gewöhnlichen Datenbank-Tugenden: Upserts und Deletes, die den Index konsistent halten, während sich Dokumente ändern, Namespaces für Isolation, und Backups. In Agenten-Stacks dient dieselbe Maschinerie doppeltem Zweck und treibt sowohl Dokument-Retrieval als auch Long-Term-Agent-Memory an, wo vergangene Interaktionen embeddet und nach Relevanz abgerufen werden.

Beispiel

Ein Legal-Tech-Startup baut Vertragssuche über 2 Millionen Klausel-Level-Chunks für 400 Kanzleien. Jeder Chunk wird embeddet und mit Metadaten gespeichert: Kanzlei-ID, Vertragsdatum, Klauseltyp, geltendes Recht. Wenn ein Anwalt bei einer Kanzlei sucht "Kündigung aus Zweckmäßigkeit mit weniger als 30 Tagen Frist", wird die Anfrage embeddet, und die Datenbank führt Nearest-Neighbor-Suche gefiltert nur auf die Dokumente dieser Kanzlei aus, gibt 20 Kandidatenklauseln in unter 50 Millisekunden zurück, die ein Reranker dann auf fünf verengt. Der Filter leistet Tenant-Isolation auf juristischem Niveau, sodass das Team verifizierte, dass Filterung innerhalb der Index-Traversierung passiert statt danach, sowohl für Recall als auch um zu garantieren, dass die Klauseln einer anderen Kanzlei nie erscheinen können. Sie starteten mit pgvector und migrierten den Retrieval-Pfad erst zu einer dedizierten Engine, als Korpus und Filterkomplexität es überstiegen.

Häufige Missverständnisse

Der wiederkehrende Fehler ist, ein KI-Projekt zu beginnen, indem man eine dedizierte Vektordatenbank beschafft, als wäre das der schwere Teil. Für Korpora unter ein paar Millionen Vektoren genügt meist pgvector oder der Vektortyp in einer bestehenden Suchmaschine, hält Embeddings transaktional konsistent neben den Quelldaten, und fügt null neue operative Fläche hinzu. Währenddessen bekommen die eigentlichen Bestimmungsfaktoren der Retrieval-Qualität, Chunking-Strategie und Wahl des Embedding-Modells, nur einen Bruchteil der Aufmerksamkeit. Wählen Sie zuerst die langweilige Speicheroption, stecken Sie die gesparte Mühe in die Pipeline, und upgraden Sie die Datenbank, wenn Maßstab oder Filteranforderungen es erzwingen.

FAQ

Brauche ich eine Vektordatenbank für RAG? Sie brauchen Vektorspeicher und Ähnlichkeitssuche; ob das ein dediziertes Produkt ist, ist eine Maßstabsfrage. Retrieval-Augmented Generation über Tausende oder sogar einige Millionen Chunks läuft gut auf pgvector oder einem bestehenden Such-Stack. Dedizierte Engines verdienen ihren Platz bei sehr großen Korpora, schweren gefilterten Suchanforderungen, oder strikten Latenzbudgets bei hohem Anfragevolumen.

Wie unterscheidet sich eine Vektordatenbank von einer gewöhnlichen Datenbank? Eine gewöhnliche Datenbank ruft Zeilen ab, die exakte Bedingungen erfüllen. Eine Vektordatenbank rankt Elemente nach geometrischer Ähnlichkeit zu einem Query-Vektor, einer unscharfen, bedeutungsbasierten Operation, die spezialisierte Indizes braucht. In der Praxis ist die Grenze verschwommen: Postgres, OpenSearch, Redis, und die meisten großen Datenbanken schrauben inzwischen Vektorsuche an, sodass "Vektordatenbank" zunehmend eine Fähigkeit benennt statt eine separate Produktkategorie.

Was wird tatsächlich darin gespeichert? Drei Dinge pro Element: der Embedding-Vektor, Metadaten für Filterung, und die Payload, entweder der ursprüngliche Chunk-Text oder ein Verweis darauf. Die Embeddings werden außerhalb der Datenbank von einem Embedding-Modell produziert, und wenn Sie je dieses Modell wechseln, muss jeder Vektor neu generiert werden, da Vektoren von unterschiedlichen Modellen nicht vergleichbar sind.

Quellen

1. Johnson, Douze & Jégou, Meta AI. "Faiss-Benchmarks für GPU-Ähnlichkeitssuche im Milliarden-Maßstab." https://arxiv.org/abs/1702.08734. Abgerufen im August 2026.
2. Subramanya et al., Microsoft Research. "DiskANN-Milliarden-Punkte-Suche auf einer einzelnen Workstation." https://papers.nips.cc/paper/9527-rand-nsg-fast-accurate-billion-point-nearest-neighbor-search-on-a-single-node. Abgerufen im August 2026.