Ein Chatbot, der höflich nichts wusste
Ein Chatbot, der höflich nichts wusste
Inhaltsverzeichnis
Das Symptom: technisch erfolgreich, inhaltlich leer
Der Chatbot auf der Startseite beantwortet Fragen zu den eigenen Diensten. Eines Tages fiel auf: Er antwortete zwar, aber inhaltlich dünn. Auf eine konkrete Frage kam sinngemäß „In der Wissensdatenbank finde ich dazu nichts – schauen Sie doch in den Blog“. Kein Fehler, kein Timeout. Die technische Antwort der Kette lautete sogar erfolgreich.
Genau diese Kombination – technisch grün, inhaltlich leer – ist tückisch. Eine abgestürzte Komponente hätte einen Alarm ausgelöst. Eine höfliche Ausweichantwort löst keinen aus. Der Chatbot funktionierte auf dem Papier tadellos und war trotzdem nutzlos.
Kurz erklärt: wie ein Wissens-Chatbot antwortet
Damit ein Sprachmodell über die eigenen Inhalte Auskunft geben kann, bekommt es die passenden Textausschnitte vor der Antwort mitgeliefert. Dieses Muster heißt RAG (Retrieval-Augmented Generation) und läuft in drei Schritten:
| Schritt | Was passiert |
|---|---|
| 1. Aufbereitung (nachts) | Alle Inhalte werden in kleine Stücke geteilt und in Zahlenvektoren übersetzt (Einbettungen), die in einer Vektordatenbank landen. |
| 2. Suche (pro Frage) | Die Frage wird ebenfalls in einen Vektor übersetzt; die Datenbank liefert die ähnlichsten Textstücke. |
| 3. Antwort | Diese Textstücke wandern als Kontext ins Sprachmodell, das daraus eine Antwort formuliert. |
Der entscheidende Punkt: Findet die Suche in Schritt 2 nichts, bekommt das Modell keinen Kontext. Es kann dann nur allgemein antworten – oder höflich auf den Blog verweisen. Genau das geschah hier.
Die Wurzel: eine leere Wissensbasis
Ein Blick in die Vektordatenbank machte es eindeutig: Die Sammlung mit dem Wissen enthielt null Einträge. Die Suche konnte gar nichts finden, weil nichts da war. Die gesamte Kette – Eingabe, Suche, Modell – funktionierte einwandfrei; sie arbeitete nur auf einem leeren Regal.
Warum war das Regal leer? Ein nächtlicher Aufbereitungslauf füllt es normalerweise aus den aktuellen Inhalten. Das Protokoll zeigte: Der letzte Lauf war mit einem Fehler abgebrochen. Und zwar an der Stelle, an der die Textstücke in Vektoren übersetzt werden – der zuständige Dienst war für ein kurzes Zeitfenster nicht erreichbar. Alle vorherigen Nächte waren grün. Diese eine Nacht nicht.
Der Konstruktionsfehler: erst löschen, dann hoffen
Der eigentliche Fehler lag nicht im kurzen Ausfall des Einbettungs-Dienstes – solche Aussetzer passieren. Der Fehler lag im Ablauf der Aufbereitung:
Das ist ein klassischer Single Point of Failure: Ein einziger misslungener Nachtlauf legt den Chatbot lahm – und weil er dabei höflich ausweicht statt abzustürzen, bleibt es unbemerkt. „Erst das Alte wegwerfen, dann das Neue bauen“ ist bequem, aber es hat keinen Rückfall. Genau das musste sich ändern.
Die Lösung: Blau/Grün mit Zeiger-Umschaltung
Die robuste Antwort kommt aus dem Deployment-Handwerk und heißt Blau/Grün. Statt einer einzigen Sammlung, die man riskant leert und neu füllt, gibt es zwei – nennen wir sie Blau und Grün. Der Chatbot liest nie direkt eine der beiden, sondern über einen Zeiger (einen Alias), der jeweils auf die aktuell gültige zeigt.
- Ins Reservefach bauen: Der Lauf befüllt immer die Sammlung, auf die der Zeiger gerade nicht zeigt. Die aktive bleibt unangetastet.
- Nur bei Erfolg umschalten: Erst wenn die neue Sammlung vollständig gefüllt ist, wird der Zeiger in einem einzigen, atomaren Schritt umgelegt.
- Fehlerfall ist harmlos: Bricht der Lauf vorher ab, bleibt der Zeiger auf der alten, vollständigen Sammlung. Der Chatbot merkt nichts.
Das Ergebnis ist ein Umschalten ohne Lücke. Es gibt keinen Moment, in dem die Wissensbasis leer ist – im Erfolgsfall zeigt der Zeiger auf frische Inhalte, im Fehlerfall auf die letzten guten. Die vorige Sammlung bleibt zudem als Rückfallebene erhalten. Aus einem „erst löschen, dann hoffen“ wird ein „erst bauen, dann umschalten“.
Zwei Nebenfunde: Wächter und ein Datei-Limit
Beim Umbau kamen zwei Dinge ans Licht, die eigene Erwähnung verdienen.
Erstens ein blinder Fleck beim Alarmieren. Der ursprüngliche Ausfall blieb nur deshalb tagelang möglich, weil niemand ihn meldete. Blau/Grün hält den Chatbot zwar am Leben, aber ein dauerhaft scheiternder Nachtlauf würde die Inhalte still veralten lassen. Deshalb gibt es jetzt einen kleinen Wächter: Er prüft nach dem Nachtlauf, ob die aktive Sammlung gefüllt ist und ob überhaupt kürzlich erfolgreich aufbereitet wurde – und meldet sich über einen vom Rest unabhängigen Kanal, falls nicht. Ein Selbstheilungs-Mechanismus, der niemanden informiert, ist nur die halbe Miete.
Lessons Learned
- „Technisch erfolgreich“ heißt nicht „inhaltlich richtig“. Eine höfliche Ausweichantwort löst keinen Alarm aus und kann einen Ausfall lange verdecken.
- Bei einem Wissens-Chatbot ist die leere Wissensbasis eine der ersten Verdächtigen, wenn Antworten plötzlich substanzlos werden – nicht das Sprachmodell selbst.
- „Erst löschen, dann neu aufbauen“ hat keinen Rückfall. Ein einziger misslungener Lauf reißt alles mit. Besser: ins Reservefach bauen und erst bei Erfolg umschalten.
- Blau/Grün mit einem Zeiger (Alias) macht das Umschalten atomar und ohne Lücke – und liefert die vorige Version gratis als Rückfallebene mit.
- Ein Selbstheilungs-Mechanismus braucht einen Wächter, der Dauerfehler meldet. Sonst veraltet still, was nicht mehr abstürzt.
- Tief liegende Standardwerte – etwa Datei-Limits – können einen korrekten Umbau blockieren. Im Zweifel gehört das Limit zur Lösung dazu.
Der Chatbot war nie kaputt – er war nur höflich ahnungslos. Die eigentliche Arbeit lag nicht darin, ihn wieder zum Reden zu bringen, sondern dafür zu sorgen, dass ihm nie wieder unbemerkt das Wissen abhandenkommt. „Erst bauen, dann umschalten“ ist dafür das ganze Geheimnis.