Data augmentation for low-resource grapheme-to-phoneme mapping (2021)

Abstract: In this paper we explore a very simple neural approach to mapping orthography to phonetic transcription in a low-resource context. The basic idea is to start from a baseline system and focus all efforts on data augmentation. We will see that some techniques work, but others do not.

## introduction this paper describes a submission by our team to the 2021 edition of the sigmorphon graphemeto-phoneme conversion challenge. here we demonstrate our efforts to improve grapheme-to-phoneme mapping for low-resource languages in a neural context using only data augmentation techniques. the basic problem in the low-resource condition was to build a system that maps from graphemes to phonemes with very limited data. specifically, there were 10 languages with 800 training pairs and 100 development pairs. each pair was a word in its orthographic representation and a phonetic transcription of that word (though some multi-word sequences were also included). systems were then tested on 100 additional pairs for each language. the 10 languages are given in to focus our efforts, we kept to a single system, intentionally similar to one of the simple baseline systems from the previous year's challenge. we undertook and tested three data augmentation techniques. in the following, we first provide additional details on our base system and then outline and test each of the moves above separately. we will see that some work and some do not. we acknowledge at the outset that we do not expect a system of this sort to "win". rather, we were interested in seeing how successful a minimalist approach might be, one that did not require major changes in system architecture or training. this minimalist approach entailed that the system not require a lot of detailed manipulation and so we started with a "canned" system. this approach also entailed that training be something that could be accomplished with modest resources and time. all configurations below were run on a lambda labs tensorbook with a single gpu. 1 no training run took more than 10 minutes. ## general architecture the general architecture of the model is inspired by one of the 2020 baseline systems @xcite : a sequence-to-sequence neural net with a two-level lstm encoder and a two-level lstm decoder. the system we used is adapted from the opennmt base @xcite . there is a 200-element embedding layer in both encoder and decoder. each lstm layer has 300 nodes. the systems are connected by a 5-head attention mechanism @xcite . training proceeds in 24,000 steps and the learning rate starts at 1.0 and decays at a rate of 0.8 every 1,000 steps starting at step 10,000. optimization is stochastic gradient descent, the batch size is 64, the dropout rate is 0.5. we spent a fair amount of time tuning the system to these settings for optimal performance with this general architecture on these data. we do not detail these efforts as this is just a normal part of working with neural nets and not our focus here. precise instructions for building the docker image, full configuration files, and auxiliary code files are available at https://github.com/hammondm/ g2p2021 . ## general results in this section, we give the general results of the full system with all strategies in place and then in the next sections we strip away each of our augmentation techniques to see what kind of effect each has. in building our system, we did not have access to the correct transcriptions for the test data provided, so we report performance on the development data here. the system was subject to certain amount of randomness because of randomization of training data and random initial weights in the network. we therefore report mean final accuracy scores over multiple runs. our system provides accuracy scores for development data in terms of character-level accuracy. the general task was scored in terms of word-level error rate, but we keep this measure for several reasons. first, it was simply easier as this is what the system provided as a default. second, this is a more granular measure that enabled us to adjust the system more carefully. finally, we were able to simulate word-level accuracy in addition as described below. we use a monte carlo simulation to calculate expected word-level accuracy based on characterlevel accuracy and average transcription length for the training data for the different languages. the simulation works by generating 100, 000 words with a random distribution of a specific characterlevel accuracy rate and then calculating word-level accuracy from that. running the full system ten times, we get the results in ## using development data the default partition for each language is 800 pairs for training and 100 pairs for development. we shifted this to 880 pairs for training and 20 pairs for development. the logic of this choice was to retain what seemed like the minimum number of development items. running the system ten times without this repartitioning gives the results in there is a small difference in the right direction, but it is not significant for characters (@xmath0.65, @xmath1.11, unpaired) or words (@xmath2.56, @xmath3.13, unpaired). it may be that with a larger sample of runs, the difference becomes more stable. ## using substrings this method involves finding peripheral letters that map unambiguously to some symbol and then finding plausible splitting points within words to create partial words that can be added to the training data. let's exemplify this with welsh. first, we identify all word-final letters that always correspond to the same symbol in the transcription. for example, the letter c always corresponds to a word-final @xcite . similarly, we identify word-initial characters with the same property. for example, in these data, the word-initial letter t always corresponds to [t]. 2 we then search for any word in training that has the medial sequence ct where the transcription has @xcite . we take each half of the relevant item and add them to the training data if that pair is not already there. for example, the word actor [aktor] fits the pattern, so we can add the pairs ac-ak and tor-tor. to the training data. note that this procedure can make errors. if there are generalizations about the pronunciation of letters that are not local, that involve elements at a distance, this procedure can obscure those. another example from welsh makes the point. there are exceptions, but the letter y in welsh is pronounced two ways. in a word-final syllable, it is pronounced [1], e.g. gwyn [gw1n] 'white'. in a non-final syllable, it is pronounced [@], e.g. gwynion [gw@njon] 'white ones'. though it doesn't happen in the training data here, the procedure above could easily 2 this is actually incorrect for the language as a whole. word-initial t in the digraph th corresponds to a different sound @xcite . result in a y in a non-final syllable ending up in a final syllable in a substring generated as above. strikingly, adding the substrings lowered performance, but the difference with the full model is not significant for either characters (@xmath4.18, @xmath5.25, unpaired) or for words (@xmath6.17, @xmath7.25, unpaired). this model without substrings is the best-performing of all the models we tried, so this is what was submitted. ## training together the basic idea here was to leverage the entire set of languages. thus all languages were trained together. to distinguish them, each pair was prefixed by its language code. thus if we had orthography @xmath8, o 2 , . . . , o n and transcription @xmath9, t 2 , . . . , t m from language x, the net would be trained on the pair @xmath10, o 1 , o 2 , . . . , o n and @xmath11, t 1 , t 2 , . . . , t m . the idea is that, while the mappings and orthographies are distinct, there are similarities in what letters encode what sounds and in the possible sequences of sounds that can occur in the transcriptions. this approach is very similar to that of @xcite , except that we tag the orthography and the transcription with the same langauge tag. peters and martins (2020) took a similar approach in last years challenge, but use embeddings prefixed at each time step. in there's a lot of variation across runs and the means for each language are quite different, presumably based on different levels of orthographic transparency. the general pattern is clear that, overall, training together does better than training separately. comparing run means with our baseline system is significant (@xmath12.06, @xmath13.001, unpaired). this is not true in all cases however. for some languages, individual training seems to be better than training together. our hypothesis is that languages that share similar orthographic systems did better with joint training and that languages with diverging systems suffered. the final results show that our best system (no substrings included, all languages together, moving development data to training) performed reasonably for some languages, but did quite poorly for others. this suggests a hybrid strategy that would have been more successful. in addition to training the full system here, train individual systems for each language. for test, compare final development results for individual languages for the jointly trained system and the individually trained systems and use whichever does better for each language in testing. ## conclusion to conclude, we have augmented a basic sequenceto-sequence lstm model with several data augmentation moves. some of these were successful: redistributing data from development to training and training all the languages together. some techniques were not successful though: the substring strategy resulted in diminished performance.