Benchmark des modèles conversationnels : GPT Realtime et Gemini répondent à presque chaque pause

À chaque pause, un modèle conversationnel doit décider : parler ou attendre. Les tests existants évaluent la détection des fins de tour, le respect de règles ou des statistiques agrégées, mais pas cette décision elle-même. Les auteurs du preprint arXiv:2610.12802 l'ont mesurée directement. Ils ont soumis six systèmes temps réel à 427 pauses et 482 fins de tour de parole, tirées de 176 conversations non préparées du jeu de données Seamless Interaction. Les API cloud (GPT Realtime, Gemini 3.1 Flash Live, Grok Voice) répondent à presque chaque pause. Seuls les modèles full-duplex Moshi et PersonaPlex savent, pour l'essentiel, se taire.

Comment fonctionne le test

Chaque système recevait l'historique de la conversation jusqu'à un point choisi. Les auteurs comparaient ensuite ce qu'il générait avec ce qu'avait fait l'humain. Plusieurs métriques coexistent, chacune répondant à une question précise :

• le modèle parle-t-il pendant la pause, et à quelle vitesse ;
• la latence, la longueur et la formulation de la réponse en fin de tour ;
• la capacité à répondre à une question sur les 30 à 120 secondes précédentes de la conversation.

La principale différence avec les benchmarks habituels tient à la référence : c'est le comportement réel de l'interlocuteur. Le test ne s'appuie pas sur une règle abstraite du type « une pause de plus de 700 ms autorise à parler ».

Qui prend la parole, et quand

Les systèmes cloud répondent à presque chaque pause, quel que soit le détecteur de fin de tour qu'ils embarquent. Le détecteur n'influe que sur la latence. Elle est d'environ 1 à 4 secondes avec les détecteurs fondés sur le silence, et d'environ 8 secondes avec la détection sémantique de fin de tour. Autrement dit, que les mots tombent dans la pause ou non ne dépend que du timing. Le modèle ne choisit pas s'il faut parler.

Les modèles full-duplex Moshi et PersonaPlex se comportent différemment. Ce sont les seuls à rester régulièrement silencieux, et les seuls à intervenir dans un délai comparable à celui d'une réaction humaine. Les systèmes cloud, eux, répondent en outre plus longuement que l'humain.

Le prix des bonnes manières : la mémoire

Sur les questions portant sur la conversation passée, le tableau s'inverse. Les systèmes cloud ont reçu l'historique sous forme de texte et se rappellent 41 à 60 % des faits selon le juge Claude Opus 5.5. Avec un appariement strict des mots, le résultat est plus bas : 19 à 26 %. Les modèles full-duplex écoutent l'historique sous forme d'audio et se rappellent 17 à 22 % des faits selon le juge, et 12 à 15 % selon l'évaluateur strict. Le rythme naturel s'obtient donc, pour l'instant, au prix de la mémoire. Et la mémoire des systèmes cloud s'explique par le fait qu'ils n'écoutent pas du tout : ils lisent.

Il faut aussi tenir compte des conditions de la comparaison. Les formats d'entrée diffèrent d'un groupe de modèles à l'autre : du texte dans un cas, de l'audio dans l'autre. L'écart ne peut donc pas être attribué entièrement à l'architecture.

Les auteurs publient les annotations, les points de sélection, le banc d'essai et chaque sortie des modèles. Les résultats peuvent être revérifiés, et de nouveaux systèmes ajoutés à la comparaison.

Si vous construisez un assistant vocal sur une API cloud, ne vous arrêtez pas à la latence moyenne. Vérifiez si le système sait se taire pendant une pause où l'humain réfléchit simplement. Le type de détecteur de fin de tour fixe un compromis : 1 à 4 secondes avec le silence, contre environ 8 s avec un détecteur sémantique.

Si la mémoire de la conversation compte pour votre produit, un historique textuel reste pour l'instant plus fiable. Si c'est le rythme qui prime, il faudra se tourner vers les modèles full-duplex et accepter leur restitution plus faible du passé. Le jeu de données et le banc d'essai de cette publication permettent de tester votre propre chaîne sur de vraies pauses, et non sur des pauses synthétiques.