Résumé technique : Du texte à la voix : un cadre reproductible et vérifiable pour l'évaluation des agents LLM appelant des outils

Énoncé du problème

Bien que les modèles de langage de grande taille (LLM) aient considérablement progressé dans l'appel d'outils et l'exécution de fonctions au sein d'environnements textuels, les benchmarks phares (par exemple, Confetti, When2Call, BFCL) restent exclusivement textuels. Cela crée un écart pour les organisations déployant des agents vocaux, qui doivent choisir entre une architecture en cascade (ASR $\rightarrow$ LLM textuel) ou une architecture omni-modale de bout en bout (Parole $\rightarrow$ Appel d'outil). Les benchmarks audio existants nécessitent souvent la création de nouveaux corpus à partir de zéro avec de nouveaux schémas d'outils et de nouvelles étiquettes de référence, ce qui est coûteux et limite l'applicabilité aux données propriétaires d'entreprise. De plus, la fiabilité des modèles omni-modaux dans des conditions audio réalistes et la dégradation spécifique des performances introduite par la modalité vocale restent insuffisamment caractérisées.

Méthodologie

Les auteurs proposent un cadre agnostique vis-à-vis des jeux de données qui convertit les benchmarks existants d'appel d'outils basés sur le texte en évaluations audio contrôlées, sans ré-annoter les schémas d'outils ni les étiquettes de référence.

1. Pipeline de conversion

Le cadre utilise des modèles de synthèse vocale (TTS) prêts à l'emploi pour générer des instances appariées texte–audio :

• Modèles TTS : Trois modèles ont été utilisés : Gemini-2.5-Flash-TTS, Gemini-2.5-Pro-TTS et GPT-4o-Mini-TTS.
• Variation des locuteurs : Des voix distinctes pour des locuteurs masculins et féminins ont été sélectionnées auprès de chaque fournisseur (par exemple, Kore/Orus pour Gemini, Coral/Ash pour GPT).
• Injection de bruit : Du bruit environnemental issu du jeu de données DEMAND a été injecté à divers rapports signal-sur-bruit (SNR : 5, 10, 15, 20 dB) pour simuler les conditions de déploiement.
• Préservation : Les schémas d'outils originaux, les étiquettes de référence et les protocoles d'évaluation sont strictement préservés à partir des jeux de données textuels sources.

2. Protocole d'évaluation

Le cadre évalue sept modèles omni-modaux auprès de quatre fournisseurs (OpenAI, Google, Qwen, Microsoft) sur deux jeux de données :

• Confetti : Se concentre sur la sélection de fonctions et la précision de l'extraction de paramètres (313 exemples nécessitant des appels d'outils).
• When2Call : Se concentre sur la capacité de prise de décision pour déterminer si un appel d'outil est nécessaire (300 exemples).

L'évaluation compare trois conditions :

1. Texte propre : Performance de base utilisant les entrées textuelles originales.
2. Voix directe : Performance utilisant des entrées audio générées par TTS traitées par des modèles omni-modaux.
3. Cascade (ASR $\rightarrow$ Texte) : Audio transcrit par GPT-4o-Transcribe et transmis à un LLM uniquement textuel.

3. Analyses supplémentaires

• Décomposition des erreurs : Les échecs appariés texte–audio sont catégorisés en erreurs de décision, erreurs de sélection d'outil, erreurs de schéma d'arguments et erreurs de valeur d'argument.
• Évaluation sans référence : Les protocoles de type « LLM en tant que juge » (utilisant GPT-5, Gemini-2.5-Pro et des modèles open-source Qwen3) sont testés par rapport aux étiquettes de référence pour évaluer leur viabilité pour les données de production dépourvues d'annotations.
• Tests de stress : Des tests de reformulation de requêtes basés sur l'ambiguïté ont été menés pour mesurer la robustesse face aux demandes d'utilisateurs sous-spécifiées.

Résultats clés

Dépendance au modèle et à la tâche

Les performances dépendent fortement du modèle et de la tâche spécifiques, plutôt que de l'architecture seule :

• Confetti : Gemini-3.1-Flash-Live a obtenu le score le plus élevé (70,4 %), suivi de Qwen3-Omni (60,4 %).
• When2Call : GPT-Realtime-1.5 a obtenu les meilleurs résultats (71,9 %), tandis que Gemini-3.1-Flash-Live est tombé à la 4ᵉ place (63,4 %).
• Écart texte-vers-voix : La dégradation des performances lors du passage du texte à la voix varie considérablement selon le modèle. Sur Confetti, l'écart varie de 1,8 point (Qwen3-Omni) à 4,8 points (GPT-Realtime-1.5).

Comparaison des architectures (Cascade vs Omni)

• Gemini-3.1-Flash-Live : L'architecture en cascade a légèrement surpassé la voix directe (71,3 % contre 70,4 %), suggérant que l'ASR + un LLM textuel puissant peut récupérer les performances.
• GPT-Realtime-1.5 et Qwen3-Omni : La voix directe a surpassé la cascade de 0,4 et 1,5 point, respectivement.
• Conclusion : Aucune architecture ne domine uniformément ; le choix optimal est spécifique au modèle et à la tâche.

Analyse des erreurs

• Valeurs d'arguments : Le mode d'échec le plus courant dans les erreurs induites par l'audio est les erreurs de valeur d'argument (valeurs de champs incorrectes ou incomplètes), représentant 57,2 % des échecs pour Gemini-3.1-Flash-Live et 54,3 % pour GPT-Realtime-1.5. Cela indique que les modèles préservent souvent la structure de l'appel d'outil mais interprètent mal le contenu vocal.
• Erreurs de décision : Des erreurs de décision significatives (30–37 %) ont été observées, indiquant que l'entrée audio modifie les décisions de haut niveau concernant l'utilisation d'outils (par exemple, savoir s'il faut appeler un outil ou non).
• Spécificités de When2Call : Les modèles ont généralement plus de mal avec les cas « sans appel d'outil » qu'avec les cas « appel d'outil », soulignant une difficulté à savoir quand ne pas agir.

Évaluation et mise à l'échelle

• Juges LLM : Les juges LLM sans référence ont montré des classements de modèles stables par rapport aux juges conscients de la référence. Les juges Qwen3 open-source avec $\ge$ 8 milliards de paramètres ont atteint plus de 80 % d'accord avec les juges propriétaires, soutenant une évaluation respectueuse de la vie privée.
• Mise à l'échelle du texte : En mode uniquement texte, la précision évolue avec la taille du modèle (par exemple, Qwen3 passant de 26,6 % à 0,6 milliard de paramètres à 70,7 % à 32 milliards). Les petits modèles textuels (par exemple, 8–14 milliards) peuvent servir de backends de cascade compétitifs.
• Test de stress sur l'ambiguïté : Les requêtes ambiguës ont provoqué des baisses de performances significatives (par exemple, Qwen3-Omni a chuté de 24,6 points), suggérant que la formulation de la requête est une source majeure de variance indépendante de l'audio.

Importance et affirmations

L'article affirme fournir un diagnostic de première étape vérifiable et reproductible pour le déploiement d'agents vocaux. Ses contributions principales sont :

1. Conversion de benchmark : Une méthode pour convertir des benchmarks textuels de confiance en évaluations audio sans reconstruire les étiquettes de référence ni les schémas, permettant aux entreprises de tester des données propriétaires.
2. Signal diagnostique : La preuve que l'écart « texte-vers-voix » n'est pas une propriété fixe de l'inférence omni-modale mais varie selon le modèle et la tâche, nécessitant des diagnostics spécifiques plutôt que des hypothèses générales.
3. Isolement des erreurs : La conception appariée texte–audio permet une analyse d'erreurs contrefactuelle, révélant que les échecs audio découlent souvent de malentendus sur les valeurs d'arguments plutôt que d'échecs structurels de sélection d'outils.
4. Évaluation pratique : La validation que les juges LLM sans référence (y compris les options open-source) peuvent évaluer efficacement l'appel d'outils dans des contextes de production où les étiquettes de référence sont indisponibles.

Les auteurs positionnent ce cadre comme un complément aux corpus audio conçus à cet effet, offrant un moyen contrôlé d'isoler les échecs induits par la modalité et d'éclairer les choix architecturaux (cascade vs omni) avant le déploiement avec la parole naturelle. Ils reconnaissent les limites, notant que l'audio TTS est un proxy contrôlé et ne capture pas pleinement les artefacts de la conversation humaine spontanée.