Semantic Product Search 2026: Vektorsuche für Shops

Ein erheblicher Teil der Produktsuchen in Online-Shops endet ergebnislos – obwohl das gesuchte Produkt im Katalog vorhanden ist. Klassische Keyword-Suche auf Basis von BM25 scheitert an Synonymen, Intent-Varianten und Long-Tail-Queries. Semantic Product Search mit Vektor-Embeddings, HNSW-Index und Cross-Encoder-Reranking schließt diese Lücke technisch. In Microsofts Azure-AI-Search-Auswertung erreicht Hybrid-Retrieval mit nachgeschaltetem Semantic Ranker NDCG@3 60,1 gegenüber 43,8 bei reiner Vektor-Suche (Microsoft Azure AI Search). Für Online-Shops und Shopware-Projekte ist eine moderne Hybrid-Search-Architektur damit ein direkter Hebel auf Umsatz, AOV und Bestandsausnutzung.

Wo klassische Keyword-Suche scheitert

BM25 und Varianten sind seit über 30 Jahren der Standard für Full-Text-Retrieval. Sie gewichten Terme nach Häufigkeit, Dokumentlänge und inverser Dokumentfrequenz – und liefern in vielen E-Commerce-Szenarien solide Grundergebnisse. Sobald eine Query jedoch von der im Katalog gespeicherten Wortwahl abweicht, fällt die Trefferqualität steil ab. Synonyme, Tippfehler, Maß- und Mengenangaben sowie beschreibende Suchen ohne Produktnamen führen regelmäßig zu leeren Ergebnisseiten. Wie hoch der Anteil im eigenen Shop ist, zeigt nur die eigene Suchstatistik: Null-Result-Rate, Suchabbruchrate und die Liste der häufigsten ergebnislosen Queries gehören in jedes Shop-Reporting.

• Synonyme und Jargon: „Turnschuh“ vs. „Sneaker“ vs. „Laufschuh“ – BM25 behandelt diese als unabhängige Tokens.
• Intent-Varianten: „Laufschuhe für Asphalt“ vs. „Straßen-Laufschuhe“ beschreiben dasselbe, teilen aber kaum Terme.
• Long-Tail-Queries: Natürliche Formulierungen wie „bequeme wasserdichte Schuhe für Herbstwanderungen“ matchen selten 1:1.
• Fehltoleranz: Tippfehler, abweichende Schreibweisen, zusammengesetzte deutsche Komposita.
• Multilinguale Kataloge: Internationale Shops mit Queries in mehreren Sprachen benötigen sprachübergreifende Repräsentationen.
• Attribut-Semantik: „Maschinenwaschbar“ als Query findet keine Produkte, deren Beschreibung nur „bei 30 Grad waschen“ enthält.

Die Folgen sind messbar: Wer Suchergebnisse nicht findet, verlässt die Seite oder bricht im Warenkorb ab. Das Baymard Institute mittelt aus 50 Studien eine globale Warenkorbabbruchrate von 70,22% (Baymard Institute) – schlechte Suche ist einer der Treiber. Wer Suchqualität ernst nimmt, greift direkt in die zentralen KPIs ein, die auch die Checkout-Optimierung adressiert.

Vektor-Embeddings: Semantik als Zahlenraum

Ein Embedding ist eine dichte numerische Repräsentation eines Textes, Bildes oder gemischten Objekts. Ein Sprachmodell bildet einen Produkttitel wie „Wasserdichte Trail-Laufschuhe Herren Gr. 43“ auf einen Vektor mit typischerweise 384 bis 2.048 Dimensionen ab – voyage-3-large deckt die Spanne von 256 bis 2.048 Dimensionen ab (Voyage AI). Produkte mit ähnlicher Bedeutung – auch bei unterschiedlichem Wortlaut – erhalten Vektoren, die im Raum nahe beieinander liegen. Semantic Search nutzt genau diese Eigenschaft: Die Query wird in denselben Vektorraum eingebettet und per Abstandsmaß (Cosine, Dot-Product, L2) mit allen Produktvektoren verglichen.

Damit lassen sich Synonyme, Paraphrasen und sprachliche Intent-Variationen implizit abdecken – ohne manuell gepflegte Wörterbücher. Embedding-Modelle werden häufig auf MS MARCO, BEIR oder domänenspezifischen E-Commerce-Datensätzen vortrainiert und lassen sich via Fine-Tuning auf Shop-spezifische Produktsprache anpassen.

Embedding-Modelle im Vergleich

Die Modelllandschaft ist breit: Sentence-BERT-Varianten auf MS-MARCO, die E5-Familie (small/base/large), multilingual-e5-large für Cross-Language, kommerzielle APIs wie OpenAI text-embedding-3-small oder voyage-3-large mit 2.048 Dimensionen (Voyage AI). Welches Modell passt, hängt von Katalogvolumen, Sprachen, Latenzbudget und Hosting-Modell ab. Kompakte Modelle wie E5-small (118M Parameter) halten Speicherbedarf und Antwortzeit niedrig, große und mehrsprachige Modelle decken heterogene Kataloge besser ab – welche Kombination trägt, zeigt erst ein Benchmark auf den eigenen Katalogdaten.

Für Shops, bei denen Latenz geschäftskritisch ist, lohnt sich ein Blick auf die Verteilung statt nur auf Mittelwerte: Ein gehosteter Embedding-Dienst antwortet im Mittel schnell, über das Gefühl der Live-Suche entscheiden aber die Ausreißer am oberen Ende. Wer p95 und p99 nicht misst, optimiert am Nutzererlebnis vorbei. Self-hosted Modelle auf eigener GPU nehmen diese Unsicherheit aus der Kette und machen die Einmal-Indexierung großer Kataloge zu einem planbaren Batch-Job – dafür wandern Betrieb und Kapazitätsplanung in den Shop. Make-or-Buy hängt am Volumen, an der Latenzanforderung und an Compliance-Vorgaben.

HNSW-Index und Vector-Datenbanken

Eine lineare Nachbarschaftssuche über Millionen Produktvektoren ist in Millisekunden-Budgets nicht machbar. Hier kommt HNSW (Hierarchical Navigable Small World) ins Spiel – ein graphbasierter Approximate-Nearest-Neighbor-Index, der in mehreren Schichten hierarchisch navigiert und in logarithmischer Zeit relevante Nachbarn findet. Kernparameter sind die Graph-Konnektivität (M), der Bauzeit-Parameter (efConstruction) und der Query-Parameter (efSearch bzw. num_candidates), der Recall gegen Latenz abwägt.

• OpenSearch: HNSW als knn_vector-Feld, enge BM25-Integration in derselben Query.
• Qdrant: Rust-basierte Vector-Engine mit Payload-Filtern, Quantisierung und Hybrid-Search-Primitives.
• Weaviate: Schema-getriebene Vector-DB mit integrierten Modulen für Generative-Search.
• pgvector (PostgreSQL): HNSW- und IVFFlat-Indizes direkt in der Relation – interessant, wenn der Shop bereits auf PostgreSQL läuft.
• Milvus: Skaliert auf Milliarden Vektoren, starke Quantisierungs-Optionen (PQ, SQ, BBQ).
• Lucene-basierte Unified-Indizes: Kombinieren BM25 und HNSW in einem Segment – ein Index, eine Query, keine getrennte Synchronisierung.

Die Wahl der Datenbank ist weniger eine Empfehlungsfrage als eine Passung zur bestehenden Infrastruktur – alle genannten Systeme sind produktionsreif. Entscheidend sind vier Punkte: Speicherbedarf je Vektor, Verhalten bei gefilterten Queries, Aufwand für Index-Aktualisierungen im laufenden Betrieb und die Frage, wer den Betrieb übernimmt. Für neue Programmier-Projekte empfiehlt sich ein kleiner Proof of Concept mit echten Katalogdaten statt synthetischer Benchmarks – ein Fremdbenchmark bildet weder den eigenen Katalog noch den eigenen Query-Mix ab.

Hybrid-Search: BM25 + Dense + RRF

Rein dichte Suche verliert bei exakten Produkt-IDs, SKUs, Marken- und Maßangaben: Wer „ISO 9001 Edelstahl 304“ eingibt, will keine semantisch ähnlichen Produkte, sondern exakte Term-Matches. Rein sparse Suche (BM25) verliert bei Synonymen und natürlicher Sprache. Die Antwort ist Hybrid-Search: Beide Retriever laufen parallel, ihre Ergebnislisten werden fusioniert.

Der robusteste Fusions-Mechanismus ist Reciprocal Rank Fusion (RRF): Die Rang-Position eines Dokuments in beiden Listen wird addiert (gewichtet invers) – ohne dass Score-Skalen normalisiert werden müssen. In Microsofts Azure-AI-Search-Auswertung übertrifft Hybrid-Retrieval die Einzelmethoden über alle Query-Typen hinweg: Auf den Kundendatensätzen erreicht reine Keyword-Suche NDCG@3 40,6, reine Vektor-Suche 43,8 und Hybrid 48,4; mit nachgeschaltetem Semantic Ranker steigt der Wert auf 60,1 – ein Vorsprung von 11,7 Punkten gegenüber Hybrid ohne Reranking (Microsoft Azure AI Search).

{
  "query": {
    "hybrid": {
      "queries": [
        {
          "multi_match": {
            "query": "wasserdichte Laufschuhe Herren Gr 43",
            "fields": ["title^3", "brand^2", "description", "attributes.*"],
            "type": "best_fields",
            "fuzziness": "AUTO"
          }
        },
        {
          "neural": {
            "embedding": {
              "query_text": "wasserdichte Laufschuhe Herren Gr 43",
              "model_id": "e5-small-v2",
              "k": 50
            }
          }
        }
      ]
    }
  },
  "search_pipeline": "hybrid-rrf-pipeline",
  "size": 20
}

Der Trick liegt in sinnvoller Feld-Gewichtung: Titel und Marke per BM25 mit höherem Boost, Beschreibung und Attribute primär über das Embedding. Für einen technischen Überblick zur Datenmodellierung lohnt der Blick auf den Beitrag zu Produktdaten-Optimierung mit KI.

Zur Robustheit gehört außerdem ein Query-Routing: Ist eine Query eine reine SKU, greift ein Exact-Match-Pfad mit Keyword-Boost. Ist sie sehr kurz (1–2 Tokens), gewinnt BM25 an Gewicht; ist sie lang und natürlich-sprachlich, liefert die Dense-Seite mehr Relevanz. Diese Weichen werden üblicherweise per Heuristik oder einem kleinen Classifier vor dem Retrieval getroffen und verhindern, dass die Hybrid-Suche pauschal „durchschnittliche“ Ergebnisse liefert, statt die jeweilige Query-Klasse sauber zu bedienen.

Cross-Encoder Reranking als zweite Stufe

Hybrid-Retrieval liefert typischerweise 50–200 Kandidaten. Der Cross-Encoder ist ein zweites, präziseres Modell, das jedes Query-Produkt-Paar gemeinsam enkodiert und einen Relevanz-Score berechnet. Anders als der Bi-Encoder (ein Vektor pro Seite) sieht der Cross-Encoder Query und Dokument simultan und erreicht höhere Präzision – zum Preis höherer Rechenkosten. Deshalb wird er nur auf den Top-K-Kandidaten der ersten Stufe angewendet.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")

def rerank(query: str, candidates: list[dict], top_n: int = 20) -> list[dict]:
    pairs = [(query, c["title"] + " " + c["description"]) for c in candidates]
    scores = reranker.predict(pairs, batch_size=32)
    for c, s in zip(candidates, scores):
        c["rerank_score"] = float(s)
    return sorted(candidates, key=lambda x: x["rerank_score"], reverse=True)[:top_n]

Cross-Encoder verlängern die Antwortzeit, wie stark, hängt von Modellgröße, Hardware und Kandidatenzahl ab. GPU-Inferenz, quantisierte Modelle und eine begrenzte Kandidatenliste halten den Zuschlag klein; wie groß er im eigenen Shop ausfällt, zeigt die Messung im eigenen Stack. Der Qualitätsgewinn ist bei mehrdeutigen Queries und feinen Intent-Unterschieden am größten – also genau dort, wo klassische Suche versagt.

In der Praxis bewährt sich ein Zwei-Modell-Setup: ein kleines Reranker-Modell (z. B. MiniLM-L-6) für den Hot-Path mit strikten Latenzvorgaben, ein größeres Modell (z. B. MonoT5 oder bge-reranker-base) im Async-Pfad für Recommendation-Listen, Kategorie-Seiten oder SEO-Programme wie Programmatic-SEO. Cross-Encoder profitieren zudem von Feature-Anreicherung: Statt nur Titel und Beschreibung zu enkodieren, lassen sich Marke, Hauptkategorie und ein oder zwei zentrale Attribute als Text-Präfix mitgeben. Das hebt den NDCG-Gewinn messbar an, ohne das Modell austauschen zu müssen.

Query Expansion mit LLMs

Vor dem Retrieval kann ein LLM die Query umformulieren, erweitern oder strukturieren: Synonyme erzeugen, implizite Attribute extrahieren, Rechtschreibfehler korrigieren, oder eine natürliche Sprache in eine strukturierte Filter-Query plus Freitext-Teil zerlegen. Das ist besonders wertvoll für Voice Commerce und Chat-Interfaces, die im Beitrag zu Voice Commerce ausführlicher beschrieben sind.

{
  "system": "Du bist ein E-Commerce-Query-Parser. Extrahiere strukturierte Filter und eine bereinigte Freitext-Query. Antworte ausschließlich als JSON.",
  "user": "bequeme wasserdichte Laufschuhe Herren Größe 43 fürs Joggen im Herbst",
  "expected_output": {
    "freetext": "wasserdichte Laufschuhe Herbst",
    "filters": {
      "category": "Laufschuhe",
      "gender": "Herren",
      "size_eu": 43,
      "feature": ["wasserdicht", "komfort"]
    },
    "synonyms": ["Runningschuhe", "Jogging-Schuhe", "Trail-Runner"]
  }
}

In Kombination mit einem Synonym-Graphen aus Katalog- und Suchlog-Daten entsteht eine Query-Understanding-Stufe, die natürliche Nutzersprache auf die im Katalog verwendete Fachsprache abbildet – ohne starre Regelbasis. Vorsicht: LLM-Calls erhöhen Latenz und Kosten; für High-Frequency-Queries lohnt Caching auf normalisierter Query-Ebene.

Ein weiterer Baustein ist Retrieval-Augmented Generation (RAG) für Beratungs-Queries: Fragen wie „Welcher Laufschuh passt bei Überpronation?“ werden gegen die Top-K-Ergebnisse plus relevante Ratgeberinhalte formuliert. Das Modell antwortet erklärend und verweist auf konkrete Produkte – sinnvoll insbesondere in beratungsintensiven Kategorien. Thematisch knüpft das an den Beitrag zu Generative Engine Optimization an, der die SEO-Seite derselben Entwicklung beschreibt.

Quantisierung: Memory-Kosten senken

Ein Float32-Vektor belegt 4 Byte je Dimension (Elastic) – bei 1.536 Dimensionen also rund 6 KB je Produkt. Für einen Beispielkatalog mit 5 Millionen Produkten sind das bereits rund 30 GB, ohne Replikation und ohne Graph-Overhead. Quantisierung reduziert diesen Footprint deutlich: Scalar INT8 speichert ein Byte je Dimension, Binary Quantization (BBQ) und Product Quantization (PQ) gehen weiter.

MongoDB dokumentiert für quantisierte Vektoren eine Speicherreduktion von 73% bis 96% bei erhaltener Recall-Leistung der Scalar-Quantisierung (MongoDB) – Quantisierung ist damit nicht mehr experimentell, sondern Production-Default. Die richtige Wahl hängt von Recall-Anforderung, Kandidatenzahl und davon ab, ob eine Rescoring-Stufe auf höherer Präzision nachgeschaltet werden kann.

Latenz-Budget: welche Stufen bei Live-Search Zeit kosten

Live-Search antwortet auf jeden Tastendruck, darum addiert sich jede Stufe der Pipeline unmittelbar zur Wartezeit. Welche Stufen je Ansatz anfallen und wovon ihre Dauer abhängt:

Wie lange jede Stufe dauert, zeigt erst die Messung am eigenen Katalog – Katalogvolumen, Replikation, Filterung und Netzwerk-Topologie bestimmen sie im Einzelfall. Für global verteilte Shops lohnt der Blick auf Edge-Caching-Strategien, die Search-Antwortzeiten regional reduzieren.

Praktische Stellhebel zur Einhaltung des Budgets: Query-Embedding auf einem dedizierten Inference-Server mit warmem Modellcache halten, Kandidatenzahl (num_candidates) sinnvoll begrenzen, Cross-Encoder auf Top-30 bis Top-50 beschränken und zugunsten von Batch-Inferenz bündeln. Auf Infrastruktur-Ebene helfen HTTP/2 bzw. HTTP/3, gRPC für interne Hops und strikte Timeouts pro Stufe – ein langsamer Reranker soll die Suche nicht blockieren, sondern auf das Hybrid-Ergebnis zurückfallen. Monitoring auf p50/p95/p99 ist Pflicht, nicht Kür.

Typische Fehler bei Semantic-Rollouts

• Dense-only statt Hybrid: Der schnellste Weg zu „die Suche findet meine SKU nicht mehr“. Hybrid ist die sichere Default-Wahl.
• Fehlende Evaluation-Suite: Ohne offline Metriken (nDCG@10, Recall@50, MRR) und A/B-Tests online lässt sich keine Veränderung belegen.
• Produktdaten ignoriert: Ein Embedding ist nur so gut wie der Input. Dünn beschriebene Produkte ergeben unscharfe Vektoren.
• Keine Negativ-Signale: Click-Logs und Käufe liefern wichtige Feedback-Daten – wer sie nicht nutzt, verschenkt das wertvollste Fine-Tuning-Signal.
• Reranker immer und überall: Cross-Encoder nur auf Top-K anwenden, nicht auf die gesamte Ergebnisliste.
• Vergessene Kategorien/Filter: Semantische Treffer müssen innerhalb aktiver Filter und Lagerbestands-Constraints bleiben.
• Kein Fallback: Wenn der Vector-Service kurz hängt, muss BM25 weiterliefern – sonst bricht die Suchfunktion komplett weg.
• Modell-Drift: Sprache und Katalog ändern sich. Ohne regelmäßiges Re-Indexing und Re-Evaluation veraltet die Suche schleichend.

Umsetzungs-Fahrplan in 6 Phasen

1. Baseline messen: Null-Result-Rate, Click-Through auf Top-5, Search-Exit-Rate, Conversion-Rate Search-User vs. Non-Search. Ohne Baseline keine belegbaren Gewinne.
2. Daten aufräumen: Titel, Kategorien, Attribute, Synonyme. Embeddings sind nur so präzise wie der Produkttext – siehe PIM-Strategie.
3. Modell wählen und indexieren: Einmal-Embedding des Katalogs, Speicherung in HNSW-Index, Quantisierung aktivieren. Re-Indexing-Workflow definieren.
4. Hybrid-Query bauen: BM25 + kNN parallel, RRF-Fusion, Feld-Boosts tunen. Filter-Constraints einbinden.
5. Reranker integrieren: Cross-Encoder auf Top-50, Latenz messen, Modellgröße justieren. Offline-Evaluation gegen Baseline.
6. A/B-Test und Iteration: Online-Rollout mit Traffic-Split, Conversion-Messung, Fine-Tuning auf Click- und Kauf-Signale. Danach kontinuierliches Monitoring.

Ob sich der Aufwand gelohnt hat, zeigt die eigene Messung: Null-Result-Rate, Suchabbruchrate, Conversion-Rate der Suchsitzungen und der Umsatzanteil über die Suche. Diese vier Werte gehören vor dem Umbau erhoben und danach im selben Zeitfenster erneut – so lässt sich der Effekt von Saisonalität und parallelen Kampagnen trennen. Personalisierung wirkt je nach Branche und Umsetzungsreife unterschiedlich stark; belastbar ist am Ende nur der Vorher-Nachher-Vergleich im eigenen Shop.

Suche als Produkt-Discovery-Engine

Semantic Product Search ist 2026 kein experimentelles Add-on mehr, sondern infrastrukturelle Basis moderner Shops. Die Bausteine – Embeddings, HNSW, Hybrid-Fusion, Reranking, Quantisierung – sind produktionsreif, belegbar wirksam und mit vertretbarem Latenz-Budget integrierbar. Wer die Suche als reine Filter-Fassade behandelt, verschenkt nicht nur Conversion, sondern verliert Boden gegenüber Shops, die Suche als primäre Discovery-Engine begreifen. Für einen strategischen Einstieg bieten sich der Überblicksartikel zu KI-gestützter Produktsuche sowie der Beitrag zu KI-Produktempfehlungen an – beide beschreiben komplementäre Bausteine derselben Discovery-Architektur.