Vector Search

Vector Search ist ein Suchverfahren, das Inhalte nach Ähnlichkeit findet statt nach exakten Stichwörtern. Jeder Text, jedes Bild und jedes Produkt wird vorab in eine Zahlenreihe übersetzt (ein sogenanntes Embedding, eine Art Fingerabdruck der Bedeutung). Zur Suchzeit wird die Anfrage in denselben Fingerabdruck übersetzt, und das System liefert die Objekte mit den ähnlichsten Zahlenreihen. Umgesetzt wird das meist mit einem Näherungsverfahren namens ANN (Approximate Nearest Neighbor Search, „ungefähre Nachbarschaftssuche"). Vector Search ist die technische Grundlage von [semantischer Suche](/insights/glossar/semantic-search/), [RAG-Pipelines](/insights/glossar/rag/), Empfehlungssystemen und multimodaler Suche über Text, Bild und Audio.

Was ist Vector Search?

Vector Search beantwortet die Frage: Welche Objekte im Bestand ähneln dem Suchobjekt am meisten? Voraussetzung ist, dass alle Objekte (Textabschnitte, Bilder, Audio-Segmente, Produkte) vorab in Embeddings übersetzt wurden. Diese Zahlenreihen haben eine feste Länge, typisch 384 bis 4.096 Zahlen pro Objekt. Ein [Embedding-Modell](/insights/glossar/embedding-models/) erzeugt diese Zahlenreihen so, dass inhaltlich ähnliche Objekte auch rechnerisch nahe beieinanderliegen. Zur Suchzeit übersetzt dasselbe Modell die Anfrage in eine Zahlenreihe, und der Suchalgorithmus liefert die k ähnlichsten Objekte aus dem Bestand samt Metadaten. Die Ähnlichkeit wird über gängige Distanz- oder Winkelmaße berechnet: Cosinus-Ähnlichkeit (Winkel zwischen zwei Zahlenreihen), Skalarprodukt oder euklidischer Abstand.

Der zentrale technische Baustein ist die Approximate Nearest Neighbor Search (ANN). Eine exakte kNN-Suche vergleicht den Query-Vektor mit jedem Vektor im Bestand und skaliert linear mit dessen Größe; bei Millionen bis Milliarden Vektoren ist das für Latenz-sensible Anwendungen unpraktikabel. ANN-Verfahren nehmen eine geringe Trefferunschärfe (typisch 95 bis 99 Prozent Recall gegenüber exakter kNN) in Kauf und erreichen dafür Latenzen im einstelligen bis niedrigen zweistelligen Millisekunden-Bereich. Verbreitete Verfahren sind Hierarchical Navigable Small World Graphs ([HNSW](https://arxiv.org/abs/1603.09320)) nach Malkov und Yashunin (2016), invertierte Datei-Verfahren mit Produktquantisierung (IVF-PQ) nach Jégou et al. (2011), Locality Sensitive Hashing sowie graphenbasierte SSD-Ansätze wie [DiskANN](https://suhasjs.github.io/files/diskann_neurips19.pdf). Die Wahl bestimmt den Trade-off zwischen Recall, Latenz, Speicherbedarf und Ingest-Kosten.

Der Begriff hat sich als eigene Kategorie durchgesetzt, weil klassische Datenbank- und Such-Indexe strukturell nicht auf Ähnlichkeitsfragen über hochdimensionalen Vektoren ausgelegt sind. Ein B-Tree beantwortet Range- und Equality-Anfragen über einer skalaren Ordnung, ein invertierter Index beantwortet Term-Anfragen über einer Vokabularmenge. Beide Verfahren verlieren ihre Effizienz in hochdimensionalen Räumen („Fluch der Dimensionalität"). ANN-Indexe umgehen das Problem durch Approximation und graphbasierte oder partitionierte Suchstrukturen. Mit dem Aufstieg dichter Foundation-Model-Embeddings und produktiver [RAG-Anwendungen](/insights/glossar/rag/) zwischen 2022 und 2024 wurde Vector Search zum Standard-Baustein moderner Retrieval-Stacks.

Über die reine Nearest-Neighbor-Abfrage hinaus umfassen produktive Vector-Search-Implementierungen weitere Bausteine. Metadaten-Filter (Sprache, Mandant, Dokumentklasse, Zeitraum) grenzen den Suchraum vor oder während der ANN-Suche ein, entweder als Pre-Filter, Post-Filter oder integriert in den Index (Filtered ANN). Namensräume oder Kollektionen erlauben Mandantenfähigkeit. Inkrementeller Ingest erlaubt Updates, ohne den gesamten Index neu zu bauen. Kombinationen mit lexikalischer Suche ergeben [Hybrid Search](/insights/glossar/hybrid-search/); ein nachgelagerter [Reranker](/insights/glossar/reranking/) erhöht die Precision der Top-Kandidaten.

Ausgeführt wird Vector Search an sehr unterschiedlichen Orten. Vector-Native-Datenbanken wie Pinecone, [Weaviate](https://weaviate.io/developers/weaviate), [Milvus](https://milvus.io/docs), Qdrant und Chroma sind vollständig auf ANN ausgerichtet. Extensions bringen die Funktion in bestehende Systeme: pgvector in PostgreSQL, Redis Vector, MongoDB Atlas Vector Search. Volltext-Engines haben kNN-Indexe nachgezogen: Elasticsearch, OpenSearch und Vespa bieten Dense-Vector-Fields mit HNSW. Managed-Angebote koppeln den Index eng an die Datenplattform: Databricks Mosaic AI Vector Search auf Unity-Catalog-Tabellen, Azure AI Search, Google Vertex AI Vector Search, AWS OpenSearch Serverless. SQL-Engines wie Snowflake und BigQuery bieten inzwischen Vector-Search-Funktionen (VECTOR_SEARCH, VECTOR_COSINE_DISTANCE) direkt im SQL-Dialekt an. Die Wahl des Ausführungsorts hängt von Bestandsgröße, Update-Frequenz, Latenz-Anforderung, Governance und Nähe zu den Wahrheitsdaten ab.

Abgrenzung zu Vector Database, Semantic Search, Lexical Search, Hybrid Search und Reranking

Der Begriff wird häufig mit angrenzenden Konzepten vermischt: mit dem Speichersystem, das ihn umsetzt, mit dem Anwendungsziel, das ihn nutzt, mit den lexikalischen Verfahren, denen er gegenübersteht, und mit der Nachbearbeitungsstufe, die auf ihn folgt.

Der Unterschied zu einer [Vector Database](/insights/glossar/vector-database/) ist der zwischen Vorgang und System. Vector Search bezeichnet den Suchvorgang selbst oder ein Feature innerhalb einer bestehenden Plattform (etwa VECTOR_SEARCH in Snowflake, KNN in Elasticsearch, <-> in pgvector). Eine Vector Database ist das eigenständige System, das diesen Vorgang skalierbar umsetzt, mit Index-Verwaltung, Metadaten-Filtern, Ingest-Pfaden und Zugriffssteuerung. Beide Begriffe werden häufig austauschbar verwendet, technisch beschreibt der eine die Funktion, der andere das Produkt. Ein PostgreSQL mit pgvector bietet Vector Search, ohne im engeren Sinn eine Vector-Native-Database zu sein; ein Snowflake mit VECTOR_SEARCH erst recht nicht.

Der Unterschied zu [Semantic Search](/insights/glossar/semantic-search/) ist der zwischen Umsetzung und Ziel. Semantic Search beschreibt das Anwendungsziel: Retrieval nach Bedeutung statt nach exakter Zeichenkette. Vector Search beschreibt das Verfahren: ANN-Suche über dichten Vektoren. Semantische Textsuche ist das dominierende Anwendungsfeld, aber weitere Anwendungsklassen nutzen dieselbe Infrastruktur ohne semantischen Bezug im engeren Sinn: Bild-Ähnlichkeitssuche über visuellen Features, Audio-Fingerprinting, Duplikat-Erkennung und Anomalie-Detektion. Umgekehrt lässt sich Semantic Search prinzipiell auch mit anderen Verfahren umsetzen (etwa Late Interaction über ColBERT oder Cross-Encoder-Scoring über einen kleinen Kandidatenraum), auch wenn Vector Search die dominierende Umsetzung ist. Wer die Begriffe synonym verwendet, macht in produktiven Text-Retrieval-Stacks selten einen Fehler, sollte den Unterschied aber kennen, sobald Bild- oder Audio-Anwendungen dazukommen.

Der Unterschied zu Lexical Search liegt in der Repräsentationsebene. Lexical Search arbeitet mit einem invertierten Index über einem Vokabular: Für jeden Term listet der Index die Dokumente auf, in denen er vorkommt, mit Positionen und Frequenzen. Die Ranking-Funktion (BM25, TF-IDF) gewichtet Term-Frequenz gegen inverse Dokumenten-Frequenz. Zwei Dokumente mit denselben Wörtern gelten als ähnlich, unabhängig von ihrer Bedeutung. Vector Search arbeitet auf einem Vektor-Index über hochdimensionalen Fließkomma-Vektoren: Zwei Dokumente mit ähnlicher geometrischer Position gelten als ähnlich, unabhängig von den verwendeten Wörtern. Lexical Search findet exakte Termübereinstimmungen und deren Stamm-Formen zuverlässig, verfehlt aber Synonyme und Paraphrasen. Vector Search deckt Synonyme, Umschreibungen und multimodale Anfragen ab, verfehlt aber exakte Bezeichner wie Produktcodes, Vertragsnummern oder Ticket-IDs. Beide Verfahren sind komplementär.

Der Unterschied zu [Hybrid Search](/insights/glossar/hybrid-search/) ist der zwischen Komponente und Kombination. Hybrid Search setzt einen lexikalischen und einen Vektor-Retriever parallel ein und fusioniert die Trefferlisten über ein Verfahren wie [Reciprocal Rank Fusion](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf). Vector Search ist der semantische Zweig innerhalb dieser Kombination. Für Anfragen mit exakten Bezeichnern (Vertragsnummern, SKUs, Personennamen) liefert Hybrid Search stabilere Ergebnisse als reine Vector Search, weil der lexikalische Zweig diese Treffer sicher findet. Für rein konzeptuelle Anfragen ohne exakte Kürzel bleibt der Zusatznutzen von Hybrid Search gering und der zusätzliche Index häufig verzichtbar.

Gegen [Reranking](/insights/glossar/reranking/) abgegrenzt: Beide Verfahren sitzen in derselben Pipeline, aber auf unterschiedlichen Stufen. Vector Search ist die Retrieval-Stufe: Aus Millionen Bestandsvektoren wählt der ANN-Index in wenigen Millisekunden eine geordnete Kandidatenliste (typisch Top-50 bis Top-200). Reranking ist die Precision-Stufe: Ein Cross-Encoder oder LLM bewertet die Kandidatenliste erneut, aber tiefer, und sortiert die Top-Kandidaten für die finale Antwort um. Vector Search optimiert Recall pro Millisekunde, Reranking optimiert Precision pro Rechenkosten. Beide Stufen laufen hintereinander in produktiven RAG-Pipelines.

Beispiel: Vector Search als ANN-Retrieval in einer RAG-Pipeline

Ein Konzern betreibt einen internen Wissensassistenten über 800.000 Textabschnitte aus technischen Handbüchern, Verträgen und Support-Tickets. Nach dem [Chunking](/insights/glossar/chunking/) durchläuft jeder Abschnitt das Embedding-Modell voyage-3-large und wird als 1.024-dimensionaler Vektor abgelegt. Der reine Vektor-Speicherbedarf liegt bei rund 3,3 GB (800.000 mal 1.024 mal 4 Byte); mit Metadaten und Original-Text-Verweisen entstehen etwa 6 bis 8 GB Index-Volumen. Der Index nutzt HNSW mit m=16 und ef_construction=200 und liegt in Databricks Mosaic AI Vector Search, gekoppelt an eine Delta-Tabelle im Unity Catalog.

Zur Query-Zeit fragt ein Mitarbeiter: „Was passiert, wenn der Kompressor unter 5 bar Druck abfällt?". Der Application-Layer erzeugt aus der Frage mit demselben voyage-3-large-Modell einen Query-Vektor mit 1.024 Dimensionen. Der Vector-Search-Aufruf läuft mit Metadaten-Filter auf mandant='werk-nord' und sprache='de'. Der HNSW-Index durchsucht die gefilterte Teilmenge und liefert die zwanzig Vektoren mit der höchsten Cosinus-Ähnlichkeit. Die Latenz liegt bei etwa 12 Millisekunden, gemessen zwischen Query-Vektor-Übergabe und Kandidatenliste. Zum Vergleich: Eine exakte kNN-Suche über 800.000 Vektoren würde selbst auf einer optimierten CPU-Implementierung mehrere hundert Millisekunden benötigen.

Die zwanzig Kandidaten laufen anschließend durch einen Cross-Encoder-Reranker (etwa bge-reranker-v2-m3), der die Top-5 nach Relevanz zur Frage umsortiert. Diese Top-5 dienen einem Sprachmodell als Kontext für die Antwortformulierung. Der gesamte Retrieval-Pfad (Embedding, ANN-Suche, Reranking) liegt bei einer Ende-zu-Ende-Latenz von etwa 250 bis 400 Millisekunden; den überwiegenden Anteil trägt der Reranker, die reine Vector Search bleibt unter 20 Millisekunden.

Der Betrieb bringt drei typische Aufgaben mit sich. Erstens die Bindung zwischen Vektoren und Erzeuger-Modell: ein Wechsel des Embedding-Modells (etwa von voyage-3-large auf text-embedding-3-large) macht alle bestehenden Vektoren im Index unbrauchbar, weil die neuen Vektoren in einem anderen semantischen Raum liegen. Der vollständige Neu-Ingest ist Pflicht. Zweitens die Wahl der Index-Parameter: höhere m- und ef_search-Werte bei HNSW verbessern Recall auf Kosten von Speicher und Latenz, IVF-PQ komprimiert Vektoren stark und verbilligt Speicher, verliert dafür aber Trennschärfe. Drittens die Synchronisation mit der Wahrheitsquelle: Ändert sich ein Chunk im Quelldokument, muss der zugehörige Vektor neu berechnet und im Index ersetzt werden. Managed-Angebote wie Databricks Mosaic AI Vector Search automatisieren diesen Ingest über Change-Data-Feed auf der Delta-Tabelle; eigenbetriebene Systeme brauchen eine eigene Ingest-Pipeline mit dedupliziertem Update.