Scaling a Bangla-English AI Chatbot Across Five Government Services

The National Digital Service Assistant (NDSA) platform gives citizens and government employees a faster alternative to traditional, human-staffed support. Rather than one generic bot, Nascenia built each participating service its own specialized virtual assistant on a shared technical core, so each could speak to that service’s specific rules, forms, and processes.
Of five service-specific chatbots delivered, MyGov, Muktopaath, Isec, and the Teacher’s Portal are live in production, while eCourt is complete and running on a test server, pending the added review judiciary-linked systems required before public launch.

Objectives of the Project

1. Build an intelligent virtual assistant for each e-governance service on one shared platform.
2. Provide 24/7 availability, not limited to office hours.
3. Support natural interaction in both Bangla and English.
4. Keep each chatbot grounded strictly in its own knowledge base to avoid misinformation.
5. Reduce human support load by auto-resolving common queries and escalating only the harder cases.

Technical Challenges We Faced and How We Solved Them

Bangla as a Low-Resource Language

Bangla is poorly served by mainstream NLP tooling compared to English. We evaluated several word-embedding approaches – including one built from local newspaper corpora – before settling on FastText for its vocabulary coverage and practicality. Regex extraction handled structured entities like emails, while synonym mapping caught the same intent phrased differently.

Balancing Guided Flows with Open Conversation

Some citizens want to be walked through a process step by step; others just want a direct answer. RASA Core handles guided journeys via webhooks and WebSocket, while free-form questions go to a RAG Server that queries the GPU-hosted ML API. A Data Scraper and Data API keep content current, and an Analytical Server logs activity for the Admin Panel:

This split lets CPU-bound conversation logic and GPU-bound inference scale independently, moving fluidly between guided and open-ended interaction within one session.
Keeping Every Answer Grounded in the Right Knowledge Base
A generic “one model answers everything” approach risked confidently wrong answers, so each service’s documents are chunked with LangChain, embedded, and stored in a dedicated Chroma vector database:

Each model answers only from its own retrieved context, not general knowledge – keeping responses traceable to a source document and easy to audit.

Scaling a Shared ML Backbone Across Independent Platforms

MyGov, Muktopaath, Teacher’s Portal, and Isec each run on their own CPU server with a platform-specific knowledge base and chat window, but all share one centralized GPU server for LLM and embedding inference:

This lets four services reach production without duplicating GPU infrastructure, and leaves a clear path to horizontally scale the ML layer with a load balancer as traffic grows.

Feeding the Models from Live, Messy Government Data

Most source content arrived as unstructured documents rather than a ready-made FAQ set. An admin panel per service lets authorized staff upload or remove training documents, review poorly-answered queries, and retrain directly – without engineering support for routine updates.

Handing Off to a Human When the Bot Can’t Help

Every chatbot includes a fallback path that escalates to a human agent, with conversation context, whenever automated confidence is low – so no citizen is left stuck.

Collaboration Challenges

Dependencies on Client-Provided Infrastructure and Data

Each rollout depended on a2i and the relevant ministry supplying servers, datasets, and APIs on schedule. Where these arrived late, the chatbot’s timeline moved with them – the main reason eCourt, though technically complete, still awaits production sign-off.

Coordinating Across Independently Maintained Web Properties

Each service is kind of like a platform, owned by a different team, and it is maintained on its own. So we needed to treat the chatbot as something self contained , a pluggable part, with its own front end plus an API gateway. In other words, more like a lightweight embed rather than a major code change, so we can give a consistent conversation experience across all sites, without stepping on the host application.  

Going in early with a common architecture is pretty clearly justified, because when 4 out of 5 chatbots go into production you start to see it working. The test server status for eCourt doesn’t really point to a development gap, it more suggests the longer runway that risk sensitive sectors, like the judiciary, rightly ask for. We also have room to get tighter with dependency tracking alongside a2i, and to reuse the Bangla NLU plus the knowledge base tooling that’s already been proven in production as more services become available.

Frequently Asked Questions

Do the chatbots support Bangla?

Yes. They converse naturally in both Bangla and English, using FastText embeddings, regex extraction and synonym mapping to handle different phrasings.

How do you stop the chatbots from giving wrong answers?

Each chatbot answers only from its own service’s knowledge base, stored in a dedicated vector database, so every answer traces back to a source document.

What happens when the chatbot can’t help?

When confidence is low, the chatbot escalates to a human agent with the conversation context, so citizens aren’t left stuck.