Ein Vektor-Index ist die Datenstruktur, die semantische Suche in Produktion schnell macht. Rohe Embedding-Vektoren zu speichern und sie einzeln gegen einen Query-Embedding zu vergleichen funktioniert bei kleinen Datenmengen, kollabiert aber jenseits weniger tausend Datensätze. Ein Vektor-Index nutzt Approximate- Nearest-Neighbour-Algorithmen, um die top-K ähnlichsten Items in einstelligen Millisekunden über Millionen von Datensätzen zurückzugeben.
Die gängigen Algorithmen.
- HNSW (Hierarchical Navigable Small World). Der Produktions-Default. Exzellente Recall, schnelle Queries, moderater Speicher-Footprint. Genutzt von FAISS, Pinecone, Weaviate, pgvector, Qdrant.
- IVF (Inverted File). Clustert Embeddings in Zellen; Queries scannen nur naheliegende Zellen. Schnellerer Build, niedrigerer Recall.
- Flat / Brute Force. Jeden Vektor scannen. Höchster Recall, niedrigste Latenz bei kleiner Datenmenge (unter ~50k Vektoren), kein Index-Build-Schritt.
Wo hosten.
Postgres + pgvector ist der richtige Default für die meisten Teams: Der Vektor-Index lebt in derselben Datenbank wie die übrigen Applikationsdaten, Transaktionen sind atomisch, die operative Komplexität ist minimal. Dedizierte Vektor-Stores (Pinecone, Weaviate, Qdrant) verdienen ihre Kosten über ein paar Millionen Vektoren oder wenn Retrieval der Engpass ist und das Team spezialisiertes Index-Tuning braucht.
Hybrides Retrieval.
Ein Vektor-Index allein verfehlt Exact-Match-Queries — Namen, Codes und seltene Begriffe bekommen schlechten Recall in reiner semantischer Suche. Die produktive Antwort ist hybrides Retrieval: Vektor-Index-Ergebnisse mit BM25-Keyword-Scores via Reciprocal Rank Fusion kombinieren. Die Eval-Harness misst, welche Mischung für die spezifische Query-Verteilung gewinnt, und das Team tunt entsprechend.
Häufige Fragen.
- Was ist ein Vektor-Index?
- Ein Vektor-Index ist die Datenstruktur, die Embedding-Vektoren mit Approximate-Nearest-Neighbour-Lookups speichert und die top-K ähnlichsten Items in Millisekunden über Millionen von Datensätzen liefert. Es ist die produktive Infrastruktur, die semantische Suche und RAG schnell macht.
- Brauche ich eine dedizierte Vektor-Datenbank?
- Wahrscheinlich nicht am Anfang. Postgres + pgvector ist der richtige Default für die meisten Teams: Der Vektor-Index lebt neben den Applikationsdaten, Transaktionen sind atomisch, operative Komplexität minimal. Dedizierte Stores (Pinecone, Weaviate, Qdrant) verdienen ihre Kosten über ein paar Millionen Vektoren oder wenn Retrieval der Engpass ist.
- Was ist der Unterschied zwischen einem Vektor-Index und einem Vektor-Store?
- Ein Vektor-Index ist die Datenstruktur (HNSW, IVF, Flat). Ein Vektor-Store ist der Managed Service oder die Datenbank, die ihn hostet. Postgres + pgvector ist ein Vektor-Store mit einem HNSW-Vektor-Index. Pinecone ist ein Vektor-Store, der seine Index-Implementierung hinter einer API versteckt.
- Soll ich den Vektor-Index auf höheren Recall oder niedrigere Latenz tunen?
- Messen Sie beides gegen Ihre tatsächliche Query-Verteilung. HNSW exponiert zwei Regler: efConstruction (Build-Zeit-Recall) und efSearch (Query-Zeit-Recall). Niedrigeres efSearch ist schneller, verfehlt aber mehr relevante Chunks; höheres efSearch ist langsamer, fängt aber mehr. Die Eval-Harness wählt den richtigen Punkt.
Englische Fassung: Vektor-Index on the EN edition.