Phonetic Matching
Rahul, Raahul, Rahool: matching by sound when spelling can't be trusted.
Why this matters
Indian names and Hindi words have no single Latin spelling, and ASR spells what it hears. The same customer can appear as *Mohammed*, *Mohammad*, *Muhammad* and *Mohd* across calls, CRM entries and transcripts. encodes words by approximate pronunciation so spelling variants collide on the same key.
It's also dangerously generous: *loan* and *lone* sound identical, and *Kumar* / *Kumari* share a code but name different people. Knowing where phonetic keys help — and measuring where they hurt — is the point of this lesson.
Core concept
Technical explanation + simple intuition + example
Soundex: a 4-character sound code
Keep the first letter, turn similar-sounding consonants into the same digit, drop vowels, and cut to four characters. Names that sound alike end up with the same code: Rahul, Raahul and Rahool all become R400.
Metaphone: pronunciation rules instead of letter classes
Soundex only groups letters. Metaphone applies English pronunciation rules: PH sounds like F, a K before N is silent, TH is its own sound. It's more accurate for English words — but its rules are English rules, so Hindi names are only approximately handled.
The 10 questions
Every important concept should answer all of these
1What is it?
Encoding words into keys based on approximate pronunciation and comparing keys instead of spellings.
2Why does it exist?
Transliteration and ASR produce spelling variation that edit distance measures poorly (Chaudhary vs Chowdhury differ by several edits).
3What problem does it solve?
It clusters spelling variants of the same spoken word, especially names, for deduplication, lookup and entity linking.
4How does it work internally?
Rule-based encoders (Soundex, Metaphone, Double Metaphone, NYSIIS) map letters/letter-groups to sound classes and simplify.
5What does it look like on real transcript data?
Customer names in CRM vs transcripts (Srinivas / Shrinivas / Sreenivas), agent names, city names. Devanagari text can't be encoded at all without transliteration.
6What can go wrong?
Homophones merge (loan / lone), related but different names merge (Kumar / Kumari), names that sound similar but differ in the first letter split (Sharma / Verma is correct to split, but Kh/K spellings may split wrongly), and non-Latin scripts return nothing.
7How do I evaluate it?
Build labelled pairs (same entity / different entity) and compute pairwise precision and recall of 'same key ⇒ same entity', as the lab does.
8When should I use it?
Name matching and deduplication, candidate generation before a stricter check, spoken-word matching after ASR.
9When should I NOT use it?
As the sole decision rule for merging customer records; for general vocabulary (homophones); for non-Latin scripts without transliteration.
10How does it affect downstream systems?
Wrong merges attach one customer's history to another; missed merges create duplicate leads and inflate counts.
Interactive lab: Phonetic encoder lab
Encode any list of words with Soundex and Metaphone, trace Soundex step by step, then measure pairwise precision/recall of phonetic keys versus edit distance on a labelled set of Indian name variants.
Try it yourself
Conceptual (A), applied (B) and engineering (C) exercises
Graded by a transparent keyword rubric (not an LLM) — it checks for the key ideas, then shows a model answer for self-assessment.
Real-world application
A lender deduplicated leads by Soundex(first name) + Soundex(last name) + city. Duplicate leads fell 40% — and complaints rose: *Kumar Sharma* and *Kumari Sharma* (siblings) in the same city were merged, and one of them stopped receiving callbacks. The fix was to use phonetic keys only for candidate generation, then require an exact phone-number match or human confirmation before merging.
Common mistakes
Codes are coarse by design; different people/words collide.
Fix: Use phonetic keys to generate candidates; confirm with other evidence (phone, DOB, context).
Metaphone's rules model English orthography.
Fix: Measure on your own name pairs; consider transliteration-aware normalization.
Homophones (loan/lone, EMI/Amy) create false matches.
Fix: Restrict to name/entity fields.
Engineering decision
Phonetic keys, edit distance, or both?
- Matching names with transliteration variants
- Generating candidates for deduplication or entity linking
- Short spoken words where spelling is unreliable
- The decision is irreversible (merging records) without confirmation
- Input is not in Latin script
- You're matching general words with many homophones
Quiz
Pass mark 60%. Missed questions go to your mistake log and spaced review.
loan vs lone illustrate a risk of phonetic matching on transcripts?राहुल returns…