ORIGINAL COMPANY-CONTEXT PRACTICE
Match products across business catalogs
Original practice scenario inspired by Reliance Industries Limited's public business context; this is not a reported interview question or a description of its internal systems. A fictional diversified group wants to match product records from several retail catalogs. Identical names can describe different pack sizes, while one product may have several names. Design an entity-matching evaluation.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Define a match as the same sellable product variant, including attributes such as pack size and unit. Text similarity alone cannot resolve identity when a misleading near-match changes what the customer receives.
Work through it
- Build labeled pairs with exact matches, spelling variants, and difficult negatives differing in size or formulation. Separate product families across training and evaluation splits.
- Use identifiers and normalized attributes where reliable, then score candidate pairs. Evaluate candidate retrieval separately from the final match decision.
- Report precision at the automatic-merge threshold and recall including missed candidates. Route ambiguous cases to review and record reversible merge provenance.
Tradeoffs to discuss
- Higher automatic precision usually reduces coverage. A review queue can recover coverage, but its workload and correction rate belong in the evaluation.
Common pitfalls
- Random pairs make negatives unrealistically easy.
- Merging two records is a business action; a high embedding similarity is not sufficient authorization.