Skip to content
goutham.dechineni

Freelance project

TransFuzzy

Problem
The same Indian name can be written in several scripts, and spelled several ways in each, so exact string search across records misses the person.
Approach
Detect the input script, transliterate to one common romanisation (ITRANS), generate candidates, and score each pair with phonetic, edit-distance and MiniLM embedding features in a RandomForest, with rule overrides for clear cases.
Result
A Flask service that takes a name in any supported Indian script and returns its matches written back in that same script.
My role
Freelance AI engineer (2024–2025). Designed and built the system end to end for a client: matching pipeline, model and service.
Stack
  • Python
  • indic-transliteration (ITRANS)
  • jellyfish
  • fuzzywuzzy
  • sentence-transformers (MiniLM)
  • scikit-learn RandomForest
  • Flask

01

Architecture

  1. Name: the user enters a name in any supported Indian script.
  2. Script detection works out which script the input is written in, so the right transliteration scheme is used.
  3. Transliteration converts the name into ITRANS, one shared Latin romanisation, so names from different scripts can be compared directly.
  4. Candidate generation produces the names to score against the input.
  5. Similarity features: for each candidate pair, Soundex and Metaphone phonetic codes (compared with fuzzy string matching), Levenshtein and Jaro-Winkler edit-distance measures, and the cosine similarity of MiniLM embeddings.
  6. RandomForest turns the features into a match score; a few rules override it in clear-cut cases.
  7. Results are converted back into the script the user typed in, so they read naturally.

02

Key decisions

  • Pivot through one romanisation instead of converting script to script

    Mapping every script to ITRANS needs one converter per script instead of one for every pair, and the phonetic and edit-distance features only need to work on Latin text. The cost is that romanisation loses some distinctions between scripts, which the fuzzy features then have to absorb.

  • Hand-built similarity features and a RandomForest, not an end-to-end neural matcher

    Phonetic codes (Soundex, Metaphone) and edit-distance measures (Levenshtein, Jaro-Winkler) capture how Indian names vary in spelling, need little training data, run on a CPU, and the forest shows which features matter. The cost is a ceiling: the model only knows the similarities it was given, so a variation none of them capture is missed.

  • Rule overrides on top of the model

    Rules make clear-cut cases behave predictably, whatever the model learned. The cost is rules that someone has to maintain, and they can mask cases where the model is wrong in a way worth fixing.

03

Results

  • Matches names across Indian scripts and spelling variants through one pipeline, and returns them in the user's own script.
  • Combines four classic string similarities with embedding similarity, so it catches both spelling and sound variations.

04

What I'd do next

  • Build a labelled set of matching and non-matching name pairs across scripts and report precision and recall per script.
  • Learn the transliteration variants from data instead of relying only on ITRANS rules.
  • Benchmark candidate generation on a large record set, and index candidates by phonetic code if it does not keep up.