Як провести порівняльне тестування MT-рушіїв: покроковий гайд по bake-off

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

Ніхто не знає. Те, що ви провели, - це не оцінка, а збір вражень.

Ось як провести справжній bake-off: структурований, відтворюваний і такий, який можна захистити, коли фінансовий відділ запитає, чому ви підписали шестизначний річний контракт на API.

Чому неформальні порівняння МП не працюють¶

У майже кожній неформальній оцінці MT є три типові збої:

Відібрані вручну зразки. Хтось вибирає речення, де улюблений рушій виглядає добре, і це враження залишається. Але те, що виглядає вражаючим у п’яти вибраних сегментах, не узагальнюється на 50 000 виробничих сегментів - і це найпоширеніша помилка в bake-off агенцій.

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

Відсутність базової лінії. Порівняння рушія A з рушієм B показує, який відносно кращий. Але не показує, чи дає будь-який із них реальну економію часу пост-редагування порівняно з перекладом з нуля - а саме це і є економічним обґрунтуванням використання МП.

Структурований bake-off виправляє всі три: фіксований корпус, визначені метрики, сліпа оцінка і порівняння з базовою лінією “з нуля”.

Що насправді вимірює bake-off¶

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

Сценарій A - вирішення, чи взагалі впроваджувати МП. Головне питання: чи є МП + пост-редагування швидшим, ніж переклад з нуля на вашому контенті? Проведіть пілот порівняння часу: дайте перекладачам пакет 2 000 слів для перекладу з нуля і пакет 2 000 слів вихідних даних МП. Виміряйте слів/год. Якщо пакет МП не показує щонайменше 30% покращення throughput, економіка не спрацьовує.

Сценарій B - вибір між 2-3 конкретними рушіями. Це класичний bake-off. Ви порівнюєте відомих кандидатів на одному корпусі, використовуючи автоматичні метрики та людську оцінку пост-редагування.

Сценарій C - оцінка, чи потрібно замінити поточний рушій. Ви вимірюєте, чи новий конкурент або нова версія моделі перевершує вашу виробничу систему на вашому контенті.

Більшість бейкоф у агенціях - це Сценарій B. Решта гайду зосереджена саме на ньому.

Крок 1: Визначте критерії оцінки до того, як торкнетеся будь-якого рушія¶

Запишіть, як виглядає “переможець”, до того, як побачите будь-які результати. Це найважливіше процедурне правило в оцінці МП - без нього оцінка несвідомо підтвердить те враження, яке хтось склав під час налаштування.

Типові критерії оцінки для агенцій, з прикладом ваг:

Ваші ваги відрізнятимуться залежно від бізнесу. Агенція, яка переважно працює з мовними парами ЄС із активним використанням CAT-інструментів, повинна надавати більшу вагу інтеграції. Агенція, яка працює з рідкісними мовними парами, - покриттю. Юридична або медична LSP - безпеці даних.

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

Крок 2: Побудуйте репрезентативний тестовий корпус¶

Тестовий корпус - найважливіший вхідний параметр bake-off. Помилка тут робить усі наступні метрики безглуздими.

Розмір корпусу¶

Практичний мінімум - 2 000 сегментів для однієї мовної пари та домену. Для результатів, які можна впевнено захистити:

• Одна мовна пара, однорідний домен: мінімум 2 000 сегментів
• Кілька доменів (наприклад, технічний + маркетинговий): 500-1 000 на домен, мінімум 2 500 загалом
• Кілька мовних пар: мінімум 1 000 сегментів на мовну пару

При менш ніж 2 000 сегментів відмінності якості між рушіями можуть бути статистично незначущими - одна “важка” або “легка” партія може перекосити результати в будь-який бік.

Склад корпусу¶

Ваш тестовий корпус повинен відображати те, що ваша агенція реально перекладає, у тих пропорціях, у яких ви це робите. Якщо 60% вашого обсягу - рядки інтерфейсу ПЗ, 30% - технічна документація, а 10% - маркетинговий контент, ваш корпус повинен відповідати цьому розподілу.

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

Навмисно включайте крайні випадки: - Речення з числами, датами та одиницями вимірювання - помилки МП тут часто найдорожчі пропустити - Іменовані сутності (назви продуктів, компаній, імена людей) - поведінка рушіїв із ними суттєво відрізняється між постачальниками - Довгі речення (40+ слів) - якість МП знижується на довгих сегментах у деяких рушіях - Галузева термінологія - сегменти, де ваш глосарій найбільш важливий

Еталонні переклади¶

Вам потрібні людські еталонні переклади для кожного сегменту в корпусі - це золотий стандарт для всіх автоматичних метрик (BLEU, COMET, TER). Використовуйте наявні переклади з вашої TM, у якості яких ви впевнені, або замовте нові спеціально для bake-off.

Поширена помилка: використання TM-перекладів як еталонів без їх попередньої перевірки. Якщо ваші еталони містять помилки, кожна автоматична метрика вимірює відхилення від неправильної цілі. Перевірте вибірково 5-10% еталонних перекладів до запуску метрик.

Крок 3: Отримайте тріальний доступ і запустіть усі рушії на одному корпусі¶

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

Запускайте всі рушії на тих самих сегментах у тому самому порядку, якнайближче за часом. Це контролює оновлення моделей - провідні рушії оновлюють ваги 2-4 рази на рік, і оновлення під час bake-off анулює порівняння.

Анонімізуйте вихідні дані перед людською оцінкою. Позначайте файли як “Рушій 1”, “Рушій 2”, “Рушій 3” - не DeepL, Google, Azure. Призначайте мітки рушіїв лише після завершення всіх людських оцінок. Цей крок обов’язковий. Оцінювачі, які знають, який рушій що видав, несвідомо оцінюватимуть результати по-різному виходячи з очікувань від бренду.

Крок 4: Автоматичні метрики - що вони говорять і чого не говорять¶

Запускайте мінімум дві автоматичні метрики. Не покладайтеся лише на одну.

BLEU (Bilingual Evaluation Understudy)¶

BLEU вимірює, скільки словосполучень (n-грами довжиною 1-4) у вихідних даних МП збігаються з еталонним перекладом. Діапазон оцінок 0-100; вищий - кращий.

Типові оцінки BLEU для сучасного нейронного МП: - Основні пари мов ЄС (EN↔DE, EN↔FR, EN↔ES): 30-45 - Менш поширені європейські пари: 20-35 - Далекі мовні пари (EN↔ZH, EN↔JA): 15-30 - Малоресурсні мови: часто нижче 15

BLEU корисний для виявлення очевидних розривів якості між рушіями та відстеження регресій з часом. Чого він не вловлює: не штрафує синтаксично правильні, але семантично неправильні вихідні дані, і не винагороджує правильні вихідні дані, які використовують іншу лексику, ніж еталон. Як показують результати WMT 2023, BLEU погано корелює з людською думкою в чутливих до стилю доменах, таких як маркетинг і художній переклад.

COMET (Crosslingual Optimized Metric for Evaluation of Translation)¶

COMET - нейронна метрика, навчена на даних людської оцінки, спеціально розроблена для кореляції з людською думкою там, де BLEU дає збій. Вона приймає вихідне речення, вихідні дані МП і еталон як вхідні дані і видає оцінку зазвичай між 0,6 і 1,0. Вищий - кращий.

Рекомендована референс-модель wmt22-comet-da (доступна на Hugging Face) є поточним стандартом. Для виробничих bake-off COMET є більш надійною автоматичною метрикою - вона виявляє розбіжності в регістрі та семантичні зсуви, які BLEU повністю пропускає.

TER (Translation Edit Rate)¶

TER вимірює, скільки правок (вставки, видалення, заміни, переміщення) потрібно внести у вихідні дані МП, щоб привести їх до еталону. Нижчий - кращий; 0 означає ідентичність еталону. Типові значення TER для МП: 0,35-0,65 для основних мовних пар.

TER особливо корисний у контекстах MTPE, оскільки він проксі-оцінює зусилля пост-редагування. Рушій із TER 0,35 теоретично потребує менше правок на сегмент, ніж рушій із TER 0,55. На практиці TER - груба проксі: реальні зусилля PE також залежать від розподілу помилок, типу сегменту та індивідуальної швидкості перекладача.

Чого автоматичні метрики не можуть сказати¶

Жодна з BLEU, TER або COMET не скаже вам: - Чи придатні вихідні дані МП для публікації без правок або потребують суттєвої переробки - Чи важливіший конкретний тип помилки у вашому контексті (неправильна дата в юридичному документі критичніша, ніж незграбний прикметник в описі продукту) - Скільки часу насправді витратить редактор, що залежить від його знайомства з доменом і звичної робочої швидкості

Саме тому автоматичні метрики - перший фільтр, а не остаточна відповідь.

Крок 5: Людська оцінка пост-редагування - метрика, яка визначає ваш ROI¶

Два методи людської оцінки надійно працюють в умовах агенції.

Метод A: Сліпа пряма оцінка¶

Оцінювачі бачать кожен вихідний сегмент МП і оцінюють його за шкалою 0-100. Два виміри: адекватність (чи правильний і повний зміст?) і плавність (чи природно читається цільовою мовою?). Еталонний переклад не показується - оцінювачі судять про вихідні дані МП самостійно.

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

Залучайте мінімум двох оцінювачів на рушій і розраховуйте міжоцінювальну узгодженість (IAA). Якщо IAA падає нижче 0,7 (каппа Коена), ваш протокол оцінки потребує вдосконалення.

Метод B: Хронометроване пост-редагування (метрика, яка прогнозує вашу економіку)¶

Дайте редакторам партію 2 000 слів вихідних даних МП - не розкриваючи, який рушій що видав, - і засічіть час виконання завдання. Фіксуйте: - Відредаговані слова на годину для кожного рушія - Редакційна відстань на сегмент (автоматична, через відстань Левенштейна, порівнюючи вихідні дані МП із готовим пост-відредагованим перекладом)

Це єдина метрика, яка безпосередньо перетворюється на бізнес-цінність. Якщо рушій A дозволяє 8 500 слів PE на годину, а рушій B - 6 200 слів PE на годину, рушій A економить приблизно 27% витрат на пост-редагування - незалежно від того, як кожен рушій оцінений за BLEU або COMET.

Як показують дослідження Nimdzi про розрив ефективності MTPE, різниця в throughput пост-редагування між найкращим і найгіршим рушіями зазвичай становить 20-40% - значно більше, ніж більшість очікують до підрахунку чисел.

MQM для структурованого аналізу помилок¶

Коли потрібно знати не просто який рушій гірший, а де кожен рушій систематично дає збій, використовуйте MQM (Multidimensional Quality Metrics). MQM класифікує помилки за типами:

• Точність - неправильний переклад, пропуск, додавання, неперекладений вміст
• Плавність - граматика, пунктуація, правопис, регістр
• Стиль - незграбне формулювання, непослідовність термінології
• Локальні конвенції - формат дати, числа, валюти, адреси

Кожній помилці присвоюється серйозність: незначна (1 бал), значна (5 балів), критична (25 балів). Фінальна оцінка MQM = загальна зважена кількість помилок на 1 000 слів. Нижча - краща.

MQM є стандартним фреймворком оцінки у великих корпоративних замовників МП. Для стандартного bake-off LSP вам не обов’язково потрібен повний фреймворк MQM, але таксономія помилок корисна для розуміння, де кожен рушій дає збій - і чи важливі ці збої для вашого конкретного типу контенту.

Крок 6: Тестуйте інтеграцію у вашому реальному TMS і CAT-інструменті¶

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

Що перевіряти¶

• Нативний плагін vs API-конектор: Чи є у рушія офіційний плагін для вашого CAT-інструменту (memoQ, Trados, Phrase, Smartcat)? Нативні плагіни краще обробляють контекст сегментів і підтримуються постачальником. API-конектори через проміжне ПЗ працюють, але додають залежність, яка може зламатися при оновленнях CAT-інструменту.
• Застосування глосарію: Завантажте термінологічну базу клієнта з 20-30 термінів і перевірте, чи вони правильно відображаються у вихідних даних МП. Тестуйте як стандартні, так і крайні терміни.
• Обробка контексту: Чи отримує рушій навколишні речення як контекст, чи перекладає кожен сегмент ізольовано? Контекстно-залежний переклад (вікно речень) покращує узгодженість у зв’язному тексті, особливо для рядків інтерфейсу та структурованих документів.
• Пропускна здатність пакетної обробки: Скільки символів на секунду API обробляє для вашого типового розміру пакету? Для процесів нічної обробки час виконання завдання 2 год проти 20 хв має реальний операційний вплив.

Мінімальний інтеграційний тест¶

Налаштуйте макет проекту: реальний клієнтський файл (або такий, що відображає ваш типовий формат), попередньо перекладений кожним рушієм, імпортований у ваш TMS, призначений редактору і завершений. Засічіть час повного циклу. Це виявляє проблеми, які ви б ніколи не помітили при оцінці на рівні сегментів: проблеми форматування файлів, обробки тегів, помилки меж сегментів і конфлікти збігів TM з вихідними даними МП.

Крок 7: Розрахуйте загальну вартість володіння¶

Ціна API - найбільш помітне число, але рідко найбільша складова TCO для агенцій, що займаються MTPE у великих обсягах.

Формула TCO¶

Річний TCO = (Місячний обсяг символів × ціна API/символ × 12)
           + (Річні слова PE ÷ слів PE/год × погодинна ставка PE)
           + (Вартість налаштування інтеграції ÷ 3)    [амортизована за 3 роки]
           + (Щорічне обслуговування: оновлення плагінів, синхронізація глосарію, управління TM)

Приклад із реальними числами¶

Агенція, що обробляє 5 мільйонів символів на місяць, EN→DE, з пост-редагуванням зі швидкістю 7 500 слів/год за вартості 35 €/год. Приблизне співвідношення символ/слово: 1 слово ≈ 5,5 символу.

(Вартість PE = річні слова PE ÷ throughput × погодинна ставка. При 5 млн символів/міс: річні символи = 60 млн, при 5,5 символу/слово = ~10,9 млн слів/рік)

При таких масштабах різниця в throughput PE 700 слів/год означає 5 000-7 000 € на рік у витратах на персонал - більше, ніж різниця у вартості API. Саме тому пілот throughput PE з кроку 5 є найважливішим числом у вашій моделі TCO.

Таймлайн bake-off і ролі¶

Мінімальний bake-off для двох рушіїв займає 3-4 тижні:

Хто що робить: - Інженер з локалізації / керівник проекту: підготовка корпусу, налаштування API, анонімізація, підрахунок метрик - 2-3 старші редактори: сліпа пряма оцінка і хронометрований пілот PE - Фінанси або операції: модель TCO і перевірка контракту API

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

Поширені скорочення, які анулюють bake-off¶

• Показ оцінювачам назв рушіїв до завершення оцінки
• Використання тестового корпусу з опублікованих бенчмарків постачальника (відібрані для демонстрації сприятливих результатів)
• Використання TM-сегментів, які рушій міг бачити під час навчання
• Пропуск хронометрованого пілота PE через те, що він “займає забагато часу” - це усуває єдиний безпосередньо бізнес-значущий вимір

Шаблон оцінки та рішення¶

Заповніть цей шаблон після завершення всіх оцінок, до обговорення результатів із командою:

Скоркард bake-off MT-рушіїв
Мовна пара: _______________   Домен: _______________   Дата: ___________

                                  Вага    Рушій A    Рушій B    Рушій C
Оцінка COMET                      25%       ___        ___        ___
Штрафна оцінка MQM                10%       ___        ___        ___
Throughput PE (слів/год)           30%       ___        ___        ___
Відповідність інтеграції CAT       15%       ___        ___        ___
TCO рік 1                         10%       ___        ___        ___
Покриття мов                       5%       ___        ___        ___
Відповідність безпеці даних        5%       ___        ___        ___
                                  ---
Зважена загальна оцінка           100%      ___        ___        ___

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

FAQ¶

У чому різниця між bake-off і пілотом?¶

Bake-off - це структурована оцінка для вибору рушія. Пілот - це реальний виробничий запуск (зазвичай 15 000-25 000 слів) із рушієм-переможцем, який використовується для валідації бізнес-показників до повного впровадження. Вони послідовні: спочатку bake-off, потім пілот.

Чи варто включати LLM-переклад (GPT-4, Claude) у bake-off?¶

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

Як оцінити рідкісні мовні пари, де у нас немає штатних лінгвістів?¶

Два варіанти: (а) залучіть фрілансера-лінгвіста для конкретної мовної пари спеціально для оцінки bake-off - це єдиний повністю надійний варіант; (б) використовуйте COMET-QE (режим оцінки якості, без еталону) як проксі, але перевіряйте хоча б невеликою людською вибіркою. Не покладайтеся виключно на автоматичні метрики для мов, які ви не можете валідувати.

Чи виправданий bake-off для агенцій із невеликим обсягом?¶

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

Як часто потрібно повторно проводити bake-off після вибору рушія?¶

Основні рушії оновлюють свої моделі 2-4 рази на рік. Запускайте швидку перевірку автоматичних метрик на фіксованому відкладеному наборі щоквартально. Проводьте повноцінний bake-off, коли: конкурентний рушій випускає основну версію, яка претендує на перевершення вашого поточного вибору; ваш мовний склад суттєво змінюється; або ви наближаєтеся до продовження річного контракту на API.