Vektordatenbank
Stell dir vor, du suchst nicht nach einem exakten Stichwort, sondern nach dem Inhalt, der deiner Frage am nächsten kommt. Genau das leisten Vektordatenbanken: Sie speichern Texte, Bilder oder andere Daten als Zahlenvektoren und finden innerhalb von Millisekunden die ähnlichsten Einträge.
Klassische Datenbanken arbeiten mit exakten Abfragen. Eine SQL-Datenbank findet alle Datensätze, in denen eine bestimmte Spalte einen bestimmten Wert hat. Eine Vektordatenbank arbeitet anders: Sie berechnet, welche gespeicherten Einträge einem gegebenen Eingabevektor am ähnlichsten sind. Der Vergleich geschieht nicht über Zeichenketten, sondern über geometrische Nähe im hochdimensionalen Raum.
Beispiel: Ein Onlineshop speichert Produktbeschreibungen als Vektoren. Ein Kunde gibt "bequeme Laufschuhe für Asphalt" ein. Die Vektordatenbank liefert Produkte zurück, deren Beschreibungsvektoren geometrisch nah an diesem Eingabevektor liegen, auch wenn keines der Suchwörter in der Beschreibung vorkommt.
Wie Daten in eine Vektordatenbank gelangen
Bevor Daten durchsuchbar sind, müssen sie in Vektoren umgewandelt werden. Diesen Vorgang übernimmt ein Einbettungsmodell. Es liest einen Text (oder ein Bild, einen Audioclip) und gibt einen Zahlenvektor mit fester Länge zurück. Typische Dimensionen liegen bei 384, 768 oder 1536 Gleitkommazahlen.
Der resultierende Vektor kodiert die semantische Bedeutung des Eingabetextes. Texte mit ähnlicher Bedeutung erzeugen Vektoren, die im hochdimensionalen Raum nahe beieinander liegen. Texte mit unterschiedlicher Bedeutung erzeugen Vektoren, die weit auseinander liegen.
Beispiel: Die Sätze "Der Hund liegt auf der Couch" und "Ein Retriever schläft auf dem Sofa" erzeugen Vektoren mit hoher Kosinusähnlichkeit, obwohl sie kaum gemeinsame Wörter teilen. Der Satz "Die Aktie fiel um drei Prozent" erzeugt einen Vektor, der weit entfernt von beiden liegt.
Beispiel: Ein Unternehmen will 200.000 Support-Tickets durchsuchbar machen. Jedes Ticket wird durch ein Einbettungsmodell in einen 768-dimensionalen Vektor umgewandelt und zusammen mit Metadaten (Datum, Kategorie, Priorität) in der Vektordatenbank gespeichert.
Approximate Nearest Neighbor Search
Die zentrale Operation einer Vektordatenbank ist die Suche nach den nächsten Nachbarn eines Abfragevektors. Bei einer exakten Suche (Brute Force) wird der Abfragevektor mit jedem einzelnen gespeicherten Vektor verglichen. Das liefert perfekte Ergebnisse, skaliert aber nicht: Bei einer Million Vektoren mit 768 Dimensionen entstehen 768 Millionen Gleitkomma-Operationen pro Abfrage.
Vektordatenbanken lösen dieses Problem durch Approximate Nearest Neighbor (ANN) Algorithmen. Diese Algorithmen bauen einen Index auf, der den Suchraum vorstrukturiert. Statt alle Vektoren zu prüfen, navigiert die Suche durch den Index und prüft nur einen kleinen Teil der Daten. Das Ergebnis ist nicht garantiert exakt, liegt in der Praxis aber bei über 95 Prozent Precision bei Antwortzeiten unter 10 Millisekunden.
Beispiel: Ein Dokumentenarchiv mit 5 Millionen Einträgen. Brute-Force-Suche dauert 1,2 Sekunden pro Abfrage. Mit HNSW-Index (einem gängigen ANN-Algorithmus) sinkt die Antwortzeit auf 4 Millisekunden, bei einem Recall von 98 Prozent.
Wie ein HNSW-Index funktioniert
Der am weitesten verbreitete ANN-Algorithmus in Vektordatenbanken ist HNSW (Hierarchical Navigable Small World). Er organisiert Vektoren in einem mehrschichtigen Graphen. Jeder Vektor ist ein Knoten. Knoten sind mit ihren nächsten Nachbarn verbunden. Die oberen Schichten enthalten wenige Knoten mit weitreichenden Verbindungen (Expressverbindungen). Die unteren Schichten enthalten alle Knoten mit lokalen Verbindungen.
Die Suche beginnt oben und springt über die Expressverbindungen schnell in die richtige Region. Dann steigt sie Schicht für Schicht ab und verfeinert das Ergebnis.
Beispiel: Eine Vektordatenbank enthält 10 Millionen Produktvektoren. Ohne Index prüft die Suche alle 10 Millionen Einträge. Mit HNSW prüft sie etwa 400 bis 800 Knoten und findet die 10 ähnlichsten Produkte in unter 5 Millisekunden.
Neben HNSW existieren weitere Indextypen: IVF (Inverted File Index) partitioniert den Raum in Cluster und durchsucht nur die relevantesten. Product Quantization (PQ) komprimiert Vektoren, um Speicher zu sparen. Viele Datenbanken kombinieren diese Verfahren.
Fachliche Einordnung: HNSW wurde 2016 von Malkov und Yashunin vorgestellt. Der Algorithmus baut auf dem Small-World-Phänomen auf: In einem gut vernetzten Graphen erreicht man jeden Knoten über wenige Zwischenschritte. Die hierarchische Erweiterung ermöglicht logarithmische Suchkomplexität (O(log n)) bei hohem Recall. Die meisten produktionsreifen Vektordatenbanken (einschließlich Qdrant, Weaviate und Milvus) verwenden HNSW als primären Indextyp.
Distanzmaße: Wie Ähnlichkeit berechnet wird
Vektordatenbanken bieten verschiedene Distanzmaße für den Vektorvergleich. Die Wahl des Distanzmaßes beeinflusst, welche Ergebnisse als "nah" gelten.
Kosinusähnlichkeit misst den Winkel zwischen zwei Vektoren. Zwei Vektoren, die in dieselbe Richtung zeigen, haben eine Kosinusähnlichkeit von 1, unabhängig von ihrer Länge. Dieses Maß eignet sich für Textvergleiche, weil die Länge eines Textes (und damit die Vektorlänge) das Ergebnis nicht verzerren soll.
Euklidische Distanz misst den geraden Abstand zwischen zwei Punkten im Raum. Hier spielt die absolute Länge der Vektoren eine Rolle. Dieses Maß eignet sich, wenn die Vektorgröße eine inhaltliche Bedeutung trägt.
Dot Product (Skalarprodukt) kombiniert Richtung und Länge. Es ist rechnerisch am günstigsten und wird häufig verwendet, wenn die Vektoren bereits normalisiert sind (dann entspricht es der Kosinusähnlichkeit).
Beispiel: Ein Einbettungsmodell erzeugt normalisierte Vektoren (Länge 1). In diesem Fall liefern Kosinusähnlichkeit und Dot Product identische Ergebnisse. Qdrant empfiehlt für diesen Fall Dot Product, weil die Berechnung schneller ist.
Beispiel: Ein Empfehlungssystem für Musik speichert Nutzervektoren und Songvektoren. Die Vektoren sind nicht normalisiert, weil die Länge die Stärke der Präferenz kodiert. Hier eignet sich Dot Product: Längere Vektoren (stärkere Präferenz) erhalten höhere Scores.
Metadaten und hybride Filterung
Reine Vektorsuche reicht in der Praxis selten aus. Die meisten Anwendungen benötigen zusätzlich strukturierte Filter: "Finde ähnliche Dokumente, aber nur aus dem Jahr 2025" oder "Finde ähnliche Produkte, aber nur in der Kategorie Elektronik".
Vektordatenbanken speichern neben dem Vektor auch Metadaten (Payload). Bei einer Abfrage wird zuerst der Vektorvergleich durchgeführt und dann ein Filter auf die Metadaten angewendet (Post-Filtering). Alternativ kann der Filter vor dem Vektorvergleich greifen (Pre-Filtering). Pre-Filtering ist präziser, weil es garantiert, dass die Ergebnismenge den Filterbedingungen entspricht. Post-Filtering kann dazu führen, dass weniger als die gewünschte Anzahl an Ergebnissen übrig bleibt.
Beispiel: Eine juristische Datenbank enthält 2 Millionen Urteile als Vektoren. Ein Anwalt sucht nach ähnlichen Urteilen zum Thema Mietrecht, aber nur aus der Gerichtsbarkeit "BGH" und ab dem Jahr 2020. Die Vektordatenbank filtert zuerst auf BGH-Urteile ab 2020 und führt dann die Ähnlichkeitssuche auf dieser Teilmenge durch.
Beispiel: Ein RAG-System für technische Dokumentation. Ein Nutzer fragt nach "Fehlermeldung beim Start des Services". Die Vektordatenbank findet ähnliche Chunks, gefiltert auf die aktuelle Softwareversion und die Sprache Deutsch.
Vektordatenbanken in RAG-Systemen
Retrieval Augmented Generation ist der häufigste Anwendungsfall für Vektordatenbanken. In einem RAG-System beantwortet ein Sprachmodell Fragen, indem es zuerst relevante Dokumente aus einer Wissensbasis abruft und dann auf Basis dieser Dokumente antwortet.
Die Vektordatenbank übernimmt den Retrieval-Schritt. Der Ablauf: Ein Nutzer stellt eine Frage. Die Frage wird vom Einbettungsmodell in einen Vektor umgewandelt. Die Vektordatenbank findet die k ähnlichsten Chunks. Diese Chunks werden als Kontext an das Sprachmodell übergeben, das eine Antwort formuliert.
Beispiel: Karl Kratz betreibt ein RAG-System für die eigene Wissensbasis. 4.000 Textabschnitte sind als Vektoren in Qdrant gespeichert. Bei einer Frage wie "Wie funktioniert Chunking mit überlappenden Fenstern?" findet die Datenbank die 5 relevantesten Abschnitte in unter 3 Millisekunden. Das Sprachmodell erhält diese Abschnitte als Kontext und formuliert eine präzise Antwort mit Quellenangaben.
Die Qualität des gesamten RAG-Systems hängt stark von der Qualität des Retrievals ab. Wenn die Vektordatenbank irrelevante Chunks liefert, kann auch das beste Sprachmodell keine gute Antwort formulieren. Entscheidende Faktoren sind die Wahl des Einbettungsmodells, die Chunking-Strategie und die Konfiguration der Suchabfrage (Anzahl der Ergebnisse, Schwellenwert für Mindestähnlichkeit).
Skalierung und Betrieb in der Praxis
Eine Vektordatenbank mit 10.000 Einträgen läuft problemlos auf einem einzelnen Server. Bei Millionen oder Milliarden von Vektoren treten drei Herausforderungen auf: Speicherverbrauch, Indexaufbauzeit und Abfragelatenz.
Speicher: Ein Vektor mit 768 Dimensionen benötigt als Float32 etwa 3 KByte. Eine Million Vektoren belegen rund 3 GByte nur für die Rohdaten. Der HNSW-Index verdoppelt bis verdreifacht den Speicherbedarf. Quantisierungstechniken wie Scalar Quantization (Float32 zu Int8) reduzieren den Bedarf auf ein Viertel bei minimalem Genauigkeitsverlust.
Beispiel: Ein E-Commerce-System speichert 50 Millionen Produktvektoren (768 Dimensionen). Ohne Quantisierung: 150 GByte Rohdaten plus Index. Mit Scalar Quantization: 38 GByte Rohdaten plus Index. Der Unterschied bestimmt, ob ein einzelner Server ausreicht oder ein Cluster notwendig wird.
Für größere Datenmengen unterstützen Vektordatenbanken horizontale Skalierung durch Sharding: Die Daten werden auf mehrere Knoten verteilt. Jeder Knoten bearbeitet Abfragen auf seinem Teil der Daten. Die Ergebnisse werden zusammengeführt. Replikation ermöglicht zusätzlich Ausfallschutz und höheren Lesedurchsatz.
Vergleich gängiger Vektordatenbanken
Die Auswahl einer Vektordatenbank hängt von Anforderungen an Hosting, Skalierung und Funktionsumfang ab.
Qdrant ist in Rust geschrieben und läuft als eigenständiger Service. Die Datenbank bietet HNSW-Indexierung, Payload-Filterung und Quantisierung. Sie lässt sich auf eigener Infrastruktur betreiben (Self-Hosting) und über eine REST- oder gRPC-Schnittstelle ansprechen.
ChromaDB ist eine leichtgewichtige Vektordatenbank in Python. Sie eignet sich für Prototypen und kleinere Projekte, weil sie als eingebettete Datenbank direkt im Anwendungsprozess läuft. Für produktionskritische Systeme mit Millionen von Vektoren fehlen Sharding und Replikation.
Pinecone ist ein vollständig verwalteter Cloud-Service. Die gesamte Infrastruktur wird vom Anbieter betrieben. Vorteil: kein Betriebsaufwand. Nachteil: Daten liegen auf fremden Servern, Kosten skalieren mit dem Datenvolumen, und die Abhängigkeit vom Anbieter ist hoch.
Milvus ist für Datensätze im Milliarden-Bereich ausgelegt. Die Architektur trennt Speicher, Indexierung und Abfrageverarbeitung in separate Komponenten, die unabhängig skaliert werden. Der Betrieb ist komplexer als bei kompakteren Alternativen.
Beispiel: Ein Team evaluiert Vektordatenbanken für ein internes RAG-System mit 500.000 Dokumenten. Anforderungen: Self-Hosting auf eigenen Servern, Payload-Filterung nach Abteilung und Dokumenttyp, Antwortzeiten unter 20 Millisekunden. Qdrant und Milvus erfüllen alle Anforderungen. ChromaDB scheidet wegen fehlender Skalierungsfunktionen aus. Pinecone scheidet wegen der Self-Hosting-Anforderung aus.
Grenzen und häufige Fehlerquellen
Vektordatenbanken sind kein Allheilmittel für jede Suchaufgabe. Mehrere Einschränkungen sind in der Praxis relevant.
Qualität der Einbettungen bestimmt die Ergebnisqualität. Die Vektordatenbank findet die geometrisch nächsten Nachbarn. Wenn das Einbettungsmodell die Domäne schlecht abbildet (etwa ein allgemeines Modell für hochspezialisierte juristische Texte), sind die Suchergebnisse trotz korrekter Datenbankfunktion schlecht.
Beispiel: Ein allgemeines Einbettungsmodell ordnet die Begriffe "Pfandrecht" und "Pfandflasche" nah beieinander ein, weil beide das Wort "Pfand" enthalten. Ein auf juristische Texte feinjustiertes Modell trennt diese Begriffe korrekt.
Approximate Search ist nicht exakt. ANN-Algorithmen garantieren keine vollständige Ergebnismenge. In seltenen Fällen fehlen relevante Treffer (False Negatives). Für Anwendungen, die garantierte Vollständigkeit erfordern (etwa regulatorische Compliance-Prüfungen), ist eine exakte Suche oder eine Kombination mit klassischer Volltextsuche notwendig.
Dimensionalität und Speicher stehen in Spannung. Höhere Vektordimensionen kodieren mehr Information, erhöhen aber Speicherbedarf und Suchzeit. Die Wahl der Dimension ist ein Kompromiss zwischen Genauigkeit und Betriebskosten.
Beispiel: Ein Benchmark-Vergleich zeigt: Ein 384-dimensionales Modell erreicht 89 Prozent Retrieval-Qualität auf einem fachspezifischen Testset. Ein 1536-dimensionales Modell erreicht 93 Prozent. Der Speicherbedarf vervierfacht sich. Ob die 4 Prozentpunkte den Mehraufwand rechtfertigen, hängt vom Anwendungsfall ab.
Cold Start bei leeren Datenbanken. Eine Vektordatenbank liefert nur Ergebnisse, wenn Daten vorhanden sind. Die initiale Befüllung (Texte chunken, einbetten, indexieren) kann bei großen Datenbeständen Stunden bis Tage dauern.
Fachliche Einordnung: Vektordatenbanken sind ein Baustein in einem größeren System, kein eigenständiges Produkt. Ihre Wirksamkeit hängt vom Zusammenspiel mit dem Einbettungsmodell, der Chunking-Strategie, der Abfragekonfiguration und der nachgelagerten Verarbeitung (etwa einem Reranker oder einem Sprachmodell) ab. Isoliert betrachtet ist eine Vektordatenbank ein hochoptimierter Index für geometrische Näherungssuche. Erst im Verbund mit den übrigen Komponenten entsteht ein funktionierendes Retrieval-System.