En este artículo
Cue Turn Detection: teléfonos, benchmarks y límites
Un número de teléfono no es una frase. Una persona dice varios dígitos, hace una pausa para recordar los siguientes y continúa. Un agente de voz que interpreta esa pausa como el final de la respuesta puede perder el número antes de que su modelo de lenguaje aporte nada útil.
Cue v1 es el sistema de detección de turnos con pesos abiertos de Pype AI. Decide si el interlocutor ha terminado y si está intentando interrumpir al agente. Su evaluación publicada combina un modelo textual Gemma 4 E4B ajustado para tomar decisiones con la puntuación de audio de Smart Turn v3.2, de Pipecat. Los pesos descargables de Cue contienen la parte textual, no toda la cadena de voz. La ficha del modelo de Pype aclara esta distinción.
La oportunidad está en gestionar mejor los tiempos durante conversaciones estructuradas, especialmente al recoger teléfonos. La pregunta empresarial es más exigente: ¿ayuda a obtener el número correcto y confirmado sin hablar por encima del cliente?
¿Qué ha publicado Pype con Cue v1?
El registro de la publicación fecha Cue 1.0.0 el 12 de octubre de 2026. Este análisis se revisó el 15 de octubre de 2026. Cue pertenece a Pype, no es un producto de Wavect.
El anuncio con demostración se centra en las pausas al dictar teléfonos y en las conversaciones multilingües. Explica bien el problema, pero no mide de forma controlada la exactitud de la captura. Este artículo analiza materiales publicados y propone una evaluación. No hemos desplegado Cue en producción ni reproducido de forma independiente sus benchmarks de inferencia.
Cue se sitúa entre reconocer las palabras y decidir cuándo responder. No sustituye la transcripción, la validación del teléfono, la síntesis de voz ni el sistema que guarda el registro del cliente. Son decisiones distintas, tratadas en nuestro análisis de ASR en streaming y en el análisis de Phonely Alma para agentes telefónicos.
¿Por qué los agentes de voz interrumpen al dictar teléfonos?
Un ejemplo ilustrativo:
Agente: «¿A qué número podemos devolverle la llamada?»
Cliente: «Más cuatro tres ...»
Agente: «Gracias. ¿Y su correo electrónico?»
Cliente: «Todavía no he terminado».
No tiene por qué haber fallado la transcripción. Los dígitos pueden ser correctos y, aun así, el sistema haber cerrado el turno demasiado pronto.
La detección de actividad vocal, o VAD, identifica si hay habla. El reconocimiento automático del habla, o ASR, la transcribe. La detección de final de turno determina si la persona ha completado su intervención. La gestión de interrupciones, o barge-in, decide qué hacer cuando el cliente habla mientras responde el agente. No conviene reducir estas responsabilidades a un único temporizador de silencio. La documentación de LiveKit sobre turnos explica cómo interactúan.
Aumentar el tiempo de espera protege las pausas, pero también retrasa respuestas que sí estaban completas. Desactivar las interrupciones evita algunas falsas alarmas, pero impide corregir al agente. El sistema debe distinguir vacilación, finalización, señal de escucha y objeción.
Cue no es el primero en abordar esta tarea. LiveKit documentó mejoras multilingües para datos estructurados, incluidos teléfonos, en diciembre de 2025. Lo relevante es si la combinación inspeccionable de Cue encaja mejor con el proceso, no si nadie había detectado antes el problema.
¿Cómo combina Cue el contexto y el audio?
El repositorio de Cue describe dos decisiones. Durante una pausa, el componente textual recibe contexto y asigna puntuaciones a cuatro estados. Cuando habla el agente, otro prompt distingue una interrupción real de una señal de escucha.
| Decisión | Estado | Interpretación prevista |
|---|---|---|
| El cliente hace una pausa | DONE | La intervención está completa. |
| El cliente hace una pausa | LIKELY_DONE | Probablemente ha terminado, con cierta incertidumbre. |
| El cliente hace una pausa | MID_THOUGHT | La frase o respuesta estructurada está incompleta. |
| El cliente hace una pausa | HOLDING | La persona necesita tiempo para pensar. |
| El cliente habla sobre el agente | STOP | Detenerse ante una corrección, petición o interrupción. |
| El cliente habla sobre el agente | CONTINUE | La señal de escucha no exige detenerse. |
El modelo Smart Turn de Pipecat analiza por separado la onda de audio. Es un detector semántico basado en audio, no un simple temporizador. Cue incorpora contexto textual explícito, como la pregunta del agente y los grupos de dígitos ya aportados.
La combinación publicada para conversaciones entre cliente y agente es:
text_end = P(DONE) + P(LIKELY_DONE)
combined_end_score = text_end * sqrt(audio_end_score)
Un umbral determina después si se cierra el turno. Esta puntuación no demuestra que el número esté completo ni que sea correcto. La fórmula tampoco la convierte automáticamente en una probabilidad calibrada para llamadas reales.
Hay dos detalles importantes en el código del cliente de Cue. El modelo produce un único token y utiliza las probabilidades logarítmicas de las opciones, en vez de redactar un párrafo. Pero, si faltan esas probabilidades, el cliente puede recurrir a la letra devuelta y asignarle toda la masa de probabilidad. Una respuesta HTTP correcta puede ocultar un cambio en el contrato de puntuación.
Comprobad la respuesta original del servidor, no solo que el helper devuelva un diccionario. Además, with_voice(...) únicamente combina puntuaciones suministradas. No carga Smart Turn ni procesa audio del micrófono. El helper separado wait(...) aplica otra política de espera; no es la política de umbrales del benchmark combinado.
Cue frente a Smart Turn y LiveKit: ¿qué dicen los benchmarks?
Pype publica los siguientes resultados obtenidos con eot-bench de LiveKit. Son mediciones del desarrollador, no un benchmark de Wavect ni una recomendación de clasificación verificada de forma independiente.
| Sistema | Retraso de detección con un presupuesto de falsos cortes del 5 % | Falsos cortes con un presupuesto de retraso de 600 ms |
|---|---|---|
| LiveKit turn-detector v1, alojado | 543 ms | 4,5 % |
| Baton v1 | 577 ms | 4,8 % |
| Soniox stt-rt-preview | 647 ms | 5,5 % |
| Cue v1, texto más Smart Turn v3.2 | 719 ms | 7,5 % |
| Componente textual de Cue | 750 ms | 7,8 % |
| Smart Turn v3.2 por separado | 1.051 ms | 14,8 % |
Fuente: resultados y limitaciones publicados por Pype, inglés, 400 turnos de clientes. Las columnas representan puntos de funcionamiento ajustados por separado, no dos mediciones de una misma configuración fija.
Con el presupuesto del 5 %, Cue decide 332 ms antes que Smart Turn, pero 176 ms después que el modelo alojado de LiveKit. Son diferencias calculadas a partir de esa tabla, no promesas para otras llamadas. «Supera aquí a Smart Turn» está respaldado. «Es el mejor detector» no.
La metodología de eot-bench mide cuándo decide la política después del final real del turno. No mide la inferencia en GPU ni toda la espera hasta que se oye la voz del agente. Su retraso de transcripción predeterminado es de 500 ms. Evalúa combinaciones de umbrales, demoras mínimas de actuación y tiempos máximos de espera.
También hay distintos niveles de separación entre desarrollo y prueba. Pype afirma que el ajuste del modelo no utilizó conversaciones del benchmark. Sin embargo, 150 turnos ingleses sirvieron para desarrollar el prompt y la fórmula de combinación. La tabla principal incluye los 400. Presentarla como un conjunto de prueba completamente intacto exageraría la evidencia.
¿Funciona igual en alemán, chino y llamadas con cambios de idioma?
No. Una evaluación multilingüe aporta evidencia, no garantiza resultados para cualquier idioma, acento o cambio de lengua. Pype evalúa 14 idiomas: árabe, chino, neerlandés, inglés, francés, alemán, hindi, indonesio, italiano, japonés, coreano, portugués, español y turco.
| Idioma | Retraso de Cue con presupuesto de falsos cortes del 5 % | Puesto publicado para ese idioma y presupuesto |
|---|---|---|
| Inglés | 719 ms | 4 de 13 |
| Alemán | 786 ms | 3 de 11 |
| Español | 792 ms | 2 de 11 |
| Chino | 838 ms | 2 de 9 |
| Portugués | 681 ms | 1 de 11 |
| Árabe | 815 ms | 6 de 9 |
Son filas seleccionadas de la misma evaluación de Pype. El primer puesto en portugués corresponde a ese punto de funcionamiento, no a todas las métricas. El número de sistemas comparados también cambia según el idioma.
Se emplea el mismo prompt inglés, pero el preprocesamiento no es totalmente idéntico: Pype neutraliza la señal de final de transcripción en idiomas donde suele faltar puntuación. El dataset público de eot-bench contiene turnos humano-agente con audio y contexto textual. No es una prueba específica de captura multilingüe de teléfonos.
Una empresa austríaca debería probar el alemán con los acentos, agrupaciones de dígitos y cambios al inglés habituales entre sus clientes. En cualquier mercado, usad la salida real del ASR de producción, no una transcripción corregida a mano. No encontramos resultados publicados de Cue que establezcan la exactitud al cambiar de idioma dentro de una llamada ni al capturar teléfonos completos.
¿Distingue Cue entre «vale» y «en realidad, no»?
La diferencia importa especialmente al leer el número para confirmarlo. «Vale» puede significar «estoy escuchando». Un «no» breve puede invalidar el dato que el agente está a punto de guardar.
Pype informa de un 98,9 % de precisión en STOP frente a CONTINUE sobre 90 preguntas sintéticas reservadas para prueba. No equivale a un 98,9 % de fiabilidad en llamadas multilingües reales. Los resultados también reconocen un fallo: «hmm, actually no» puede clasificarse como CONTINUE hasta que llega más información.
El entrenamiento utilizó 310 conversaciones escritas por un LLM. Pype publica una especificación de entrenamiento y scripts, pero no las conversaciones. Los pesos abiertos facilitan el despliegue y la inspección. No permiten reproducir automáticamente todas las afirmaciones sobre entrenamiento con los materiales disponibles.
Nuestra recomendación es tratar las correcciones como una condición de seguridad independiente. Reevaluad con las palabras nuevas, suspendiendo el guardado pendiente al detectar una objeción. Verificad además que STOP cancele realmente el audio en cola. Un clasificador correcto no detiene una respuesta que la capa de telefonía sigue reproduciendo.
¿Cómo debería utilizar Cue un proceso de captura de teléfonos?
Cue decide cuándo escuchar o hablar. La lógica de la aplicación decide qué se puede guardar. Recomendamos esta separación con cualquier detector de turnos.
Primero, conservad el número en construcción entre pausas. La pregunta y los grupos anteriores deben seguir disponibles. No sobrescribáis todo el borrador con cada fragmento del ASR. Una decisión tardía tampoco debe cerrar una revisión más reciente de la transcripción.
Después, interpretad los dígitos hablados y normalizad según el país. Una biblioteca adecuada de teléfonos puede comprobar formato y longitud plausibles. No impongáis diez dígitos como regla mundial. Un formato válido sigue sin demostrar que el teléfono pertenezca al cliente o que esos fueran los dígitos que quería comunicar.
A continuación, leed con claridad el número normalizado. Exigid una confirmación explícita, adecuada al proceso, antes de guardarlo. Un sonido de escucha no es una autorización para completar un campo. Las correcciones deben sustituir el borrador correspondiente e invalidar la confirmación anterior.
Por último, guardad solo el valor confirmado. Los reintentos tras un timeout no deben crear registros duplicados. Ofreced teclado telefónico, entrada de texto segura o asistencia humana cuando falle la captura repetidamente. Minimizad el audio y las transcripciones retenidos; no registréis teléfonos reales por todas partes para facilitar la depuración.
Este es nuestro diseño de control propuesto, no una función incluida en Cue. El resultado buscado es un campo correcto y confirmado, no simplemente menos retraso en la detección del turno.
¿Cómo evaluar Cue localmente sin confundir una demo con una integración?
Pype publica un archivo GGUF y un adaptador LoRA. El aviso de licencia de la publicación declara Apache-2.0 para los pesos, adaptador, prompts y documentación de Cue. La dependencia independiente Smart Turn utiliza BSD-2-Clause.
Una prueba técnica inicial requiere Python y un llama-server con soporte de GPU y Gemma 4. Este ejemplo de shell para macOS/Linux fija el código del cliente revisado. No fija todas las versiones de un entorno de producción y no se ha ejecutado para este análisis.
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
La guía de la CLI de Hugging Face documenta hf download y la opción --revision. Registrad la revisión y la suma de comprobación del archivo y fijad ambas antes de una comparación controlada. Mantened el servidor de llama.cpp en loopback durante la prueba local. No expongáis a internet un puerto de inferencia sin autenticación.
En otra terminal, entrad al repositorio, activad el mismo entorno y ejecutad python examples/quickstart.py. Esto ejercita la interfaz de decisión textual. Para evaluar el sistema combinado publicado todavía hacen falta Smart Turn v3.2, audio y transcripción sincronizados y una política de umbrales. Añadid plazos de respuesta, rechazo de resultados obsoletos y una alternativa con espera limitada antes de conectar llamadas reales.
¿Cuántas llamadas puede atender una GPU?
Decisiones por segundo no significa llamadas simultáneas. Las mediciones de Pype con una T4 rondan las 13 decisiones por segundo. La mediana sube de 79 ms con una solicitud en curso a 364 ms con cuatro y 1.220 ms con dieciséis. Esto mide la ejecución de inferencia, no el retraso de detección de la tabla anterior.
La estimación de capacidad de Pype supone unas seis decisiones por turno del cliente y seis turnos por minuto. Cada llamada necesitaría entonces 0,6 decisiones por segundo. Veinte llamadas activas requieren una media de doce decisiones por segundo, ya cerca del rendimiento publicado.
El cálculo no demuestra que veinte personas puedan pausar a la vez y recibir todas una decisión en menos de 200 ms. Evaluad ráfagas, fallos de caché y la longitud real del prompt. Fijad límites de admisión según los percentiles altos de latencia, no solo la utilización media.
Los aproximadamente 0,0005 dólares por minuto de llamada del desarrollador estiman la asignación de GPU bajo sus supuestos, no el precio completo de un agente. Sumad ASR, TTS, telefonía, orquestación, monitorización, capacidad ociosa y soporte antes de comparar el coste por acción de IA aceptada.
¿Qué debe incluir la prueba de aceptación de teléfonos?
La siguiente matriz es una propuesta de pruebas, no resultados conseguidos por Cue. Preparad ejemplos autorizados o sintéticos para cada idioma admitido y mantened separado el conjunto de ajuste.
| Prueba | Variación | Comportamiento requerido |
|---|---|---|
| 1. Grupos de dígitos | Pausas cortas y largas entre grupos | Sin respuesta prematura ni pérdida del grupo anterior. |
| 2. Formatos | Prefijo internacional, cero inicial, extensión | Normalización correcta sin inventar dígitos. |
| 3. Formas habladas | «Doble», números agrupados, palabras o cifras | El mismo valor normalizado previsto. |
| 4. Cambio de idioma | Cambio durante el mismo número | Captura completa o petición explícita de aclaración. |
| 5. Revisión del ASR | La última transcripción cambia un dígito | Un resultado obsoleto no confirma el valor anterior. |
| 6. Corrección | El cliente reemplaza un grupo tras una pausa | Borrador actualizado y nueva confirmación. |
| 7. Señal de escucha | «Vale» mientras se lee el número | Sin confirmación accidental ni reinicio innecesario. |
| 8. Objeción breve | «No» o «en realidad, no» durante la lectura | Cancelar audio y suspender el guardado. |
| 9. Voz de fondo | Otra persona, ruido o eco | Sin cambios ni confirmaciones injustificados. |
| 10. Silencio largo | El cliente piensa o pierde la conexión | Espera limitada y recuperación clara. |
| 11. Ráfaga de carga | Muchas llamadas pausan al mismo tiempo | Cumplir plazos y degradar de forma segura. |
| 12. Escritura fallida | Timeout del CRM después de confirmar | Reconciliar el estado sin duplicar registros. |
Definid la métrica principal antes de probar: éxito al primer intento = intentos que obtienen el número exacto previsto y explícitamente confirmado sin reiniciar el dictado / todos los primeros intentos elegibles. Informad por separado de captura final, guardados incorrectos, cortes al cliente, turnos de reparación y abandono.
Segmentad por idioma y condición de llamada. Medid por separado el retraso de detección, el de respuesta audible y el tiempo desde la objeción hasta detener el audio, incluyendo P95. Comparad el sistema actual, la parte textual de Cue y la combinación con la misma regla de aceptación. Ajustad umbrales en las llamadas de desarrollo y congeladlos para la prueba reservada.
¿Cuándo merece la pena adoptar Cue?
Cue merece una evaluación cuando las respuestas estructuradas se cortan, importa el comportamiento multilingüe y el equipo puede operar una cadena de decisiones textual y acústica. Es menos convincente como sustitución sin probar dentro de un sistema que funciona o como atajo para compensar una transcripción poco fiable.
El servicio de integración e ingeniería de IA de Wavect conecta componentes con procesos empresariales controlados. El caso Twinsoft AI aporta contexto de ejecución relacionado, no evidencia de una implementación de Cue. La lista de comprobación de QA antes del lanzamiento cubre la decisión de publicación más amplia.
Traed un ejemplo anonimizado de una captura fallida y el formato del registro deseado para hablar con Wavect sobre vuestro agente de voz. La meta no es un modelo que hable antes. Es un agente que escuche el tiempo necesario, acepte correcciones y guarde el resultado correcto.