E-commerce semantic product search

Shoppers who use on-site search are close to buying, yet classic keyword search fails on typos, synonyms, vague or descriptive queries and mixed-language catalogues. Semantic (hybrid) product search adds embeddings and learned re-ranking on top of keyword matching, so "Regenjacke wanderlust leicht" finds the right items even if no product contains those words. For shop owners it means fewer zero-result pages and better discovery; for developers it is a well-understood retrieval stack.

Problem & value

• Today: most shops run keyword search (database LIKE, Elasticsearch/Solr BM25, or the platform default) maintained by hand-written synonym lists, redirects and boost rules. Typical failures: zero-result pages, wrong ranking of accessories vs. main products, no understanding of attributes ("rot", "ab 100 Euro"), poor handling of German compounds and of catalogues in several languages.
• AI value: meaning-based matching (embeddings), query understanding by an LLM or small classifier, learned re-ranking from click/purchase data, less manual synonym maintenance, better long-tail coverage.
• Evidence base: the public Amazon Shopping Queries Dataset (ESCI) provides ~130k queries and ~2.6M human relevance judgements in English, Spanish and Japanese and is the standard benchmark for product ranking [1]. Revenue uplift claims published by search vendors are case-specific and not independent; measure on your own traffic with an A/B test rather than relying on them.

Variants

• SMB shop (Shopware, Shopify, WooCommerce, Magento/Adobe Commerce): plug-in or SaaS search with typo tolerance and semantic fallback; catalogue of hundreds to ~100k SKUs.
• Marketplace / large catalogue: millions of SKUs, learned-to-rank, personalised ranking, ads slots (see REC-013), multilingual and multi-currency.
• B2B / technical wholesale: part numbers, GTIN, technical attributes, cross-references and "which part fits my machine" queries; overlaps with KNOW-004 and KNOW-001.
• Conversational / guided shopping: an LLM asks clarifying questions and returns a shortlist with reasons (agentic assistant, see AGENT-020); retrieval remains the same hybrid index underneath.
• Visual and multimodal search: image or photo query plus text ("like this, but in blue"), see VIS-017.
• Private use: comparison and price-search engines; same techniques, but run by the platform, not the user.

How it works

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: multilingual text embedding models map queries and product texts into one vector space; vector index uses HNSW or similar. Multimodal embeddings can index product images too.
• Hybrid retrieval: keyword search stays essential for exact identifiers (SKU, EAN, model numbers) and brand names; semantic search covers the vocabulary gap. Vendors typically offer presets, e.g. Algolia NeuralSearch runs keyword and vector retrieval separately and merges the normalised lists, with a "conservative" preset that uses semantic results only when keyword search returns nothing [2].
• LLM query understanding: turns "Sneaker weiß Größe 42 unter 100 Euro" into filters (colour, size, price) plus a text query; a small LLM with JSON schema output is sufficient and cacheable.
• Re-ranking: a cross-encoder reranker on the top 50–200 candidates, or gradient-boosted learning-to-rank on behavioural features (see REC-001 for shared ranking signals).
• Human-in-the-loop: merchandisers review top queries, pin/bury products, curate synonyms and inspect zero-result and low-click queries; relevance changes ship only after offline + A/B evaluation.

Data preparation

The raw material is the product catalogue: titles, descriptions, attributes, categories, EAN/GTIN, images, prices and stock. In an SMB it typically lives in the ERP or merchandise system, the shop backend (Shopware, Shopify, WooCommerce), supplier price lists and Excel sheets, plus supplier PDFs and images on file shares. Search quality depends far more on this data than on the model.

Typical gaps are inconsistent or missing attributes (colour, size, material), duplicate products, supplier descriptions copied verbatim, unstructured Excel imports, missing synonyms and shop-specific jargon, and no record of what shoppers searched for without success.

Preparation steps: - Export the catalogue via API or connector (PREP-005) and clean it into tidy tables (PREP-011). - Normalise attributes and category tree, remove duplicates, fill gaps with an LLM plus human spot checks. - Build a synonym and abbreviation list from zero-result queries (PREP-015). - Collect a test set of 100 to 200 real queries with expected hits (PREP-018). - Check whether query logs contain personal data (PREP-025).

Expect roughly 30 to 40 percent of the total effort in data work, mostly one-off catalogue clean-up and then continuous maintenance. See also DATA-007.

Implementation paths

Which path for whom

• SMB: Path A, because mature shop-search products (shop-system plugins, EU-hosted SaaS) deliver hybrid search in days at monthly fees.
• Enterprise: Path B, because search is core to revenue, so own ranking, merchandising logic and behavioural data justify building on embedding and reranker APIs.
• Developer: Path C, because OpenSearch, Typesense or Meilisearch with open embedding models run on HW1 and give full control over ranking.

Path A — Buy (recommended for most shops)

• Search-as-a-service / commerce search: Algolia (NeuralSearch; EU data centres available), 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 regions), Meilisearch Cloud (FR). Mark as EU/GDPR-friendly: the European vendors above, subject to contract and hosting check.
• Shop-platform search: Shopware, Shopify and Adobe Commerce ship built-in search with typo tolerance; semantic add-ons exist per platform. Good enough for small catalogues.
• Choose A when: catalogue < ~1M SKUs, no deep custom ranking logic, small team. Check: EU hosting, DPA, index freshness (price/stock updates in seconds), German compound handling, merchandising UI, export of search logs, exit options.

Path B — Build on cloud APIs

• Embeddings: Mistral Embed (EU provider), Cohere Embed (multilingual, multimodal in v4), Google Gemini Embedding, OpenAI text-embedding-3, Voyage AI; use EU regions where offered. Embeddings are computed offline for the catalogue, so API cost is a one-off per product change; query embeddings are tiny.
• Rerankers: Cohere Rerank, Voyage rerank, Jina Reranker (EU-based company, Berlin), or a self-hosted reranker.
• Query understanding: a small/fast LLM (Claude Haiku class, Mistral Small, Gemini Flash class) with structured output; cache results for frequent queries to keep latency below ~100 ms on the hot path.
• Index: managed OpenSearch/Elasticsearch (hybrid query with normalisation pipeline [3]), Qdrant Cloud (DE/EU regions), Weaviate, Pinecone, or pgvector in PostgreSQL for catalogues up to a few million items.
• Choose B when: you need custom ranking or want to keep the shop's own search UX and data model.

Path C — Self-host (open source)

• Engines: OpenSearch or Elasticsearch (hybrid BM25 + kNN), Typesense (typo tolerance, built-in embeddings, GPL-3 server) [4], Meilisearch (MIT community edition, French origin, hybrid search; semantic features still partly experimental) [5], Qdrant (Berlin), Vespa (strong for learning-to-rank at scale), pgvector.
• Models: Qwen3-Embedding (0.6B/4B/8B, Apache-2.0, 100+ languages, top of MTEB multilingual at release in June 2025) [6], BGE-M3 (dense+sparse), multilingual-e5; rerankers such as bge-reranker-v2-m3 (0.6B, Apache-2.0) [7] or Qwen3-Reranker. Check licences: some popular embedding models (e.g. Jina v3) are non-commercial unless licensed.
• Hardware: HW1 (CPU + small GPU or even CPU only) is enough for query-time inference with small models and a few hundred thousand SKUs; HW2 helps for 4–8B embedders, bulk re-embedding and image embeddings. Query traffic is served from the index; GPU is mainly needed for batch indexing.
• Ops effort: index sync with PIM/ERP, shard/replica sizing, monitoring of latency and relevance drift. Choose C for on-prem or sovereignty requirements, very high query volume or cost control.

Path D — Custom training

Worth it for large catalogues with strong behavioural data: fine-tune an embedding model on query–product click/purchase pairs (contrastive training with hard negatives, ESCI-style labels [1] for evaluation), train a domain reranker or learning-to-rank model, or distil an LLM judge into a small relevance model. Requires tens of thousands of query–product judgements or click logs. Start with off-the-shelf models and fine-tune only if offline nDCG on your own test set plateaus.

State of the art (2026)

• Hybrid is the default: BM25 plus dense (and sometimes learned sparse) retrieval with rank fusion or normalised score merge, followed by cross-encoder reranking. Pure vector search underperforms on identifiers and exact attributes.
• Multilingual and multimodal embeddings: open models such as Qwen3-Embedding lead public multilingual benchmarks [6]; multimodal embedders allow image+text catalogue indexing and "shop the look" search.
• LLMs in the loop: query rewriting and attribute extraction, LLM-as-judge for relevance evaluation (replacing part of the human labelling that datasets like ESCI required [1]), catalogue enrichment (missing attributes, normalised titles) and conversational shopping assistants on top of the search index.
• Evaluation: offline nDCG/MRR on judged query sets, then online A/B tests on conversion and revenue per search session.
• Limits and failure modes: hallucinated product claims in generative answers; semantic drift returning "similar but wrong" items (wrong size, voltage, compatibility); popularity bias; stale price or stock data in the index; compounds and abbreviations in German; cold start for new products; latency from heavy rerankers; cost of LLM query rewriting at high QPS. Exact-match queries (EAN, article numbers) must bypass semantic ranking.

Shared resources & combinations

• Same building blocks (embedding-text + reranker + vector-db + search-engine): KNOW-001 (enterprise search), KNOW-002 (RAG over documents), KNOW-004 (technical manuals), DOC-014 (document parsing for RAG) — one embedding service and one vector/hybrid cluster (HW1–HW2) can serve all of them.
• Ranking and personalisation: REC-001 (product recommendations) shares behavioural signals and feature store; REC-013 (retail media) shares the ranking slots and auction logic.
• Catalogue quality: DATA-007 (metadata enrichment) and LLM attribute extraction improve search recall directly.
• Assistants and agents: AGENT-020 (e-commerce operations agent) and conversational shopping use the search index as a tool.
• Visual: VIS-017 (visual product recognition) supplies image embeddings for multimodal queries.
• Demand side: PRED-001 (demand forecasting) can feed stock-aware ranking (boost available items).

Effort, cost & KPIs

• Path A: days to a few weeks (catalogue feed, synonyms, UI widgets); SaaS fees usually scale with records and search requests.
• Path B: 1–3 months for hybrid retrieval, reranking, evaluation harness and A/B infrastructure.
• Path C: 2–4 months plus ongoing ops; main cost is engineering and cluster operations, not GPUs.
• Path D: additional 2–3 months for data preparation, training and validation.
• Cost drivers: catalogue size and update rate, query volume, reranker depth, LLM calls per query, index replicas.
• KPIs: zero-result rate, search CTR, add-to-cart and conversion rate of search sessions, revenue per search session, nDCG@10 on a judged query set, query latency (p95), share of reformulated queries, merchandiser time spent on synonyms.

People & change

Involve management for budget and goals, the e-commerce or marketing lead as process owner, and the merchandisers who set boosts and synonyms from the start; they know the catalogue and will tune the system daily. IT or the agency handles the integration; suppliers matter where their product data is poor.

Works council: normally not required, because shoppers and not employees are the users and no employee behaviour is monitored. Inform the works council early anyway (§90(1) no. 3 BetrVG) if merchandisers' work processes change, and check §87(1) no. 6 if tool logs show individual staff activity.

Data protection: query and click logs can be personal data. Involve the DPO, sign an AVV (Art. 28 GDPR) with every SaaS vendor, anonymise logs and run a DPIA only if profiling at scale is added.

AI literacy: support staff with a short session on how semantic ranking works and where it errs (Art. 4 AI Act, GUIDE-006). Start with a pilot on one category or an A/B test on part of the traffic (GUIDE-009). Typical concern: "the algorithm hides my products"; address it with merchandising rules (pins, boosts) that humans keep control of, and transparent dashboards. Also see GUIDE-008.

Risks, regulation & compliance

• EU AI Act: minimal risk for ranking and query understanding; AI literacy duty (Art. 4) applies to staff. Art. 50 transparency duties apply if a chatbot/shopping assistant interacts with people (disclose it is AI) or generates synthetic content. Manipulative or exploitative personalisation (Art. 5) must be avoided, e.g. exploiting vulnerabilities of children.
• Digital Services Act: online marketplaces and platforms must explain the main ranking parameters (Art. 27 DSA) and very large platforms must offer a non-profiling option; the Platform-to-Business Regulation (EU) 2019/1150 requires disclosure of ranking parameters to business users [8][9]. Sponsored results must be labelled (see REC-013).
• GDPR: query logs and click histories are personal data when linked to users or sessions; personalised ranking needs a legal basis (consent or legitimate interest, ePrivacy for cookies), data minimisation and retention limits; DPA with search vendors; check third-country transfers for US vendors.
• Consumer law: ranking must not mislead (UWG, Omnibus Directive requires disclosure of paid placement and main ranking parameters).
• Mitigations: fall back to keyword search, block-lists and rules for regulated goods (age-restricted products, medicines), log pseudonymised queries, test for biased or self-preferencing ranking, keep generative answers grounded in catalogue data.

Getting started

1. Export the last 3 months of search logs; compute zero-result rate, top queries and reformulation rate as baseline.
2. Build a judged test set of 200–500 real queries (include typos, German compounds, long-tail, identifier queries).
3. Try one Path A product and one open stack (e.g. OpenSearch or Typesense plus Qwen3-Embedding) on the same catalogue sample.
4. Compare nDCG@10 offline, then run a 2–4 week A/B test on a traffic share with conversion as the primary metric.
5. Add query understanding and merchandising controls; review zero-result and low-click queries weekly.

Sources

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