AI-система оцінювання якості перекладу: QE без еталонів

Чому Quality Estimation ламається без еталонних перекладів

Еталонні метрики якості перекладу тримаються на одному допущенні: у кожного сегмента є еталон. На практиці він є лише для контрольного набору, а основний потік — інтерфейси, документація, маркетингові тексти — іде без нього.

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

Тоді вмикається ручна перевірка, і вона швидко стає вузьким місцем. Лінгвіст розбирає сегмент за сегментом: швидкість передбачувана — хвилини на фрагмент, — а обсяг контенту зростає швидше.

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

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

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

Далі модель навчається на цій розмітці та виставляє бали вже без еталонів — відтворювано і з відомою похибкою. Розбираємо, як це закривається: від схеми розмітки й метрик згоди між оцінювачами до контролю дрейфу оцінок після кожної вибірки донавчання.

Що дає автоматичний контроль якості на потоці

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

На робочих мовних парах це знімає 70–85% обсягу ручної перевірки: час редакторів іде на спірні місця та глосарії, а не на повторне читання стабільних фрагментів.

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

Для кожної пари мов поріг свій: мови з багатою морфологією та короткі інтерфейсні рядки поводяться по-різному.

Єдину шкалу оцінювання дають відкриті метрики сімейства COMET — стандарт у галузі Quality Estimation. Вони навчені на людських оцінках і тому зіставні між мовами, командами та підрядниками.

Замість п'яти різних «добре/погано» у звіті з'являється одне число й формальна межа приймання — сперечатися можна по суті, а не до смаку.

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

Друга — керованість: середній бал за релізом і частка сегментів нижче порогу порівнюються з попереднім прогоном, і просідання на кілька пунктів видно до того, як текст потрапив до користувачів.

Quality Estimation: порівняння підходів без еталонів

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

Сегментний режим ловить локальні викривлення — переплутаний термін, втрачене заперечення, неправильне число, — але не бачить, що абзаци перестали бути зв'язними.

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

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

Порівнювати режими коректно на своїй вибірці: 300–500 сегментів із ручною оцінкою за багатовимірною шкалою в дусі MQM показують, де модель помиляється системно.

У гібриді відбір роблять стратифікованим — ризиковані сегменти повністю йдуть редактору, решта потрапляє у випадкову вибірку 5–10%, і за нею рахують частку пропущених дефектів.

Етапи впровадження: від аудиту даних до передачі системи

Впровадження оцінювання якості перекладу без еталонів — це не встановлення готової моделі, а ланцюжок робіт, де кожен крок спирається на результат попереднього.

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

1. Аудит історичних перекладів. Збираємо корпус із уже прийнятих замовником робіт, розмічаємо за шкалою прямих помилок — смисл, термінологія, оформлення, — виявляємо домени, мовні пари та типи сегментів, прибираємо дублі й обрізані рядки.
2. Проєктування схеми оцінювання. Фіксуємо, що вважаємо критичною помилкою, а що допустимою варіативністю, кодуємо правила в розмітку й ділимо корпус на навчальну, контрольну та відкладену частини.
3. Налаштування моделі. Навчаємо оцінювач на парах «переклад — вердикт редактора», окремо обробляємо рідкісні домени, щоб зміщення за частими темами не переносилося на інші.
4. Налаштування порогів. Підбираємо межі, за яких сегмент іде на ручну перевірку: рахуємо повноту й точність на контрольній частині та балансуємо навантаження редакторів — надто вузький поріг завалює їх роботою, надто широкий пропускає смислові помилки.
5. Перевірка на відкладеній вибірці. Проганяємо систему на сегментах, що не брали участі в навчанні, зі стратифікацією за доменами та мовними парами, звіряємо з оцінками редакторів і розбираємо кожну розбіжність із верхньої частини діапазону.
6. Передача системи. Віддаємо конфігурації, регламент розмітки, схему перенавчання й порядок оновлення корпусу, навчаємо команду замовника запускати оцінювання та читати звіти самостійно.

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

Що передаємо на руки: конфігурації та регламенти

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

Склад нижче — типовий для впровадження оцінювання якості перекладу (Quality Estimation): він закриває і повсякденну роботу, і спірні ситуації, коли автоматичний бал розходиться з думкою редактора.

• Конфігурації оцінювання — профілі під кожну мовну пару й тип контенту: пороги, ваги ознак, список винятків. Змінюються в окремому файлі, без правки коду.
• Схема інтеграції — де система підключається до вашого контуру перекладу: сервісний виклик, пакетна обробка файлів, вивантаження з пам'яті перекладів. З форматами обміну та поведінкою в разі недоступності сервісу.
• Опис правил оцінювання — як формується бал за сегментом, які ознаки на нього впливають, що вимкнено і чому: результат перестає бути «чорною скринькою».
• Регламент розбору спірних випадків — хто і в який термін розглядає розбіжність між автоматичною оцінкою та живим редактором, як рішення повертається в налаштування.
• Набір еталонних сегментів — розмічена вибірка, на якій систему проганяють після кожної зміни порогів: видно, стало точніше чи просто інакше.
• Інструкції з експлуатації — запуск, контроль показників, ознаки деградації та порядок дій, коли якість просіла.
• Журнал рішень і калібрування — зафіксовані домовленості щодо складних сегментів, порядок додавання нової мовної пари та дані, на яких перевіряють результат.

Кейс: контроль якості перекладу на восьми мовних парах

До: вибірковий контроль замість системи

Вісім мовних пар і постійний потік правок від редакторів і зовнішніх перекладачів — а перевірялася лише десята частина сегментів.

Еталона для більшості пар не існувало, тому якість оцінювали вручну: два редактори незалежно виставляли бали, і за одними й тими самими сегментами розбіжність сягала двох пунктів за п'ятибальною шкалою. Спірні випадки йшли на третій круг узгодження, і випуск версії чекав саме на них.

Що налаштували

Побудували оцінювання якості без еталонів (Quality Estimation) на COMET: модель передбачає якість сегмента за парою «джерело — переклад», не вимагаючи заздалегідь підготовленого зразка.

Розміткою стали накопичені правки — те, що редактор змінював, модель навчалася вважати відхиленням, а не варіантом норми.

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

Що стало з метриками

Частка автоматичних рішень зросла з третини до трьох чвертей сегментів, обсяг ручного вичитування скоротився приблизно втричі.

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

Час циклу випуску скоротився з дев'яти днів до чотирьох — вузьким місцем перестала бути черга на узгодження, а спірні сегменти стали видні на вході, а не після вичитування.

Що робити, якщо вже розгорнуто власний контроль якості?

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

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

Гібридна схема виявляється робочою найчастіше: свої правила та накопичена розмітка залишаються джерелом істини, а зовнішнє оцінювання закриває пари й жанри, де своїх прикладів мало. Обидві шкали зводяться до однієї — інакше цифри не зіставити й довіри до них немає.

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

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

Технічні сумніви: де помиляється автоматична оцінка

Оцінювання без еталона (Quality Estimation) передбачає якість перекладу за парою «джерело — результат», не маючи підготовленого зразка.

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

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

Окрема категорія — власні назви, числа та одиниці вимірювання: їхня підміна змінює смисл, але майже не змінює формулювання, і оцінка тут ненадійна.

Що робити з пограничними сегментами?

Сегменти із сірої зони не приймаються автоматично й не відкидаються, а йдуть на ручну перевірку. Частка таких сегментів — керований параметр: нижчий поріг — ширша автоматика, вищий — точніша оцінка.

Чи тримається оцінка при зміні домену або мови?

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

Обговоримо задачу: як будується система оцінювання якості

Перша розмова — технічна, без презентацій: потрібно зрозуміти, де у вашому потоці з'являється текст і хто зараз приймає рішення про його якість вручну. Нічого готувати заздалегідь не потрібно — достатньо описати процес і показати приклади перекладів.

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

Щоб порахувати терміни за вашими даними, а не середні по ринку, потрібен мінімум вхідних даних:

• 2-5 тисяч сегментів «джерело — переклад» у робочому форматі: xliff, tmx або простий tsv з вашої системи перекладів.
• правила якості та розмітка помилок, якщо вона велася: гайдлайни, шкала, приклади спірних випадків.
• один-два оцінювачі, готові розмітити 300-500 сегментів: за їхніми вердиктами ми калібруємо модель і рахуємо розбіжності.
• опис потоку: на якому кроці людина зараз вичитує текст, де приймається рішення і що з ним відбувається далі.
• обмеження щодо контуру: які дані не можна виводити за межі вашої інфраструктури і в якому режимі має працювати оцінювання.

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

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