Semantic Product Search 2026: Vektorsuche für Shops

31% (Baymard Institute) aller Produktsuchen in Online-Shops enden 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. Suchende konvertieren bis zu 2-3x höher (Algolia) als reine Browser-Nutzer - im Amazon-Fall steigt die Conversion-Rate von 2% auf 12%. 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. 70% (Baymard) der 60 größten E-Commerce-Shops zeigen bei Synonym-Suchen keine relevanten Treffer. 41% (Baymard) der Shops unterstützen die acht häufigsten Query-Typen nicht vollständig. Branchenweit liegen Null-Result-Raten zwischen 10 und 30% (Lucidworks/Wizzy), ohne intelligente Suche häufig über 25%. Der Algolia-Zielwert für produktive Shops liegt unter 2% - ab 3-5% gilt die Suche als akut sanierungsbedürftig (Algolia).

• 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: In einem Apparel-Case-Study sank die Search-Exit-Rate binnen drei Monaten um 35% (Netguru) nach Einführung von Semantic Search. Globale Cart-Abandonment-Raten liegen bei 70,22%, auf Mobile sogar bei 80,2% (Opensend) - 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. 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. Welches Modell passt, hängt von Katalogvolumen, Sprachen, Latenzbudget und Hosting-Modell ab. Ein wichtiger Befund: Das kompakte E5-small (118M Parameter) schlägt in Benchmarks teils 70-fach größere Modelle und liefert Latenzen unter 30 ms bei bis zu 100% Top-5-Accuracy in E-Commerce-Tests (aimultiple, Supermemory).

Für Shops, bei denen Latenz geschäftskritisch ist, lohnt sich ein Blick auf die Verteilung statt nur auf Mittelwerte: OpenAI text-embedding-3-small zeigt p90-Latenzen um 500 ms, mit p99-Spitzen bis 5 Sekunden (Nixiesearch) - ein Risiko für Live-Search-UX. Self-hosted Modelle auf NVIDIA L4 erreichen rund 2.000 Tokens/s auf 7B-Embedding-Modellen; die Einmal-Indexierung von 1 Mrd. Items dauert grob 5,8 Tage (Baseten/Introl). Dem gegenüber liegen API-Kosten bei 0,02-0,18 USD pro Million Tokens - Make-or-Buy hängt am Volumen und an Compliance-Anforderungen.

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.

• Elasticsearch / OpenSearch: HNSW als dense_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 - 8,9- bis 186-fach schneller als getrennte Indizes (Elastic Labs).

Performance-Zahlen aus Produktions-Benchmarks: Elasticsearch BBQ erreicht laut Elastic 2025 eine 5-fache Geschwindigkeit gegenüber OpenSearch mit FAISS und bis zu 8-fachen Throughput bei gefilterten Queries (Elastic). Typische kNN-Latenzen liegen bei 7-16 ms in Elasticsearch, auch unter Schreib-Last unter 15 ms (Elastic/Baseten). Die Wahl der Datenbank ist weniger eine Empfehlungsfrage als eine Passung zur bestehenden Infrastruktur - alle genannten Systeme sind produktionsreif. Für neue Programmier-Projekte empfiehlt sich ein kleiner Proof of Concept mit echten Katalogdaten statt synthetischen Benchmarks.

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. RRF liefert laut Premai.io +15 bis +30% Recall gegenüber Einzelmethoden. Auf dem WANDS-E-Commerce-Benchmark wurden +1,7% Mean NDCG gegenüber reiner Dense-Suche dokumentiert (Hindsight/Vectorize 2026) - bei gleichzeitig höherer Robustheit.

{
  "retriever": {
    "rrf": {
      "retrievers": [
        {
          "standard": {
            "query": {
              "multi_match": {
                "query": "wasserdichte Laufschuhe Herren Gr 43",
                "fields": ["title^3", "brand^2", "description", "attributes.*"],
                "type": "best_fields",
                "fuzziness": "AUTO"
              }
            }
          }
        },
        {
          "knn": {
            "field": "embedding",
            "query_vector_builder": {
              "text_embedding": {
                "model_id": "e5-small-v2",
                "model_text": "wasserdichte Laufschuhe Herren Gr 43"
              }
            },
            "k": 50,
            "num_candidates": 200
          }
        }
      ],
      "rank_window_size": 100,
      "rank_constant": 60
    }
  },
  "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](/de/blog/produktdaten-ki-optimieren-strukturierte-daten-2026/).

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 deutlich 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 fügen typischerweise 20-80 ms zur Latenz hinzu, je nach Modellgröße und Kandidatenzahl. Auf GPU-Inferenz oder mit quantisierten Modellen bleibt die Pipeline insgesamt unter der Live-Search-Schwelle. 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](/de/blog/generative-engine-optimization-geo-2026/) an, der die SEO-Seite derselben Entwicklung beschreibt.

Quantisierung: Memory-Kosten senken

Ein 1.536-dimensionaler Float32-Vektor belegt 6 KB. Bei 5 Millionen Produkten sind das bereits 30 GB - ohne Replikation, ohne Graph-Overhead. Quantisierung reduziert diesen Footprint drastisch: Scalar INT8 halbiert bis viertelt Memory, Binary Quantization (BBQ) und Product Quantization (PQ) gehen deutlich weiter.

MongoDB Atlas dokumentiert für 15,3 Mio. Vektoren × 2.048 Dim eine Accuracy von 90-95% bei Latenzen unter 50 ms (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: 50-200ms für Live-Search

Live-Search-UX verlangt Antwortzeiten unter 200 ms - darüber beginnen spürbare Wartezeiten. Ein realistisches Budget für die gesamte Pipeline sieht so aus:

Die genannten Werte stammen aus Produktions-Messungen auf Elasticsearch, OpenSearch und Qdrant (Elastic/Baseten). Sie sind als Orientierung zu verstehen - Katalogvolumen, Replikation, Filterung und Netzwerk-Topologie verschieben die Zahlen im Einzelfall. Für global verteilte Shops lohnt der Blick auf [Edge-Caching-Strategien](/de/blog/managed-hosting-online-shops-2026/), 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-Konstraints 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.

Ein Apparel-Retailer dokumentierte nach diesem Vorgehen -35% Search-Exit-Rate binnen drei Monaten (Netguru). Envive berichtet für mittlere Kataloge +8-12%, für Enterprise-Kataloge +15-20% Conversion-Steigerung und +20-25% AOV bei High-Intent-Suchen (Envive 2026). Personalisierte Semantic Search im Algolia-Benchmark zeigt sogar +50% Conversion-Rate (Algolia 2025). Die Zahlen variieren je Branche und Umsetzungsreife - aber die Richtung ist konsistent.

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.