Як правильно провести людську оцінку якості MT-виводу

Постачальник надіслав тобі детальний бенчмарк: кастомізований EN→UK движок набрав 47.2 BLEU на тестовому наборі технічної документації, проти 39.8 шість місяців тому. Ти пустив через нього 30% обсягу. Через три тижні клієнт повертає партію перекладених технічних інструкцій - неправильні одиниці виміру, перевернуті правила безпеки, один пункт означає рівно протилежне оригіналу.

BLEU нічого з цього не виловив. Бенчмарк постачальника нічого не виловив. Людина-оцінювач, читаючи вивід як кінцевий користувач, виловила б усе за десять хвилин.

Саме це вирішує людська оцінка якості МТ - і саме тому більшість агенцій проводять її неправильно.

Чому автоматичних метрик недостатньо¶

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

CSA Research у своїй практичній оцінці назвала автоматичні MT-метрики “штучними і нерелевантними для виробничих середовищ перекладу”. Це різко, але суть правильна: жодна автоматична метрика зараз не скаже тобі чи перекладений контент придатний для його призначення з його аудиторією.

Людська оцінка - так. Підводний камінь у тому, що погано проведена оцінка дає результати не менш оманливі - просто дорогі та повільні замість дешевих і швидких.

Три основні фреймворки¶

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

Direct Assessment (DA)¶

DA - протокол оцінки на рівні сегменту від WMT. Оцінювачі бачать вихідний сегмент і один переклад (не бачать референс і не знають яка система його зробила), потім виставляють загальну якість на безперервному повзунку 0-100. Декілька оцінювачів оцінюють кожен сегмент; оцінки z-score нормалізуються по оцінювачу щоб прибрати масштабний зсув (70 одного оцінювача може відповідати 85 іншого якщо їхні внутрішні шкали різні).

На що відповідає: “Як система A ранжується відносно системи B на цьому контенті?” Швидко в адмініструванні, добре для порівняння кількох систем коли потрібне відносне ранжування без глибокого аналізу помилок.

На що не відповідає: де помилки, якого вони типу, і чи відповідає вивід конкретному порогу якості. Оцінка 72 не скаже тобі - ця 28-бальна різниця одна критична помилка перекладу чи сотня незначних пунктуаційних.

MQM (Multidimensional Quality Metrics)¶

MQM - стандарт для виробничої оцінки. Оцінювачі не виставляють цілісну оцінку - вони читають переклад разом з джерелом і позначають конкретні помилкові фрагменти, потім класифікують кожен за типом і серйозністю.

Типи помилок в MQM:

Ваги серйозності (з themqm.org):

Формула MQM-балу: (Критичні × 25 + Значні × 5 + Незначні × 1) ÷ кількість слів × 1000

Менше - краще. Більшість виробничих порогів для публікованого контенту - до 5-10 балів MQM на 1000 слів; для юридичних і медичних матеріалів типово до 2.

На що відповідає MQM: саме де якість ламається, в яких категоріях і якої серйозності. Якщо движок виробляє точний але ненатуральний вивід - MQM скаже що це проблема Плавності, а не Точності. Це визначає чи вкладати в донавчання, пост-редагування або роботу зі стайлгайдом.

Error Span Annotation¶

Легший варіант між DA і повним MQM. Оцінювачі позначають фрагменти з помилками без повної класифікації. Легше навчити оцінювачів, швидше проводити. Стаття 2024 року про Error Span Annotation показала кореляцію з MQM при витраті на 30-40% менше часу на сегмент.

Корисно коли потрібно більше сигналу ніж від DA, але немає бюджету чи часу на повний MQM.

Вибір оцінювачів - рішення яке визначає все¶

Будь-яке інше рішення в дизайні оцінки вторинне відносно цього. Неправильні оцінювачі дадуть тобі впевнені цифри які не відображають реальну якість.

Що робить оцінювача кваліфікованим¶

Носій цільової мови - без винятків. Навіть дуже вільний ненативний мовець пропустить проблеми природності і реєстру які будь-який носій помітить одразу.

Профресійний перекладач з доменним досвідом. Дослідження опубліковане в TACL (MIT Press) підтвердило те що практики вже знали: профресійні перекладачі знаходять значно більше помилок ніж білінгви без перекладацької освіти, особливо тонких - неправильна доменна термінологія, порушення зв’язності між сегментами, прагматичні помилки. Краудворкери “більш терпимі до MT-виводу” і систематично ставлять йому вищі оцінки, що зміщує результати в бік переоцінки якості.

Домен має значення. Літературний перекладач оцінюючи технічні керівництва пропустить термінологічні помилки очевидні для технічного перекладача. Юридичний контент - юридичний перекладач. Медична документація - медичний перекладач.

WMT переглянув свої процедури оцінки саме тому що краудворкери “менш здатні виявляти тонкі MT-помилки” - через це WMT перейшов від краудсорсингу до пулів профресійних перекладачів для якісної оцінки.

Скільки оцінювачів¶

Мінімум 3 на сегмент для MQM. Більшість серйозних оцінок використовують 2-3 анотатори на сегмент з протоколом арбітражу для розбіжностей. Менше 3 оцінювачів - розрахунок міжоцінювального узгодження стає ненадійним.

Навчання оцінювачів - обов’язково мінімум 2 години¶

Оцінювачі мають бути відкалібровані перш ніж торкнуться реальних даних. Мінімально: 1. Проведи їх через інструкції анотації (не просто дай PDF) 2. Попроси їх анотувати 20-30 попередньо розмічених навчальних сегментів де ти знаєш правильні відповіді 3. Разом переглянь їхні анотації, обговори розбіжності 4. Починай рахувати рейтинги тільки після цієї калібрувальної фази

Дослідницькі гайдлайни рекомендують “мінімум 2 години навчання на оцінювача”. На практиці для MQM на спеціалізованому контенті плануй повсякденну сесію калібрування.

Дизайн тестового набору¶

Поганий дизайн тестового набору - друга за частотою причина провалу оцінки.

Розмір¶

Гайдлайни MQM-сампілінгу на themqm.org чіткі: ідеал - оцінювати весь перекладений контент; при сампілінгу мінімум 500-1000 слів. Для порівняння двох виробничих систем з достатньою статистичною потужністю - ціль 1000-5000 сегментів.

Нижче 500 сегментів - недостатньо даних щоб відрізнити реальну різницю якості від варіативності контенту.

Практичний орієнтир: - Швидкий скринінг MT-движка: 500-1000 слів - Порівняння вендорів перед контрактом: 1000-2000 сегментів - Валідація виробничого порогу якості: 2000-5000 сегментів

Репрезентативність контенту¶

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

Якщо контент неоднорідний (технічні посібники + маркетингові тексти + FAQ підтримки) - стратифікуй вибірку щоб включити всі типи. Одна цифра по змішаному тестовому набору ховатиме те що движок чудово справляється з посібниками і жахливо з маркетингом.

Ізоляція тестового набору¶

Тестовий набір не повинен бути в навчанні або файнтюнінгу MT-движка. Звучить очевидно, але порушується постійно у вендорських бенчмарках. Якщо вендор надає власні результати - вимагай щоб вони були виміряні на сегментах які контролюєш ти, а не він. Запитуй прямо: “Чи був якийсь частина цього тестового набору використана у файнтюнінгу або адаптації?” Якщо не можуть підтвердити що ні - стався до цифр як до маркетингу, а не оцінки.

Проведення оцінки¶

Сліпа подача¶

Кожен оцінювач бачить: - Вихідний сегмент - Один переклад - (Для MQM) Референсний переклад, якщо використовується

Що оцінювачі не повинні бачити: - Яка система що зробила - Анотації інших оцінювачів на тому самому сегменті - Результати різних систем поряд

Подавай системи в різному випадковому порядку кожному оцінювачу. Анотуй кілька систем у перемішаному порядку - щоб оцінювачі не формували ментальну модель “це виглядає як система A”. Те ж саме що сліпе тестування смаку в харчовій оцінці - і тут це настільки ж важливо.

Дослідження WMT підтвердило: “дослідники виявляли незначну перевагу своїх систем” навіть при нібито сліпій оцінці. Прибери можливість для упередженості.

Контрольні сегменти¶

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

Команда eBay описала цей підхід: профресійні судження “вставляються випадковим чином по всьому завданню оцінки” і використовуються для виключення суддів які показують нижче порогу на контролях. Той самий принцип що перевірки уваги в дослідженні думок.

Якщо оцінювач провалює більше 20-25% контрольних сегментів - його анотації треба перевірити перед включенням.

Інструкції анотації¶

Пиши інструкції анотації до того як набираєш оцінювачів - не після, і не в процесі. Інструкції мають охоплювати:

• Як поводитися з неоднозначним вихідним текстом (не штрафуй МТ за неоднозначність яка вже є в джерелі)
• Як поводитися з кількома правильними перекладами (синоніми що означають те саме - не помилки)
• Область оцінки: оцінюєш сирий MT-вивід чи MT після легкого редагування?
• Які категорії MQM застосовуються до твого типу контенту
• Приклади кожного рівня серйозності з реального доменного контенту

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

Розрахунок міжоцінювального узгодження¶

Якщо маєш 3 оцінювачів і пропустиш цей крок - довіряєш числу яке може бути обумовлене одним нетиповим оцінювачем.

Cohen’s kappa (для двох оцінювачів) і Fleiss’ kappa (для 3+) вимірюють наскільки оцінювачі погоджуються понад те що передбачає випадок:

Для MQM-анотації помилок середнє у дослідженнях - kappa близько 0.51, “помірний” діапазон. Дослідження з добре навченими фахівцями досягали 0.92-0.95.

Якщо kappa нижче 0.3: зупинись перш ніж аналізувати результати, переглянь інструкції разом з оцінювачами, разом анотуйте вибірку, виправ розбіжності - потім продовжуй.

Низька kappa не означає що оцінювачі помиляються - вона означає що інструкції залишають занадто багато простору для інтерпретації.

Типові помилки які знищують результати¶

Оцінювання сегментів поза контекстом документа. Сегмент “Не натискайте цю кнопку” може означати зовсім різне залежно від контексту. Оцінювання на рівні речення сліпе до проблем зв’язності і когерентності. Для будь-чого серйознішого за швидке ранжування - показуй попередній і наступний сегменти.

Відсутність контролю складності вихідного тексту. Легкий контент (короткі сегменти, загальний словник) завищує MT-оцінки відносно складного. Якщо порівнюєш загальний движок на легкому контенті з адаптованим на складному - виміряв контент, а не движки.

Змішування рівнів досвіду оцінювачів. Один професійний перекладач і два двомовних не-перекладачі - це не три еквівалентні точки даних. Або використовуй всіх професіоналів, або аналізуй окремо.

Використання плавності як замінника точності. MT-системи набагато кращі у виробництві плавного виводу ніж точного - це одне з найстабільніших досліджень у MT. Оцінювачі, особливо не-перекладачі, систематично плутають плавність з якістю. MQM запобігає цьому розділяючи виміри; DA заохочує цю плутанину.

Оцінювання без референсу доменного знавця. Оцінювачі без знання домену пропустять термінологічні помилки. У МТ юридичних документів неправильно перекладений термін може змінити зміст зобов’язань - і це помітить тільки юридичний перекладач.

Знання оцінювачами яка система яка. Навіть тонкі підказки - “система A це наш новий движок” - вносять упередженість. Сліпа оцінка не опція якщо потрібні достовірні результати.

Що робити з результатами¶

Результати MQM кажуть де втручатися¶

Якщо MQM-вивід показує: - Багато помилок точності: движок недостатньо розуміє зміст джерела. Файнтюн на доменних паралельних даних або цей тип контенту не підходить для сирого МТ. - Багато помилок плавності: вивід точний але ненатуральний. Хороший стайлгайд + MTPE-воркфлоу виправить це дешевше ніж перекладання. - Багато термінологічних помилок: движок пропускає доменний словник. Виправляй ін’єкцією глосарію, термінологічним файнтюнінгом або інструментами контролю термінів. - Багато помилок локальних конвенцій: проблема конфігурації - формати дат, системи одиниць. Зазвичай виправляється пост-обробкою або конфігурацією движка.

Цей діагноз можливий тільки з MQM. DA-оцінка 65 каже тобі що якість не оптимальна; MQM каже чи вкладати у файнтюнінг, пост-редагування або роботу зі словником.

Встановлення порогів прохід/провал¶

Типові виробничі пороги за типом контенту (MQM-бали на 1000 слів):

Ці числа не універсальні - калібруй під свій контент і вимоги клієнтів. Але вони дають початкову рамку.

Передавай результати вендорам¶

Людська оцінка яка виробляє тільки число - втрачена можливість. Поділись з MT-вендором розподілом MQM-помилок - вони можуть використати це для пріоритизації файнтюнінгу. “Ваш движок має в 3 рази більше критичних помилок точності в підрядних реченнях” - це дійова інженерна інформація яку дельта BLEU надати не може.

FAQ¶

Скільки займає людська оцінка МТ?¶

Для MQM-анотації досвідчений професійний перекладач анотує приблизно 400-600 слів на годину (враховуючи позначення помилкових фрагментів, класифікацію і серйозність). Оцінка 2000 сегментів з 3 оцінювачами займає близько 30-40 людино-годин плюс 4-6 годин навчання і калібрування. Плануй 1-2 тижні на розклад і виконання.

Чи можна використовувати одних і тих самих оцінювачів для кількох оцінок?¶

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

Яка різниця між оцінкою якості і оцінкою якості без референсу (QE)?¶

Людська оцінка (MQM, DA) вимірює фактичну якість людьми що читають вивід. Quality estimation (QE) - автоматизована - вона передбачає показники якості без референсного перекладу, використовуючи моделі навчені на даних людської оцінки. COMET-QE, наприклад, передбачає MQM-подібні оцінки на рівні сегменту. QE набагато дешевша і швидша; людська оцінка - це ground truth яку QE намагається наблизити.

Чи оцінювати сирий MT чи відредагований?¶

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

Джерела¶

• MQM Framework - themqm.org
• MQM Sampling Guidelines
• Slator - How to Fix the 5 Flaws in Evaluating Machine Translation
• Experts, Errors, and Context - TACL/MIT Press
• eBay - Human Evaluation of Machine Translation
• Machine Translate - Human evaluation metrics
• Error Span Annotation: A Balanced Approach (2024)