機械翻訳におけるBLEUスコアの落とし穴
はじめに
機械翻訳の質を評価する指標として知られるBLEU(Bilingual Evaluation Understudy)は、2002年に提案されて以来、依然として広く使用されています。
この記事では、BLEUについて概説した後、BLEUを実際に使用している中で陥った具体的な「困りポイント」を紹介します。
BLEUとは
BLEUは、機械翻訳システムが出力した文章と、あらかじめ用意された正答(参照訳)を比較することで、翻訳の質を評価する指標です。スコアは0から1の範囲を取り、翻訳が完全に正答と一致すれば1になります[1]。
BLEUの主な目的は、大量の翻訳結果を自動で効率的に評価し、人手による評価の負担をなくすことです。そのため、「人手による評価と一定の相関があれば十分」という考え方が根底にあります。
BLEUには、機械学習で用いられる他の多くの評価指標とは異なる、2つの大きな特徴があります。
1つ目は、複数の文からなる集合(コーパス)全体が評価の単位である点です。個々の文単位で計算したスコアをコーパスにわたって平均するのではなく、コーパス全体を用いて一括でスコアを計算します。
2つ目は、正答を複数用意する点です。翻訳というものには本来正解はなく、多種多様でありうるので、一つひとつの文については、機械的に計算されるBLEUスコアと人手による判定が頻繁に異なるのは明らかです。そのため、BLEUは、一つひとつの文につき複数の正答を参照します。
BLEUは、以下の2つの要素によって計算されます。
-
-gram精度: 出力文中のn 個の連続した単語が、正答文に含まれる割合n - 簡潔性ペナルティ(Brevity Penalty; BP): 出力文の長さが正答文に比べて短い場合のペナルティ[2]
この2つの要素を用いて、BLEUは以下のように定義されます:
ここで、
2002年にIBMが提案して以来、BLEUは長らく翻訳評価のデファクトスタンダードとして利用されてきました。しかし、その理由の一部は「他に広く使われる指標がない」という消極的なものに過ぎず[3]、BLEUにはいくつもの欠点が指摘されています。
BLEUで困ったこと
自分が実際にBLEUを使っていて直面した具体的な落とし穴として、
- 無言へのペナルティが貧弱
- 正答が1つしかない場合の限界
- (おまけ)SacreBLEUの引数のクセが強い
の3点を取り上げます。
BLEUの問題点については多くの研究で指摘されています[4]が、この記事ではそれらから少し離れた、より実践的な内容になります。
無言へのペナルティが貧弱
1つ目の落とし穴は、「無言」に関するものです。
業務で大規模言語モデル(LLM)を翻訳用にトレーニングしていた際、モデルが文章を生成せず、何も出力しない現象[5]に、遭遇しました(以下、この現象を「無言」と呼びます)。
BLEUには、誤った翻訳を出力するよりも無言のほうがペナルティが小さいという、困った性質があります。
これを次のような架空のコーパスで考えてみます。
原文 | 正答 | |
---|---|---|
1 | 猫がマットの上にいます。 | The cat is on the mat. |
2 | 猫がマットの上にいます。 | The cat is on the mat. |
… | … | … |
7 | 猫がマットの上にいます。 | The cat is on the mat. |
8 | 猫がマットの上にいます。 | The cat is on the mat. |
8つの文からなるコーパスです。ここでは簡単のため、すべて同一の文とし、正答は1つずつしか用意されていないことを想定しています。
このコーパスを用いて、2つの翻訳機械A、Bを比較する実験を行った結果、以下のような出力を得たとします。
翻訳機械A | 翻訳機械B | |
---|---|---|
1 | There is a cat on the mat. | There is a cat on the mat. |
2 | There is a cat on the mat. | There is a cat on the mat. |
… | … | |
7 | There is a cat on the mat. | There is a cat on the mat. |
8 | There is a dog on the mat. |
翻訳機械Aは、7番目の文までは適切な翻訳を出力しましたが、惜しいことに最後の1文で"cat"を"dog"と誤訳しました。
翻訳機械Bは、7番目の文まではAと全く同じ出力をしましたが、最後の1文だけ無言になりました。
直感的にはAのほうがスコアが高くなることを期待するのですが[6]、それぞれの翻訳機械のBLEUスコアを計算してみると、
という結果になります。つまり、無言である翻訳機械Bのスコアが、些細な誤訳を含むAよりも高くなります。
なせこのようなことが起きるのか、BLEUの定義に基づき、2つの原因を検討します。
原因1:n-gram精度の計算によるもの
実は、
ただし、
式の詳しい説明は他に譲るとして[8]、今回の文脈で重要なのは、分母において足されるものが
翻訳機械が出力した無言の文章を
翻訳機械Bの出力の場合で言えば、7番目までの出力のみで計算した
一方で、翻訳機械Aの出力は、7番目までの出力のみで計算した
無言が
原因2:BPの計算によるもの
結論から言ってしまうと、ある条件下では、
where
ただし、
上の定義から、
さて、
先ほどの例について実際に計算してみると、正答の"The cat is on the mat."は7単語であるから(ピリオドを含む)、
無言を含む翻訳機械Bの出力については、"There is a cat on the mat."は8単語であるから、
したがって
つまり、その他の文で十分な単語数を出力している場合、いくつか無言となる文があっても、
正答が1つしかない場合の限界
2つ目の落とし穴は、翻訳の正解として用意する正答の数に関するものです。
BLEUは、本来、1つの文に対して複数の正答を用意することを前提としています。
しかし、実際には正答が1つしか用意されていないコーパスで評価を行うことが一般的です。この場合、翻訳の多様性が考慮されず、BLEUの評価が不正確になる可能性があります。
そもそもなぜ複数の正答が必要なのでしょうか?
ここで、複数であることと多様であることの区別が重要になります。
例えば、「東アジアの経済」の英訳として、機械が"East Asian economy"という優れた翻訳文を出力したとします。以下のようなコーパスであった場合、この機械はBLEU=1を達成します。
原文 | 正答A | 正答B | 正答C | 正答D |
---|---|---|---|---|
東アジアの経済 | economy of East Asia | the economies of East Asian countries | East Asia's economy | East Asian economy |
しかし、以下のようにたまたま全ての正答文が"economy of East Asia"であった場合、"East"しか合致していないため、非常に低いBLEUスコアとなってしまいます。
原文 | 正答A | 正答B | 正答C | 正答D |
---|---|---|---|---|
東アジアの経済 | economy of East Asia | economy of East Asia | economy of East Asia | economy of East Asia |
翻訳において正解は一つではなく、妥当な翻訳というのは非常に多様でありうるものです。正答が複数であっても、多様性がなければ正しく評価をすることができません。したがって、異なるスタイルを持つ複数の人間の翻訳者によってコーパスの正答が作成されるということが重要です。
BLEU論文では、1つの文につき正答が1つしかない場合の実験も行っています。それぞれの文に対して、4つの正答のうち1つをランダムに選択することで、正答が1つしかないコーパスをシミュレートしました。翻訳機械3つと人間2人を用いた実験の結果、正答が4つある場合と、1つしかない場合とで、BLEUの得点に関して各翻訳主体の順位には変動がなかったとしています。
ただし、順位が変動しなかっただけであり、(論文中で明言はされていないものの)BLEUスコアそのものが変動しなかったわけではないことに注意が必要です。同論文中でも、文あたりの正答の数が多ければ多いほど、スコアは高くなることに注意が必要だと述べられています。
また、4つの正答のうちランダムに1つを選んだという点も重要です。この実験が示唆するのは、あくまでも「正答がすべて同じ翻訳者によるものでなければ(翻訳に多様性があれば)、1つの文につき1つの正答しかもたないコーパスを実験に使ってもよいかもね」ということです。[11]
なお、LLMをパラフレーズに用いて正答文を増やすことにより、BLEUスコアと人手による評価との相関が向上したとする研究もあります。[12]
(おまけ)SacreBLEUの引数のクセが強い
3つ目の落とし穴は、BLEUそのものというより、計算ライブラリに関するものです。
Hugging FaceのevaluateライブラリにはBLEUが実装されており[13]、こちらは以下のように、同じ文に対する正答がネストの内側のリストにまとまっており、直感的に使用することができます。
import evaluate
references = [
['文1の正答a', '文1の正答b'],
['文2の正答a', '文2の正答b'],
['文3の正答a', '文3の正答b'],
]
predictions = ['文1の機械翻訳', '文2の機械翻訳', '文3の機械翻訳']
bleu = evaluate.load("bleu")
results = bleu.compute(predictions=predictions, references=references)
一方で、BLEUを計算するためのライブラリとして機械翻訳界隈において事実上の標準となっているSacreBLEUは、以下のように、メソッドのreferences
引数に渡すリストの形状が、Hugging Faceの実装に比べてちょうど転置した形になっており、個人的には非常に直感に反します。しかも、誤って転置したものを与えてもエラーにならず、意図していない計算結果を出力してしまうので、注意が必要です。
from sacrebleu.metrics import BLEU
references = [
['文1の正答a', '文2の正答a', '文3の正答a'],
['文1の正答b', '文2の正答b', '文3の正答b'],
]
predictions = ['文1の機械翻訳', '文2の機械翻訳', '文3の機械翻訳']
bleu = BLEU()
bleu.corpus_score(hypotheses=predictions, references=references)
また、Hugging Faceの実装は文ごとの正答の数が異なる(ネストの内側のリストの長さが異なる)ことを許容するのですが、一方SacreBLEUはそのような柔軟性がなく、空の文字列""
を加えることでリストの長さを揃えなければならず、この点も厄介です。
おわりに
問題含みな評価指標であっても、BLEUが機械翻訳界隈のデファクト・スタンダードであり続ける状況はしばらくは続きそうです。
限界を理解した上でBLEUを使用すること、また、何らかの結論を導き出す際にBLEUスコアのみに依存しない姿勢が求められます。BLEURTやCOMET[14]といった、人手による評価との相関がBLEUよりも高い評価指標もあります。これらの評価指標を組み合わせて、翻訳の質を多角的に評価することが重要です。
参考文献
Chris Callison-Burch, Miles Osborne, and Philipp Koehn. 2006. Re-evaluating the Role of Bleu in Machine Translation Research. In 11th Conference of the European Chapter of the Association for Computational Linguistics, pages 249–256, Trento, Italy. Association for Computational Linguistics.
Benjamin Marie. 2022. 12 Critical Flaws of BLEU: Why you shouldn’t trust BLEU according to 37 studies published over 20 years. The Kaitchup – AI on a Budget. Available at: https://open.substack.com/pub/kaitchup/p/12-critical-flaws-of-bleu-1d790ccbe1b1
Nitika Mathur, Timothy Baldwin, and Trevor Cohn. 2020. Tangled up in BLEU: Reevaluating the Evaluation of Automatic Machine Translation Evaluation Metrics. In Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics, pages 4984–4997, Online. Association for Computational Linguistics.
Kishore Papineni, Salim Roukos, Todd Ward, and Wei-Jing Zhu. 2002. Bleu: a Method for Automatic Evaluation of Machine Translation. In Proceedings of the 40th Annual Meeting of the Association for Computational Linguistics, pages 311–318, Philadelphia, Pennsylvania, USA. Association for Computational Linguistics.
Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Łukasz Kaiser, and Illia Polosukhin. 2017. Attention is all you need. In Proceedings of the 31st International Conference on Neural Information Processing Systems (NIPS'17). Curran Associates Inc., Red Hook, NY, USA, 6000–6010.
Xianfeng Zeng, Yijin Liu, Fandong Meng, and Jie Zhou. 2024. Towards Multiple References Era – Addressing Data Leakage and Limited Reference Diversity in Machine Translation Evaluation. In Findings of the Association for Computational Linguistics: ACL 2024, pages 11939–11951, Bangkok, Thailand. Association for Computational Linguistics.
バージョン情報
Python==3.10.15
evaluate==0.4.3
sacre_bleu==2.4.1
unbabel-comet==2.2.4
BLEURT @ git+https://github.com/google-research/bleurt.git@cebe7e6f996b40910cfaa520a63db47807e3bf5c
-
ただし、翻訳の正答は一意に定まるものではないので、BLEUが1をとることはほとんどありません。BLEU提案論文 (Papineni et al., 2002)では人間が中国語->英語の翻訳をした場合に0.3468や0.2571といったスコアであったことが述べられているほか、Attention is All you Need (Vaswani et al. 2017) では、Transformerのbigモデルを用いて、英語->ドイツ語翻訳で0.284、 英語->フランス語翻訳で0.41となっています(なお、同一の実験条件下での比較のみが意味を持つので、この結果をもって人間よりもTransformerのほうが優れているということにはなりません)。 ↩︎
-
機械学習の一般的な用語で言えば、
-gram精度がprecisionに、簡潔性ペナルティ(BP)がrecallに対応することが目指されています。ただし厳密には対応しておらず、特にBPに関しては"stop-gap measure"(Callison-Burch et al., 2006)(=その場しのぎ)で設けられた向きがあります。 ↩︎n -
シンプルで計算が早い点もBLEUが支持される理由の1つと考えられます。 ↩︎
-
例えばCallison-Burch et al. (2006)、Mathur et al. (2020)など。後者はACL 2020のHonorable Mention for Best Overall Paperに選出されています。 ↩︎
-
モデルが他に通常のテキストを一切生成することなくEOSトークン(生成の終了を示すトークン)を出力する、ということです。 ↩︎
-
学校のテストの比喩を用いれば、7問目までは全く同一の答案を提出したものの、8問目で些細なミスをした生徒Aと、8問目を白紙で提出した生徒Bとでは、8問目の点数はBは0点だがAには部分点をあげたい、といったところです。 ↩︎
-
簡単のため、1文につき正答が1つしか与えられない場合の定義を示しています。 ↩︎
-
なぜ分子に
が出てくるのかについては、「BLEU 修正n-gram精度」などで検索すると解説が出てきます。 ↩︎min -
誤訳された文に関しては、分母には
が足され、分子にはk > 0 が足されるため。 ↩︎l<k -
の定義はsacreBLEUの実装を参考にしています。元論文ではBP の計算においてBP がゼロの場合(ゼロ除算)が考慮されていません。また、c とr について、ここでも簡単のため、1文につき正答が1つしか与えられない場合の定義を示しています。 ↩︎c -
論文中の当該箇所の原文は"This outcome suggests that we may use a big test corpus with a single reference translation, provided that the translations are not all from the same translator."です。もし「provided that ~」を「only if ~」の意味に解釈するならば、「同じ翻訳者の手によってすべての正答が用意された場合、1文につき1つの正答しかないコーパスにはBLEUを使用できない」という強い主張にも解釈できます。 ↩︎
-
Zeng et al., 2024 ↩︎
-
Hugging FaceのBLEU実装はTensorflowによるBLEU実装のラッパーとなっており、Tensorflowの実装にはこちらのissueで述べられているように誤りがあるので、計算としてはSacreBLEUのほうが正しいものが出力されます。 ↩︎
-
COMETのUnbabel/wmt22-comet-daモデルとBLEURTのbleurt-base-128モデルで先の例を実験したところ、どちらも
という直感に即した結果になりました。加えて、BLEURTとCOMETは正答を1つしか必要としないので、その点でもBLEUより便利です。 ↩︎B < A
Discussion