Ihr Chatbot glänzt bei Einzelfragen - aber hält er auch ein Gespräch aus?

Wie N+1-Evaluation die Fehler aufdeckt, die Single-Turn-Tests übersehen - und wie Sie das Ganze in elluminate aufsetzen.

Ihr Support-Bot erreicht 92 % auf dem Testset. Das Produktteam ist zufrieden. Dann werfen Sie einen Blick in die Eskalations-Queue und finden Tickets wie dieses:

Kundin: Ich habe Laufschuhe bestellt und sie sind in der falschen Größe angekommen.
Bot: Gerne helfe ich Ihnen bei der Rücksendung! Wie lautet Ihre Bestellnummer?
Kundin: ORD-2847193.
Bot: Gefunden! Nike Air Zoom Pegasus, Größe 10, geliefert am 3. April. Sie sind noch innerhalb der Rückgabefrist.
Kundin: Super. Was muss ich tun, um sie zurückzuschicken?
Bot: Gerne helfe ich Ihnen bei der Rücksendung! Wie lautet Ihre Bestellnummer?

Der Bot dreht sich im Kreis. Er vergisst, was bereits besprochen wurde. Er fragt nach Informationen, die die Kundin längst geliefert hat. Und Ihr Score von 92 %? Der wurde auf Single-Turn-Fragen gemessen - isolierten Prompts ohne Gesprächsverlauf. Der Bot musste sich nie etwas merken.

Genau diese Lücke übersehen die meisten Evaluations-Setups komplett. Wir sind auf dieses Problem bei einem unserer Kunden gestoßen, einem deutschen IT-Dienstleister im Bereich gesetzliche Krankenversicherung. Er betreibt einen Support-Bot im Kundenkontakt und hatte solide Single-Turn-Evaluationen etabliert - aber keinen Weg, um das Verhalten des Bots über mehrere Gesprächsrunden hinweg systematisch zu testen. Den in diesem Beitrag beschriebenen Workflow haben wir gemeinsam mit ihm aufgebaut.

Single-Turn-Tests verbergen Multi-Turn-Fehler

Wenn Sie einen Chatbot mit einzelnen Fragen wie „Wie sende ich einen Artikel zurück?” oder „Wie lautet Ihre Rückerstattungsrichtlinie?” testen, prüfen Sie sein Wissen. Das ist notwendig, aber nur die halbe Miete. In der Produktion stellen Kunden keine isolierten Fragen. Sie führen Gespräche: liefern Kontext, stellen Rückfragen, ändern die Richtung und werden ungeduldig, wenn sie sich wiederholen müssen.

Die Fehler, die tatsächlich zu Eskalationen führen, sind fast immer Multi-Turn-Fehler:

• Der Bot verliert den Kontext und fragt zweimal nach der Bestellnummer
• Der Bot widerspricht sich selbst („Sie haben Anspruch auf Rückerstattung” → „Leider ist dieser Artikel nicht rückerstattungsfähig”)
• Der Bot liefert eine generische Antwort, statt auf bereits Besprochenes aufzubauen
• Der Bot ignoriert die konkrete Situation der Kundin und fällt auf Standardantworten zurück

Single-Turn-Evaluation wird diese Fehler nie aufdecken. Sie müssen den Bot im Gespräch testen.

Zwei Ansätze zur Multi-Turn-Evaluation

Es gibt zwei wesentliche Wege, Chatbot-Gespräche zu evaluieren:

Dieser Beitrag konzentriert sich auf die N+1-Evaluation - den Ansatz, mit dem Sie heute loslegen können, mit Gesprächen, die bereits vorliegen. Simulierte Gespräche sind mächtig, aber N+1 ist der richtige Startpunkt.

Die N+1-Idee in 30 Sekunden

Das Prinzip ist einfach:

1. Nehmen Sie ein reales Gespräch bis zur letzten Kundennachricht (Turn N)
2. Lassen Sie den Bot seine nächste Antwort generieren (Turn N+1)
3. Evaluieren Sie diese Antwort gegen konkrete Qualitätskriterien

Sie testen den Bot nicht isoliert - Sie testen ihn im Kontext. Die Kriterien können prüfen, ob der Bot den Kontext gehalten, auf vorherige Informationen aufgebaut oder frühere Turns widerspruchsfrei fortgeführt hat.

Die entscheidende Bedingung: Das Gespräch muss mit einer Kundennachricht enden. Genau das löst die nächste Antwort des Bots aus - die Antwort, die Sie evaluieren.

So sieht das in der Praxis aus. Eine Kundin hat mehrere Nachrichten zu einer Lieferung in falscher Größe ausgetauscht. Ihre letzte Nachricht lautet: „Super. Was muss ich tun, um sie zurückzuschicken?” Der Bot hat die Bestellnummer bereits bestätigt, das Produkt identifiziert und die Rückgabefrist geprüft. Eine gute Antwort liefert konkrete Rücksende-Anweisungen, die auf diesem Kontext aufbauen - statt von vorne zu beginnen.

Aufsetzen in elluminate

Wir gehen das komplette Setup am Beispiel eines E-Commerce-Support-Bots durch.

Schritt 1: Eine Collection mit Conversation-Spalte anlegen

In elluminate hält eine Collection Ihre Testfälle. Für Multi-Turn-Evaluation brauchen Sie einen besonderen Spaltentyp: Conversation. Diese Spalte speichert strukturierte Nachrichtenverläufe - abwechselnde Kunden- und Bot-Nachrichten -, die elluminate während der Experimente an das Modell schickt.

Legen Sie eine Collection mit drei Spalten an:

• conversation (Typ: Conversation) - der strukturierte Chat-Verlauf
• goal (Typ: Text) - eine Beschreibung dessen, was die Kundin erreichen will
• category (Typ: Category) - die Themenkategorie (Rücksendungen, Abrechnung, Kontoprobleme usw.)

Die Spalte goal ist wichtig - sie fließt später in Ihre Evaluationskriterien ein, damit jeder Testfall gegen seine eigene, spezifische Erfolgsdefinition evaluiert wird.

Hier eine Collection mit 8 Support-Gesprächen. Jede Zeile enthält den Gesprächsverlauf, das Ziel der Kundin und eine Kategorie zum Filtern.

Schritt 2: Testset aufbauen

Jedes Gespräch in Ihrer Collection ist ein JSON-Array aus Nachrichten mit role und content:

[
  {
    "role": "user",
    "content": "I ordered running shoes and they arrived in the wrong size."
  },
  {
    "role": "assistant",
    "content": "I'd be happy to help! What's your order number?"
  },
  { "role": "user", "content": "ORD-2847193." },
  {
    "role": "assistant",
    "content": "Found it! Nike Air Zoom Pegasus, size 10. You're within the return window."
  },
  {
    "role": "user",
    "content": "Great. So what do I need to do to send them back?"
  }
]

Woher kommen diese Gespräche? Drei Quellen:

1. Echte Support-Logs - exportieren Sie Gespräche aus Ihrer Support-Plattform und bringen Sie sie ins JSON-Format
2. Handgefertigte Testfälle - schreiben Sie realistische Szenarien auf Basis Ihrer häufigsten (und problematischsten) Kundenreisen
3. Eskalations-Tickets - die Fälle, in denen der Bot in der Produktion gescheitert ist, sind die wertvollsten Testfälle überhaupt

Starten Sie mit 8 bis 15 Gesprächen über Ihre wichtigsten Problemkategorien hinweg. Mehr können Sie später jederzeit ergänzen. Eine gute Mischung: ~60 % typische Gespräche (Happy Path), ~30 % knifflige Folgefragen (Themenwechsel, Rückfragen) und ~10 % adversariale Fälle (ungeduldige Kunden, widersprüchliche Informationen).

Schritt 3: Evaluationskriterien definieren

Kriterien in elluminate sind binäre Ja/Nein-Fragen - jedes prüft einen konkreten Qualitätsaspekt der Bot-Antwort. Für Multi-Turn-Evaluation decken drei Kriterien die meisten Anwendungsfälle eines Support-Bots ab:

Jedes Kriterium nutzt {{goal}}-Platzhalter, die aus der Spalte goal der Collection befüllt werden:

Correctness: „Hat der Bot das Anliegen der Kundin richtig verstanden und eine korrekte, hilfreiche Antwort gegeben, die sie der Lösung näherbringt?”

Das ist die Basis - ist die Antwort fachlich richtig?

Coherence: „Hat der Bot den Kontext aus vorherigen Turns gehalten und darauf aufgebaut, statt redundante Fragen zu stellen oder sich selbst zu widersprechen?”

Das ist das spezifische Multi-Turn-Kriterium. Es deckt genau die Fehler auf, die Single-Turn-Tests übersehen.

Communication: „Hat der Bot klar, professionell und in angemessenem Ton kommuniziert - und, wo nötig, die Frustration der Kundin anerkannt?”

Der Ton zählt. Eine technisch korrekte Antwort, die kalt und roboterhaft klingt, erzeugt immer noch ein schlechtes Kundenerlebnis.

Beachten Sie den {{goal}}-Platzhalter in jedem Kriterium. Zur Evaluationszeit ersetzt elluminate ihn mit dem Wert aus der Spalte goal für den jeweiligen Testfall. Das heißt: Das Gespräch „Schuhe in falscher Größe zurückgeben” wird gegen dieses Ziel evaluiert, das Gespräch „gestohlenes Paket” gegen sein Ziel. Gleiche Kriterien, spezifische Evaluation.

Schritt 4: Das Experiment starten

Beim Anlegen eines Experiments kommt alles zusammen: Ihre Collection (Testdaten), Ihre Kriterien (Bewertungsregeln) und ein Modell (der Bot, der die Antworten erzeugt).

Das Entscheidende: Es ist kein Prompt-Template nötig. Da Ihre Collection eine Conversation-Spalte hat, schickt elluminate den vollständigen Chat-Verlauf direkt an das Modell. Der Bot hat seinen eigenen System-Prompt und seine eigenen Anweisungen - Sie testen ihn so, wie er ist, im Kontext.

Ein Klick auf „Create Experiment” und elluminate erledigt den Rest: Für jeden Testfall wird das Gespräch ans Modell geschickt, die Antwort erfasst und gegen alle drei Kriterien bewertet. Acht Gespräche mit je drei Kriterien dauern etwa 15 Sekunden.

Der Ausgangswert: 58 %

Wir haben unsere 8 Gespräche gegen einen echten Support-Bot laufen lassen - einen mit einfachem System-Prompt und einer knappen FAQ als Wissensbasis. Die Sorte Bot, die nach einem schnellen ersten Deployment herauskommt. Das Ergebnis:

58,3 % Gesamtscore auf 8 Gesprächen - der Bot scheitert in fast der Hälfte der Fälle. Die Aufschlüsselung pro Kriterium erzählt jedoch eine viel konkretere Geschichte:

Correctness bei 25 %, Coherence bei 75 %, Communication bei 75 %. Der Bot ist höflich und überwiegend kohärent - aber er löst das Problem der Kundin schlicht nicht. Er liefert nur in 2 von 8 Gesprächen eine wirklich hilfreiche Antwort. Das Muster: Der Bot klingt gut, liefert aber nicht.

Wenn Sie ausschließlich Single-Turn-Fragen wie „Wie sende ich einen Artikel zurück?” getestet hätten, würde dieser Bot gut abschneiden. Die FAQ kennt er. Die Multi-Turn-Evaluation deckt auf, was die FAQ nicht abdeckt.

Fehlern auf den Grund gehen

Die Kennzahl sagt Ihnen, dass etwas schiefläuft. Der Sample Navigator zeigt Ihnen, was.

Schauen wir uns zwei Fehler aus dem Ausgangslauf an.

Fehler 1: Generische Rücksende-Anweisungen (2 von 3 Kriterien bestanden)

Eine Kundin hat Schuhe in der falschen Größe erhalten und fragt, wie sie diese zurückschickt. Der Bot hat Bestellung und Rückgabefrist bereits bestätigt:

Die Kundin hat die Bestellnummer geliefert, der Bot hat Artikel und Rückgabefrist bestätigt, und die letzte Nachricht lautet: „Was muss ich tun, um sie zurückzuschicken?” Der Bot antwortet mit generischen Rücksende-Schritten: Bestellungsseite aufrufen, auf „Start Return” klicken, darauf achten, dass die Etiketten noch dran sind. Klingt plausibel. Aber sehen Sie, was die Evaluationskriterien aufgedeckt haben:

2 von 3 Kriterien bestanden. Communication bestanden (höflich, klar). Coherence bestanden (Bezug zur Bestellung). Aber Correctness nicht bestanden. Die Begründung sagt genau, warum: „Das Ziel der Kundin umfasst auch, die richtige Größe zu bekommen - die Antwort enthält keinerlei Hinweise oder Anleitungen zum Umtausch des Artikels.”

Der Bot hat die Frage beantwortet, die er beantworten konnte (wie man eine Rücksendung startet) - und den Teil ignoriert, den er nicht konnte (wie man die richtige Größe bekommt). Ein Single-Turn-Test mit der Frage „Wie sende ich einen Artikel zurück?” hätte diesen Bot mit Bravour bestanden.

Fehler 2: Komplettes Ausweichen (0 von 3 Kriterien bestanden)

Ein Kunde hat einen Bluetooth-Lautsprecher und eine Handyhülle bestellt. Der Lautsprecher ist nicht vorrätig, die Bestellung verzögert sich. Der Kunde fragt, ob die Handyhülle separat verschickt werden kann, während der Lautsprecher nachkommt:

Der Bot hat die Ursache der Verzögerung identifiziert (Lautsprecher nicht vorrätig), und der Kunde fragt: „Können Sie die Handyhülle einfach jetzt verschicken und den Lautsprecher später nachsenden?” Die Bot-Antwort: „Es tut mir leid, aber ich kann bei konkreten Änderungen an Bestellungen nicht helfen. Bitte besuchen Sie unser Help Center unter help.shopeasy.com oder rufen Sie 1-800-SHOP-EASY an.” Komplettes Ausweichen. So bewerten die Kriterien die Antwort:

Null von drei Kriterien bestanden. Die Begründungen sind vernichtend:

• Communication: „Erkennt die ausgedrückte Frustration des Kunden nicht an und gibt keine strukturierte Hilfestellung, die konkret auf das Aufteilen der Bestellung eingeht”
• Coherence: „Die abschließende Antwort übergeht die konkreten Details zur Bestellung (Handyhülle vs. Lautsprecher) und baut nicht auf diesen Informationen auf”
• Correctness: „Geht nicht direkt auf den Wunsch ein, die Bestellung zu splitten. Stattdessen wird eine generische Nachricht geliefert, die Änderungen an Bestellungen nicht bearbeiten könne”

Das Muster ist eindeutig: Sobald das FAQ-basierte Wissen des Bots an seine Grenzen kommt, weicht er aus. Er weiß nicht, wie er Expresslieferungen, Bestell-Splits, Konto-Wiederherstellung ohne Login oder Rücksendungen ohne Etikett behandeln soll. Das sind keine exotischen Edge Cases - das sind genau die Gespräche, die zu Eskalations-Tickets führen.

Der Fix: 58 % → 96 %

Die Evaluation hat uns genau gezeigt, was fehlte: konkrete Richtlinien für Edge Cases, Anweisungen an den Bot, den Gesprächskontext zu nutzen, und klare Prozesse statt Verweise aufs Help Center.

Wir haben den System-Prompt des Bots um Folgendes ergänzt:

• Ausführliche Rückgabepolicy: inklusive Ausnahme für Etiketten, die innerhalb von 14 Tagen entfernt wurden, und Umtauschoption bei falscher Größe
• Prozesse rund um Bestellungen: Teillieferungen sind möglich, Adressänderungen während der Bearbeitung ebenfalls
• Konto-Wiederherstellungs-Flow: Identitätsprüfung und E-Mail-Änderung ohne Login
• Umgang mit Lieferproblemen: Recherche beim Versanddienstleister, 48-Stunden-Frist, Ersatzlieferung oder Rückerstattung
• Kontext-Anweisung: „Beziehen Sie sich immer auf konkrete Details, die die Kundin bereits genannt hat. Fragen Sie nie nach Informationen, die bereits geliefert wurden.”

Vor dem erneuten Lauf haben wir dem Testset noch ein weiteres Gespräch hinzugefügt - einen Fall mit einem beschädigten Geschenk, bei dem eine Kundin eine Lösung in Stunden statt Tagen braucht. Die ursprünglichen 8 Gespräche stammten aus Fehlern, die wir in Eskalationen bereits gesehen hatten - das verzerrt das Set zugunsten der Probleme, die der Fix gezielt adressieren sollte. Ein frischer Edge Case prüft, ob der Fix über die bekannten Probleme hinaus trägt - und nicht nur diese flickt.

Danach haben wir das vollständige Set aus 9 Gesprächen erneut gegen den aktualisierten Bot laufen lassen:

96,3 % Gesamtscore - Correctness ist von 25 % auf 89 % gesprungen, Coherence und Communication liegen jeweils bei 100 %. Der Fix hat fast jede Lücke aus dem Ausgangslauf geschlossen, nur ein Fall scheitert noch:

Schauen wir uns dasselbe Gespräch zum Bestell-Split an, das im Ausgangslauf 0 von 3 erreicht hat:

Gleicher Kunde, gleiche Frage - aber 3 von 3 Kriterien bestanden. Vorher: „Ich kann bei Änderungen an Bestellungen nicht helfen.” Nachher: „Ich kann die Handyhülle sofort versenden lassen, der Lautsprecher geht raus, sobald er wieder verfügbar ist.” Der Bot erkennt die Frustration an, nimmt Bezug auf die konkreten Artikel (Handyhülle vs. Lautsprecher) und den Lagerstatus aus den vorherigen Turns, bietet an, die Bestellung aufzuteilen, und liefert einen klaren nächsten Schritt. Das Problem des Kunden ist tatsächlich gelöst.

Der eine Fall, der weiterhin scheitert

Der einzige Fehlschlag ist das Gespräch, das wir bewusst ergänzt haben: Eine Kristallvase kommt am Tag vor dem 60. Geburtstag der Mutter der Kundin zerbrochen an. Eine Rückerstattung löst das Timing-Problem nicht. Ein Standard-Ersatz in 3 bis 5 Tagen kommt zu spät. Die Kundin fragt explizit, was der Bot tun kann, um morgen vor 10 Uhr einen Ersatz zu liefern - und der Bot, beschränkt auf Richtlinien, die Rückerstattungen und Standard-Ersatz abdecken, aber keinen Express-Weg kennen, bietet an, was er hat, und entschuldigt sich.

Der Evaluator hat das bei Correctness aufgefangen: Die Antwort ist klar und kontextbezogen, löst aber das Ziel der Kundin nicht. Und genau darum geht es bei Multi-Turn-Evaluation - sie zeigt das nächste, was zu beheben ist. Der nächste Schritt ist klar: ein Prozess für „dringende Geschenke” ins Playbook des Bots aufnehmen (Kurier am selben Tag, Filialabholung koordinieren, Geschenkgutschein mit Zusage einer späteren Ersatzlieferung als Fallback). Ausrollen, dieselben 9 Gespräche erneut laufen lassen - und die 96 % rücken näher an die 100 %. Ehrlich gesagt: ein Edge Case nach dem anderen.

Das Testset ist jetzt Ihre Regressions-Suite. Jedes Mal, wenn Sie den Bot aktualisieren, lassen Sie das gleiche Experiment erneut laufen. elluminate unterstützt geplante Experimente - richten Sie einen wöchentlichen Lauf ein, und Sie erkennen Regressionen, bevor Ihre Kunden es tun. Mit der Zeit wächst das Testset, indem Sie reale Gespräche ergänzen, in denen der Bot in der Produktion versagt hat.

Fangen Sie mit dem an, was Sie haben

Sie brauchen kein Simulations-Framework und keine synthetischen Personas, um Multi-Turn-Qualität zu evaluieren. Sie brauchen drei Dinge:

1. Eine Handvoll echter Gespräche - schon 5 reichen, um Muster zu erkennen
2. Klare Evaluationskriterien - was heißt „gut” konkret für Ihren Bot?
3. Einen systematischen Weg, das Ganze laufen zu lassen - keine Einmal-Aktion, sondern einen wiederholbaren Prozess

Das Conversation-Feature in elluminate liefert Ihnen diesen dritten Baustein. Fügen Sie Gespräche aus Ihrer Support-Plattform ein, definieren Sie Ihre Kriterien und starten Sie ein Experiment. Sie sehen exakt, wo Ihr Bot trägt und wo er auseinanderfällt - in Minuten, nicht Tagen.

Der Single-Turn-Score Ihres Bots mag 92 % sein. Aber wenn er kein Gespräch führen kann, wissen Ihre Kunden das längst.

Bereit, Ihre Gespräche zu evaluieren?

Wir helfen Teams, N+1-Evaluations-Workflows auf ihrem echten Produktivtraffic aufzusetzen - von der Wahl der richtigen Kriterien bis zu geplanten Läufen, die Regressionen erkennen, bevor Kunden es tun. Wenn Sie sehen wollen, wie das zu Ihrem Bot passt, sprechen Sie uns an.

Demo buchen