Der MMK Chatbot beantwortet Fragen von Studierenden der Digitalen Medien an der DHBW Mannheim aus den offiziellen Unterlagen des Studiengangs und verlinkt zu jeder Antwort die Quelle. Technisch ist er ein RAG-System mit hybrider Suche über 588 Dokumente und Seiten. Ich habe ihn als Praxisteil meiner Bachelorarbeit und als Hiwi-Projekt für den Studiengang gebaut.
Warum ein Chatbot für den Studiengang?
Wer an der DHBW Mannheim Digitale Medien mit Schwerpunkt Medienmanagement und Kommunikation (MMK) studiert, hat ständig organisatorische Fragen: Bis wann muss eine Krankmeldung vorliegen? Wie trete ich von einer Prüfung zurück? Wie beantrage ich eine Freistellung? Was gilt formal für die Bachelorarbeit? Wann liegt die nächste Praxisphase? Die Antworten stehen in Studien- und Prüfungsordnungen, Phasenplänen, Leitfäden und auf Dutzenden Webseiten. Wer sie nicht findet, schreibt dem Sekretariat.
Der MMK Chatbot nimmt Studierenden diese Suche ab. Man stellt die Frage in eigenen Worten und bekommt eine Antwort in ganzen Sätzen, samt Link auf das Dokument, in dem es steht. Zwei Dinge macht er bewusst nicht: Er gibt keine verbindliche Rechtsauskunft und verweist in solchen Fällen an das Studiengangssekretariat, und er ist kein Gesprächspartner für private Themen.
Was ist ein RAG-System?
RAG steht für Retrieval-Augmented Generation. Ein RAG-System beantwortet eine Frage in zwei Schritten: Zuerst sucht es in einer eigenen Wissensbasis die Textstellen, die zur Frage passen. Danach formuliert ein Sprachmodell die Antwort ausschließlich auf Grundlage dieser Stellen und nennt die Quellen. So bleiben die Antworten aktuell und nachprüfbar, und das Modell muss nichts aus dem Gedächtnis erfinden. Für einen Studiengang mit vielen Ordnungen und Fristen ist das der entscheidende Vorteil gegenüber einer allgemeinen KI.
-
Frage
Wann muss ich in den Betrieb?
Glossar in den Betrieb Phasenplanung -
hybride Suche
Semantisch, EmbeddingsLexikalisch, BM25RRFeine gemeinsame Rangliste
-
Kontext
6 12 20Abschnitte je Antwortmodus
-
Antwort, gestreamt
Phasenplanung MMK23, PDF
So funktioniert der MMK Chatbot
Die Wissensbasis
Grundlage ist ein Rohkorpus aus mehreren tausend gecrawlten Webseiten und PDFs der DHBW. Daraus habe ich über eine explizite Entscheidungsliste pro Datei, ergänzt um Regeln, einen fokussierten Bestand gefiltert: Bachelor, Fakultät Wirtschaft, Schwerpunkt MMK. Den gleichnamig abgekürzten Masterstudiengang habe ich bewusst ausgeschlossen, weil er zu vermischten und damit falschen Antworten geführt hat.
Heute umfasst die Wissensbasis 588 Dokumente und Seiten, aufgeteilt in 5.317 Abschnitte. Von 575 Quell-Links sind 571 geprüft erreichbar, dadurch führt praktisch jede Quellenangabe auch wirklich zum Original.
Rohkorpus
mehrere tausend Seiten und PDFs
Filter, Datei für Datei
- ✓Bachelor
- ✓Fakultät Wirtschaft
- ✓Studienrichtung MMK
- ✕
Master MMK
Wissensbasis
588Dokumente und Seiten
5.317Abschnitte
571 von 575Quelllinks als erreichbar geprüft
Aufbereitung der Texte
Die Dokumente werden in Abschnitte von 320 Wörtern mit 60 Wörtern Überlappung zerlegt. Jeder Abschnitt bekommt zusätzlich einen generierten Kontextsatz und fünf bis zehn Schlagworte. Dazu kommt ein Glossar, das die Sprache der Studierenden in das Vokabular der DHBW übersetzt. Die Frage „Wann muss ich im Betrieb sein?“ findet so die Phasenplanung, obwohl das Wort Phasenplanung in der Frage gar nicht vorkommt.
-
Abschnitt 1 · 320 Wörter
Kontextsatz
-
Abschnitt 2 · 320 Wörter
Kontextsatz
-
Abschnitt 3 · 320 Wörter
Kontextsatz
Hybride Suche
Die Suche läuft in Qdrant und kombiniert zwei Verfahren: eine semantische Suche über Embeddings, die Bedeutungen findet, und eine lexikalische Suche mit BM25, die exakte Fachbegriffe findet. Beide Ergebnislisten werden mit Reciprocal Rank Fusion zusammengeführt. Je nach Antwortmodus gehen 6, 12 oder 20 Abschnitte an das Sprachmodell.
Die Antwort
Das Sprachmodell läuft über ein Gateway in Rechenzentren in der EU. Die Antwort wird per Server-Sent Events Wort für Wort in die Oberfläche gestreamt, die Quellen erscheinen, sobald die Antwort fertig ist. Das Backend selbst ist mit FastAPI gebaut und speichert nichts.
Oberfläche, Anmeldung und Feedback
Die Oberfläche ist eine eigene Next.js-Anwendung. Fertige Open-Source-Chatoberflächen habe ich geprüft und mich dann für eine eigene Oberfläche entschieden, die genau auf Quellenanzeige, Anmeldung und Feedback zugeschnitten ist.
Jede und jeder Studierende bekommt ein eigenes Konto auf Basis der anonymen S-Adresse der DHBW. Es gibt keine Selbstregistrierung, beim ersten Login ist ein neues Passwort Pflicht. Die Konten und der gespeicherte Chatverlauf liegen in PocketBase. Über Daumen hoch und runter lässt sich jede Antwort bewerten. Bevor ein Gesprächsverlauf als Feedback gespeichert wird, entfernt schon der Browser E-Mail-Adressen, IBANs, Telefonnummern und lange Ziffernfolgen.
Wie gut findet das System die richtige Stelle?
Ein RAG-System ist nur so gut wie seine Suche. Findet sie die richtige Textstelle nicht, kann auch das beste Sprachmodell nicht korrekt antworten. Deshalb messe ich die Suche mit einem eigenen Goldset aus 40 handgeschriebenen Fragen in drei Gruppen: umgangssprachlich umschriebene Fragen, wörtliche Fachbegriffe und Fragen auf Englisch.
Die wichtigste Kennzahl ist Recall@12: der Anteil der Fragen, bei denen das richtige Dokument unter den ersten zwölf Treffern ist. Nach der Überarbeitung der Suche im Juli 2026 sahen die Werte so aus:
| Messung | Vorher | Nachher |
|---|---|---|
| Recall@12, umschriebene Fragen | 0,45 | 0,50 |
| Recall@12, wörtliche Fachbegriffe | 0,80 | 0,933 |
| Recall@12, gesamt | 0,625 | 0,70 |
| MRR | 0,406 | 0,455 |
| nDCG@12 | 0,613 | 0,718 |
Nach dem Umzug auf neue Modelle für Antworten und Embeddings im September 2026 erreichte dasselbe Goldset einen Recall@12 von 0,825 und einen MRR von 0,516, bei umschriebenen Fragen einen Recall von 0,65. Die alte Konfiguration wurde in diesem Lauf nicht erneut gemessen, der Vergleich ist daher eine Tendenz und keine exakte Gegenüberstellung.
- Recall@12, umschriebene Fragen
- 0,45 0,50 Sept. 0,65
- Recall@12, wörtliche Fachbegriffe
- 0,80 0,933
- Recall@12, gesamt
- 0,625 0,70 Sept. 0,825
- MRR
- 0,406 0,455 Sept. 0,516
- nDCG@12
- 0,613 0,718
Was nicht funktioniert hat
Die lehrreichste Erkenntnis des Projekts: Eine bekannte Empfehlung war für diesen Korpus falsch. Anthropic beschreibt mit Contextual Retrieval ein Verfahren, bei dem jeder Abschnitt einen generierten Kontextsatz bekommt, der sowohl in den semantischen als auch in den lexikalischen Index wandert. Anthropic berichtet von deutlich weniger fehlgeschlagenen Suchen.
Im MMK Chatbot habe ich das direkt gemessen. Im semantischen Index hat der Kontextsatz den Recall bei umschriebenen Fragen verschlechtert, von 0,45 auf 0,40, während er bei Fachbegriffen und englischen Fragen half. Der Grund liegt im Material: Hochschulunterlagen bestehen zu einem großen Teil aus fast identischen Verwaltungstexten. Ein Kontextsatz pro Abschnitt beschreibt dort am Ende immer das ganze Dokument und macht die Abschnitte einander ähnlicher statt unterscheidbarer. Die Lösung: Der Kontextsatz bleibt nur im lexikalischen Index.
umschriebene Fragen, Recall@12
wohin der Kontextsatz kommt
- Semantischer Index aus
- Lexikalischer Index, BM25 an
hilft: Fachbegriffe hilft: englische Fragen
Auch andere Ideen haben nicht getragen. Dateinamen durchsuchbar zu machen, hat den Recall nicht verbessert. Ein JSON-Format für die generierten Schlagworte ist an nicht maskierten Anführungszeichen zerbrochen. Und ein zu knapp gesetztes Token-Limit hat Modelle mit Denkphase stillschweigend abgeschnitten. Die allgemeine Lehre: Empfehlungen sind Hypothesen, entschieden wird mit Messungen am eigenen Korpus.
Datenschutz ohne eigene Hardware
Der Prototyp meiner Bachelorarbeit war hybrid aufgebaut: Ein Router prüfte jede Frage mit Microsoft Presidio auf personenbezogene Daten und schickte sensible Fragen an ein lokales Modell mit Ollama, der Rest ging an ein Cloud-Modell. Für den produktiven Betrieb habe ich diesen Pfad bewusst entfernt. Die Inhalte der Wissensbasis sind überwiegend öffentlich, günstige Modelle in EU-Rechenzentren lösen die Datenschutzfrage ausreichend, und eigene Hardware hätte keine Kostenvorteile gebracht.
Betrieben wird der Chatbot auf einem Server mit Coolify, was Deployments und den Dauerbetrieb einfach hält. Eine Verwaltungsoberfläche für Konten gibt es absichtlich nicht: Neue Jahrgänge werden per Skript aus einer Liste von S-Adressen importiert. Für den Zweck wäre mehr überdimensioniert.
Bezug zur Bachelorarbeit
Der MMK Chatbot ist das praktische Artefakt meiner Bachelorarbeit an der DHBW Mannheim zu einer hybriden, datenschutzkonformen RAG-Architektur für öffentliche Hochschulen. Die Abweichungen zwischen Prototyp und Produktion, vor allem der Verzicht auf das lokale Modell, sind dabei selbst ein Ergebnis: Sie zeigen, welche Architektur sich für öffentliche Inhalte im Hochschulalltag tatsächlich bewährt.
Status und Zugang
Die Anwendung ist live unter app.mmk-chatbot.com, die Infoseite unter mmk-chatbot.com. Nutzen können ihn Studierende der Studienrichtung MMK mit ihrer S-Adresse. Du arbeitest an einem ähnlichen System für eine Hochschule oder eine Organisation mit vielen Dokumenten? Schreib mir an kontakt@bitzer-fabian.de.