Remporter le défi ASR en swahili sur un seul GPU de 16 Go

Comment une machine apprend à comprendre la parole des bus, des marchés et des bureaux animés. Première place avec un taux d’erreur sur les mots (WER) de 17,81 % au classement privé de la compétition, avec un modèle entraîné sur un seul GPU emprunté.

Vous êtes-vous déjà demandé comment une machine apprend à comprendre une langue, non pas à partir d’un texte proprement tapé sur un écran, mais à partir de la vraie parole humaine, celle des bus, des marchés, des bureaux animés ou des maisons tranquilles ? Une parole pleine d’interruptions, de bruits de fond, d’accents, de rires et d’hésitations ?

C’est à cette question que nous voulions répondre en participant à l’AI for Good Swahili ASR Challenge sur Zindi. Nous avons fini par remporter la compétition.

Notre système a obtenu un taux d’erreur sur les mots (WER) de 17,81 % au classement privé et de 18,22 % au classement public. Il traitait chaque enregistrement en 1,24 seconde environ et a transcrit l’intégralité du jeu de test, soit 4 089 enregistrements, en une heure et vingt-quatre minutes. Nous avons entraîné tout le système sur un seul GPU emprunté.

Mais le score n’est pas l’aspect le plus important de ce travail.

Ce qui comptait pour nous, c’est que ce défi reflétait bon nombre des conditions que nous rencontrons quand nous construisons des technologies de la parole pour les langues africaines : des enregistrements bruités, une puissance de calcul limitée et des langues encore mal représentées dans les plus grands modèles d’IA.

De la parole réelle, pas de la parole lue

Le swahili n’est pas le hausa, mais beaucoup de problèmes techniques sont semblables. Une grande partie des données vocales disponibles en ligne est de la parole lue. Quelqu’un s’assoit dans une pièce calme, utilise un bon microphone et lit des phrases préparées. Ces données sont propres et faciles à annoter, mais les modèles entraînés uniquement sur elles ont souvent du mal face à de vraies conversations.

Dans la réalité, les gens marquent des pauses, s’interrompent, changent d’avis, parlent avec des accents différents et prononcent les mots différemment selon leur région d’origine. Ils parlent aussi dans des lieux où il y a de la circulation, de la musique, du vent, des marchés et d’autres personnes qui parlent à côté.

C’est pourquoi nous avons entraîné notre modèle sur le jeu de données SALT de Sunbird, un corpus conversationnel en swahili avec plusieurs locuteurs et des dialogues naturels. Ces données étaient plus difficiles à exploiter, mais elles étaient bien plus proches de l’environnement dans lequel le modèle serait finalement utilisé.

Partir d’un modèle distillé

Nous n’avons pas entraîné le modèle à partir de zéro. Nous sommes partis d’un checkpoint distillé de Whisper, déjà entraîné sur les données swahili de Common Voice 12. Le modèle avait ainsi une compréhension de base des sonorités du swahili avant que nous commencions à l’affiner.

Un modèle distillé est un modèle plus petit, entraîné pour reproduire une grande partie des performances d’un modèle plus grand. Il demande moins de mémoire et de puissance de calcul, tout en conservant une grande partie de la précision du modèle d’origine.

C’était important, car il ne s’agissait pas seulement de construire un système précis. Le système devait aussi être assez petit et efficace pour tourner sur un appareil, au lieu de dépendre d’un grand serveur dans le cloud. Comme le modèle de départ comprenait déjà un peu le swahili, nous pouvions consacrer nos ressources d’entraînement limitées à l’aider à gérer de vraies conversations et un audio difficile.

Entraîner le modèle à s’attendre au bruit

Une façon courante de traiter les enregistrements bruités consiste à nettoyer l’audio avant la transcription. Le système essaie de supprimer le bruit de la circulation, des marchés ou d’autres conversations avant d’envoyer l’enregistrement au modèle de parole.

Nous avons choisi une autre approche. Au lieu d’essayer de supprimer le bruit, nous avons entraîné le modèle à s’y attendre.

Pendant l’entraînement, notre collateur de données personnalisé sélectionnait des sons dans une collection de bruits urbains d’Afrique de l’Est, notamment la circulation, les marchés et des conversations proches. Il mélangeait ces sons aux enregistrements d’entraînement à différents niveaux de volume. Le modèle entendait chaque fois une combinaison différente. Il ne pouvait pas se contenter de mémoriser un seul type de bruit de fond. Il devait apprendre à reconnaître la parole même en présence d’autres sons.

C’est peut-être l’élément le plus important de tout le système. Un modèle qui n’a entendu que des enregistrements de studio propres aura du mal la première fois que quelqu’un essaiera de l’utiliser dans un bus, au bord d’une route ou au milieu d’un marché animé.

Un seul GPU, emprunté

Nous avons entraîné le modèle sur un seul GPU NVIDIA T4 doté de 16 Go de mémoire, dans un notebook Kaggle gratuit. Cette contrainte a façonné la manière dont nous avons construit le système.

Au lieu de mettre à jour toutes les parties de Whisper, nous avons gelé le modèle principal et entraîné de petits adaptateurs LoRA dans ses couches d’attention. Cela nous a permis d’ajuster le modèle en n’entraînant qu’un faible pourcentage de ses paramètres. Nous avons aussi chargé le modèle en précision 8 bits pour réduire ses besoins en mémoire. L’entraînement en précision mixte et le gradient checkpointing nous ont permis d’économiser encore davantage de mémoire.

Avec ces changements, nous avons entraîné le modèle avec une taille de lot de quatre et utilisé l’accumulation de gradients pour atteindre une taille de lot effective de huit. Nous avons utilisé un taux d’apprentissage de 1e-5 et 500 étapes d’échauffement, et retenu le checkpoint qui avait l’erreur de validation la plus faible.

Ces méthodes n’ont rien d’inhabituel ni d’expérimental. Ce sont des outils standards pour entraîner des modèles avec des ressources limitées. C’est justement pour cela qu’elles comptent. Construire un modèle de parole compétitif pour une langue peu dotée n’a pas exigé l’accès à un grand laboratoire de recherche. Nous l’avons entraîné sur du matériel auquel un étudiant pouvait accéder gratuitement. Pour beaucoup de personnes qui travaillent sur les langues africaines, c’est la réalité.

Le décodage

Pendant la transcription, nous avons utilisé une recherche en faisceau (beam search) avec trois sorties possibles et une pénalité de répétition de 1,2.

Une méthode plus simple, appelée décodage glouton, choisit à chaque étape le mot suivant le plus probable et ne revient jamais en arrière. Cela peut bien fonctionner sur un audio propre. Sur des enregistrements bruités, en revanche, le modèle peut commettre une erreur dès le début, perdre le fil de la phrase et se mettre à répéter les mêmes mots. La recherche en faisceau garde plusieurs transcriptions possibles ouvertes en même temps. Elle demande un peu plus de calcul, mais elle donne au modèle de meilleures chances de se remettre d’une incertitude.

Nous n’avons pas utilisé de modèle de langue séparé, ni combiné plusieurs modèles en un ensemble. Ces deux approches auraient peut-être amélioré le score final, mais elles auraient aussi rendu le système plus lourd et plus difficile à déployer. Notre objectif n’était pas seulement de bien figurer au classement. Nous voulions construire quelque chose qui puisse, de façon réaliste, être utilisé.

Ce que signifie 17,81 %

Un WER de 17,81 % signifie qu’environ un mot sur six est mal transcrit. Ce n’est pas assez précis pour des tâches qui exigent une trace écrite parfaite, comme la dictée professionnelle. Mais cela peut quand même être utile lorsque l’objectif est de comprendre ce que quelqu’un demande.

Même quand un mot est erroné, le reste de la phrase fournit souvent assez de contexte pour comprendre ce que veut dire la personne qui parle. Cette distinction entre produire une transcription parfaite et comprendre la demande d’une personne est importante pour les systèmes que nous construisons.

Quatre leçons que nous appliquons au hausa

1. Les données conversationnelles valent davantage que des enregistrements parfaitement propres lorsque le système sera utilisé dans de vraies conversations.
2. Le bruit doit faire partie de l’entraînement. Nous ne pouvons pas supposer que les gens parleront toujours depuis des pièces calmes ou dans des microphones coûteux.
3. L’affinage économe en paramètres (parameter-efficient fine-tuning) rend possible une recherche sérieuse sur la parole sans gros budgets de calcul. C’est particulièrement important pour les chercheurs et les communautés les plus proches des langues peu dotées.
4. Le décodage compte. Sur un audio difficile, la différence entre le décodage glouton et la recherche en faisceau peut être celle qui sépare une réponse utile d’une phrase répétée qui ne mène nulle part.

Le hausa fait face à bon nombre des mêmes défis que le swahili, mais avec encore moins de jeux de données, de modèles et de ressources techniques disponibles.

Le code complet d’entraînement et d’inférence est disponible sur github.com/SalifouAbdourahamane/swahili_asr_sota_model. Une explication technique plus détaillée de la solution est également disponible sur Zindi.