Semantische Produktsuche im E-Commerce

Kundinnen und Kunden, die die Shop-Suche nutzen, stehen kurz vor dem Kauf – doch die klassische Stichwortsuche scheitert an Tippfehlern, Synonymen, vagen oder beschreibenden Anfragen und mehrsprachigen Katalogen. Die semantische (hybride) Produktsuche ergänzt die Stichwortsuche um Embeddings und gelerntes Re-Ranking, sodass "Regenjacke wanderlust leicht" die passenden Artikel findet, auch wenn kein Produkt diese Wörter enthält. Für Shop-Betreiber bedeutet das weniger Seiten ohne Treffer und bessere Produktentdeckung; für Entwickler ist es ein gut verstandener Retrieval-Stack.

Problem & Nutzen

• Heute: Die meisten Shops betreiben eine Stichwortsuche (Datenbank-LIKE, Elasticsearch/Solr BM25 oder die Plattform-Standardsuche), gepflegt über handgeschriebene Synonymlisten, Weiterleitungen und Boost-Regeln. Typische Schwächen: Seiten ohne Treffer, falsche Rangfolge von Zubehör und Hauptprodukten, kein Verständnis von Attributen ("rot", "ab 100 Euro"), schlechter Umgang mit deutschen Komposita und mit Katalogen in mehreren Sprachen.
• KI-Nutzen: Bedeutungsbasierter Abgleich (Embeddings), Anfrageverständnis durch ein LLM oder einen kleinen Klassifikator, gelerntes Re-Ranking aus Klick- und Kaufdaten, weniger manuelle Synonympflege, bessere Abdeckung des Long Tails.
• Evidenzbasis: Der öffentliche Amazon Shopping Queries Dataset (ESCI) liefert rund 130.000 Anfragen und etwa 2,6 Mio. menschliche Relevanzbewertungen auf Englisch, Spanisch und Japanisch und ist der Standard-Benchmark für das Produkt-Ranking [1]. Von Suchanbietern veröffentlichte Umsatzsteigerungen sind fallspezifisch und nicht unabhängig geprüft; messen Sie mit einem A/B-Test auf Ihrem eigenen Traffic, statt sich auf sie zu verlassen.

Varianten

• KMU-Shop (Shopware, Shopify, WooCommerce, Magento/Adobe Commerce): Plug-in oder SaaS-Suche mit Fehlertoleranz und semantischem Fallback; Katalog von einigen hundert bis etwa 100.000 Artikeln (SKUs).
• Marktplatz / großer Katalog: Millionen SKUs, Learning-to-Rank, personalisiertes Ranking, Werbeplätze (siehe REC-013), mehrsprachig und mit mehreren Währungen.
• B2B / technischer Großhandel: Teilenummern, GTIN, technische Attribute, Querverweise und Anfragen wie "welches Teil passt zu meiner Maschine"; Überschneidung mit KNOW-004 und KNOW-001.
• Dialogorientierte / geführte Kaufberatung: Ein LLM stellt Rückfragen und liefert eine Auswahlliste mit Begründungen (agentischer Assistent, siehe AGENT-020); darunter bleibt derselbe hybride Index für das Retrieval.
• Visuelle und multimodale Suche: Bild- oder Fotoanfrage plus Text ("wie dieses, aber in Blau"), siehe VIS-017.
• Privatnutzung: Vergleichs- und Preissuchmaschinen; gleiche Techniken, aber betrieben von der Plattform, nicht von den Nutzenden.

So funktioniert es

1. catalogue feed / PIM (ETL, enrichment)
2. text normalisation (compounds, units, language) + optional LLM attribute enrichment
3. indexing: inverted index (BM25) + dense embeddings (title+attributes, optionally image)
4. query time: spell-correction
5. query understanding (intent, filters, language)
6. hybrid retrieval (BM25 + vector, fused via RRF or normalised scores)
7. re-ranking (cross-encoder or learned-to-rank with sales/click signals, business rules)
8. results + facets + autocomplete
9. click/purchase logging
10. offline evaluation + A/B test

• Embeddings: Mehrsprachige Text-Embedding-Modelle bilden Anfragen und Produkttexte in einem gemeinsamen Vektorraum ab; der Vektorindex nutzt HNSW oder ähnliche Verfahren. Multimodale Embeddings können auch Produktbilder indexieren.
• Hybrides Retrieval: Die Stichwortsuche bleibt unverzichtbar für exakte Kennungen (SKU, EAN, Modellnummern) und Markennamen; die semantische Suche überbrückt die Vokabellücke. Anbieter liefern meist Voreinstellungen, z. B. führt Algolia NeuralSearch Stichwort- und Vektorsuche getrennt aus und führt die normalisierten Listen zusammen, mit einer "konservativen" Voreinstellung, die semantische Treffer nur nutzt, wenn die Stichwortsuche nichts liefert [2].
• LLM-Anfrageverständnis: Wandelt "Sneaker weiß Größe 42 unter 100 Euro" in Filter (Farbe, Größe, Preis) plus eine Textanfrage um; ein kleines LLM mit JSON-Schema-Ausgabe genügt und lässt sich zwischenspeichern.
• Re-Ranking: Ein Cross-Encoder-Reranker auf den Top 50–200 Kandidaten oder Gradient-Boosted Learning-to-Rank auf Verhaltensmerkmalen (gemeinsame Ranking-Signale siehe REC-001).
• Mensch-in-der-Schleife (Human-in-the-Loop): Merchandiser prüfen Top-Anfragen, pinnen oder verdrängen Produkte, pflegen Synonyme und untersuchen Anfragen ohne Treffer und mit wenigen Klicks; Relevanzänderungen gehen erst nach Offline- und A/B-Auswertung live.

Datenaufbereitung

Das Rohmaterial ist der Produktkatalog: Titel, Beschreibungen, Attribute, Kategorien, EAN/GTIN, Bilder, Preise und Lagerbestände. In einem KMU liegt er typischerweise im ERP- oder Warenwirtschaftssystem, im Shop-Backend (Shopware, Shopify, WooCommerce), in Lieferanten-Preislisten und Excel-Tabellen sowie in Lieferanten-PDFs und Bildern auf Dateiablagen. Die Suchqualität hängt weit stärker von diesen Daten ab als vom Modell.

Typische Lücken sind uneinheitliche oder fehlende Attribute (Farbe, Größe, Material), doppelte Produkte, wortwörtlich übernommene Lieferantenbeschreibungen, unstrukturierte Excel-Importe, fehlende Synonyme und shopspezifischer Jargon sowie keine Aufzeichnung darüber, wonach Kundinnen und Kunden erfolglos gesucht haben.

Schritte der Aufbereitung: - Den Katalog per API oder Konnektor exportieren (PREP-005) und in saubere Tabellen überführen (PREP-011). - Attribute und Kategoriebaum normalisieren, Duplikate entfernen, Lücken mit einem LLM plus stichprobenartiger menschlicher Prüfung füllen. - Aus Anfragen ohne Treffer eine Synonym- und Abkürzungsliste aufbauen (PREP-015). - Einen Testsatz aus 100 bis 200 echten Anfragen mit erwarteten Treffern zusammenstellen (PREP-018). - Prüfen, ob die Anfrage-Logs personenbezogene Daten enthalten (PREP-025).

Rechnen Sie mit etwa 30 bis 40 Prozent des Gesamtaufwands für die Datenarbeit, überwiegend einmalige Katalogbereinigung und danach laufende Pflege. Siehe auch DATA-007.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, weil ausgereifte Shop-Suchprodukte (Plug-ins für Shop-Systeme, in der EU gehostetes SaaS) hybride Suche innerhalb weniger Tage zu monatlichen Gebühren liefern.
• Großunternehmen: Weg B, weil die Suche umsatzkritisch ist; eigenes Ranking, eigene Merchandising-Logik und Verhaltensdaten rechtfertigen den Aufbau auf Embedding- und Reranker-APIs.
• Entwickler: Weg C, weil OpenSearch, Typesense oder Meilisearch mit offenen Embedding-Modellen auf HW1 laufen und volle Kontrolle über das Ranking geben.

Weg A — Kaufen (Standardsoftware; für die meisten Shops empfohlen)

• Search-as-a-Service / Commerce-Suche: Algolia (NeuralSearch; EU-Rechenzentren verfügbar), Bloomreach, Constructor, Coveo, Klevu (FI), Doofinder (ES), Empathy.co (ES), Luigi's Box (CZ), FACT-Finder (DE), Findologic (DE/AT), epoq (DE), Elastic Cloud (EU-Regionen), Meilisearch Cloud (FR). Als EU- bzw. DSGVO-freundlich einzustufen: die oben genannten europäischen Anbieter, vorbehaltlich Vertrags- und Hosting-Prüfung.
• Plattform-Suche der Shop-Systeme: Shopware, Shopify und Adobe Commerce liefern eine eingebaute Suche mit Fehlertoleranz; semantische Erweiterungen gibt es je Plattform. Für kleine Kataloge gut genug.
• A wählen, wenn: Katalog < ca. 1 Mio. SKUs, keine tiefgehende individuelle Ranking-Logik, kleines Team. Prüfen: EU-Hosting, AVV, Aktualität des Index (Preis-/Bestandsupdates in Sekunden), Umgang mit deutschen Komposita, Merchandising-Oberfläche, Export der Such-Logs, Ausstiegsmöglichkeiten.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Embeddings: Mistral Embed (EU-Anbieter), Cohere Embed (mehrsprachig, multimodal in v4), Google Gemini Embedding, OpenAI text-embedding-3, Voyage AI; EU-Regionen nutzen, wo angeboten. Embeddings werden vorab für den Katalog berechnet, sodass die API-Kosten je Produktänderung einmalig anfallen; Anfrage-Embeddings sind winzig.
• Reranker: Cohere Rerank, Voyage rerank, Jina Reranker (Unternehmen mit Sitz in der EU, Berlin) oder ein selbst betriebener Reranker.
• Anfrageverständnis: Ein kleines, schnelles LLM (Klasse Claude Haiku, Mistral Small, Gemini Flash) mit strukturierter Ausgabe; Ergebnisse häufiger Anfragen zwischenspeichern, um die Latenz auf dem heißen Pfad unter ca. 100 ms zu halten.
• Index: Verwaltetes OpenSearch/Elasticsearch (Hybrid-Abfrage mit Normalisierungs-Pipeline [3]), Qdrant Cloud (DE/EU-Regionen), Weaviate, Pinecone oder pgvector in PostgreSQL für Kataloge bis zu einigen Millionen Artikeln.
• B wählen, wenn: Sie ein individuelles Ranking benötigen oder die eigene Such-UX und das eigene Datenmodell des Shops behalten wollen.

Weg C — Selbst betreiben (Open Source)

• Engines: OpenSearch oder Elasticsearch (hybrid BM25 + kNN), Typesense (Fehlertoleranz, eingebaute Embeddings, GPL-3-Server) [4], Meilisearch (MIT-Community-Edition, französischer Ursprung, Hybridsuche; semantische Funktionen teils noch experimentell) [5], Qdrant (Berlin), Vespa (stark für Learning-to-Rank im großen Maßstab), pgvector.
• Modelle: Qwen3-Embedding (0,6B/4B/8B, Apache-2.0, über 100 Sprachen, bei Veröffentlichung im Juni 2025 Spitzenreiter im mehrsprachigen MTEB) [6], BGE-M3 (dicht+sparse), multilingual-e5; Reranker wie bge-reranker-v2-m3 (0,6B, Apache-2.0) [7] oder Qwen3-Reranker. Lizenzen prüfen: Einige beliebte Embedding-Modelle (z. B. Jina v3) sind ohne Lizenz nur nicht-kommerziell nutzbar.
• Hardware: HW1 (CPU + kleine GPU oder sogar nur CPU) reicht für die Inferenz zur Anfragezeit mit kleinen Modellen und einigen hunderttausend SKUs; HW2 hilft bei 4–8B-Embeddern, massenhaftem Neu-Embedding und Bild-Embeddings. Der Anfrageverkehr wird aus dem Index bedient; die GPU wird vor allem für die Batch-Indexierung gebraucht.
• Betriebsaufwand: Index-Synchronisation mit PIM/ERP, Dimensionierung von Shards/Replikaten, Überwachung von Latenz und Relevanzdrift. C wählen bei On-Premises- oder Souveränitätsanforderungen, sehr hohem Anfragevolumen oder zur Kostenkontrolle.

Weg D — Eigenes Training

Lohnt sich für große Kataloge mit starken Verhaltensdaten: ein Embedding-Modell auf Anfrage-Produkt-Paaren aus Klicks/Käufen feintunen (kontrastives Training mit schwierigen Negativbeispielen, Labels im ESCI-Stil [1] zur Evaluation), einen domänenspezifischen Reranker oder ein Learning-to-Rank-Modell trainieren oder ein LLM als Bewerter in ein kleines Relevanzmodell destillieren. Erfordert zehntausende Anfrage-Produkt-Bewertungen oder Klick-Logs. Beginnen Sie mit fertigen Modellen und nehmen Sie ein Feintuning erst vor, wenn der Offline-nDCG auf Ihrem eigenen Testsatz stagniert.

Stand der Technik (2026)

• Hybrid ist der Standard: BM25 plus dichtes (manchmal auch gelernt-sparses) Retrieval mit Rangfusion oder normalisierter Score-Zusammenführung, gefolgt von Cross-Encoder-Reranking. Reine Vektorsuche schneidet bei Kennungen und exakten Attributen schlechter ab.
• Mehrsprachige und multimodale Embeddings: Offene Modelle wie Qwen3-Embedding führen öffentliche mehrsprachige Benchmarks an [6]; multimodale Embedder erlauben die Indexierung von Bild+Text im Katalog und eine "Shop the Look"-Suche.
• LLMs in der Schleife: Umformulierung von Anfragen und Attributextraktion, LLM-as-Judge zur Relevanzbewertung (ersetzt einen Teil der menschlichen Bewertung, die Datensätze wie ESCI erforderten [1]), Katalogaufwertung (fehlende Attribute, normalisierte Titel) und dialogorientierte Kaufassistenten auf dem Suchindex.
• Evaluation: Offline-nDCG/MRR auf bewerteten Anfragesätzen, danach Online-A/B-Tests zu Conversion und Umsatz je Suchsitzung.
• Grenzen und Fehlerbilder: Halluzinierte Produktaussagen in generativen Antworten; semantische Abweichung, die "ähnliche, aber falsche" Artikel liefert (falsche Größe, Spannung, Kompatibilität); Popularitätsverzerrung; veraltete Preis- oder Bestandsdaten im Index; Komposita und Abkürzungen im Deutschen; Kaltstart bei neuen Produkten; Latenz durch aufwendige Reranker; Kosten für LLM-Anfrageumformulierung bei hohen Anfragen pro Sekunde. Exakte Anfragen (EAN, Artikelnummern) müssen das semantische Ranking umgehen.

Gemeinsame Bausteine & Kombinationen

• Gleiche Bausteine (embedding-text + reranker + vector-db + search-engine): KNOW-001 (Enterprise Search), KNOW-002 (RAG über Dokumente), KNOW-004 (technische Handbücher), DOC-014 (Dokumentenparsing für RAG) – ein Embedding-Dienst und ein Vektor-/Hybrid-Cluster (HW1–HW2) können sie alle bedienen.
• Ranking und Personalisierung: REC-001 (Produktempfehlungen) teilt Verhaltenssignale und Feature Store; REC-013 (Retail Media) teilt die Ranking-Plätze und die Auktionslogik.
• Katalogqualität: DATA-007 (Metadaten-Anreicherung) und LLM-Attributextraktion verbessern den Recall der Suche unmittelbar.
• Assistenten und Agenten: AGENT-020 (E-Commerce-Betriebsagent) und dialogorientierte Kaufberatung nutzen den Suchindex als Werkzeug.
• Visuell: VIS-017 (visuelle Produkterkennung) liefert Bild-Embeddings für multimodale Anfragen.
• Nachfrageseite: PRED-001 (Bedarfsprognose) kann bestandsabhängiges Ranking speisen (verfügbare Artikel bevorzugen).

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis wenige Wochen (Katalog-Feed, Synonyme, UI-Widgets); SaaS-Gebühren skalieren meist mit Datensätzen und Suchanfragen.
• Weg B: 1–3 Monate für hybrides Retrieval, Reranking, Evaluationsumgebung und A/B-Infrastruktur.
• Weg C: 2–4 Monate plus laufender Betrieb; Hauptkosten sind Entwicklung und Cluster-Betrieb, nicht GPUs.
• Weg D: zusätzlich 2–3 Monate für Datenaufbereitung, Training und Validierung.
• Kostentreiber: Katalogumfang und Aktualisierungsrate, Anfragevolumen, Reranker-Tiefe, LLM-Aufrufe je Anfrage, Index-Replikate.
• Kennzahlen: Quote ohne Treffer, Such-CTR, Warenkorb- und Conversion-Rate der Suchsitzungen, Umsatz je Suchsitzung, nDCG@10 auf einem bewerteten Anfragesatz, Anfrage-Latenz (p95), Anteil umformulierter Anfragen, Zeitaufwand der Merchandiser für Synonyme.

Menschen & Veränderung

Beziehen Sie von Anfang an die Geschäftsführung für Budget und Ziele ein, die E-Commerce- oder Marketingleitung als Prozessverantwortliche sowie die Merchandiser, die Boosts und Synonyme festlegen; sie kennen den Katalog und werden das System täglich nachjustieren. Die IT oder die Agentur übernimmt die Integration; Lieferanten sind dort wichtig, wo ihre Produktdaten schlecht sind.

Betriebsrat: In der Regel nicht erforderlich, weil Kundinnen und Kunden und nicht Beschäftigte die Nutzer sind und kein Mitarbeiterverhalten überwacht wird. Informieren Sie den Betriebsrat dennoch frühzeitig (§ 90 Abs. 1 Nr. 3 BetrVG), wenn sich die Arbeitsabläufe der Merchandiser ändern, und prüfen Sie § 87 Abs. 1 Nr. 6, wenn Tool-Logs die Aktivität einzelner Beschäftigter zeigen.

Datenschutz: Anfrage- und Klick-Logs können personenbezogene Daten sein. Binden Sie die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten ein, schließen Sie mit jedem SaaS-Anbieter einen AVV (Art. 28 DSGVO) ab, anonymisieren Sie Logs und führen Sie eine DSFA nur durch, wenn Profiling in großem Umfang hinzukommt.

KI-Kompetenz: Unterstützen Sie die Beschäftigten mit einer kurzen Schulung dazu, wie semantisches Ranking funktioniert und wo es irrt (Art. 4 KI-Verordnung, GUIDE-006). Starten Sie mit einem Pilotprojekt für eine Kategorie oder einem A/B-Test auf einem Teil des Traffics (GUIDE-009). Typische Sorge: "der Algorithmus versteckt meine Produkte"; begegnen Sie ihr mit Merchandising-Regeln (Pins, Boosts), die in menschlicher Hand bleiben, und mit transparenten Dashboards. Siehe auch GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Minimales Risiko für Ranking und Anfrageverständnis; die Pflicht zur KI-Kompetenz (Art. 4) gilt für die Beschäftigten. Die Transparenzpflichten nach Art. 50 greifen, wenn ein Chatbot/Kaufassistent mit Menschen interagiert (Hinweis, dass es sich um KI handelt) oder synthetische Inhalte erzeugt. Manipulative oder ausbeuterische Personalisierung (Art. 5) ist zu vermeiden, z. B. das Ausnutzen von Schwächen von Kindern.
• Digital Services Act: Online-Marktplätze und Plattformen müssen die wichtigsten Ranking-Parameter erläutern (Art. 27 DSA), und sehr große Plattformen müssen eine Option ohne Profiling anbieten; die Platform-to-Business-Verordnung (EU) 2019/1150 verlangt die Offenlegung der Ranking-Parameter gegenüber gewerblichen Nutzern [8][9]. Gesponserte Ergebnisse müssen gekennzeichnet werden (siehe REC-013).
• DSGVO: Anfrage-Logs und Klickverläufe sind personenbezogene Daten, wenn sie Nutzern oder Sitzungen zugeordnet werden; personalisiertes Ranking braucht eine Rechtsgrundlage (Einwilligung oder berechtigtes Interesse, ePrivacy für Cookies), Datenminimierung und Speicherfristen; AVV mit Suchanbietern; Drittlandübermittlungen bei US-Anbietern prüfen.
• Verbraucherrecht: Das Ranking darf nicht irreführen (UWG; die Omnibus-Richtlinie verlangt die Offenlegung bezahlter Platzierungen und der wichtigsten Ranking-Parameter).
• Gegenmaßnahmen: Rückfall auf die Stichwortsuche, Sperrlisten und Regeln für regulierte Waren (altersbeschränkte Produkte, Arzneimittel), pseudonymisierte Anfragen protokollieren, auf verzerrtes oder selbstbevorzugendes Ranking testen, generative Antworten an Katalogdaten binden.

Erste Schritte

1. Die Such-Logs der letzten 3 Monate exportieren; Quote ohne Treffer, Top-Anfragen und Umformulierungsrate als Ausgangswert berechnen.
2. Einen bewerteten Testsatz aus 200–500 echten Anfragen aufbauen (mit Tippfehlern, deutschen Komposita, Long Tail, Kennungsanfragen).
3. Ein Produkt für Weg A und einen offenen Stack (z. B. OpenSearch oder Typesense plus Qwen3-Embedding) am selben Katalogausschnitt testen.
4. Den nDCG@10 offline vergleichen, dann einen 2–4-wöchigen A/B-Test auf einem Traffic-Anteil mit Conversion als Hauptkennzahl durchführen.
5. Anfrageverständnis und Merchandising-Steuerung ergänzen; Anfragen ohne Treffer und mit wenigen Klicks wöchentlich prüfen.

Quellen

1. Amazon Science — Shopping Queries Dataset (ESCI) — https://github.com/amazon-science/esci-data
2. Algolia — NeuralSearch (hybrid keyword + vector, presets) — https://www.algolia.com/doc/guides/getting-started/neuralsearch/
3. OpenSearch — Hybrid search documentation — https://docs.opensearch.org/latest/vector-search/ai-search/hybrid-search/index/
4. Typesense — open-source search engine (README) — https://github.com/typesense/typesense
5. Meilisearch — open-source search engine (README) — https://github.com/meilisearch/meilisearch
6. Qwen3-Embedding-8B model card — https://huggingface.co/Qwen/Qwen3-Embedding-8B
7. BAAI bge-reranker-v2-m3 model card — https://huggingface.co/BAAI/bge-reranker-v2-m3
8. Regulation (EU) 2022/2065 (Digital Services Act) — https://eur-lex.europa.eu/eli/reg/2022/2065/oj
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj