ChatGJU

Die zentrale Architekturentscheidung war eine strikte Trennung zwischen dem Gehirn und den Gesichtern. Ein Python-FastAPI-Backend (apps/retriever) stellt drei Endpunkte bereit: einen Health-Check, einen Retrieve-only-Endpunkt für die Vektorsuche und einen Chat-Endpunkt, der die komplette RAG-Pipeline ausführt.

Jede Chat-Oberfläche, heute die Next.js-Web-App, später der geplante WhatsApp-Bot und die mobile App, kommuniziert mit dieser einen API über ein standardisiertes Messages-Payload. Eine neue Oberfläche hinzuzufügen bedeutet, einen dünnen Client zu bauen, nicht ein neues Gehirn.

Das Web-Frontend ist eine aufgeräumte Chat-Oberfläche mit Next.js und TypeScript, inklusive Konversationsverlauf, Streaming-typischen Tippzuständen und Quellen-Metadaten neben jeder Antwort.

Fragen durchlaufen eine komplette Pipeline, bevor das Sprachmodell sie überhaupt zu Gesicht bekommt:

Erkennen der Sprache der Frage, Einbetten mit Coheres Embed-Modell v4.0 in 3.072 Dimensionen, Suche in der Zilliz-(Milvus-)Vektordatenbank nach den besten Kandidaten-Chunks, dann Re-Ranking anhand von Gewichten nach Quelltyp und Abschneiden aller Chunks unterhalb eines Mindest-Konfidenzwerts.

Darauf sitzen zwei Retrieval-Verfeinerungen, auf die ich besonders stolz bin: eine Heuristik, die Listen-Fragen wie „liste alle Studiengänge der Ingenieurwissenschaften“ erkennt und die Suche für bessere Abdeckung verbreitert, und ein Query-Intent-Dienst, der aus natürlicher Sprache strukturierte Fachbereichs-Filter ableitet, sodass eine Frage zum Informatik-Fachbereich nur in Informatik-Inhalten sucht.

Ein Universitäts-Chatbot, der Fristen oder Bürostandorte erfindet, ist schlechter als gar kein Chatbot. Der System-Prompt erzwingt strenge Grounding-Regeln: ausschließlich aus dem abgerufenen Wissensbasis-Auszug antworten, niemals Zahlen, Daten, E-Mails oder Links erfinden und sagen, wenn die Wissensbasis die Antwort nicht enthält.

Off-Topic-Fragen werden höflich zu Universitätsthemen umgeleitet, und abgerufene Chunks tragen reichhaltige Metadaten (Titel, Domain, Quelltyp) in den Prompt, damit das Modell präzise sagen kann, was es zitiert.

Außerdem haben wir ein Evaluierungstool gebaut, das Fragensets gegen die Pipeline laufen lässt, sodass Prompt- und Retrieval-Änderungen gemessen statt erraten werden.

Ein Crawler zieht gju.edu.jo in strukturiertes CSV, und separate Ingestion-Skripte laden sowohl die gescrapten Inhalte als auch die handkuratierten Fragen und Antworten mit konsistentem Tagging in die Vektordatenbank. Ingestion vom Scraping zu trennen ermöglichte es uns, den Index neu zu bauen, ohne neu crawlen zu müssen.

Als Teamleiter habe ich Aufgaben über vier Personen koordiniert, alle Integrationsarbeit überprüft und die Architektur von Anfang bis Ende verantwortet. Das bedeutete, früh klare Interface-Verträge zu schreiben (die API-Form hat sich mitten im Semester nie geändert) und sicherzustellen, dass Backend-, Frontend- und Daten-Workflows zusammenkommen statt auseinanderzudriften.