MT Evaluation in General
 | |
| Lecture video: |
web TODO Youtube |
|---|---|
{{#ev:youtube|_QL-BUxIIhU|800|center}}
Data Splits
Available training data is usually split into several parts, e.g. training, development (held-out) and (dev-)test. Training data is used to estimate model parameters, development set can be used for model selection, hyperparameter tuning etc. and dev-test is used for continuous evaluation of progress (are we doing better than before?).
However, you should always keep an additional (final) test set which is used only very rarely. Evaluating your system on the final test set can then be used as a rough estimate of its true performance because you do not use it in the development process at all, and therefore do not bias your system towards it.
The "golden rule" of (MT) evaluation: Evaluate on unseen data!
Approaches to Evaluation
Let us first introduce the example that we will use throughout the section:
Example Sentence + Translations
Original German sentence:
- Arbeiter sturzte von Leiter: schwer verletzt
English reference translation:
- Worker falls from ladder: seriously injured
| Translation Candidate | Notes |
|---|---|
| A Workers rushed from director: Seriously injured | plural (workers), bad choice of verb (rushed), Leiter mistranslated as director |
| B Workers fell from ladder: hurt | plural (workers), intensifier missing |
| C Worker rushed from ladder: schwer verletzt | bad choice of verb (rushed), tail is left untranslated |
| D Worker fell from leader: heavily injures | Leiter translated as leader (not a typo, a bad lexical choice), poor morphological choices |
Absolute Ranking
We put each translation into a category that best describes its quality. The following categories can be used:
| Worth publishing | Translation is almost perfect, can be published as-is. |
| Worth editing | Translation contains minor errors which can be quickly fixed by a human post-editor. |
| Worth reading | Translation contains major errors but can be used for rough understanding of the text (gisting). |
If we define our categories like this, probably all example translations fall in the worth editing bin.
We can also separate our assessment of translation quality into different aspects (or dimensions). One division that has been used extensively for MT evaluation is:
- Adequacy -- how faithfully does the translation capture the meaning of the source sentence
- Fluency -- is the translation a grammatical, fluent sentence in the target language? (regardless of meaning)
In this case, e.g. candidate A could be marked as worth publishing in terms of fluency, while it is worth reading at best in terms of adequacy.
Relative Ranking
In this case, we avoid assigning translations into categories and instead ask the human judge(s) to rank the possible translations relative to one another. (Human inter-annotator agreement can be surprisingly low in both scenarios, though.)
In this case, we would probably order the systems (from best to worst): B > D > C > A
Different annotators could come up with different rankings. Ranking can also differ according to the intended purpose of the translations -- it a human translator is supposed to post-edit the translation, major errors in adequacy (such as spurious/missing negation) might be easy to fix and therefore should be ranked higher than factually correct translations with lots of small errors.