Ви завантажуєте 40 000 слів у MT-рушій у понеділок. У середу редактор пише вам: “Якість цього батча гірша за звичайне - витрачаю вдвічі більше часу на сегмент”. А ви вже зафіксували терміни і ставку для MTPE в договорі з клієнтом.
Ось що відбувається, коли якість MT не вимірюється до початку проекту. Вміти оцінити якість перед тим, як взяти зобов’язання, і мати систему, яка вловлює деградацію коли вона починається, - ось що відрізняє агентства, які заробляють на MTPE, від тих, що поглинають збитки.
Чому вимірювання якості MT - це бізнес-рішення, а не академічна вправа¶
Оцінка якості перекладу існує у двох світах. Дослідники відстежують кореляції метрик до сотих частин відсотка. Агентствам у продакшні потрібні відповіді на три конкретні питання:
- Чи достатньо хороший цей MT-аутпут, щоб запустити MTPE за тією ставкою, яку я озвучив?
- Який рушій краще для цього типу контенту і мовної пари?
- Чи деградувала якість посередині проекту - і наскільки?
Автоматичні метрики типу BLEU отримують багато критики в науковому середовищі - і значна її частина справедлива. Але для агентств їхня цінність не в ідеальній кореляції з людськими судженнями. Вона в тому, що вони швидкі, безкоштовні і достатньо послідовні, щоб вловлювати великі падіння якості до того, як вони стануть дорогою проблемою.
Автоматичні метрики: що вони вимірюють і коли використовувати¶
Автоматичні метрики порівнюють MT-аутпут з еталонним перекладом - зазвичай людською пост-редакцією - і видають бал. Ніякого людського рецензента, результат за секунди. Компроміс: усі автоматичні метрики вимірюють поверхневий збіг з еталоном, а не реальну якість перекладу.
BLEU - галузевий стандарт, який треба розуміти¶
BLEU (Bilingual Evaluation Understudy) опублікували Papineni et al. з IBM Research у 2002 році - і відтоді це дефолтна метрика оцінки MT. Вона вимірює, скільки n-грам (послідовностей слів) із MT-аутпуту також зустрічаються в еталонному перекладі. Бал від 0 до 100, вищий - більший збіг з еталоном.
Чому агентства досі використовують BLEU: - Швидкий і безкоштовний (sacrebleu - стандартна реалізація з відкритим кодом) - Відтворюваний - при однакових даних два виконавці отримають однаковий бал - Порівнюваний між рушіями при однаковому тестовому наборі і токенізації
Чому на BLEU не можна покладатися як на єдину метрику: - Вимірює збіг слів, а не зміст. Речення, що правильно передає сенс, але іншими словами, отримає нижчий бал, ніж речення, яке збігається з еталоном, але тонко помилкове. - Чутливий до стилю еталону - якщо еталон відображає вибір одного перекладача, MT з рівноцінними, але іншими формулюваннями отримає низький бал. - Погано корелює з людською оцінкою - особливо для творчого контенту, мов з вільним порядком слів, малоресурсних мовних пар.
Орієнтовні діапазони для технічного контенту у великих мовних парах:
| Діапазон BLEU | Що означає | Очікуваний рівень пост-редагування |
|---|---|---|
| < 25 | Погана якість, значне доопрацювання | FPE або перекласти з нуля |
| 25-40 | Середня якість | FPE необхідний |
| 40-50 | Хороша якість | LPE швидше за все достатньо |
| > 50 | Висока якість (доменний контент) | LPE або легка перевірка |
Ці діапазони суттєво змінюються залежно від мовної пари і домену. EN-FR технічний контент при BLEU 40 - зовсім інша ситуація, ніж EN-AR юридичний при BLEU 40.
TER - безпосередньо корисний для оцінки зусиль редагування¶
Translation Edit Rate (TER) вимірює, скільки правок - вставок, видалень, замін і переставлень - потрібно, щоб перетворити MT-аутпут в еталон, поділене на довжину еталону. TER 0,3 означає, що приблизно 30% слів потребують редагування. Нижче - краще.
TER природно відповідає MTPE-воркфлоу, бо прямо моделює зусилля редагування. Агентства, які відстежують TER по проектах, можуть накопичити емпіричні дані про те, який поріг прогнозує прийнятну швидкість пост-редагування для їхніх конкретних редакторів і типів контенту.
Практичні порогові значення на основі галузевих бенчмарків:
| Діапазон TER | Що означає | Дія |
|---|---|---|
| < 0,3 | Висока якість MT | LPE придатний, ставте відповідну ціну |
| 0,3-0,5 | Середня якість | FPE необхідний, закладіть час редактора |
| > 0,5 | Погана якість | Зусилля редагування наближаються до повного перекладу - перегляньте ціну або перенаправте |
Застереження: TER не враховує складність окремих правок. Виправлення термінологічної помилки, яка зайняла 10 хвилин на дослідження, рахується так само, як додати пропущений прийменник. Тому людські дані пілоту завжди точніші за TER.
chrF - краще для мов з багатою морфологією¶
Character n-gram F-score (chrF) працює на рівні символів, а не слів - це робить її чутливішою до морфологічних варіацій. Для мов, де закінчення слів суттєво змінюються залежно від граматичного контексту - для української, російської, фінської, угорської, польської - chrF часто краще корелює з якістю, ніж BLEU.
Якщо ваше агентство активно працює зі східноєвропейськими або аглютинативними мовними парами, chrF не коштує нічого додатково (вона в sacrebleu поруч з BLEU) і дає надійніший сигнал для цих пар.
COMET - найкраща автоматична метрика зараз¶
COMET (Crosslingual Optimized Metric for Evaluation of Translation), розроблений Unbabel, використовує нейромережу, навчену на людських оцінках якості з кампаній WMT. Це найкраща автоматична метрика в WMT Metrics Shared Tasks стабільно з 2020 року.
Практична відмінність від BLEU: COMET краще вловлює, чи семантично правильний переклад, а не тільки чи використовує він ті самі слова, що й еталон. Два переклади, що передають однаковий зміст, але формулюють його по-різному, отримають дуже різні бали BLEU, але схожі бали COMET.
Коли використовувати COMET: - Вибір рушія - порівняння DeepL, Google Translate, Microsoft Translator або власного рушія для вашого типу контенту - Регресійне тестування - виявлення падіння якості після оновлення рушія - Бенчмаркінг мовних пар - розуміння, для яких пар MT надійно видає якісний результат
Підсумок метрик:
| Метрика | Потрібен еталон? | Найкраще для | Основне обмеження |
|---|---|---|---|
| BLEU | Так | Швидкий сигнал, порівняння рушіїв | Погана кореляція зі змістом |
| TER | Так | Оцінка зусиль редагування | Не враховує складність правок |
| chrF | Так | Морфологічно багаті мови | Поверхнева метрика |
| COMET | Так (DA-версія) | Найкращий автоматичний сигнал | Потрібне налаштування Python |
MQM: професійний стандарт для людської оцінки якості¶
Автоматичні метрики показують, наскільки MT-аутпут схожий на еталон. MQM (Multidimensional Quality Metrics) показує, що саме в ньому не так.
MQM - це таксономія помилок: структурований спосіб для людей-рецензентів категоризувати і оцінювати помилки перекладу. Використовується командою якості Google Translate, Microsoft і державними перекладацькими службами. Категорії помилок дають вам дієві дані, а не просто бал.
Основні категорії помилок MQM:
Помилки точності (чи переклад передає те, що сказано в джерелі?): - Неправильний переклад: передано неправильний зміст - Неповний переклад: контент джерела пропущено - Надмірний переклад: додано зміст, якого немає в джерелі - Неперекладено: текст джерела залишено без перекладу
Помилки плавності (чи читається переклад природно?): - Граматика: неправильна морфологія, синтаксис, узгодження - Типографіка: розділові знаки, регістр, відступи - Регістр: неправильний рівень формальності для контексту
Термінологічні помилки: - Неправильний технічний термін (проти затвердженого глосарію) - Непослідовне вживання терміну в документі
Стилістичні помилки: - Не відповідає голосу бренду або стайл-гайду - Незграбне формулювання, яке технічно правильне, але так не пишуть носії
Кожна помилка отримує ступінь критичності: критична (завдає шкоди або правові проблеми), велика (суттєво впливає на якість), мала (незначна, не впливає на розуміння). Бал MQM розраховується з кількості помилок, зважених за критичністю, відносно порогів, які ви самі встановлюєте для кожного типу контенту.
Коли агентствам потрібен MQM: - Контракти з клієнтами, що передбачають формальні метрики якості - Процеси відповідності ISO 17100 або 18587 - Формальний вибір між конкурентними рушіями - Точкові перевірки поточного MTPE-аутпуту відносно базової лінії
Коли повний MQM не потрібен: - Внутрішній контент без формальних вимог до QA - Великооб’ємний MTPE низького ризику, де проксі якості є відстань редагування
Навіть якщо ви не проводите формальні MQM-аудити, категорії помилок корисні як мнемоніка для людей-рецензентів. Навчити рецензентів класифікувати знайдені помилки - точність vs плавність vs термінологія - означає генерувати дані, що допоможуть виявити системні слабкості MT у конкретних доменах або мовних парах.
Quality Estimation: оцінка якості без еталонного перекладу¶
Метрики з еталоном (BLEU, TER, COMET-DA) потребують людської пост-редакції для порівняння. Проблема: дані про якість потрібні до пост-редагування, щоб вирішити як її проводити.
Quality Estimation (QE) вирішує це, прогнозуючи якість перекладу безпосередньо з джерела і MT-аутпуту, без жодного еталону. Це практичний інструмент для маршрутизації в продакшні.
Моделі QE навчаються на людських оцінках і вчаться прогнозувати бали якості для пар джерело-MT. Вони можуть позначати окремі сегменти, які потребуватимуть серйозного редагування - до того як редактор до них дійде, що дозволяє автоматично маршрутизувати потоки у великих обсягах.
Інструменти QE, доступні у 2026 році:
COMET-Kiwi (відкритий код, від Unbabel): поточна топова QE-модель у WMT. Прогнозує бали якості на рівні сегменту без еталону. Потребує Python, але запускається локально.
ModelFront: комерційний QE-інструмент для агентств і LSP, спеціально для автоматичного маршрутизування воркфлоу. Інтегрується з основними TMS-платформами.
DeepL Quality Check: власна система балів впевненості DeepL, доступна через API поряд з перекладами.
Phrase (колишній Memsource): вбудований QE від кількох провайдерів, доступний без окремого налаштування.
Практичні сценарії використання QE:
Автоматичне маршрутизування: сегменти вище порогу впевненості йдуть на LPE, нижче - позначаються для FPE або повного людського перекладу. У великих обсягах це може знизити зусилля пост-редагування на 20-30%.
Оцінка ризику перед проектом: запустіть вихідний файл через QE до того, як взяти зобов’язання. Якщо середні бали QE низькі - цей проект вимагатиме важчого пост-редагування, і ваша ціна має це відображати.
Порівняння рушіїв без еталонного набору: порівняйте бали QE двох рушіїв на одному джерелі. Менш надійно, ніж метрики з еталоном, але корисно, коли немає золотого стандарту для нового типу контенту.
Пілотне тестування: єдина перевірка, яка реально працює¶
Автоматичні метрики дають сигнали. QE дає прогнози. Ніщо з цього не замінить те, що ви отримаєте від людського пілоту на реальному контенті.
Перед тим як взяти значний проект на MTPE - особливо для нової мовної пари, нового типу контенту або нового MT-рушія - проведіть людський пілот. Він займає кілька годин. Він може запобігти тижням збитків.
Протокол пілоту:
Крок 1 - Виберіть вибірку. 3 000-5 000 слів, репрезентативних для реального проекту. Не вибирайте тільки прості сегменти. Якщо в проекті є таблиці, юридичні пункти і технічні специфікації - включіть усі три у вибірку.
Крок 2 - Згенеруйте MT. Використовуйте саме той рушій і ті налаштування, що й для всього проекту. Не тестуйте на іншій версії рушія або з іншою попередньою обробкою.
Крок 3 - Пост-редагування з відстеженням. Попросіть надійного лінгвіста відредагувати вибірку, фіксуючи: час на сегмент (більшість CAT-інструментів це логують автоматично), відстань редагування (скільки вони змінили відносно MT-аутпуту), сегменти, які довелося переписати повністю.
Крок 4 - Розрахунок і інтерпретація. З даних пілоту: - Слів/год: якщо нижче 500 - проект наближається до зусиль повного перекладу, ваша MTPE-ціна, мабуть, не спрацює - Середній TER: надійна оцінка зусиль для всього проекту - Відсоток повністю переписаних сегментів: вище 20% - MT-рушій не справляється з цим типом контенту
Крок 5 - Рішення. Якщо дані пілоту підтверджують придатність MTPE - ставте ціну відповідно. Якщо ні - або переставте ціну на рівень FPE, або рекомендуйте клієнту людський переклад, або позначте це до того, як взяти зобов’язання.
Як показує аналіз продуктивності SwissGlobal 2026, продуктивність MT суттєво відрізняється між мовними парами: для EN-FR вони зафіксували +130% приросту швидкості при MTPE, а для EN-SE - мінус 7% (повільніше за людський переклад). Цей розрив виявляється тільки через пілотне тестування для кожної пари окремо.
Відстеження якості в часі: базові лінії і виявлення деградації¶
Одноразова перевірка перед проектом недостатня. MT-рушії оновлюються без попередження. Типи контенту змінюються. Редактори міняються. Якість може повільно деградувати місяцями, поки хтось не надішле скаргу клієнт.
Сформуйте базову лінію якості і регулярно порівнюйте з нею.
Що відстежувати: - Бали BLEU або COMET на фіксованому тестовому наборі (ті самі сегменти завжди - ніколи не міняйте тестовий набір) - TER по проектах для однієї мовної пари і типу контенту - Швидкість пост-редагування (слів/год) для кожного лінгвіста по типу контенту - в логах TMS - Щільність помилок при людських перевірках (помилок на 1 000 слів за категоріями MQM)
Коли запускати перевірку: - Після будь-якого оновлення або зміни MT-рушія - Коли редактор повідомляє, що якість змінилася - Коли час пост-редагування на проект стабільно росте - Щоквартальна точкова перевірка для найбільших за обсягом мовних пар
Фіксований тестовий набір з 1 000-2 000 сегментів, один раз відредагований надійним лінгвістом і назавжди заморожений, дає відтворювальний бенчмарк. Запуск COMET на свіжому MT-аутпуті відносно цього еталону займає хвилини і одразу показує, чи змінилася якість.
Саме цю проблему фіксує звіт Nimdzi MTPE Efficiency Gap: агентства, що маршрутизують контент на MTPE без відстеження якості, часто платять за пост-редагування, що наближається до зусиль повного перекладу, при цінах MTPE.
Метрики якості MT vs якість перекладу - це різні речі¶
Важлива відмінність, яку часто плутають: метрики якості MT оцінюють, наскільки хороший сирий MT-аутпут. Оцінка якості перекладу (за ISO 18587:2017 та ISO 17100) оцінює фінальний пост-редагований результат.
Для клієнтських контрактів і гарантій якості важлива якість фінального аутпуту, а не сирого MT. Поганий MT може дати відмінний фінальний результат після роботи досвідченого редактора. Хороший MT може залишитися з помилками після неуважного редактора.
Отже: метрики якості MT мають керувати вашими внутрішніми рішеннями - маршрутизація, ціноутворення, вибір рушія. Людська перевірка пост-редагованого аутпуту керує клієнтськими гарантіями якості.
Виняток: якщо клієнт вимагає підтвердження, що AI-інструменти не використовувалися, або що переклад є “авторським людським перекладом” - це юридично-договірні вимоги, які метрики якості MT не можуть задовольнити незалежно від балів.
Де в цьому всьому AI-платформи для документів¶
Для агентств, що обробляють великі обсяги документального перекладу - технічні мануали, каталоги продуктів, стандартні договори - шар роботи з файлами (видобування тексту, збереження форматування, збирання перекладеного файлу) часто є таким самим тертям, як і лінгвістична якість.
Платформи типу ChatsControl беруть на себе шар завантаження документів і генерації відформатованого чернетки (DOCX, PDF зі збереженням макету), після чого результат іде до редактора. Оцінка якості MT все одно застосовується, щоб визначити маршрутизацію - платформа бере на себе роботу з файлами, а не оцінку якості. Для сертифікованого або нотаріального перекладу не підходить.
Часті питання¶
Як порівняти два MT-рушії та обрати один для агентства?¶
Запустіть обидва на одному тестовому наборі з 500-1 000 сегментів, репрезентативних для вашого реального контенту. Розрахуйте BLEU і COMET для кожного аутпуту. Потім попросіть одного редактора відредагувати 100-200 сегментів від кожного рушія, окремо відстежуючи час. Автоматичні бали покажуть відносний рейтинг. Людський пілот - чи дійсно кращий за рейтингом рушій помітно швидший на практиці.
Не проводьте оцінку на загальних інтернет-тестових наборах - вони не відображають ваш домен і не прогнозують реальну продуктивність.
Чи потрібно будувати власні еталонні переклади?¶
Для постійної оцінки - так, потрібні власні галузеві еталони. Загальні еталони з наборів даних WMT не відображають якість технічного або юридичного перекладу і дають оманливі бали.
Будуйте еталонний набір із роботи, яку вже робите. Після кожного значного проекту зберігайте 200-500 пост-редагованих сегментів із джерелами як постійний тестовий набір для цієї мовної пари і типу контенту. За 6 місяців у вас будуть надійні дані для оцінки найбільш частих пар.
Як вимірювати якість MT у продакшні без еталонних перекладів?¶
Використовуйте інструменти Quality Estimation. COMET-Kiwi, ModelFront або вбудований QE в Phrase можуть оцінити MT-аутпут без еталону. Вони прогнозують якість, а не вимірюють відносно стандарту, але для рішень про маршрутизацію - який сегмент потребує важкого vs легкого редагування - бали QE добре справляються на практиці.
Також можна використовувати сам процес пост-редагування як дані про якість: відстежуйте відстань редагування на сегмент під час роботи редакторів. Після накопичення 10 000+ сегментів даних у вас буде реальна емпірична база для розуміння, що таке хороший і поганий MT-аутпут у ваших конкретних воркфлоу.
Яка різниця в зусиллях між BLEU 35 і BLEU 45?¶
Для технічного EN-DE контенту: BLEU 35 зазвичай означає 35-45% сегментів потребують значного редагування, BLEU 45 - приблизно 20-30%. Це приблизно 600-700 слів/год при BLEU 35 проти 800-1 000 слів/год при BLEU 45 для FPE. Чи суттєва ця різниця для вашої маржі - залежить від ставки клієнта і оплати редактора.
Для творчого або маркетингового контенту ті самі бали BLEU є в основному безглуздими як предиктори зусиль - MT може бути плавним і при цьому вимагати майже повного перекладу, бо він культурно неправильний.
Чи можна вписати метрики якості MT у клієнтські контракти?¶
Так, але обережно. Якщо ви вказуєте мінімальний BLEU або поріг помилок у контракті, ви і клієнт повинні узгодити методологію: однаковий тестовий набір, однаковий еталон, однаковий інструмент оцінки. MQM-контракти більш захищені, бо категорії помилок зрозумілі: “жодних критичних помилок точності за таксономією MQM” чіткіше і більш піддається аудиту, ніж “BLEU вище 45.”
Джерела¶
- Papineni et al. (2002) - BLEU: A Method for Automatic Evaluation of Machine Translation
- Unbabel/COMET - Crosslingual Optimized Metric for Evaluation of Translation
- ISO 18587:2017 - Post-editing of machine translation output
- GTS Translation - The State of MTPE in 2025: What Translators Think
- SwissGlobal - Translation productivity 2026: human translation vs MTPE
- Slator - How Fast Should You Post-edit Machine Translation?
- Nimdzi - The MTPE Efficiency Gap
- Hunnect - Fair Pricing Strategies for MTPE