Qu?est-ce qu?un mod?le KWS ? Contr?le vocal hors ligne avec ONNX

La commande vocale ne nécessite pas toujours de transcription, de service cloud ni de grand modèle de langage.

Si un appareil doit seulement réagir à une courte liste de phrases connues — « allumer », « éteindre », « suivant » ou « prendre une photo » — il suffit parfois de détecter si l’un de ces mots-clés a été prononcé. C’est le rôle du keyword spotting, abrégé en KWS.

Le KWS est un classificateur audio spécialisé. Il analyse de courtes fenêtres sonores et estime si un mot-clé appris est présent. Il ne transcrit pas tout ce que dit la personne et ne comprend pas les demandes libres.

Le mot de réveil est un cas courant, mais pas le seul

Le KWS sert souvent à détecter un mot de réveil. Un petit détecteur peut écouter localement une phrase comme « Bonjour appareil ». Lorsqu’il la reconnaît, le produit peut lancer un système de reconnaissance vocale plus complet ou un assistant.

Le KWS peut aussi commander directement un appareil. Un interrupteur peut reconnaître « allumer » et « éteindre » ; une télécommande de présentation, « diapositive suivante » et « retour ». Dans ces cas, aucune conversation ultérieure n’est nécessaire.

Avec un vocabulaire fixe de quelques commandes — et parfois une dizaine ou davantage selon le modèle, la ressemblance entre les phrases et le matériel — chaque détection peut déclencher directement une action. Il n’existe pas de limite universelle : le choix dépend du vocabulaire et des faux déclenchements mesurés.

KWS et ASR ne répondent pas à la même question

La reconnaissance automatique de la parole (ASR) transforme la voix en texte. Elle convient lorsque les utilisateurs peuvent formuler leurs demandes de nombreuses façons et que l’application a besoin des mots prononcés.

Le KWS pose une question plus ciblée : l’une de ces phrases précises vient-elle d’être prononcée ? Cette tâche plus limitée permet d’utiliser un modèle compact, exécuté localement lorsque le stockage, les ressources de calcul, le réseau ou la confidentialité sont contraints.

Un petit modèle KWS n’est pas un chatbot miniature. Il reconnaît uniquement les phrases prévues et doit être testé dans les conditions réelles d’utilisation.

Que signifie l’inférence ONNX locale ?

ONNX est un format portable pour représenter des modèles d’apprentissage automatique. Un moteur compatible peut charger le modèle sur un appareil pris en charge et effectuer la détection localement, sans envoyer le son à un service de reconnaissance.

microphone
  → préparer l’audio et former de courtes trames
  → extraire les caractéristiques attendues par le modèle
  → effectuer l’inférence ONNX
  → lisser les scores et appliquer les règles de détection
  → émettre un événement de mot-clé
  → lancer l’action de l’application ou de l’appareil

Une fois le modèle et le moteur installés, l’inférence peut fonctionner sans connexion Internet. Cela réduit la dépendance au réseau et permet de garder l’audio sur l’appareil. L’exécution locale ne garantit pas à elle seule la confidentialité ni une faible consommation : il faut aussi gérer les autorisations du microphone, la capture audio, le moteur et l’énergie consommée.

ONNX ne signifie pas que chaque modèle fonctionne sans adaptation sur toutes les puces. L’appareil cible doit disposer d’un moteur ONNX compatible et de ressources suffisantes. Les microcontrôleurs peuvent nécessiter un autre format ou un moteur optimisé, comme TensorFlow Lite Micro. Il faut valider toute la chaîne sur le matériel final.

Le fichier du modèle ne suffit pas

Un modèle renvoie généralement des scores pour des trames audio ; l’application décide à quel moment ils correspondent à une commande. Réagir à un seul score qui dépasse un seuil peut entraîner des commandes manquées, des répétitions ou de faux déclenchements.

Un détecteur pratique peut exiger plusieurs trames consécutives, appliquer un délai de récupération après une détection et choisir les seuils à partir d’essais avec de la parole ordinaire et du bruit ambiant. Les commandes qui se ressemblent à l’oreille sont plus difficiles à séparer. Des expressions courtes aux sons distincts facilitent généralement la tâche.

Testez avec le microphone, les voix, les distances, les bruits de la pièce et les accents prévus pour le produit. Mesurez à la fois les omissions et les faux déclenchements. De bons résultats sur des exemples synthétiques ne garantissent pas le même comportement dans un boîtier réel ou une pièce bruyante.

Quand choisir un petit modèle KWS ?

Envisagez le KWS lorsque la liste de commandes est courte et définie à l’avance, que chaque phrase correspond à une action claire et que le fonctionnement hors ligne ou le traitement local de la voix est important.

L’ASR est préférable pour dicter du texte, formuler librement des demandes ou traiter des phrases inattendues. Une architecture hybride est également fréquente : le KWS attend le mot de réveil, puis l’ASR prend le relais pour la parole libre.

Une démarche simple pour prototyper

Commencez par noter chaque commande et l’action associée. Choisissez des phrases faciles à distinguer à l’oreille, puis un moteur adapté à la plateforme cible. Reliez les événements détectés aux actions de l’application et testez les faux déclenchements aussi sérieusement que les détections réussies.

Un modèle KWS peut être entraîné pour un vocabulaire personnalisé puis exporté dans un format de déploiement tel qu’ONNX. Le moteur libre onnx-wakeword fournit des intégrations d’inférence pour plusieurs plateformes. Voicute permet de créer des modèles de mots-clés personnalisés.

Transparence : je suis le créateur de Voicute et un mainteneur de onnx-wakeword.