BLEU: неправильно зрозуміла метрика з іншої доби

Але все ще використовується сьогодні в дослідженнях ШІ

GPT-3, Шепіт, PaLM, NLLB, FLAN, і багато інших моделей були оцінені за допомогою метрики BLEU, щоб підтвердити їх перевагу в деяких завданнях.

Але що таке BLEU? Як це працює?

У цій статті ми повернемося на 20 років назад, щоб розкрити основні причини, які привели до існування BLEU і зробили його дуже успішним показником. Ми розглянемо, як працює BLEU на деяких прикладах. Я також висвітлю основні обмеження метрики та надам рекомендації щодо її використання.

Ця стаття розглядається як вступ до BLEU, але також може бути чудовим нагадуванням для досвідчених практиків НЛП/ШІ, які використовують BLEU за звичкою, а не за потребою.

BLEU вперше було описано в дослідницькому звіті IBM, співавторами якого були Кішоре Папінені, Салім Рукос, Тодд Уорд і Вей-Цзін Чжу, у 2001 році. Вони опублікували наукова стаття з його описом через рік на ACL 2002, який набагато більше цитується і його легко знайти.

Спочатку BLEU був запропонований як автоматична метрика для оцінки машинного перекладу (MT).

У 2001 році системи машинного перекладу все ще в основному оцінювалися вручну або за допомогою старих автоматичних показників, таких як WER (коефіцієнт помилок у словах). WER — це метрика, натхненна дистанцією Левенштейна, і досі використовується для оцінки систем розпізнавання мовлення. Для оцінки машинного перекладу WER можна розглядати як предка BLEU. Автори BLEU висловлюють це так:

Ми формуємо нашу метрику близькості на основі дуже успішної метрики рівня помилок у словах, яку використовує спільнота розпізнавання мовлення

Як і WER, BLEU є показником, який вимірює наскільки текст близький до довідкових текстів, створених людьми, наприклад, довідкові переклади.

Оскільки переклад є завданням із кількома правильними рішеннями, автори BLEU розробили свою метрику так, щоб вона могла обробляти кілька посилальних перекладів. На той час це не було новим, оскільки WER уже перетворювався на «mWER», щоб також обробляти численні посилання. Наскільки мені відомо, це було вперше запропоновано Альшаві та ін. (1998) від AT&T Labs.

Важливо відзначити, що в усьому документі, в якому представлено BLEU, автори завжди припускають використання кількох посилальних перекладів для своєї метрики. Вони коротко обговорюють використання єдиного посилального перекладу, який є правильним лише за деяких обставин:

ми можемо використовувати великий тестовий корпус з єдиним еталонним перекладом, за умови, що всі переклади не від одного перекладача.

Навпаки, сьогодні більшість наукових робіт використовують BLEU з a єдине посилання, часто від ан невідомого походження, А для різноманітні завдання, тобто не лише переклад.

З 2001 року BLEU був, м’яко кажучи, дуже успішним показником. Частково це сталося завдяки його дешеві обчислювальні витрати і відтворюваність балів BLEU, на відміну від оцінювання людиною, результати якого можуть сильно відрізнятися залежно від оцінювачів і системи оцінювання.

BLEU зараз використовується майже в 100% наукових статей з машинного перекладу і значною мірою поширився на інші завдання створення природної мови.

Точніше, BLEU оцінює, наскільки якісні n-грами перекладу що відповідає n-грамам з набору довідкових перекладів, а покарання за машинний переклад, якщо він коротший або довший ніж довідкові переклади.

Деякі визначення:

An n-грам є послідовністю токенів. Давайте також визначимо тут, що a знак це послідовність символів, довільно розділених пробілами. Наприклад, речення «лексема — це не слово». часто лексемують як «лексема — це не слово .». Ми обговоримо більше про надзвичайно важливу роль токенізації далі в цій статті.

Щоб побачити BLEU у дії, я запозичив із статті BLEU приклад речення китайською мовою (не наданого авторами), перекладеного англійською мовою. У нас є такі 2 переклади, згенеровані машинним перекладом:

І наступні 3 довідкові переклади, надані людьми:

Питання, на яке ми хочемо відповісти з BLEU:

Який переклад є найближчим до наведених довідкових перекладів?

Я виділив усі n-грами, які охоплюються довідковими перекладами в обох варіантах перекладу.

Кандидат 1 охоплює набагато більше n-грамів із еталонних перекладів, і оскільки його довжина (кількість лексем) також обґрунтовано відповідає довжині еталонних перекладів, він отримає вищу оцінку BLEU, ніж Кандидат 2. Тут BLEU правильний, оскільки Кандидат 1 справді кращий за Кандидата 2.

На цьому прикладі ми можемо побачити деякі очевидні обмеження BLEU. Значення оцінюваного перекладу не враховується. BLEU шукав лише точні збіги з лексемами еталонних перекладів.

Наприклад, "забезпечувати" у Кандидаті 2 немає в довідкових перекладах, але "гарантує” є. Оскільки "забезпечувати"не зовсім те саме, що"гарантує”, BLEU не винагороджує це, незважаючи на близьке значення.

Ще гірше може бути, коли ми уважно дивимося на розділові знаки. Наприклад, Кандидат 2 закінчується на «.", але цей період додається до "прямий.”, щоб сформувати єдиний токен. «прямий.” не є ознакою еталонних перекладів. Кандидат 2 не отримує винагороду за правильне включення цієї точки.

Ось чому BLEU зазвичай обчислюється на основі перекладів, які розділені на розділені лексеми, що містять знаки пунктуації. Ми обговоримо це далі в наступному розділі.

Щоб було просто, я не буду обговорювати рівняння, що стоять за BLEU. Якщо вам цікаво обчислити BLEU самостійно, я запрошую вас прочитати статтю BLEU, де всі рівняння добре мотивовані та пояснені.

Ми побачили, що BLEU є дуже суворим, оскільки токен має бути ідентичним до токена в еталонних перекладах, щоб вважатися збігом. Тут токенізація відіграє дуже важливу роль часто неправильно розуміють Роль.

Дещо дає токенізація гнучкість до BLEU.

Наприклад, давайте знову подивимося на Кандидата 2:

Це має забезпечити, щоб війська назавжди чули посібник з діяльності, яким керує ця сторона.

Але цього разу ми застосовуємо прості правила токенізації, щоб відокремити знаки пунктуації від слів. Отримуємо:

Це гарантує, що війська назавжди чутимуть посібник з діяльності, який керує сторона.

Зауважте, що «." було відокремлено від "прямий” через пробіл. Це єдина різниця. Кандидат 2 тепер відповідає ще одному токену з еталонних перекладів. Цей маркер є ".”. Це не здається важливим, оскільки це лише ще один токен, але він дуже частий. Ця токенізація матиме вплив майже на всі речення, що призведе до значно кращих оцінок BLEU.

Існує нескінченна кількість можливих токенізацій. Наприклад, наступні французькі речення є перекладами з англійської, до яких я застосовую 5 різних токенізаторів. Примітка: я використовував Мойсей (з відкритим кодом, ліцензія LGPL) і SacreBLEU (відкритий код, ліцензія Apache 2.0).

Це однакові речення, але оскільки вони по-різному лексемовані, вони відповідатимуть іншим лексемам із перекладів посилання. Усі ці токенізації дадуть різні оцінки BLEU, а переклади залишаться незмінними.

Ось чому дві оцінки BLEU, обчислені на основі перекладів, для яких токенізація є іншою або невідомою, не можна порівнювати.

Це часто нехтують в наукових працях сьогодні.

Ви можете побачити токенізацію як параметр BLEU. Якщо ви змінюєте параметри, ви змінюєте метрику. Оцінки двох різних показників не можна порівнювати.

Коли в 2001 році було запропоновано BLEU, якість машинного перекладу була дуже різною.

Щоб дати вам уявлення про цю різницю, я спробував відтворити систему машинного перекладу з французької на англійську з 2000-х років. Для цього я навчив систему статистичного машинного перекладу на основі слів. Я зробив це з Мойсей. Я буду позначати цю систему «статистичне МТ (2001)».

Потім я навчив систему нейронного машинного перекладу за допомогою моделі Vanilla Transformer. Я зробив це з Меріан (з відкритим кодом, ліцензія MIT). Я буду позначати цю систему «нейронний МТ (2022)».

Переклади, які вони створюють, такі. Примітка: я виділив n-грами, які відповідають перекладу посилання.

Як і очікувалося, переклад, створений статистичним МТ, не має особливого сенсу, особливо в кінці речення. Він охоплює менше n-грамів із еталонного перекладу, ніж нейронний МТ. З іншого боку, переклад, згенерований нейронним МТ, виглядає ідеально (без контексту), але він не зовсім такий самий, як еталонний переклад, тому він буде покараний BLEU.

У 2001 році системи машинного перекладу створювали переклади, які часто були безглуздими та з очевидними синтаксичними помилками. Їх справедливо покарали за те, що вони не відповідали конкретним довідковим перекладам. Нині нейронний машинний переклад часто створює дуже плавний переклад, особливо для «легких» мовних пар, таких як французька-англійська. Вони часто знаходять правильний переклад, але оскільки існує багато можливих правильних перекладів, точний переклад, використаний як посилання, може бути знайдено лише випадково.

Саме тут ми досягли межі BLEU, яка винагороджує лише точні збіги, навіть якщо переклад правильний.

BLEU протягом багатьох років керує прогресом у дослідженнях машинного перекладу. На NAACL 2018 автори BLEU отримали нагорода за перевірку часом.

BLEU все ще використовується в багатьох сферах штучного інтелекту, але лише за звичками. Тепер він значно перевершує багато інших показників оцінювання для завдань генерації природної мови, включаючи машинний переклад, наприклад chrF, BLEURTабо COMET.

Тим не менш, BLEU залишається дуже хороший інструмент для діагностичних цілей.

Оскільки BLEU має добре відому поведінку, тобто ми знаємо, якого рівня BLEU очікувати для конкретних завдань перекладу, його можна використовувати для швидкого виявлення помилок та інших проблем у навчальному конвеєрі системи машинного перекладу або в її обробці даних.

У будь-якому випадку, BLEU не слід використовувати в коротких текстах. На практиці спеціалісти з машинного перекладу завжди запускають BLEU над текстами, що містять понад 1,000 речень. BLEU призначений для оцінки перекладу документів. Його не слід використовувати для оцінки перекладу речень.

Що стосується реалізацій BLEU, багато з них є загальнодоступними. Hugging Face має власну реалізацію в Оцініть бібліотеку. НЛТК також реалізує BLEU. Існує також multi-bleu.perl сценарій у проекті Moses. Зверніть увагу, що всі ці реалізації BLEU різні і не дадуть порівнянних результатів. Моя особиста рекомендація - використовувати оригінальну реалізацію SacreBLEU оскільки цей інструмент мав на меті гарантувати відтворюваність і порівнянність балів BLEU.

І якщо ви плануєте використовувати BLEU у своїй наступній роботі, не забувайте про необхідність перевірки статистичної значущості ваших результатів.

Найкращий спосіб підтримати мою роботу — стати учасником Medium за моїм посиланням:

Якщо ви вже є учасником і хочете підтримати цю роботу, просто слідкуйте за мною на Medium.