Post-processing dans les systèmes de reconnaissance automatique de la parole

Introduction

Les systèmes ASR de reconnaissance automatique de la parole fournissent des transcriptions de texte, généralement sous la forme d’une séquence de mots. Cisco utilise des systèmes ASR pour afficher des sous-titres en temps réel pendant les réunions Webex. Mais la lecture de texte sans ponctuation ni lettres majuscules peut s’avérer problématique. En effet, un même texte peut être compris différemment selon sa ponctuation. Imaginez les deux possibilités de ponctuation pour la séquence de mots suivante :

« thank you your donation just helped someone get a job »

Option A : «Thank you! Your donation just helped someone get a job. » (Merci ! Votre don vient d’aider quelqu’un à trouver du travail.)

Option B : « Thank you! Your donation just helped someone. Get a job. » (Merci ! Votre don vient d’aider quelqu’un. Allez vous faire voir.)

Un seul signe de ponctuation et tout peut basculer.

Lors du développement d’un système de post-processing, plusieurs facteurs sont à prendre en compte :

• Des modèles d’une grande exactitude pour la restauration de la ponctuation et l’application de majuscules à partir du texte brut. Une inférence rapide sur les résultats intermédiaires : pour assurer la génération de sous-titres en temps réel.
• L’utilisation de ressources de petite capacité : la reconnaissance de la parole requiert des calculs intensifs ; nos modèles de ponctuation ne doivent donc pas être eux aussi gourmands en calcul.
• La capacité à traiter des mots ne figurant pas au vocabulaire : la ponctuation ou l’utilisation de majuscules doit parfois s’appliquer à des mots jamais rencontrés par notre modèle.

Certaines approches n-grammes conventionnelles [1] sont relativement efficaces, mais elles présentent aussi des inconvénients. Bien que l’inférence des modèles n-grammes soit rapide, même les modèles 3-grammes peuvent nécessiter plusieurs gigaoctets d’espace disque selon le vocabulaire de la langue. La gestion des mots inconnus présente un autre inconvénient. Lorsqu’un mot n’existe pas dans les données d’entraînement, le modèle ne peut pas le traiter de façon habituelle, au détriment de l’exactitude. Les approches modernes utilisent des techniques efficaces mais extrêmement gourmandes en calcul, comme le RNN bidirectionnel [3], ou des architectures de réseaux de neurones basés sur un transformeur et des mécanismes d’attention [2]. Ces modèles présentent une grande exactitude [2] mais peuvent ne pas convenir aux cas d’utilisation de diffusion en direct car ils ont besoin de l’intégralité de la séquence d’entrée pour exécuter l’inférence. Par exemple, lorsque vous n’avez qu’un seul nouveau jeton d’entrée pour un RNN bidirectionnel, vous devez mettre à jour les états masqués de tous les jetons précédemment rencontrés par ce modèle (figure 1).   Certaines approches tentent d’appliquer la ponctuation et l’utilisation de majuscules en créant deux modèles différents [3][6], tandis que d’autres combinent les deux dans un même modèle car les sorties sont hautement corrélées [4][2]. Les mots placés immédiatement après la ponctuation en sont un bon exemple : ils commencent généralement par une majuscule après un point et une minuscule après une virgule. D’autres approches suggèrent une architecture à plusieurs sorties [4] (une par tâche, respectivement), qui s’avère plus performante que les architectures séparant la ponctuation de l’application de majuscules. À la lumière de ces observations, nous avons opté pour l’utilisation d’un seul réseau de neurones basé sur un GRU avec deux sorties, pour la ponctuation et l’application de majuscules. Pour gérer les mots qui ne figurent pas dans le vocabulaire du modèle, nous utilisons une technique de type SentencePiece [6] qui divise les mots inconnus en petits jetons, ou, dans des cas extrêmes, en caractères, comme nous l’expliquons ci-dessous.

TruncBiRNN

L’intuition et l’expérimentation ont montré qu’il est essentiel de disposer du contexte à venir pour créer un modèle de ponctuation : si l’on ignore quels seront les prochains mots, il est très difficile de déterminer le signe de ponctuation pour un emplacement donné. Pour utiliser les informations des prochains jetons et ne pas être obligés de mettre à jour tous les états masqués de tous les jetons vers l’arrière, nous avons décidé de limiter le passage en sens inverse à une fenêtre fixe. Dans le sens avant, nous appliquons un RNN ordinaire. Pour le passage en sens inverse, nous prenons seulement en compte une fenêtre fixe au niveau de chaque jeton, en exécutant le RNN sur cette fenêtre (figure 2). L’utilisation de cette fenêtre nous permet d’obtenir une inférence temporelle constante pour chaque nouveau jeton d’entrée (nous devrons calculer un état masqué en sens avant et n+1 en sens inverse).   Ainsi, pour chaque jeton, nous obtenons des états masqués pour les sens avant et inverse, respectivement. Appelons cette couche TruncBiRNN ou TruncBiGRU (comme nous utilisons le GRU). Ces états masqués peuvent être calculés en durée constante, qui ne dépend pas de la longueur d’entrée. Le fonctionnement en durée constante est essentiel pour que le modèle puisse assurer la génération de sous-titres en temps réel.

Architecture

L’architecture comprend une couche d’embedding, la couche GRU unidirectionnelle et TruncBiGRU, et la couche entièrement connectée. Pour la sortie, nous utilisons deux couches softmax pour la ponctuation et l’application de majuscules, respectivement (figure 3).   Pour chaque mot, le modèle prédit si une majuscule sera appliquée et s’il sera suivi d’un signe de ponctuation. Pour mieux synchroniser ces deux sorties et prédire l’application de majuscules, nous devons également connaître l’embedding du jeton précédent (pour restaurer le signe de ponctuation de l’étape précédente). En appliquant aussi une fonction loss personnalisée (voir section suivante), cela nous permet d’éviter les cas où une minuscule figurerait en début de phrase. Concernant la prédiction de la ponctuation, il est également utile d’obtenir une prédiction de l’application d’une majuscule au mot suivant. C’est pourquoi nous concaténons les embeddings actuel et suivant. Une couche de sortie pour la ponctuation prédit la distribution de tous les signes de ponctuation. Pour notre modèle, on trouve :

point– un point au milieu d’une phrase qui n’implique pas nécessairement que le mot suivant commence par une majuscule (« a.m. », « D.C. », etc.)

virgule

point d’interrogation

points de suspension

deux-points

tiret

point final – un point à la fin d’une phrase

  Concernant l’application de majuscules, nous avons quatre catégories :

minuscules

majuscules – toutes les lettres sont mises en majuscules (« IEEE », « NASA », etc.)

capitale

mix_minuscules_majuscules – applicable aux mots tels que « iPhone »

capitale au début – mots commençant une phrase

Les catégories additionnelles, « capitale au début » et « point final » peuvent sembler redondantes au premier abord, mais elles augmentent la cohérence des réponses liées à l’application de majuscules et à la ponctuation. Le « point final » implique que la prochaine réponse d’application de majuscules ne pourra pas être « minuscule » tandis que « capitale au début » signifie que le signe de ponctuation précédent est un « point final » ou un point d’interrogation. Ces catégories jouent un rôle important dans la fonction loss. Fonction loss : Nous devons optimiser à la fois l’application de majuscules et la ponctuation. Pour y parvenir, nous utilisons une somme de fonction log-loss avec un coefficient : Toutefois, comme mentionné plus haut, les sorties d’un réseau de neurones peuvent ne pas être en parfaite corrélation. Par exemple, le ponctuateur pourrait prédire « point final » pour le mot courant alors que l’applicateur de capitale ne prédira pas « capitale au début » pour le prochain jeton. Ce type d’erreur, bien que rare, peut être très embêtant. Pour l’éviter, nous utilisons une condition supplémentaire dans la fonction loss pour le pénaliser : La première condition correspond à la probabilité de trouver « capitale au début » après l’absence de « point final » et la deuxième correspond à la probabilité de ne pas trouver « capitale au début » après « point final ».  Cette pénalité s’additionne pour les jetons avec cette erreur. De plus, nous faisons passer deux tenseurs consécutifs de la couche précédente vers les couches softmax. Ceci nous permet de réduire efficacement les conditions de pénalité. Enfin, nous disposons de la fonction loss :

Entraînement

Pour l’entraînement, nous utilisons des transcriptions de texte provenant d’un ensemble de réunions internes à Webex et de données de texte issues de Wikipédia. Pour commencer, les données d’entraînement sont nettoyées et divisées en phrases. Pendant l’entraînement, chaque échantillon est généré depuis des phrases consécutives, puis coupé à une longueur aléatoire depuis une distribution fixe. Le modèle peut ainsi identifier les expressions coupées pendant l’entraînement et donc gérer les résultats intermédiaires durant l’inférence. Ensuite, nous entraînons un modèle sur environ 300 mégaoctets de texte Wikipédia, puis l’affinons avec des transcriptions de réunions Webex. Le pré-entraînement sur Wikipédia aide à améliorer toutes les catégories de ponctuation, mais il est particulièrement utile pour les catégories d’application de majuscules. Nous pensons que cela est dû au grand nombre de noms propres mentionnés dans Wikipédia. Nous appliquons la même préparation des données à nos ensembles d’évaluation en concaténant des phrases, puis en les coupant à des longueurs aléatoires. Nous pouvons ainsi mesurer l’exactitude de ce que nous obtenons généralement aux états de transcription intermédiaires.

Conclusion

En ayant recours à des techniques relativement simples et quelques personnalisations de l’architecture, telles que le GRU coupé et une pénalité additionnelle dans une fonction loss, nous avons créé un modèle qui peut être exécuté en ligne. L’expérience de lecture des sous-titres en direct est largement améliorée grâce aux signes de ponctuation et à l’application de majuscules en temps réel. Références [1] A. Gravano, M. Jansche et M. Bacchiani, « Restoring punctuation and capitalization in transcribed speech », ICASSP 2009, 2009, pp. 4741–4744. [2] Monica Sunkara, Srikanth Ronanki, Kalpit Dixit, Sravan Bodapati, Katrin Kirchhoff, « Robust Prediction of Punctuation and Truecasing for Medical ASR » [3] Tilk, Ottokar & Alumäe, Tanel. (2016). Bidirectional Recurrent Neural Network with Attention Mechanism for Punctuation Restoration. 3047-3051. 10.21437/Interspeech.2016-1517. [4] Vardaan Pahuja, Anirban Laha, Shachar Mirkin, Vikas Raykar, Lili Kotlerman, Guy Lev « Joint Learning of Correlated Sequence Labelling Tasks Using Bidirectional Recurrent Neural Networks » [5] Wang, Peilu & Qian, Yao & Soong, Frank & He, Lei & Zhao, Hai. (2015). Part-of-Speech Tagging with Bidirectional Long Short-Term Memory Recurrent Neural Network. [6] Lita, Lucian & Ittycheriah, Abe & Roukos, Salim & Kambhatla, Nanda. (2003). tRuEcasIng. 10.3115/1075096.1075116. [7] https://github.com/google/sentencepiece Inscrivez-vous à Webex Accédez à notre page d’accueil ou contactez-nous directement si vous avez besoin d’aide. Cliquez ici pour en savoir plus sur les offres de Webex et créer un compte gratuit.