Vektordatenbank

Einfach erklärt

Eine Vektordatenbank ist eine spezielle Datenbank, die für die Speicherung und Suche von Embeddings optimiert ist. Während eine normale Datenbank nach exakten Werten sucht (“Finde alle Kunden mit PLZ 10115”), sucht eine Vektordatenbank nach Ähnlichkeit (“Finde die 10 Dokumente, die dieser Frage am ähnlichsten sind”).

Warum braucht man eine Vektordatenbank?

Wenn du ein RAG-System baust, musst du:

1. Tausende Dokumente als Embeddings speichern
2. Bei jeder Nutzeranfrage die relevantesten Dokumente in Millisekunden finden
3. Das Ganze skalierbar und zuverlässig betreiben

Eine Vektordatenbank löst genau diese Aufgaben.

Der typische Workflow:

1. Indexierung: Dokumente werden in Chunks aufgeteilt, embeddet und gespeichert
2. Suche: Eine Anfrage wird embeddet und die ähnlichsten Vektoren werden gefunden
3. Ergebnis: Die zugehörigen Dokument-Chunks werden zurückgegeben

Vergleich der Optionen:

Lösung	Vektoren	Latenz	Aufwand	Ideal für
In-Memory (NumPy)	< 10K	Schnell	Minimal	Prototypen
pgvector	< 1M	Gut	Gering	Bestehende PostgreSQL-Infrastruktur
ChromaDB	< 1M	Gut	Gering	Lokale Entwicklung
Qdrant/Weaviate	< 100M	Sehr gut	Mittel	Produktion
Pinecone	< 1B	Sehr gut	Gering (Managed)	Enterprise

Technischer Deep Dive

Indexstrukturen

Die Herausforderung: Exakte Nearest-Neighbor-Suche in hochdimensionalen Räumen ist extrem langsam (O(n) pro Query). Vektordatenbanken nutzen Approximate Nearest Neighbor (ANN) Algorithmen:

HNSW (Hierarchical Navigable Small World):

• Graph-basierter Index mit mehreren Ebenen
• Sehr schnelle Suche mit hoher Genauigkeit (Recall > 95%)
• Standard in den meisten Vektordatenbanken
• Trade-off: Hoher Speicherbedarf (Index im RAM)

IVF (Inverted File Index):

• Teilt den Vektorraum in Cluster (Voronoi-Zellen)
• Suche nur in den nächsten Clustern statt im gesamten Raum
• Weniger Speicher als HNSW, aber etwas langsamer
• Gut kombinierbar mit Product Quantization (IVF-PQ)

Product Quantization (PQ):

• Komprimiert Vektoren durch Aufteilung in Subvektoren
• Drastische Speicherreduktion (z.B. 1536D Float32 → 48 Bytes)
• Trade-off: Leichter Genauigkeitsverlust

Filterung und Hybrid Search

Moderne Vektordatenbanken unterstützen:

Metadata-Filterung:

• Vektoren mit Metadaten versehen (Kategorie, Datum, Autor)
• Filter vor oder nach der Vektorsuche anwenden
• Pre-Filtering: Genauer, aber langsamer
• Post-Filtering: Schneller, aber kann zu wenigen Ergebnissen führen

Hybrid Search:

• Kombination aus Vektorsuche (semantisch) und Keyword-Suche (BM25)
• Reciprocal Rank Fusion (RRF) für die Kombination der Ergebnisse
• Beste Ergebnisse für die meisten Retrieval-Aufgaben

Skalierung und Performance

Sharding:

• Verteilung der Vektoren auf mehrere Nodes
• Horizontale Skalierung für Milliarden von Vektoren

Replikation:

• Kopien der Daten für Hochverfügbarkeit
• Read-Replicas für höheren Durchsatz

Quantisierung:

• Float32 → Float16: 2x weniger Speicher, minimaler Qualitätsverlust
• Float32 → Int8: 4x weniger Speicher
• Binary Quantization: 32x weniger Speicher, für Reranking geeignet

Best Practices

• Embedding-Modell und Datenbank zusammen evaluieren: Die Qualität hängt von beiden ab
• Chunk-Größe testen: 256-1024 Tokens, abhängig vom Use Case
• Overlap verwenden: 10-20% Überlappung zwischen Chunks
• Metadaten mitführen: Quelle, Datum, Kategorie für spätere Filterung
• Monitoring: Latenz, Recall und Relevanz kontinuierlich messen
• Backup-Strategie: Regelmäßige Snapshots der Vektordaten