Aller au contenu
Cercle IA Tech · Vocal Un site du réseau Cercle IA Tech

Guide

Détection de fin de parole (VAD) : fonctionnement

VAD, détection de tour de parole et interruptions dans un agent vocal : ce que fait Silero VAD et les réglages décrits par LiveKit Agents.

Mis à jour le

Le VAD (voice activity detection, ou détection d'activité vocale) répond à une question simple : ce segment d'audio contient-il de la parole ou non ? Dans un agent vocal, il sert à décider quand l'appelant a fini de parler, quand il vient d'interrompre l'agent, et quand il faut relancer la reconnaissance. C'est le petit composant qui conditionne le rythme de la conversation.

Ce que fait le VAD

Un VAD reçoit de l'audio par petits morceaux et renvoie, pour chacun, une probabilité de parole. Un seuil transforme cette probabilité en décision binaire. La durée de silence qui suit la dernière parole est ensuite comparée à un délai : au-delà, l'agent considère que le tour est terminé.

Le VAD ne comprend pas le sens de ce qui est dit. Il entend seulement qu'il y a de la voix, ou qu'il n'y en a pas. C'est pour cela qu'il est rapide, et aussi pour cela qu'il se trompe sur une pause réfléchie, un bruit de fond ou une toux.

Silero VAD, un exemple publié

Silero VAD est un détecteur pré-entraîné, publié sur GitHub. Sa page annonce les points suivants :

  • il distingue la parole du reste de l'audio, dans des conditions de bruit et de qualité variées ;
  • il a été entraîné sur des corpus qui couvrent, selon la page, plus de 6 000 langues ;
  • les taux d'échantillonnage supportés sont 8 000 Hz et 16 000 Hz ;
  • la page annonce qu'un segment d'au moins 30 ms est traité en moins de 1 ms sur un seul thread CPU.

Ce dernier chiffre est celui de l'éditeur, pour sa propre mesure. Il ne dit rien du temps total d'un tour de parole. Le taux d'échantillonnage compte : si votre téléphonie envoie de l'audio à un autre format, il faut le convertir avant le VAD.

Le tour de parole

LiveKit Agents distingue plusieurs modes de détection de tour. La documentation indique que :

  • le modèle de tour est le mode par défaut et le mode recommandé : il prédit la fin du tour à partir du sens de la parole et de ses caractéristiques acoustiques, en complément du VAD ;
  • le VAD seul (turn_detection="vad") sert à obtenir une latence minimale, ou pour une langue que le modèle de tour ne couvre pas ;
  • l'endpointing STT (turn_detection="stt") convient à un service de reconnaissance qui gère déjà ses tours, comme AssemblyAI ou Deepgram Flux. Le VAD de la session continue alors de gérer les interruptions ;
  • le contrôle manuel sert au mode « appuyer pour parler ».

Deepgram décrit son modèle Flux STT comme un modèle conçu pour les agents vocaux, avec « détection de fin de tour intégrée ». Le choix dépend donc du service de reconnaissance : si celui-ci gère déjà les tours, inutile de doubler la détection.

Les réglages qui comptent

Les valeurs suivantes viennent de la documentation LiveKit. Ce sont des valeurs d'exemple ou par défaut, pas des recommandations universelles :

Réglage Valeur citée Rôle
Délai d'interruption fausse 2,0 s (Python), 2 000 ms (Node.js) Reprendre la parole après une interruption qui n'en était pas une
Délais de transcription 2,0 s par défaut (Python) Attendre le texte final avant de conclure
Limite de tour utilisateur 30 s et 100 mots, désactivés par défaut Couper un monologue trop long
Exemple de téléphonie temps réel silence_duration_ms=400, prefix_padding_ms=300, threshold=0.7 Point de départ à tester

Pour les interruptions, la documentation décrit un mode adaptive (par défaut sur LiveKit Cloud ou en mode développement avec reconnaissance), qui distingue une vraie interruption d'un simple signal d'écoute. Les options min_duration et min_words filtrent les interruptions trop courtes ou sans contenu. L'option resume_false_interruption reprend la parole de l'agent après une fausse alerte.

Régler sans se tromper

  1. Commencer par le réglage par défaut et écouter une dizaine d'appels de test.
  2. Noter les deux erreurs : l'agent qui coupe l'appelant, et l'agent qui attend trop longtemps.
  3. Modifier un seul paramètre à la fois, puis rejouer les mêmes scénarios.
  4. Tester les pauses réelles : un chiffre dicté, une adresse épelée, une hésitation. Ce sont elles qui cassent le réglage.
  5. Tester le bruit de fond : une voiture, une cuisine, une conversation voisine.

Le réglage ne se fait donc pas une fois pour toutes : il dépend du public, du type d'appel et du téléphone utilisé. Pour mesurer le temps perdu dans cette étape, lisez la latence d'un agent vocal. Pour le scénario où l'agent doit passer la main, lisez transférer un appel à un humain.

Sources

Pages consultées pour écrire cet article :

  1. https://github.com/snakers4/silero-vad
  2. https://docs.livekit.io/agents/build/turns/
  3. https://developers.deepgram.com/docs/models-languages-overview

À lire aussi