Скінчився дедлайн, команда пост-редакторів завершила робочий день, а потім контроль якості виявляє 140 помилок у 2000 сегментів — половина яких автоматичні QA-перевірки мали би ловити без люди. Подвійні пробіли, забуті терміни, невідповідності форматування, пропущені числа. Все те, що алгоритм видить краще людини, але ніхто не налаштував.
Ось чому автоматичні QA-перевірки — це не «вишенька на тортику» в MTPE-потоці, а фундамент. Вони не замінюють людські рецензії, але ловлять 70% грубих помилок ДО редагування, заощаджуючи 25-40% часу редактора і запобігаючи упущенням, які дорого коштують у фіналізації.
Що таке автоматичні QA-перевірки¶
Автоматичні QA-перевірки — це налаштовані правила, які сканують перекладений текст і ловлять об’єктивні, легко-пропустити помилки без посилання на еталон чи людське судження.
На відміну від людського рецензента, що прочитує весь текст і оцінює семантику, QA-перевірка працює за простими правилами:
- «Якщо в цільовому тексті подвійний пробіл — заповідити»
- «Якщо цільовий термін не збігається з глосарієм — сигнал»
- «Якщо кількість чисел в джерелі не дорівнює цільовій — заповідити»
- «Якщо теґ <b> в джерелі, але не в цілі — заповідити»
Ці перевірки запускаються автоматично в CAT-інструментах (memoQ, Trados, Smartcat, Phrase) або в окремих QA-модулях на кожному етапі MTPE-потоку.
Чому QA-перевірки критичні для MTPE¶
MTPE-цикл виглядає так: машинний переклад → пост-редагування → контроль якості → експорт. На практиці, якщо QA-перевірки слабкі або відсутні, контроль якості витрачає 40-50% часу на пошук механічних помилок, а не на редакцію семантики чи ревю термінології.
За дослідженням QE4PE (2025), коли пост-редактори знають, де машинний переклад слабкий, вони редагують 30% швидше — вони мають фокус. Але якщо у них немає сигналів від QA, вони втрачають 15-25% часу на пошук помилок, замість спрямування до них.
Крім того, ISO 18587:2017 (стандарт для MTPE) вимагає валідацію мінімум 8 категорій помилок: 1. Терміни (консистентність, глосарій) 2. Пунктуація 3. Числа і формати дат 4. Теґи (HTML, XML, форматування) 5. Форматування (абзаци, проміжки, перенесення) 6. Пропущені або додаткові сегменти 7. Правопис 8. Контекст (деякі помилки потребують контексту, не тільки сегменту)
Якщо ви не перевіряєте всі 8 — ви рискуєте невідповідністю стандартам.
Обов’язкові QA-перевірки для MTPE¶
1. Термінологічна консистентність¶
Термін, один раз перекладений як «API», у наступній появі не може бути «Інтерфейс програмування». Постійно.
Як це працює: - Глосарій проекту містить схвалені терміни і їх переклади. - QA-перевірка сканує кожен сегмент: якщо вихідний термін присутній, але переклад не збігається з глосарієм — сигнал. - У memoQ ви можете налаштувати перевірку терміна в обох напрямках: якщо джерело має термін, ціль мусить мати відповідний переклад; і навпаки, якщо ціль має термін, він повинен відповідати глосарію.
Реальний приклад: Проект про фінанси. Глосарій: «акція» = «share», «дивіденд» = «dividend», «ризик» = «risk». Редактор по невдачі пишет «акция» (російська) замість «акція» (українська). QA-перевірка ловить це як «невідповідність терміну». Без перевірки — опубліковано.
Як налаштувати: - В memoQ/Trados: QA Settings → Terminology → «Check terminology» + «Both directions» (якщо ви хочете перевіряти, чи всі глосарійні терміни використані). - Але будьте обережні: якщо глосарій завелике або містить опціональні варіанти, надто багато хибних сигналів. Розділіть глосарій на «mandatory» і «recommended».
2. Форматування і пунктуація¶
Подвійні пробіли, пропущена кома, розривальні символи, де їх не має бути.
QA-перевірка ловить: - Подвійні пробіли (два пробіли поспіль) - Пропущена пунктуація в кінці (якщо джерело закінчується крапкою, ціль теж повинна) - Невідповідні лапки або дужки (відкрита дужка без закриття) - Пропущена абзацна структура
Приклад:
Джерело: «Hello, world.»
Переклад: «Привіт, світ»
QA ловить: пропущена крапка в кінці.
Налаштування: в memoQ/Trados → QA → Punctuation & Spacing → включіть «check trailing punctuation» і «check double spaces».
3. Числа і дати¶
Числа часто вимагають локалізації (тисячні роздільники, формати дат), і якщо автоматичний переклад пропустив число або отримав неправильне — має буть помічено.
QA-перевірка ловить: - Кількість чисел в джерелі != кількість чисел в цілі - Числа, які мали бути відформатовані по-іншому (1,000 в англійській, 1.000 в німецькій, 1 000 в українській) - Дати в неправильному форматі (DD.MM.YYYY vs MM/DD/YYYY)
Приклад:
Джерело (англ.): «Cost: $1,500»
Переклад: «Вартість: $1500» (без розділювача)
QA виявляє: число присутнє, але формат змінений; залежно від налаштувань — сигнал.
4. Теґи (Tags) і заповідники¶
HTML/XML теґи, плейсхолдери для змінних, теґи форматування DOCX (bold, italic, hyperlinks).
QA-перевірка ловить:
- Теґ <b> в джерелі, але не в цілі (або навпаки)
- Плейсхолдер {name} пропущений в цілі
- Закрита дужка без відкритої
Без цієї перевірки перекладений документ розпадається при експорті.
Приклад:
Джерело: <p>This is <b>bold</b> text.</p>
Переклад: <p>Це <b>жирний текст.</p> (закривальний теґ пропущений)
QA ловить: невідповідність теґів.
5. Пропущені або додаткові сегменти¶
Якщо джерело має 2000 сегментів, а переклад — 1998 або 2002, це серйозна проблема.
QA-перевірка ловить: - Кількість сегментів не збігається - Сегмент вийшов порожнім (тільки пробіли або спеціальні символи) - Переклад містить тільки джерельний текст (не перекладено)
Якість машинного перекладу: метрики¶
Крім перевірки правил, варто розуміти якість самого машинного перекладу ДО редагування. Це допомагає вирішити: чи редагувати весь документ, чи вибірково?
BLEU (Bilingual Evaluation Understudy)¶
BLEU вимірює схожість перекладу до еталонного перекладу з використанням n-грам (послідовностей слів). Шкала: 0-100.
- BLEU > 50 — гарна якість, редагування слід бути легким.
- BLEU 30-50 — середня якість, редагування типове.
- BLEU < 30 — погана якість, або переклад потребує переробки, або дані дуже спеціалізовані.
Обмеження: BLEU ігнорує контекст, може нагороджувати невірні за смислом переклади якщо слова збігаються.
TER (Translation Edit Rate)¶
TER рахує кількість редагувань (вставок, видалень, замін, зрушень фраз), які потрібні, щоб машинний переклад став еквівалентний еталону, поділеному на довжину еталону.
- TER < 40 — сильна якість (мало редагувань).
- TER 40-50 — прийнятна якість.
- TER > 60 — слаба якість, потребує серйозного редагування або перекладу заново.
Приклад: Джерело: 100 слів. Машинний переклад потребує 35 редагувань на еталон. TER = 35 / 100 = 35% — сильна якість.
COMET (Crosslingual Optimized Metric for Evaluation of Translation)¶
COMET — це нейронна мережа, навчена на людських оцінках якості, і дає набагато точніші оцінки, ніж BLEU. Вона корелює з людськими оцінками на рівні сегменту набагато краще.
На 2024-2025 рік COMET стає стандартом у професійних QA-конвеєрах, де точність важлива.
Маршрутизація на основі якості¶
Якщо ви знаєте якість машинного перекладу заздалегідь, можна маршрутизувати:
- BLEU > 60, TER < 30: контент уже вивіриється якості, можете пропустити пост-редагування або зробити легке редагування.
- BLEU 40-60, TER 30-50: типове пост-редагування, але редактор знає, що якість нормальна.
- BLEU < 40, TER > 50: перекладайте заново, не редагуйте.
Це дозволяє розподілити ресурси розумніше.
Типові помилки при налаштуванні QA¶
1. Надто багато сигналів → перевтома сигналів¶
Якщо QA-перевірка виявляє 500 попереджень у 1000 сегментів, редактор ігнорує їх. Будьте вибіркові.
Рішення: розділіть на hard rules (блокувати) і soft rules (сигнал). Hard: забуті сегменти, невідповідні теґи. Soft: можливо неправильний термін.
2. QA-перевірка не оновлена з проектом¶
Глосарій проекту змінився, але QA-правила ні. Результат: застарілі помилки дозволяються, нові терміни не перевіряються.
Рішення: переглядайте та оновлюйте QA-профіль при кожній значній зміні проекту.
3. Одна QA-перевірка на всі мови¶
Формати дат, символи пунктуації, порядок слів залежать від мови. QA-профіль для англійської → німецької відрізняється від англійської → японської.
Рішення: налаштуйте окремі QA-профілі для кожної мовної пари.
Як впровадити QA в потік роботи¶
Крок 1: Визначте категорії помилок, що мають ловитися¶
Для вашого проекту/домену вирішіть: які помилки найчастіше пропускаються? Терміни? Числа? Теґи? Починайте з цього.
Крок 2: Налаштуйте CAT-інструмент¶
- memoQ: Workspace → Project Settings → QA → включіть необхідні перевірки (Terminology, Punctuation, Numbers, Tags, etc.).
- Trados: Tools → QA Checker Configuration → налаштуйте per-project rules.
Крок 3: Тестуйте з невеликим набором¶
Запустіть QA на 100-200 сегментів, переглядайте результати: скільки справжніх помилок, скільки хибних сигналів? Настройте чутливість.
Крок 4: Інтегруйте в редакторський робочий процес¶
Експортуйте QA-результати редакторам перед редагуванням або показуйте сигнали прямо в редакторі. Більшість CAT-інструментів мають вбудовані сигнали.
Крок 5: Контролюйте тренди¶
Відстежуйте: кількість QA-сигналів на сегмент, кількість помилок, що пропустили QA. За кілька проектів побачите, що працює, що не працює.
Часті питання¶
Як часто повинні запускатися автоматичні QA-перевірки в MTPE-потоці?
На кожному кроці: після машинного перекладу (для маршрутизації), під час редагування (для сигналів в редакторі), та перед експортом (фінальна перевірка). В інтегрованих CAT-інструментах це відбувається постійно без людської дії.
Чи можна залишити тільки перевірку термінологічної консистентності?
Ні. Сама по собі перевірка термінології ловить 10-15% можливих помилок. Вам потрібна мультидимензійна QA: форматування + термінологія + числа + теги + пунктуація. В іншому разі рецензент потім відловлює 50-60% помилок вручну.
BLEU і TER — це те саме?
Ні. BLEU вимірює схожість до еталонного перекладу (0-100, вище краще), TER рахує кількість редагувань потрібних для виправлення (нижче краще). Разом вони дають повнішу картину якості.
Якщо QA-перевірка виявила помилку, чи повинна вона блокувати експорт?
Залежить від серйозності. Критичні помилки (забуті сегменти, невідповідні теги) — так. Попередження (можливо невідповідне слово з глосарію) — ні, показуються як сигнал редактору.
Чи автоматичні QA-перевірки замінюють людський контроль якості?
Ні. Вони замінюють 70% механічних помилок. Для семантичних помилок, термінів, що потребують судження, та якості загалом — людина обов’язкова. QA вільняє людину від пошуку подвійних пробілів.