Seven languages broke my RAG

For the last few months, alongside the European work, I have been building Pravachak: a multi-tenant AI co-teacher for Indian private schools. Students ask questions in their own language, teachers get 5E lesson plans and quizzes, admins get governance over all of it. Seven Indic languages plus English at launch.

I went in thinking I had multilingual RAG solved. My European stack serves Italian, English and German daily. It does not.

Where it broke

Lexical retrieval collapses. My hybrid retriever leans on BM25 alongside vector search, and BM25 assumes tokenisation that means something. Hindi and Telugu are agglutinative enough that naive whitespace tokenisation shreds the signal, and Devanagari and Telugu script share no surface forms at all with a Latin-script query about the same concept. A student typing romanised Hinglish - "photosynthesis kaise hota hai" - matches nothing in either index.

The corpus and the question are in different languages. NCERT source material is largely English. The student asks in Kannada. Classic cross-lingual retrieval, and the embedding model's alignment quality between English and each Indic language varies enormously. It is decent for Hindi, notably worse for the lower-resource languages in the set, and my evaluation harness had been averaging that variance into a single number that told me nothing.

Code-switching is the normal case, not the edge case. Real Indian classroom language mixes English technical terms into an Indic sentence, in either script. Any pipeline branch that starts with "detect the language" is already wrong, because the answer is "two of them, mid-sentence."

Answer language is a product decision, not a passthrough. Answering entirely in Kannada is wrong when the exam will use the English term. Students need the English keyword preserved alongside the local-language explanation. That is a prompt and evaluation requirement, not something the model does by default.

What actually fixed it

• Index the source in English, retrieve cross-lingually, answer in the student's language. Fighting to translate the whole corpus into seven languages was worse on every axis: cost, drift, and the maintenance burden when NCERT updates a chapter.
• Query-side expansion instead of corpus-side translation. Expand the incoming question into English plus a transliterated form, then run both through the hybrid retriever. Cheap, and it fixed romanised input almost completely.
• Per-language evaluation sets, never an average. Eight separate scoreboards. The averaged number had been hiding that one language was materially worse than the rest.
• Transliteration as a first-class step, not a preprocessing afterthought. Roman to native script and back, both directions, on the query path.
• Explicit terminology policy in the prompt. Keep the English technical term, explain around it in the local language.

The governance half

The other thing this project forced me to internalise: India's DPDP regime is on a real clock. The Board can inquire and levy penalties from 13 November 2026, the consent manager framework goes operational the same day, and full data-fiduciary compliance lands by 13 May 2027. Penalties run to ₹250 crore per violation.

Since the data subjects here are largely minors, consent, deletion and export were not features to add later. They shipped in the first build: consent records per student, an immutable audit log per admin action, and an export-and-delete job that actually runs.

That part felt familiar. Same instinct as GDPR work in Europe, different statute. The lesson generalises: if you are building for a regulated user base, the governance layer is cheaper to build first than to retrofit, in every jurisdiction I have worked in.