Overview

The University of Haripur wanted an assistant that could answer student and staff questions about its own material — prospectuses, policies, notices, academic documents — without a person having to answer the same question a hundred times a week. The requirement that shaped everything was that it must answer from the documents, and be able to say where an answer came from.

The result is a retrieval-augmented service built as an API rather than a chat app. Documents are uploaded, split, embedded and indexed; a question retrieves the passages that actually bear on it and a language model composes the answer from those passages alone, carrying the source reference back with it. Around that sits the part that makes it operable: eighteen endpoints for managing the corpus, an admin key on every mutation, a request limiter, and — unusually — the ability to list, edit and delete an individual chunk, so a bad passage can be corrected without re-ingesting the whole document.

It was built in a one-week window in February 2025, with a co-developer, at the request of the university.

Problem

A retrieval assistant over institutional documents has three problems that a demo never surfaces.

The answer has to be traceable. A student told the wrong fee deadline by a confident chatbot is a real institutional problem. It is not enough for the model to be grounded — the answer has to carry the reference back with it, which means the reference has to survive the whole pipeline: the chunk has to remember which document and which section it came from, and that memory has to still be there at generation time.

A vector store alone is not enough to run this. Embeddings are excellent at finding relevant text and useless at answering the operational questions an administrator actually has — what has been uploaded, when, how many chunks did it produce, has this file already been ingested. Those are relational questions. Using one store for both jobs means doing at least one of them badly.

Corpora go stale, and re-ingesting is a blunt instrument. A single wrong or outdated paragraph in a long prospectus should not require deleting and rebuilding the entire document's index — but chunk-level surgery is exactly the thing a naive RAG pipeline makes impossible, because it treats the index as write-once.