Was nach dem Gespräch übrig bleibt

Ein Anrufer legt auf. Was bleibt, ist ein Transkript, und das ist weniger, als man denkt.

Im Chatfenster sieht der Nutzer, was passiert. Ein Tool wird aufgerufen und zeigt sich als Kästchen, eine Suche läuft und nennt ihre Treffer, eine Prüfung schlägt an und schreibt es hin. Am Telefon sieht der Anrufer nichts. Zwischen seiner Frage und der Antwort liegen Sekunden, in denen mehrere Systeme miteinander gesprochen haben, und davon ist im Transkript keine Spur.

Deshalb zeichnen die Werkzeugkästen mehr auf als den Text. Der Begriff dafür ist der Trace, auf Deutsch Ablaufspur:

A trace captures the end-to-end record of model calls, tool calls, guardrails, and handoffs for one run.

Sie besteht aus Abschnitten, und jeder hat einen Anfang und ein Ende:

Spans represent operations that have a start and end time.

Damit hat man, was ein Transkript nicht hergibt: eine Reihenfolge mit Uhrzeiten.

Warum die Reihenfolge zählt

Ein Beispiel aus einem eigenen Projekt, einem Sprachagenten am Kiosk-Terminal. Ein Anrufer fragte nach einer Person, das System antwortete, es habe dazu nichts gefunden. Im Transkript sah das aus wie eine Wissenslücke: Frage gestellt, Antwort negativ, Datenbestand offenbar unvollständig.

Der Trace zeigte etwas anderes. Die Suchanfrage, die die Antwort geliefert hätte, lief nach der Absage. Das System hatte geantwortet, bevor es nachgesehen hatte.

Ein solcher Befund lässt sich aus einem Transkript nicht gewinnen, und aus einer Fehlerquote erst recht nicht. Er hängt an zwei Uhrzeiten.

Was von selbst mitläuft

Bei mindestens einem Werkzeugkasten ist die Aufzeichnung der Ausgangszustand:

Tracing is enabled by default.

Das ist bequem, und es hat eine Kehrseite, die in der Tiefe dieses Kapitels steht.

Ein einzelner Trace erklärt ein Gespräch. Für die Frage, ob ein Sprachagent seine Arbeit tut, braucht es viele, und dafür müssen die Daten irgendwo hin.

Rasa beschreibt den Weg und liefert die Auswertung ausdrücklich nicht mit:

The Analytics Pipeline in Rasa streams conversation data from your deployed assistant to a data warehouse of your choice.

Erfasst werden dabei Ereignisse, nicht Sätze: die Äußerungen des Nutzers, die Befehle, die das Modell daraus gebildet hat, der Zustand der Abläufe, die ausgelösten Handlungen. Aus diesen Ereignissen lassen sich Kennzahlen bilden, und der Hersteller ordnet sie in vier Gruppen, von der Nutzung bis zum geschäftlichen Ergebnis.

Die Kennzahl, die alle nennen

In der Gruppe mit dem geschäftlichen Bezug steht eine Größe, die in diesem Feld als Erfolgsmaß gilt. Der Hersteller definiert sie mit:

containment rate (how many conversations were fully automated vs. handed to a human)

Auf Deutsch: der Anteil der Gespräche, die ohne einen Menschen zu Ende gingen. Wer eine Hotline automatisiert, hat damit eine Zahl, die sich in Kosten umrechnen lässt.

Sie hat einen blinden Fleck, und der ist groß. Ein Gespräch ohne Übergabe kann gelöst oder abgebrochen sein. Der Anrufer, der eine Auskunft bekam und zufrieden auflegte, zählt genauso wie der, der aufgab und es später auf einem anderen Weg versuchte. Beide erscheinen als Erfolg.

Die Zahl misst also, was der Agent nicht abgegeben hat, und das ist etwas anderes als das, was er geleistet hat. Wann eine Übergabe überhaupt fällig ist und wer sie auslöst, steht in Kapitel 08.

Das ist ein Sonderfall einer allgemeineren Regel: Aus dem Ausbleiben einer Reaktion lässt sich nichts über ihre Qualität schließen. Wer nicht nachfragt, kann zufrieden oder gleichgültig sein, und die Daten unterscheiden das nicht.

Was eine Auswertung sieht und was nicht

Aus demselben Projekt zwei Beobachtungen, die zusammengehören.

Erstens erschienen in der Gesprächsübersicht Einträge mit null Zügen. Jemand hatte begonnen und nichts gesagt, oder etwas war schiefgegangen, bevor das erste Wort ankam. Die Kategorie war sichtbar. Gezählt wurde sie nie, es gibt in den Projektnotizen keine Zahl dazu.

Zweitens war in der Auswertungsansicht der Tool Call sichtbar und die Tool-Antwort nicht. An einer anderen Stelle fehlten die Tool-Protokolle ganz, woraus der Verdacht entstand, das Tool sei überhaupt nicht aufgerufen worden.

Beide Fälle zeigen dasselbe: Eine Auswertung ist eine Aussage über das, was aufgezeichnet wurde. Wo die Aufzeichnung eine Lücke hat, entsteht in der Auswertung eine plausible Zahl. Ein Loch wäre das bessere Ergebnis.

Bis hierher liest sich Aufzeichnung wie ein Gewinn. Sie ist auch eine Sammlung.

Was in einem Trace landet, sind die Ein- und Ausgaben der Modellaufrufe und der Tool Calls, also das, was der Anrufer gesagt hat, und das, was das System damit gemacht hat. Die Voreinstellung ist eindeutig:

By default, trace_include_sensitive_data is True.

Für einen Sprachagenten kommt eine zweite Ebene dazu, und die ist der eigentliche Punkt:

Audio spans include base64-encoded PCM data for input and output audio by default.

Aufgezeichnet wird dabei der Ton selbst, die Aufnahme der Stimme, ab Werk, ohne dass jemand eine Einstellung vorgenommen hätte. Abschalten lässt sich beides, und zwar getrennt: eine Einstellung für die Textinhalte, eine zweite eigens für das Audio.

seitlich verschiebbar

eigene Darstellung nach der Tracing-Dokumentation des OpenAI Agents SDK, Stand 07.08.2026

Wer das nicht tut, betreibt eine Stimmsammlung. Was eine Stimme über eine Person verrät und welche Pflichten daran hängen, steht in Kapitel 09.

Zwei Fragen vor der ersten Aufzeichnung

Wozu. Ein Trace, der einen Fehler erklären soll, braucht Zeitstempel, Reihenfolge und die Namen der beteiligten Schritte. Er braucht dafür nicht den Ton. Der Unterschied zwischen „ich will wissen, was schiefging“ und „ich hebe alles auf“ ist eine Einstellung, und sie steht standardmäßig auf der zweiten Variante.

Wie lange. Eine Aufzeichnung, die niemand ansieht, ist ein Bestand, der altert. Für Textinhalte ist das eine Aufbewahrungsfrage, für Stimmaufnahmen eine andere Größenordnung.

Der Kreis schließt sich

Ein Gespräch, das schiefging, ist der wertvollste Testfall, den ein Sprachagent haben kann. Er beschreibt einen Fehler, den jemand wirklich erlebt hat.

Der Weg dorthin führt über den Trace: Er zeigt, an welcher Stelle es schiefging, und daraus wird eine Erwartung, die ein Testlauf künftig prüft. Wie ein solcher Testfall aussieht und was er festhält, steht in Kapitel 10.

Damit ist der Bogen zu: prüfen, betreiben, auswerten, und aus dem Ausgewerteten entsteht die nächste Prüfung.

Aus dem eigenen Projekt lässt sich dazu sagen, wo dieser Kreis reißt. Die beobachteten Fehler der Erkennung wanderten dort in eine Testklasse und blieben geprüft. Die Fehler der Wissenssuche, die häufiger auftraten, wanderten in Notizen. Den Unterschied machte, wie leicht sich ein Testfall dafür schreiben ließ.

Was hier offen bleibt

Zur Wirksamkeit dieser Rückkopplung gibt es in den geprüften Quellen keine Messung. Keiner der Hersteller beziffert, wie viele Fehler ein solcher Kreislauf in welcher Zeit beseitigt.

Zur Aufbewahrung von Stimmaufnahmen aus Traces findet sich in der Dokumentation, auf die dieses Kapitel sich stützt, keine Angabe. Dass die Aufzeichnung abschaltbar ist, steht dort; wie lange sie sonst liegen bleibt, steht dort nicht.