Resumen Técnico: De Texto a Voz: Un Marco Reproducible y Verificable para Evaluar Agentes LLM de Llamada de Herramientas

Declaración del Problema

Aunque los Modelos de Lenguaje Grandes (LLM) han avanzado significativamente en la llamada de herramientas y la ejecución de funciones dentro de entornos basados en texto, las principales pruebas de rendimiento (p. ej., Confetti, When2Call, BFCL) siguen siendo exclusivamente de texto. Esto crea una brecha para las organizaciones que despliegan agentes de voz, quienes deben elegir entre una arquitectura en cascada (ASR $\rightarrow$ LLM de texto) o una arquitectura omni-modal de extremo a extremo (Voz $\rightarrow$ Llamada de herramienta). Las pruebas de rendimiento de audio existentes a menudo requieren construir nuevos corpus desde cero con nuevos esquemas de herramientas y etiquetas de referencia, lo cual es costoso y limita la aplicabilidad a datos empresariales propietarios. Además, la fiabilidad de los modelos omni-modales bajo condiciones de audio realistas y la degradación específica del rendimiento introducida por la modalidad de voz siguen estando insuficientemente caracterizadas.

Metodología

Los autores proponen un marco agnóstico al conjunto de datos que convierte las pruebas de rendimiento existentes basadas en texto para llamadas de herramientas en evaluaciones de audio controladas sin reanotar esquemas de herramientas ni etiquetas de referencia.

1. Pipeline de Conversión

El marco utiliza modelos de Texto a Voz (TTS) comerciales para generar instancias emparejadas de texto y audio:

• Modelos TTS: Se utilizaron tres modelos: Gemini-2.5-Flash-TTS, Gemini-2.5-Pro-TTS y GPT-4o-Mini-TTS.
• Variación de Hablante: Se seleccionaron voces distintas para hablantes masculinos y femeninos de cada proveedor (p. ej., Kore/Orus para Gemini, Coral/Ash para GPT).
• Inyección de Ruido: Se inyectó ruido ambiental del conjunto de datos DEMAND a varias relaciones señal-ruido (SNR: 5, 10, 15, 20 dB) para simular condiciones de despliegue.
• Preservación: Los esquemas de herramientas originales, las etiquetas de referencia y los protocolos de evaluación se preservan estrictamente desde los conjuntos de datos de texto originales.

2. Protocolo de Evaluación

El marco evalúa siete modelos omni-modales de cuatro proveedores (OpenAI, Google, Qwen, Microsoft) en dos conjuntos de datos:

• Confetti: Se centra en la precisión de la selección de funciones y la extracción de parámetros (313 ejemplos que requieren llamadas de herramientas).
• When2Call: Se centra en la capacidad de toma de decisiones para determinar si es necesaria una llamada de herramienta (300 ejemplos).

La evaluación compara tres condiciones:

1. Texto Limpio: Rendimiento de referencia utilizando entradas de texto originales.
2. Voz Directa: Rendimiento utilizando entradas de audio generadas por TTS procesadas por modelos omni-modales.
3. Cascada (ASR $\rightarrow$ Texto): Audio transcrito por GPT-4o-Transcribe y pasado a un LLM de solo texto.

3. Análisis Adicionales

• Descomposición de Errores: Los fallos emparejados de texto y audio se categorizan en errores de decisión, errores de selección de herramienta, errores de esquema de argumentos y errores de valor de argumento.
• Evaluación Libre de Referencia: Se prueban protocolos de LLM como Juez (utilizando GPT-5, Gemini-2.5-Pro y modelos de código abierto Qwen3) frente a etiquetas de referencia para evaluar la viabilidad en datos de producción que carecen de anotaciones.
• Pruebas de Estrés: Se realizaron pruebas de reformulación de consultas basadas en ambigüedad para medir la robustez ante solicitudes de usuario no especificadas.

Resultados Clave

Dependencia del Modelo y la Tarea

El rendimiento depende en gran medida del modelo y la tarea específicos, y no solo de la arquitectura:

• Confetti: Gemini-3.1-Flash-Live obtuvo la puntuación más alta (70,4%), seguido de Qwen3-Omni (60,4%).
• When2Call: GPT-Realtime-1.5 tuvo el mejor rendimiento (71,9%), mientras que Gemini-3.1-Flash-Live cayó al cuarto lugar (63,4%).
• Brecha de Texto a Voz: La degradación del rendimiento al pasar de texto a voz varía significativamente según el modelo. En Confetti, la brecha oscila entre 1,8 puntos (Qwen3-Omni) y 4,8 puntos (GPT-Realtime-1.5).

Comparación de Arquitecturas (Cascada vs. Omni)

• Gemini-3.1-Flash-Live: La arquitectura en cascada superó ligeramente a la voz directa (71,3% frente a 70,4%), lo que sugiere que ASR + un LLM de texto potente pueden recuperar el rendimiento.
• GPT-Realtime-1.5 y Qwen3-Omni: La voz directa superó a la cascada en 0,4 y 1,5 puntos, respectivamente.
• Conclusión: Ninguna arquitectura domina uniformemente; la elección óptima es específica del modelo y la tarea.

Análisis de Errores

• Valores de Argumentos: El modo de fallo más común en los errores inducidos por audio son los errores de valor de argumento (valores de campo incorrectos o incompletos), que representan el 57,2% de los fallos para Gemini-3.1-Flash-Live y el 54,3% para GPT-Realtime-1.5. Esto indica que los modelos a menudo preservan la estructura de la llamada de herramienta pero malinterpretan el contenido del habla.
• Errores de Decisión: Se observaron errores de decisión significativos (30–37%), lo que indica que la entrada de audio altera las decisiones de alto nivel sobre el uso de herramientas (p. ej., si llamar a una herramienta o no).
• Especificidades de When2Call: Los modelos generalmente tuvieron más dificultades con los casos de "sin llamada de herramienta" que con los casos de "llamada de herramienta", lo que resalta una dificultad para saber cuándo no actuar.

Evaluación y Escalado

• Jueces LLM: Los jueces LLM libres de referencia mostraron clasificaciones de modelos estables en comparación con los jueces conscientes de la referencia. Los jueces de código abierto Qwen3 con $\ge$ 8B de parámetros lograron una concordancia >80% con los jueces propietarios, apoyando la evaluación que preserva la privacidad.
• Escalado de Texto: En modo solo texto, la precisión escala con el tamaño del modelo (p. ej., Qwen3 sube del 26,6% en 0,6B al 70,7% en 32B). Los modelos de texto más pequeños (p. ej., 8B–14B) pueden servir como backends de cascada competitivos.
• Prueba de Estrés de Ambigüedad: Las consultas ambiguas provocaron caídas significativas en el rendimiento (p. ej., Qwen3-Omni bajó 24,6 puntos), lo que sugiere que la formulación de la consulta es una fuente importante de variación independiente del audio.

Significado y Afirmaciones

El artículo afirma proporcionar un diagnóstico verificable y reproducible de primera etapa para el despliegue de agentes de voz. Sus contribuciones principales son:

1. Conversión de Pruebas de Rendimiento: Un método para convertir pruebas de rendimiento de texto confiables en evaluaciones de audio sin reconstruir etiquetas de referencia o esquemas, lo que permite a las empresas probar datos propietarios.
2. Señal Diagnóstica: Evidencia de que la brecha "de texto a voz" no es una propiedad fija de la inferencia omni-modal, sino que varía según el modelo y la tarea, lo que requiere diagnósticos específicos en lugar de suposiciones generales.
3. Aislamiento de Errores: El diseño emparejado de texto y audio permite un análisis de errores contrafáctico, revelando que los fallos de audio a menudo se deben a malentendidos de los valores de los argumentos en lugar de fallos estructurales en la selección de herramientas.
4. Evaluación Práctica: Validación de que los jueces LLM libres de referencia (incluidas las opciones de código abierto) pueden evaluar eficazmente las llamadas de herramientas en entornos de producción donde no hay etiquetas de referencia disponibles.

Los autores posicionan este marco como un complemento a los corpus de audio diseñados específicamente, ofreciendo una forma controlada de aislar los fallos inducidos por la modalidad e informar las elecciones arquitectónicas (cascada vs. omni) antes de desplegar con habla natural. Reconocen las limitaciones, señalando que el audio TTS es un proxy controlado y no captura completamente los artefactos de la conversación humana espontánea.