Test des agents | ElevenLabs Documentation

Les tests d’agent vous permettent de vérifier les réponses conversationnelles, l’utilisation des outils et les résultats complets sur plusieurs tours avant le déploiement. Créez des tests à partir de zéro ou de conversations existantes, puis exécutez-les depuis le Dashboard, la CLI ou l’API.

Présentation vidéo

Vue d’ensemble

Le framework comprend trois types de tests complémentaires :

Tests de simulation : exécutent des conversations complètes sur plusieurs tours avec un utilisateur simulé
Tests de réponse suivante (scénario) : valident la prochaine réponse de l’agent selon des critères de réussite
Tests d’appel d’outil : vérifient que l’agent appelle le bon outil avec les bons paramètres

Quel test utiliser ?

Type de test	À utiliser lorsque vous devez
Simulation	Vérifier qu’une conversation complète atteint un résultat défini
Réponse suivante (scénario)	Vérifier que le prochain message de l’agent respecte des critères de qualité, de ton ou de politique
Appel d’outil	Vérifier que l’agent appelle un outil spécifique avec les paramètres attendus

Créer des tests à partir de conversations

Transformez des conversations réelles en cas de test lorsque vous identifiez une interaction dans laquelle l’agent n’a pas donné les résultats attendus.

Création d’un test à partir d’une conversation

Ouvrez la conversation dans l’historique des appels
Cliquez sur Créer un test à partir de cette conversation
Examinez le contexte prérempli, puis définissez le comportement attendu
Ajoutez le test à votre suite pour détecter des échecs similaires ultérieurement

Tests de simulation

Les tests de simulation évaluent votre agent au cours d’une conversation complète sur plusieurs tours avec un utilisateur IA simulé. Contrairement aux tests de réponse suivante, ce type de test vérifie que l’interaction complète atteint le résultat défini.

Créer un test de simulation

Interface de création d’un test de simulation

Définir le scénario

Décrivez en langage naturel le contexte, l’intention et le comportement de l’utilisateur. Le simulateur utilise ce scénario pour orienter la conversation.

Exemple de scénario :

« Un touriste qui ne maîtrise pas couramment l’anglais tente de passer commande dans un restaurant. »

Définir la condition de réussite

Définissez le résultat qui doit être considéré comme une réussite. Cette instruction sert à évaluer si la conversation complète a abouti.

Exemple de condition de réussite :

« L’agent a confirmé les détails de la commande, traité les questions de clarification et finalisé la commande sans malentendu. »

Définir le nombre maximal de tours

Choisissez la durée d’exécution de la simulation avant son arrêt. Utilisez une valeur faible pour des vérifications ciblées et une valeur plus élevée pour des workflows complexes.

Minimum : 1
Maximum : 50
Valeur par défaut : 5

Exécuter et examiner le résultat

Exécutez le test et examinez la transcription de conversation générée. Vérifiez le résultat de réussite ou d’échec par rapport à votre condition de réussite, puis ajustez votre instruction, vos outils ou la configuration de l’agent.

Configuration facultative

Vous pouvez affiner le comportement de la simulation dans le panneau de configuration du test :

Environnement : sélectionnez l’environnement à tester lorsque plusieurs environnements sont configurés pour votre agent. Si un seul environnement est disponible, ce sélecteur est masqué.
Historique de discussion : partez d’une conversation partielle plutôt que d’un état vide. Cette option est utile pour tester des conversations en cours et les comportements de reprise.
Variables dynamiques : injectez des valeurs propres au test dans les variables de votre agent, par exemple des noms d’utilisateurs ou des identifiants de commande, sans modifier la configuration de base de l’agent.

Simulation d’outils

Les tests de simulation prennent en charge la simulation d’outils afin que votre agent reçoive des réponses contrôlées pendant une exécution, au lieu d’appeler des systèmes en production.

Stratégie de simulation

Ne simuler aucun outil : aucun outil n’est simulé.
Simuler tous les outils : chaque outil pouvant être simulé renvoie une réponse simulée.
Simuler les outils sélectionnés : seuls les outils que vous choisissez explicitement sont simulés.

Les outils système et les outils de workflow ne sont jamais simulés.

Comportement de repli

Si un outil simulé est appelé sans qu’aucune réponse simulée correspondante ne soit trouvée, choisissez l’un des comportements suivants :

Appeler l’outil réel : exécute l’appel à l’outil réel.
Terminer avec une erreur : renvoie une réponse d’erreur de l’outil au lieu d’appeler l’outil réel.

Le paramètre de repli s’affiche uniquement lorsqu’au moins un outil est simulé.

Tests de réponse suivante (scénario)

Les tests de réponse suivante (scénario) évaluent uniquement le prochain message de l’agent, et non le résultat complet d’une conversation sur plusieurs tours. Fournissez l’historique de conversation menant à la réponse à évaluer, puis évaluez cette réponse selon des critères de réussite.

Pour les résultats complets sur plusieurs tours, utilisez les tests de simulation.

Créer un test de réponse suivante

Interface de test de réponse suivante (scénario)

Définir l’historique de discussion

Fournissez l’historique de conversation menant à la réponse que vous souhaitez évaluer. Il peut s’agir d’un seul message utilisateur ou de plusieurs tours de contexte.

Exemple d’historique de discussion :

User: "I'd like to cancel my subscription. I've been charged twice this month and I'm frustrated."

Définir les critères de réussite

Décrivez en langage clair ce que la réponse de l’agent doit accomplir. Précisez le comportement, le ton et les actions attendus.

Exemple de critères de réussite :

L’agent doit reconnaître avec empathie la frustration du client
L’agent doit proposer d’enquêter sur le double prélèvement
L’agent doit indiquer clairement les prochaines étapes d’annulation ou de résolution
L’agent doit conserver un ton professionnel et serviable

Fournir des exemples

Fournissez des exemples de réussite et d’échec afin d’aider l’évaluateur à comprendre les nuances de vos critères.

Exemple de réussite :

« Je comprends à quel point des doubles prélèvements peuvent être frustrants. Laissez-moi examiner cela immédiatement pour vous. Je constate qu’il y a bien eu deux prélèvements ce mois-ci, je vais traiter sans délai le remboursement du prélèvement en double. Souhaitez-vous toujours procéder à l’annulation ou préférez-vous continuer une fois ce problème résolu ? »

Exemple d’échec :

« Vous devez contacter le service de facturation pour les problèmes de remboursement. Votre abonnement sera annulé. »

Exécuter le test

Exécutez le test. Un évaluateur LLM compare la prochaine réponse de l’agent à vos critères de réussite et à vos exemples afin de déterminer si le test réussit ou échoue.

Tests d’appel d’outil

Les tests d’appel d’outil vérifient que votre agent utilise correctement les outils et transmet les bons paramètres dans des situations spécifiques. Ils sont essentiels pour des actions telles que les transferts d’appel, les recherches de données ou les intégrations externes.

Créer un test d’appel d’outil

Sélectionner l’outil

Choisissez l’outil que l’agent doit appeler dans le scénario donné (par exemple, transfer_to_number, end_call, lookup_order).

Définir les paramètres attendus

Précisez les données que l’agent doit transmettre à l’outil. Vous disposez de trois méthodes de validation :

Méthodes de validation

Correspondance exacte
Le paramètre doit correspondre exactement à la valeur spécifiée.

Transfer number: +447771117777

Motif regex Le paramètre doit correspondre à un motif spécifique.

Order ID: ^ORD-[0-9]{8}$

Évaluation par LLM Un LLM évalue si le paramètre est sémantiquement correct selon le contexte.

Message: "Should be a polite message mentioning the connection"

Configurer les variables dynamiques

Lors des tests en développement, utilisez des valeurs de variables dynamiques correspondant aux valeurs réelles en production. Exemple : {{ customer_name }} ou {{ order_id }}

Exécuter et valider

Exécutez le test pour vérifier que l’agent appelle le bon outil avec les paramètres appropriés.

Cas d’usage critiques

Les tests d’appel d’outil sont essentiels pour les scénarios à forts enjeux :

Transferts d’urgence : vérifiez que les urgences médicales sont toujours redirigées vers le bon numéro
Sécurité des données : vérifiez que les informations sensibles ne sont jamais transmises à des outils non autorisés
Logique métier : confirmez que les recherches de commande utilisent des formats et une authentification valides

Exécuter des tests

Écrivez des tests pour les nouveaux comportements ou les échecs connus, exécutez-les pendant que vous ajustez les instructions et la configuration, puis enregistrez-les une fois qu’ils réussissent.

Exécuter depuis le Dashboard

Exécuter via la CLI

Exécuter via l’API

Accédez à l’onglet Tests dans l’interface de votre agent. Vous pouvez y exécuter des tests individuels, sélectionner plusieurs tests de votre bibliothèque par lot ou exécuter toute votre suite avec Exécuter tous les tests.

Tests probabilistes

Les résultats de l’agent peuvent varier d’une exécution à l’autre. Une seule réussite montre que l’agent peut réussir ; les tests probabilistes indiquent à quelle fréquence il réussira en exécutant plusieurs fois le même test et en produisant un taux de réussite.

Exécuter un test plusieurs fois

Contrôle d’exécution multiple d’un test permettant de choisir le nombre d’exécutions

Lorsque vous lancez un test depuis le Dashboard, utilisez le contrôle d’exécution multiple du bouton d’exécution pour choisir le nombre d’exécutions, par exemple 3×, 5× ou 15×. Chaque exécution est indépendante : l’agent reçoit le même historique de discussion, les mêmes variables dynamiques et les mêmes autres entrées, mais sa réponse est générée à nouveau à chaque fois.

L’exécution multiple fonctionne pour les tests individuels, les dossiers et l’exécution de toute la suite de tests associée à un agent. Elle est compatible avec les trois types de tests, simulation, réponse suivante (scénario) et appel d’outil, et s’avère généralement particulièrement utile pour les tests de simulation, où l’étendue plus large d’une conversation sur plusieurs tours rend les variations de réponse plus probables.

Taux de réussite et regroupement des résultats

Résultats d’exécutions multiples regroupés par réussite et échec avec un badge de taux de réussite

À la fin d’une exécution multiple, les résultats sont résumés sous la forme d’un taux de réussite, par exemple 4/5 réussis, avec un badge coloré :

Vert : 100 % de réussite
Ambre : au moins 80 % de réussite
Rouge : moins de 80 % de réussite

Les exécutions individuelles sont ensuite regroupées par motif d’échec pour vous permettre de voir comment l’agent échoue, et pas seulement qu’il échoue. Au lieu de parcourir cinq transcriptions distinctes pour identifier les différences, vous voyez des groupes tels que « Correctement redirigé vers la facturation (4 exécutions) » et « A inventé un numéro d’assistance (1 exécution) », chacun pouvant être développé pour afficher les transcriptions sous-jacentes et le raisonnement de l’évaluation.

Quand l’utiliser

Avant de déployer une modification : réexécutez les tests associés de manière probabiliste pour confirmer que la fiabilité n’a pas diminué, par exemple de 95 % à 60 %.
Diagnostiquer un comportement instable : un échec isolé peut être du bruit ; un échec une fois sur cinq avec un groupe d’échec clairement nommé constitue un problème reproductible à corriger.
Ajuster les instructions et les outils : itérez sur la configuration et comparez les taux de réussite côte à côte, plutôt que de vous appuyer sur des exécutions ponctuelles.

Exécuter des tests probabilistes via l’API ou le SDK

Transmettez repeat_count, entre 2 et 20, dans la requête run-tests pour exécuter chaque test ce nombre de fois. Définir repeat_count active automatiquement le regroupement des échecs dans la réponse. L’invocation renvoyée inclut donc le regroupement par catégorie et le taux de réussite affichés dans le Dashboard.

from elevenlabs import ElevenLabs
elevenlabs = ElevenLabs()
invocation = elevenlabs.conversational_ai.agents.run_tests(
    agent_id="<agent-id>",
    tests=[{"test_id": "<test-id>"}],
    repeat_count=5,
)

Bonnes pratiques

Évaluer la cohérence de la persona de l’agent

Vérifiez que votre agent conserve la personnalité, le ton et les limites comportementales définis dans divers scénarios de conversation et contextes émotionnels.

Vérifier un raisonnement complexe sur plusieurs tours

Créez des scénarios qui testent la capacité de l’agent à conserver le contexte, à suivre une logique conditionnelle et à gérer les transitions d’état au fil de conversations prolongées.

Tester les tentatives d’injection d’instructions

Évaluez la manière dont votre agent répond aux tentatives de contourner ses instructions ou d’extraire des informations système sensibles au moyen d’entrées adverses.

Évaluer la résolution d’intentions ambiguës

Testez l’efficacité avec laquelle votre agent clarifie les demandes vagues, gère les informations contradictoires et traite les situations où l’intention de l’utilisateur n’est pas claire.

Prochaines étapes

Consultez la documentation CLI pour configurer les tests automatisés
Découvrez la configuration des outils pour comprendre les outils disponibles
Lisez le guide de prompting pour rédiger des instructions testables