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 
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 ).
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).
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)
ç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 :
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 !
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 
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
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 :
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é :
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… 
.
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.
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)
Par contre il est tout à fait possible de générer la liste des enregistrements vocaux de phrases inadéquate.
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 
.
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. 
“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é.