Category: General
What Is Semantic Product Matching? How the Matching Algorithm Actually Works
From lexical matching to embeddings, retrieval-rerank and hard negative sampling — how Senkrondata matches product titles, step by step.
Every team working with e-commerce, quick-commerce, or marketplace data runs into the same problem sooner or later: you have one product title, and in front of you sits a set of thousands — sometimes millions — of other product titles, and you need to find which one is the same product. A barcode doesn't always help; often all you have is text.
In this post, we share the method we use at Senkrondata to match product titles using text alone: first why the simple approaches fall short, then which techniques we combined to solve it.
Our goal is this: given a product title p, find its corresponding title (if one exists) within an unordered set S = {t₁, t₂, …, tₙ}. That set can be our own catalog (to find duplicates) or a competitor's catalog (for assortment and price comparison).
Method 1 — Lexical Matching
The first, cheapest idea is to break both titles into a bag of words and divide the overlapping word count by the total word count — this is called Intersection over Union (IoU). It can be refined further with TF-IDF weighting and a BM25 similarity score.
This method has two big advantages:
- Speed via an inverted index: an inverted index lets you search for matching words very fast, even across a large set S.
- Off-the-shelf tools: libraries like Lucene make this method easy to implement.
But lexical matching rests on a core assumption: for words in p and t to match, they have to be identical. That assumption breaks constantly in the real world:
| Type of difference | Title A | Title B |
|---|---|---|
| Unit notation | Coca-Cola 1 Lt | Coca-Cola 1000ml |
| Misspelling | Ülker Chocospread 350g | Ulker Choco Spread 350gr |
| Missing word | Nivea Men Deep Shaving Foam 200 ml | Nivea Deep Shaving Foam 200 ml |
This table shows why lexical matching alone isn't enough: you need a method closer to language itself, one that can recognize different phrasings of the same product.
Method 2 — Semantic Encoder (Embeddings)
A Semantic Encoder turns text into a vector (embedding) that captures its meaning, going beyond surface-level word overlap. If two pieces of text carry the same or a very similar meaning, the distance (cosine or Euclidean) between their embeddings should be small.
For this we use an SBERT (Sentence-BERT)-style encoder built on a transformer-based language model, fine-tuned with a Siamese Network architecture. Fine-tuning runs on our own internal dataset: pairs of product titles labeled either "matched" or "not-matched."
The strength of a semantic encoder is catching the same meaning written with different words — "fast USB charger" and "quick charging USB adapter" share almost no words but carry very close meaning, and a good encoder sees that.
But this method has two limits too:
- Contextual limitation: because each title is encoded independently, the model can miss a fine, mutual relationship between two texts — a unit/pack-count difference, say.
- Keyword loss: because embeddings have limited size, the encoder focuses on high-level meaning — certain keywords critical for matching, like brand names, can get lost in that representation.
Method 3 — Retrieval-Rerank
Retrieval-Rerank, a well-established method in information retrieval, balances speed and precision using two distinct stages: a fast but less precise retrieval stage first, followed by a slower, much more accurate reranking stage. The first stage's job is to narrow the field of possible matches, since the second stage is more expensive.
First Stage: Retrieval
The retrieval stage's job is to quickly produce a list of k candidates. You can use either Method 1 or Method 2 for this. We run lexical and semantic retrieval together at this stage: the lexical method cheaply and quickly catches exact word overlaps, while the semantic method also pulls in titles written differently but meaning the same thing — each covers what the other misses.
Second Stage: Reranking
For reranking, we use a transformer-based cross-encoder. Unlike an encoder-only model — which processes inputs independently and produces a separate embedding for each — a cross-encoder examines the input pair together. This joint processing captures the interaction between the two texts and delivers noticeably higher accuracy.
That's especially valuable for tasks requiring a fine-grained read of subtle nuances or contextual similarity. But the cross-encoder's high computational cost is exactly why we reserve it for the second stage — we run it on the small candidate set the first stage has already narrowed down, not on millions of pairs.
Combined, the retrieval-rerank approach strikes a balance between operational efficiency and accuracy: the first stage efficiently filters a huge pool of data, while the second applies a far more rigorous analysis to the narrowed set — high-quality final results without the prohibitive cost of running a cross-encoder over the entire dataset.
Hard Negative Sampling
Hard negative sampling is about selecting negative samples the model struggles to classify correctly — hence "hard." This technique is used to improve model performance by forcing it to genuinely learn to distinguish similar from dissimilar.
To find hard negatives, we primarily rely on an encoder-based approach: we find pairs that are labeled non-matches but whose embeddings turn out surprisingly close — surpassing a set similarity threshold. These pairs count as "hard negatives" because, despite not being a real match, their embeddings suggest high similarity, making them difficult for the model to classify correctly. Once identified, we fine-tune our cross-encoder models on these hard negative samples.
The bottom line
Our method for matching product titles starts with lexical matching in the first stage, then applies a retrieval-rerank approach for efficient, accurate matching. This comprehensive strategy, strengthened by hard negative sampling, lets us effectively identify similar products, manage assortment gaps, and maintain a diverse, accurate product catalog for our customers.
If you want your product matching engine built with this approach, talk to the Senkrondata team.
Emre
Price Intelligence & Data Engineering
Emre writes about the machinery behind competitor price data: product matching, normalization, collection at scale and the analytics layer on top.
More from EmreContact Us
Leave your email address for a detailed demo or overview session, and we will get back to you shortly.
