Spoken by Billions, Misheard by AI

A Note on the Data and Benchmarks: The AI landscape evolves rapidly. The benchmarks, vendor recommendations, and performance metrics in this white paper reflect our research and testing as of March 2026. Because ASR and LLM performance varies significantly based on audio quality, regional dialects, and specific use cases, the findings here are intended as a structural guide. They do not replace the need to evaluate these models on your own real-world audio and learners.

---

TL;DR

Key Findings

• Some of the world's most widely spoken languages are dramatically underrepresented in AI training data. The gap between where Hindi and Tamil sit versus English is not a small one - and it is the structural root cause of almost every AI problem this white paper covers.
• India's 22 scheduled languages span four distinct families - Indo-Aryan, Dravidian, Tibeto-Burman, and Austroasiatic - each with its own word structures, sound systems, and grammar patterns. Treating them all as "Indic" masks differences that matter deeply when building AI for them.
• Every language Spark supports must clear three quality hurdles before we are comfortable shipping it - and each one turned out to be harder than we expected:
  • Transcription accuracy: Indic language error rates are dramatically higher than English - and the gap is much larger than most people expect. No single provider wins across all languages; per-language routing is essential.
  • Content naturalness: Even with a perfect transcript, LLMs default to a formal, archaic register for Indic languages - grammatically correct, but lifeless. Output sounds like a government circular, not a teacher. The reasons are structural and go deeper than a simple prompt fix.
  • Instructor voice: Even genuinely colloquial output can fail if it does not sound like this specific instructor talking to these specific students.
• Choosing between global frontier models and India-first sovereign models is as much an economic decision as a quality one. The cost dynamics for Indic languages on global models are surprising - and strongly favor a hybrid architecture.
• The ecosystem is improving fast, with serious investment from government (IndiaAI Mission), academia (AI4Bharat at IIT Madras), and startups (Sarvam AI). But the structural data gap is years away from fully closing - especially for conversational, spoken-register data.

Context

Spark is an AI platform that turns recorded teaching sessions into structured courses - chapters, study notes, quiz questions - automatically. The idea is simple: an instructor records a Zoom session, uploads it, and gets a fully structured course out the other end. As my team and I started building support for Indic language instructors, we ran headfirst into a set of problems that went far deeper than we expected.

This white paper is my attempt to document them honestly - the research, the failure modes, and what we are trying to do about it as a team. It serves a dual purpose: as a contribution back to the Indian startup ecosystem, and as a foundational knowledge base that we now use internally to guide Spark’s own AI systems.

The India Paradox - and the feedback that started everything

Here is a number that was a bit shocking when I first saw it:

Hindi has roughly 350 million native speakers in India by census-based estimates, and on the order of 600 million speakers when first- and second-language users are counted together. By most counts, it is one of the top three most spoken languages on earth [1]. Tamil has somewhere between 77 and 90 million native speakers [2], spread across India, Sri Lanka, Malaysia, Singapore, and diaspora communities worldwide.

And yet, according to Common Crawl - the largest public web archive, which forms the backbone of training data for nearly every major AI model - Hindi accounts for just 0.22% of all web content. Tamil accounts for 0.049%. English, by contrast, accounts for 41.7% [3].

This is not a small gap. It is a structural chasm. And it has direct, concrete consequences for anyone trying to build AI products that serve Hindi or Tamil speakers.

I learned this the hard way.

A few weeks ago, we rolled out a first version of Hindi language support in Spark. An instructor uploaded their Hindi teaching video. Out came a beautifully structured course. Technically, it worked.

My Hindi isn’t great, but I still noticed certain abnormalities in the output.

To confirm my suspicion, we showed it to a fluent Hindi speaker.

Their feedback was immediate: "It's weird. Archaic. Like someone wrote it with a dictionary. It doesn't sound like a teacher - it sounds like a government circular."

That sent me down a research rabbit hole that took about a week to work through. This white paper is what I found.

One of my most engaged readers, Manish, recently told me: "I find the build-in-public stuff most useful - what challenge are you working on and how you are solving it." So here it is, Manish. All of it 🙂

A note on scope: this white paper covers two AI layers we are building at Spark - ASR (transcription, which converts spoken audio into text) and language models (which generate the course content as text output). Modern language models like GPT-5.4 and Gemini 3.1 Pro are multimodal and can both process and generate images, audio, and video; in Spark's pipeline, we are specifically using their text generation capabilities to produce study notes, chapter summaries, and quiz questions. TTS (voice output) is a third layer with its own set of challenges; it is outside the scope of this white paper.

---

The Language Landscape

India officially recognizes 22 scheduled languages. For product builders, the key point is that speaker scale, digital data availability, and benchmark coverage are all uneven across these 22.

That creates a practical split:

• Some high-demand languages have relatively better tooling and benchmark visibility (for example: Hindi, Bengali, Marathi, Tamil, Telugu, Kannada, Malayalam, Gujarati, Punjabi, Odia, Urdu).
• Other scheduled languages are critically important but still have thinner standardized benchmark coverage and often need heavier custom evaluation (for example: Assamese, Maithili, Santali, Kashmiri, Sindhi, Dogri, Bodo, and others).

So this white paper focuses on the first group for concrete comparisons. For the second group, we use an API-first baseline only as a starting point, then run native-speaker pilot testing on real user audio before making any production-quality claims or rollout decisions.

Concrete examples from a builder lens:

• If you launch in Hindi, you can start with stronger published transcription-accuracy benchmarks and API options, then optimize for classroom code-mixing and voice style.
• If you launch in Bodo or Dogri, the core workflow is often reversed: run your own eval set early, test with native speakers quickly, and avoid assuming benchmark parity with Hindi.

The Structural Divide: India's Four Language Families

The Indian subcontinent brings together languages from several distinct families. When building AI for these languages, it is tempting to treat them all as "Indic" - but this masks important structural differences. Each family has its own sound systems, word structures, and grammar patterns. These differences shape how hard AI is to build for each language in ways that go well beyond speaker count or web presence.

The 22 scheduled languages span four families [4]:

* Kashmiri is technically Dardic, a branch within the broader Indo-Iranian family, though commonly grouped with Indo-Aryan in practical contexts. † Sanskrit is a classical language, not a spoken native language today.

Indo-Aryan is the largest family by speaker volume, covering 15 of the 22 scheduled languages. These languages have moderately complex word structures - but significantly less so than Dravidian. A more notable challenge here is dialect compression: "Hindi" alone spans Bhojpuri, Awadhi, Braj, Haryanvi, and more - varieties that are structurally distinct from each other and from the generic standard register that AI systems default to.

Dravidian covers 4 scheduled languages with very large collective speaker bases. These languages build words by chaining suffix after suffix onto a root - a single word can carry the meaning of an entire English phrase. Tamil, in particular, has one of the sharpest formal-versus-spoken divides of any living language. These structural properties have direct consequences for how AI handles both transcription and content generation.

Tibeto-Burman covers 2 scheduled languages (Bodo and Manipuri/Meitei), representing the Northeast and Himalayan belt. These languages build words through suffix-chaining [5] and use tonal patterns to distinguish meaning, with significant internal diversity even within the family. They have the thinnest AI tooling coverage of any family in this white paper.

Austroasiatic (Munda) is represented by a single scheduled language - Santali - which belongs to a completely different family from the other three [4]. It is critically important for its speaker communities but has very thin AI coverage.

Why this white paper focuses on Indo-Aryan and Dravidian: Spark's first wave of Indic teaching content skews toward languages with the largest classroom and creator volume - which today is still mostly Indo-Aryan and Dravidian. If you are building for Bodo, Meitei, Santali, or other lower-resource languages, treat everything in this white paper as a starting point: the same structural challenges apply, often more severely, and there is no substitute for native-speaker testing on your own recordings.

---

The Three Quality Gates

Every language Spark adds must pass three quality gates before the team is comfortable shipping it.

Gate 1: Transcription quality (ASR)

Spark processes video recordings. The first thing that happens is the audio gets transcribed into text. We measure transcription accuracy using something called Word Error Rate, or WER - it counts the proportion of words that are wrong, whether misheard, skipped, or hallucinated (inserted words that were never spoken). A WER above 100% is possible when a model adds so many hallucinated words that the errors outnumber the actual words in the recording.

A WER of 5% means the AI gets 95 out of every 100 words right - excellent. A WER of 30% means roughly 1 in 3 words is wrong - which, for educational content, can be catastrophic. If the AI mishears "mitochondria" as "mitikondria" the meaning is still recoverable; if it mishears "stoichiometry" as "stoic metry" and that flows into the language model, you get course content about the wrong concept entirely.

Gate 2: Course content generation quality (language model)

Even if we get a perfect transcript, the language model can still produce text output that feels completely unnatural to a native speaker. Technically correct. But wrong in a way that is hard to describe until you see it - and then immediately obvious.

Gate 3: Does it sound like this instructor, talking to these students?

Gate 2 asks whether the output sounds natural to any fluent native speaker. Gate 3 goes further: does it sound like this specific instructor, talking to this specific audience?

You can pass Gate 2 - produce genuinely natural, colloquial Hindi - and still fail Gate 3. Here are two examples of such failures:

• A Mumbai business coach who naturally mixes 40% English into their Hindi gets output that sounds like a different, generically "casual" Hindi teacher. The AI smoothed out their personal voice.
• A Class 10 biology teacher gets content using university-level vocabulary that their students have never encountered. The AI defaulted to "educated adult" register rather than the curriculum register the students are used to.

In both cases the language passes a native speaker test. But the instructor would immediately notice it doesn't sound like them, and the students would find it slightly off.

---

Gate 1: The AI Mishears More

I defined Gate 1 above - as transcription accuracy - the first non-negotiable quality bar in Spark's pipeline.

Now let's move from definition to reality: why this gate is disproportionately hard for Indian languages, and what breaks first in real classroom audio.

The tables below compare Word Error Rate across two groups: well-resourced languages as a baseline, and all 12 Indic languages with published benchmark data.

Comparison baseline - well-resourced languages [6]

Indic languages - all 12 with published benchmark data

• ⚠️ Urdu: WER doesn't capture script complexity (right-to-left Nastaliq).
• ⚠️ Sanskrit: classical written language, not a practical spoken teaching target.

To put this in perspective:

• For English, the AI mishears about 1 in 25 words (4% WER).
• For Tamil, it mishears about 1 in 4 words (25.3% WER) - that's 6x worse.
• For Odia, closer to 1 in 3 words (35.1% WER) - that's almost 9x worse than English.

A few things to note when interpreting these tables:

• Two data sources for Indic languages: The Farmer.Chat study [7] covers Hindi, Telugu, and Odia from real noisy field recordings. The AI4Bharat Vistaar benchmark [8] covers the remaining 9 Indic languages from a standardised test set - which likely understates real-world difficulty.
• Coverage gap: India has 22 scheduled languages. The 12 above are the only ones with published standardised benchmark WER data. For the other 10 (including Assamese, Maithili, Santali, Kashmiri, and Nepali) - ASR models do exist (AI4Bharat's IndicConformer and Bhashini cover all 22 scheduled languages), but their performance has not been formally measured in a standardised benchmark. In practice, that means you cannot know their real-world accuracy until you test them yourself.
• Other Indic datasets and benchmarks are excluded from this WER table: Beyond Farmer.Chat and Vistaar, there are other Indic speech datasets and related benchmarks (Vaani, FLEURS, BhasaAnuvaad/Indic-Spontaneous-Synth, IndicSUPERB, Lahaja, Svarah, Bhashini ULCA corpora), but as of early 2026 there is no published, cross-provider WER leaderboard for Indic languages comparable to what I use here. Where they report metrics, they focus on other tasks (AST, accent robustness, keyword spotting) or English, so I exclude them from this WER table.
• Two outliers in the Indic table: Urdu's WER looks competitive, but its right-to-left Nastaliq script introduces rendering and tokenization challenges not captured by WER alone. Sanskrit's 48% reflects that it is a classical written language rarely spoken in everyday contexts - not a practical target for teaching video transcription.
• Why the first table includes multiple non-Indic languages: English alone would be too easy to dismiss ("of course AI is better at English"). Including Spanish, French, German, Japanese, and Korean makes the contrast harder to ignore.

Why the WER gap exists

The main driver is straightforward: training data imbalance.

If you look back at the WER tables, the gap between English (~4% WER) and Indic languages (16%–48% WER) is not primarily a model architecture problem. It is mostly a reflection of what these models have been trained on.

ASR systems learn from paired audio + text. For English, there are decades of large-scale transcription data: podcasts, audiobooks, call centres, meetings, lectures, and videos. Thousands of hours across a wide range of accents, microphones, and background conditions.

Hindi – the most widely spoken Indic language – has substantially less publicly available transcription data than English. Tamil, Telugu, and other Indic languages have even less. What does exist is often narrower in scope: more scripted or formal speech, cleaner audio, and more limited accent and dialect variation.

In that context, the outcome is predictable. A model trained on something like 10,000 hours of diverse English audio will outperform a model trained on a few hundred hours of relatively clean, formal Hindi audio – not because Hindi ASR is intrinsically harder, but because the training material is both smaller and less diverse.

On top of quantity, there are quality and coverage gaps:

• Labels for Indic datasets can be noisier or inconsistent.

• Indic speakers tend to mix English and local languages mid-sentence (code-switching), but most training data doesn't include enough of this.

  • For example, a Hindi teacher might say: "Toh aaj hum cover karenge photosynthesis ka process, jo aapke boards ke liye bahut hi important topic hai." - seamlessly blending Hindi and English technical terms mid-sentence.

• The writing systems themselves are trickier. India's 12 major languages use roughly 10 different scripts - because two pairs of languages share a script, while the remaining eight each have their own:

  • Hindi and Marathi: Devanagari (shared)
  • Bengali and Assamese: Bengali/Bangla script (shared, with minor differences)
  • Punjabi: Gurmukhi
  • Urdu: right-to-left Nastaliq
  • Tamil, Telugu, Kannada, Malayalam, Gujarati, and Odia: each has its own distinct script

  They are different writing systems, each with 100-400+ characters including diacritics and conjunct consonants. The ASR decoder must learn to map sounds to the correct characters in the correct script, a harder task when training data is thin.

  A compounding problem: many Indian users type in Roman script informally (typing "kal aana" rather than "कल आना"). Training data contains both native-script and romanized versions of the same words. Models exposed to this mix can produce inconsistent script output - sometimes romanized when native script is expected.

Model choice matters enormously on real-world Indic audio

These numbers represent the best available model for each language. What happens when you use a different - even popular - model on the same recordings?

The Farmer.Chat study tested 10 ASR models on the same real-world noisy Hindi and Odia recordings. The gap between the best and a commonly used default is striking:

• Hindi: Google STT achieves 16.2% WER. Whisper - the most widely used default ASR model - achieves 46.8% on the exact same recordings [7].
• Odia: Azure Speech (with speaker diarization) achieves 35.1%. Whisper on the same recordings hits 125.6% WER - more hallucinated words than real words [7].

A 125% WER means the model hallucinated more words than it actually heard - the transcription is not just inaccurate but actively fabricating content. For Spark, where course content flows directly from the transcript, this is a non-starter.

A note on why we use Whisper as the comparison baseline here: Whisper is not the strongest English ASR model available today. As of early 2026, models like NVIDIA Parakeet and Cohere Transcribe outperform it on English benchmarks in the Hugging Face Open ASR Leaderboard. We use Whisper as the comparison point specifically because it remains the most widely reached-for default when developers first add speech recognition to a product - and because the Farmer.Chat study [7] benchmarked it directly.

Lesson: for Indic languages, the default model is often the wrong model. Provider selection matters as much as language support.

The "no single winner" problem

There is no single transcription provider that wins across all Indic languages. The Farmer.Chat results already show this pattern clearly: one provider can lead in one language pair, while a different provider leads in another on the same kind of noisy, multi-speaker audio [7].

For product teams, the principle is simple:

• Per-language specialist routing beats one-size-fits-all in most production setups.
• Pan-Indic coverage leaders are useful defaults when explicit routing is not available, but "best average coverage" is still not "best for every language."

For the concrete model and API choices by language, see The Definitive 12-Language Cheat Sheet below.

The Zoom-specific challenge: who is speaking?

One more complication specific to Spark's use case: Zoom recordings are rarely monologues. A 90-minute session typically has a Q&A section with 3-5 participants, each with their own accent, dialect, and language mixing ratio.

Determining who said what - "speaker diarization" - is already a hard problem in English. In Indic languages with code-mixing, it is significantly harder. If Q&A sections are misattributed or garbled in the transcript, the course content generation can pick up student questions as if they were instructor teaching - and generate completely wrong study notes.

---

Gate 2: The AI Writes Like a Textbook

Technically correct. But wrong.

Recall the Hindi course output I mentioned earlier - the one that sounded like a government notification rather than a teacher.

The course output itself was not incorrect. It covered the right topics in the right order. The study notes had the right facts.

But it felt like reading a government notification. Every sentence was grammatically impeccable, perfectly formal and.. completely lifeless. The kind of Hindi you'd hear on Doordarshan in 1988, not the kind you'd hear a passionate teacher use in a classroom in 2026.

The technical term for what was happening is "formal register bias." But understanding why this happens - and why it is not a simple bug to fix - requires understanding where LLMs learn their language.

Why it happens: six root causes

1. Training data skew

Modern frontier models are multimodal, so they learn from more than just text. But language behavior is still shaped heavily by their text data and text-centric alignment pipelines. The more high-quality language data a model sees in a language, the better it gets. And quality matters as much as quantity - or more.

For Hindi, the text that ends up in LLM training datasets is heavily skewed toward formal sources: government documents, legal records, news articles, Wikipedia entries, textbook content, and exam preparation material. This is not an accident - these are the texts that are easiest to scrape cleanly from the web.

IndicCorp, one of the most commonly used Indic language training corpora, covers 20.9 billion tokens across 24 languages and is built almost entirely from news, Wikipedia, and OSCAR web crawls [9].

What is not in these datasets: WhatsApp conversations, YouTube comments, Instagram captions, the way people actually text each other, or the casual way teachers talk in class. This content is abundant on the internet - but it is hard to scrape cleanly, often in inconsistent scripts, and gets filtered out as "low quality noise" during data preparation.

The result: when you ask an LLM to write in Hindi, its mental template is "newspaper column meets exam preparation guide" - not "engaged teacher explaining a concept."

2. Diglossia: two languages in one name

Tamil provides the clearest illustration of a problem that exists across Indic languages to varying degrees: diglossia.

Tamil has two distinct varieties. The "high" variety (called Senthamizh or Literary Tamil) is used in formal writing, textbooks, legal documents, official speeches, and news broadcasts. The "low" variety (Spoken Tamil) is what people actually use in everyday conversation - regionally varied, heavily contracted, code-mixed, with different verb endings, different pronouns, and a completely different feel.

These are not just "formal" vs "casual" in the way English has those registers. The IruMozhi project - a Tamil NLP research initiative - explicitly documented that internet training data "heavily overrepresents Literary Tamil," while the vast majority of Tamil speakers prefer and use Colloquial Tamil in their daily lives [10]. To a native Tamil speaker, LLM output in Literary Tamil sounds like someone speaking in Shakespearean English - technically correct, but strikingly strange.

The same pattern exists in Hindi (formal Shuddh Hindi vs everyday Hinglish), Bengali, Kannada, Telugu, and Malayalam. Every Indic language has some version of this spoken-written gap, and training data disproportionately represents the written, formal variety.

3. Morphological safety

To understand this one, it helps to know two terms:

• Agglutinative languages build words by stacking distinct suffixes onto a root - each suffix carries one specific meaning, and you can take the word apart like Lego blocks. Tamil is the clearest example: the single word வருகிறேன் (varukiṟēṉ) means "I am coming" - root + tense suffix + person/number suffix, each doing a separate job.
• Fusional languages instead blend grammatical information into word endings - a single ending simultaneously encodes multiple meanings that cannot be separated. In Hindi, the word गया (gayā) means "went" - but its ending encodes past tense, masculine gender, and singular number all at once as one indivisible unit. Change one element and the whole ending shifts: गई (gaī) is past + feminine + singular. Unlike agglutinative stacking, there are no Lego blocks to pull apart [11].

Both are harder for AI than English, which expresses most of this through separate words ("I", "am", "going"). But agglutination creates a far larger vocabulary explosion - Tamil can theoretically produce thousands of surface forms from a single root [12] - which is why the problem is most acute in Dravidian languages.

To be clear, neither fusion nor agglutination is unique to Indic languages. German is fusional; Finnish and Hungarian are strongly agglutinative - Finnish alone has 15 grammatical cases all formed by stacking suffixes.

What makes Dravidian languages specifically hard for AI is not the mechanism itself, but three problems hitting simultaneously: extreme agglutination scale, near-zero training data, and severe diglossia.

German's fusion is handled well by modern AI because the training data is abundant. Finnish's agglutination is manageable because Finnish is an EU language with strong digital representation.

Tamil has all three problems at once, with no equivalent data cushion.

Informal spoken Tamil breaks and contracts these suffix chains; formal Tamil preserves them carefully. For a model trying to produce correct output, it is safer to stick to formal morphological rules. The "penalty" for being too formal is that the output sounds stiff. The penalty for attempting informal contractions and getting them wrong is that the output sounds broken. Training and human feedback in RLHF both push models toward "better too formal than wrong" [13].

4. Cultural prestige bias

In many Indian language communities, there is a long tradition of valuing "pure" or "literary" forms of the language and treating heavily code-mixed or colloquial speech as somehow less correct. Tamil has the concept of "Senthamizh" (pure Tamil). Hindi has the formal-versus-colloquial tension between Shuddh Hindi and Hinglish.

This cultural prestige shows up in RLHF annotation: human annotators tend to reward outputs that look like "proper language" and penalize heavily code-mixed or slangy outputs - especially in professional contexts. The Telegraph India described it plainly: even ChatGPT-style tools "feel clunky or overly formal in Hindi or Bengali" [14].

The model has been explicitly rewarded for producing formal language. And so it does.

5. Dialect compression (standardization bias)

"Hindi" is not one language. A teacher from rural Bihar speaks Bhojpuri-inflected Hindi. A teacher from Delhi speaks urban Hinglish. A teacher from Lucknow speaks the Awadhi-influenced Hindi of that region. When an LLM produces "Hindi," it defaults to a generic standard register (Khari Boli) that feels somewhat foreign to all of them.

The same is true for Tamil (Chennai Tamil vs Coimbatore Tamil vs Sri Lankan Tamil), Bengali (Kolkata Bengali vs East Bengali/Bangladeshi Bengali), and every other major Indic language. The language name in a prompt is a blunt instrument. Specifying the regional variety makes a meaningful difference - and in many cases, the model does respond to that specificity.

6. Code-mixing underperformance

Even when the transcript is accurate, LLMs struggle with code-mixed input and output. A 2025 benchmark called CodeMixBench found that state-of-the-art LLMs "consistently underperform" on code-mixed tasks involving Indic languages [15] - the switch between languages within a sentence trips up generation just as it trips up transcription.

7. Script fragmentation

As introduced in Gate 1, India's major languages each use a different script. This creates LLM output challenges distinct from the register and morphology problems above.

Tokenization cost varies by script: Devanagari tokenizes reasonably efficiently - roughly one syllable per one or two tokens. Tamil and Malayalam use conjunct characters (composite glyphs representing consonant clusters) that standard tokenizers often break into multiple tokens, inflating cost further. This is part of why Malayalam sits at the extreme end of the token fertility problem described in the economics section below.

Cross-script confusion is a quality failure that benchmarks rarely capture. LLMs sometimes produce Devanagari characters when writing Punjabi (Gurmukhi script) because the scripts look visually similar. When writing Assamese (Bengali script), models may produce Bengali-specific word forms rather than Assamese-specific ones - the scripts are shared but the languages are not identical.

Finally, inconsistent script choice in output: asked to write colloquial Tamil, should the model use Tamil script or Roman transliteration (Tanglish)? LLMs are inconsistent on this, and may produce a response mixing both scripts in the same paragraph - technically readable but disorienting for the reader.

How formal register bias varies by language family

The seven root causes above apply across these language families - but with different severity and character. Builders targeting languages from different families will hit different combinations of these problems:

Note: "Low" ratings for Tibeto-Burman often reflect limited research coverage rather than absence of the problem. Santali (Austroasiatic/Munda) is omitted from this table: LLM-quality research for it is too thin to characterize reliably across these dimensions. Severity ratings represent the author's synthesis across multiple sources; individual citations are provided for specific claims in the body text above.

The underlying drivers are consistent across all families - training data that skews formal, benchmarks built on written text, human feedback that rewarded "correct and polite." The severity and character of each driver varies significantly by family.

---

Gate 3: Does It Sound Like This Instructor?

Even if we solve the formal-register bias problem - even if the output is genuinely colloquial and natural-sounding - there is still a subtler question: does it sound like this instructor, talking to these students?

Instructor voice preservation

Every instructor has a personal linguistic fingerprint. A business coach from Mumbai might naturally use about 40% English words embedded in Hindi sentences, with specific phrases they return to repeatedly. A Tamil mathematics teacher from Chennai has a particular blend of spoken Tamil with English mathematical terms and specific ways of building up to an explanation.

When Spark generates course content from their recordings, does the output preserve that fingerprint? Or does it flatten everything into a generic "colloquial Hindi" or "colloquial Tamil"?

Right now, it flattens. The model has no mechanism to infer and preserve an individual instructor's code-mixing ratio, vocabulary preferences, or rhetorical style. Two instructors who teach the same topic in Hindi - one with heavy English code-mixing, one without - would get nearly identical output from the current system.

Student vocabulary calibration

The content that works for a Class 10 student learning biology is different from what works for an engineering graduate revisiting the same topic - even in the same language. A Class 10 student using NCERT textbooks has been exposed to specific vocabulary conventions that an AI generating "biology content in Hindi" would not automatically know to follow.

Indian curricula (NCERT for Class 10, for instance) use specific term conventions that differ from international textbooks. When the AI generates content in a slightly different vocabulary register, it creates a subtle but real disconnect for students who are used to their curriculum's language.

---

The Sovereign vs. Global Paradigm

As I dug deeper into the research, a clear pattern emerged across the data: the 2026 AI landscape for Indian languages is defined by a fundamental battle between Sovereign AI and Global AI. This is my synthesis of how that dynamic plays out for product builders.

Global frontier models (like GPT-5.4 and Gemini 3.1 Pro) bring massive reasoning capabilities to the table. But because they are trained primarily on Western datasets, they suffer from high "token fertility" (they break Indian words into too many pieces, driving up costs) and formal register bias.

On the other side are Sovereign models (like Sarvam-105B) built specifically for the Indian linguistic ecosystem. These models excel at "cultural groundedness" - they understand code-switching, regional idioms, and proper colloquial tone, while maintaining low token fertility through custom tokenizers.

The trade-off is that Sovereign models are not always frontier leaders on broad, global benchmarks: in public comparisons they can lag top global models on hard reasoning, coding tasks, and some multimodal capabilities. Operationally, the open ecosystem can also be less mature in places (tooling compatibility, deployment paths, and benchmark coverage), so teams often get the best production outcome from a hybrid stack - global models for heavy reasoning, Sovereign models for high-volume Indic-language generation.

---

What We're Building: Gate by Gate

None of the problems above have clean, complete solutions. The structural data gap is real and will take years to fully close. What we can do is build intelligently around current limitations - and be precise about which problem each mitigation actually addresses.

The sections below mirror the three gates. For each gate, we cover what we are doing, which specific sub-problem from that gate each approach targets, and what it still does not fix.

*For a quick per-language reference on ASR routing and LLM model selection across the top 12 Indian languages, jump straight to The Definitive 12-Language Cheat Sheet. The sections below explain the reasoning and the root-cause logic behind those recommendations.*

---

Solving for Gate 1: Transcription Accuracy

Gate 1 established that Indic language WER is 4-9x worse than English, driven by training data imbalance, multiple writing systems, code-switching complexity, and multi-speaker recording challenges specific to Zoom sessions. Here is how we address each.

1. Language detection and provider routing - the "no single winner" problem

Since no single ASR provider wins across all Indic languages, the right approach is to detect the language at ingestion and route to the best hosted API for that language. For builders looking for product-grade APIs without running their own inference stack, here is how we think about the ecosystem in 2026:

• Google Cloud STT: The overall accuracy leader for standard Hindi (16.2% WER) and Telugu (33.2% WER) [7]. Handles clean audio well; can stumble on rural dialects or heavy code-mixing.
• Azure Speech: The strongest option for multi-speaker recordings with speaker diarization, specifically outperforming others for Odia (35.1% WER vs. Google's ~70%) [7]. Does not support Punjabi STT.
• Sarvam (Saaras V3): The practical default for pan-Indic coverage. Covers all 22 scheduled languages with a hosted API and handles code-mixed speech (Hinglish, Kanglish, Tanglish) natively, avoiding the hallucinations common in Western models on low-resource Indic audio [18].
• Bhashini: India's government-built platform, offering free ASR APIs across all 22 scheduled languages using AI4Bharat's IndicConformer models under the hood [19]. The best fallback for low-resource languages like Assamese, Sindhi, or Bodo.

What about Vaani? Project Vaani (IISc / ARTPARK, backed by Google) is an open dataset and a set of open Hugging Face models, not a drop-in public API. Invaluable for teams that can self-host or fine-tune - but for direct integration, Spark prioritizes the hosted APIs above.

This ecosystem fragmentation makes automatic language identification at the ingestion stage - before transcription begins - an absolute necessity.

2. Audio preprocessing - the data quality problem

Before transcription begins, audio quality directly affects WER. Noise reduction, speaker separation, and format normalization are the first line of defense against the training data quality gap described in Gate 1. Sarvam's Saaras V3 is explicitly optimized for real-world Indian audio conditions - background noise, low-quality microphones, and telephony-grade input [20].

3. Speaker diarization for multi-speaker recordings - the Zoom Q&A misattribution problem

Gate 1 identified a failure mode specific to Spark's use case: in a 90-minute Zoom session with Q&A, student questions misattributed as instructor speech generate completely wrong study notes. Addressing this requires an explicit diarization step before the transcript flows into course generation.

Azure Speech Service's real-time diarization assigns speaker identifiers to each spoken segment [21], enabling the pipeline to separate instructor content from student questions before either reaches the LLM. One viable approach: configure the course generation pipeline to treat diarized segments differently - instructor segments generate course content; Q&A segments are preserved as context, flagged, and not used as the primary content source.

The honest caveat: speaker diarization for code-mixed Indic multi-speaker audio is an active research problem. The DISPLACE challenge [22] - the primary benchmark for multilingual speaker diarization in Indian languages, covering 158 hours across 5 Indian languages in code-mixed, multi-speaker conversational audio - confirms that identifying speaker switches in sessions where participants naturally code-mix is significantly harder than monolingual diarization. For Tamil specifically, the SiTa dataset [23] is among the first real-world conversational diarization resources for South Asian languages. Azure's diarization is a viable starting point for this problem; the downstream LLM prompt must be designed to be robust to minor misattributions, because perfect speaker separation on code-mixed Indic audio does not exist yet.

4. Script normalization - the Roman vs. native script inconsistency problem

After ASR produces a transcript, it may contain inconsistent script choices - some words in native script, others romanized (typing "kal aana" rather than "कल आना"), or both within a single sentence. A 2024 EMNLP paper [24] found that normalization routines in major ASR models including Whisper, Meta MMS, and Seamless are "fundamentally flawed when applied to Indic scripts" - artificially masking transcript errors and producing unreliable output for downstream tasks.

The recommended mitigation is to run script normalization using the Indic NLP Library [25] before the transcript feeds to the LLM. This standardizes inconsistent romanization to native script for the target language, reduces the LLM's burden of interpreting mixed-script input, and improves the consistency of course content output.

5. Code-switching configuration - the mid-sentence language switch problem

When a Hindi teacher says "aaj hum cover karenge photosynthesis ka process," most ASR APIs face a choice: treat the whole sentence as Hindi, or switch to English mid-sentence for the English words. Google STT's alternativeLanguageCodes supports multi-language detection; Sarvam handles code-mixing natively without any toggle.

In practice, turning on language switching can help with English technical terms but sometimes causes over-switching, producing a fragmented transcript. For Spark's use case, this is less critical than it sounds: the transcript feeds into an LLM that generates the final course content, and a well-crafted prompt can instruct the LLM to normalize the output into a consistent script and register regardless of transcript inconsistencies. Getting the transcript broadly accurate matters more than getting the script choice perfect at the ASR layer [26].

6. Domain vocabulary tuning - the educational term misrecognition problem

Subject-specific terms are the most likely to be misrecognized and the most damaging when wrong. A misheard chemical compound or historical figure name at the transcript stage cascades into completely wrong course content downstream. Google STT and Azure Speech both support custom phrase boosting, which reduces domain-critical errors without requiring full model fine-tuning.

7. Post-ASR correction (optional)

Running a second-pass correction model on the raw transcript before the LLM can improve accuracy. EACL 2026 work [27] shows that fine-tuned smaller models consistently outperform large frontier models for this task in Hindi, and that mid-sized general LLMs can actually degrade quality rather than improve it.

The reason to avoid this approach: it introduces a second model into the pipeline, meaning two failure modes instead of one. Unless fine-tuned specifically for your audio domain, a correction model risks smoothing over errors in ways that reduce overall accuracy.

What Gate 1 solutions do not fix

The structural WER floor is set by training data quantity - not provider selection or pipeline engineering. For low-resource languages where Bhashini and Sarvam are the best available options, WER of 25-35% is the current ceiling regardless of routing intelligence. Speaker diarization for code-mixed multi-speaker Indic audio remains an active research problem [22]; Azure's diarization is a viable starting point, not a research-grade speaker separation solution. Self-hosting ASR models or building custom Indic speech training datasets would improve results, but both represent significant infrastructure investments beyond the scope of API-first routing.

---

Solving for Gate 2: Natural Course Content

Gate 2 identified seven root causes behind formal register bias: training data skew, diglossia, morphological safety, cultural prestige bias, dialect compression, code-mixing underperformance, and script fragmentation. No single intervention covers all seven. The goal is to stack mitigations that address as many as possible, while being honest about what remains structurally hard.

1. Model selection - addressing training data skew and morphological safety (Root Causes 1 and 3)

The single most impactful decision in building for Indic languages is model choice.

Root Cause 1 - training data skew: Sovereign models like Sarvam-105B were pre-trained on data specifically curated for Indian linguistic contexts, directly reducing the formal-source bias baked into global models by their predominantly formal text corpora.

Root Cause 3 - morphological safety: Models default to formal morphological forms because informal contractions carry higher generation risk when training data for informal forms is thin. Sovereign models have been exposed to substantially more informal, spoken-register Indic text, making informal forms less penalized internally. At the prompting layer, structured prompting with negative constraints - explicitly suppressing formal register tokens - consistently produces 12-18 percentage point improvements in grammatical naturalness for morphologically complex languages [28].

Here is how we think about the model ecosystem:

• Sarvam-105B [29]: Our go-to for cultural naturalness and colloquial output - recommended for Hindi, Marathi, Tamil, Gujarati, Kannada, Odia, Punjabi, Assamese, and Bengali. As a sovereign model built specifically for Indian linguistic contexts, it handles code-switching and regional idioms without sounding like machine translation. When the primary goal is output that sounds like a real teacher talking to real students, Sarvam-105B is where we start.
• Gemini 3.1 Pro [30][31]: Our recommendation when the task demands reasoning, technical precision, or long-context understanding - specifically for Hindi (reasoning tasks), Marathi (technical and legal content), Telugu, Gujarati, Urdu, and Malayalam. Notably, Malayalam is the one language where we lead with a global model: its extreme morphological complexity means reasoning quality matters more than cultural groundedness for structured course content.
• Qwen 3.5 (235B): The open-weight leader for Bengali, Assamese, Urdu, Punjabi, and Odia. Outperforms Llama-based models on long-form generation and formal reasoning for these languages, and its open-weight nature makes it worth evaluating if cost or self-hosting matters to your team [32].

A practical two-step architecture: use Gemini 3.1 Pro or Qwen 3.5 for course structure reasoning internally in English, then use Sarvam-105B for generating the final learner-facing text in the Indic language. This separates the reasoning problem (where global models excel) from the cultural generation problem (where sovereign or highly-tuned models win) - and avoids the "reasoning tax" on high-token Indic text described in the economics section.

2. Register-explicit prompting - addressing diglossia and cultural prestige bias (Root Causes 2 and 4)

The single most accessible improvement is telling the model explicitly what register you want - and what you don't want. This pulls the output away from the formal default that diglossia and prestige bias both push toward.

For example, a prompt for Hindi generation might look like this:

"Explain this in very casual spoken Hindi, like the Dhruv Rathee channel - short sentences, conversational, some natural English words. Not like a textbook. Not very Sanskrit."

Worth noting: referencing a specific channel is a soft hint, not a hard constraint. The model will only truly reflect that creator's style if it was trained on substantial amounts of their transcripts. Descriptive language ("short sentences, conversational, some English") works more reliably than channel references alone.

Similarly, a prompt for Tamil generation might look like this:

"Explain this in spoken Chennai Tamil, friendly and informal, like talking to young professional friends. Mix in some English naturally. Avoid literary or old-fashioned Tamil."

3. Dialect and region specification - addressing dialect compression (Root Cause 5)

"Hindi" is too blunt an instruction. Explicitly naming the regional variety in the system prompt produces measurably different output. The INDIC-DIALECT benchmark [33] - covering 11 dialects across Hindi and Odia - showed that frontier models like GPT-4o and Gemini 2.5 perform poorly at dialect classification without explicit guidance, with F1 scores as low as 19.6% without fine-tuning. Specifying "Bhojpuri-influenced conversational Hindi, not standard Khari Boli" for a Bihar-based instructor produces noticeably more appropriate output than specifying only "Hindi."

This works better for languages with more dialect-specific training data. For lower-resource languages like Odia or Assamese, explicit dialect specification has diminishing returns when the model has seen almost no dialect-specific text to begin with.

4. Code-mixed model routing and prompting - addressing code-mixing underperformance (Root Cause 6)

CodeMixBench's finding [15] that frontier LLMs consistently underperform on code-mixed Indic tasks is partly a model-selection problem with a practical solution. A 2025 survey of code-switching NLP [34] found that multilingual NLU models suffer up to a 15% drop in semantic accuracy on code-mixed data. Sarvam's models are explicitly trained on code-mixed Indic text in native script, romanized, and code-mixed forms - and Sarvam-M's latest release showed an 86% improvement on romanized Indian language tasks specifically [35]. For instructors whose natural register is heavily code-mixed - a Mumbai business coach mixing 40% English into Hindi, or a Bengaluru engineer using Kanglish throughout - routing to Sarvam for the generation step produces substantially better output than routing to a global frontier model.

At the prompting level, explicitly specifying a target code-mix ratio ("Include approximately 30% English words naturally embedded in Hindi sentences, as a Hinglish speaker would naturally speak") nudges generation toward the right density.

5. Script output specification and normalization - addressing script fragmentation (Root Cause 7)

Cross-script confusion (a model producing Devanagari characters when writing Punjabi) and inconsistent script choice (mixing Tamil script with Tanglish in the same paragraph) can both be partially mitigated at the prompt level by explicitly specifying the output script: "Respond entirely in Tamil script (Unicode). Do not use Roman transliteration." For languages prone to cross-script slippage - particularly Punjabi (Gurmukhi vs. Devanagari lookalikes) and Assamese (Bengali script being replaced with Bengali word forms) - adding a negative constraint reduces slippage significantly. Structured prompting research on Tulu, a low-resource Dravidian language with similar challenges, showed that negative constraints consistently produced 12-18 percentage point improvements in grammatical accuracy and reduced vocabulary contamination from 80% to 5% [28].

For post-generation cleanup, the Indic NLP Library [25] provides script-specific normalizers that catch common mixed-script outputs before they reach the learner.

Script output specification is a prompt-level mitigation, not a model-level fix. The TransliCo research [36] demonstrated that cross-script representations in multilingual models occupy fundamentally different subspaces - fully solving this requires training-level interventions, not just prompting.

6. Few-shot style exemplars - addressing formal register bias across multiple root causes

Providing 3-10 example sentences in the exact register you want at inference time is one of the most cost-effective improvements available. A 2025 NAACL paper, PromptRefine [37], showed that the choice of which examples to include matters enormously - and crucially, that examples do not need to be in the target low-resource language itself. PromptRefine retrieves examples from related higher-resource Indic languages using cross-lingual embeddings, significantly outperforming random or naive same-language selection. For Spark, this means a Tamil generation task can benefit from well-chosen Kannada or Telugu examples if Tamil examples are scarce - reducing the cold-start problem for lower-resource Indic languages.

How do we know it is working? The quality evaluation challenge

Standard automated metrics - BLEU scores, ROUGE scores, perplexity - were calibrated on formal written text and do not capture what we care about at Spark: does this feel natural to a native speaker? The PARIKSHA study [38] - the most comprehensive evaluation of LLM judgment on Indic languages to date, with 90,000 human evaluations and 30,000 LLM-based evaluations across 10 Indic languages - found that GPT-4o and Llama-3 70B perform best as evaluators for most Indic languages, but human-LLM agreement drops specifically for Bengali and Odia. Self-bias in GPT-based evaluators is documented.

Recommended approaches for evaluation:

• Rubric-driven frontier judges: Rather than hosting custom evaluator models, we use frontier models (like GPT-5.4 or Gemini 3.1 Pro) as automated judges via API. The key is not asking a generic "is this good?" but providing a strict, multi-dimensional rubric tailored to Gates 2 and 3. The judge scores the output 1-5 on highly specific criteria: "Spoken vs Formal Register," "Code-mix naturalness," and "Vocabulary calibration."
• Human-in-the-loop (HITL) calibration: Native speaker spot-checking is not just for catching errors; it is the ground truth used to calibrate the LLM judge. If the automated judge rates a Tamil output 5/5 for naturalness, but our human instructor rates it 2/5 (because it used Literary Tamil), we use that delta to refine the judge's grading rubric. This creates a continuous feedback loop that makes the automated evaluation more accurate over time.

What Gate 2 solutions do not fix

Cultural prestige bias (Root Cause 4): Baked into RLHF annotation norms. Prompting can partially override it, but the model's reward signal continues to push toward formal output. Sovereign models trained with Indian annotators reduce this pressure but do not eliminate it entirely.

Morphological safety at depth (Root Cause 3): Fundamentally a training data problem. Structured prompting with negative constraints helps at the margins [28], but substantially solving it requires models trained on more informal, spoken-register data - which is exactly the data hardest to collect and curate.

Dialect compression for lower-resource languages (Root Cause 5): Explicit dialect prompting has limited effect when the model has seen almost no dialect-specific training text. For languages like Odia or Assamese, even precise regional specification produces minimal differentiation today.

Script fragmentation at model depth (Root Cause 7): Prompt-level and post-processing fixes handle the most common cases, but models with poor Indic script coverage will still produce cross-script errors under adversarial conditions. Training-level solutions like TransliCo [36] are required for a complete fix.

---

Solving for Gate 3: Sounding Like This Instructor

Gate 3 identified two distinct problems: instructor voice preservation (a specific instructor's code-mix ratio, vocabulary choices, and rhetorical patterns) and student vocabulary calibration (Class 10 NCERT vocabulary vs. university register). These are subtler than Gates 1 and 2, and the honest answer upfront is that complete instructor voice preservation at scale is still an open research problem.

What is well-established - and what we are building toward - is that fidelity exists on a spectrum. Even the lower levels of that spectrum produce meaningfully better output than the current default of complete voice flattening.

Level 1 - Audience context specification (lowest investment, immediate improvement)

Specifying grade level, exam board, curriculum, and subject in the system prompt directly addresses the student vocabulary calibration problem. "Generate content appropriate for Class 10 CBSE biology students, using vocabulary consistent with NCERT textbooks, avoiding university-level terminology" produces measurably better curriculum-aligned output than a generic "biology content in Hindi" instruction.

The COGENT framework [39] demonstrated that curriculum-oriented content generation - simultaneously specifying concepts, learning objectives, and readability targets - produces grade-appropriate content comparable to human references for STEM subjects. The EduAdapt benchmark [40] - 48,000 grade-labeled QA pairs across nine science subjects from Grades 1-12 - found that even large models struggle specifically with early-grade content (Grades 1-5), where defaulting to sophisticated vocabulary is the most common failure mode. That is precisely the student calibration failure described in Gate 3 above.

Level 2 - Style profiling from the instructor's own transcript (medium investment, no fine-tuning)

Rather than asking instructors to manually describe their style - an unreliable and high-friction process - style signals can be extracted directly from their transcript: English word ratio, average sentence length, vocabulary level measured against a corpus, and recurring signature phrases. These feed into a style brief in the system prompt: "This instructor uses approximately 35% English words naturally embedded in Hindi. Average sentence length is 11 words. Common signature phrases include: 'think about it this way,' 'remember this for your exam.'"

Research on style-conditioned generation via parameter-efficient fine-tuning [41] establishes that author-specific style signals - even lightweight ones - produce meaningful lexical and syntactic alignment with the target author. The documented limitation: informal conversational style is harder to capture than formal style. A 2025 study on LLM style imitation across 400+ real-world authors [42] found that while LLMs approximate style well in structured formats like news and email, they show fundamental gaps in informal, conversational registers - blogs and forums - which is exactly where a teaching transcript lives.

Level 3 - Few-shot anchoring from the instructor's own approved content (medium investment, no fine-tuning)

Providing 5-10 representative sentences from the instructor's own previously approved course output as style exemplars in the system prompt significantly outperforms description-only approaches. TinyStyler [43] demonstrated that even a lightweight 800M-parameter model, given pre-trained authorship embeddings from a small sample of author-specific text, outperforms GPT-4 on authorship style transfer tasks. For Spark's pipeline: once an instructor's first course is approved - either by the instructor directly or via native speaker review - those approved sentences become a style anchor library for all subsequent courses from the same instructor. No fine-tuning required; this is purely inference-time style conditioning, extending the cross-lingual exemplar approach of PromptRefine [37] to instructor-specific style.

Level 4 - Fine-tuning on instructor corpus (high investment, research-grade fidelity)

Parameter-efficient fine-tuning using LoRA on 1,000-50,000 tokens of instructor-specific content produces substantially better style fidelity than any prompt-based approach - and begins to capture the informal, conversational register that prompting alone cannot [41]. This is the path toward true instructor voice preservation: each instructor gets a dedicated LoRA adapter, or a slot in a multi-instructor merged model.

The constraint is data curation: fine-tuning requires enough approved, high-quality instructor output to train on, and serving complexity increases. This approach becomes practical as instructor content accumulates on the platform.

How do we know Gate 3 is working? The evaluation problem sharpens

The quality evaluation challenge from Gate 2 becomes harder at Gate 3. Automated metrics cannot measure whether output sounds like a specific person - that requires the instructor themselves, or a trained proxy who knows their style closely. There is no published benchmark for instructor voice fidelity in Indic educational contexts. The only reliable signal today is instructor feedback on generated courses - which is why early adopter relationships with real instructors testing real content are irreplaceable at this stage.

The student interaction layer makes this particularly acute. When a student asks our AI tutor a question in Hindi mid-session, the tutor generates a response in seconds - with no review loop. The voice fidelity of that response is what the student actually experiences. Getting it right requires a tighter feedback loop than anything that currently exists.

What Gate 3 solutions do not fix

At Levels 1-3, a documented limitation in LLM style imitation research [42] holds: LLMs have significant gaps in capturing nuanced, informal, conversational style from prompts alone. An instructor's personality - their sense of humor, the way they build to a reveal, their specific analogies - is not fully transferable at inference time. Level 4 closes much of this gap but does not fully close it. Gate 3 is an asymptote, not a solved problem.

Building custom Indic language training datasets and instructor-level fine-tuning would both produce better long-term results - both become more viable as the platform matures and instructor content accumulates.

---

At the Search and Retrieval Layer

Modern retrieval systems use different matching strategies - keyword-based approaches like BM25, vector search (semantic retrieval), or a combination of both (hybrid search). This section is specifically about the vector search component: a user's query gets converted into a vector, and the most relevant content is retrieved by measuring similarity in that vector space. The quality of that retrieval depends entirely on the embedding model used - and this is where standard setups quietly break down for Indic languages.

The problem with English-first embeddings

Teams building English-first RAG systems typically reach for one of a handful of common defaults: OpenAI's text-embedding-3-small or text-embedding-3-large (via API), open-source models like BGE-M3 or multilingual-E5, or Cohere Embed [44]. These models share a common characteristic: they were all optimized primarily for English and Western European languages.

For a code-mixed query like "cell membrane ka kya function hai", an English-first embedding does not capture the semantic meaning as accurately as it would for a pure English query. The retrieved chunks may be less relevant, and whatever sits on top of that retrieval will be grounded in the wrong context as a result.

The practical options

• Gemini Embedding 001: A proper API swap - no self-hosting required. Google's multilingual training covers 100+ languages and is meaningfully better than English-first models for Indic and code-mixed text [45]. For teams already on OpenAI embeddings, this is the lowest-effort upgrade path.
• Cohere Embed v4: Another API option worth evaluating, particularly if you need cross-lingual retrieval - a Hindi query retrieving Tamil documents, for example. Cohere explicitly supports eight Indic languages (Bengali, Gujarati, Hindi, Kannada, Malayalam, Marathi, Tamil, and Telugu) in a unified multilingual space.
• LaBSE (Language-agnostic BERT Sentence Embeddings): An open-source model trained on 109 languages, specifically strong on Indic and code-mixed text. It enables cross-lingual retrieval - a Tamil query can retrieve Hindi documents and vice versa. LaBSE can be self-hosted or deployed as a managed endpoint via Azure AI Foundry [46]. BGE-M3 [47] is a newer self-hosted alternative that adds hybrid retrieval (dense + sparse) to similar multilingual coverage. The IndicRAGSuite project [48] provides 26 million evaluation tuples across 19 Indian languages if you want to benchmark retrieval quality for your specific content.

The same guidance applies regardless of the embedding model you choose: the per-language variation here is low. Unlike ASR or LLM choice - where the right answer differs by language - the embedding upgrade benefits all Indic languages equally.

---

The Economics of Indic AI

Choosing the right model in 2026 is as much an economic decision as it is a technical one. The "Tokenizer Economy" has become a central focus for developers, as Western models charge significantly more for the same Indic text than they do for English.

Token Fertility

Because global frontier models were trained on Western-heavy datasets, their tokenizers are primarily English-centric. This creates a massive inefficiency called "token fertility." When global models process Dravidian languages (like Tamil or Malayalam), they often break a single word into 6 to 8.5 tokens [49]. Recent morphological tokenizers have proven that this can be brought down to under 2 tokens per word [50].

This means that a paragraph in Tamil could be 3x to 5x more expensive to generate than the exact same paragraph in English.

Sovereign models (like Sarvam-105B) solve this by using custom tokenizers optimized for Indic scripts, bringing the token fertility down to roughly ~2 tokens per word - near parity with English. For high-volume enterprise applications, this cost advantage is profound.

The "Reasoning Tax"

A new development in 2026 is the use of "thinking" or reasoning tokens in models like Gemini 3.1 Pro and Qwen 3.5. While these tokens significantly improve performance in complex logic tasks (which is exactly why we might use them at Spark for course structure reasoning), they act as a multiplier on the total token count.

This introduces a "reasoning tax" that can increase the effective cost of a model by 3x to 9x [51]. For Indic languages - where the base token count is already 3x higher on global models - adding a 3x-9x reasoning multiplier makes them entirely cost-prohibitive for standard conversational UX.

This economic reality strongly favors the two-step architecture we are exploring as a team: use the global reasoning models on the English logic layer, and use sovereign models for the high-volume Indic text generation layer.

---

The Definitive 12-Language Cheat Sheet

For builders looking for a quick reference on how to route the top 12 Indian languages, here is my 2026 summary matrix (synthesized from the research behind this white paper).

For the complete breakdown of every language (including specific ASR models, LLM nuances, caveats, and deep-dive notes), please see this document

* Vaani is open-source data/models for self-hosting and benchmarking, not a hosted commercial API.

† Azure: outperformed older Google STT across 6 of 7 Indic languages in the Vistaar benchmark (AI4Bharat, 2023) on clean audio. Has speaker diarization advantage for multi-speaker recordings. Does not support Punjabi STT.

‡ Google Chirp 3 (October 2025): Confirmed support for all 8 languages listed above. No independent Indic-language benchmark exists for Chirp 3 yet - the Vistaar data pre-dates it. Worth testing alongside Azure, particularly where diarization is not needed. Our expectation is that Chirp 3 is meaningfully better than the 2023 Google STT benchmarked in Vistaar, but this has not been independently verified.

Also worth evaluating (vendor-reported data only)

The following providers did not make it into the main routing table because their performance claims are not yet backed by independent benchmarks. We have not verified them ourselves on real classroom audio. That said, they are worth evaluating on your own recordings - especially if the main four providers fall short for a specific use case:

• Gnani AI - Focuses on telephonic audio and Kannada, with a specific optimization for Indian accents and call-center environments. Launched Vachana STT in late 2025 (trained on 1M hours under IndiaAI Mission). Claims 10-20% lower WER than leading providers on top Indic languages, but no independent benchmark confirms this. Gnani.ai
• Reverie Technologies - Focuses on code-mixed Indian language speech (Tanglish, Benglish, Punglish and similar variants) and numeric/entity recognition in BFSI contexts. Supports 11+ Indian languages with dialect-aware models. Performance data is from Reverie's own comparisons. Reverie
• Soniox - A multilingual ASR provider claiming 10.9% WER on Kannada (vs Google's 56.6% and Azure's 58.8% on real-world YouTube audio in a 2025 study) - a striking figure if it holds on classroom audio. However, this benchmark was conducted by Soniox themselves, not a neutral third party. Soniox

---

The International Picture

To understand how challenging the Indic language problem is, it helps to compare with the languages AI handles well.

To make the comparison concrete, I picked six representative languages that collectively cover Western Europe and East Asia - the two non-English tiers where AI support is strongest: Spanish, French, German, Japanese, Korean, and Chinese. I deliberately left out Dutch, Italian, Portuguese, Polish, Swedish, and other major European languages - not because they are unimportant, but because they fall in the same 4-8% WER tier as Spanish, French, and German and would not change the argument. The same applies to Arabic and Turkish, which have larger data gaps than Western European languages but are still dramatically better resourced than Indic languages.

German accounts for ~5.96% of all web content. Japanese accounts for ~5.77%. Spanish ~4.62% [3]. Each of these is 20-100x more represented than the most common Indic languages.

This translates directly to capability:

• ASR: WER for Spanish, French, German, and Japanese on real-world audio is typically 5-8%. For Indic C-tier languages, it is 18-35% under controlled conditions and much higher in real-world conditions.
• LLM output quality: A-tier languages get natural, varied output across the full spectrum - from formal to slangy, from technical to casual. They have enough training data representing every register. Indic languages default to formal register because that is almost all they have seen.
• Tokenization: A-tier European and East Asian languages are handled reasonably efficiently by modern tokenizers. Standard Indic language tokenization costs roughly 2x more tokens per unit of meaning than English - and more for languages with complex morphology and worse tokenizer support.

The practical implication for Spark: adding Spanish or French support is relatively straightforward. The ASR works well, the LLMs produce natural output, the tokenization costs are manageable. Adding Tamil or Kannada requires scaffolding at every layer of the stack - ASR routing, post-correction, model selection, register prompting, quality evaluation - and the results will still be imperfect.

A word on what I have consciously left out: African and other low-resource languages

The Indic language problem is real. But it is worth noting that it sits in the middle of a much larger global spectrum.

Many African languages face a data representation crisis that makes even the hardest Indic languages look relatively well-resourced. Languages like Yoruba, Zulu, and Amharic have less than 0.01% web content presence. Without fine-tuning, Whisper produces 50-100%+ WER for many of them. With fine-tuning on limited datasets, a fine-tuned Whisper large gets Yoruba down to ~25% WER on benchmarks - but 62% on real-world audio, a gap even larger than what I see for Indic languages in the data [52]. There is active research (Meta's MMS model, the AfriSpeech dataset, ACL AfricaNLP workshops), but the ecosystem is significantly earlier stage.

We are not building for African languages right now at Spark. But the team and I are aware that the challenge I am documenting for Indic languages is not the hardest version of this problem - just the version most relevant to Spark's current users.

Brief note on Urdu: one of India's 22 scheduled languages, Urdu uses right-to-left Nastaliq script, which introduces a completely different class of technical challenges at the rendering and tokenization layer beyond everything discussed here. It is on the team's radar but a separate problem.

---

Where This Is All Heading

The challenges above are real. But the ecosystem is improving - and faster than it has at any point in the past.

IndiaAI Mission is a government-backed initiative explicitly designed to build sovereign AI infrastructure in India. Sarvam's 105B and 30B models were trained under this mission, with compute support from Yotta and Nvidia [53]. The explicit goal is that India's AI capabilities should not be entirely dependent on foreign closed-source models. That is a meaningful shift.

AI4Bharat at IIT Madras has been building open-source ASR, NLP, LLM, and translation models for all 22 scheduled Indian languages for several years [54]. Their Vistaar benchmark suite, IndicWhisper ASR models, and IndicTrans translation models are foundational pieces of the ecosystem.

Bhashini, India's government-built translation and speech platform, provides free APIs for ASR, TTS, and translation across all 22 scheduled languages - including Conformer-based ASR for the truly low-resource ones like Sindhi, Dogri, Santali, and Bodo [19].

The data gap that drives most of these problems is structural - it will not close in a year. But in 2-3 years, I expect B-tier and C-tier Indic languages to have significantly better ASR and LLM support than they do today. The formal-bias problem will persist longer, because it requires not just more data but specifically conversational, spoken-register data that is harder to collect and curate.

Our architecture is built with this trajectory in mind: swappable ASR and LLM layers, not hard dependencies on specific providers. As better models arrive, the architecture is designed to take advantage of them.

---

Where We Are

Spark's Indic language support is at proof-of-concept stage. We started with Hindi - built an early POC, showed it to instructors, and watched carefully where it broke. That feedback loop is what drove the research behind this white paper. The problems we found were not quirks. They were structural, and they apply to every Indic language we want to support.

The near-term goal covers the 12 languages in the cheat sheet above. The long-term goal is all 22 scheduled languages of India.

The gate-by-gate solutions section is our roadmap - ASR routing, register-explicit prompting, model selection, speaker diarization, script normalization, per-language dialect specification, and the Gate 3 instructor voice spectrum. The research behind each of these is solid. We are publishing it openly because other builders in this space should not have to rediscover it from scratch.

The architecture is built with the ecosystem's trajectory in mind: swappable ASR and LLM layers, not hard dependencies on any single provider. As better models arrive, the architecture is designed to take advantage of them.

---

If you are building AI products for Indian language users - the research above is yours to use. The citations are all linked. Share what you learn. The ecosystem gets better faster when we build it together.

---

Citations

[1] Hindi: speakers and status (Wikipedia; census- and survey-based estimates) - https://en.wikipedia.org/wiki/Hindi

[2] Tamil language: speakers and distribution (Wikipedia) - https://en.wikipedia.org/wiki/Tamil_language

[3] Common Crawl language distribution statistics (March 2026) - https://commoncrawl.github.io/cc-crawl-statistics/plots/languages.html

[4] Languages of India - Wikipedia (language family distribution and speaker shares) - https://en.wikipedia.org/wiki/Languages_of_India

[5] Beyond Multilinguality: Typological Limitations in Multilingual Models for Meitei Language (ACL SIGTYP 2026) - https://aclanthology.org/2026.sigtyp-main.5/

[6] AssemblyAI ASR benchmarks - https://www.assemblyai.com/docs/benchmarks

[7] Benchmarking Automatic Speech Recognition for Indian Languages in Agricultural Contexts (Farmer.Chat) - https://arxiv.org/html/2602.03868v1

[8] AI4Bharat Vistaar Benchmark (Tamil 25.3%, Bengali 20.1%, Kannada 18.3%, Malayalam 32.3% WER) - https://github.com/AI4Bharat/vistaar

[9] Towards Leaving No Indic Language Behind: IndicCorp monolingual corpora (AI4Bharat, arXiv:2212.05409) - https://arxiv.org/abs/2212.05409

[10] IruMozhi project / diglossia in Tamil NLP (NAACL Findings 2024) - https://aclanthology.org/2024.findings-naacl.195.pdf

[11] Improving Bengali and Hindi Large Language Models (LREC 2024) - https://aclanthology.org/2024.lrec-main.764

[12] Morphological Inflection in the Low-Resource Setting (SIGMORPHON 2023) - https://aclanthology.org/2023.sigmorphon-1.3.pdf

[13] Building an LLM from Scratch for Indic Languages - https://dev.to/daud_ibrahim_9887/building-an-llm-from-scratch-for-indic-languages-what-no-one-tells-you-about-the-hard-parts-1e85

[14] When AI is Anglophone - Telegraph India - https://www.telegraphindia.com/opinion/when-ai-is-anglophone-can-chatgpt-generate-arguments-in-hindi-or-bengali-with-the-same-clarity-prnt/cid/2109430

[15] CodeMixBench: Evaluating Code-Mixing Capabilities of LLMs - https://arxiv.org/pdf/2507.18791

[16] Manipuri Language Variation - Central Institute of Indian Languages (CIIL) - http://lisindia.ciil.org/Mani/Mani_vari.html

[17] Mizo grammar - Wikipedia (agglutinative morphology in Mizo) - https://en.wikipedia.org/wiki/Mizo_grammar

[18] Saaras V3 beats Gemini and GPT-4o on Indian speech benchmarks - https://www.business-standard.com/technology/tech-news/saaras-v3-beats-gemini-gpt-4o-on-indian-speech-benchmarks-says-sarvam-ai-126021200384_1.html

[19] Bhashini - India's government translation and speech platform - https://dibd-bhashini.gitbook.io/bhashini-apis/available-models-for-usage

[20] Sarvam Saaras V3 blog - https://www.sarvam.ai/blogs/asr

[21] Azure Speech Service - Real-time Diarization (Microsoft Learn) - https://learn.microsoft.com/en-us/azure/ai-services/speech-service/get-started-stt-diarization

[22] The Second DISPLACE Challenge: DIarization of SPeaker and LAnguage in Conversational Environments - https://arxiv.org/html/2406.09494v1

[23] SiTa: Sinhala and Tamil Speaker Diarization Dataset in the Wild (ACL CHIPSAL 2025) - https://aclanthology.org/2025.chipsal-1.8/

[24] What is lost in Normalization? Exploring Pitfalls in Multilingual ASR Model Evaluations (EMNLP 2024) - https://aclanthology.org/2024.emnlp-main.607

[25] Indic NLP Library - Script Normalization Utilities - https://indic-nlp-library.readthedocs.io/en/latest/indicnlp.normalize.html

[26] Script normalisation for code-mixed ASR (ISCA Interspeech 2023) - https://www.isca-archive.org/interspeech_2023/verma23_interspeech.pdf

[27] Post-ASR Correction in Hindi (EACL 2026) - https://aclanthology.org/2026.eacl-short.45/

[28] Making Large Language Models Speak Tulu: Structured Prompting for an Extremely Low-Resource Language (ACL LoResLM 2026) - https://aclanthology.org/2026.loreslm-1.5/

[29] Sarvam-105B model overview and Indian language benchmarks (Sarvam API docs) - https://docs.sarvam.ai/api-reference-docs/getting-started/models/sarvam-105b

[30] Google Gemini API - Models documentation - https://ai.google.dev/gemini-api/docs/models

[31] The Broken Token: Tokenization for Malayalam Language Models (2026) - https://thottingal.in/blog/2026/02/27/malayalam-tokenizer-llm/

[32] Ultimate Guide - Best Open Source LLM for Bengali in 2026 - SiliconFlow - https://www.siliconflow.com/articles/en/best-open-source-llm-for-bengali

[33] INDIC DIALECT: A Multi Task Benchmark to Evaluate and Translate in Indian Language Dialects - https://arxiv.org/abs/2601.10388

[34] Beyond Monolingual Assumptions: A Survey of Code-Switched NLP in the Era of Large Language Models (2025) - https://arxiv.org/html/2510.07037v3

[35] Sarvam-M: Open Source Hybrid Indic LLM (Sarvam AI, 2025) - https://www.sarvam.ai/blogs/sarvam-m

[36] TransliCo: A Contrastive Learning Framework to Address the Script Barrier in Multilingual Pretrained Language Models (ACL 2024) - https://aclanthology.org/2024.acl-long.136

[37] PromptRefine: Few-Shot Performance on Low-Resource Indic Languages (NAACL 2025) - https://aclanthology.org/2025.naacl-long.17/

[38] PARIKSHA: A Large-Scale Investigation of Human-LLM Evaluator Agreement on Multilingual and Multi-Cultural Data (EMNLP 2024) - https://aclanthology.org/2024.emnlp-main.451/

[39] COGENT: A Curriculum-oriented Framework for Generating Grade-appropriate Educational Content (BEA 2025) - https://aclanthology.org/2025.bea-1.10/

[40] EduAdapt: A Question Answer Benchmark Dataset for Evaluating Grade-Level Adaptability in LLMs (EMNLP 2025) - https://aclanthology.org/2025.emnlp-main.1736/

[41] Customizing Large Language Model Generation Style using Parameter-Efficient Finetuning (2024) - https://arxiv.org/abs/2409.04574

[42] Catch Me If You Can? Not Yet: LLMs Still Struggle to Imitate the Implicit Writing Styles of Everyday Authors (2025) - https://arxiv.org/abs/2509.14543

[43] TinyStyler: Efficient Few-Shot Text Style Transfer with Authorship Embeddings (2024) - https://arxiv.org/abs/2406.15586

[44] Best Embedding Models 2025-2026: What Changed - https://deploybase.ai/articles/best-embedding-models-2025-2026-what-changed

[45] Gemini Embedding 001 - Google AI for Developers - https://ai.google.dev/gemini-api/docs/models/gemini-embedding-001

[46] LaBSE managed endpoint - Azure AI Foundry Models - https://ai.azure.com/catalog/models/setu4993-labse

[47] BAAI/bge-m3 multilingual embedding model - Hugging Face - https://huggingface.co/BAAI/bge-m3

[48] IndicRAG: Breaking Language Barriers in Document QA - https://sanjaysakhinala.pages.dev/blog/multilingual-rag-systems

[49] Understanding SUTRA's Multilingual Tokenizer (Two.ai, 2024) - https://www.two.ai/blog/understanding-sutra-s-multilingual-tokenizer

[50] Tokenization efficiency for Indic languages - https://arxiv.org/pdf/2603.05883

[51] LLM API Pricing in 2026: The Complete Cost Comparison (AI Magicx) - https://www.aimagicx.com/blog/llm-api-pricing-comparison-2026

[52] Full Fine-Tuning vs. Parameter-Efficient Adaptation for Low-Resource African ASR (ACL AfricaNLP 2026) - https://aclanthology.org/2026.africanlp-main.19/

[53] Sarvam releases 30B and 105B LLMs under Apache 2.0 (IndiaAI Mission) - https://www.opensourceforu.com/2026/03/sarvam-releases-30b-and-105b-llms-under-apache-2-0/

[54] AI4Bharat - IIT Madras initiative for Indian language AI - https://ai4bharat.iitm.ac.in

[55] Few-Shot Controllable Style Transfer for Low-Resource Languages (Google Research / ACL) - https://arxiv.org/abs/2110.07385

[56] Sarvam-105B model card - https://huggingface.co/sarvamai/sarvam-105b

[57] Sarvam API pricing - https://www.sarvam.ai/api-pricing

[58] Comparative ASR study on Dravidian languages (Feb 2025, ASMP Journal) - https://asmp-eurasipjournals.springeropen.com/articles/10.1186/s13636-025-00395-5

[59] Breaking language barriers 2.0 - Hindi ASR (Collabora) - https://www.collabora.com/news-and-blog/news-and-events/breaking-language-barriers-20-moving-closer-production-ready-hindi-asr.html

[60] Global AI models struggles with Indian languages and dialects: Report - Business Standard - https://www.business-standard.com/technology/tech-news/global-ai-models-struggles-with-indian-languages-and-dialects-report-126021600237_1.html

[61] Best Kannada ASR Tools for Indian Languages in 2026 - Gnani AI - https://gnani.ai/resources/blogs/best-kannada-asr-tools-for-indian-languages-in-2026

[62] Deepgram vs Reverie: Comparison of Multilingual Accuracy in 2026 - Reverieinc - https://reverieinc.com/blog/deepgram-vs-reverie-speech-to-text-accuracy/

[63] MILU: A Multi-task Indic Language Understanding Benchmark (2025) - https://research.ibm.com/publications/milu-a-multi-task-indic-language-understanding-benchmark