Semantic Search

Semantic Search bezeichnet ein Suchverfahren, das nach der Bedeutung einer Anfrage sucht statt nach den exakten Wörtern. Anfrage und Dokumente werden dazu in Zahlenvektoren ([Embeddings](/insights/glossar/embeddings/)) übersetzt, also in Zahlenreihen, die die Bedeutung eines Texts abbilden. Zwei Vektoren, die nah beieinanderliegen, stehen für Texte mit ähnlicher Bedeutung, auch wenn andere Wörter verwendet werden. Klassische Verfahren wie BM25 (das Ranking-Standardverfahren für Volltext-Suche) oder TF-IDF (Term Frequency, Inverse Document Frequency) vergleichen dagegen nur Zeichenketten und verfehlen deshalb Synonyme, Umformulierungen und umgangssprachliche Anfragen.

Was ist Semantic Search?

Semantic Search verschiebt die Suche von der Ebene der Wörter auf die Ebene der Bedeutung. Ein [Embedding-Modell](/insights/glossar/embedding-models/), meist ein sogenannter Transformer-Encoder (ein trainiertes Sprachmodell), übersetzt Anfrage und Dokumente in Vektoren, also Zahlenreihen mit fester Länge (typisch zwischen 384 und 4.096 Zahlen). Texte mit ähnlicher Bedeutung erzeugen ähnliche Vektoren und liegen im entstehenden Zahlenraum (dem Vektorraum) nahe beieinander, unabhängig davon, welche konkreten Wörter sie verwenden. Wie nah zwei Vektoren beieinanderliegen, misst ein Ähnlichkeitsmaß, meist die Kosinus-Ähnlichkeit (ein Wert zwischen minus eins und eins). Als Ergebnis liefert die Suche die Top-k, also die k nächstgelegenen Dokumente, zurück.

Die Ausführung teilt sich in Index- und Query-Zeit. Zur Indexierung durchlaufen Text-[Chunks](/insights/glossar/chunking/) das Embedding-Modell und landen samt Metadaten in einem Vektor-Index. Gängige Index-Strukturen sind hierarchisch-navigierbare Kleine-Welt-Graphen ([HNSW](https://arxiv.org/abs/1603.09320)), invertierte Datei-Verfahren mit Produktquantisierung (IVF-PQ) oder Late-Interaction-Ansätze wie ColBERTv2, die mehrere Vektoren pro Dokument speichern. Zur Query-Zeit erzeugt dasselbe Embedding-Modell aus der Nutzeranfrage ein Query-Embedding; ein Approximate-Nearest-Neighbor-Algorithmus liefert die Top-k Kandidaten in Millisekunden, ohne den gesamten Index linear zu durchsuchen. Diese Kandidaten laufen häufig durch einen zweiten Schritt ([Reranking](/insights/glossar/reranking/)), bevor sie an ein Sprachmodell oder eine Such-UI übergeben werden.

Der Begriff existiert, weil klassische lexikalische Suche bei Synonymen, Paraphrasen, umgangssprachlichen und mehrsprachigen Anfragen strukturell schwach ist. Ein invertierter Index findet nur Dokumente, die die Query-Terme (oder ihre Stamm-Formen) enthalten. Eine Anfrage nach „Krankmeldung" trifft keine Passagen zu „Arbeitsunfähigkeitsbescheinigung", eine Anfrage nach „Datenpanne" trifft keine Dokumente zu „Data Breach". Semantic Search kodiert Bedeutung geometrisch: Beide Formulierungen erzeugen Embeddings, die im Vektorraum nahe beieinanderliegen, und liefern dieselben Trefferdokumente. Diese Verschiebung ist die Grundlage moderner Retrieval-Stacks in [Enterprise-Search](/insights/glossar/enterprise-search/), [RAG](/insights/glossar/rag/)-Pipelines und Support-Assistenten.

Historisch war [Latent Semantic Indexing (Deerwester et al. 1990)](https://asistdl.onlinelibrary.wiley.com/doi/10.1002/(SICI)1097-4571(199009)41:6%3C391::AID-ASI1%3E3.0.CO;2-9) der konzeptionelle Vorläufer: eine Singulärwertzerlegung der Term-Dokument-Matrix erzeugt einen reduzierten Bedeutungsraum. Die moderne Umsetzung entstand mit Bi-Encoder-Architekturen und kontrastivem Training: Sentence-BERT (Reimers & Gurevych 2019) etablierte gepoolte Satz-Embeddings, [Dense Passage Retrieval (Karpukhin et al. 2020)](https://arxiv.org/abs/2004.04906) zeigte, dass gelernte dichte Repräsentationen BM25 auf Open-Domain-Question-Answering übertreffen. Seit 2022 dominieren Foundation-Model-basierte Embedding-APIs (OpenAI text-embedding-3, Cohere Embed, Voyage, Google Gemini) und Open-Source-Modelle (BAAI/BGE, Nomic, E5); der [MTEB-Benchmark](https://huggingface.co/spaces/mteb/leaderboard) dient als Evaluations-Landkarte.

Der Preis des Verfahrens ist doppelte Infrastruktur (Embedding-Modell im Serving plus Vektor-Index), eine harte Bindung zwischen Vektoren und Erzeuger-Modell (ein Modellwechsel macht alle bestehenden Embeddings unbrauchbar) und eine strukturelle Schwäche bei exakten Bezeichnern. Produktcodes, Vertragsnummern, Ticket-IDs, Eigennamen und Fachkürzel werden im Embedding-Raum verwischt, weil das Modell diese Tokens im Trainingskorpus selten in bedeutungstragendem Kontext gesehen hat. Genau an dieser Grenze setzt [Hybrid Search](/insights/glossar/hybrid-search/) an und kombiniert Semantic Search mit einem lexikalischen Zweig.

Abgrenzung zu Lexical Search, Vector Search, Hybrid Search und Neural Search

Der Begriff wird in der Praxis häufig mit angrenzenden Retrieval-Konzepten und mit seiner eigenen Infrastruktur vermischt. Die Abgrenzung sitzt jeweils an einer klaren funktionalen Grenze.

Der Unterschied zu Lexical Search ist die Repräsentationsebene. Lexical Search arbeitet auf einem invertierten Index: Für jeden Term aus dem Wortschatz führt der Index eine Liste der Dokumente, in denen er vorkommt, mit Positionen und Frequenzen. Die Ranking-Funktion (BM25 oder TF-IDF) gewichtet Term-Frequenz gegen inverse Dokument-Frequenz. Zwei Dokumente mit denselben Wörtern gelten als ähnlich, unabhängig von ihrer Bedeutung. Semantic Search arbeitet umgekehrt auf einem Vektor-Index: Zwei Dokumente mit derselben Bedeutung gelten als ähnlich, unabhängig von den verwendeten Wörtern. Beide Verfahren decken komplementäre Trefferklassen ab und ergänzen sich in Hybrid Search.

Der Unterschied zu Vector Search ist der zwischen Zweck und technischer Umsetzung. Semantic Search beschreibt das Ziel: Retrieval nach Bedeutung. Vector Search beschreibt die Infrastruktur: ein Vektor-Index mit ANN-Suche über dichten Vektoren. Vector Search kann auch nicht-semantische Anwendungen bedienen, etwa Bild-Ähnlichkeitssuche über visuelle Features oder Audio-Fingerprinting; in diesen Fällen sind die Vektoren keine Sprach-Embeddings und die Suche ist nicht semantisch im engeren Sinn. In der Retrieval-Praxis werden die Begriffe synonym benutzt, weil semantische Textsuche das dominierende Anwendungsfeld für Vector Search ist.

Der Unterschied zu Hybrid Search ist der zwischen Komponente und Kombination. Hybrid Search setzt zwei Retriever parallel ein (einen lexikalischen BM25-Retriever und einen semantischen Vektor-Retriever) und fusioniert die Trefferlisten über ein Verfahren wie [Reciprocal Rank Fusion](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf). Semantic Search ist eine der beiden Komponenten, nicht die Alternative dazu. Für Anfragen mit exakten Bezeichnern (Produktcodes, Vertragsnummern) liefert Hybrid Search stabilere Ergebnisse als reine Semantic Search, weil der lexikalische Zweig diese Treffer sicher findet.

Neural Search ist ein Sammelbegriff, der Semantic Search enthält, aber weiter reicht. Er umfasst zusätzlich Cross-Encoder-Reranker, Late-Interaction-Modelle wie ColBERT und LLM-basierte Rank-Modelle wie RankGPT, die Retrieval-Ergebnisse mit neuronalen Modellen weiter verarbeiten. Semantic Search ist die Retrieval-Stufe innerhalb dieses Oberbegriffs.

Full-Text Search ist der Datenbank-nahe Oberbegriff für Verfahren, die auf einem invertierten Index über Volltext-Feldern arbeiten. Elasticsearch, OpenSearch, Postgres tsvector und MySQL FULLTEXT fallen in diese Klasse. Full-Text Search enthält BM25 und TF-IDF als Ranking-Funktionen, aber keine dichten Embeddings. Moderne Volltext-Systeme wie Elasticsearch oder OpenSearch bieten heute zusätzlich einen kNN-Index für Vektoren an; sobald dieser genutzt wird, verlässt das System die reine Full-Text-Klasse und macht Semantic Search verfügbar.

Beispiel: HR-Wissensassistent über Betriebsvereinbarungen

Ein interner Wissensassistent soll Fragen zu Personalrichtlinien und Betriebsvereinbarungen beantworten. Der Dokumentenbestand umfasst 12.000 Text-Chunks aus rund 300 PDF-Dokumenten. Eine Mitarbeiterfrage lautet: „Was passiert, wenn ich krank werde und keine AU einreichen kann?"

In einer reinen BM25-Pipeline über einem Volltext-Index findet das System Passagen, die das Kürzel „AU" enthalten. Es verfehlt allerdings Chunks, in denen von „Arbeitsunfähigkeitsbescheinigung", „Krankmeldung", „Meldepflicht bei Erkrankung" oder „ärztlichem Nachweis" die Rede ist. Genau diese Passagen beantworten die Frage. BM25 hat keine Vorstellung davon, dass „AU" und „Arbeitsunfähigkeitsbescheinigung" dasselbe bezeichnen.

In einer Semantic-Search-Pipeline durchläuft jeder Chunk vorab ein Embedding-Modell (etwa bge-large-de oder text-embedding-3-large) und landet als 1.024-dimensionaler Vektor in einem Vektor-Index. Zur Query-Zeit erzeugt dasselbe Modell aus der Frage ein Query-Embedding. Ein HNSW-Index liefert innerhalb weniger Millisekunden die zehn Chunks, deren Vektoren der Frage im Vektorraum am nächsten liegen, gemessen per Cosinus-Ähnlichkeit. Die Trefferliste enthält Passagen zu „Arbeitsunfähigkeitsbescheinigung", „Nachweispflicht bei Krankheit" und „Meldepflichten bei kurzfristiger Arbeitsunfähigkeit", obwohl keiner dieser Chunks den exakten Term „AU" führt. Ein optionaler Cross-Encoder-Reranker sortiert die Top-10 nach Relevanz um; die Top-3 laufen als Kontext in ein Sprachmodell, das die Antwort mit Quellenverweis formuliert.

Vergleichbare Muster finden sich in produktiven Retrieval-Stacks auf Elasticsearch (kNN Search mit Dense Vector Field), OpenSearch Neural Search, Azure AI Search Vector Search, Weaviate, Qdrant, Pinecone, Milvus, Vespa und Databricks Mosaic AI Vector Search. Für Anfragen mit exakten Bezeichnern (etwa einer konkreten Betriebsvereinbarungs-Nummer) wird Semantic Search in der Regel zu Hybrid Search erweitert, damit der lexikalische Zweig diese Treffer sicher findet.