AssemblyAI détaille les tests de charge des agents vocaux avant le lancement
AssemblyAI a publié un guide technique sur la façon de tester un agent vocal avant le lancement, arguant que la performance de la démonstration lors d’un seul appel en salle silencieuse ne reflète pas les conditions de production. Dans l’article, publié le 2026-10-20, l’entreprise indique que les équipes devraient rejouer leurs appels réels les plus difficiles à travers l’intégralité du pipeline à la concurrence maximale prévue et mesurer la précision de l’entité, la latence P95 , les connexions rejetées et le coût par tâche accomplie.
Ce que le guide dit pour tester
L’article indique que les tests de charge doivent couvrir toute la pile vocale — reconnaissance vocale, LLM, synthèse vocale, appels d’outils et téléphonie — et doivent séparer la concurrence, le débit et la durée de la session, car chacun échoue différemment. AssemblyAI affirme qu’une campagne de rappel qui ouvre des centaines d’appels en une courte fenêtre peut atteindre une limite différente d’une charge de concurrence de longue durée, et que la plupart des équipes ne testent que le premier cas. Le guide recommande également quatre profils : régime stationnaire, rampe linéaire, pic et absorption.
Les exemples d’AssemblyAI se concentrent sur des entrées de type production plutôt que sur un audio propre. Le post indique que les équipes devraient constituer un corpus à partir de leurs pires appels, incluant la compression téléphonique 8 kHz, le contenu chargé en entités comme les numéros de compte et les codes de confirmation, les vrais accents, le bruit de fond, les interruptions et les faux départs. Il avertit également que les étiquettes de transcription humaine peuvent contenir des omissions ou des nettoyages qui déforment les métriques d’erreur de mot, et précise que la précision des entités doit être pondérée au-dessus de la précision des mots lors de la notation des flux de travail vocaux.
Capacité, facturation et modes de défaillance
L’article indique que le test devrait prouver que les sessions se ferment proprement et que la montée en puissance reste dans les limites du fournisseur. Sur les API de streaming et Voice Agent d’AssemblyAI, les sessions sont facturées en fonction du temps connecté, et le guide indique que la capacité est régie par compte. Pour le streaming, le post indique que la limite concerne les nouvelles sessions par minute et peut être automatiquement adaptée aux comptes payants ; pour l’API Voice Agent, la limite concerne les sessions simultanées.
AssemblyAI précise également que les tests de charge doivent prendre en compte le comportement de facturation. Le post indique que le temps d’inactivité est facturable, qu’une session de streaming non explicitement fermée peut se fermer automatiquement après trois heures et être facturée pour toute la période, et fermer un socket Voice Agent sans envoyer session.end laisse une fenêtre de reprise de 30 secondes qui est également facturable. L’entreprise affirme que le coût par tâche achevée est un meilleur indicateur que le coût à l’heure, car un agent moins cher mais moins efficace peut tout de même devenir plus coûteux en pratique.
Indicateurs de référence et chiffres de référence
Le guide recommande de déclarer les percentiles plutôt que les moyennes et donne des seuils ciblés pour plusieurs indicateurs, notamment P95 sous 500 ms pour le délai de finalisation, P95 moins de 1.5 secondes pour la latence de virage bout à bout, P95 moins de 500 ms pour les allers-retours par appel outil, zéro rejet au pic prévu et sous 0.5% sessions supprimées. Il est également indiqué que les équipes doivent séparer les mesures de phase de rampe et de phase de soutien, car la latence peut s’aggraver pendant la rampe.
Pour illustrer les comparaisons de précision, AssemblyAI cite son benchmark anglais pour les agents vocaux de 12,460 scénarios scriptés. Sur ce benchmark, la société indique que Universal-3.6 Pro Realtime a enregistré 5.19% taux d’erreur de mot et 14.4% d’entité, comparé à Deepgram Flux EN à 13.50% et 30.1%, ElevenLabs Scribe v2 à 7.78% et 18.5%, et Deepgram Nova-3 à 8.64% et 26.1%. Le post cite également un sous-ensemble de numéros de téléphone à 2.4% contre 11.5% pour Deepgram Flux EN. Il fait également référence au benchmark indépendant Open STT de Pipecat, qui, selon lui, a trouvé un taux d’erreur sémantique de mot 0.80% pooled et un délai médian 307 ms de transcription finale, tout en notant l’avis de Pipecat selon lequel de petits intervalles entre les meilleurs services peuvent ne pas être significatifs.
Guidage du harnais et manipulation limite
AssemblyAI inclut un code d’exemple pour son API de streaming et son API Voice Agent, en mettant l’accent sur le rythme audio en temps réel, l’attente de confirmation de session avant d’envoyer l’audio, et le comptage des pics de concurrence uniquement après que le serveur a confirmé qu’une session est active. Le post précise que les sessions peuvent être rejetées au moment de la connexion et que les sessions rejetées doivent être comptées plutôt que réessayées lors d’un test de chargement. Il avertit également que les chunks audio doivent rester dans la taille autorisée par l’API et que le flux doit être explicitement terminé afin que le test ne divulgue pas les sessions facturables.
Pour la planification, l’entreprise conseille que les équipes fixent le modèle vocal plutôt que de s’appuyer sur les modèles de secours par défaut les plus récents, de benchmark sur le même corpus, et d’établir des seuils de retour en arrière avant le lancement. L’article se termine par un plan de déploiement d’une semaine et une checklist de préparation à la production couvrant la charge et la concurrence, la surveillance, le benchmarking sur les données propres à l’équipe, ainsi que les questions contractuelles telles que les limites de débit, les unités de facturation, les régions de traitement des données et les objectifs de réponse de soutien.