Resumo Técnico: De Texto para Voz: Um Framework Reprodutível e Verificável para Avaliar Agentes LLM de Chamada de Ferramentas

Declaração do Problema

Embora os Modelos de Linguagem de Grande Escala (LLMs) tenham avançado significativamente na chamada de ferramentas e execução de funções em ambientes baseados em texto, benchmarks proeminentes (por exemplo, Confetti, When2Call, BFCL) permanecem apenas em texto. Isso cria uma lacuna para organizações que implantam agentes de voz, que devem escolher entre uma arquitetura em cascata (ASR $\rightarrow$ LLM de Texto) ou uma arquitetura omni-modal de ponta a ponta (Fala $\rightarrow$ Chamada de Ferramenta). Benchmarks de áudio existentes frequentemente exigem a construção de novos corpora a partir do zero com novos esquemas de ferramentas e rótulos de ouro, o que é custoso e limita a aplicabilidade a dados proprietários de empresas. Além disso, a confiabilidade de modelos omni-modais sob condições de áudio realistas e a degradação específica de desempenho introduzida pela modalidade de fala permanecem insuficientemente caracterizadas.

Metodologia

Os autores propõem um framework agnóstico ao conjunto de dados que converte benchmarks existentes de chamada de ferramentas baseados em texto em avaliações controladas de áudio, sem reanotar esquemas de ferramentas ou rótulos de ouro.

1. Pipeline de Conversão

O framework utiliza modelos de Texto para Voz (TTS) prontos para uso para gerar instâncias emparelhadas de texto–áudio:

• Modelos TTS: Três modelos foram utilizados: Gemini-2.5-Flash-TTS, Gemini-2.5-Pro-TTS e GPT-4o-Mini-TTS.
• Variação de Locutor: Vozes distintas para locutores masculinos e femininos foram selecionadas de cada provedor (por exemplo, Kore/Orus para Gemini, Coral/Ash para GPT).
• Injeção de Ruído: Ruído ambiental do conjunto de dados DEMAND foi injetado em várias Relações Sinal-Ruído (SNR: 5, 10, 15, 20 dB) para simular condições de implantação.
• Preservação: Os esquemas de ferramentas originais, os rótulos de ouro e os protocolos de avaliação são estritamente preservados a partir dos conjuntos de dados de texto fonte.

2. Protocolo de Avaliação

O framework avalia sete modelos omni-modais de quatro provedores (OpenAI, Google, Qwen, Microsoft) em dois conjuntos de dados:

• Confetti: Foca na seleção de funções e na precisão da extração de parâmetros (313 exemplos que exigem chamadas de ferramentas).
• When2Call: Foca na capacidade de tomada de decisão para determinar se uma chamada de ferramenta é necessária (300 exemplos).

A avaliação compara três condições:

1. Texto Limpo: Desempenho de base usando entradas de texto originais.
2. Voz Direta: Desempenho usando entradas de áudio geradas por TTS processadas por modelos omni-modais.
3. Cascata (ASR $\rightarrow$ Texto): Áudio transcrito por GPT-4o-Transcribe e passado para um LLM apenas de texto.

3. Análises Adicionais

• Decomposição de Erros: Falhas emparelhadas de texto–áudio são categorizadas em erros de decisão, erros de seleção de ferramenta, erros de esquema de argumento e erros de valor de argumento.
• Avaliação sem Referência: Protocolos de LLM como Juiz (usando GPT-5, Gemini-2.5-Pro e modelos Qwen3 de código aberto) são testados contra rótulos de ouro para avaliar a viabilidade para dados de produção que carecem de anotações.
• Teste de Estresse: Testes de reformulação de consultas baseados em ambiguidade foram conduzidos para medir a robustez a solicitações de usuário subespecificadas.

Principais Resultados

Dependência de Modelo e Tarefa

O desempenho é altamente dependente do modelo e da tarefa específicos, e não apenas da arquitetura:

• Confetti: Gemini-3.1-Flash-Live alcançou a maior pontuação (70,4%), seguido por Qwen3-Omni (60,4%).
• When2Call: GPT-Realtime-1.5 teve o melhor desempenho (71,9%), enquanto Gemini-3.1-Flash-Live caiu para o 4º lugar (63,4%).
• Lacuna Texto-para-Voz: A degradação de desempenho ao passar de texto para voz varia significativamente por modelo. No Confetti, a lacuna varia de 1,8 pontos (Qwen3-Omni) a 4,8 pontos (GPT-Realtime-1.5).

Comparação de Arquiteturas (Cascata vs. Omni)

• Gemini-3.1-Flash-Live: A arquitetura em cascata superou ligeiramente a voz direta (71,3% vs. 70,4%), sugerindo que ASR + LLM de texto forte pode recuperar o desempenho.
• GPT-Realtime-1.5 e Qwen3-Omni: A voz direta superou a cascata em 0,4 e 1,5 pontos, respectivamente.
• Conclusão: Nenhuma arquitetura domina uniformemente; a escolha ótima é específica ao modelo e à tarefa.

Análise de Erros

• Valores de Argumento: O modo de falha mais comum em erros induzidos por áudio são erros de valor de argumento (valores de campo incorretos ou incompletos), representando 57,2% das falhas para Gemini-3.1-Flash-Live e 54,3% para GPT-Realtime-1.5. Isso indica que os modelos frequentemente preservam a estrutura de chamada de ferramenta, mas interpretam mal o conteúdo da fala.
• Erros de Decisão: Erros de decisão significativos (30–37%) foram observados, indicando que a entrada de áudio altera decisões de alto nível de uso de ferramentas (por exemplo, se deve ou não chamar uma ferramenta).
• Específicos do When2Call: Os modelos geralmente tiveram mais dificuldade com casos de "sem chamada de ferramenta" do que com casos de "chamada de ferramenta", destacando uma dificuldade em saber quando não agir.

Avaliação e Escala

• Juízes LLM: Juízes LLM sem referência mostraram classificações de modelos estáveis em comparação com juízes com referência. Juízes Qwen3 de código aberto com $\ge$ 8B parâmetros alcançaram >80% de concordância com juízes proprietários, apoiando a avaliação que preserva a privacidade.
• Escala de Texto: No modo apenas de texto, a precisão escala com o tamanho do modelo (por exemplo, Qwen3 subindo de 26,6% em 0,6B para 70,7% em 32B). Modelos de texto menores (por exemplo, 8B–14B) podem servir como backends de cascata competitivos.
• Teste de Estresse de Ambiguidade: Consultas ambíguas causaram quedas significativas de desempenho (por exemplo, Qwen3-Omni caiu 24,6 pontos), sugerindo que a formulação da consulta é uma grande fonte de variância independente do áudio.

Significado e Alegações

O artigo alega fornecer um diagnóstico de primeira etapa verificável e reprodutível para a implantação de agentes de voz. Suas principais contribuições são:

1. Conversão de Benchmark: Um método para converter benchmarks de texto confiáveis em avaliações de áudio sem reconstruir rótulos de ouro ou esquemas, permitindo que empresas testem dados proprietários.
2. Sinal Diagnóstico: Evidência de que a lacuna "texto-para-voz" não é uma propriedade fixa da inferência omni-modal, mas varia por modelo e tarefa, necessitando de diagnósticos específicos em vez de suposições gerais.
3. Isolamento de Erros: O design emparelhado de texto–áudio permite análise de erro contrafactual, revelando que falhas de áudio frequentemente decorrem de mal-entendidos de valores de argumento, e não de falhas estruturais de seleção de ferramenta.
4. Avaliação Prática: Validação de que juízes LLM sem referência (incluindo opções de código aberto) podem avaliar efetivamente a chamada de ferramentas em configurações de produção onde rótulos de ouro estão indisponíveis.

Os autores posicionam este framework como um complemento a corpora de áudio construídos para fins específicos, oferecendo uma maneira controlada de isolar falhas induzidas por modalidade e informar escolhas arquiteturais (cascata vs. omni) antes de implantar com fala natural. Eles reconhecem limitações, observando que o áudio TTS é um proxy controlado e não captura totalmente os artefatos da conversa humana espontânea.