"We don’t have enough Tamil training data, so let’s generate some with a large model." It sounds reasonable. For Indian-language workloads it is often a quiet way to make your model worse without realising it. Here is when synthetic data pays off in the Indic context, when it actively damages quality, and how to build a pipeline that gets the benefits without the damage.
The translation-artefact trap
Much of the "Tamil" or "Hindi" text generated by English-dominant models is structurally English translated into the target language: English word order, English idioms, English politeness register. Train on enough of it and your model produces fluent-looking output that native speakers find awkward. Synthetic-augmented models can score higher on automated metrics while scoring lower in human review, because the metrics reward surface overlap rather than naturalness.
Tells to look for when reviewing generated text:
- Subject–verb–object order in languages that normally put the verb last.
- Literal translations of English idioms that no native speaker would use.
- Formal, textbook vocabulary where people would naturally use everyday or borrowed English words.
- The wrong honorific or register for the relationship in the conversation.
Where synthetic data helps
- Schema-bound generation. Filling slots in fixed templates (addresses, dates, names, transaction descriptions). Low semantic risk, high coverage gain.
- Negative examples. Generating adversarial or out-of-scope queries. Translation artefacts matter less when the target behaviour is "decline gracefully".
- Code-mixed augmentation. Synthesising Hindi–English code-switching within constrained patterns. Real users mix; datasets rarely capture it. Careful synthesis helps.
- Long-tail intents. When you have 50 real examples of a rare intent and need 500, careful synthesis from those seeds multiplies coverage without flooding the model with bias.
Where synthetic data hurts
- Replacing missing fluent text in low-resource languages. Use real corpora instead, such as AI4Bharat's Sangraha and the resources published through Bhashini.
- Cultural references, idioms and contextual reasoning. Models produce plausible-but-wrong cultural details: festivals in the wrong season, dishes from the wrong region, forms of address nobody uses.
- Evaluation sets. Synthetic evaluation data contaminates against synthetic training data. Your numbers go up; reality does not.
Source order that works
- Real native text from your domain and your users.
- Human-augmented data: paraphrases and variations written by native speakers.
- Constrained synthetic data for slots, templates and adversarial examples.
- Free-form synthetic text.
The further down the list, the smaller the share of your dataset it should be. Our working rule is to keep synthetic text under 15% of any Indic training set, and at zero in evaluation sets.
Indic-specific generators are better
Models built or tuned for Indian languages, such as Sarvam's, Krutrim and AI4Bharat-tuned models, tend to produce more idiomatic synthetic text than English-dominant models. Test a few candidates on a small batch and have native speakers rate the output before you choose. That step costs little compared with retraining on a bad dataset.
Human-in-the-loop is the bridge
Generate, then have native speakers review and edit. The cost per example rises, but the quality cliff disappears. For datasets of 500 to 5,000 examples, a short reviewer engagement usually pays for itself in evaluation consistency. Our annotation pipelines piece covers how to structure that review, and data tagging with native-speaker reviewers is a practical way to run it.
A worked example
Say a lender is building a Tamil and Hindi support assistant and has 2,000 real customer messages, most of them in Hindi. A sensible plan:
- Hold out a few hundred real messages in each language as the evaluation set, and never add synthetic data to it.
- Commission native speakers to paraphrase and extend the Tamil messages until coverage is comparable.
- Generate slot-filled variants (loan types, amounts, dates) from templates, plus a batch of out-of-scope queries.
- Have reviewers edit a sample of every synthetic batch, and drop any batch that needs heavy editing.
- Compare models trained with and without the synthetic data on the real evaluation set, with native-speaker ratings alongside automated scores.
Checklist before you generate
- Is there a real corpus you have not used yet?
- Is the evaluation set entirely real and held out?
- Do you have native speakers lined up to review samples?
- Can you trace every training example back to its source type?
FAQ
Can we machine-translate our English dataset instead?
Machine translation carries the same artefact problem as generation. It can be a starting point for native speakers to edit, but treat unedited translations as synthetic data and cap their share accordingly.
Which languages need the most care?
Lower-resource languages, where generators have seen the least real text, and any language in which your users mix scripts. Review more samples in those languages and keep their synthetic share lowest.
Is synthetic data ever safe for evaluation?
Only for narrow robustness checks, such as confirming the model declines out-of-scope requests, and even then keep it in a separate, clearly labelled split so it never inflates your headline scores.
How we approach this at Velura Labs
Our AI and data solutions team runs Indic data pipelines with the source-order discipline above, paired with custom LLM applications for the model side. For the broader user-research framing, read our Bharat design patterns. Talk to us before you generate a million synthetic Tamil examples; we will help you avoid the evaluation-set headache.
Whether you are in California, Texas or Washington in the US, France or Italy in Europe, the UAE or Saudi Arabia in the Gulf, or here in India, Velura Labs delivers this end to end. Talk to us about your context.