Chatbot-Testen heißt, KI-gestützte Chat-Systeme jenseits von bestanden oder nicht bestanden zu prüfen: Stimmen die Antworten, holt der Abruf die richtigen Inhalte, bleiben Halluzinationen aus, hält der Bot den Kontext über mehrere Gesprächsrunden? Weil dieselbe Eingabe viele gültige Antworten erzeugen kann, reicht der Blick auf die letzte Antwort nicht. Testerinnen und Tester müssen die ganze RAG-Pipeline untersuchen, von Chunks und Vektor-Embeddings über Prompts bis zur Fallback-Logik.
Das Wichtigste in Kürze
- Chatbot-Fehler sind im klassischen Sinn unsichtbar: Sie stecken nicht nur im Code, sondern auch im Prompt, in der Abruflogik und in der Antwortgenerierung. Das Debugging braucht deshalb einen ganz anderen Ansatz.
- Chatbots antworten nicht deterministisch. Auf dieselbe Eingabe gibt es mehrere gültige Antworten, das klassische Bestanden-oder-nicht-bestanden-Modell greift nicht mehr, und was als korrektes Testergebnis zählt, muss breiter gefasst werden.
- Die Protokollierung muss Chunks, Abrufergebnisse und Abfragen umfassen, nicht nur die fertige Antwort. Ohne dieses vollständige Protokoll lässt sich kaum klären, warum eine Antwort falsch war.
- Das CHAT-Framework ordnet Chatbot-Tests nach vier Themen: Kontext halten, Halluzinationen kontrollieren, Genauigkeit und Relevanz sowie ein Testablauf aus Nachverfolgen, Beheben und erneutem Testen mit ähnlichen Abfragen.
- Ein Stresstest prüft beim Chatbot nicht die Leistung unter Last, sondern die Antworten auf Rechtschreibfehler, mehrdeutige Begriffe und schlechte Formulierungen, wie sie frustrierte Nutzer tippen.
Warum Chatbot-Testen mit klassischer Testlogik schiefgeht
Beim Chatbot-Testen zerbricht das Paar, auf dem klassisches Testen ruht: eine Eingabe, ein erwartetes Ergebnis, bestanden oder nicht bestanden. Auf dieselbe Frage kann ein Chatbot viele verschiedene Antworten geben, und mehrere davon können gleichzeitig richtig sein.
Der Kern des Problems ist der fehlende Determinismus. Der klassische Testentwurf geht von genau einem gültigen Fall aus und behandelt alles andere als Negativszenario. Ein Chatbot liefert dagegen eine ganze Bandbreite brauchbarer Antworten. Manche ähneln sich, manche sind anders formuliert, und alle können stimmen.
Damit ändert sich deine Aufgabe als Tester. Du bestätigst nicht mehr die eine richtige Antwort. Du beurteilst, ob eine Antwort korrekt, relevant und beim Thema ist, oft bei Fragen, deren richtige Antwort du selbst gar nicht kennst.
Was unter der Frage liegt
Das Verhalten eines Chatbots entsteht in Schichten, die im Chatfenster nie sichtbar werden. Hinter jeder Frage stehen Chunks, Abfragen, Prompts und Abruflogik, und jede dieser Schichten lässt sich testen.
Die meisten Chatbots bauen auf einem RAG-System auf (Retrieval-Augmented Generation). Die Antwort ist also nur die halbe Geschichte. Was das System abruft, bevor es antwortet, zählt genauso viel, und die Abruflogik braucht eigene Tests, nicht nur der fertige Text.
Dusanka Lecic ist diese Arbeit zunächst manuell angegangen, weil das Terrain für sie neu war. Sie hat es in kleine Teile zerlegt und sich zuerst eine schlichte Frage gestellt: Was will ich eigentlich von diesem Chatbot? Genauigkeit, Korrektheit, Relevanz und Antworten, bei denen sich der Nutzer nicht wiederholen muss.
Früh rückte das Chunking in den Fokus. Wie entstehen die Chunks, manuell oder automatisch, und taugen sie etwas? Semantische Grenzen, Top-k-Scores, Vektor-Embeddings und die Wahl der Vektordatenbank wurden von fremden Begriffen zu konkreten Testgegenständen.
Erst der Mensch, dann die Technik
Eine brauchbare Teststrategie beginnt bei dem, was ein Mensch von dem Gespräch will, nicht bei der Architektur. Die Grundanforderung ist schlicht: Der Nutzer soll sich nicht ärgern und nicht wiederholen müssen, was er schon gesagt hat.
Daraus folgen die technischen Fragen. Wie baust du Negativszenarien für ein System, das viele gültige Antworten kennt? Wie testest du Vektor-Embeddings, und wann sind sie gut genug? Solche Fragen ergeben erst Sinn, wenn klar ist, wie eine gute Antwort aus Sicht eines Menschen aussieht.
Das CHAT-Framework: Struktur für Chatbot-Tests
Dusanka hat ihre Tests an einem schlanken Leitfaden ausgerichtet, den sie CHAT nennt. Jeder Buchstabe steht für einen Bereich, den die Tests abdecken müssen. Das ist weniger ein starres Framework als eine Orientierung dafür, worauf es ankommt.
| Buchstabe | Fokus | Was dazugehört |
|---|---|---|
| C | Context Retention (Kontext halten) | Den Kontext über mehrere Gesprächsrunden bewahren, damit sich der Nutzer nicht wiederholen muss |
| H | Hallucination Control (Halluzinationen kontrollieren) | Erfundene Fakten und irreführende Antworten verhindern |
| A | Accuracy and Relevance (Genauigkeit und Relevanz) | Korrekte Antworten, die tatsächlich auf die gestellte Frage eingehen |
| T | Testing Workflow (Testablauf) | Nachverfolgen, beheben und mit denselben oder ähnlichen Abfragen erneut testen |
Beim Kontext geht es um mehr als den Inhalt. In einem Gespräch über mehrere Runden muss sich der Bot merken, was vorher gesagt wurde. Kontext und Inhalt gehören deshalb in denselben Test.
Der Testablauf schließt den Kreis. Du verfolgst nach, was passiert ist, behebst den Fehler und testest dann erneut mit Abfragen, die denen ähneln, die das Problem zuerst gezeigt haben. Erst dieser Nachtest mit ähnlichen Abfragen zeigt, dass die Korrektur hält.
Was ein Stresstest bei einem Chatbot bedeutet
Mit Performance oder Last hat der Stresstest hier nichts zu tun. Bei einem Chatbot heißt Stresstest: Du fütterst ihn mit den unordentlichen Eingaben echter Nutzer, mit Rechtschreibfehlern, mehrdeutigen Begriffen, Tippfehlern und schiefen Formulierungen, gerade mit denen, die in Momenten des Frusts entstehen.
Du willst sehen, wie der Bot mit einer schlecht gestellten Frage zurechtkommt. Echte Nutzer tippen keine sauberen Prompts, und ein Chatbot, der nur mit ordentlicher Eingabe klarkommt, ist für sie nicht bereit.
Warum Chatbot-Fehler unsichtbar sind
Ein Chatbot-Bug ist meist kein Defekt im Code. Genau das macht ihn schwerer zu fassen als einen klassischen Bug, den du reproduzierst, debuggst, als Ticket anlegst und mit einem Screenshot belegst.
Der Fehler kann an mehreren Stellen stecken. Vielleicht liegt er darin, wie Informationen aus der Datenbank abgerufen werden. Vielleicht liegt er im Prompt selbst, wenn ein schlecht aufgebauter Prompt ein schlechtes Ergebnis erzeugt. Oder er entsteht erst bei der Generierung der Antwort.
Weil die Ursache im Abruf, im Prompt oder in der Generierung liegen kann, darfst du nicht einfach annehmen, dass der Code schuld ist, und dort mit dem Debugging anfangen. Zuerst musst du herausfinden, welche Schicht das falsche Verhalten erzeugt hat.
Wie Protokollierung unsichtbare Fehler behebbar macht
Erst die Protokollierung macht aus einem unsichtbaren Chatbot-Fehler etwas, das du beheben kannst. Abfrage und Antwort zu protokollieren reicht nicht. Du protokollierst auch die abgerufenen Chunks, damit du siehst, warum ein bestimmter Chunk zurückkam und wie der Abruf abgelaufen ist.
“Bugs sind, würde ich sagen, unsichtbar. Warum unsichtbar? Weil sie nicht im Code stecken.”
(Dusanka Lecic)
Manche Fehler lassen sich leicht beheben, andere nicht. Wenn es nicht einfach geht, musst du das Modell vielleicht neu trainieren, es aktualisieren oder deine Strategie für eine ganze Klasse von Situationen überarbeiten. Ohne detaillierte Protokolle bleibt dir nur Raten.
Nicht jeder Fehler lässt sich verhindern, und das ist in Ordnung. Wenn du alles getan hast, um einen Fehler zu vermeiden, und er trotzdem auftritt, nimm ihn als Lektion und richte das System darauf ein. Eine Fallback-Logik sorgt dafür, dass der Bot kontrolliert zurückfährt, statt hart auszufallen.
Ein praktischer Fallback: Der Bot fragt zurück. Statt bei einer mehrdeutigen Frage zu raten, fragt er den Nutzer, ob er das eine oder das andere gemeint hat, und bittet um mehr Erklärung. Nutzerfeedback und protokollierte Fehler fließen dann ins Nachtrainieren ein und verbessern das Modell mit der Zeit.
Manuell und automatisiert kombinieren
Beim Chatbot-Testen musst du dich nicht zwischen manuell und automatisiert entscheiden, du kombinierst beides. Manuell verstehst du, was unter den Fragen, Abfragen, Antworten und Abrufen passiert. Das ist gründlich, und es ist langsam.
Die Automatisierung macht den Rest beherrschbar. Sie trägt die wiederkehrende Last und hält den Aufwand tragbar, denn jede Schicht von Hand zu untersuchen, skaliert nicht.
Bei der Dokumentation zeigt sich dieselbe Verschiebung wie beim Testentwurf. Viele gültige Szenarien und mehr Positivtestfälle als in einer klassischen Suite machen es mühsam, alles von Hand aufzuschreiben. Wer Teile der Dokumentation automatisiert, verhindert, dass sie zum Engpass wird. Abgesehen von der Menge gültiger Fälle unterscheidet sich die Dokumentationsarbeit aber kaum vom klassischen Testen.
Die Werkzeuglücke ist echt
Es gibt kein einzelnes Tool, das dir das Chatbot-Testen abnimmt. In der Praxis mischst du mehrere spezialisierte Werkzeuge mit viel manuellem Testen, eine Komplettlösung gibt es noch nicht.
Nützlich war zum Beispiel Ragas zum Testen von RAG-Systemen. Es deckt einen Teil der Arbeit ab, nicht die ganze. Danach testest du wieder manuell.
Diese Lücke betrifft nicht nur Chatbots. KI kann Teile der Arbeit übernehmen, aber harte Infrastruktur, Subsysteme und ähnliche Schichten lassen sich schwer automatisieren. Das kann sich ändern, und individuelle Einzellösungen könnten mit der Zeit zu richtigen Produkten und Suiten reifen. Im Moment fehlen die Werkzeuge.
Der Einstieg: die Strategie aus dem System heraus entwickeln
Der Weg ins Chatbot-Testen führt darüber, zu erforschen, was im System steckt, und es in testbare Bereiche zu gliedern. Ein fertiges Playbook zum Abschreiben gibt es nicht. Du baust dir dein eigenes aus Artikeln, Forschungsarbeiten, Konferenzvorträgen und dem, was dein Team gemeinsam herausfindet.
Konzepte musst du verstehen, bevor du sie testen kannst. Vektordatenbanken, wozu man überhaupt eine Vektordatenbank braucht, Chunking und Overlap, Top-k-Scores: All das willst du erst nachlesen und durchdringen. Der beste Rat ist, direkt mit einem Chatbot zu spielen, ihn mit ein paar Fragen zu trainieren und zu beobachten, was passiert. Über diesen direkten Kontakt ergeben die fremden Teile nach und nach einen Sinn.
Häufig gestellte Fragen
Kann man einen Chatbot mit nur einer erwarteten Antwort pro Testfall bewerten?
Nein. Dieselbe Frage kann viele verschiedene Antworten hervorbringen, und mehrere davon können gleichzeitig gültig sein. Der klassische Testentwurf geht von einem gültigen Fall aus und behandelt alles andere als negativ, was hier nicht zutrifft. Die Aufgabe des Testers besteht nun darin, zu beurteilen, ob eine Antwort korrekt, relevant und themenbezogen ist, oft ohne die richtige Antwort im Voraus zu kennen.
Welche Teile eines Chat-Systems müssen neben der sichtbaren Antwort noch getestet werden?
Chunks, Abfragen, Prompts und die Abruflogik liegen alle hinter dem Chat-Fenster und können jeweils getestet werden. Die meisten Chatbots basieren auf „Retrieval-Augmented Generation“, daher ist das, was das System abruft, bevor es eine Antwort schreibt, genauso wichtig wie der Text selbst. Die Qualität der Chunk-Aufteilung, semantische Grenzen, Top-K-Werte, Vektor-Embeddings und die Wahl der Vektordatenbank sind konkrete Testziele.
Was bedeutet Kontextbeibehaltung im Zusammenhang mit der Chatbot-Qualität?
Kontextbeibehaltung bedeutet, dass der Bot das, was zuvor gesagt wurde, über eine mehrstufige Unterhaltung hinweg beibehält, sodass der Nutzer bereits gegebene Informationen nie wiederholen muss. Das ist nicht nur eine Frage des Inhalts. Kontext und Inhalt müssen gemeinsam getestet werden, denn eine Antwort kann sachlich richtig und trotzdem nutzlos sein, wenn der Bot den Gesprächsverlauf vergessen hat, zu dem sie gehört.
Bedeutet ein Stresstest für einen Chatbot, seine Leistung unter Last zu prüfen?
Nein. Bei einem Chatbot bedeutet ein Stresstest, ihn mit den chaotischen Eingaben zu füttern, die echte Nutzer produzieren: Rechtschreibfehler, Tippfehler, mehrdeutige Begriffe und schlecht formulierte Fragen, vor allem solche, die auftreten, wenn jemand frustriert ist. Das Ziel ist es, zu sehen, wie sich der Bot schlägt, wenn eine Frage schlecht formuliert ist. Ein Bot, der nur mit ordentlichen Eingaben zurechtkommt, ist nicht bereit für echte Nutzer.
Wo liegen Chatbot-Fehler normalerweise, wenn nicht im Code?
Sie können beim Abrufen, im Prompt oder bei der Generierung der Antwort liegen. Der Fehler könnte darin liegen, wie Informationen aus der Datenbank abgerufen werden, oder in einem schlecht strukturierten Prompt, die zu einem schlechten Ergebnis führt. Deshalb darfst du nicht einfach davon ausgehen, dass der Code schuld ist, und dort mit dem Debugging anfangen. Finde zuerst die fehlerhafte Ebene.
Was muss protokolliert werden, um eine falsche Chatbot-Antwort nachvollziehbar zu machen?
Das Protokollieren von Abfrage und Antwort reicht nicht aus. Du musst auch die abgerufenen Chunks protokollieren, damit du sehen kannst, warum ein bestimmter Chunk zurückgegeben wurde und wie der Abruf ablief. Ohne diesen detaillierten Ablaufverlauf wird die Grundursachenanalyse zu reiner Spekulation. Manche Korrekturen sind einfach, andere erfordern das erneute Trainieren des Modells, dessen Aktualisierung oder die Überarbeitung der Strategie für eine ganze Klasse von Situationen.
Gibt es ein einziges Tool, das das Testen von Chatbots von Anfang bis Ende abdeckt?
Eine solche All-in-One-Lösung gibt es nicht. Die Arbeit besteht aus einer Mischung aus mehreren spezialisierten Tools und einem hohen Anteil an manuellen Tests. Ragas hat sich beim Testen von RAG-Systemen als nützlich erwiesen, deckt aber nur einen Teil der Aufgabe ab, danach bist du wieder auf manuelle Arbeit angewiesen. Maßgeschneiderte Lösungen könnten sich mit der Zeit zu vollwertigen Produkten entwickeln.
Wie sollte ein Chatbot auf eine Frage reagieren, die er nicht interpretieren kann?
Eine praktische Ausweichlösung besteht darin, den Bot zurückfragen zu lassen: Anstatt bei einer mehrdeutigen Frage zu raten, fragt er, ob der Nutzer das eine oder das andere gemeint hat, und bittet um weitere Erläuterungen. Dank dieser Ausweichlogik kann das System kontrolliert zurückfahren, anstatt komplett auszufallen. Nicht jeder Fehler lässt sich verhindern, und Nutzer-Feedback sowie protokollierte Fehler fließen in das erneute Training ein.
