Ein Gespräch testen, nicht eine Frage
Unser Referenzset stellte eine Frage und prüfte eine Antwort — ein fairer Test für eine Suchmaschine und ein schlechter für einen Assistenten. Echte Gespräche haben Rückfragen, und in der Rückfrage ging unserer schief.
Wo die Fehler lagen
Wir haben sechzig eskalierte Gespräche durchgesehen, um herauszufinden, was der Assistent falsch gemacht hatte. In einundvierzig war die erste Antwort in Ordnung. Das Problem trat in der zweiten oder dritten Runde auf, und in neunzehn davon war der Auslöser eine Rückfrage, die sich auf etwas Früheres bezog.
Unser Bewertungsset enthielt nichts davon, denn jeder Fall war eine Frage mit erwarteter Antwort. Wir hatten den Teil gemessen, der funktionierte.
Die zwei Fehler, die einen Verlauf brauchen
Bezugnahme. Ein Nutzer fragt nach einem Teil und sagt dann und das andere, und der Assistent löst das entweder richtig auf oder antwortet über etwas, das der Nutzer nie erwähnt hat. Mit einem Einzelfragefall lässt sich das nicht prüfen, denn die Mehrdeutigkeit besteht nur relativ zum Vorherigen.
Übertragung von Einschränkungen. Ein Nutzer stellt in Runde eins fest, dass er an der älteren Variante arbeitet, und in Runde vier antwortet der Assistent für die aktuelle, weil die Einschränkung aus dem Kontext gealtert ist. Beide Fehler sehen im Protokoll wie gewöhnliche falsche Antworten aus.
Die Forschung zur Bewertung von Dialogen
Kranti und Kollegen veröffentlichten 2025 clem:todd, einen Rahmen zur systematischen Bewertung aufgabenorientierter Dialogsysteme auf Basis von Sprachmodellen, mit dem Gespräch statt der einzelnen Antwort als Bewertungseinheit.
Übernommen haben wir den Gedanken, dass ein Dialogtest ein Gegenüber braucht. Eine einzelne Antwort zu prüfen verlangt nur eine Eingabe; ein Gespräch zu prüfen verlangt etwas, das den Nutzer spielt — und dieses Etwas zu entwerfen ist der größte Teil der Arbeit.
| Einzelfragefall | Gesprächsfall |
|---|---|
| Eine Eingabe, eine erwartete Antwort | Ein Ziel und eine Folge von Nutzerrunden |
| Prüft Richtigkeit | Prüft Richtigkeit und Übertragung |
| Billig zu schreiben | Braucht einen simulierten oder festen Nutzer |
| Verfehlt Bezug und Einschränkungen | Fängt beides |
Wie wir einen Gesprächsfall bauen
Mit einem festgeschriebenen Nutzer, nicht mit einem simulierten, wenn es als Gate dient. Jeder Fall ist eine feste Folge von Nutzerrunden, geschrieben von einem Fachexperten, mit erwarteten Eigenschaften je Assistentenrunde: Die Antwort muss die ältere Variante betreffen, muss das genannte Teil benennen, darf keine Einschränkung erfinden.
Festgeschrieben heißt, der Test ist deterministisch und der Fehler zuordenbar. Ein simulierter Nutzer, der bei jedem Lauf andere Runden erzeugt, ist zur Erkundung nützlich und als Gate nutzlos, denn ein fehlgeschlagener Lauf lässt sich nicht reproduzieren.
Wo der simulierte Nutzer nützt
Beim Finden von Fällen, die wir nicht geschrieben hätten. Wir lassen ein Modell mit Ziel und Rolle als Nutzer gegen den Assistenten laufen, sammeln Gespräche, die ohne Zielerreichung enden, und ein Mensch liest sie. Die guten werden zu festgeschriebenen Fällen.
Das ist die richtige Aufteilung: Der Simulator erzeugt Kandidaten, ein Mensch entscheidet, wie ein korrektes Gespräch aussieht, und die festgeschriebene Fassung läuft in der Pipeline. Den Simulator urteilen zu lassen wiederholte den Fehler, den wir mit erzeugten Bewertungsdaten gemacht haben.
Was sich am System geändert hat
Zwei Dinge, beide klein und beide für einen Einzelfragetest unsichtbar. Der Assistent nennt heute die Einschränkung, unter der er arbeitet, wenn ein Gespräch eine festgelegt hat — in einem kurzen Halbsatz, nicht in einem Absatz. Und Bezüge auf frühere Gegenstände werden ausdrücklich aufgelöst, mit sichtbarer Auflösung, statt still erschlossen.
Die Eskalationen aus den mehrstufigen Fehlerarten fielen um rund zwei Drittel. Die Einzelfragegenauigkeit bewegte sich überhaupt nicht — genau das war zu erwarten und ist der klarste Beleg dafür, dass die beiden Tests Verschiedenes messen.
Was es kostet
Ein Gesprächsfall kostet einen Fachexperten etwa dreimal so viel Zeit wie ein Fragefall, und wir haben vierzig davon gegenüber achtzig Einzelfragefällen. Die Suite läuft länger, weil jeder Fall mehrere Modellaufrufe umfasst.
Wir würden das Einzelfrageset dadurch nicht ersetzen. Diese Fälle sind billiger, decken Abruf- und Extraktionsverhalten gründlich ab und fangen Fehler, die ein Gesprächstest nur zufällig fände. Die beiden Sets prüfen verschiedene Komponenten.
Was wir nicht behaupten
Wir behaupten nicht, vierzig Gesprächsfälle seien ausreichende Abdeckung. Gespräche verzweigen, unsere nicht, und ein Nutzer, der einen nicht geschriebenen Weg nimmt, ist ungeprüft. Es ist besser als null, wo wir waren, und das ist die ehrliche Beschreibung.
Wir behaupten auch nicht, der simulierte Nutzer finde repräsentative Probleme. Er findet Probleme, auf die ein Modell in der Nutzerrolle stößt — eine Verteilung mit eigenen Verzerrungen — und der menschliche Filterschritt existiert genau deshalb, weil wir ihm die Auswahl nicht zutrauen.