Building a Multilingual Campus Helper That Answers Only From Trusted Data

Students ask small, practical questions. When is the assignment due? Is the library open on Sunday? Where's the IT support office? Who handles student services? The answers usually exist, but they're scattered across notices, LMS pages, timetables, emails, group chats and separate departments. CampusAI is a prototype built to make that lookup easy, without becoming a chatbot that confidently invents answers.

What it is

CampusAI is a multilingual student-support assistant aimed at higher-education institutions. Instead of hunting through several systems, a student types a natural question such as "When is my Network Security assignment due?" The app searches its institutional knowledge base, picks the matching record, sends only that record to Google Gemini, and gets back a student-friendly reply. It works in English, Tamil and Sinhala, because an assistant shouldn't force every student into one language.

The real problem

Wiring Gemini to a chat box is the easy part. The harder question is how to get answers from trusted campus information instead of made-up ones. In student support, wrong information can be worse than none. Picture an assistant saying an assignment is due next week when the real deadline is tomorrow.

That led to three principles: retrieve first, generate second, and cite the source.

How it fits together

The architecture is deliberately plain. A question goes through the interface to a retrieval engine, which queries the knowledge base. Only the relevant records reach Gemini, and the reply comes back in the student's language with its source attached:

Student
   ↓
CampusAI UI
   ↓
Retrieval Engine
   ↓
Campus Knowledge Base
   ↓
Relevant Records
   ↓
Google Gemini
   ↓
Multilingual Answer + Source

The prototype is built with Python and Streamlit, uses Google Gemini through the Google Gen AI SDK, keeps institutional knowledge in JSON, relies on a custom retrieval and relevance-scoring layer, and tracks changes with Git and GitHub.

Organizing the knowledge

Rather than keeping one giant file, the data is split by topic, one file per area:

data/
├── assignments.json
├── contacts.json
├── courses.json
├── general.json
├── library.json
├── policies.json
└── services.json

A single library record looks like this:

{
  "id": "LIB-001",
  "category": "library",
  "title": "Library Opening Hours",
  "content": "The campus library is open Monday to Friday from 8:00 AM to 6:00 PM. On Saturday it is open from 8:00 AM to 1:00 PM. The library is closed on Sunday.",
  "source": "Library Information Notice"
}

All of this is demonstration data, not official records from a real institution. That distinction matters. The goal is to prove an architecture that could later run on approved institutional information.

Retrieval comes before generation

The first version sent the entire knowledge base to Gemini with every question. It worked, but it doesn't scale. The more information an institution holds, the more wasteful it is to send everything, and unrelated content makes grounding less precise.

So a retrieval layer was added. For a question like the assignment one, the retriever works through these steps:

1. Normalize the question.
2. Strip low-value words.
3. Guess the likely categories.
4. Compare the meaningful terms.
5. Score the candidate records.
6. Filter out weak matches.
7. Return only the strongest ones.

Here's what comes out for that assignment question:

Question:
When is my Network Security assignment due?

        ↓

Retriever

        ↓

ASSIGN-001
Network Infrastructure Security Assignment

Deadline:
30 September 2026

Submission:
LMS

Source:
Network Security Assignment Notice

Only then does Gemini see anything. Its job is to understand the student's wording and present the retrieved facts naturally, not to guess the campus facts itself.

When nothing should match

Testing exposed a useful failure. Someone asked for tomorrow's cafeteria menu, and the knowledge base has nothing on cafeterias. Yet the retriever still returned unrelated records, because common words like "what", "is" and "the" showed up in various documents.

The fix had several parts:

• Filter stop words.
• Require meaningful token overlap.
• Give categories more weight.
• Support multi-word keyword matches.
• Add a minimum relevance score.

After that, the same question behaves correctly:

Question:
What is tomorrow's cafeteria menu?

The retriever returns nothing:

Records found: 0

The assistant then says it can't find verified information, rather than inventing a menu. That refusal is one of the most important behaviors in the whole project.

Letting Gemini write the answer

Once records are retrieved, they go to Gemini with firm instructions. It must not invent assignment deadlines, schedules, lecturers, classrooms, fees, policies, contact details or announcements. When there's a match, the model turns it into a clear sentence. For the assignment question, the reply gives the 30 September 2026 deadline and says to hand it in via the LMS, then adds the source, which is the assignment notice. Showing the source tells the student where the answer came from.

Three languages, one knowledge base

A student can ask the library question in English, Tamil or Sinhala. The retrieved record stays in one structured format while Gemini replies in whichever language the student used. That's far more flexible than running a separate chatbot for each language.

A worked example

Suppose the library record contains these hours:

Library hours

Monday–Friday:
8:00 AM – 6:00 PMSaturday:
8:00 AM – 1:00 PMSunday:
Closed

A student asks whether the library is open on Sunday. The retriever finds the library record, and Gemini replies that it's closed on Sunday, citing the library information notice. The student never needs to know whether the answer lives in a JSON file, a timetable, a notice or a database. They just ask.

Responsible behavior built in

CampusAI is still a prototype, but safe behavior is part of the design instead of a later add-on. It follows five safeguards:

1. Campus facts must come from retrieved records, and Gemini is told not to use general knowledge for them.
2. A minimum relevance threshold rejects low-confidence matches.
3. If nothing suitable exists, the student is told verified information couldn't be found.
4. Each record keeps the institutional source used for the answer.
5. The demo holds no sensitive data, meaning no student IDs, grades, medical details, passwords, financial information or private records.

A production deployment would need authentication and access control before it touched any personal student data.

The interface

The front end is built with Streamlit and meant to feel familiar to anyone who's used a modern conversational AI product. It has a conversation area, a sidebar, suggested questions, language information, a new-chat option, a persistent input box and readable responses. The visual design stays simple on purpose. What matters isn't animation. It's whether a student can ask where to get IT support and receive the right answer quickly.

How it was tested

Several kinds of questions were tried. Known information:

What are the library opening hours?

Assignments:

When is my Network Security assignment due?

Campus services:

Where can I get IT support?

Tamil, a mixed-language question about when to submit the assignment:

Network Security assignment எப்போது submit செய்ய வேண்டும்?

Sinhala, asking where the IT support desk is:

IT support එක කොහෙද තියෙන්නේ?

And information that doesn't exist:

What is tomorrow's cafeteria menu?

The last category matters most. A useful institutional assistant should be able to say it has no verified information about something. That beats a confident, wrong answer every time.

Lessons learned

The generative model is just one piece. A useful application also needs good data, retrieval, clear boundaries, source tracking, error handling, a decent user experience and privacy awareness.

The biggest improvement didn't come from rewriting the prompt. It came from building the retrieval layer that decides what Gemini is allowed to see before it generates anything. That made behavior more predictable and gave the system a much clearer structure.

What could come next

The project is an MVP, and several directions look promising:

• Semantic retrieval. Today's approach uses category detection and relevance scoring. Larger datasets could move to embeddings and vector search.
• Document ingestion. Administrators could upload vetted files, such as PDF notices, regulations, handbooks, timetables and student guides, and the app would index them on its own.
• LMS integration. Real approved information could come straight from the LMS instead of demo JSON files.
• Student authentication. Signed-in students could see information for their own programme or level, with proper access controls.
• Administrative analytics. Institutions could learn which questions come up most and which information students struggle to find.
• Cloud deployment. The current version runs locally, but it could become a scalable web service on Google Cloud.

The idea in one line

The starting question was whether students can reach campus information more naturally without giving up reliability. Gemini supplies language understanding and multilingual generation. Pairing it with retrieval, structured data, source attribution and a willingness to refuse is what turns it into something better than a basic chatbot.

Ask naturally. Retrieve carefully. Generate from trusted information.