In diesem Beitrag
Cue Turn Detection: Telefonnummern, Benchmarks und Grenzen
Eine Telefonnummer ist kein Satz. Jemand nennt ein paar Ziffern, überlegt kurz und spricht weiter. Ein KI-Telefonassistent, der diese Pause als Gesprächsende interpretiert, kann die Nummer verlieren, noch bevor sein Sprachmodell sinnvoll zum Einsatz kommt.
Cue v1 ist ein Turn-Detection-System mit offenen Modellgewichten von Pype AI. Es entscheidet, ob ein Anrufer fertig gesprochen hat und ob er den Assistenten unterbrechen möchte. Die veröffentlichte Auswertung kombiniert ein feinabgestimmtes Gemma-4-E4B-Modell für Textentscheidungen mit dem Audioscore von Pipecats Smart Turn v3.2. Die Cue-Gewichte enthalten nur die Textkomponente, nicht die gesamte Sprachpipeline. Das stellt die Modellbeschreibung von Pype klar.
Interessant ist das für strukturierte Gespräche, besonders beim Erfassen von Telefonnummern. Für ein Unternehmen zählt aber mehr: Erfasst der Assistent die richtige, bestätigte Nummer, ohne dem Anrufer ins Wort zu fallen?
Was hat Pype mit Cue v1 veröffentlicht?
Laut Veröffentlichungsdaten von Pype erschien Cue 1.0.0 am 12. Oktober 2026. Dieser Artikel wurde am 15. Oktober 2026 geprüft. Cue stammt von Pype, nicht von Wavect.
Der Ankündigungsbeitrag mit Demonstration zeigt Pausen beim Diktieren von Telefonnummern und thematisiert mehrsprachige Gespräche. Das erklärt das Problem anschaulich, misst aber nicht kontrolliert die Erfassungsgenauigkeit. Dieser Artikel analysiert veröffentlichte Unterlagen und schlägt einen Prüfplan vor. Wir haben weder einen Cue-Produktivbetrieb durchgeführt noch die Inferenzbenchmarks unabhängig reproduziert.
Cue liegt zwischen dem Erkennen von Wörtern und der Entscheidung zu antworten. Spracherkennung, Rufnummernprüfung, Sprachausgabe und das Speichern des Kundendatensatzes bleiben eigenständige Aufgaben. Die angrenzenden Komponenten behandeln unser Review zu Streaming-Spracherkennung und unser Phonely-Alma-Review für Telefonagenten.
Warum unterbrechen KI-Telefonassistenten beim Diktieren von Nummern?
Ein beispielhafter Gesprächsverlauf:
Assistent: „Unter welcher Nummer können wir Sie zurückrufen?“
Anrufer: „Plus vier drei ...“
Assistent: „Danke. Und Ihre E-Mail-Adresse?“
Anrufer: „Ich bin noch nicht fertig.“
Dafür muss die Transkription nicht falsch sein. Das System kann die Ziffern korrekt erkannt und trotzdem den Redebeitrag zu früh beendet haben.
Voice Activity Detection, kurz VAD, erkennt, ob gesprochen wird. Automatic Speech Recognition, kurz ASR, wandelt Sprache in Text um. End-of-Turn Detection entscheidet, ob der Redebeitrag abgeschlossen ist. Barge-in Handling regelt, was passiert, wenn der Anrufer während der Assistentenantwort spricht. Diese Aufgaben gehören nicht in einen einzigen pauschalen Stille-Timer. Die LiveKit-Dokumentation zur Gesprächssteuerung erläutert ihr Zusammenspiel.
Ein längerer Timeout schützt Denkpausen, verzögert aber auch tatsächlich vollständige Antworten. Werden Unterbrechungen abgeschaltet, sinken womöglich falsche Abbrüche. Dafür können Anrufer Fehler nicht mehr rechtzeitig korrigieren. Sinnvoll ist eine Unterscheidung zwischen Zögern, Abschluss, Zuhörsignal und Einwand.
Cue ist nicht das erste Modell für diese Aufgabe. LiveKit beschrieb bereits im Dezember 2025 Verbesserungen für strukturierte Angaben und mehrsprachige Sprecherwechsel, darunter Telefonnummern. Entscheidend ist, ob Cues nachvollziehbare Kombination zum eigenen Ablauf passt, nicht ob das Problem zuvor unbekannt war.
Wie verbindet Cue Gesprächskontext und Audio?
Das Cue-Repository beschreibt zwei Entscheidungen. Bei einer Pause erhält die Textkomponente Gesprächskontext und bewertet vier Zustände. Während der Assistent spricht, unterscheidet ein weiterer Prompt zwischen einer echten Unterbrechung und einem Zuhörsignal.
| Entscheidung | Zustand | Beabsichtigte Bedeutung |
|---|---|---|
| Anrufer pausiert | DONE | Der Redebeitrag ist vollständig. |
| Anrufer pausiert | LIKELY_DONE | Wahrscheinlich vollständig, aber nicht eindeutig. |
| Anrufer pausiert | MID_THOUGHT | Satz oder strukturierte Antwort sind noch unvollständig. |
| Anrufer pausiert | HOLDING | Der Sprecher braucht Zeit zum Nachdenken. |
| Anrufer spricht gleichzeitig | STOP | Für Korrektur, Frage oder Einwand anhalten. |
| Anrufer spricht gleichzeitig | CONTINUE | Ein Zuhörsignal erfordert keinen Abbruch. |
Pipecats Smart-Turn-Modell untersucht separat die Audiowellenform. Es ist ein audiobasierter semantischer Turn-Detektor, nicht bloß ein Timer. Cue ergänzt expliziten Textkontext, etwa die zuvor gestellte Frage und bereits genannte Zifferngruppen.
Die veröffentlichte Kombination für Anrufer-Agenten-Gespräche lautet:
text_end = P(DONE) + P(LIKELY_DONE)
combined_end_score = text_end * sqrt(audio_end_score)
Ein Schwellenwert entscheidet anschließend über das Gesprächsende. Dieser kombinierte Score beweist weder die Vollständigkeit noch die Richtigkeit einer Telefonnummer. Durch die Formel wird er auch nicht automatisch zu einer kalibrierten Wahrscheinlichkeit für den Produktivbetrieb.
Zwei Details im Quellcode des Cue-Clients sind wichtig. Das Modell erzeugt ein Antworttoken und liest die Log-Wahrscheinlichkeiten der Optionen aus, statt einen Absatz zu schreiben. Fehlen diese Werte, kann der Client auf den ausgegebenen Buchstaben zurückfallen und ihm die gesamte Wahrscheinlichkeitsmasse zuweisen. Eine erfolgreiche HTTP-Anfrage kann damit eine veränderte Bewertungslogik verdecken.
Prüft deshalb die unverarbeitete Serverantwort, nicht nur das zurückgegebene Dictionary. Außerdem kombiniert with_voice(...) lediglich übergebene Scores. Die Funktion lädt weder Smart Turn noch verarbeitet sie Mikrofon-Audio. Der separate Helfer wait(...) verwendet eine andere Wartezeitstrategie und entspricht nicht der Schwellenwertlogik des kombinierten Benchmarks.
Cue, Smart Turn und LiveKit im Benchmark
Pype berichtet die folgenden Werte mit LiveKits eot-bench. Es handelt sich um Messungen des Herausgebers, nicht um einen Wavect-Benchmark oder eine unabhängig bestätigte Ranglistenempfehlung.
| System | Verzögerung bis zur Gesprächsende-Entscheidung bei 5 % Fehlunterbrechungsbudget | Fehlunterbrechungen bei 600 ms Verzögerungsbudget |
|---|---|---|
| LiveKit turn-detector v1, gehostet | 543 ms | 4,5 % |
| Baton v1 | 577 ms | 4,8 % |
| Soniox stt-rt-preview | 647 ms | 5,5 % |
| Cue v1, Text plus Smart Turn v3.2 | 719 ms | 7,5 % |
| Cue-Textkomponente allein | 750 ms | 7,8 % |
| Smart Turn v3.2 allein | 1.051 ms | 14,8 % |
Quelle: Pypes veröffentlichte Ergebnisse und Einschränkungen, Englisch, 400 Anruferbeiträge. Die Spalten bilden getrennt abgestimmte Betriebspunkte ab, nicht zwei Kennzahlen derselben unveränderten Produktivkonfiguration.
Beim 5-Prozent-Budget entscheidet Cue laut Tabelle 332 ms früher als Smart Turn, aber 176 ms später als das gehostete LiveKit-Modell. Das sind Rechenergebnisse aus diesen Messwerten, keine Zusagen für Kundengespräche. „Hier besser als Smart Turn“ ist belegt. „Bester Turn-Detektor“ nicht.
Die eot-bench-Methodik misst den Entscheidungszeitpunkt nach dem tatsächlichen Ende des Redebeitrags. Sie misst weder GPU-Inferenzzeit noch die gesamte Wartezeit bis zur hörbaren Antwort. Standardmäßig wird eine Transkriptverzögerung von 500 ms angenommen. Schwellenwerte, minimale Aktionsverzögerungen und Timeouts werden systematisch variiert.
Auch bei der Trennung von Entwicklung und Test ist Genauigkeit nötig. Laut Pype wurde das Modell nicht auf Benchmark-Gesprächen trainiert. Allerdings dienten 150 englische Benchmark-Beiträge zur Entwicklung von Prompt und Kombinationsformel. Die Haupttabelle umfasst alle 400 Beiträge. Sie vollständig als unangetasteten Testsatz zu bezeichnen, wäre zu weitgehend.
Funktioniert Cue auf Deutsch, Chinesisch und bei Sprachwechseln gleich gut?
Nein. Mehrsprachige Evaluation ist ein Anhaltspunkt, keine Garantie für jede Sprache, jeden Akzent oder jeden Sprachwechsel. Pype evaluiert 14 Sprachen: Arabisch, Chinesisch, Niederländisch, Englisch, Französisch, Deutsch, Hindi, Indonesisch, Italienisch, Japanisch, Koreanisch, Portugiesisch, Spanisch und Türkisch.
| Sprache | Cue-Verzögerung bei 5 % Fehlunterbrechungsbudget | Veröffentlichter Rang für Sprache und Betriebspunkt |
|---|---|---|
| Englisch | 719 ms | 4 von 13 |
| Deutsch | 786 ms | 3 von 11 |
| Spanisch | 792 ms | 2 von 11 |
| Chinesisch | 838 ms | 2 von 9 |
| Portugiesisch | 681 ms | 1 von 11 |
| Arabisch | 815 ms | 6 von 9 |
Das sind ausgewählte Zeilen derselben Pype-Auswertung. Platz eins für Portugiesisch gilt für diesen Betriebspunkt, nicht für jede Kennzahl. Außerdem werden je Sprache unterschiedlich viele Systeme verglichen.
Der englische Prompt bleibt gleich. Die Vorverarbeitung ist jedoch nicht vollständig identisch: Bei Sprachen mit häufig fehlender Interpunktion neutralisiert Pype das Merkmal zum Transkriptende. Der öffentliche eot-bench-Datensatz enthält Mensch-Agent-Gesprächsbeiträge mit Audio- und Textkontext. Er ist kein spezieller Test zur mehrsprachigen Telefonnummernerfassung.
Ein österreichisches Unternehmen sollte mit den tatsächlichen Akzenten, Zifferngruppierungen und Wechseln ins Englische seiner Anrufer testen. Verwendet die Ausgabe der produktiven Spracherkennung, keine manuell korrigierten Transkripte. Wir fanden keinen veröffentlichten Cue-Nachweis für die Genauigkeit von Sprachwechseln innerhalb eines Anrufs oder für exakt erfasste Telefonnummern.
Erkennt Cue den Unterschied zwischen „okay“ und „eigentlich nein“?
Beim Vorlesen der Nummer ist diese Unterscheidung entscheidend. „Okay“ kann lediglich „Ich höre zu“ heißen. Ein kurzes „Nein“ kann dagegen die Nummer ungültig machen, die der Assistent gerade speichern will.
Pype nennt 98,9 % Genauigkeit für STOP gegenüber CONTINUE auf 90 zurückgehaltenen synthetischen Fragen. Das sind keine 98,9 % Zuverlässigkeit in mehrsprachigen Produktivgesprächen. Die Ergebnisse nennen auch einen Fehlerfall: „hmm, actually no“ kann als CONTINUE gelten, bis weitere Informationen eintreffen.
Für das Training wurden 310 von einem LLM geschriebene Gespräche verwendet. Pype veröffentlicht eine Trainingsspezifikation und Skripte, aber nicht die Gespräche selbst. Offene Gewichte erleichtern Betrieb und Untersuchung. Sie machen nicht automatisch jede Trainingsaussage mit den veröffentlichten Materialien reproduzierbar.
Unsere Empfehlung: Korrekturen als eigenständige Sicherheitsbedingung im Erfassungsablauf behandeln. Mit neuen Wörtern erneut entscheiden, einen ausstehenden Speichervorgang bei einem erkannten Einwand aussetzen und prüfen, ob STOP tatsächlich gepufferte Sprachausgabe beendet. Ein korrekter Klassifikator stoppt kein Audio, das die Telefonieschicht weiter abspielt.
Wie sollte ein Ablauf zur Telefonnummernerfassung Cue einsetzen?
Cue entscheidet über Zuhören und Sprechen. Die Anwendung entscheidet, was gespeichert werden darf. Diese Trennung empfehlen wir unabhängig vom konkreten Turn-Detektor.
Zuerst muss die begonnene Nummer über Pausen hinweg erhalten bleiben. Die Frage des Assistenten und frühere Zifferngruppen gehören zum Kontext. Überschreibt den Entwurf nicht bei jedem ASR-Fragment. Eine verspätete Endpunktentscheidung darf auch keine neuere Transkriptversion abschließen.
Danach werden gesprochene Ziffern verarbeitet und länderspezifisch normalisiert. Eine geeignete Rufnummernbibliothek prüft plausibles Format und Länge. Eine globale Zehn-Ziffern-Regel ist ungeeignet. Selbst ein gültiges Format beweist nicht, dass die Nummer dem Anrufer gehört oder von ihm so gemeint war.
Anschließend wird die normalisierte Nummer verständlich vorgelesen. Vor dem Speichern ist eine ausdrückliche, zum Ablauf passende Bestätigung erforderlich. Ein Zuhörgeräusch ist keine Freigabe für einen Feldeintrag. Eine Korrektur ersetzt den betroffenen Entwurf und macht die vorige Bestätigung ungültig.
Erst dann wird der bestätigte Wert gespeichert. Wiederholte Anfragen dürfen bei Timeouts keine doppelten Datensätze erzeugen. Bei mehrfach gescheiterter Erfassung braucht es eine Tastatureingabe am Telefon, einen sicheren Texteingabekanal oder menschliche Hilfe. Speichert Audio und Transkripte sparsam, statt echte Rufnummern für bequemes Debugging überall zu protokollieren.
Das ist unser vorgeschlagenes Kontrolldesign, keine von Cue mitgelieferte Funktion. Sein Ergebnis ist ein richtiges, bestätigtes Datenfeld, nicht nur eine schnellere Entscheidung über eine Pause.
Wie lässt sich Cue lokal prüfen, ohne Demo und Integration zu verwechseln?
Pype stellt eine GGUF-Datei und einen LoRA-Adapter bereit. Der Lizenzhinweis der Veröffentlichung nennt Apache-2.0 für Gewichte, Adapter, Prompts und Dokumentation von Cue. Für die separate Smart-Turn-Abhängigkeit gilt BSD-2-Clause.
Ein technischer Funktionstest benötigt eine Python-Umgebung und einen GPU-fähigen llama-server-Build mit Gemma-4-Unterstützung. Dieses Shell-Beispiel für macOS/Linux fixiert den geprüften Client-Quellstand. Es ist keine vollständig versionsfixierte Produktivumgebung und wurde für dieses Review nicht ausgeführt.
git clone https://github.com/PYPE-AI-MAIN/cue-v1.git
cd cue-v1
git checkout 7919e712801e4b93f8de4dd1577fd908510005db
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -e . huggingface_hub
hf download Pype/cue-v1 cue-v1-q8_0.gguf --local-dir models
llama-server -m models/cue-v1-q8_0.gguf -c 8192 -np 4 -ngl 999 \
--jinja --host 127.0.0.1 --port 8090
Die Hugging-Face-CLI-Dokumentation beschreibt hf download und die Option --revision. Erfasst Modellrevision und Datei-Prüfsumme und fixiert beide vor einem kontrollierten Vergleich. Für einen lokalen Test sollte der llama.cpp-Server nur über Loopback erreichbar sein. Ein ungeschützter Inferenzport gehört nicht ins öffentliche Internet.
In einem zweiten Terminal ins Repository wechseln, dieselbe Umgebung aktivieren und python examples/quickstart.py ausführen. Das prüft die Textentscheidungsschnittstelle. Für das veröffentlichte kombinierte System fehlen noch Smart Turn v3.2, zeitlich abgestimmte Audio- und Transkripteingaben sowie die eigene Schwellenwertlogik. Vor echten Anrufen braucht es außerdem Antwortfristen, die Ablehnung veralteter Ergebnisse und eine begrenzte Rückfallstrategie.
Wie viele Anrufe schafft eine GPU?
Entscheidungen pro Sekunde sind nicht gleichzeitige Anrufe. Pypes T4-Messungen nennen ungefähr 13 Entscheidungen pro Sekunde. Der Median steigt von 79 ms bei einer laufenden Anfrage auf 364 ms bei vier und 1.220 ms bei sechzehn. Das misst den Inferenzbetrieb, anders als die vorherige Endpointing-Tabelle.
Pypes Kapazitätsschätzung unterstellt etwa sechs Entscheidungen je Anruferbeitrag und sechs Beiträge pro Minute. Daraus folgen 0,6 Entscheidungen pro Sekunde und Anruf. Zwanzig aktive Anrufe benötigen durchschnittlich zwölf Entscheidungen pro Sekunde und liegen damit bereits nahe am angegebenen Durchsatz.
Diese Rechnung belegt nicht, dass zwanzig Anrufer gleichzeitig pausieren können und jede Entscheidung unter 200 ms vorliegt. Prüft Lastspitzen, nicht zwischengespeicherte Prompts und die tatsächliche Promptlänge. Maßgeblich für die Zulassungsgrenze sind hohe Latenzperzentile, nicht nur mittlere Auslastung.
Die ungefähr 0,0005 US-Dollar pro Gesprächsminute des Herausgebers sind eine GPU-Umlage unter seinen Annahmen, kein Komplettpreis für einen Sprachagenten. ASR, TTS, Telefonie, Ablaufsteuerung, Monitoring, freie Kapazität und Betreuung kommen hinzu. Vergleicht deshalb die Kosten pro abgenommener KI-Aktion.
Welche Abnahmetests braucht die Telefonnummernerfassung?
Die folgende Matrix ist ein Prüfvorschlag, kein nachgewiesenes Cue-Ergebnis. Erstellt freigegebene oder synthetische Testfälle für jede unterstützte Sprache. Haltet zusätzliche Fälle zur Abstimmung getrennt.
| Test | Variation | Erwartetes Verhalten |
|---|---|---|
| 1. Zifferngruppen | Kurze und lange Pausen zwischen Gruppen | Keine verfrühte Antwort, keine verlorene Gruppe. |
| 2. Nummernformate | Landesvorwahl, führende Null, Durchwahl | Richtig normalisieren, keine Ziffern erfinden. |
| 3. Gesprochene Formen | „Doppelt“, Zahlengruppen, Wörter oder Ziffern | Dieselbe beabsichtigte normalisierte Nummer. |
| 4. Sprachwechsel | Wechsel innerhalb derselben Nummer | Vollständige Erfassung oder klare Rückfrage. |
| 5. ASR-Revision | Neuere Transkription ändert eine Ziffer | Veraltete Ergebnisse bestätigen keinen alten Wert. |
| 6. Korrektur | Nach einer Pause wird eine Gruppe ersetzt | Entwurf aktualisieren und neu bestätigen. |
| 7. Zuhörsignal | „Okay“ während des Vorlesens | Keine versehentliche Bestätigung oder unnötiger Neustart. |
| 8. Kurzer Einwand | „Nein“ oder „eigentlich nein“ beim Vorlesen | Audio abbrechen und Speichern aussetzen. |
| 9. Hintergrundsprache | Andere Person, Geräusch, Echo | Keine unbegründete Feldänderung oder Bestätigung. |
| 10. Lange Stille | Nachdenken oder Verbindungsabbruch | Begrenzte Wartezeit und verständliche Fortsetzung. |
| 11. Lastspitze | Viele Anrufe pausieren gleichzeitig | Antwortfristen und sichere Rückfallstrategie einhalten. |
| 12. Schreibfehler | CRM-Timeout nach der Bestätigung | Zustand abgleichen, keine doppelten Datensätze. |
Legt die Hauptkennzahl vor dem Test fest: Erfolg beim Erstversuch = Versuche mit exakt beabsichtigter, ausdrücklich bestätigter Nummer ohne Neustart des Diktierens / alle geeigneten Erstversuche. Berichtet späteren Erfassungserfolg, falsche Speichervorgänge, Unterbrechungen, Korrekturschleifen und Abbrüche separat.
Wertet nach Sprache und Gesprächsbedingung aus. Messt die Entscheidung nach Gesprächsende, die hörbare Antwort und die Zeit vom Einwand bis zum Audiostopp getrennt, jeweils einschließlich P95. Vergleicht Bestandssystem, Cue nur mit Text und Cue als Kombination nach derselben Abnahmeregel. Schwellenwerte werden auf Entwicklungsfällen festgelegt und für den zurückgehaltenen Test eingefroren.
Wann lohnt sich Cue?
Cue ist einen Versuch wert, wenn strukturierte Antworten zu früh abgeschnitten werden, mehrsprachige Anrufer relevant sind und das Team eine kombinierte Text-Audio-Entscheidungspipeline betreiben kann. Weniger überzeugend ist ein ungeprüfter Austausch in einem funktionierenden System oder der Versuch, mangelhafte Spracherkennung damit zu umgehen.
Wavects KI-Integration und Engineering verbindet solche Komponenten zu kontrollierten Geschäftsabläufen. Die Twinsoft-AI-Fallstudie zeigt angrenzende Umsetzungserfahrung, keinen Cue-Einsatz. Unsere QA-Checkliste vor dem Softwarelaunch behandelt die umfassendere Freigabe.
Bringt ein bereinigtes Beispiel einer gescheiterten Nummernerfassung und das gewünschte Kundendatenformat mit, um euren Sprachagenten-Ablauf mit Wavect zu besprechen. Das Ziel ist nicht ein Modell, das früher spricht. Es ist ein Assistent, der lange genug zuhört, Korrekturen zulässt und das richtige Ergebnis speichert.