AI University Chatbot & International Student Assistant

I was the primary creator and project lead for a retrieval-assisted university-support application built with Python, OpenAI, Pinecone, and Gradio. I structured the knowledge, implemented embedding and retrieval logic, assembled model context, and shaped the conversational experience. I also guided a team on a related university implementation; that leadership context is separate from authorship of the core application described here.

The information problem behind the chat interface

University information is usually organized around departments and documents, while a student's question crosses those boundaries. An international student may need an admissions requirement, a course detail, a campus contact, a job resource, and a location answer during one task. Searching separate pages or asking the same administrative questions repeatedly creates friction for both students and support teams.

The product goal was to create one conversational entry point without pretending that a language model already knows the institution's facts. The system needed a prepared knowledge source, a way to find relevant passages, a method for giving those passages to the model, and a simple interface for the resulting exchange.

Preparing knowledge for retrieval

I organized confirmed university information into structured categories including academic, admissions, international-student, employment, contact, address, and campus-support topics. This preparation matters because retrieval quality begins before an embedding is created. Inconsistent names, incomplete entries, or overlapping fragments can make technically valid vector search return unhelpful context.

The implementation creates embeddings for the prepared content and uses Pinecone for vector indexing and similarity search. For a new question, the application creates a query representation, retrieves relevant knowledge, and constructs the context supplied to the OpenAI model.

This is retrieval-assisted generation rather than model training. I integrated hosted model and vector services; I did not develop or fine-tune a foundation model. The architecture diagram identifies the supported path from knowledge preparation through the Gradio response experience.

Turning retrieval into an answer

Retrieval is only one stage of the request. The orchestration layer has to load knowledge, create or query embeddings, select relevant context, construct the model input, call the model, and return an answer in a form a student can understand.

I implemented that flow in Python. The Gradio interface provides the conversational surface, while environment-variable configuration keeps provider credentials out of the source. The repository includes the application file, notebook, and supporting documentation; a current dependency and secret audit remains a prerequisite for any hosted public demo.

def get_relevant_info(index, query, metadata_type, top_k=5):
    query_embedding = get_embeddings([query])[0]
    query_result = index.query(
        vector=query_embedding,
        top_k=top_k,
        include_metadata=True,
    )
    return [match for match in query_result["matches"]
            if match["metadata"]["type"] == metadata_type]

The use cases focus on accessing institutional information, not making high-impact decisions. The assistant can help a user locate or understand available information. It should not independently decide admissions, legal-status, employment, financial, or academic outcomes.

Conversation states and failure boundaries

A useful support assistant needs more than a successful answer state. The case-study visual plan includes questions where relevant information is found, where relevance is weak, where a source is missing, where a provider call fails, and where the question should be redirected to an official human channel.

I treat those states as an evaluation framework: check retrieval relevance, source coverage, response usefulness, refusal behavior, and whether the fallback gives the user a safe next step. A formal accuracy score, adoption count, latency benchmark, and complete evaluation dataset are not available, so none is claimed.

Privacy is another system boundary. The public interactive explanation uses neutral support labels and no student records or confidential university data. A future hosted demo would need explicit policies for submitted questions, provider retention, logging, source access, and questions that require refusal or human support.

Ownership and team guidance

For the core project, I owned the product and technical path: knowledge architecture, Python application flow, embeddings, Pinecone retrieval, context construction, OpenAI integration, Gradio interaction, and supporting documentation.

Separately, I guided and managed a team working on a related university-support implementation. That involved helping translate the support problem into information categories, application tasks, and implementation decisions. The team context demonstrates leadership, but it is not used to blur who created the public repository implementation.

Evidence that can be inspected

The public repository is the strongest external evidence for this project. It supports the named stack, knowledge preparation, retrieval flow, model integration, and interface implementation. Production hosting, institutional adoption, response accuracy, and usage at scale remain outside that evidence.

Repository artifacts are presented as public source evidence after audit. The interactive explanation uses neutral sanitized scenarios, while architecture and failure-mode views remain programmatic diagrams. Those presentation choices do not change the project's maturity.

Tradeoffs and next evaluation work

Hosted model and vector services reduced the amount of infrastructure needed for the implementation and made the end-to-end flow easier to demonstrate. They also introduce dependency, cost, latency, configuration, and data-governance questions that a production deployment would need to address.

The next engineering step is a reproducible evaluation set drawn from the supported information categories. It should record expected source coverage, retrieval relevance, answer usefulness, refusal or escalation behavior, and representative failure cases. A separate knowledge-maintenance process would clarify how changes are reviewed, indexed, and verified over time.