Apply for AI Grants India

Kannada instruction-tuning data should do more than pair a question with a plausible answer. It should teach a model to follow Kannada instructions, preserve local meaning, cite evidence, handle mixed-language input, and refuse requests when the source does not support an answer. Indian public documents are a strong starting point because they contain authentic administrative, educational, legal, health, agricultural, and civic language—but only when collected and transformed carefully.

This guide explains a reproducible workflow for building a dataset that a small research team or startup can audit and improve. It is designed for Kannada-first systems, including assistants, search tools, education products, and public-service applications.

Define the dataset before collecting documents

Start with the model behaviour you want to improve. A broad corpus of Kannada text is not automatically an instruction-tuning dataset. Write a task specification covering:

• Target users: citizens, students, government staff, farmers, customer-support agents, or researchers.
• Language policy: Kannada-only, Kannada with English terms, or Kannada-English code-mixed input and output.
• Task types: summarisation, question answering, classification, extraction, rewriting, translation, form assistance, and grounded dialogue.
• Evidence policy: whether every answer must quote or identify its source and whether unsupported answers must say “not available in the document”.
• Safety boundaries: personal data, medical advice, legal interpretation, political persuasion, and high-impact decisions.

A useful first release might contain 2,000–10,000 carefully reviewed examples across six to eight task types. A smaller, well-labelled dataset is generally more useful than a large collection of duplicated prompts. For the model-training stage, follow established best practices for fine-tuning LLMs on custom data, especially around validation splits and contamination checks.

Select Indian public documents responsibly

Prioritise sources that are authoritative, stable, and clearly attributable. Potential Kannada sources include:

• Karnataka government department websites, circulars, schemes, notifications, budgets, and citizen-service instructions.
• Legislative and local-government material, including publicly posted rules, meeting documents, and tenders.
• University repositories, open educational resources, and publicly available research summaries.
• Agriculture, health, disaster-management, transport, and election-information portals.
• Public-domain or openly licensed cultural and literary material.

“Publicly accessible” does not necessarily mean “free to reuse for model training.” Record the URL, publisher, publication date, licence or terms of use, access date, and any restrictions. Exclude pages that contain substantial personal information, leaked material, user comments, or unclear ownership. For sensitive domains, use a documented review process rather than assuming that government publication removes all privacy or compliance obligations. High-stakes deployments should also adopt a formal data veracity infrastructure for high-stakes AI.

Build a source register and collection pipeline

Create a source register before downloading content. Give each document a stable ID and store:

• Title, department or publisher, language, document type, date, URL, and licence status.
• File format, OCR requirement, version, checksum, and collection timestamp.
• Topic labels such as education, welfare, agriculture, health, or transport.
• Risk labels for personal data, medical content, legal content, or outdated policy.

Use official downloads or permitted APIs whenever possible. For web collection, respect robots.txt, rate limits, authentication rules, and terms of use. Keep the raw file unchanged in restricted storage, then create a processed copy. This makes it possible to reproduce errors, remove a source later, or prove which version supported a training example.

PDFs require special attention. Test extraction on Kannada Unicode text, scanned pages, tables, headers, footers, and multi-column layouts. OCR output should be treated as untrusted until reviewed: Kannada vowel signs, conjuncts, punctuation, numerals, and similar-looking characters are frequent error points. Preserve page numbers and section headings so each generated example can be traced to evidence.

Convert documents into instruction examples

Do not ask a language model to generate thousands of examples without controls. First segment each document into meaningful units: a scheme description, eligibility section, procedure, definition, table, or paragraph. Then generate task templates appropriate to that unit.

Examples include:

• Grounded question answering: “ಈ ಯೋಜನೆಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಲು ಬೇಕಾದ ದಾಖಲೆಗಳು ಯಾವುವು?”
• Concise summarisation: “ಈ ಅಧಿಸೂಚನೆಯ ಮುಖ್ಯ ಅಂಶಗಳನ್ನು ಐದು ಬುಲೆಟ್‌ಗಳಲ್ಲಿ ನೀಡಿ.”
• Information extraction: “ಅರ್ಹತೆ, ಕೊನೆಯ ದಿನಾಂಕ ಮತ್ತು ಸಹಾಯವಾಣಿ ಸಂಖ್ಯೆಯನ್ನು JSON ನಲ್ಲಿ ಹೊರತೆಗೆಯಿರಿ.”
• Classification: assign a query to a department, service, or document type.
• Rewrite: convert formal administrative Kannada into plain Kannada without changing obligations.
• Abstention: ask the model to state when the document does not answer the question.

Store examples in a consistent schema, such as:

{
  "id": "ka-gov-000184-q03",
  "instruction": "ಈ ಅಧಿಸೂಚನೆಯ ಅರ್ಹತಾ ನಿಯಮಗಳನ್ನು ಸರಳ ಕನ್ನಡದಲ್ಲಿ ವಿವರಿಸಿ.",
  "context": "...relevant source passage...",
  "response": "...reviewed Kannada answer...",
  "source": {"document_id": "ka-gov-000184", "pages": [2, 3]},
  "task": "grounded_rewrite",
  "language": "kn",
  "review_status": "approved"
}

Keep the answer grounded in the supplied passage. If a number, date, place name, office, or eligibility condition is changed, the example becomes actively harmful. Include negative examples where the correct response is clarification, refusal, or “the source does not specify this”.

Kannada-specific quality controls

Normalisation must be conservative. Do not erase meaningful punctuation, headings, numbers, or official names. Maintain a glossary for department names, schemes, legal terms, transliterations, and recurring abbreviations. Decide whether English technical terms should remain in Latin script, be transliterated, or be explained in Kannada; apply that decision consistently.

Use at least two review stages:

• Linguistic review: native Kannada reviewers check grammar, spelling, dialect sensitivity, natural phrasing, and code-mixing.
• Factual review: a separate reviewer verifies every answer against the cited pages.

Track measurable error categories: OCR corruption, hallucinated facts, mistranslation, omitted qualifiers, wrong dates, broken numerals, unnatural Kannada, privacy leakage, and unsafe advice. Calculate agreement on a sample rather than relying on a single editor. Keep rejected examples and rejection reasons in a quarantine log; they reveal weaknesses in your generation templates.

Split, evaluate, and test for leakage

Create training, validation, and test sets by document or source, not by randomly splitting near-identical paragraphs. Otherwise, the model may memorise a document and produce misleadingly high scores. Keep a challenging test set containing long passages, tables, spelling variation, Kannada-English queries, OCR noise, and questions whose answers are absent.

Evaluate both language quality and task reliability:

• Exact-match or field accuracy for dates, names, numbers, and structured extraction.
• Evidence-supported answer rate for question answering.
• Abstention precision when the source lacks an answer.
• Human ratings for naturalness, completeness, and instruction following.
• Safety error rate for medical, legal, financial, and personal-data prompts.

Before release, run memorisation and privacy scans, deduplicate near-identical examples, and document known gaps. If the dataset will support a voice interface, test spoken-query variations separately; Kannada text quality alone does not guarantee good speech performance. Teams building regional products can also study Indian open-source AI developer projects for reusable tooling and evaluation ideas.

A practical release checklist

A publishable dataset should include:

• A data card describing scope, sources, dates, languages, tasks, and limitations.
• Source-level licence and provenance records.
• A removal process for restricted or incorrectly included documents.
• Annotation guidelines and reviewer training notes.
• Versioned train, validation, and test files with checksums.
• Safety exclusions, privacy handling, and known dialect or domain gaps.
• Baseline results from at least one open model and one non-tuned comparison.

Refresh policy-heavy content regularly, but do not silently replace old versions. Retain version history and mark superseded documents. This matters for government schemes, deadlines, eligibility rules, and service procedures that change over time.

Common mistakes to avoid

The most damaging shortcuts are translating English prompts mechanically, treating OCR output as ground truth, mixing licensed and unlicensed text, generating answers without citations, and evaluating only fluent prose. Avoid over-representing Bengaluru or formal government Kannada if the product serves rural users or other regions. Include plain-language requests, spelling variation, respectful forms, and realistic code-mixed queries.

A strong Kannada instruction dataset is ultimately a provenance and review system, not just a file of prompts. Start with a narrow domain, establish traceability, measure factual and linguistic errors, and expand only after the first release passes human review. For founders building India-focused language products, this disciplined approach creates a better foundation for trustworthy deployment and future multilingual expansion.

Apply for AI Grants India

Building a Kannada AI product or an open dataset for Indian-language technology? Apply for support at AI Grants India to explore funding and ecosystem support for your project.