La détection d’activité vocale (VAD) identifie la parole dans un flux audio. Pour un agent, elle aide à répondre à « Quelqu’un parle-t-il ? » La question difficile est « A-t-il terminé ? »
Un appelant dit « Mon adresse est… », puis cherche le numéro de l’immeuble. Un détecteur peut signaler correctement le silence tandis que l’agent commence à parler à tort. Personne ne demandait une interruption particulièrement assurée.
Pour construire un agent conversationnel, utilisez la VAD là où des limites de parole sont nécessaires, puis choisissez une politique explicite de tours de parole. Voici comment les composants s’articulent, quand les détecteurs autonomes aident et quoi tester avant les appels.
Comment fonctionne la VAD
Un détecteur traite de courtes fenêtres audio et estime si elles contiennent de la parole. Selon l’implémentation, il produit une décision binaire, une probabilité ou des horodatages de parole assemblés à partir des décisions.
Un simple seuil d’énergie considère un son assez fort comme de la parole. C’est peu coûteux, mais une porte qui claque est aussi forte. Des détecteurs plus élaborés utilisent des caractéristiques acoustiques ou des modèles neuronaux pour distinguer les sons. La VAD moderne ne se limite pas au volume.
L’application ajoute généralement une logique autour du détecteur : plusieurs trames vocales avant de commencer, un bref tampon antérieur au déclenchement et une attente pendant un court silence avant de fermer le segment. Cette logique influence le résultat : sans tampon, une détection correcte peut arriver trop tard pour garder le début du mot.
La VAD ne transcrit pas, n’identifie pas un locuteur précis et ne supprime pas le bruit. Ce sont d’autres tâches. Elle peut reconnaître correctement une voix de télévision tout en déclenchant une mauvaise action dans un agent censé écouter uniquement l’appelant.
VAD, fin de parole et détection sémantique des tours
Ces termes décrivent des décisions différentes :
| Composant | Question | Limite |
|---|---|---|
| VAD | Cet audio contient-il de la parole ? | Une pause renseigne peu sur l’achèvement d’une idée |
| Fin fondée sur le silence | L’arrêt dure-t-il assez pour fermer le tour ? | Un délai fixe traite pareil réflexion et phrase terminée |
| Détection sémantique | Audio et contexte suggèrent-ils une fin ? | Prédictions encore précoces ou tardives ; récupération nécessaire |
| Gestion des interruptions | Faut-il arrêter la réponse quand la parole commence ? | Il faut aussi arrêter ou jeter les tampons audio et la génération en cours |
La détection fondée sur le silence est souvent un bon départ. Un délai court répond vite mais risque de couper la réflexion ; un délai long laisse du temps mais retarde les réponses aux phrases terminées.
La détection sémantique utilise davantage de contexte. « Mon e-mail est… » et « C’est tout, merci » peuvent demander des attentes différentes après une pause similaire. Cela reste une estimation, pas une garantie que l’appelant ne changera plus d’avis.
L’annonce d’Ink 2 explique notre intégration de la fin sémantique dans la reconnaissance. L’objectif est de laisser finir les idées et de répondre à temps. Optimiser uniquement la précision des trames ne prouve pas cette expérience.
Quand utiliser une VAD autonome
Un détecteur autonome aide à repérer la parole avant de décider quoi en faire : marquer des passages enregistrés, animer un indicateur de parole ou fournir des événements de début à votre chaîne. Une détection locale garde cette étape sur l’appareil, sans rendre le reste d’un agent connecté privé ou hors ligne.
Deux implémentations à évaluer sont WebRTC VAD via py-webrtcvad et Silero VAD.
| Implémentation | Entrée et exécution | Vérifications |
|---|---|---|
| WebRTC VAD | Le wrapper Python accepte le PCM mono 16 bits à 8, 16, 32 ou 48 kHz, en trames de 10, 20 ou 30 ms, avec quatre modes d’agressivité | Parole faible manquée par un filtrage strict et validité des trames de capture |
| Silero VAD | Détecteur neuronal PyTorch ou ONNX ; le projet documente 8 et 16 kHz | Coût du modèle et du moteur sur l’appareil, contraintes de fragments et faux déclenchements |
Ces formats sont propres aux implémentations. Un en-tête WAV n’est pas un échantillon PCM et un paquet MP3 n’est pas une trame directement utilisable par WebRTC VAD. Décodez et convertissez si nécessaire. Consultez la documentation actuelle sans supposer que la fréquence par défaut du microphone du navigateur convient.
Aucun des deux n’est un gestionnaire complet de conversation. Il faut encore déterminer les fins, gérer les interruptions et récupérer quand l’appelant continue.
Utiliser la détection intégrée d’Ink
Pour réunir transcription continue et limites des tours, l’API Realtime Speech-to-Text (Auto) de Cartesia inclut les deux, sans VAD supplémentaire pour ces limites.
Le cycle d’événements distingue fin possible et fin confirmée :
| Événement | Traitement à prévoir |
|---|---|
turn.start | L’appelant commence. Appliquez la politique d’interruption à la réponse active. |
turn.update | Actualisez la transcription affichée ou stockée pour ce tour. |
turn.eager_end | Le tour semble complet. Une réponse spéculative peut commencer à être générée. |
turn.resume | L’appelant continue. Annulez ou jetez le travail issu de la fin provisoire. |
turn.end | Le détecteur confirme la fin. Utilisez la transcription complète pour poursuivre. |
Une fin anticipée après « Je dois annuler » peut être suivie de « le deuxième rendez-vous, pas le premier ». Préparez une réponse pour réduire la latence si utile, mais attendez la confirmation avant lecture. Gardez les actions importantes derrière les règles de validation et de confirmation. Une prédiction précoce n’est pas une autorisation utilisateur.
Deux détails sont faciles à manquer. Les événements de transcription contiennent le texte cumulé du tour : remplacez le texte actuel, car concaténer les mises à jour répète les mots. L’API attend aussi un audio continu, silences compris. Ne supprimez pas les fragments silencieux avec une VAD en amont : une absence d’audio signifie attente d’entrée, pas fin de parole.
La documentation des tours couvre seuils, annulation et vidage des événements en tampon à la fermeture. Commencez par les valeurs par défaut et modifiez un réglage à la fois à partir d’échecs conversationnels enregistrés.
Tester la conversation entière
Définissez l’expérience avant les seuils. Un réceptionniste qui recueille une adresse doit laisser le temps de la chercher. Une réponse oui/non peut demander moins d’attente. Un délai de silence global ne représente pas tous les besoins.
Utilisez des enregistrements autorisés et le microphone ou la connexion réellement prévus. Écoutez des échanges complets :
| Situation | Échec à rechercher |
|---|---|
| Première syllabe faible après silence | Début du mot perdu dans l’enregistrement ou la transcription |
| Pause au milieu d’une adresse | Réponse avant la fin de l’appelant |
| Réponse courte et complète | Attente alors que le tour est manifestement fini |
| « Finalement, plutôt jeudi » pendant la réponse | Audio en tampon continuant sur la correction |
| Parole de fond, clavier ou écho | Arrêt ou réponse déclenchés par le mauvais son |
| Accents, débits et hésitations variés | Réglage adapté à l’auteur du test mais coupant les autres |
Suivez fins précoces et interruptions manquées avec le délai de réponse. Séparez la fermeture du tour du temps dans le LLM, les outils, la génération et la lecture. Raccourcir un délai VAD ne corrige pas une recherche de calendrier lente.
En cas d’interruption, examinez toute la sortie. Annuler le texte ne vide pas forcément l’audio déjà chez le client. Une personne qui dit « stop » se soucie du moment où le son s’arrête, pas de la tâche serveur annulée.
Essayez la démonstration Ink en faisant volontairement une pause dans une phrase. Exécutez ensuite l’exemple Realtime STT dans vos conditions audio. Le bon test est de savoir si l’agent laisse finir vos utilisateurs et répond quand ils sont prêts.