Benchmark de modelos conversacionales: GPT Realtime y Gemini responden en casi todas las pausas

En cada pausa, un modelo conversacional decide si habla o espera. Las pruebas existentes evalúan la detección de límites de turno, el cumplimiento de reglas o estadísticas agregadas, pero no esa decisión en sí. Los autores del preprint arXiv:2610.12802 la midieron de forma directa. Sometieron a seis sistemas en tiempo real a 427 pausas y 482 finales de turno extraídos de 176 conversaciones no preparadas del dataset Seamless Interaction. Las API en la nube (GPT Realtime, Gemini 3.1 Flash Live, Grok Voice) responden en casi todas las pausas. Quienes saben callar son, sobre todo, los modelos full-duplex Moshi y PersonaPlex.

Cómo funciona la prueba

A cada sistema se le daba el historial de la conversación hasta un punto elegido. Después se comparaba lo que generaba con lo que había hecho la persona. Hay varias métricas y cada una responde a una pregunta distinta:

• si el modelo habla en la pausa y con qué rapidez;
• la latencia, la longitud y la formulación de la respuesta al final de un turno;
• la capacidad de responder a una pregunta sobre los 30–120 segundos anteriores de conversación.

La principal diferencia con los benchmarks habituales es que el patrón de referencia es el comportamiento real del interlocutor. La prueba no se contrasta con una regla abstracta del tipo «una pausa de más de 700 ms significa que se puede hablar».

Quién entra en la conversación y cuándo

Los sistemas en la nube responden en casi todas las pausas, sea cual sea el detector de fin de turno que lleven. Del detector depende solo la latencia: con detectores basados en silencio ronda 1–4 segundos y con detección semántica del fin de turno, unos 8 segundos. Es decir, que las palabras caigan dentro de la pausa o no depende únicamente del tiempo. El modelo no elige si conviene hablar.

Los modelos full-duplex Moshi y PersonaPlex se comportan de otro modo. Solo ellos permanecen en silencio con regularidad y solo ellos intervienen dentro del tiempo de reacción humano. Además, los sistemas en la nube dan respuestas más largas que las de la propia persona.

El precio de los buenos modales: la memoria

En las preguntas sobre la conversación pasada, el panorama se invierte. A los sistemas en la nube se les entregó el historial como texto, y recuerdan entre el 41% y el 60% de los hechos según la evaluación del juez Claude Opus 5.5.

Con una comparación estricta de palabras, el resultado es inferior: 19–26%. Los modelos full-duplex escuchan el historial como audio y recuerdan entre el 17% y el 22% de los hechos según el juez, y entre el 12% y el 15% según el comparador estricto. Todo indica que, por ahora, el ritmo natural se consigue a costa de la memoria, y que la memoria de los sistemas en la nube se logra porque no escuchan en absoluto: leen.

Hay que tener en cuenta también las condiciones de la comparación. Los formatos de entrada de cada grupo de modelos son distintos: texto en un caso y audio en el otro. Por eso la diferencia no puede atribuirse por completo a la arquitectura.

Los autores publican las etiquetas, los puntos de selección, el banco de pruebas y cada salida de los modelos. Los resultados pueden verificarse de nuevo y se pueden añadir a la comparación nuevos sistemas.

Si está construyendo un asistente de voz sobre una API en la nube, no se fije solo en la latencia media. Compruebe si el sistema sabe callar en una pausa en la que la persona simplemente está pensando. El tipo de detector de fin de turno impone un compromiso: 1–4 segundos con silencio frente a unos 8 s con detector semántico.

Si para el producto es importante la memoria de la conversación, por ahora es más fiable un historial en texto. Si lo importante es el ritmo, habrá que mirar los modelos full-duplex y aceptar que resumen peor el pasado. El dataset y el banco de pruebas de la publicación sirven para evaluar su propia combinación de componentes con pausas reales, y no sintéticas.