ChatGJU

The core architectural decision was a strict separation between the brain and the faces. A Python FastAPI backend (apps/retriever) exposes three endpoints: a health check, a retrieve-only endpoint for vector search, and a chat endpoint that runs the full RAG pipeline.

Every chat interface, the Next.js web app today, and the WhatsApp bot and mobile app planned next, talks to that single API with a standard messages payload. Adding a new surface means building a thin client, not a new brain.

The web frontend is a clean Next.js and TypeScript chat interface with conversation history, streaming-style typing states, and source metadata returned alongside each answer.

Questions go through a full pipeline before the language model ever sees them:

Detect the question's language, embed it with Cohere's embed v4.0 model at 3,072 dimensions, search the Zilliz (Milvus) vector database for the top candidate chunks, then re-rank using source-type boost weights and cut off anything below a minimum confidence score.

On top of that sit two retrieval refinements I'm particularly happy with: a heuristic that detects list-style questions like "list all engineering programs" and widens the search for better coverage, and a query-intent service that infers structured department filters from natural language, so a question about the CS department only searches CS-tagged content.

A university chatbot that invents deadlines or office locations is worse than no chatbot. The system prompt enforces strict grounding rules: answer only from the retrieved knowledge base excerpt, never invent numbers, dates, emails, or links, and say when the knowledge base doesn't contain the answer.

Off-topic questions get politely redirected to university topics, and retrieved chunks carry rich metadata (title, domain, source type) into the prompt so the model can be precise about what it cites.

We also built an evaluation tool that runs question sets against the pipeline, so prompt and retrieval changes are measured instead of guessed at.

A scraper crawls gju.edu.jo into structured CSV, and separate ingestion scripts load both the scraped content and hand-curated Q&A into the vector database with consistent tagging. Keeping ingestion separate from scraping let us rebuild the index without re-crawling.

As team lead I coordinated tasks across four people, reviewed all integration work, and owned the architecture end to end. That meant writing clear interface contracts early (the API shape never changed mid-semester), and making sure the backend, frontend, and data workstreams came together instead of drifting apart.