Marathi Medical Support Chatbot

BACHELOR OF ENGINEERING IN COMPUTER

ENGINEERING

By

Prajwal Shevante 223A1134

Yash Shinde 223A1135

Vikneshlaxman Nityanand 122A1122

Prof. Sujata K.

Department of Computer Engineering

SIES GRADUATE SCHOOL OF TECHNOLOGY
NERUL, NAVI MUMBAI – 400706
ACADEMIC YEAR
2024 – 2025

Department of Computer Engineering

 CERTIFICATE

This is to certify that the Mini Project entitled “Marathi Medical Support Chatbot” is
a bonafide work of Prajwal Shevante (223A1134), Yash Shinde (223A1135) and
Vikneshlaxman Nityanand (122A1122) submitted to the University of Mumbai in
partial fulfillment of the requirement for the award of the degree of “Bachelor of
Engineering” in “Computer Engineering”

Prof. Ujwala R

Mentor

Dr. Aparna Bannore Dr. K. Lakshmisudha

Head of Department Principal

Department of Computer Engineering

 Mini Project Approval

This Mini Project entitled “Marathi Medical Support Chatbot” by Prajwal Shevante
(223A1134), Yash Shinde (223A1135) and Vikneshlaxman Nityanand (122A1122) is
approved for the degree of Bachelor of Engineering in Computer Engineering.

Prof. Ujwala R

Mentor

Date:
Place:

Department of Computer Engineering

 Contents

Acknowledgement i

Abstract ii

List of Figures iii

1 Introduction 1

1.1 Introduction

1.2 Motivation

1.3 Problem Statement & Objectives

1.4 Scope

2 Literature Survey 5

2.1 Survey of Existing System

3 Proposed System 8

3.1 Proposed System

3.2 System Framework

3.3 Algorithm and Process Design

3.4 Details of Hardware & Software

3.5 Conclusion and Future work.

4 Design and Methodology 18

Department of Computer Engineering

 4.1 Design details
4.2 Methodology
5 Result and Discussion 24
5.1 Implementation
5.2 Results and Discussions
6 Conclusion and Future Scope 30
6.1 Conclusion
6.2 Future Scope
7 References 32

7.1 References

Department of Computer Engineering

 ACKNOWLEDGEMENT

We would like to thank our guide Ujwala R. for continuous guidance and support
throughout the project. A special thanks goes to each team member who worked
together in completing the project, where we all exchanged ideas and made it possible to
complete our project with accurate information. We also wish to thank our parents for
their personal support and attention who inspired us to go our own way.
We also extend our sincere gratitude to our Principal, Dr. K. Lakshmisudha and our
Head of the Department, Dr. Aparna Bannore for their continuous support and
encouragement.
We would also like to thank our other faculty members for providing us with all the
required resources and references for the project.

i
 ABSTRACT

Access to reliable medical information in local languages is critical in India. The

Marathi Medical Support Chatbot is a proof-of-concept conversational assistant
tailored to Marathi-speaking users that provides health information, symptom guidance,
and triage suggestions. The system combines a translation lookup (local dataset), an
LLM-based medical-response generator (Gemini in our prototype), and a Flask-based
chat frontend. It aims to be low-cost, privacy-aware, and easy to deploy for clinics,
telehealth pre-screening, and public health outreach.
This project demonstrates a pipeline that: (1) accepts Marathi user queries, (2) maps
them to English using a preloaded parallel dataset (samanantar) when possible, (3)
queries a generative model for an answer, and (4) returns the answer translated back to
Marathi. We highlight system components, algorithmic choices, evaluation observations,
limitations (safety & clinical validation), and future directions including domain-specific
fine-tuning, offline models, and integration with local health services.

ii
iii
 CHAPTER -1
INTRODUCTION

1.1 Problem Statement & Objectives

Problem Statement:

Distracted driving is an ever-present and hazardous situation on roadways around the

world. The World Health Organization (WHO) and in India, the Ministry of Road
Transport and Highways state that millions suffer serious injury or fatality due to road
traffic accidents every year, with distracted driving being a major cause among others.

Distractions can come in important terms which are cognitive, visual, or manual. Any
of these distractions will impair a driver's reaction time, a driver's ability to make sound
decisions and provide attentiveness to the road which all contribute to the likelihood of
the accident in which the incident could occur. While education on distracted driving is
increasing, there needs to be an intelligent camera-based solution that is capable of
tracking and evaluation driver behaviour, capture and identify distractions immediately,
and notify the driver when they are outside of optimal driving conditions thereby
preventing an accident or incident.
Objectives:

1 Driver drowsiness and fatigue detection: Make mechanisms to be able to detect

tiredness signals like prolonged eye closure, excessive blinking and yawning through
the use of facial landmarks and eye state classification.

2 Mobile phone detection: Detect gestures that are hand-to-ear that indicate phone use
while driving.

3 Real-time alerting: Combined into a system through multiple real-time detection

modules that can produce audio or visual alerts when any form of distraction is
detected.

Department of Computer Engineering

4 Safety enhancements through monitoring: Make sure the system is unobtrusive,
lightweight, and flexible for any type of vehicle so that it can be installed in all types
of vehicle types and help make our road usage safer.

1.2 Scope

This report outlines the design and development of a distracted driver detection system,
aimed at the detection of common in-vehicle distractions using computer vision and
machine learning. The report focuses on drowsiness detection through yawn and eye
closure detection leveraging facial landmark detection and eye state classification.
Beyond detection of drowsiness, there were theoretical models and techniques explored
for detecting other common modes of distractions. The proposed methods for detecting
these other distractions included hand tracking analysis and gaze estimation.
The report also includes information on how the complete system was architected,
which tools and libraries were employed, and challenges faced during implementation.
Ultimately, this report represents our best effort to demonstrate how artificial
intelligence can be applied to improve driver safety by way of continuous, real-time
monitoring.

Department of Computer Engineering

 CHAPTER -2

LITERATURE SURVEY

2.1 Survey of Existing Systems

Sr. Title / System Year Purpose Issues

No.

1 Symptom-checker 2018– Triage & advice, mostly Often limited language

chatbots (commercial) 2023 English support; medico-legal
risks

2 AI4Bharat translation 2021 Parallel datasets for Coverage & domain

resources (Samanantar) Indian languages mismatch for medical
jargon

3 Deep Learning for 2020– Conversational agents in Need domain fine-tuning

clinical dialogue 2023 healthcare and safe-response
guardrails

4 Local language health 2019– Increase health access Small datasets; quality
bots (research 2022 via local language UI varies by dialect and
prototypes) region

Department of Computer Engineering

 CHAPTER -3

PROPOSED SYSTEM

3.1 Proposed System

The Marathi Medical Support Chatbot architecture is designed for clarity and safety. Main
components:
1. Frontend (Flask + HTML UI): Accepts Marathi user input, shows conversation
history, and displays English intermediate steps for debugging (prototype).
2. Translation lookup layer: A preloaded in-memory sample from
ai4bharat/samanantar is used to map Marathi sentences to English equivalents (and
vice versa) when exact matches exist. This accelerates common-phrase handling.
3. LLM layer (Gemini prototype): English text is sent to a generative model to
produce a concise, helpful response with medically cautious phrasing.
4. Back-translation layer: Map the LLM’s English response back to Marathi using the
sample dictionary when possible.
5. Response & logging: Return the final Marathi reply; log session metadata and
anonymized message pairs for future improvement.

Design principles: safety-first (no prescriptions), transparency (show translation steps

during development), privacy (local dataset + optional local logging), modularity (swap
LLM or translation component easily).

Figure 3.1.1 — Proposed System Architecture (frontend → translation → LLM → back-

translation → UI).

3.2 System Framework

1. User Interface Layer

Department of Computer Engineering

 o Simple chatbox in Marathi.
o Shows intermediate English mapping for development/QA.
2. Application Layer
o Translation modules (marathi_to_english_dict, english_to_marathi_dict).
o LLM connector (Gemini client wrapper).
o Safety wrapper that appends medical disclaimers and triage escalation rules.
3. Communication Layer
o Flask REST endpoint /chat receives JSON input.
o Server validates message and orchestrates translation + LLM call.
4. Data Layer
o In-memory translation dictionaries (sampled dataset).
o Optional local logs with timestamps and anonymized IDs.

3.3 Algorithm and Process Design

Data representation
 Each incoming Marathi message is normalized and looked up in
marathi_to_english_dict.
 If present, the mapped English text is used; otherwise, the original Marathi text is
sent to the LLM after a short wrapper that instructs the model to respond concisely
and cautiously.
Flow
1. Client sends Marathi message to /chat.
2. Server runs translate_marathi_to_english(marathi_text).
o If lookup hit: use cached English phrase (faster, consistent).
o If miss: optionally run a fallback translation (not in prototype), or send
Marathi + instruction to LLM.
3. Call get_gemini_response(english_request) to obtain English response.
4. Map English response back to Marathi via translate_english_to_marathi if an exact
mapping exists; otherwise return English response and a Marathi fallback note
(prototype chooses to return English_response mapped where possible).
5. Send JSON with intermediate fields to frontend: english_request, english_response,
final_marathi_response.

Department of Computer Engineering

Safety policies & guardrails
 Prepend LLM prompt with constraints: “Do not give prescriptions; provide general
guidance; always advise to see a doctor for serious symptoms; include escalation
steps if red-flag symptoms present.”
 If user describes emergency symptoms (e.g., severe chest pain, unconsciousness),
the server replies with a canned emergency escalation message in Marathi and
avoids open-ended counsel.

Figure 3.3.1 — Translation + LLM Pipeline diagram.

3.4 Details of Hardware & Software

Hardware
 Development laptop: CPU (Intel i5/Ryzen 5), 8GB+ RAM.
 Production: small VPS or local clinic server; no GPU required for prototype since
LLM calls are API-based.
Software
 Python 3.8+
 Flask (web server)
 [Link] / Gemini client (LLM API)
 datasets (HuggingFace) for sampling Samanantar
 python-dotenv for keys
 Optional: sqlite or file-based logging
Key libraries used in prototype
 Open-source translation dataset: ai4bharat/samanantar (mr)
 LLM: Gemini (via genai in prototype)
 Web: Flask templates & fetch API for chat UI

3.5 Conclusion and Future Work (summary)

The proposed architecture balances accessibility (Marathi) and generation quality (LLM) by
leveraging a translation dataset as a bridge. It is designed to be a safe, modular starting point
that can be extended with domain fine-tuning and offline translation models.

Department of Computer Engineering

 CHAPTER-4
DESIGN AND METHODOLOGY
4.1 Design details
Flowchart summary (Fig 4.1.1):
1. User types Marathi message (UI).
2. Server normalizes and looks up translation dictionary.
3. If lookup hit → mapped English request; else → send an English instruction +
original Marathi to LLM.
4. LLM returns English response (with safety instructions in the prompt).
5. Server maps English response to Marathi using dictionary lookup; if not available,
returns English (with Marathi note) or runs fallback translation.
6. Client displays final Marathi response and optionally shows intermediate steps for
debugging.
Key UI elements
 Chat window with history
 Input box (Marathi)
 Status indicators (translation hit/miss, LLM in progress)
 Safety disclaimer visible on first use
4.2 Methodology
Project phases
1. Requirements and safety definition (non-prescriptive medical guidance).
2. Data sampling: stream a sample of ai4bharat/samanantar to populate
marathi_to_english_dict.
3. Prototype implementation: Flask server, translation lookup, Gemini call wrapper,
basic UI.
4. Testing: sample user queries, edge-cases (empty message, emergency symptoms),
and translation hit/miss verification.

Department of Computer Engineering

 5. Evaluation: measure how often the dataset returns an exact mapping for common
phrases and note LLM response quality.
6. Documentation and demonstration.
Implementation notes from prototype
 The prototype uses streaming dataset access to avoid downloading full dataset.
 It stores mapping in two dictionaries for fast lookup.
 LLM interactions are rate-limited via [Link](1) to respect free-tier constraints in
the example.
 Error handling returns a Marathi fallback message when LLM or dataset access fails.

Department of Computer Engineering

 CHAPTER-5
RESULT AND DISCUSSION

5.1 Implementation
We implemented a Flask server with routes:
 / — main chat UI
 /chat (POST) — receives Marathi message JSON and returns:
o english_request (string)
o english_response (string)
o final_marathi_response (string)
Sample UI screenshots (Fig 5.1.1 Chat UI). The UI displays translation steps and final
responses for debugging. The server loads up to 20,000 sentence pairs from Samanantar into
memory on startup (configurable).

5.2 Results and Discussions

Translation lookup effectiveness
 For commonly phrased queries (e.g., symptom names, simple requests), the
Samanantar lookup returned direct mappings in a useful percentage of cases.
 Many medical or colloquial Marathi queries missed exact translation matches —
expected because Samanantar is general-domain.
LLM response quality
 The Gemini-based responses were generally clear and concise for general health
questions.
 Without domain fine-tuning the model sometimes produced generic answers; adding
strict prompt guardrails improved safety.
Observed issues
9

Department of Computer Engineering

  Medical safety: LLMs can hallucinate or provide overly confident answers. We
mitigate with prompt instructions and a clear “see a doctor” escalation.
 Translation coverage: Exact-match dictionary lookup is brittle. Better fallback
(translation model or bilingual LLM prompt) is needed for production.
 Latency: External API calls add delay. Caching common Q/A can improve UX.
 Privacy: Sending user concerns to an external API has privacy implications. For
deployment in clinics, either use on-prem models or get explicit user consent.
User experience
 Marathi replies increase comprehension for native speakers.
 Showing intermediate steps helps during development but should be hidden in
production.

10

Department of Computer Engineering

 CHAPTER 6

CONCLUSION AND FUTURE SCOPE

6.1 Conclusion

The Marathi Medical Support Chatbot prototype demonstrates a practical pipeline that
connects a local translation sample and an LLM to provide Marathi conversational medical
guidance. It improves accessibility for Marathi speakers and shows how dataset-driven
translation plus an LLM can be combined quickly. The system is a prototype, not a clinical
tool. With careful safety design and domain-specific tuning, this approach can be extended
into a robust assistive service.

6.2 Future Scope

1. Medical safety & clinical validation

o Collaborate with medical professionals to craft response templates and

escalation rules.

o Add a clinical review loop for high-risk categories.

2. Better translation

o Integrate a production-quality Marathi ↔ English translation model (offline or

on-prem).

11

Department of Computer Engineering

 o Fine-tune bilingual models on medical dialogues.

3. Domain fine-tuning

o Fine-tune the LLM on verified medical Q/A to reduce hallucinations and

improve specificity.

4. Offline/on-prem deployment

o Explore smaller, deployable models to avoid sending sensitive queries

externally.

5. Escalation & integration

o Connect with local clinics, telemedicine providers, or ambulance services for

emergency escalation.

6. Multimodal input

o Add voice input in Marathi, OCR for prescriptions, and simple forms to
capture structured symptoms.

7. Personalization & privacy

o Implement optional user profiles for chronic conditions while preserving

privacy through encryption and opt-in data storage

12

Department of Computer Engineering

 REFRENCES

1. AI4Bharat — Samanantar dataset (parallel corpora for Indian languages).

2. Research papers and articles on clinical chatbots and safety in medical LLM usage
(various 2019–2023).
3. Gemini (Google) API documentation — for generative model usage and best
practices.
4. Papers on language resources for Indian languages and multilingual translation.

13

Department of Computer Engineering