Sprachagenten und Korrekturen: Warum es nicht reicht, die richtige Bestellnummer zu hören

Eine Bestätigung, die richtig klang

Ein Kunde bittet einen Sprachagenten, die Lieferung von Bestellung 4821 auf Freitag zu verschieben. Bevor der Agent ausgeredet hat, unterbricht der Kunde mit einer Korrektur: Die Nummer ist 4281, nicht 4821. Der Agent bricht mitten im Satz ab, stimmt zu und verspricht, Bestellung 4281 zu aktualisieren.

Das Gespräch endet in guter Stimmung. Doch das System hat Bestellung 4821 geändert, und Bestellung 4281 wurde nie angefasst.

Die Spracherkennung hat beide Nummern korrekt erfasst. Der Agent hat die korrigierte sogar wörtlich wiederholt. Im Transkript ist nichts falsch, und trotzdem ist etwas kaputtgegangen.

Warum ein Transkript kein Zustand ist

Das Debugging beginnt damit, die offensichtlichen Verdächtigen auszuschließen. Es war kein Erkennungsfehler, und der Agent hat keine Nummer erfunden. Die Pipeline hat einfach vier verschiedene Dinge behandelt, als wären sie eines:

Conversation history   →  4821, then a correction to 4281
Active intent          →  the order the customer currently means
Pending action         →  the order ID already loaded into the tool call
Backend state          →  the order that was actually written

Ein Transkript ist ein Ereignisprotokoll. Es hält alles Gesagte in Reihenfolge fest, für immer. Beide Bestellnummern gehören dort hinein, weil beide ausgesprochen wurden. Nach der Korrektur gehört aber nur noch eine davon in den aktiven Aufgabenzustand, und wenn das Transkript zugleich der Zustand ist, kann nichts den früheren Wert als veraltet markieren.

Die Aufzeichnung dessen, was gesagt wurde, war korrekt. Schiefgegangen ist der Zustandsübergang.

Wie der veraltete Wert überlebte

Drei gewöhnliche Designentscheidungen reichen dafür aus, und die meisten Voice-Stacks enthalten alle drei.

Ein Verlauf, der nur wächst

Eine Korrektur kommt als eine weitere Nachricht an, und niemand erklärt den alten Wert ausdrücklich für ungültig. In jedem Zug muss das Modell herausfinden, welcher von mehreren plausiblen Werten aktuell ist. Wenn die Latenz knapp ist, kann diese Überlegung das Rennen gegen die nächste Aktion verlieren.

Zu früh vorbereitete Tools

Sprachagenten sind auf schnelle Reaktion getrimmt, deshalb beginnen Tool-Aufrufe oft schon mit dem Befüllen der Argumente, bevor der Kunde den Satz beendet hat. Ein Unterbrechen bringt das Audio zum Schweigen. Eine API-Anfrage, die bereits unterwegs ist, bricht es nicht automatisch ab.

Mehrere Kopien einer Tatsache

Das Gesprächsmodell, die Orchestrierungsschicht und die Tool-Aufruf-Schicht halten oft jeweils eine eigene Kopie der Bestell-ID, und wer eine aktualisiert, aktualisiert die anderen nicht. Daraus entsteht das übelste Ergebnis. Laut sagt der Agent 4281, aber das Tool hält noch 4821, sodass das Gespräch richtig klingt, während die Aktion falsch ist.

Was der Trace zeigt

Weder das Transkript noch die letzte gesprochene Antwort verraten etwas davon. Nur ein Ausführungs-Trace mit Zeitstempeln zeigt es:

10:03:12.100  Customer mentions order 4821
10:03:12.420  Active state set: order_id = 4821
10:03:13.000  Update tool prepared: order_id = 4821
10:03:13.250  Customer interrupts: "Sorry, I meant 4281."
10:03:13.510  Conversation state updated:  order_id = 4281
10:03:13.700  Previously prepared tool executes: order_id = 4821
10:03:14.100  Agent says: "I've updated order 4281."

Die Korrektur kam bei 13.510 an, der Tool-Aufruf war aber schon bei 13.000 festgeschrieben. Alles nach diesem Festschreiben, einschließlich der gesprochenen Bestätigung, spiegelt einen Wert wider, der nicht mehr dem entspricht, was der Kunde will. Eine Evaluierung, die prüft, ob das Transkript die Korrektur erfasst hat oder ob die Antwort die richtige Bestellung nannte, würde dieses Gespräch durchwinken. Nur der Trace legt die Abweichung offen.

Korrekturen müssen ausstehende Arbeit abbrechen

Ein raffinierterer Prompt ist nicht die Heilung. Das Gespräch muss als gestufter Zustandsautomat laufen, und eine Korrektur muss jeden Schritt rückgängig machen, der vom ersetzten Wert abhing:

→ Intent detected
→ Parameters collected
→ Parameters validated
→ Customer confirmation
→ Action committed
→ Backend result verified

Wenn sich die Bestell-ID ändert, wird eine ganze Kette veraltet: der geladene Bestelldatensatz, das Ergebnis der Berechtigungsprüfung, die für das Tool eingereihten Argumente, eine bereits gegebene Bestätigung des Kunden und jeder noch nicht abgeschlossene Schreibvorgang. Der Ablauf kehrt zur Stufe „Parameter erfasst“ zurück und läuft erneut vorwärts. In der Praxis braucht es dafür mehrere Dinge, die zusammenspielen:

• strukturierter Aufgabenzustand statt eines aus dem Transkript abgeleiteten Zustands
• Versionsnummern am Zustand, damit ein veralteter Schreibvorgang erkannt und abgelehnt werden kann
• Idempotenzschlüssel, damit eine doppelte oder überholte Aktion nicht unbemerkt zweimal angewendet wird
• ausdrückliches Abbrechen laufender Tool-Aufrufe bei jedem Unterbrechen
• eine Bestätigung, die an den aktuellen Zustand gebunden ist und nicht an den Zustand beim Beginn der Bestätigung
• ein Abgleich mit dem Backend nach der Ausführung, statt dem Rückgabewert des Tools zu vertrauen

Wie man darauf testet

Ein Test, der die Genauigkeit des Transkripts misst, findet diese Fehlerklasse nie, weil das Transkript in Ordnung ist. Um sie zu fangen, braucht es synthetische Gespräche, die an drei bestimmten Stellen unterbrechen: bevor das Tool vorbereitet ist, während der Vorbereitung und nach dem Absenden. Sie sollten über mehrere Arten von Korrekturen laufen: Bestellnummer, Menge, Lieferdatum, Adresse, Identität des Kunden und Verneinung, etwa ein Kunde, der um Bestätigung bittet und gleich danach sagt, doch nicht.

Jeder Lauf wird anhand von sieben Fragen bewertet:

1. Wurde die Korrektur erfasst?
2. Wurde der aktive Zustand aktualisiert?
3. Wurde der alte Wert ungültig gemacht?
4. Hat das Tool die richtigen Argumente bekommen?
5. Wurde eine doppelte oder veraltete Aktion versucht?
6. War der endgültige Backend-Zustand korrekt?
7. Stimmte die gesprochene Bestätigung mit dem Backend überein?

Die Lücke zwischen der sechsten Frage und den Prüfungen der gesprochenen Bestätigung auf Transkriptebene ist genau der Ort, an dem sich dieser Fehler versteckt. Sichtbar wird er nur mit einer Testsuite, die die Wahrheit im Backend misst und nicht die Plausibilität des Gesprächs.

Hören ist nicht Anwenden

Ein Sprachagent verdient kein Lob dafür, dass er eine Korrektur hört oder sauber wiederholt. Das sind Aussagen auf Gesprächsebene. Damit eine Korrektur zählt, muss sie den aktiven Zustand aktualisieren, jede ausstehende Aktion abbrechen oder ersetzen, mit den richtigen Argumenten beim Tool ankommen und schließlich im Backend auftauchen.

In Voice-KI ist „Ich habe Sie verstanden“ eine Aussage über das Gespräch, „Die Korrektur ist angewendet“ dagegen eine Aussage über das Zustandsmanagement. Produktivsysteme müssen die zweite überprüfen, denn ohne diese Prüfung verrät das Transkript nichts.