Eskalation an einen Menschen

Jedes Gesprächssystem stößt an eine Grenze. Die Frage ist, was dann passiert, und die zweitbeste Antwort lautet: Ein Mensch übernimmt.

Der Fachbegriff dafür

Human in the Loop, abgekürzt HITL, bezeichnet die Stelle in einem Ablauf, an der ein Mensch entscheidet. Der Werkzeugkasten von OpenAI für Agenten beschreibt eine seiner zwei Formen so:

Use the human-in-the-loop (HITL) flow to pause agent execution until a person approves or rejects sensitive tool calls. (externe Seite, openai.github.io)

Das ist die Freigabe: Der Ablauf hält an, ein Mensch stimmt einer einzelnen Handlung zu, und danach läuft alles weiter wie zuvor. Das Gespräch bleibt beim System. Wie diese Rückfrage im Sprachkanal aussieht, steht in Kapitel 06.

Die zweite Form ist die Übergabe, im Englischen handoff. Hier wechselt das Gespräch den Sprecher: Ab einem bestimmten Punkt redet der Anrufer mit einer Person, und das System ist raus. Dieses Kapitel handelt überwiegend von der zweiten, weil sie am Telefon die schwierigere ist.

Auch die Anbieter nennen beide in einem Atemzug. Die Anleitung für Sprachagenten empfiehlt:

Use Guardrails and human review when spoken workflows need safety checks or approvals. (externe Seite, developers.openai.com)

Prüfung durch die Maschine und Prüfung durch den Menschen stehen dort nebeneinander, und das ist der Zusammenhang zu Kapitel 07: Beide beantworten dieselbe Frage, nämlich wo ein System aufhört, für sich selbst zu entscheiden.

Was das Tastenmenü besser konnte

Wer je in einer Warteschleife war, kennt den Vorgänger. IVR steht für Interactive Voice Response, das Menü, das Ansagen vorliest und auf Tastendrücke wartet. Die Technik dahinter steht in Kapitel 04, wo die Tastenwahl an der Stimme vorbeiläuft.

An diesem alten Aufbau war eine Sache besser als heute: Der Ausstieg war eine Taste. Er stand im Menü, er war abzählbar, und wer ihn drückte, landete bei einem Menschen. Das System musste dafür nichts verstehen.

Ein Sprachagent hat diese Stelle nicht mehr von selbst. Er versteht ganze Sätze, also gibt es kein Menü, in dem der Ausstieg als Punkt vier stünde. Wann übergeben wird, muss eigens entschieden und eigens gebaut werden. Was Kapitel 01 über die Grenze und die Übergabe sagt, findet hier seine Ausführung.

Die Voreinstellung ist ein Eingeständnis

Bei einem verbreiteten Werkzeugkasten für Dialogsysteme ist die Übergabe ein vorgefertigter Gesprächsverlauf. Was ohne eigenes Zutun geschieht, steht in der Dokumentation:

Currently, the default behaviour for a human handoff is to inform the user that the assistant cannot help with the request. (externe Seite, rasa.com)

Der Standardfall ist also, dem Anrufer zu sagen, dass es hier nicht weitergeht. Das klingt nach einer Schwäche und ist eine vorsichtige Grundeinstellung: Ein Tool kann nicht wissen, ob am anderen Ende jemand sitzt.

Die Bedingung sagt der Hersteller im nächsten Satz:

However, in scenarios where customer service is available, implementing a human handoff becomes relevant. (externe Seite, rasa.com)

Damit ist die Eskalation als das benannt, was sie zuerst ist: eine Betriebsfrage. Ein Sprachagent kann rund um die Uhr antworten. Die Menschen, an die er übergibt, können das selten. Wer eine Übergabe einbaut, ohne die Besetzung dahinter zu klären, baut eine Tür in eine Wand.

Drei Auslöser, die sich unterscheiden lassen

Beim Bauen hilft es, die Fälle zu trennen, in denen übergeben wird.

Das System weiß es nicht. Die Frage liegt außerhalb dessen, was es beantworten kann. Das ist der Fall, den Grundkurs, Kapitel 07 als Enthaltung beschreibt, und der einfachste von dreien.

Das System darf es nicht. Die Auskunft wäre möglich, und für ihre Folgen möchte niemand geradestehen. Hier greifen die Regeln aus Kapitel 07.

Der Anrufer will es. Jemand verlangt einen Menschen. Das ist der Fall, den das Tastenmenü von selbst konnte, und der einzige, bei dem eine Diskussion schadet.

Das Weiterverbinden eines Anrufs ist ein gelöstes Problem. Es steht seit 2009 in einer Spezifikation, und wer heute einen Sprachagenten baut, benutzt genau diese Mechanik.

Drei Formen, drei Rollen

Die Spezifikation nennt die Varianten in einem einzigen Satz:

SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. (externe Seite, rfc-editor.org)

Auf Deutsch: die unangekündigte Weitergabe, die Weitergabe mit Rückfrage und die angekündigte Weitergabe. Der Unterschied liegt darin, was zwischen dem Auslösen und dem Verbinden passiert.

Dazu drei Rollen, und die Spezifikation gibt ihnen Namen. Der Transferor gibt weiter, der Transferee wird weitergegeben, das Transfer Target ist das Ziel. In unserem Fall ist der Sprachagent der Transferor, der Anrufer der Transferee, und das Ziel ist ein Mensch. Die einfachste Form geht so:

Basic Transfer consists of the Transferor providing the Transfer Target’s contact to the Transferee. (externe Seite, rfc-editor.org)

Der Agent gibt dem Anrufer also die Adresse des Ziels weiter, und der Anrufer wendet sich dorthin. Für den Anrufer sieht es aus wie ein Verbinden. Technisch ist es eine Bitte, sich woandershin zu wenden.

Warum eine Form rückholbar ist

Der Satz, an dem sich die Bauentscheidung entscheidet, steht ebenfalls in der Spezifikation:

The signaling relationship between the Transferor and Transferee is not terminated, so the call is recoverable if the Transfer Target cannot be reached. (externe Seite, rfc-editor.org)

Der Sprachagent bleibt also in der Leitung, während die Verbindung zum Ziel aufgebaut wird. Meldet sich dort niemand, hat der Anrufer weiterhin jemanden am Apparat. Bei der unangekündigten Form endet die Verbindung sofort, und wenn das Ziel besetzt ist, steht der Anrufer im Leeren.

Die aufwendigste Form beschreibt die Spezifikation Schritt für Schritt:

The Transferor places the Transferee on hold, establishes a call with the Transfer Target to alert them to the impending transfer, places the target on hold, then proceeds with transfer using an escaped Replaces header field in the Refer-To header. (externe Seite, rfc-editor.org)

Übersetzt: Der Anrufer wartet, der Agent ruft den Menschen an und kündigt die Übergabe an, und erst danach werden beide verbunden. Das ist die Form, die im Callcenter seit jeher „warm“ heißt, und für einen Sprachagenten die interessanteste. In dem Moment, in dem er den Menschen anspricht, kann er ihm sagen, worum es geht.

Die Methode darunter

Die eigentliche Mechanik ist älter und schlichter. Eine eigene Spezifikation von 2003 definiert sie:

This document defines the REFER method. (externe Seite, rfc-editor.org)

This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. (externe Seite, rfc-editor.org)

Eine Gegenstelle wird gebeten, sich an eine Adresse zu wenden. Bemerkenswert ist, wie zurückhaltend der Text bei den Anwendungen bleibt:

This can be used to enable many applications, including call transfer. (externe Seite, rfc-editor.org)

Die Anrufweitergabe ist dort ein Beispiel unter mehreren. Was die Methode mitbringt, ist eine Rückmeldung:

It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. (externe Seite, rfc-editor.org)

Der Bittende erfährt also, ob es geklappt hat. Für einen Sprachagenten ist das die Voraussetzung dafür, überhaupt zu merken, dass eine Übergabe schiefgegangen ist.

Dieselbe Sache heute

Die Sprachschnittstelle von OpenAI, die in Kapitel 04 beschrieben ist, führt die Weitergabe als eigenen Endpunkt. Die Aufzählung dort liest sich wie eine Zusammenfassung dieses Kapitels:

The APIs to accept, reject, monitor, refer, and hangup the call are documented below. (externe Seite, developers.openai.com)

Annehmen, ablehnen, mithören, weitergeben, auflegen. Für den vierten Punkt steht dort:

Transfer an active call using the Refer call endpoint. (externe Seite, developers.openai.com)

Wichtig ist, wo die Zuständigkeit dabei endet. Der Anbieter reicht die Bitte weiter und meldet den Erfolg dieses Schrittes:

OpenAI returns 200 OK once the REFER is relayed to your SIP provider. (externe Seite, developers.openai.com)

The downstream system handles the rest of the call flow for the caller. (externe Seite, developers.openai.com)

Die Bestätigung sagt also, dass die Bitte angekommen ist. Ob der Mensch am anderen Ende erreicht wurde, steht auf einem anderen Blatt und in einem anderen System. Wer eine Übergabe baut und den Rückgabewert als Erfolgsmeldung liest, misst den falschen Schritt. Das ist dieselbe Unterscheidung, die Kapitel 06 beim Tool Call trifft: Ein Aufruf angestoßen zu haben, sagt nichts über sein Ergebnis.

Die Leitung umzulegen ist der gelöste Teil. Der ungelöste ist die Frage, was der Mensch am anderen Ende über das bisherige Gespräch erfährt.

Drei Anbieter, drei Antworten

Bei einem Werkzeugkasten für Dialogsysteme geschieht die Übergabe im Kanal, und die Dokumentation beschreibt sie ungewöhnlich handfest:

A straightforward way to achieve human handoff is to configure your messaging or voice channel to switch which host it listens to based on a specific bot or user message. (externe Seite, legacy-docs-oss.rasa.com)

Der Kanal hört also ab einem bestimmten Punkt einem anderen Rechner zu. Und dann folgt der einzige Satz in allen geprüften Quellen, der den Inhalt der Übergabe benennt:

When the channel sees this message, it stops listening to the Rasa server, and sends a message to the human channel with the transcript of the chat conversation up to that point. (externe Seite, legacy-docs-oss.rasa.com)

Übergeben wird die Abschrift bis zu diesem Punkt. Das ist eine Entscheidung, und sie ist hier ausdrücklich getroffen worden.

Google gibt für dieselbe Sache ein Signal aus und überlässt alles Weitere der Anwendung:

This response signals to the detect intent API caller that the conversation should be handed off to a human agent. (externe Seite, docs.cloud.google.com)

Your system or integration can use this signal to take any actions necessary to hand off the conversation. (externe Seite, docs.cloud.google.com)

Für die Daten, die dabei mitgehen, macht die Plattform ausdrücklich keine Vorgabe:

Because Dialogflow CX does not impose structure on this data, you can choose any structure that suits your system. (externe Seite, docs.cloud.google.com)

Und die Sprachschnittstelle aus Kapitel 04 übergibt eine Zieladresse. Zum Inhalt sagt sie nichts, denn sie arbeitet auf der Ebene der Leitung, eine Schicht unterhalb des Gesprächs.

Damit steht der Befund. Drei Anbieter, drei verschiedene Antworten, und keine davon ist eine Festlegung: Einer schickt die Abschrift, einer stellt es frei, einer schweigt. Was ein Mensch bei einer Übergabe sieht, entscheidet also der Bauende, und niemand nimmt ihm diese Entscheidung ab.

Der Kanal entscheidet dabei mit:

The implementation for handing off to a human from the front end will depend on which channel you’re using. (externe Seite, legacy-docs-oss.rasa.com)

Was eine Abschrift verliert

Angenommen, die Abschrift geht mit. Dann ist noch nicht viel gewonnen, denn was in Kapitel 02 über die Kette steht, gilt hier ein zweites Mal: Die Spracherkennung, englisch Speech-to-Text und abgekürzt STT, liefert Wörter. Den Tonfall nimmt sie nicht mit. Wer einem Menschen eine Abschrift übergibt, übergibt den Inhalt ohne die Art, in der er gesagt wurde.

Für eine Eskalation ist das die falsche Auswahl. Ein Gespräch, das an einen Menschen übergeben wird, ist häufig eines, das schwierig geworden ist, und die Information darüber steckt eben nicht im Wortlaut. Wer eine Abschrift liest, sieht einen sachlichen Verlauf, während der Anrufer die letzten fünf Minuten verärgert war.

Ein durchgehendes Sprachmodell könnte das mitgeben, denn es hat den Ton gehört. Eine Zusammenfassung mit einer Zeile über die Stimmung wäre technisch möglich. Sie wäre allerdings die Einschätzung eines Modells über einen Menschen, und wer sie einem Mitarbeiter vorlegt, sollte wissen, dass er das tut.

Was der Mensch außerdem nicht sieht

Ein zweiter Teil des Zusammenhangs steht in keiner Abschrift: was das System bereits ausgelöst hat. Dieselbe Lücke trifft die Auswertung nach dem Gespräch, und was sich dagegen aufzeichnen lässt, steht in Kapitel 12.

Kapitel 06 beschreibt, dass ein laufender Tool Call in der Anwendung sitzt und ein Abbruch der Erzeugung ihn nicht anhält. Wer eine Buchung angestoßen hat und dann übergeben wird, hat die Buchung trotzdem angestoßen. Der Mensch, der übernimmt, erbt diesen Zustand, und er erbt ihn unsichtbar.

Daraus folgt eine Bauregel, die über die Technik der Weitergabe hinausgeht: Zum übergebenen Zusammenhang gehört die Liste dessen, was in diesem Gespräch schon geschehen ist. Sie herzustellen kostet fast nichts, weil die Anwendung diese Aufrufe selbst ausgeführt hat. Sie wegzulassen kostet den Menschen am anderen Ende die erste Minute.

Warum die Freigabe technisch anspruchsvoller ist als sie klingt

Die zweite Form von HITL, die Freigabe einer einzelnen Handlung, wirkt einfacher. Sie hat allerdings eine Bedingung, die der Werkzeugkasten von OpenAI offenlegt:

Tools declare when they need approval, run results surface pending approvals as interruptions, and RunState lets you serialize paused runs and resume them after decisions are made. (externe Seite, openai.github.io)

Der entscheidende Teil steht am Ende: Der Lauf lässt sich sichern und später fortsetzen. Ohne das müsste ein Mensch sofort antworten, und die Freigabe wäre auf die Dauer eines Gesprächs beschränkt.

Für ein Telefongespräch ist genau das der Regelfall. Niemand hält einen Anruf zehn Minuten offen, während jemand eine Freigabe prüft. Die Freigabe im Sprachkanal funktioniert deshalb nur für Entscheidungen, die in Sekunden fallen. Alles andere führt zurück zur Übergabe, oder zu einem Rückruf, und damit endet das Gespräch ohnehin.