ONDC is a network protocol, not a single storefront. That distinction matters when adding language AI: your model must work across buyer and seller applications, commerce domains, and structured network flows rather than only produce fluent chat. This guide explains how to train Indian language models for ONDC integration in a way that is measurable, interoperable, and useful for Indian users.
A strong implementation usually combines a multilingual foundation model with task-specific fine-tuning, retrieval, translation, speech components, and deterministic business logic. Do not ask a language model to invent catalogue attributes, prices, delivery promises, or order states. Let the model handle language; let ONDC-compliant services and your transaction systems remain the source of truth.
Start with specific ONDC language tasks
Define the user journeys before collecting data or selecting a model. Common applications include:
- Discovery: Convert a Hindi, Tamil, Bengali, Marathi, Telugu, Kannada, Malayalam, Gujarati, Punjabi, Odia, or mixed-language request into structured search filters.
- Catalogue assistance: Explain product descriptions, ingredients, sizes, warranties, and policies in the user’s preferred language.
- Seller tools: Help small businesses create listings, translate attributes, classify products, and respond to customer questions.
- Order support: Explain order status, cancellations, returns, and refunds using verified transaction data.
- Voice commerce: Transcribe speech, handle code-switching, and respond through text or voice.
Write an intent and entity schema for each flow. For example, a grocery query may require category, brand, quantity, dietary_preference, location, and budget. Keep these fields separate from free-form text so downstream search and fulfilment systems can validate them.
For voice-first experiences, review the practical trade-offs in voice agent services for Indian businesses. ONDC assistants often need low latency, interruption handling, and escalation to a human—not just a capable text model.
Build a representative data pipeline
Data quality and coverage matter more than raw volume. Combine several sources, but document provenance, consent, licence terms, and permitted commercial use.
- Real commerce language: Collect anonymised search queries, support tickets, seller catalogue text, FAQs, and call transcripts. Remove phone numbers, addresses, payment details, and order identifiers.
- Indic resources: Use openly licensed corpora, parallel translation data, speech datasets, and tokenisers. Inspect each dataset for language balance, duplicated text, and licence restrictions.
- Human-created examples: Ask native speakers to write natural requests, including spelling variation, Roman-script input, code-mixing, abbreviations, and local product names.
- Synthetic augmentation: Generate paraphrases and translations only after establishing human-reviewed seed examples. Synthetic data should expand coverage, not replace authentic usage.
Create evaluation splits by user, seller, geography, and time, not random rows alone. This prevents leakage from repeated catalogues or conversations. Maintain separate challenge sets for Romanised Indic text, dialect variation, noisy speech transcripts, named entities, and safety-sensitive requests.
For low-resource languages, the methods in this builder’s guide to low-resource Indic NLP are especially relevant. Start with transfer learning and targeted annotation rather than attempting to train a large model from scratch.
Preprocess without erasing meaning
Indic text requires careful normalisation. Unicode normalisation, punctuation handling, spelling variants, transliteration, and tokenisation can materially affect results. Do not blindly lowercase or remove symbols: product codes, quantities, currency values, and brand names may depend on them.
Build language identification that supports mixed utterances. A user may type “mujhe red kurta chahiye” or speak in one language while inserting English product terms. Preserve the original text alongside normalised forms, and store detected language with confidence rather than forcing every request into one label.
For speech, measure word error rate separately by language, accent, speaking speed, and device quality. A transcription error in a product name or quantity can lead to an incorrect order, so add confirmation steps before any consequential action.
Select and adapt the model
Choose the smallest model that meets accuracy, latency, privacy, and cost requirements. A practical architecture may include:
- A multilingual encoder or instruction-tuned model for intent and entity extraction.
- A retrieval layer for catalogues, policies, and seller information.
- A translation or transliteration component where direct multilingual generation is weak.
- Tool-calling interfaces that return validated ONDC and order-system data.
- A smaller classifier for routing, language identification, and fallback decisions.
Begin with prompting and retrieval baselines. Then fine-tune using supervised examples for classification, structured extraction, translation, response rewriting, and tool selection. Parameter-efficient methods such as LoRA can reduce compute and make language- or domain-specific updates easier to manage.
Keep training targets precise. For catalogue extraction, prefer JSON constrained by a schema over prose. For customer support, train the model to cite the retrieved policy and say when information is unavailable. Never reward confident guessing simply because it sounds helpful.
Evaluate commerce outcomes, not just fluency
BLEU or ROUGE can be useful for narrow translation comparisons, but they do not show whether a buyer found the right product or received a safe answer. Build a scorecard covering:
- Intent accuracy and entity-level precision, recall, and F1.
- Search success, attribute extraction accuracy, and add-to-cart completion.
- Translation adequacy, terminology consistency, and human preference.
- Speech word error rate and end-to-end task completion.
- Hallucination rate, refusal quality, and policy adherence.
- Latency, cost per interaction, uptime, and fallback frequency.
Have native-language evaluators review outputs for politeness, dialect fit, cultural context, and unintended offensive meanings. Report results by language and script; an overall average can hide poor performance in smaller language groups. Test adversarial inputs such as misleading seller claims, prompt injection in catalogue text, requests for restricted goods, and attempts to expose personal data.
Integrate safely with ONDC systems
Place the model behind a versioned service layer rather than coupling it directly to every buyer or seller application. Define stable interfaces for language detection, intent extraction, catalogue retrieval, response generation, and transaction actions.
Use these controls in production:
- Require explicit confirmation before placing, cancelling, or modifying an order.
- Validate every extracted field against catalogue, inventory, logistics, and payment systems.
- Log model version, prompt or template version, retrieved sources, confidence, and tool results—while protecting personal data.
- Add deterministic fallbacks for unsupported languages, low confidence, outages, and sensitive cases.
- Provide an easy language switch and a human support route.
- Encrypt data, enforce access controls, set retention limits, and conduct privacy reviews.
For seller-facing workflows, combine automated classification with human review for regulated categories, health claims, financial products, and disputes. Feedback should be labelled before it enters future training data. An automated feedback pipeline, such as user feedback categorisation for Indian SaaS, can help organise this process, but never treat unverified feedback as ground truth.
A practical 2026 rollout plan
Phase one: baseline. Select two or three high-volume languages and one narrow journey, such as multilingual product search. Establish a non-AI baseline and a human-reviewed test set.
Phase two: pilot. Deploy retrieval, structured extraction, confirmation prompts, and monitoring with a limited group of buyers and sellers. Track completion, correction, and escalation rates.
Phase three: expand. Add languages and voice only after measuring quality separately for each one. Retrain on reviewed errors, refresh terminology, and run regression tests before every release.
Phase four: network readiness. Test across participating applications, catalogues, domains, devices, and connectivity conditions. Publish limitations and maintain rollback procedures.
The goal is not to make ONDC sound multilingual in a demo. It is to help people discover, understand, and complete commerce transactions accurately in the language they use. Builders that pair Indic language expertise with strict data contracts, evaluation discipline, and human fallback will produce systems that are more trustworthy—and more useful at national scale.