Open ASR Leaderboard : mise à jour Monsoon pour l’hindi et l’anglais indien

Un leaderboard peut vous dire que deux systèmes de reconnaissance vocale sont presque à égalité. Monsoon ajoute la question qui compte vraiment : à égalité pour quels locuteurs, quelles régions, quels appareils et quelles conventions d’écriture ? Les nouveaux jeux d’évaluation en-IN et hi-IN rendent l’Open ASR Leaderboard plus pertinent pour évaluer l’ASR multilingue. Mais comme les enregistrements publics restent courts, leurs résultats doivent être interprétés avec prudence.

En bref : Monsoon montre enfin pourquoi les modèles se départagent

L’Open ASR Leaderboard intègre désormais deux jeux d’évaluation Voice Arena : Monsoon en-IN pour l’anglais indien et Monsoon hi-IN pour l’hindi. L’anglais indien apparaît dans les colonnes principales du classement et contribue à l’Average WER affiché en tête. L’hindi est présenté dans la vue d’évaluation multilingue : pour obtenir un classement dans cette vue, un modèle doit couvrir les langues sélectionnées.

Les quatre splits publics et privés regroupent 4 888 locuteurs distincts et documentent 12 attributs liés aux locuteurs, couvrant les données démographiques, le contexte, la géographie et les téléphones utilisés. Les chercheurs peuvent ainsi aller au-delà de la simple question « quel modèle affiche le WER moyen le plus bas ? » et repérer les situations dans lesquelles chaque système devient moins fiable. Monsoon constitue une vraie amélioration pour évaluer la robustesse régionale et le scoring des transcriptions en hindi. Ce n’est en revanche ni une garantie de performance en production ni une mesure représentative de toutes les langues parlées en Inde.

Ce que Monsoon ajoute à l’Open ASR Leaderboard

Monsoon apporte quatre splits de test collectés via le même processus de conversations spontanées. Pour chaque langue, un split public permet de reproduire les scores, tandis qu’un split privé limite les possibilités d’optimisation spécifique au benchmark. L’annonce officielle présente cette sortie comme la première intégration d’une langue indienne dans le contexte multilingue de ce leaderboard.

Le détail des quatre splits

La fiche du jeu de données Monsoon en-IN public indique un audio en 16 kHz, une durée moyenne de 9,6 secondes par clip et une médiane de 10,4 secondes. La fiche Monsoon hi-IN annonce, pour son split public, une moyenne de 6,4 secondes et une médiane de 5,0 secondes. Les quatre splits totalisent 17.00 heures : il s’agit donc d’un benchmark axé sur la diversité, construit à partir de courtes séquences conversationnelles plutôt que d’appels longs.

Du public pour reproduire, du privé pour mesurer la généralisation

Les chercheurs peuvent charger les splits publics depuis Hugging Face, faire tourner leur système de reconnaissance, normaliser sa sortie, puis calculer un score à l’échelle du corpus. Pour en-IN, la fiche du dataset précise qu’il faut diviser le total des insertions, suppressions et substitutions par le nombre total de mots de référence, au lieu de calculer une moyenne des WER clip par clip.

Pour l’hindi, la fiche publique fournit le scorer voi-oiwer, conçu pour les lattices. Voici un exemple minimal de chargement :

from datasets import load_dataset
from voi_oiwer import oiwer

hi = load_dataset(
    "VoiceArena/MonsoonASR-Open-ASR-leaderboard-hi-IN",
    split="test",
)
hypothesis = "replace with your model output for hi[0]"
result = oiwer(hypothesis, hi[0]["lattice"], "hindi")
score, (ins, dele, sub), ref_words = result[0], result[4], result[5]

Les splits privés restent hors d’accès et séparés par locuteur afin qu’une équipe ne puisse pas ajuster son modèle sur chaque exemple d’évaluation. La conception des données privées conserve ces résultats dans des vues agrégées distinctes, sans modifier le classement public par défaut.

La couverture des locuteurs est le vrai changement méthodologique

Le split public en-IN compte 1 444 locuteurs répartis sur 2 102 clips, tandis que le split public hi-IN en compte 468 sur 753 clips. Le tableau de couverture de l’annonce officielle indique que les dix plus gros contributeurs ne représentent que 2.8% à 6.8% de la durée totale, selon le split considéré.

Le score risque ainsi moins d’être dominé par un locuteur très prolifique, un microphone particulier ou une seule manière d’enregistrer. Cela ne rend pas pour autant l’échantillon représentatif. Les 12 attributs collectés portent sur le genre, la date de naissance, la profession, le niveau d’études, la situation matrimoniale, les revenus, le district et l’État d’origine, la ville actuelle, le nombre d’années passées dans le district actuel, le fabricant de l’appareil et son modèle.

L’anglais indien reflète une diversité géographique, pas un accent unique

Le split public en-IN couvre 428 districts d’origine, 30 États et territoires de l’Union, 641 villes actuelles et 556 modèles de téléphones. La répartition régionale est de 35 % pour le Sud, 18 % pour l’Est, 18 % pour le Centre, 16 % pour le Nord et 11 % pour l’Ouest. D’après l’annonce de Hugging Face, aucun État ne représente plus de 13 % des locuteurs.

Les champs native_district, native_state, current_city, years_spent_in_current_district, device_manufacturer et device_model permettent de comparer les différents territoires et appareils. L’« anglais indien » ne correspond donc ni à une seule configuration de microphone ni à un seul accent. Un modèle peut très bien réussir sur une distribution régionale donnée et se montrer moins stable sur une autre, tout en conservant un WER global compétitif.

L’hindi a une couverture différente et un problème de scoring spécifique

Le split public hindi est plus réduit : 1.33 heure, 468 locuteurs, 202 districts et 315 modèles de téléphones. La couverture se concentre dans la Hindi Belt ; l’annonce précise que l’Uttar Pradesh représente environ 40 % des locuteurs hindi collectés. Cette information est utile pour mettre un résultat en perspective, mais elle ne signifie pas que toutes les communautés hindiophones sont représentées de manière équilibrée.

L’hindi comprend aussi des mots d’origine anglaise, du code-switching, des mots composés écrits attachés ou séparés, des variations orthographiques en devanagari et des équivalents romanisés. La fiche du dataset hi-IN stocke donc un lattice dans lequel chaque segment de transcription peut contenir plusieurs formes écrites acceptées.

L’analyse régionale révèle des écarts que le WER global masque

L’exemple régional officiel s’appuie sur le split public d’anglais indien. Huit modèles se situent entre 4.81 et 4.99 de WER, soit un écart de seulement 0.18 point. L’annonce rappelle qu’un jeu de test d’environ cinq heures ne permet pas forcément de départager une différence aussi faible.

Mais lorsqu’on ventile les mêmes résultats entre cinq zones géographiques, la stabilité apparente change nettement :

L’écart plus important traduit une variabilité régionale supérieure pour Voxtral, pas quatre fois plus d’erreurs de transcription. Les faiblesses régionales ne sont pas non plus les mêmes d’un modèle à l’autre. Cela suggère une sensibilité propre à chaque système, sans permettre d’en établir la cause.

Un utilisateur, @FoucqueThomas, a souligné la même distinction après la publication :

« ⚡ L'Open ASR Leaderboard ajoute l'hindi et l'anglais indien (4 888 locuteurs, 12 attributs/clip). Résultat : deux modèles quasi identiques sur le WER global affichent jusqu'à ~4x d'écart selon la région du locuteur. Un benchmark enfin honnête sur la diversité vocale. » — @FoucqueThomas sur X

Si vos utilisateurs sont concentrés dans une région particulière, une égalité au niveau global ne suffit pas pour choisir entre deux modèles. L’exemple ne démontre pas qu’un déséquilibre dans les données d’entraînement soit à l’origine du phénomène régional.

Pourquoi le scoring par lattice est important pour l’ASR multilingue en hindi

Le WER classique suppose une référence canonique. Cette approche fonctionne pour la casse ou la normalisation orthographique, mais atteint vite ses limites avec l’hindi mélangé à l’anglais. Une sortie valide peut utiliser une graphie en devanagari, une forme romanisée, une orthographe issue de l’anglais ou une autre segmentation des mots composés.

Monsoon hi-IN répond à ce problème avec des lattices de références. La publication officielle explique que les variantes candidates sont développées, relues par des linguistes natifs, puis filtrées pour ne conserver que les formes compatibles avec l’énoncé. Une variante valide est ainsi comptée comme correcte au lieu d’être pénalisée simplement parce qu’elle diffère de la transcription choisie par un annotateur.

Pour l’évaluation hindi, le leaderboard utilise l’Orthographically-Informed Word Error Rate (OIWER). Une variante acceptée est considérée comme correcte, tandis qu’une véritable erreur de reconnaissance reste pénalisée. Le commit d’intégration au leaderboard montre comment les données hindi et les vues multilingues par langue ont été ajoutées à l’application.

Cette règle de scoring peut modifier l’ordre des modèles. L’annonce officielle indique que l’aplatissement des lattices hindi en références uniques augmente les taux d’erreur de tous les systèmes testés, mais pas dans les mêmes proportions. Un leaderboard multilingue peut donc devenir plus équitable linguistiquement sans ramener tous les résultats à un seul chiffre universel.

Comment utiliser le leaderboard mis à jour pour choisir un modèle

Utilisez Monsoon pour présélectionner et diagnostiquer les modèles, puis validez les finalistes sur des données audio réellement représentatives de votre usage.

1. Commencez par l’Average WER pour réduire la sélection. L’anglais indien entre désormais dans la moyenne principale du leaderboard. Les modèles performants uniquement sur de l’anglais lu ou non indien sont donc moins à l’abri d’un test conversationnel avec accent indien.
2. Vérifiez la couverture linguistique avant de comparer les moyennes multilingues. Le code source du leaderboard affiche les langues sélectionnées absentes sous la forme NA et indique une valeur de Coverage telle que 3/5. Un modèle n’obtient un rang multilingue que s’il prend en charge toutes les langues sélectionnées. Consultez le code d’intégration.
3. Découpez les données publiques Monsoon selon les champs documentés. Comparez les districts d’origine, les États, les villes, les appareils ou les autres métadonnées disponibles. Cherchez les écarts et les concentrations d’échecs, pas uniquement le meilleur score obtenu sur un sous-groupe.
4. Validez sur un audio représentatif de la production. Testez vos téléphones, vos conditions de bruit, vos habitudes de code-switching, votre VAD et vos durées de parole. Les clips publics de Monsoon durent en moyenne moins de dix secondes : ils ne peuvent pas représenter à eux seuls tous les workloads de centres d’appels, de réunions ou d’agents vocaux.

Sur X, le praticien @PlimmApp a averti que le VAD peut masquer les hallucinations sur les silences lorsque l’évaluation commence par des segments contenant de la parole : « the vad step in your pipeline is also the blind spot… a model that emits fluent text over silence never gets charged for it. » Consultez le commentaire complet. Les équipes qui travaillent sur l’appareil doivent évaluer séparément le VAD, la détection de fin de parole et la gestion des hallucinations.

Ce que Monsoon ne permet toujours pas de conclure

• La taille et le transfert vers les contenus longs : le split public en-IN représente 5.62 heures et le split public hi-IN 1.33 heure ; les clips durent en moyenne 9,6 et 6,4 secondes respectivement. Les petits écarts de score et le comportement sur les longs fichiers doivent être validés séparément.
• La représentativité nationale : une couverture étendue des districts, États et appareils ne constitue pas un recensement pondéré de la population anglophone ou hindiophone en Inde.
• Les explications causales : une corrélation régionale ne permet pas de déterminer si la cause vient des données d’entraînement, de l’acoustique, de la phonétique, du décodage ou d’un autre facteur.
• La capacité prédictive des splits privés : les splits privés, distincts par locuteur, sont conçus pour tester la généralisation, mais leurs exemples ne peuvent pas être inspectés indépendamment.
• L’adéquation aux usages textuels : la recherche, les sous-titres, l’analytique et les transcriptions juridiques peuvent privilégier des conventions différentes pour l’écriture, la normalisation, la ponctuation ou le code-switching.

FAQ sur Open ASR Leaderboard Monsoon

L’anglais indien influence-t-il la moyenne du leaderboard principal ?

Oui. Monsoon en-IN est intégré par défaut au leaderboard anglais et contribue à l’Average WER. Consultez l’inventaire des splits pour connaître les tailles des versions publique et privée.

L’hindi fait-il partie du classement principal ?

L’hindi apparaît dans la vue multilingue. Les langues sélectionnées qui ne sont pas prises en charge sont affichées sous la forme NA, et seuls les modèles couvrant intégralement les langues choisies obtiennent un rang multilingue.

Puis-je télécharger les jeux publics et calculer les scores moi-même ?

Oui. Les fiches en-IN et hi-IN proposent des exemples de chargement. Utilisez une agrégation au niveau du corpus et OIWER pour les lattices hindi.

Pourquoi l’hindi n’est-il pas évalué avec un WER classique ?

Une référence hindi fixe peut pénaliser des variantes valides en devanagari, romanisées, issues du code-switching ou liées à la séparation des mots composés. Le lattice répertorie les formes acceptées pour chaque segment de transcription.

Un WER global plus faible signifie-t-il qu’un modèle est meilleur dans toutes les régions indiennes ?

Non. L’exemple officiel en-IN montre des WER globaux presque identiques, mais des écarts régionaux très différents. Examinez les performances par sous-groupe et testez un audio représentatif avant tout déploiement.

La décision à retenir

Utilisez en-IN pour la présélection fondée sur le score principal, hi-IN et OIWER pour les comparaisons hindi ou multilingues, et l’écart régional comme signal de risque lorsqu’il devient important. Validez ensuite le finaliste sur les caractéristiques audio, le bruit, le comportement du VAD et les conventions textuelles réellement produites par vos utilisateurs.