Автоматические QA-проверки, которые нужны каждому MTPE-рабочему процессу

Закончился дедлайн, команда пост-редакторов завершила рабочий день, а потом контроль качества обнаруживает 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 освобождает человека от поиска двойных пробелов.