150 сторінок технічної документації, дедлайн — дві тижні, бюджет обрізаний на 40%. Знайомий сценарій? Власне це те, через що більше половини агенцій за останні 3 роки переходять на MTPE для технічних мануалів, а не чекати, поки клієнт знайде тих, хто дешевше.
Але MTPE для технічної документації — це не просто кидати текст в DeepL і давати редактору скажену хворобу розбиратися з AI-каломом. Це цілісний процес із нетривіальною підготовкою, чіткими чеклистами якості, правильно налаштованими інструментами і запалом не перекомплексувати без причини. Розберемо як це насправді робиться.
Що таке MTPE і чому для технічної документації це працює¶
MTPE (Machine Translation Post-Editing) — це коли ви запускаєте текст через AI-перекладач (MT-engine), а потім людина-редактор його шліфує. Звучить як недовар, але саме в технічній документації це щонайкраще спрацьовує.
Чому? Тому що технічний текст — це скелет. Інструкції, специфікації, API-документація, user manuals написані коротко, без вишурів, з повторювальною структурою. Залізо MT-engine вже це добре чує. Дослідження показують, що для технічного контенту середня продуктивність MTPE — це 15-30% скорочення часу порівняно з чистим ручним перекладом, а собівартість падає на 30-60%.
Для контрасту: крім маркетингового копірайтингу (де MT часто просто кидає брак) MTPE технічної документації дає передбачуваний результат.
Робочий процес MTPE: від вихідного тексту до доставки¶
Не всі розуміють, чому MTPE не почується як “Ось машина, ось редактор, готово”. Чинних кроків шість, кожен важливий:
1. Підготовка вихідного тексту (Pre-editing). Якість вихідного тексту впливає 80% на якість MT-output. Якщо ваш технічний райтер пише “система може можливо переробляти дані”, то MT видасть вам що-небудь страшне. Натомість потрібні чіткі вказівки: номенклатура однакова, коротко-складні речення, однозначна граматика. Це перший тісний заробіток часу — в правильній підготовці джерела.
2. Налаштування MT-engine. Не просто берете перший вільний Google Translate чи DeepL. Для технічної документації вам потрібен engine, натренований хоча б на вашу предметну область. Варіанти: - Готові (hosted): DeepL, Amazon Translate, Google Cloud Translation — гарна якість для пар мов, але без контексту вашої компанії. - Fine-tuned: якщо обсяги >50K слів/місяц, розглядайте API з fine-tuning (Amazon, Google, Azure Translator) на власну TM — виймаються 20-30% якості за 2-3 тижні.
3. Translation Memory (TM) + Glossary. Правильна TM — це половина роботи. Якщо у вас раніше вже перекладали подібне, то TM повинна мати контекст кожного терміна. Glossary (термінологічна база) — це білий список: “Product X завжди Product X, ніколи не перекладається”.
4. MT-generation. Машина робить чернетку. Займає хвилини-часи залежно від обсяг. На цьому етапі вже видно, чи правильно ви налаштували глосарій й TM (добрий знак: 80%+ термінів на місці, речення мають смисл).
5. Post-Editing. Тепер редактор або “light” (швидко чищу помилки), або “full” (переписую для якості). Більш на це нижче.
6. QA-перевірка. Фінал: автоматична перевірка (орфографія, теги, цифри, пунктуація) + кінцеве рецензування експертом. Без цього кроку у вас виходить половинчаста робота.
Часова шкала на типовій 10-тисячнослівній технічній документації: підготовка — 4 год, MT — 0.5 год, light PE — 8-12 год, QA — 2-3 год. Загалом ~15-20 годин. Чистий переклад того ж тексту вручну — 30-40 годин.
Light редагування VS Full редагування: коли що вибирати¶
Два режими MTPE дають різні результати, різну вартість, різні правила.
| Параметр | Light Post-Editing | Full Post-Editing |
|---|---|---|
| Фокус | Correcting grammar, spelling, obvious mistranslations | Publication-ready quality: style, tone, cultural fit |
| Продуктивність | 2-3x faster than human translation (5000-8000 слів/день) | 15-30% faster than human translation (2000-3000 слів/день) |
| Якість | Comprehensible, internal use, documentation | Publishable, customer-facing, professional |
| Edit distance | 15-25% | 30-40% |
| Typoical use | API docs, internal manuals, knowledge bases | Software help files, user manuals, marketing material |
| Cost | 40-50% off human translation | 20-30% off human translation |
| Who does it | Junior translator, editor with MT training | Senior translator with domain expertise |
Light підходить, якщо ви переводите for internal use, speed matters, quality — 7 з 10 достатньо. Приклад: ваша API-документація перекладається з англійської на німецьку, основна задача — щоб dev розуміли, як користуватися. MT дав 85% розуміння, light PE додасть ще 10%.
Full — коли текст вийде в світ, коли помилка дорожче, коли бренд на кону. Інструкції до медичного пристрою, лабораторна техніка, документація для нормативної бази.
За дослідженнями, для більшості технічної документації оптимально — це light PE з повтором QA. Помилки спіймає QA (той самий автоматичний контроль + людина), гроші не витрачаються на перемапування фразеології, дедлайн гарний.
Налаштування QA: чеклист перевірок¶
Автоматична QA-перевірка — це ваш перший щит від брака. Налаштовується в CAT-інструментах (SDL Trados, memoQ, Phrase, Lokalise) раз один, потім працює на всіх проектах.
| QA Check | Що шукаємо | Як налаштувати | Приклад помилки |
|---|---|---|---|
| Terminology | Чи не заблудилася жодна термін глосарія | Додайте glossary в CAT, включіть “Flag not in glossary” | Глосарій каже “API”, редактор написав “Interfase” |
| Formatting | Теги, маркування, числа на місці | Enable tag checking, match numbers between source & target | <b>Bold</b> в оригіналі стало <B>Bold</b> в перекладі |
| Spelling & Grammar | Орфографічні помилки, неправильна структура | Виконуйте спеллчекер на цільовій мові | Подвійні пробіли, “програма програма” замість “програма” |
| Numbers & Quantities | Чи не потрапили чи не змінилися цифри | Create rules for numbers: “check if number in source == number in target” | Source: “32 MB”, Target: “3 MB” (машина обрізала) |
| Consistency | Чи однакові переводиться одно слово | Export TM, scan for “English term translated 5 different ways” | “Database” - раз “база даних”, раз “БД”, раз “база даних” |
| Forbidden Terms | Чи не залишилось жодного англійського слова/скорочення | Create blacklist of terms that must NOT appear | Source is Ukrainian, but target has “OK”, “ASAP”, “TCP/IP” без локалізації |
ISO 18587:2017 — це стандарт MTPE, сформований у Європі. Він каже: мінімум, що ви повинні перевіряти, це орфографія, граматика, консистентність термінів і форматування. Все інше — залежно від вашого рівня амбіцій.
Практична система: налаштуйте в своєму CAT щонайменше 5 правил (terminology, spelling, numbers, forbidden chars, consistency). Запустіть QA, виправте флаґовані елементи. На великих проектах кількість помилок, які ловить автоматичний контроль, падає на 70-80% проти ручного перегляду.
Термінологія й Translation Memory: як не наплутати¶
Технічний текст — це 40% повторень. Одне слово з’являється у 100 місцях. Якщо ви перекладаєте його 100 разів по-різному, то це не MTPE, це лайно.
Translation Memory (TM) — це база попередніх переводів з контекстом. Коли редактор бачить нове речення, CAT показує, як раніше перекладали схоже. Якщо TM якісна, вам економиться 30-40% редагування.
Glossary — це список правил: “Product X завжди X, ніколи не перекладається”. Глосарій перевантажує TM, це чистий список термінів.
Як налаштувати:
-
Отримайте попередню TM. Якщо раніше переводили — експортуйте всі попередні проекти в .tmx (стандартний формат TM). Очистіть брак, вилучіть сміття. На вихіді — золото.
-
Побудуйте glossary на основі документації. Витягніть всі технічні терміни вашого продукту, їх переводи. Приклад для e-commerce платформи: - “Shopping cart” → “Кошик покупок” - “Checkout” → “Оформлення замовлення” (не “Вихідна касса”, не “Касса”) - “Refund” → “Повернення коштів” (не “Відшкодування”)
-
Заблокуйте MT-engine від порушення глосарія. На базових MT-API (DeepL, Google) це не можна. На більш розвинених (Azure, Amazon, custom fine-tuning) — вставляєте glossary в конфіг.
-
Переглядайте & оновлюйте TM щомісяця. Виправки, які робили редактори, — це новий сенс. Кожна «добре зроблена» сегмента повинна повертатися в TM.
Дослідження показують, що з якісною TM (>80% match) для нових проектів час редагування падає на 40-50%. Без TM ви редагуєте наосліп.
Бенчмарки продуктивності: скільки часу на скільки слів¶
Числа, які люди питають весь час:
- Light PE, нова мова, гарний MT: 250-400 слів/годину (один редактор)
- Light PE, з гарною TM (>70% match): 500-800 слів/годину
- Full PE, технічний текст: 150-250 слів/годину
- QA перевірка: 1000-2000 слів/годину (в основному автоматич)
Для проекту 10,000 слів: - Чистий переклад вручную: 8-12 днів (40 годин) - Light MTPE без TM: 5-6 днів (25 годин) = 40% скорочення - Light MTPE з TM: 3-4 дні (15 годин) = 60% скорочення
Це передбачає, що MT-engine якісний (BLEU score >25, edit distance <35%), редактор натренований, інструменти налаштовані.
Зверніть увагу: цифри — для проектів 5K+ слів. На маленьких (500-1000 слів) overhead установки TM, глосарія, CAT-налаштування не окупається.
Інструменти: які CAT-програми купувати, які MT-api¶
CAT інструменти (де працює редактор): - SDL Trados Studio. Індустрія вимагає в 70% агенцій. Дорогий (€1500-3000/рік), але це де-факто стандарт. Чудовий з TM, QA, custom MT integration. - memoQ. Більш демократична ціна (€500-2000/рік), скірше в політезиці, гарно вбудовувати MT. Популярна в Україні й Є. - Phrase (раніше Memsource). Cloud-native, лінгвіст-friendly, вбудова MT-engines всередину. - Lokalise. Для digital teams, легко інтегрується в CI/CD, але менше для типового MTPE.
Вибирайте на основі того, що вже знаюте, або що ваш клієнт вимагає.
MT-engines: - DeepL API. 💰 Низька вартість (~50€/місяць за 500K charaters), 💪 висока якість для ЄС-мов. Не дозволяє glossary інлайн, але можна реалізувати це в CAT. - Amazon Translate. 💰 Дешево за обсяги, 💪 fine-tuning на власну TM. Хорош для великих проектів. - Google Cloud Translation. 💪 Ще краще якість, але дорожче. Glossary support, AutoML для custom models. - Azure Translator. 💪 Glossary інлайн, fine-tuning. Microsoft ecosystem, якщо ви вже в облаці.
Рекомендація: для першого MTPE-проекту почніть з DeepL або Amazon (дешево, порядок якості). Коли обсяги виростуть і окупилися інструменти, розглядайте fine-tuning.
Поширені помилки й як їх уникнути¶
-
Вибір неправильного MT-engine без тестування. Купили Trados, вкинули його в Google Translate та думаєте, що тепер ви гурман. Нівелюйте. Тестуйте 1000-слівний сегмент на трьох-чотирьох engines, порівняйте edit distance. Часом буває різниця в 20%.
-
Ігнорування якості вихідного тексту. MT не можуть розуміти gramatically broken вихідний текст краще, ніж редактор. Якщо райтер пише “система буває містити помилок”, то MT видасть вам щось нісенітниці. Залучіть редактора до підготовки (pre-editing), не до відновлення.
-
Розповсюджування MTPE як універсального. Для поетичного тексту, креативних слоганів, юридичних контрактів MTPE не рішення — там потрібен спеціаліст. Тільки структурований контент (інструкції, API, специфікації).
-
Перекомплексовування процесу. Додали 20 QA-правил, TM на 500K сегментів, fine-tuning, аудит, три рівні ревьюверки. Результат — гарна якість, але це коштує стільки ж, скільки і чистий переклад. Почніть з мінімуму (5 QA-правил, базова TM, light PE), потім розширюйте.
-
Неправильна оплата редакторів. Редактор за MTPE не можна платити як за переклад (за слово). Це або почасово, або “за effort” (вихідно на редаговані часи). Інакше редактор просто пропустить помилки, щоб швидше закінчити.
Як почати: практичний plan на перший місяць¶
Тиждень 1: Planning & Piloting - Виберіть проект 5,000-10,000 слів (технічний, бажано з повторювальними термінами) - Виберіть мову (порівняйте 2-3 MT-engine на перших 500 словах) - Найміть редактора з MTPE-досвідом (або натренуйте свого за 2-3 дні)
Тиждень 2: Setup - Налаштуйте TM у Trados/memoQ - Побудуйте glossary за документацією вашого продукту (50-100 ключ термінів) - Настроїте 5 базових QA-правил (terminology, spelling, numbers, forbidden terms, consistency)
Тиждень 3-4: Execution & Learning - Запустіть MT на пілотному проекті - Редактор робить light PE (2-3 години на 1000 слів) - QA-перевірка, вилучення помилок - Порахуйте: часи, деньги, помилки. Порівняйте з чистим перекладом.
Iterative: збереміст це 30% на часі / 50% на деньги — масштабуйте. Якщо нічого не сохранилось (помилок розпечений, деньги перерукані) — пересмотр MT-engine, TM, або редактора.
FAQ¶
Чи можна MTPE для складної технічної документації?
Для високого ризику (медична, ядерна, авіація) — тільки full PE з експертом. Для посередньої сложности (user manuals, API docs, product specifications) MTPE дає 40-60% зануря часу. Ключ — не тип контенту, а ваш поріг щоб ризику.
Як розраховувати ROI?
Виконайте пілот на 5K-10K слів: порахуйте собівартість MT+редагування, порівняйте з чистим перекладом. Зазвичай окупляється на 3-му проекті. Формула: (Tiempo сохранилось × ставка редактора) - (MT API + CAT license) = ROI.
Скільки часу на навчання редактора?
Базова підготовка — 2-3 дні (ознайомлення з MT-гавнами, QA-інструментами, стайл-гайдом). Повна компетенція — 2-3 проекти на 20-50K слів. Потім він працює оптимально.
Як обрати MT-engine?
Для технічної документації: DeepL (якісна, дешева) або Amazon Translate (масштабується). Тестуйте на репрезентативному зразку (500-1000 слів), порівняйте edit distance (чим нижче, тим краще; <35% — добре).
Яка це вартість повного MTPE-setup?
CAT: €1000-3000/год. MT API: €200-800/месяц. TM+glossary: €500-2000 установка. QA-інструменти часто вбудовані. Переважно окупляється за 1-2 проекти.
Як впевніткися в консистентності термінів?
Налаштуйте QA-правило “terminology check” в CAT проти вашого glossary + TM. Потім експортуйте готовий переклад, сканьте на “як часто кожен англійський термін переводився” — маєте бути найбільше 1 варіант на термін.
Що якщо MT-output дуже погано?
Перевіріть: 1) вихідний текст граматичен? 2) MT-engine натренований на технічний контент? 3) глосарій налаштований? 4) TM якісна? Якщо все це добро й BLEU <20, то MTPE для цього контенту неекономічно — переходьте на чистий переклад.