VEKTOR-INDEX · AI-KONZEPT

Was ist ein Vektor-Index? HNSW, IVF, ScaNN und Quantisierung Mai 2026

Ein Vektor-Index ist die Datenstruktur einer Vektor-DB, die ähnliche Embeddings schnell findet. Trade-off zwischen Recall, Latenz und Speicher.

Recherche & Faktencheck: DuneDive LLC · Stand: 2026-05

Was ist ein Vektor-Index?

Ein Vektor-Index ist eine Datenstruktur, die einer Vektor-Datenbank erlaubt, in Millisekunden die zu einer Anfrage ähnlichsten Embeddings zu finden. Ohne Index muss die DB jeden gespeicherten Vektor mit dem Anfrage-Vektor vergleichen – bei 10 Millionen Vektoren mit je 1024 Dimensionen ist das jenseits jeder Praxis-Latenz. Der Index strukturiert die Vektoren so, dass die Suche nicht mehr linear, sondern logarithmisch oder sublinear wächst.

Die zentrale Idee ist Approximate Nearest Neighbor (ANN). Eine exakte Suche durch alle Vektoren würde garantiert die echten Top-k Treffer liefern, ist aber zu langsam. ANN-Algorithmen liefern fast immer die richtigen Treffer (Recall typisch 95-99%), aber 100-1000x schneller. Der bewusste Verzicht auf Perfektion ist der Trick.

Mai 2026 dominiert ein Algorithmus diese Welt: HNSW (Hierarchical Navigable Small Worlds). HNSW ist Default in Qdrant, Weaviate, Milvus, pgvector ab Version 0.5, Elasticsearch, OpenSearch, Pinecone. Andere wichtige Algorithmen: IVF (Inverted File, gut für GPU-beschleunigte FAISS-Setups), Annoy (Spotify-Open-Source, etwas älter, dafür extrem speicherarm), ScaNN (Google, in TensorFlow integriert, sehr schnell bei sehr grossen Korpora). Die Wahl hängt von Datenmenge, Recall-Anforderung und Hardware ab.

Warum es zählt

Drei Eigenschaften eines Vektor-Index entscheiden über den Erfolg eines RAG-Systems: Recall, Latenz, Speicher.

Recall ist der Anteil der wirklich relevanten Treffer, die der Index zurückgibt. Ein Recall von 95% heisst: in 5% der Fälle fehlt der wichtigste Treffer im Top-k. Für eine RAG-Anwendung im Treuhand-Kontext mit Beweispflicht ist 99% das Minimum – sonst antwortet das System gelegentlich aus dem falschen Dokument. Recall ist via Index-Parameter steuerbar (M, ef bei HNSW; nlist, nprobe bei IVF), kostet aber Latenz und Speicher.

Latenz ist die Antwortzeit pro Anfrage. HNSW auf modernen CPUs erreicht 1-5 ms für 1 Million Vektoren, 5-30 ms für 10 Millionen, 50-200 ms für 100 Millionen – bei Standard-Parametern. Latenz ist linear-in-log mit Korpus-Grösse, nicht linear-in-Korpus. Das macht HNSW skalierbar.

Speicher ist der RAM-Bedarf pro Index. HNSW braucht typisch 1.5-2x die Vektor-Daten als Index – bei 10 Millionen Vektoren mit 1024 Dimensionen und 4-Byte-Floats sind das 60-80 GB. Quantisierung (siehe unten) reduziert das auf 6-15 GB ohne nennenswerten Recall-Verlust.

Weitere Faktoren: Indexierungs-Geschwindigkeit (HNSW ist langsam zu bauen, schnell zu suchen – IVF ist umgekehrt), Update-Fähigkeit (HNSW unterstützt Inserts/Deletes mit kleinem Performance-Verlust, einige ältere Algorithmen nicht), Hybrid-Suche (Vektor-Suche kombiniert mit Filter-Bedingungen – Mai 2026 in Qdrant und Weaviate stark, in pgvector verbessert sich das mit jeder Release).

Algorithmen im Detail

Vier Algorithmen dominieren Mai 2026 das Feld.

HNSW (Hierarchical Navigable Small Worlds, Malkov & Yashunin, 2018). Baut einen mehrschichtigen Graphen. Obere Schichten sind dünn (wenige Knoten, lange Verbindungen), untere Schichten dicht. Eine Suche startet ganz oben, springt grob in die Nähe des Ziels, geht dann schichtweise hinunter und verfeinert. Die zwei Hauptparameter sind M (Verbindungen pro Knoten, Default 16-32) und ef_construction/ef_search (Suchtiefe, Default 100-500). Höheres ef = mehr Recall, mehr Latenz. HNSW ist der Standard für fast alle Use-Cases mit < 100 Millionen Vektoren.

IVF (Inverted File, Sivic & Zisserman, 2003 mit FAISS-Implementierung). Teilt den Vektor-Raum in Cluster (typisch 1000-100000), jede Anfrage sucht nur in den nearest nprobe Clustern. Schnell zu indexieren, gut auf GPU. Recall schlechter als HNSW bei gleichen Ressourcen, aber bei sehr grossen Korpora (>100 Mio. Vektoren) oder bei GPU-Inferenz oft die bessere Wahl. Bekannt aus FAISS, Milvus.

Annoy (Approximate Nearest Neighbors Oh Yeah, Spotify 2014). Baut mehrere Random-Projection-Trees. Sehr speicherarm, in-memory mappable. Schwächer beim Recall als HNSW, aber wenn Speicher knapp ist und Updates selten, immer noch nützlich. Bekannt aus Spotify-Empfehlungs-Systemen.

ScaNN (Scalable Nearest Neighbors, Google 2020). Quantisierungs-basiert, sehr aggressiv. Erreicht bei korrekter Konfiguration den höchsten Durchsatz pro Hardware-Einheit – aber Indexierung ist aufwendig. In TensorFlow Recommenders und einigen Google-Cloud-Produkten integriert. Für Hyperscale-Setups attraktiv, für KMU mit 1-10 Mio. Vektoren meist Overkill.

Quantisierung als Querschnitt. Mai 2026 wird HNSW zunehmend mit Quantisierung kombiniert: Binary Quantisation (jede Dimension wird auf 1 Bit reduziert – 32x kleiner, Recall fällt auf 80-90% ohne Rescoring, mit Rescoring zurück auf 99%), Scalar Quantisation (jede Dimension auf 8 oder 4 Bit, 4-8x kleiner, marginal weniger Recall). Qdrant 1.10+, Weaviate 1.25+ und pgvector 0.8 unterstützen Mai 2026 alle quantisierte HNSW-Varianten. Speicher-Einsparung 40-90%, bei Recall-Verlust unter 1% mit Rescoring-Schritt.

Index-Auswahl in 5 Schritten

01Datenvolumen abschätzen: heute, in 12 Monaten, in 36 Monaten. Quantität (Vektoren) und Dimension (typisch 384, 768, 1024, 1536).
02Anforderungen festlegen: Ziel-Recall (95% reicht? 99% nötig?), Ziel-Latenz (50 ms? 5 ms?), RAM-Budget, Update-Frequenz.
03Algorithmus wählen: < 100 Mio. Vektoren -> HNSW. > 100 Mio. oder GPU vorhanden -> IVF in FAISS/Milvus. RAM-Knappheit -> Annoy oder Quantisierung.
04Quantisierungs-Strategie: Scalar Quantisation als Default für 4-8x Speicher-Einsparung; Binary Quantisation + Rescoring bei sehr grossen Korpora.
05Recall messen: 50-200 Frage-Antwort-Paare manuell kuratieren, Index-Parameter (ef, M) iterativ anpassen. Erst dann produktiv schalten.

Welcher Index für welchen Fall

Für 95% aller KMU-Anwendungen ist die Antwort: HNSW mit Default-Parametern, optional mit Scalar Quantisation, in Qdrant. Das ist Mai 2026 die richtige Antwort, sofern Sie nicht sehr ungewöhnliche Bedingungen haben.

Konkrete Entscheidungspfade.

1 Million Chunks, RAG für eine Treuhand-Wissensbasis. HNSW Default in Qdrant. 1.5 GB Index in RAM, 2 ms Latenz, 99%+ Recall. Quantisierung optional.

10 Millionen Chunks, RAG für Versicherungs-Schadensregulierung mit Bildern + Text. HNSW mit Scalar Quantisation in Qdrant oder Weaviate. 6-10 GB Index, 10-20 ms Latenz. Falls Bilder einen eigenen Index brauchen: zweite Collection.

100 Millionen Chunks, Konzern-Knowledge-Base. HNSW mit Binary Quantisation und Rescoring; alternativ IVF in Milvus mit GPU. Prüfen, ob Sharding nötig ist (mehrere Replicas, jede mit Teilmenge des Index). Latenz mit korrekter Konfiguration 30-100 ms.

Sehr begrenzter RAM, eingebettetes System. Annoy oder pgvector mit Binary Quantisation. Recall geringer, dafür Mappable in 1-2 GB RAM.

Hybrid-Suche (Vektor + SQL-Filter). Qdrant (sehr stark) oder Weaviate. pgvector kann das, wird aber schwächer mit grösseren Datenmengen. Elasticsearch und OpenSearch können das nativ, sind aber bei reiner Vektor-Last langsamer als spezialisierte DBs.

Mehrere Sprachen (DE/EN/FR/IT). Index-Wahl ist neutral; entscheidend ist das Embedding-Modell (Cohere embed-multilingual-v3, BGE-m3, E5-multilingual). Das ist eine andere Frage – siehe embeddings-und-vektoren.

Wann gar keinen Vektor-Index

Drei Fälle, in denen ein Vektor-Index überflüssig ist oder Schaden anrichtet.

Erstens: zu wenig Daten. Bei weniger als 1000 Vektoren ist eine Brute-Force-Suche durch alle Vektoren in unter 1 ms erledigt. HNSW oder IVF lohnen sich erst ab einigen tausend Vektoren – vorher ist der Index-Overhead grösser als der Nutzen. Qdrant erkennt das und nutzt automatisch Brute-Force unter einem Schwellwert.

Zweitens: Schlüsselwort-Suche reicht. Wenn die Anwendung primär auf exakte Treffer oder Boolean-Logik basiert (z.B. "alle Mandantenakten mit Vertragsdatum 2024 und Status ABGESCHLOSSEN"), ist eine klassische Volltext- oder SQL-Suche schneller und genauer. Vektor-Indizes glänzen bei semantischer Nähe ("Texte, die SINNGEMÄSS zur Frage passen"), nicht bei exakter Filter-Logik. Hybrid-Suche kombiniert beides.

Drittens: stark wechselnde Daten ohne Update-Fähigkeit. HNSW und ScaNN unterstützen Updates, aber jede häufige Inkremental-Indizierung kostet Performance. Wer einen Bestand hat, der minuetlich um 10000 Einträge wechselt, sollte entweder periodisch komplett re-indexieren oder einen Algorithmus mit echter Update-Unterstützung wählen – pgvector mit HNSW ist Mai 2026 dafür brauchbar geworden.

Weitere Falle: blind Default-Parameter übernehmen ohne Recall zu messen. Eine eigene Test-Suite mit 50-200 manuell verifizierten Frage-Antwort-Paaren zeigt, ob der Index die Anforderung erfüllt. Ohne Test misst man nichts und vertraut blind auf Defaults – bei Compliance-relevanter Anwendung gefährlich.

Vor- und Nachteile

STÄRKEN

Sub-Sekunden-Suche bei Millionen Vektoren – RAG-Praxis überhaupt erst möglich
HNSW ist sehr robuster Default – kaum Tuning nötig für den 95%-Fall
Quantisierung 2026 reif – Speicher-Einsparung 40-90% ohne Recall-Verlust
Algorithmen Open-Source, Implementierungen austauschbar (FAISS, hnswlib, Qdrant)

SCHWÄCHEN

Approximate, nicht exakt – 1-5% der Treffer fehlen je nach Parametern
Indexierung kann lange dauern (HNSW: Minuten bis Stunden bei Millionen)
RAM-Bedarf gross ohne Quantisierung – 1.5-2x der Vektor-Daten
Parameter-Tuning erfordert eigene Test-Suite – Default-Werte sind nicht immer optimal

Häufige Fragen

HNSW vs. pgvector – was ist Mai 2026 schneller?

Qdrant mit HNSW ist bei reiner Vektor-Last 2-5x schneller als pgvector mit HNSW (pgvector 0.8) bei gleichen Parametern. Pgvector hat aber den Vorteil, dass Vektoren UND klassische Spalten in derselben Postgres-DB leben – eine Single-Source-of-Truth-Architektur. Bei < 5 Mio. Vektoren und vorhandener Postgres-Infrastruktur ist pgvector die ruhigere Wahl. Ab 10 Mio. Vektoren oder bei hoher Update-Frequenz ist Qdrant die Performance-Wahl.

Was kostet Binary Quantisation an Recall?

Ohne Rescoring fallen Recall typisch von 99% auf 80-90% – ungeeignet für präzise Anwendungen. MIT Rescoring (Top-100 mit Binary suchen, dann mit Original-Vektoren neu sortieren) ist Recall wieder bei 98-99%, bei 30-50x kleinerem Index. Qdrant 1.10+ macht das nativ. Praktisch: 10 Mio. Vektoren x 1024 Dim x 4 Byte = 40 GB -> Binary-Index 1.3 GB plus Original-Vektoren auf Disk. Rescoring kostet 5-15 ms extra Latenz.

Kann ich Vektor-Index auf SQLite oder MariaDB betreiben?

SQLite über sqlite-vec (ab 2024 stabil) ja, bis ca. 100k Vektoren brauchbar. MariaDB hat ab 11.7 (2024) eine eigene VECTOR-Spalte mit HNSW, Mai 2026 produktiv aber noch weniger ausgereift als pgvector. Für Treuhand-/KMU-Setups mit < 50k Dokumenten und vorhandener MariaDB-Infrastruktur ist beides eine Option. Für alles Grössere oder für Hybrid-Suche bleibt Qdrant oder pgvector die bessere Wahl.

Quellen

PASSEND ZU IHREM STACK?

Wie das in Ihrem Betrieb konkret aussieht – 30 Minuten Erstgespräch.

Erstgespräch buchen