Retrieval across 16 Indian languages, and the receipts to check it

India publishes an enormous amount of public information, and it does not publish it in one language. A single government notice can appear in Hindi, Tamil, Bengali, Urdu and a dozen more. If you want to find the one right passage for a question, and the question and the answer are in different languages, ordinary search struggles. That is the problem we went after.
Today we are releasing embed-gov-indic, a small open adapter for cross-lingual retrieval over Indian government press-release text. It is public on Hugging Face, the weights are Apache-2.0, and the model is yours to pull and try.
huggingface.co/quanfire-ai/embed-gov-indic
What it is
embed-gov-indic is a LoRA adapter over a frozen intfloat/multilingual-e5-small. It adds 589,824 parameters, which on disk is 2.4 MB. It produces 384-dimensional normalized vectors, and it covers 16 Indian languages: English, Hindi, Tamil, Telugu, Kannada, Malayalam, Urdu, Punjabi, Bengali, Odia, Marathi, Assamese, Gujarati, Khasi, Manipuri and Nepali.
The point of shipping something this small is that it is honest and portable. It is not a giant black box you have to take on faith. It is a tiny, inspectable delta on a well-known open base, and you can pull it and try it on your own text.
The numbers
Against the untrained base model, on held-out press releases:
| Metric | Base e5-small | embed-gov-indic | Change |
|---|---|---|---|
| Recall@1 | 0.1836 | 0.2349 | +27.9% |
| Recall@5 | 0.516 | 0.636 | +23% |
| Recall@10 | 0.649 | 0.744 | +15% |
| MRR | 0.336 | 0.408 | +21% |
The Recall@1 gain is statistically significant: the 95% confidence intervals do not overlap (base [0.165, 0.204], adapter [0.214, 0.257]). Per language, the jumps are largest where they matter for cross-lingual search, for example Hindi 0.324 to 0.405, Urdu 0.206 to 0.313, and English 0.167 to 0.297.
We will be the first to put the numbers in context. The absolute Recall@1 is modest, because retrieving the single correct passage out of roughly 1,800 candidates across 16 languages is genuinely hard. The honest way to read this is that the right passage lands in the top 10 about 74% of the time, and that a 2.4 MB adapter moved it there with no change to the base model. Quality here is a dial you turn with clean data and a little training, not a mystery.
Where the data came from, and why that matters
The adapter is trained on Press Information Bureau (pib.gov.in) press releases, joined across their sibling-language versions to mine cross-lingual pairs. PIB material is public and permits reproduction with source acknowledgement, with no non-commercial and no share-alike restriction. So we attribute it plainly:
Source: Press Information Bureau (pib.gov.in), Government of India.
Clean, documented provenance is not a footnote for us, it is the product. It is why we can show our work instead of asking you to trust us, and it is why these weights are safe to build on.
Check our work
Do not take our word for any of this, and you do not have to. The model card lays out the full benchmark, the per-language table, the confidence intervals, and the scope in one place. The base model is open (multilingual-e5-small, MIT), so what we added is a tiny, inspectable 2.4 MB adapter and not a black box: pull it and run it on your own text to judge it directly. The provenance is publicly checkable too, because PIB is a public source with a public reproduction policy and we attribute it, so anyone can confirm the source is exactly what we say it is. Our training framework is open source at github.com/quanfire-ai/quanfire-multilingual-embedding (Apache-2.0).
What it is for, and what it is not
We are precise about scope. embed-gov-indic is built and validated for retrieval over Indian government press releases. It is not validated for other domains such as legal, finance, news, conversational or product text, and the three lowest-resource languages here (Khasi, Nepali, Manipuri) have thin evaluation sets, so treat those numbers as indicative. Saying this plainly is the whole idea. A model that tells you where it works is worth more than one that claims to work everywhere.
Why we build in the open
We keep putting clean, verifiable models out in the open, and the pattern is deliberate. We think the team you trust with your documents should be a team that ships its own domain models, documents their provenance, and hands you the receipts. That discipline is what we bring to our products too.
Want that same provenance-first, verify-it-yourself discipline applied to your own documents? The same team builds DocPro. Try it on your contracts and filings.