Apply for AI Grants India

What this workflow is for

Local language LLM fine-tuning on GitHub is not simply a matter of downloading a repository and running a training script. GitHub provides the code, configuration, issue history, model cards, and reproducible workflows; the quality of the result depends on your base model, data rights, language coverage, and evaluation design.

For Indian-language applications, the hardest problems are often practical: mixed scripts, transliterated text, spelling variation, code-switching, dialect differences, and limited high-quality instruction data. Start with a narrow use case—such as customer-support answers in Marathi, agricultural guidance in Kannada, or document extraction in Hindi—rather than trying to create a general-purpose model immediately.

Builders working with scarce data should first review this guide to low-resource Indic natural language processing. It explains why tokenisation, domain balance, and evaluation require different decisions from those used for English-heavy benchmarks.

Choose the right adaptation strategy

Fine-tuning is only one option. Select the lightest approach that solves the problem:

• Prompting or retrieval-augmented generation: Best when facts change frequently or the task mainly requires access to documents.
• Supervised fine-tuning (SFT): Suitable for consistent response formats, domain terminology, and instruction-following behaviour.
• LoRA or QLoRA: Usually the most practical starting point for Indian startups and researchers because only a small set of adapter weights is trained.
• Continued pretraining: Useful when you have a large, clean corpus in the target language, but it needs substantially more compute and careful data governance.

For a broader checklist on data splits, hyperparameters, and failure modes, use best practices for fine-tuning LLMs on custom data. Do not fine-tune merely to add factual knowledge that could be retrieved from a maintained source.

Find and audit GitHub repositories

Search GitHub for repositories containing transformers, peft, trl, bitsandbytes, Indic-language datasets, and the name of your target model. Prefer projects that include:

• A maintained README and a clear licence.
• Pinned dependency versions or a reproducible environment file.
• Dataset cards describing source, licence, language, and preprocessing.
• Training and evaluation scripts that can be run on a small sample.
• An issue tracker showing recent maintenance and transparent limitations.
• Model cards that state supported languages, context length, quantisation, and intended use.

Treat random notebooks and repositories with copied credentials, unverified downloads, or unclear data provenance as unsafe. Clone into an isolated environment, inspect scripts before execution, and pin package versions. If you want to improve an existing project rather than only consume it, see how to contribute to AI GitHub repositories in India.

Prepare Indian-language data carefully

Data quality usually matters more than adding another training epoch. Build a dataset that reflects the actual users and task:

• Separate languages, dialects, scripts, and transliterated text in metadata.
• Remove duplicates, boilerplate, spam, personally identifiable information, and unsafe instructions.
• Preserve native punctuation and sentence boundaries where they carry meaning.
• Record source, licence, collection date, language, domain, and filtering decisions.
• Keep train, validation, and test sets separated by document or source—not just by random rows.
• Include hard cases: code-switching, named entities, numerals, honorifics, spelling variants, and short user messages.

For sources suitable for Indian AI projects, consult low-resource language datasets for AI training in India. Confirm that commercial use, redistribution, and model training are permitted. Publicly accessible text is not automatically free of copyright, privacy, or contractual restrictions.

A practical instruction record might look like this:

{"messages":[
  {"role":"user","content":"किसान के लिए खरीफ फसल की संक्षिप्त सलाह दें।"},
  {"role":"assistant","content":"स्थानीय मौसम और मिट्टी की जाँच के बाद..."}
]}

Keep an untouched evaluation set. Never use generated answers from the same model as your only ground truth; they can reinforce errors and unnatural phrasing.

Set up a reproducible training project

A lightweight project structure makes GitHub collaboration easier:

project/
├── data/README.md
├── configs/lora.yaml
├── scripts/prepare_data.py
├── scripts/train.py
├── scripts/evaluate.py
├── requirements.txt
└── README.md

Create an isolated environment and install only the versions you have tested:

python -m venv .venv
source .venv/bin/activate
pip install torch transformers datasets accelerate peft trl bitsandbytes evaluate

Use a decoder-only instruct model that genuinely supports the target language. Do not treat bert-base-multilingual-cased as a drop-in causal chat model: BERT is generally an encoder model, while conversational generation requires a compatible causal language model and chat template. Check the tokenizer before training; poor token coverage can make a supposedly small dataset expensive and produce broken output.

For limited GPU memory, QLoRA with 4-bit loading is a sensible baseline. Begin with conservative sequence lengths, gradient accumulation, and a small pilot run. Log the exact base-model revision, dataset hash, random seed, GPU type, batch settings, and adapter configuration.

Train adapters before changing the base model

A typical LoRA experiment should vary one factor at a time: learning rate, rank, target modules, sequence length, or data mixture. Save checkpoints and evaluate after each meaningful interval. Watch for:

• Training loss falling while validation loss rises.
• Fluent Hindi or another target language being replaced by English.
• Memorisation of names, phone numbers, or source passages.
• Loss of general capabilities after domain training.
• Responses that are grammatically correct but culturally or factually unsafe.

Use early stopping where available. Keep a baseline model and compare it with the adapted model on the same test set. Adapter weights are easier to review, distribute, roll back, and license than a full model merge.

Evaluate language quality, not just loss

Perplexity and loss are useful diagnostics, not product metrics. Build a small human-reviewed suite covering:

• Language identification and script correctness.
• Instruction adherence and answer completeness.
• Translation or transliteration accuracy, if relevant.
• Named entities, numbers, dates, and units.
• Dialect and code-switching robustness.
• Hallucination, toxicity, privacy leakage, and refusal behaviour.

Use native speakers familiar with the domain, and score outputs with a documented rubric. Compare against the base model, a retrieval baseline, and—where appropriate—a strong hosted model. Report results by language and task instead of hiding weak performance inside one average score. For Hindi-focused model options, compare the approaches outlined in open-source small language models for Hindi.

Deploy responsibly in India

Package the adapter, tokenizer, base-model identifier, licence notices, training-data statement, evaluation results, and known limitations. Test inference on the hardware you actually plan to use; a model that trains on an expensive cloud GPU may still be unsuitable for a local or edge deployment.

For production, expose a versioned API, validate input length, redact sensitive logs, rate-limit requests, and monitor language-specific failures. Keep a rollback path and a process for removing contaminated or legally disputed data. If the use case involves health, finance, benefits, or public services, add human review and clear escalation routes.

A practical GitHub release checklist

Before publishing, confirm that the repository contains:

• Reproducible setup and training commands.
• Data documentation without exposing restricted or personal records.
• Licence and attribution information.
• Evaluation scripts, test examples, and per-language results.
• Model-card limitations, safety notes, and intended use.
• Issue templates for bug reports and language-quality feedback.

The strongest local-language projects are transparent about what they cannot do. Start with a measurable Indian-language task, run a small adapter experiment, evaluate with native speakers, and publish enough detail for another builder to reproduce—or challenge—your result.