RAG-Chatbot in der Praxis: Antworten mit prüfbaren Quellen
Der KI-Assistent auf dieser Website darf nur über meine Arbeit, Angebote und Systeme sprechen. Dafür braucht er mehr als einen langen Systemprompt. Preise ändern sich, Inhalte haben verschiedene Sprachen und manche Fragen liegen außerhalb des veröffentlichten Wissens. Der Assistent muss diese Grenzen erkennen und sichtbar machen.
Dieser Artikel ist die technische Fallstudie zum laufenden System. Die grundlegende Unterscheidung zwischen festen Abläufen und autonomen Agenten erkläre ich separat in Agentische Workflows: So baust du verlässliche KI-Abläufe. Hier geht es um die konkrete Pipeline hinter dem Chat.
1. Wissen als kleine, prüfbare Einträge
Die Wissensbasis besteht aus Markdown-Dateien. Jeder Eintrag behandelt einen begrenzten Sachverhalt und besitzt eine stabile ID, einen Titel, eine Kategorie, eine Sprache und ausgewählte Suchbegriffe. Preise, Kontaktwege und Leistungsgrenzen liegen dadurch nicht lose in einem Prompt.
Vor dem Laden prüft ein Schema die Pflichtfelder. Unbekannte Verknüpfungen zwischen Einträgen führen zu einem Fehler, statt später eine leere Quelle zu erzeugen. Diese Strenge kostet beim Schreiben ein paar Minuten und spart unklare Antworten im Betrieb.
Ich habe mich bewusst gegen einen ungefilterten Dokumentenordner entschieden. Je kleiner der relevante Wissensausschnitt ist, desto leichter lässt sich nachvollziehen, warum eine Antwort entstanden ist.
2. Retrieval mit sichtbarem Match-Status
Für jede Frage sucht der Server passende Einträge. Suchbegriffe, Synonyme, Titel und Inhalt fließen mit unterschiedlichen Gewichten ein. Das Ergebnis enthält neben den Treffern einen Match-Status. Liegt kein ausreichender Treffer vor, bekommt das Modell diese Information ausdrücklich.
Das verändert die Antwortlogik. Eine Wissenslücke wird nicht als Einladung zum Raten behandelt. Der Assistent sagt, dass er die Antwort nicht verlässlich kennt, und verweist auf den Kontaktweg. Gleichzeitig protokolliert das System das fehlende Thema ohne die Antwort mit einem internen Marker zu verschmutzen.
So wächst die Wissensbasis aus echten Fragen. Ich ergänze einen Eintrag, wenn dieselbe relevante Lücke wiederholt auftaucht. Inhalte entstehen dann aus Bedarf und nicht aus einer geratenen Liste möglicher Nutzerfragen.
3. Modellzugriff hinter einer festen Schnittstelle
Die Anwendung trennt Retrieval und Promptaufbau vom Modellanbieter. Der ausgewählte Wissensausschnitt und dieselben Verhaltensregeln können dadurch an unterschiedliche Provider übergeben werden. Ein Fallback bleibt eine kontrollierte Serverentscheidung und keine spontane Wahl des Modells.
Das folgt einem einfachen Architekturprinzip: Geschäftsregeln bleiben im eigenen Code. Das Modell formuliert die Antwort, aber es entscheidet weder über gültige Preise noch über die Existenz einer Quelle. Mehr zu dieser Trennung steht in KI-Systemarchitektur: Erst Schnittstellen, dann Modelle.
4. Quellenprüfung während des Streams
Die Antwort wird als Server-Sent Events, also als fortlaufender Ereignisstrom, an den Browser gesendet. Das Modell kann Quellen in einem festgelegten Markerformat nennen. Eine deterministische Prüfstelle hält unvollständige Marker kurz zurück und vergleicht ihre ID mit den Wissenseinträgen, die für diese Anfrage tatsächlich verfügbar waren.
Eine erfundene Quellen-ID wird entfernt, bevor sie die Oberfläche erreicht. Gültige Quellen erscheinen als auflösbare Links. Damit löst das System Halluzinationen nicht grundsätzlich. Es verhindert aber, dass eine frei erfundene Referenz wie ein Beleg aussieht.
Diese Grenze ist mir wichtig. Ein zweites Modell als Faktenprüfer würde wieder eine Wahrscheinlichkeitsentscheidung treffen. Der ID-Abgleich ist normale Programmlogik und liefert für denselben Eingang dasselbe Ergebnis.
5. Sicherheit vor Komfort
Eingaben werden begrenzt und validiert, bevor die Agenten-Sitzung startet. Das Modell erhält keine Werkzeuge zum Lesen beliebiger Dateien oder zum Ausführen von Code. Versuche, interne Anweisungen oder Geheimnisse abzufragen, liegen außerhalb des erlaubten Verhaltens.
Eine solche Regel im Prompt allein wäre zu schwach. Deshalb liegen Größenlimits, Sitzungsprüfung, Providerwahl und Quellen-Gate im Servercode. Der Prompt erklärt die Rolle. Der Code setzt die technischen Grenzen.
OpenAI ordnet Guardrails in seinem Leitfaden zum Bau von Agenten als eigene Architekturschicht ein. Das NIST Generative AI Profile ergänzt den Blick auf Tests und Risikomanagement über den Lebenszyklus. Für diesen Assistenten werden daraus konkrete Testfälle: Prompt Injection, Wissenslücke, falsche Quellen-ID, ungültige Eingabe und nicht erreichbarer Provider.
Was das System bewusst nicht kann
Der Assistent greift nicht auf mein gesamtes privates Projektwissen zu. Er kann keine Verfügbarkeit versprechen, keine neuen Preise erfinden und keine Verträge abschließen. Wenn eine Information nicht veröffentlicht ist, bleibt sie außerhalb der Antwort.
Auch Retrieval garantiert keine Wahrheit. Ein sauber gefundener Eintrag kann veraltet sein. Deshalb braucht jeder geschäftskritische Fakt eine gepflegte Quelle und einen verantwortlichen Menschen. Technik kann den Weg einer Aussage sichtbar machen. Die inhaltliche Verantwortung nimmt sie niemandem ab.
Warum ich diesen Aufbau zeige
Aktuell gibt es auf dieser Website keine erfundenen KI-Kundencases. Meine eigenen Systeme sind deshalb der offenste Einblick in meine Arbeit. Der Chatbot zeigt, wie ich Wissen, Datenschutz, Provider und Nutzeroberfläche in einem laufenden Produkt verbinde. Die Grenzen gehören zu diesem Einblick dazu.
Wer den Assistenten testen möchte, kann direkt mit Kirks KI-Assistenten sprechen. Für einen eigenen Wissensassistenten oder einen begrenzten Automatisierungs-Pilot führt der nächste Schritt über das KI-Potenzial-Audit.
Über den Autor
Ich bin Kirk Kleinau, AI Strategist und Creative Technologist sowie IHK-geprüfter KI-Manager. Den Assistenten, die Wissensstruktur und die Website entwickle ich als zusammenhängendes System. Meine Grundlage sind acht Jahre Arbeit in Design, Konzeption, Projektleitung, Web und Frontend.