Proportion de noms propres à consonnance étrangère

tout ce que j’ai importé, c’est passé https://github.com/common-voice/commonvoice-fr/tree/5699e59244d14bb14d5b7603b91c934b761c9194/CommonVoice-Data/data en fait, c’est simple, ce sont les scripts shell dans https://github.com/common-voice/commonvoice-fr/tree/master/CommonVoice-Data que j’ai fait tourner, donc si y’a pas de wikipedia.sh c’est que j’ai bricolé et j’ai dû constater que ça faisait plus de mal que de bien et j’ai laissé tombé

le projet common voice a, de son côté, fait des imports de wikipedia, j’ai pas suivi, et je sais juste que c’est avec https://github.com/common-voice/cv-sentence-extractor

c’est bien pour ça que pour les imports français j’ai tenu à :

  • avoir des scripts
  • avec les paramètres de reproduction
  • qui génèrent des données finales dont on a la traçabilité avant ajout

Pour ce qui a été fait via Sentence Collector et l’extracteur mentionné avant, je n’ai pas d’autre bonne solution, et en débattre dans https://discourse.mozilla.org/c/voice/239 est la meilleure façon de faire avancer le problème

Alors il y a eu plusieurs publis sur Common Voice, je les aies pas lues

Les utilisations de ton modèles seront-elles sur un français commun parfait ? Il faut quelque chose utilisable au quotidien.

Ensuite, ne pas oublier que les imports Sentence Collector sont la majorité maintenant, de ce que j’en ai entendu la dernière fois. Ces imports nécessitent aussi d’être validés par plusieurs personnes avant d’être acceptés.

Je dis pas qu’il n’y a pas de curation à faire, bien au contraire cf https://github.com/common-voice/commonvoice-fr/issues mais à l’époque de deepspeech j’ai déjà pas eu le temps de le faire, maintenant que je bosse plus du tout autour de ces thématiques c’est encore pire

Oui et non. Moi le premier certaines tournures d’ancien français c’est pas immédiat, mais :

  • c’est pour ça qu’il y a les fonctions signaler / passer, si la personne ne sent pas à l’aise il n’y a aucun soucis à passer
  • du point de vue du modèle ça peut être pertinent d’avoir des enregistrements de termes qui ne soient pas en français mais qui peuvent avoir leur place dans une phrase en français

Point important : ça n’est que mon opinion de quelqu’un qui a bossé sur le modèle pour essayer d’en faire un truc qui marche pour de vrai (avec l’aide de gens très sympas de eSup Pod) et même si ça n’a pas été fait dans le cadre d’une publi, j’ai constaté les grosses améliorations apportées par l’augmentation importante du volume de français sur Common Voice.

Mais je veux pas non plus qu’on imagine que c’est « la position officielle du projet Common Voice FR », ça reste mon opinion, et je trouve très important ce travail de curation, parce que j’ai aussi vu passer pas mal de déchets (et pas que dans Common Voice) quand j’ai bossé sur les importeurs dans deepspeech.

Et à la fin, c’est bien ceux qui font le travail d’amélioration comme celui que tu proposes qui décident :slight_smile:

Oui, mais c’est quelque chose que j’avais suggéré y’a longtemps, je sais pas si hillary a pu avancer dessus, mais avoir des « profils » et pouvoir identifier des phrases dans certaines catégories permettrait de résoudre ça et améliorer l’utilisation pour les enfants, les personnes pas à l’aise avec le français, en évacuant ces phrases (parce que tout le temps faire « passer » ça peut être pénible à la longue)

Tu as fait un gros travail de catégorisation et de curation, ça serait vraiment triste que ça parte à la poubelle.

Dernier point, tu mentionnes

J’imagine que tu parlais de moi et donc j’insiste, même si je suis toujours salarié, même du temps de DeepSpeech c’était pas mon affectation principale, et même si je pouvais y passer du temps de travail (et des déplacements, pas mal), je n’étais pas dans l’équipe Common Voice. J’ai essayé de faire en sorte que d’autres aussi prennent en charge le projet, et la porte reste très grande ouverte.

On peut sortir les chiffres si vous voulez.

Modèle 0.6:

  • Common Voice FR (v5.1): ~490h
  • Total: ~1340h
  • WER sur CV: 30.12%
  • WER moyen: 29.11%

Modèle 0.8:

  • Common Voice FR (v8.0): ~826h
  • Total: ~2’551h
  • WER sur CV: 37.02%
  • WER moyen: 21.54%

C’est difficile de tirer un constat définitif sur deux point de donnés mais globalement voici ce que j’en conclus:

  1. Le WER moyen diminue avec l’augmentation de données de qualité.
    (~300 heures d’audio ont été remplacé par des nouvelles données de meilleur qualité en plus de ~1200h additionnelles).

  2. L’ajout de ~340h d’audio dans CV a fait augmenter le WER sur celui-ci de 7.1%.
    (On pourrait s’attendre à une légère augmentation de la difficulté lié au nouvelles données cependant on peut aisément constater que la version 8 de CV-fr possède un taux d’erreur par phrase plus élevé que la version 6 du set).

J’ai envie de dire qu’on arrive à une sorte de consensus, non?

Pour recap, on peut constater que l’ajout de grandes quantités de donnés (d’une qualité suffisante) permet d’améliorer les résultats cependant on pourra toutefois constater qu’on a une fâcheuse tendance à accumuler les erreurs au fils des ajouts, le bruit prenant de plus en plus de place face au signal.

De mon côté, j’ai pas mal fouiné dans CV, en voulant filtrer les données avant l’entraînement, la salle matrix de CommonVoice-Fr en sait quelque chose :sweat_smile:

Donc un ménage de printemps je dis pas non mais maintenant c’est surtout l’équipe de CommonVoice qu’il va falloir convaincre.

Il faut aussi garder à l’esprit que le set de donnés ne doit pas être parfait! La réalité ne l’est pas. Notre set doit simplement être représentatif proportionnellement à la langue orale.

La robustesse d’un modèle est un concept tout à fait tangible et mesurable (c.f différence entre le model 0.8 et 0.9). On veut quelle petites erreurs qu’un être humain lambdas pourrait commettre (c’est du signal ça, pas du bruit).

Comment faire la différence? On a cette super page de critères depuis quelques temps, elle est au poil honnêtement.

:loudspeaker: Par expérience, mon humour souvent naze et parfois mal compris pourrait faire réagir certain·e·s d'entre vous. Mes excuses par avance si c'est le cas, ce n'est pas volontaire, il n'y a pas de volonté de mauvais esprit de ma part.

:thinking: /me, hier : “Je suis un vieux routard de Wikipédia, j’aime clarifier les trucs pas clairs dans les aides et les documentations de modèle. Je pourrais me définir comme WikiGnome. Or, là, je me dis qu’il y a BEAUCOUP de mots étrangers dans mes échantillons, et je me dis que les règles sont pas claires… Donc je vais laisser un petit message sur un fil vieux de plus de 18 mois, confiant dans la communauté pour me répondre, mais sans grandes attentes. Qui ne tente rien n’a rien !”

:exploding_head: /me, 24 h plus tard : “WHAT ??? Qu’est ce que j’ai dit ou fait pour avoir 10 réponses, et plusieurs pages de lecture ???”

:face_with_monocle: /me, après avoir tout lu : "Bon… Va falloir répondre maintenant. "

:loudspeaker: Ce qui suit est donc une tentative de rattrapage de wagon :railway_track: :train: :twisted_rightwards_arrows: :repeat_one:, donc n’hésitez pas à tirer sur l’ambulance m’expliquer/corriger ce que je dis/m’envoyer sur la bonne page (“RTFM” is an acceptable answer …with the link) (No I am not taking about Zelda! :elf: Stay focus !)

Bon, heureusement, sur internet :globe_with_meridians:, on n’est jamais perdu ! :world_map: :round_pushpin: On est là.

En préambule, je tiens à affirmer que je ne voulais pas mettre de l’huile sur un feu :fire: qui avait l’air de couver. :fire_extinguisher:En lisant ton post initial et les réponses, drzraf, je me suis dit, comme skeilnet tout à l’heure, que ton travail était une bonne idée, et qu’il fallait en faire quelque chose. …Et je suis d’accord, lissyx, que des réponses avaient été données.
(…L’honnêteté m’oblige aussi à dire que je ne retrouve pas mes petits dans https://discourse.mozilla.org/c/voice/239, mais c’est sans doute le manque de pratique du forum et du projet.)
Et tant que j’y suis à lancer des fleurs, je suis bien conscient que c’est un projet participatif, chacun fait ce qu’il peut. Merci :pray: à vous trois d’avoir repris le sujet au vol !

Je commence par la fin, en bottant en touche sur toute la partie suppression des données :recycle: :put_litter_in_its_place:. Je ne connais pas assez (pour l’instant) ni la programmation, ni le projet, ni les critères pour prendre à ma charge les propositions et méthodes de correction :exploding_head:.
Amha, je vais plus faire des dégats qu’arranger les choses pour l’instant :-1:.

:warning: Attention, je ne dis pas que le débat en cours ne m’intéresse pas, bien au contraire, je dis juste que vous avez pour l’instant des discussions stratosphériques :satellite: :artificial_satellite: par rapport à mes connaissances sur le projet, et par rapport à des newbies :man_student: :woman_student:.

:thinking: Si la meilleure façon de ne pas avoir de la donnée moisie en sortie, c’est de ne pas la mettre à l’entrée (Garbage in - garbage out, en effet), il reste à définir les critères (d’entrée) pour les futurs apports, et comment nettoyer les entrées existantes. Et c’est laaaaaaargement hors de ma portée :artificial_satellite:. J’ai cherché si Hillary avait lancé un sujet sur cette question, mais je n’ai pas trouvé (help needed :sweat_smile:).

Cela étant… Mon objectif initial était beaucoup plus raz des pâquerettes :sunflower: (oui, cet emoji est un tournesol, mais là n’est pas la question), et avait pour but d’aider les “nouveaux” :woman_student: :man_student: (…j’en fais partie !) à ne pas rajouter du bruit sur le signal. …Plus exactement, clarifier :mag: ce qui EST du bruit de ce qui est du signal :loud_sound: :vs: :signal_strength:.

Désolé si j’ai l’air de radoter, ma question initiale portait sur une éventuelle amélioration/complémentation :arrow_heading_up: de la page que tu cites, skeilnet, c.à.d. https://commonvoice.mozilla.org/fr/criteria. Elle est au poil pour tout ce qu’elle décrit.
…Mais elle POURRAIT expliquer s’il faut rejeter/passer/garder les noms exotiques. Ce n’est ni décrit dans la version VF, ni explicité dans la version EN. Et mes recherches dans le forum n’a rien donné… Si ce n’est ce post, qui avait l’air de dire, conformément à je ne sais plus quelle page de règle :straight_ruler: :exclamation: ** que je ne retrouve pas, qu’on devrait se limiter à l’alphabet latin, et donc qu’on devrait “supprimer” les mots non français. …Sauf que, comme les réponses de ce fils l’indiquent, depuis, les règles se sont (ou pas) assouplies :triangular_ruler: :question:. Bref, la nature ayant horreur du vide, nous sommes dans un flou artistique :art:, perdus dans le brouillard :cloud:, sans boussole :compass: pour naviguer.

** EDIT 2 : je parle de cette page : how to, qui décrit : " Ajouter de nouvelles phrases : (…) Lettres étrangères. Les lettres doivent exister dans la langue que l’on doit parler. Par exemple, « ж » est une lettre de l’alphabet russe mais n’est jamais utilisée en français et ne devrait donc jamais apparaître dans un texte source en français." :sweat_smile:

J’insiste, je venait humblement requérir l’avis de l’Oracle :hindu_temple: de ceux qui connaissent le projet :man_teacher: :woman_teacher:, pour ne pas faire n’importe quoi, et permettre aux nouveaux :man_student: :woman_student: (j’insiste encore) de savoir quoi faire dans les situations où il y a des mots qui ne sont pas à consonnance bien rançaise * (et je ne dis pas de chez nous, puisque la :world_map:francophonie, ce n’est pas la :fr:France…).

Voilà voilà… Je vous souhaite pleins de bonnes choses, et je suis impatient de lire vos réponses. :dove: & :love_letter:.

* :laughing: Celle là, elle est un peu capillotracté, je fais référence au nom de ce sub dans Reddit : https://www.reddit.com/r/rance/ …Encore une fois, c’est une blague naze, n’allez pas chercher :clock12: à :clock2:.

EDIT :
:man_facepalming: J’ai oublié de demander ce que signifie

  • WER sur CV: 30.12%
  • WER moyen: 29.11%

…J’avoue que j’ai pas beaucoup cherché, mais j’ai pas trouvé :frowning: :sweat_smile:.

:pushpin: Message qui sera utile plus tard.
Pendant qu’on y est, une fois qu’on aura tranché le débat :left_speech_bubble: :speech_balloon: :ok:,
il faudra aller ici :
https://github.com/common-voice/commonvoice-fr/issues/21
pour retrouver le dossier des règles de validation.
(qui au jour de l’écriture de ces lignes est absent pour FR. yakafokon.)

Ouvre un bug sur github pour qu’elle puisse être plus personnalisée ? Ou lance la discussion sur Discourse avant ?

Pas de soucis, faut juste pas avoir peur de se lancer, y’a assez peu de gens qui s’occupent du projet FR, donc finalement assez peu de cadre. Avec les avantages et inconvénients que ça a …

J’ai oublié de demander ce que signifie

WER sur CV: 30.12%
WER moyen: 29.11%

…J’avoue que j’ai pas beaucoup cherché, mais j’ai pas trouvé

Oups :smile: C’est assez simple en fait, lorsque qu’un modèle est entraîné, on utilise un sous-ensemble représentatif de nos données pour représenter les données du monde réel (set de données de test).

Le WER (en anglais Word Error Rate) qu’on peut traduire par “taux d’erreur par mot” est un indicateur très utile (c’est pas le seul) qui nous permet (dans de bonne conditions) de comparer des modèles entre eux. En règle générale on aimerait ce taux au plus bas (dans les fait c’est plus complexe bien-sûr).

30% sur CommonVoice en français c’est dans les clous mais ça démontre bien la complexité du set (les erreurs qui s’y cachent aussi :smile:).

WER sur CV

C’est le taux d’erreur par mot sur CommVoice-FR uniquement.

WER moyen

C’est le taux d’erreur par mot moyen sur touts les jeux de données (de test) qu’on a utilisé (c.f. la page du modèle en question qui contient généralement ce genre de détail croustillant).

Pour revenir à nos moutons, il nous faut en fait un ambassadeur de la communauté francophone pour représenter nos intérêts auprès du projet CommonVoice dans sa globalité mais aussi pour pousser nos questions et suggestions spécifiquement francophones dans un contexte plus global. C’est qu’on peut avoir de bonnes idées quand on s’y mets! Les autres communauté linguistiques pourraient en profiter (et vis-versa bien-sûr).

1 Like

skeilnet, si cela vous est possible je serai vraiment ravi d’avoir un retour sur le WER résultant du dataset ainsi modifié.

Pourquoi tu vires tous les noms propres ? (c’est pas forcément que ça me dérange, mais le raisonnement est pas forcément bien clair sur le bug, alors que je pense que les ratios dont tu parles pourraient probablement aider au niveau général du projet)

1 Like

ça serait sûrement une bonne idée de découper ton commit en plusieurs, chacun se focalisant sur certains aspects (noms propres, noms à consonance étrangère, etc).

Certes c’est semi-automatisé, mais je ne peux pas vraiment “répartir”.

Le principe est :

  • d’extraire le capitalized
    • & black-magic sur apostrophes et tirets + case-insensitive
  • Filtrer pour autoriser tout ce qui fait partir de DB “communes”, soit noms communs (français + anglais) + Morphalou (toutes les déclinaisons possibles) + DB de toponymes (grandes villes, monde, pays) + grosse DB de prénoms
    • & black-magic sur apostrophes et tirets + case-insensitive
  • Pas 100% fool-proof mais une blacklist finale de 238k mots (essentiellement noms de famille + toponymes + typos/mots mal-orthographiés + néologismes + dieux grecs/latins + quelques trucs du genre “Babar” ou “Volkswagen” …)
    • Sur l’Assemblée Nationale c’est surtout beaucoup de “La parole est à Dugenoux” qui sont stripées
    • Pour le littéraire ce sont des noms de personnages ou d’auteurs
    • Pour le reste quelques noms de marques déposées
    • Mais c’est surtout sur les gros sets wiki* et sentence-collector.txt que du charabia est massivement retiré

Pour l’anecdote, on ne supprime pas impunément 238k patterns en case-insentive sur 150MB. Pour descendre de 10h de processing a une durée plus décente j’ai du passer par de la compilation de patterns (en les combinant par 25k pour ne pas (trop) swapper) afin d’aboutir un à une durée de processing d’à peu près une heure.

C’est entre autre (en plus d’une question de simplicité) la raison pour laquelle tout le stripping se fait en une seule fois, en une étape finale, plutôt qu’en plusieurs “commits thématiques” qui demanderaient de refaire tout le process pour chaque thématique.

Tiens je viens de voir Question about CV Sentence Extractor quality and your experience IMHO tout ce travail que tu fais pourrait bénéficier à ce thread !

1 Like

Bon, j’ai avancé le sujet, et ai fait une ébauche de commit pour les rules FR.

Qui ne contrôle absolument pas les caractères exotiques (puisque en fait il faudrait refuser les phrases avec des lettres hors alphabet latin, au lieu de les transformer)

mais qui corrige les acronymes, et d’autres trucs…

please have a look at :

Comme on dit, qui peut le plus, peut le moins :slightly_smiling_face:

Tu peux très bien faire ça après coup, à partir du jeu de données proposé par le projet. Suffirait d’un petit script shell qui analyserait les transcriptions pour ne garder que les échantillons dont l’ensemble des mots se trouve bien dans le dictionnaire français (+ éventuellement les prénoms, noms propres, marques et autres lieux communs par chez nous).

De nos jours, en France, énormément de gens (de tout âge) sont passionnés de mangas ou d’animes japonais, de séries ou de musique coréennes (la fameuse kpop), de football (avec des joueurs étrangers aux noms exotiques) et ainsi de suite. On peut aussi parler de l’actualité. Depuis la guerre en Ukraine, on entend de nombreux noms aussi bien russes qu’ukrainiens. Je trouve donc important d’avoir tout un tas de noms issus de pays lointains dans notre jeu de données.

Même pour l’anglais, même si de plus en plus de français arrivent à s’en sortir, il y a encore énormément de gens qui vont le parler aussi bien qu’une vache espagnole. Ce qui ne les empêchera pas de baragouiner quelque chose à leur zapette et d’avoir la surprise de voir Google Assistant réussir à trouver le titre qu’ils cherchaient (ce qui est bien souvent infiniment plus rapide que d’utiliser le clavier virtuel pour lancer une recherche Netflix ou autre).

J’espère qu’un jour, les modèles libres basés sur Common Voice arriveront eux aussi à retranscrire correctement n’importe quel titre d’œuvre et autre nom propre provenant de pays lointains, et ce, peut importe que l’on maîtrise ou non la langue :slightly_smiling_face:

Je suis d’accord sur la vision mais il y a un écueil : Il faut quand même que les mots dictés soient compris par le locuteur (et/ou que ce dernier ait une information sur la culture d’origine afin d’en inférer les règles de prononciation). Dans le cas contraire, créé des association “syllabe - son” erronées pour lesquelles tout le monde est perdant.

Personnellement, à voir le contenu du lexique et après avoir validé quantité de phrases, j’en suis arrivé à penser que seul le “pot commun” du lexique devrait être “language-based”. Le reste devrait être le fruit de lexiques spécialisés annotés dès lors que cela contient des anglicisme, mots latins ou japonais et autres termes à consonance bien distincte (biologie, informatique, géographie, adresse et noms propres …)

En effet, extraire/filtrer les termes et phrases propres à ces derniers lors d’une phase d’entraînement est très difficile sans l’annotation d’un set d’origine. (Et dans tous les cas, il faut des dictionnaires spécialisés)

Pour l’instant, l’idée est surtout d’éviter :

  1. De mauvaises performances liées à des mapping portant sur des termes inusités et trop souvent mal prononcés (ratio d’erreur très élevé)
  2. De réduire la barrière d’entrée causée par des phrases absconses qui rendent pénible la participation au projet

Concernant une réduction de la barrière d’entrée et la réalisation simple de lexiques spécialisés, je me permet de mentionner cette proposition que j’avais faite par le passé :

1 Like

C’est pas aussi simple malheureusement. Il faut que les modifs soient publiées dans une nouvelle release de CommonVoice pour pouvoir entraîner un nouveau modèle de comparaison.

C’est aussi bien de noter qu’on utilise pas tout le set de données.

Exactement! Par example, on utilise python (plus versatile qu’un shell) pour filtrer nos phrases lors de l’importation des données d’entraînement, avec l’importateur de données pour CV et un filtre de caractères pour le français (ça exclut déjà pas mal de mauvaises phrases - les plus detrimental à l’apprentissage en tout cas - ).

Vu qu’une nouvelle release apporte aussi son lot de nouvelle donnés, une comparaison directe ne sera pas vraiment possible mais on pourra quand même indirectement constater l’impact des modifications sur le WER.

Dans l’immédiat, je suis quand même censé réduire ma consommation énergétique de 15% pour les raison qu’on connait tous… :frowning:.

J’ai quand même deux trois idées sympa pour le prochain modèle de français donc je garde ça dans un coin de ma tête et j’espère que je pourrais les implémenter dans un futur proche.

  1. Concernant https://github.com/common-voice/common-voice/pull/3786 les phrases disposant déjà d’un enregistrement vocal ne seront pas retirées => donc pas d’impact sur le WER en perspective (malheureusement)

  2. Par contre il est tout à fait possible de générer la liste des enregistrements vocaux de phrases inadéquate.

  3. Dès lors il vous serait possible, sur votre release du dataset existant, de les supprimer (retirer de la liste des fichiers sur lesquels s’entraîner/tester) avant de relancer un entraînement (et comparer le WER)

Qu’en pensez-vous ? Souhaitez la liste des phrases ? Ou bien celle des fichiers correspondants aux phrases si vous préférez ?

ça serait possible de remplacer les fichiers TSV d’origine avec les modifs et de ré-importer les données. Faudrait toutefois faire une session d’entraînement à partir de zero (3-4 jours d’entrainement quand même). On pourrait un peu tricher en utilisant la precision mixte (AMP) pour (un peu) accélérer le processus mais ça fait quand même long (et cher) pour finalement pas grand chose (le modèle ne serait pas utilisable en l’état à cause d’AMP ou par manque d’amélioration significatives).

Quand je parles d’économie d’énergie, c’est exactement ce genre de run inutile que j’aimerais éviter. Si j’entraîne un modèle c’est pour le publier et qu’on puisse tous l’utiliser :slight_smile:.
Il me faut assez de bonnes raisons de penser qu’un nouveau run est justifié (au niveau de l’impact sur le WER/CER). Mon meilleur modèle (v0.9) atteint déjà 19% de WER moyen et 31% de WER sur CV-FR. Il va falloir beaucoup de petites optimisations un peu partout pour faire mieux.

Comme mentionné plus haut, j’ai quelques idées pour la version 1.x du modèle de français donc je ferais de toute façon un nouveau run, d’ici là (j’espère) que toutes ou une partie des modifs auront été ajouté au set.
J’ai espoirs que ce nettoyage de printemps en plus de quelques autres optimisations et l’ajouts de nouvelles données puissent réduire le taux d’erreur (moyen) à moins de 15% par mot. :crossed_fingers:

  • “31% de WER sur CV-FR” me paraît absolument énorme et je ne comprends pas pourquoi CV-FR s’avérer tellement plus difficile qu’un dataset “commun”.

  • 4 jours d’entraînement c’est beaucoup. Personnellement ça ne me paraît pas valoir le coup même si certains pourraient tout aussi légitimement arguer qu’enlever 150k items est suffisamment significatif pour mériter d’être testé.

  • Après, le problème c’est que sans PR, pas de release donc pas de test de régression du WER. Mais sans test de régression du WER, pas de PR (aussi radicale) donc pas de release non plus.

  • J’aurais aimé qu’un matheux / expert AI vienne prouver que si "modèle A performe mieux après X epochs que modèle B", alors “modèle A meilleur que modèle B pour toute epoch ultérieur”. Ça permettrait un diff du WER sur des modèles partiellement trainés et moins coûteux à générer.

CommonVoice c’est notre set de données le plus représentatif du monde réel donc forcement plus complexe qu’un set manufacturé pour un domaine précis. Comme on a vu y’a aussi pas mal d’erreurs qui font augmenter le WER.

Je ne dis pas que ça n’aura pas un impact significatif sur le WER de CV. Le truc c’est que CV-FR ne représente que 1/3 de mon mix de données. Donc même si on arrivait par miracle à enlever toutes les erreurs et à remplacer les heures perdues par de nouvelles données de meilleurs qualité, l’impact sur le WER moyen serait négligeable. D’où l’idée d’enchaîner les optimisation un peu partout.

Avec ou sans PR, y’aura une de toute façon d’autre releases. Il me semble pas non plus que l’équipe de CommonVoice s’intéressent particulièrement à l’impact sur le WER puisque c’est pas eux qui s’occupent de l’entraînement des modèles. Ils utilisent le retour de la communauté pour ça.

ça serait pas fiable. Il faut atteindre la convergence sur les données pour pouvoir comparer des modèles entre eux.

On pourrait utiliser la precision mixte pour entertainer deux modèles sur CV-FR uniquement (avec et sans les modifs) sans scorer. Juste pour comparer.

On en reviens au fait qu’il faille entraîner un (ou plusieurs) modèle(s) qui ne sera/ont utile que pour avoir une idée de l’impact sur le WER. En d’autre termes, un modèle inutilisable pour la transcription du français dans le monde réel.

En temps normal j’aurais été ravis de satisfaire ma curiosité en faisant les calculs mais c’est juste pas rentable en terme de coûts d’énergie pour le bénéfice escompté.