Semantic Product Matching Using Retrieval-Rerank Architecture

delivery_hero · E-commerce · 2024 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: E-commerce product matching and assortment intelligence

Delivery Hero needed to identify similar or duplicate product titles across its own and competitor catalogs for pricing, assortment gap analysis, and duplicate detection.

Constraints:

• Product matching must work from product titles even when descriptions use different units, spellings, or missing words.
• Pure lexical matching is efficient but requires overlapping tokens.
• Sentence encoders capture semantic similarity but can miss pairwise nuances and important keywords such as brands.
• Cross-encoders are more accurate but too computationally heavy to score every possible pair directly.

Architecture

Delivery Hero evolved from lexical matching to an SBERT semantic encoder and then to a retrieval-rerank architecture: lexical matching and inverted indexes produce a fast candidate set, a transformer cross-encoder reranks the reduced set with pairwise context, and hard-negative sampling from close-but-not-matching pairs fine-tunes the reranker to distinguish subtle product-title differences.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  A["Input product title"] --> C["Lexical retrieval stage"]
  B["Candidate title set"] --> C
  C --> D["Candidate shortlist"]
  D --> E["Cross-encoder reranker"]
  B --> F["Hard-negative mining"]
  F --> G["Hard-negative training set"]
  G --> E
  E --> H["Matched product output"]

Components

Data flow

A product title is matched against an unordered candidate set. Lexical retrieval rapidly narrows candidates using word overlap, TF-IDF/BM25, and inverted indexes. A transformer cross-encoder then jointly scores candidate pairs, and hard negatives mined from embedding-near nonmatches are used to fine-tune the cross-encoder.

Why this architecture

The final architecture keeps lexical retrieval for efficient candidate generation while reserving the cross-encoder's more expensive pairwise reasoning for a narrowed candidate set.

Models used: SBERT · Transformers-based Large Language Model · transformer-based cross-encoder

Scale

• The candidate set can be large enough that the first stage must rapidly process many documents.
  “making it well-suited for rapidly processing a large number of documents to extract a manageable subset of candidates.”article, stated
• Hard negatives are selected above a predefined similarity threshold.
  “possess embeddings that are surprisingly close to each other, surpassing a predefined similarity threshold.”article, stated

Alternatives considered (roads not taken)

Lexical matching as the full solution

Rejected because: Lexical matching is efficient but fails when semantically equivalent product titles use different words, spellings, sizes, or missing descriptors.

Semantic encoder alone

Rejected because: Encoding titles independently can miss pairwise context and important keywords needed for exact product matching.

Cross-encoder over the entire candidate set

Rejected because: The cross-encoder is computationally intensive, so it is reserved for a reduced set from retrieval.

Patterns

retrieval-ranking (retrieval)

Delivery Hero uses a two-stage retrieval-rerank pipeline where fast retrieval narrows candidates and a cross-encoder reranks the shortlist.

hybrid-search (retrieval)

The system combines lexical BM25-style retrieval with transformer semantic reranking.

fine-tuning-adaptation (model-adaptation)

Delivery Hero fine-tuned SBERT and cross-encoder models on internal matched/not-matched product-pair data and hard negatives.

Tradeoffs

Use lexical matching for retrieval.

Chose BM25/inverted-index lexical first stage over semantic cross-encoder scoring for every candidate.

Rationale: Lexical retrieval is fast and cost-effective for candidate generation, while cross-encoding is reserved for a smaller set.

Use a cross-encoder only after retrieval.

Chose slower pairwise reranking on a reduced candidate set over faster independent embeddings alone.

Rationale: The cross-encoder captures text interactions that independent encoders miss, but its cost requires a narrowed candidate list.

Gotchas (what bit them)

Lexical methods miss real matches with different wording.

Root cause: The same product may be represented with different units, spelling variants, or omitted descriptive words.

Resolution: Add semantic encoders and cross-encoder reranking to capture meaning and pairwise context.

Independent embeddings can lose important pairwise distinctions.

Root cause: Sentence encoders encode each title separately and compress details into a limited embedding.

Resolution: Use a cross-encoder reranker on a smaller candidate set for joint pair processing.

Hard negatives can look semantically close without being true matches.

Root cause: Nonmatching product pairs can have embeddings above a similarity threshold.

Resolution: Mine those close nonmatches and use them to fine-tune the cross-encoder.

Evaluation

Delivery Hero evaluates product matching by comparing lexical, semantic encoder, and retrieval-rerank approaches on labeled product-title pairs, including hard negatives mined from close embeddings.

Metrics: product-pair match labels · embedding similarity threshold · candidate retrieval quality · reranker accuracy

Outcomes

• Delivery Hero landed on a retrieval-rerank architecture for efficient and accurate matching.
• The system supports pricing strategy, assortment gap analysis, and duplicate-item detection.
• Hard-negative sampling improves discrimination between true matches and semantically close nonmatches.

The article does not publish catalog size, latency, or offline accuracy numbers.