Три години редагування медичної інструкції на 40 сторінок. МТ перекладає “patient consent form” як “форма згоди пацієнта” на рядку 12, потім “форма надання згоди пацієнтом” на рядку 47, потім “документ про згоду пацієнта” на рядку 89. Один документ. Один термін. Три різні переклади.
Твій словник говорить, що це має бути один конкретний вираз, завжди. Директиви редагування кажуть “дотримуйся словника”. Але базовий вихід МТ уже невирівняний з прийменниками та особливостями мови, тому ти не можеш просто це пропустити — ти мусиш перечитати кожне речення, щоб вловити ці дрібні невідповідності. Робота, яка мала зайняти 3 години, тепер займає 5. І все тому, що машинний переклад не “зрозумів” твій словник.
Це не проблема навички. Не лінивого розробника. Це те, як насправді працює нейронна МТ: вона передбачає терміни слово-за-словом на основі контексту, не пам’ятаючи, що вона обрала п’ять речень тому. Твій словник — це просто текстовий файл. МТ-двигун не вчиться на ньому; він замінює токени на виході, що часто руйнує граматику навколо них. І для багатьох перекладачів це — підставка для незадоволення.
Чому машинний переклад не може дотримуватися твого словника (і чому це стає гіршим)¶
Щоб зрозуміти, чому МТ ламає словники, потрібно розуміти, як насправді працює нейронна машинна трансляція.
Традиційний статистичний МТ-двигун (старі речі, до 2015 року) спочатку шукав у словнику. Якщо він знайшов збіг, він його використав. Без запитань. Просто, передбачуваного, і нудно — але послідовно.
Нейронна МТ змінила все. Замість правил, NMT-моделі працюють так:
- Читають вихідне речення. Модель приймає все — контекст, сусідні слова, пунктуацію.
- Передбачають токени один-за-один. Виходячи з того, що вона читає і що вона вже випустила до цього, вона угадує наступне цільове слово. Потім наступне. Потім наступне.
- Повторюють для кожного речення. Модель не має пам’яті про те, що вона робила три речення тому. Кожне нове речення — це свіже передбачення.
Твій словник невидимий для цього процесу. Двигун був навчений на мільярдах слів, і він вивчив статистику: “коли я бачу [вихідний термін] у [контекст], [цільовий переклад] імовірний.” Переміщення словника відбувається після основного проходу перекладу, так що це як сказати “мені байдуже, що ти навчився — використовуй це замість того.” Двигун не був побудований для органічної інтеграції обмежень словника; він просто замінює токени в кінці.
Ось що насправді відбувається, коли ти додаєш словник до NMT-двигуна:
- Заміна токена: Двигун генерує “consentimiento de paciente.” Словник говорить “використовуй consentimiento del paciente.” Двигун замінює його. Але навколишнє речення було передбачено за припущення оригінального порядку, так що тепер ти отримуєш граматично дивне.
- Сліпота контексту: Словник не має способу сказати “використовуй цей переклад тільки якщо пацієнт — один, жіночого статі, і контекст хірургічний.” Він застосовується сліпо.
- Компроміс якості: Дослідження від Phrase, AppTek та TranslateFX показують, що застосування обмежень словника зменшує загальну якість перекладу на 5-15%, оскільки двигун має працювати навколо примусового терміна замість природної генерації.
Тож словники в комерційних МТ-двигунах (Google Cloud Translation, Azure, Bing) працюють — вони примушують термін. Але вони часто залишають синтаксис навколо них поламаним або невирівняним, змушуючи редакторів виправляти граматику навколо терміна словника, що перекреслює всю мету мати словник.
Реальна вартість непослідовної термінології (Це не просто дратівливо)¶
Так, це дратує бачити один термін, перекладений трьома різними способами. Але вартість глибша.
Час редагування. Непослідовність термінології — це #1 причина, чому редактори повідомляють, що MTPE займає більше часу, ніж очікувалось. Коли вихід непослідовний, твій мозок не може покладатися на закономірності; ти маєш перевіряти кожне входження. Дослідження показують, що редактори витрачають 30-50% часу на виправлення термінів, коли словники не зводяться до слова. Це гроші.
Скарги на якість. Клієнти швидко помічають непослідовність. Вони читають перекладений документ і думають “невже перекладач не знав, що це має бути одне й те саме слово кожного разу?” Незалежно від того, визнають вони це чи ні, вони знижують оцінку за професійність. Для регульованих індустрій (медицина, право, фінанси) непослідовність термінів може створити проблеми з дотриманням — регуляторні органи очікують послідовного використання визначених термінів.
Відповідальність та переробка. У секторах, як-то фармацевтика, контракти або медичні пристрої, непослідовність термінів може зробити документ неприйнятним для подання органам влади. Ви це виявляєте під час огляду, а не під час передачі. Переробка коштує у 2-3 рази дорожче за оригінальне редагування.
Вигорання редакторів. Редактори, які витрачають половину часу на виправлення “повинно-бути-автоматичного”, швидко розчаровуються. Робота відчувається повторною і невтішною. Магазини, які працюють з великим обсягом MTPE, повідомляють про 40% плинність редакторів саме через погане застосування словника.
Втрата конкурентної переваги. Агенції, які поставляють послідовні, словник-забезпечені переклади, перемагають ті, які цього не роблять. Клієнти тепер очікують, що MTPE видасть вихід настільки послідовний, як у людського перекладача, і якщо твій словник не працює, ти поставляєш менше.
Рішення 1: Побудуй словник, який насправді працює¶
Проблема не у словниках — проблема у поганих словниках.
Більшість словників не впираються, тому що вони надто великі, надто загальні або надто жорсткі. Ви бачите словники з 1000 записів, що змішують “the” (визначено пропустити це) з висока спеціалізованими термінами. Ви бачите словники без контексту: “bank” → “banco” (чоловіче? який вид банку?). Ви бачите словники, побудовані однією людиною, яка не редагує, тому вони включають терміни, які не підходять до граматики цільової мови.
Словник, який працює, виглядає інакше:
1. Зосередься безжально. Включай тільки терміни, які: - З’являються у 80%+ вихідних документів, АБО - Мають мандат клієнта або є критичними для бренду, АБО - Є спеціалізованими і не інтуїтивними (наприклад, “data controller” у контексті GDPR — не “data manager”).
Прагни 100-200 термінів для більшості проектів, не 1000. Кожен термін, який ти додаєш, коштує редакторам когнітивного навантаження, коли цей термін з’являється. Менший, тісніший словник шіндше перевіряти.
2. Додай контекст та інформацію про граматику. Для кожного запису: - Вихідний термін та переважний цільовий переклад - Частина мови (іменник, дієслово, прикметник) - Контекст використання (“тільки в документах, звернених до пацієнтів” або “тільки юридичні контракти”) - Заборонені альтернативи (“НЕ використовуй [цей синонім]”) - Морфологічні варіанти, якщо потрібно
Словник з замітками самодокументується. Редактори розуміють, чому термін обов’язковий, а не просто що він є.
3. Уникай перекладів один-до-одного, які не працюють у цільовій мові. Якщо англійський “the” не має еквівалента у цільовій мові, не намагайся його примушувати. Якщо вихідний термін повинен бути переструктурований, щоб звучати природно у цільовій мові, задокументуй цю переструктуризацію у словнику, а не як просту заміну терміна.
4. Зберігай його в терм-базі, а не у таблиці. CAT-інструменти (Trados, memoQ, Smartcat, SDL) мають модулі терм-базів, які зберігають метадані та інтегруються у робочий процес редагування. Коли редактор працює над реченням, яке містить термін словника, термін з’являється як пропозиція або попередження в реальному часі. Таблиці потребують ручного пошуку, який редактори часто пропускають під тиском часу.
5. Версіонуй та підтримуй його. Словники — це живі документи. Якщо редактори знайдуть термін словника, який не підходить, позначте його для огляду. Якщо зворотний зв’язок клієнта змінює, що термін повинен бути, оновлюй його та повідомляй про зміну. Стежите за версіями, щоб знати, яка версія використовувалася для якої партії.
Рішення 2: Обмежуй МТ-двигун (Обережно)¶
Коли у тебе є міцний словник, тобі потрібно розповісти МТ-двигуну його використовувати. Є три головних підходи, з різними компромісами.
Переміщення словника на виході (просто, але ризиковано):
Це те, що Google Translate, Bing Translator та Azure Translation роблять за замовчуванням. Ти приєднуєш словник, двигун працює як звичайно, потім замінює токени на збіги словника на виході.
Плюси: Легко, без перенавчання, працює з будь-яким хмарним МТ-двигуном. Мінуси: Руйнує навколишню граматику, зменшує загальну якість на 5-15%, не враховує контекст чи морфологію.
Використовуй це тільки якщо твій словник дуже малий (30-50 термінів) і складається з власних імен або назв брендів, які не впливають на синтаксис (наприклад, назви компаній, назви продуктів).
Обмеження на основі розмітки (краще, потребує попередньої обробки):
Ти обертаєш терміни словника в розмітку перед відправкою на МТ, наприклад:
<term target="consentimiento del paciente">patient consent form</term>
Деякі МТ-двигуни (AppTek, певні конфігурації Trados) розпізнають цю розмітку та розглядають термін словника як “зафіксований” — двигун не торкатиметься його, а речення передбачується навколо нього. Це краще зберігає синтаксис, ніж сліпа заміна токена.
Плюси: Краще збереження граматики, враховує контекст (ти можеш додавати різні розмітки для різних контекстів). Мінуси: Потребує попередньої обробки вихідного тексту, працює тільки з двигунами, які це підтримують, все одно додає накладні витрати.
Використовуй це для технічних та медичних документів, де послідовність критична, але ти згоден з дещо вищою вартістю обробки.
Навчання для конкретної сфери (найкраще, але дорого):
Якщо у тебе є 10,000+ вирівняних пар речень у твойй спеціалізованій сфері, ти можеш довести open-source NMT-модель (Opus MT, Hugging Face transformers) або найняти сервіс-провайдера (Translated, Lionbridge, AppTek) для створення власного двигуна. Терміни словника вбудовані у ваги моделі — обмеження словника не потрібно.
Плюси: Двигун природно вчиться використовувати твою термінологію, без втрати якості, автоматично обробляє контекст та морфологію. Мінуси: Висока початкова вартість (€5,000-25,000), потребує 3-6 тижнів, жизнездатно тільки для великих, постійних проектів (200k+ слів/рік).
Використовуй це, якщо у тебе є стабільний, великий обсяг спеціалізованого контенту (технічна документація, фармацевтика, право) та ти можеш розподілити вартість на 12+ місяців перекладів.
Рішення 3: Перевіряй дотримання словника з QA-автоматизацією¶
Ось жорстка правда: навіть з чудовим словником та обмеженим МТ-двигуном, редактори іноді пропускатимуть терміни словника, якщо вони під тиском часу або термін словника “відчувається невірно” у контексті. Тут вступає QA-автоматизація.
Перед тим, як редактори навіть відкриють документ, запусти автоматичну QA-перевірку, яка сигналізує: - Терміни в словнику, які не з’являються у виході (пропущені терміни словника) - Терміни у виході, які повинні бути у словнику, але їх немає (порушення послідовності) - Терміни словника, використані граматично дивно (пропонуючи артефакт переміщення словника)
Більшість CAT-інструментів мають це вбудоване (QA Trados, QA-перевірки memoQ, валідація Smartcat). Встановлюй на “жорстку зупинку” — не дозволяй перекладачу перейти до наступного сегмента, поки порушення словника не дозволено.
Дані з QA-перевірок також розповідають вам, які терміни словника викликають проблеми (можливо, термін насправді не підходить до цільової мови, або, можливо, його потрібно уточнити). Використовуй цей зворотний зв’язок для ітерації словника.
Дослідження від Phrase та Translated показують, що QA-валідована типово обов’язує 95%+ помилок в термінології перед тим, як людина навіть їх переглядає, скорочуючи остаточний час QA на 40%.
Рішення 4: Використовуй інтеграцію словника на рівні платформи¶
Для агенцій або команд, що працюють з великим обсягом, ручне управління словником стає вузьким місцем. Сучасні платформи перекладу (Phrase, Smartcat, ChatsControl, Crowdin) тепер пропонують інтегровану обробку словників, яка комбінує всі вищезазначені підходи.
Ці платформи зазвичай пропонують: - Терм-база з робочими процесами затвердження. Терміни можуть бути запропоновані, обговорені, затверджені та версіоновані в межах платформи. - Введення контексту перед МТ. Платформа передає релевантні записи словника до МТ-двигуна разом з контекстом домену/тону, тому двигун має більше інформації наперед. - Інтеграція редактора в реальному часі. Редактори бачать збіги словника та прапори QA вбудовано під час роботи. - Автоматизована попередня валідація. Перед редаганням QA запускається автоматично та виявляє порушення та непослідовності словника. - Звітування про дотримання. Панелі показують, які терміни словника були застосовані, які були перекриті та які викликали проблеми.
Наприклад, ChatsControl включає застосування термінів як частину своєї системи перекладацької інструкції: перед перекладом документа ви вказуєте домен (медичний, юридичний, технічний), тон та словник. AI-перекладач платформи використовує цей контекст, щоб побудувати план (включаючи зіставлення словника), перекладає проти цього плану, потім прохід QA повторно перевіряє дотримання словника та сигналізує непослідовності. Для команд, що працюють з великим обсягом MTPE, це зменшує час редагування на 30-40% на одній роботі з термінів. Платформа також сигналізує терміни, які словник говорить повинні бути використані, але не були, спрощуючи для редакторів виявлення промахів.
Загвоздка: платформи додають залежність (ти більше не перекладаєш локально зі своїми інструментами). Але для команд, що роблять 200k+ слів/місяць, переваги управління словником часто перевішують блокування інструменту.
Чек-лист найкращих практик: Робочий процес застосування словника¶
Ось конкретний робочий процес, який працює:
До перекладу: - [ ] Витягай словник з контексту проекту (документи клієнта, попередні переклади, дослідження сфери) - [ ] Побудуй терм-базу з 100-250 критичними термінами (не 1000) - [ ] Додай контекст, морфологію та замітки щодо використання для кожного терміна - [ ] Мається на увазі щонайменше один двомовний рецензент, щоб затвердити словник перед використанням - [ ] Зберігай словник у системі терм-базів (CAT-інструмент або платформа), не у таблиці
При перекладі: - [ ] Передавай словник + контекст домену до МТ-двигуна (через розмітку, параметр або платформу) - [ ] Обирай метод обмеження на основі розміру та вмісту словника (переміщення для імен/брендів; розмітка для технічних термінів; власне навчання для великих обсягів) - [ ] Логуй, яка версія словника використовувалася для кожної партії (для відстеження)
Перед редаганням: - [ ] Запусти QA-валідацію, сигналізуючи порушення словника - [ ] Переглянь QA-звіт для термінів з високими порушеннями (ці потребують удосконалення словника) - [ ] Спілкуйся з редакторами: “Ці терміни зі словником; ти можеш перекрити тільки з затвердженням лідера та документованою причиною”
Під час редагування: - [ ] Редактори працюють з видимими прапорами QA; терміни словника з’являються як вбудовані пропозиції - [ ] Перекривай терміни словника тільки коли це абсолютно необхідно, з замітками (ці замітки передаються назад до удосконалення словника)
Після редагування: - [ ] Запусти остаточну QA, щоб перевірити дотримання словника у завершеній роботі - [ ] Витягай перекриті або проблемні терміни для огляду словника у наступному проекті - [ ] Задокументуй уроки (“цей термін потребує морфологічних варіантів”, “цей термін повинен бути забороненим синонімом”, тощо)
Часті питання¶
Чому функція словника в Google Translate насправді не працює?
Безкоштовні МТ-двигуни порівнюють словник з вихідним текстом, потім замінюють терміни у виході — але ця заміна часто руйнує граматику навколо них. До того ж, вони не враховують контекст (bank = банк як фінустанова чи берег річки), тому змушують неправильні переклади. Платні інструменти краще фільтрують, але навіть там обмеження словника знижують якість на 5-10%.
Варто користуватися словником з нейронною МТ, якщо вона зменшує якість?
Так, але не самим. Зосереджений словник (100-300 критичних термінів) разом з навчанням на спеціалізованих даних та QA-перевіркою перебільшує як самий словник, так і саме навчання. Ключ — почати редагування з послідовної вихідної версії, а не виправляти терміни з нуля. Навіть 5-10% втрати якості компенсується 40-50% швидшим редаганням виправок термінів.
Яка різниця між словником і терм-базою?
Словник — проста список вихідних → цільових пар. Терм-база (у CAT-інструментах типу Trados, memoQ, Smartcat) зберігає метадані: частину мови, замітки щодо використання, заборонені синоніми, правила контексту та статус затвердження. Терм-бази інтегруються прямо в інтерфейс редагування — редактори бачать пропозиції та попередження в реальному часі.
Як запобігти ‘дрейфу термінології’ у великих проектах?
Дрейф термінології (коли перекладачі поступово відхиляються від словника під тиском часу) трапляється у 80% великих MTPE-проектів. Рішення: (1) передавай словник МТ-двигуну перед кожною партією, (2) запускай автоматичну QA-перевірку, яка сигналізує про порушення словника до редагування, (3) встановлюй жорстке правило, що терміни словника обов’язкові (документуй ‘чому цей термін’ у замітках), (4) вибірково перевіряй 5-10% завершеної роботи на дрейф.
Чи можна ‘навчити’ МТ-двигун дотримуватися мого словника без додавання його щоразу?
Так, через спеціалізоване доведення або навчання. Якщо у тебе є 10,000+ вирівняних пар речень з послідовною термінологією, ти можеш довести open-source-модель (типу Opus MT) або використати сервіс-провайдера (Translated, AppTek, Lionbridge) для створення власного двигуна. Це вбудовує твою термінологію прямо в модель — жодних обмежень словника не потрібно. Однак це коштує €5,000-20,000 на початку, тому це жизнездатно тільки для великих обсягів (100k+ слів/місяць).
Як я можу знати, чи редактори насправді користуються словником?
Включи QA-валідацію в своєму CAT-інструменті (більшість мають це вбудоване), щоб автоматично сигналізувати про порушення словника. Переглядай QA-звіти щотижня; якщо порушення зростають, це означає, що редактори перевантажені або словник незрозумілий. Також відстежуй ‘послідовність термінології’ як окрему метрику — прагни 95%+ дотримання словника на критичних термінах. Деякі платформи (ChatsControl, Smartcat, Phrase) показують live-панелі дотримання.
Що робити, якщо термін словника не підходить до граматики цільової мови?
Це найпоширеніша причина, чому редактори пропускають словник. Рішення: додай морфологічні варіанти та замітки контексту до запису словника. Наприклад, якщо “Data Protection Officer” обов’язковий, але не працює з німецьким визначенням статі, додай замітку: “Використовуй Datenschutzbeauftragte (жін.) або Datenschutzbeauftragter (чол.) залежно від контексту.” Якщо словник створюється спільно перекладачами + клієнтами, ці винятки вирішуються наперед, не під час редагування.