Benchmark de modelos de conversação: GPT Realtime e Gemini respondem a quase todas as pausas

A cada pausa, um modelo de conversação decide se fala ou se espera. Os testes existentes avaliam a detecção de limites de fala, o cumprimento de regras ou estatísticas agregadas, mas não essa decisão em si. Os autores do preprint arXiv:2610.12802 a mediram diretamente. Eles colocaram seis sistemas de tempo real diante de 427 pausas e 482 finais de fala, extraídos de 176 conversas não ensaiadas do dataset Seamless Interaction. As APIs na nuvem (GPT Realtime, Gemini 3.1 Flash Live, Grok Voice) respondem a quase todas as pausas. Quem sabe ficar calado são, em geral, os modelos full-duplex Moshi e PersonaPlex.

Como o teste funciona

Cada sistema recebia o histórico da conversa até um ponto escolhido. Depois, o que ele gerava era comparado com o que a pessoa fez. As métricas são várias, e cada uma responde a uma pergunta diferente:

• se o modelo fala durante a pausa e com que rapidez;
• a latência, o tamanho e a formulação da resposta no final de uma fala;
• a capacidade de responder a uma pergunta sobre os 30–120 segundos anteriores da conversa.

A principal diferença em relação aos benchmarks habituais é que o referencial é o comportamento real do interlocutor. O teste não se baseia em uma regra abstrata do tipo "pausa maior que 700 ms significa que pode falar".

Quem entra na conversa, e quando

Os sistemas na nuvem respondem a quase todas as pausas, seja qual for o detector de fim de fala que usam. O detector influencia apenas a latência. Com detectores baseados em silêncio, ela fica em cerca de 1–4 segundos; com detecção semântica de fim de fala, em torno de 8 segundos. Assim, o fato de as palavras caírem dentro da pausa ou não depende só do tempo. O modelo não escolhe se vale a pena falar.

Os full-duplex Moshi e PersonaPlex se comportam de outro jeito. Só eles ficam em silêncio com regularidade, e só eles entram na conversa dentro do tempo de reação humana. Os sistemas na nuvem, além disso, dão respostas mais longas que as da própria pessoa.

O preço da boa educação: a memória

Nas perguntas sobre a conversa anterior, o quadro se inverte. Os sistemas na nuvem receberam o histórico como texto e lembram 41–60% dos fatos, segundo a avaliação do juiz Claude Opus 5.5. Na comparação estrita de palavras, o resultado é menor: 19–26%. Os modelos full-duplex ouvem o histórico como áudio e lembram 17–22% dos fatos pelo juiz e 12–15% pelo matcher estrito. Ou seja, o ritmo natural ainda é alcançado à custa da memória, e a memória dos sistemas na nuvem vem do fato de que eles não ouvem, e sim leem.

Também é preciso considerar as condições da comparação. Os formatos de entrada dos dois grupos de modelos são diferentes: texto em um caso, áudio no outro. Por isso, a diferença não pode ser atribuída inteiramente à arquitetura.

Os autores publicam os rótulos, os pontos de seleção, o ambiente de teste e cada saída dos modelos. Os resultados podem ser conferidos, e novos sistemas podem entrar na comparação.

Se você está construindo um assistente de voz sobre uma API na nuvem, não olhe só para a latência média. Verifique se o sistema sabe ficar calado numa pausa em que a pessoa está apenas pensando. O tipo de detector de fim de fala define um trade-off: 1–4 segundos com silêncio contra cerca de 8 s com detector semântico.

Se a memória da conversa é importante para o produto, por enquanto o histórico em texto é mais confiável. Se o ritmo é o mais importante, será preciso olhar para os modelos full-duplex e conviver com o resumo mais fraco do que foi dito antes. O dataset e o ambiente de teste do release servem para avaliar a sua própria combinação de componentes em pausas reais, e não em sintéticas.