This is Part 2 of our GeoIndia series, which follows Part 1’s introduction of GeoIndia, the Seq2Seq model that converts messy Indian addresses into precise map locations. In this post, we go one level deeper: what we learned from running GeoIndia in the wild, and how that pushed us to rebuild the system around a fundamentally different idea.
"Near the temple, behind Golu Mishra's house"
That's not a joke. That's a real Indian address.
So is this one: "Floor 10, Tower E, Gate Number 3, Helios Business Park, Chandana, Outer Ring Road." And this: "Pnt colony, near SBI Bank, beside Mansa devi mandir, raipur rd, raebareli raipur, Uttar Pradesh."
Three addresses. Three completely different ways of describing a location. None of them have street numbers. None of them have postal codes you can trust. All of them are perfectly clear to a human living in that neighbourhood, and completely baffling to a computer.
This is the everyday reality of geocoding in India. In Tier-2 and Tier-3 cities especially, addresses lean on landmarks, personal references, and local knowledge rather than standardised formats. The cost of getting them wrong adds up. India loses an estimated $10–14 billion every year to address-related delivery inefficiencies, roughly 0.5% of GDP.
When you're running last-mile delivery at scale, getting addresses right isn't a nice-to-have. It's the entire game.
Why this is uniquely an Indian problem
Most geocoding systems in the world were built for clean Western-style addresses: a number, a street, a city, a postcode. India doesn't play by those rules. And the messiness comes in two distinct flavours, both of which break naive models.
Variant 1: Same place, completely different words. Imagine a single locality where one resident describes their home as "Shri Bhagvati Amma Temple, near Orchid Interio, in the lane opposite the Wells Fargo office," while their neighbour writes "Relish Cafe, in front of Oracle Prestige Velocity, near Byasnavi Vrindavan Phase 1." Both addresses sit within walking distance of each other. There's almost no lexical overlap between them. A model that only reads words will treat them as completely unrelated places.
Variant 2: Different places, suspiciously similar words. Now picture two addresses, both mentioning "SBI Bank" and "Raipur," in the state of Uttar Pradesh. They sound nearly identical. They're actually in different towns, dozens of kilometres apart. A model leaning on textual similarity will confidently place them at the same point, and be wrong both times.
This is the "needle in a haystack, but the haystack is also made of needles" problem. Words alone can't tell you which Raipur, which temple, which SBI Bank.
The first chapter: GeoIndia, and what it taught us
About a year ago, we shipped GeoIndia, our first serious attempt at this problem. It framed address resolution as a structured generation task: take raw text, predict a sequence of hierarchical H3 cells (a geospatial indexing system that breaks the world into nested hexagonal grids), and out comes a location.
It worked. GeoIndia beat the Google Maps Geocoding API on Indian addresses across all the states we tested, and it's been running on Meesho ever since. The Seq2Seq approach, with state-specific fine-tuning, gave us a system that could handle informal address structures far better than any off-the-shelf option.
But living with a model in production teaches you things benchmarks don't. We watched GeoIndia stumble in a very specific way: it was reading addresses, but it wasn't understanding geography.
When two addresses shared misleading lexical similarity (the two Raipurs problem), GeoIndia would confidently collapse them into the same location. When two addresses described the same place using totally different phrasing (the temple-and-cafe problem), it would treat them as unrelated. The model was working off surface text alone. It had no sense of which places were actually near which other places in the real world.
We needed the model to stop reading addresses like a stranger and start reading them like a local.
[You can access the research paper on GeoIndia V1 here]
The insight: our field executives already solve this every day
Here's the thing we kept coming back to. The hardest version of this problem (disambiguating two "Raipurs," knowing which temple, recognizing that "Relish Cafe" and "Shri Bhagvati Amma Temple" describe the same neighbourhood) is already solved every single day by our field executives.
Field executives (FEs) are the people who deliver packages. They have practical, lived knowledge of localities. They know that this Raipur is the one in Raebareli, not the one near Lucknow, because they've delivered there before. They can resolve vague or inconsistent addresses based on past experience and neighbourhood layout. It's expertise built one doorstep at a time.
And here's the part that unlocked everything: that expertise is sitting in our logs.
Two years of FE delivery traces is, in effect, two years of geographic intuition. If FE Ramesh scanned a package at Address A and then scanned another package at Address B fifteen minutes later, those two addresses are physically near each other. We didn't need to teach the model geography from scratch. We needed to teach it from the people who already knew.
That insight became GeoIndia V2.
Teaching the model to think like a local
The core idea in V2 is straightforward to describe even if the implementation is involved: give the model two ways of looking at every address, and let them talk to each other.
Build a giant map of "who's next to whom". Using two years of FE delivery scan logs, we constructed a massive graph. Each address is a node. Whenever an FE delivered to two addresses consecutively (within a fifteen-minute window), we drew a 1-hop edge between them. If there was exactly one delivery between them, we drew a 2-hop edge. Do this across millions of deliveries and you end up with a fine-grained web of which addresses are actually near which others, grounded in real-world delivery sequences rather than guesswork.
Give the model two brains. The first is a language brain: a pretrained transformer language model (PTLM) trained from scratch on 67 million Indian addresses, which reads address text and extracts token-level meaning. The second is a geography brain: a Graphormer that reads the delivery graph and learns the spatial topology, which addresses connect to which, how dense the local neighbourhood is, and what the structural patterns look like.
Make the two brains talk. This is the heart of V2. We built a fusion mechanism called Key Modulated Cross-Attention (KMCA). In plain terms: the geography brain takes what it knows about an address's spatial context and whispers it to the language brain, modulating which words and phrases in the address actually matter for placing the location. The two perspectives don't sit side by side. They combine.
The fused representation then passes through a decoder that generates a hierarchical H3 cell sequence: a precise location, one nested hexagon at a time.
Putting it to the test
We evaluated V2 against three baselines (the Google Maps Geocoding API, our own GeoIndia V1, and G2PTL, a graph-based geocoding architecture from related work) across three structurally and linguistically diverse Indian states: Uttar Pradesh, Haryana, and Karnataka.
The headline metric is Accuracy within 1km, how often the predicted location lands within 1km of the true delivery point.
The other metrics tell the same story. Mean distance error in Uttar Pradesh dropped from 6.71km to 1.98km. The 99th-percentile distance error, the long tail where things go really wrong, fell from 44.69km to 23.55km.
We also dug into where the gains came from. A few findings worth highlighting:
The KMCA fusion was doing real work. We tested several alternative fusion strategies: simple concatenation, mean pooling, gated fusion with sigmoid, gated fusion with ReLU. KMCA outperformed all of them. Letting the geography brain modulate which tokens the language brain pays attention to is meaningfully better than just mixing the two representations.
Neighbourhood size has a sweet spot. We varied the size of the subgraph the model looks at, from 2 addresses to 10. Performance peaked at 6 nodes. Smaller graphs didn't give the model enough context; larger ones introduced noise from less relevant connections.
Weak supervision matters. We pre-train on a Weakly Supervised Dataset of noisy address-GPS pairs from historical delivery logs before fine-tuning on a smaller High-Confidence Dataset. Without the noisy pre-training stage, accuracy drops significantly across every model we tested. Diverse, messy data builds stronger initial representations than clean data alone.
When we visualised the learned address embeddings using t-SNE across seven districts in Haryana, the picture was striking. G2PTL and GeoIndia V1 produced significant overlap between district clusters; the model wasn't really separating them. GeoIndia V2 produced distinct, compact clusters per district. The model had internalised geography, not just words.
The deployment problem nobody warns you about
There's a wrinkle in all of this. At training time, we have rich delivery sequences and can build real subgraphs around every address. At inference time, a fresh address comes in by itself, with no delivery history attached. How do you give it geographic context when there is none?
The naïve fallback is what prior work like G2PTL did: replicate the same address across six isolated nodes connected only to themselves (a "self-loop" graph). It preserves architectural compatibility, but it throws away the model's structural inductive bias. And our experiments confirmed it: using self-loops at inference dropped Acc@1km from 89.62% to 85.30% in Haryana, and from 86.34% to 81.40% in UP. Meaningful gains, gone.
Our solution: construct the inference-time graph dynamically using approximate nearest neighbour (ANN) search. When a new address arrives, we use the V2 encoder to embed it, then retrieve its top-5 nearest neighbours from a pre-indexed address database. We connect each node to its most similar neighbour as a 1-hop edge, and add transitive 2-hop edges where the structure suggests them. No self-loops; we want the model to lean on real relational structure, not identity shortcuts.
This gives us, at inference, an approximation of the kind of delivery graph the model trained on. The architecture stays compatible. The performance stays high. Median inference latency lands at around 495ms, fast enough for production.
GeoIndia V2 is now deployed on Meesho's platform, handling real customer addresses every day.
What this unlocks
The way we think about V2 isn't just "a better geocoder." It's a way of fusing two very different kinds of knowledge (what an address says and where it sits in the real world) into a single representation that's stronger than either on its own.
That has implications beyond geocoding itself. The same architecture extends naturally to other geospatial problems we care about: high-precision address matching (is this the same place as that one?), address quality assessment (is this address even resolvable?), and address enrichment (filling in missing context). Each of these benefits from the same insight: that geographic structure, learned from real delivery patterns, carries information that pure text never can.
It also points to a broader pattern in how we approach modelling at Meesho: the most valuable signal often isn't in the data you collected for the task. It's in the operational data sitting in your logs, generated as a side effect of doing business. Two years of FE scan logs weren't created to train geocoders. They turned out to be the best teachers we had.
Closing thought
In a country where addresses are stories, built from temples, tea stalls, and the houses of neighbours everyone seems to know, we needed a model that could listen the way a local listens. GeoIndia V2 isn't there yet. No system is. But it's a meaningful step closer, and it's already changing what gets delivered, to whom, and where.
The next chapter of this work is already in motion. More on that soon.
The full paper is available here.
About the Authors
GeoIndia V2 was built by Arpit Tiwari, Bhavuk Singhal, Anshu Aditya, Shubham Jain, Debashis Mukherjee, and Debdoot Mukherjee. The full technical paper was published at CIKM '25 in Seoul.
