Как провести сравнительное тестирование MT-движков: пошаговый гайд по bake-off

Ваша команда только что потратила три дня на “оценку” MT-движков. Один PM вставил описание продукта в каждый веб-интерфейс, один лингвист сравнил два сегмента из юридического договора, а кто-то прогнал маркетинговый слоган через всех пятерых кандидатов. Теперь вас спрашивают: какой движок выбрать?

Никто не знает. То, что вы провели, - это не оценка, а сбор впечатлений.

Вот как провести настоящий bake-off: структурированный, воспроизводимый и такой, который можно защитить, когда финансовый отдел спросит, почему вы подписали шестизначный годовой контракт на API.

Почему неформальные сравнения МП не работают¶

В почти каждой неформальной оценке МП есть три типичных сбоя:

Отобранные вручную образцы. Кто-то выбирает предложения, где любимый движок выглядит хорошо, и это впечатление остаётся. Но то, что впечатляет в пяти выбранных сегментах, не распространяется на 50 000 производственных сегментов - и это самая частая ошибка в bake-off агентств.

Тестирование UI против API-деплоя. Движок, который вы тестировали в бесплатном веб-интерфейсе, может вести себя иначе при работе через API: обработка контекста, пакетная обработка, применение глоссария и обработка границ сегментов - всё это отличается между потребительским продуктом и производственным API. То, что вы тестируете в UI, - не то, что вы разворачиваете в продакшн.

Отсутствие базовой линии. Сравнение движка A с движком B показывает, какой из них относительно лучше. Но не показывает, даёт ли хоть один из них реальную экономию времени пост-редактирования по сравнению с переводом с нуля - а именно это и есть экономическое обоснование использования МП.

Структурированный bake-off исправляет все три проблемы: фиксированный корпус, определённые метрики, слепая оценка и сравнение с базовой линией “с нуля”.

Что на самом деле измеряет bake-off¶

Прежде чем выбирать метрики, определите, на какой вопрос вы отвечаете. Три сценария требуют разных дизайнов оценки:

Сценарий A - решение, внедрять ли МП вообще. Главный вопрос: быстрее ли МП + пост-редактирование, чем перевод с нуля на вашем контенте? Проведите пилот сравнения времени: дайте переводчикам пакет 2 000 слов для перевода с нуля и пакет 2 000 слов вывода МП. Измерьте слов/час. Если пакет МП не показывает минимум 30% улучшения throughput, экономика не работает.

Сценарий B - выбор между 2-3 конкретными движками. Это классический bake-off. Вы сравниваете известных кандидатов на одном корпусе, используя автоматические метрики и человеческую оценку пост-редактирования.

Сценарий C - оценка, нужно ли заменить текущий движок. Вы измеряете, превосходит ли новый конкурент или новая версия модели вашу производственную систему на вашем контенте.

Большинство bake-off в агентствах - это Сценарий B. Остальная часть гайда сосредоточена именно на нём.

Шаг 1: Определите критерии оценки до того, как прикоснётесь к любому движку¶

Запишите, как выглядит “победитель”, до того как увидите любые результаты. Это важнейшее процедурное правило в оценке МП - без него оценка бессознательно подтвердит то впечатление, которое кто-то составил при настройке.

Типичные критерии оценки для агентств, с примером весов:

Ваши веса будут отличаться в зависимости от бизнеса. Агентство, работающее преимущественно с языковыми парами ЕС с активным использованием CAT-инструментов, должно давать больший вес интеграции. Агентство с редкими языковыми парами - покрытию. Юридическая или медицинская LSP - безопасности данных.

Запишите эти веса до того, как увидите любые результаты, и зафиксируйте их. Изменение весов после ознакомления с результатами превращает оценку в рационализацию.

Шаг 2: Постройте репрезентативный тестовый корпус¶

Тестовый корпус - самый важный входной параметр bake-off. Ошибка здесь делает все последующие метрики бессмысленными.

Размер корпуса¶

Практический минимум - 2 000 сегментов для одной языковой пары и домена. Для результатов, которые можно уверенно защитить:

• Одна языковая пара, однородный домен: минимум 2 000 сегментов
• Несколько доменов (например, технический + маркетинговый): 500-1 000 на домен, минимум 2 500 итого
• Несколько языковых пар: минимум 1 000 сегментов на языковую пару

При менее 2 000 сегментов различия качества между движками могут быть статистически незначимыми - одна “тяжёлая” или “лёгкая” партия может перекосить результаты в любую сторону.

Состав корпуса¶

Ваш тестовый корпус должен отражать то, что ваше агентство реально переводит, в тех пропорциях, в которых вы это делаете. Если 60% вашего объёма - строки интерфейса ПО, 30% - техническая документация, а 10% - маркетинговый контент, ваш корпус должен соответствовать этому распределению.

Не используйте вашу TM как тестовый набор без предварительной проверки. Некоторые движки частично запомнили контент из публичных параллельных корпусов, и сегменты из TM могут показать завышенные оценки. Используйте недавно переведённый контент, которого нет ни в одной публичной TM.

Намеренно включайте граничные случаи: - Предложения с числами, датами и единицами измерения - ошибки МП здесь часто самые дорогостоящие - Именованные сущности (названия продуктов, компаний, имена людей) - поведение движков с ними существенно различается между поставщиками - Длинные предложения (40+ слов) - качество МП снижается на длинных сегментах в некоторых движках - Отраслевая терминология - сегменты, где ваш глоссарий наиболее важен

Эталонные переводы¶

Вам нужны человеческие эталонные переводы для каждого сегмента в корпусе - это золотой стандарт для всех автоматических метрик (BLEU, COMET, TER). Используйте существующие переводы из вашей TM, в качестве которых вы уверены, или закажите новые специально для bake-off.

Частая ошибка: использование TM-переводов как эталонов без их предварительной проверки. Если ваши эталоны содержат ошибки, каждая автоматическая метрика измеряет отклонение от неправильной цели. Проверьте выборочно 5-10% эталонных переводов до запуска метрик.

Шаг 3: Получите тестовый доступ и запустите все движки на одном корпусе¶

Настройте API-доступ для каждого кандидата. Большинство основных движков предлагают бесплатные триальные уровни:

Запускайте все движки на тех же сегментах в том же порядке, как можно ближе по времени. Это контролирует обновления моделей - ведущие движки обновляют веса 2-4 раза в год, и обновление во время bake-off аннулирует сравнение.

Анонимизируйте выходные данные перед экспертной оценкой. Помечайте файлы как “Движок 1”, “Движок 2”, “Движок 3” - не DeepL, Google, Azure. Присваивайте метки движкам только после завершения всех экспертных оценок. Этот шаг обязателен. Оценщики, знающие, какой движок что выдал, будут бессознательно оценивать результаты по-разному исходя из брендовых ожиданий.

Шаг 4: Автоматические метрики - что они говорят и чего не говорят¶

Запускайте минимум две автоматические метрики. Не полагайтесь только на одну.

BLEU (Bilingual Evaluation Understudy)¶

BLEU измеряет, сколько словосочетаний (n-граммы длиной 1-4) в выводе МП совпадают с эталонным переводом. Диапазон оценок 0-100; выше - лучше.

Типичные оценки BLEU для современного нейронного МП: - Основные пары языков ЕС (EN↔DE, EN↔FR, EN↔ES): 30-45 - Менее распространённые европейские пары: 20-35 - Далёкие языковые пары (EN↔ZH, EN↔JA): 15-30 - Малоресурсные языки: часто ниже 15

BLEU полезен для обнаружения очевидных разрывов качества между движками и отслеживания регрессий со временем. Чего он не улавливает: не штрафует синтаксически правильный, но семантически неверный вывод, и не вознаграждает правильный вывод, использующий иную лексику, чем эталон. Как показывают результаты WMT 2023, BLEU плохо коррелирует с мнением человека в чувствительных к стилю доменах, таких как маркетинг и художественный перевод.

COMET (Crosslingual Optimized Metric for Evaluation of Translation)¶

COMET - нейронная метрика, обученная на данных человеческой оценки, специально разработанная для корреляции с мнением человека там, где BLEU даёт сбой. Она принимает исходное предложение, вывод МП и эталон как входные данные и выдаёт оценку, как правило, между 0,6 и 1,0. Выше - лучше.

Рекомендуемая референсная модель wmt22-comet-da (доступна на Hugging Face) является текущим стандартом. Для производственных bake-off COMET - более надёжная автоматическая метрика: она улавливает несоответствия регистра и семантические сдвиги, которые BLEU полностью пропускает.

TER (Translation Edit Rate)¶

TER измеряет, сколько правок (вставки, удаления, замены, перестановки) нужно внести в вывод МП, чтобы привести его к эталону. Ниже - лучше; 0 означает идентичность эталону. Типичные значения TER для МП: 0,35-0,65 для основных языковых пар.

TER особенно полезен в контекстах MTPE, поскольку он служит прокси для усилий пост-редактирования. Движок с TER 0,35 теоретически требует меньше правок на сегмент, чем движок с TER 0,55. На практике TER - грубое приближение: реальные усилия PE также зависят от распределения ошибок, типа сегмента и индивидуальной скорости переводчика.

Чего автоматические метрики не могут сказать¶

Ни BLEU, ни TER, ни COMET не скажут вам: - Пригодны ли выходные данные МП для публикации без правок или требуют существенной переработки - Важнее ли конкретный тип ошибки в вашем контексте (неверная дата в юридическом документе критичнее, чем неловкое прилагательное в описании продукта) - Сколько времени реально потратит редактор, что зависит от его знакомства с доменом и привычной рабочей скорости

Именно поэтому автоматические метрики - первый фильтр, а не окончательный ответ.

Шаг 5: Экспертная оценка пост-редактирования - метрика, определяющая ваш ROI¶

Два метода экспертной оценки надёжно работают в условиях агентства.

Метод A: Слепая прямая оценка¶

Оценщики видят каждый сегмент вывода МП и оценивают его по шкале 0-100. Два измерения: адекватность (правильный и полный ли смысл?) и беглость (читается ли естественно на целевом языке?). Эталонный перевод не показывается - оценщики судят о выводе МП самостоятельно.

Оценки выше 80 обычно свидетельствуют о выводе, пригодном для лёгкого пост-редактирования. Оценки ниже 60 часто указывают на сегменты, которые быстрее переделать с нуля, чем исправлять.

Привлекайте минимум двух оценщиков на движок и рассчитывайте межоценщиковое согласие (IAA). Если IAA падает ниже 0,7 (каппа Коэна), ваш протокол оценки требует доработки.

Метод B: Хронометрированное пост-редактирование (метрика, прогнозирующая вашу экономику)¶

Дайте редакторам партию 2 000 слов вывода МП - не раскрывая, какой движок что выдал, - и засеките время выполнения задачи. Фиксируйте: - Отредактированные слова в час для каждого движка - Редакционное расстояние на сегмент (автоматически, через расстояние Левенштейна, сравнивая вывод МП с готовым пост-отредактированным переводом)

Это единственная метрика, которая напрямую переводится в бизнес-ценность. Если движок A обеспечивает 8 500 слов PE в час, а движок B - 6 200 слов PE в час, движок A экономит примерно 27% затрат на пост-редактирование - независимо от того, как каждый движок оценён по BLEU или COMET.

Как показывают исследования Nimdzi о разрыве эффективности MTPE, разброс throughput пост-редактирования между лучшим и худшим движками обычно составляет 20-40% - значительно больше, чем большинство ожидает до подсчёта цифр.

MQM для структурированного анализа ошибок¶

Когда нужно знать не просто какой движок хуже, а где каждый движок систематически даёт сбой, используйте MQM (Multidimensional Quality Metrics). MQM классифицирует ошибки по типам:

• Точность - неправильный перевод, пропуск, добавление, непереведённое содержимое
• Беглость - грамматика, пунктуация, правописание, регистр
• Стиль - неловкие формулировки, непоследовательность терминологии
• Локальные конвенции - формат даты, числа, валюты, адреса

Каждой ошибке присваивается серьёзность: незначительная (1 балл), значительная (5 баллов), критическая (25 баллов). Финальная оценка MQM = общее взвешенное количество ошибок на 1 000 слов. Ниже - лучше.

MQM - стандартный фреймворк оценки у крупных корпоративных заказчиков МП. Для стандартного bake-off LSP не обязательно использовать полный фреймворк MQM, но таксономия ошибок полезна для понимания, где каждый движок даёт сбой - и важны ли эти сбои для вашего конкретного типа контента.

Шаг 6: Тестируйте интеграцию в вашем реальном TMS и CAT-инструменте¶

Движок, который хорошо справляется изолированно, но создаёт трудности интеграции в вашем рабочем процессе, не является производственно-пригодным выбором.

Что проверять¶

• Нативный плагин vs API-коннектор: есть ли у движка официальный плагин для вашего CAT-инструмента (memoQ, Trados, Phrase, Smartcat)? Нативные плагины лучше обрабатывают контекст сегментов и поддерживаются вендором. API-коннекторы через промежуточное ПО работают, но добавляют зависимость, которая может сломаться при обновлениях CAT-инструмента.
• Применение глоссария: загрузите терминологическую базу клиента с 20-30 терминами и проверьте, правильно ли они отображаются в выводе МП. Тестируйте как стандартные, так и граничные термины.
• Обработка контекста: получает ли движок окружающие предложения как контекст, или переводит каждый сегмент изолированно? Контекстно-зависимый перевод (окно предложений) улучшает согласованность в связном тексте, особенно для строк интерфейса и структурированных документов.
• Пропускная способность пакетной обработки: сколько символов в секунду обрабатывает API для вашего типичного размера пакета? Для процессов ночной обработки время выполнения задания 2 часа против 20 минут имеет реальное операционное значение.

Минимальный интеграционный тест¶

Настройте макет проекта: реальный клиентский файл (или отражающий ваш типичный формат), предварительно переведённый каждым движком, импортированный в ваш TMS, назначенный редактору и завершённый. Засеките время полного цикла. Это выявляет проблемы, которые никогда не обнаружишь при оценке на уровне сегментов: проблемы форматирования файлов, обработки тегов, ошибки границ сегментов и конфликты совпадений TM с выводом МП.

Шаг 7: Рассчитайте совокупную стоимость владения¶

Цена API - самое заметное число, но редко самая большая составляющая TCO для агентств, занимающихся MTPE в больших объёмах.

Формула TCO¶

Годовой TCO = (Месячный объём символов × цена API/символ × 12)
            + (Годовые слова PE ÷ слов PE/час × почасовая ставка PE)
            + (Стоимость настройки интеграции ÷ 3)     [амортизированная за 3 года]
            + (Ежегодное обслуживание: обновления плагинов, синхронизация глоссария, управление TM)

Пример с реальными числами¶

Агентство, обрабатывающее 5 миллионов символов в месяц, EN→DE, с пост-редактированием со скоростью 7 500 слов/час при стоимости 35 €/час. Приблизительное соотношение символ/слово: 1 слово ≈ 5,5 символа.

(Стоимость PE = годовые слова PE ÷ throughput × почасовая ставка. При 5 млн символов/мес: годовые символы = 60 млн, при 5,5 символа/слово = ~10,9 млн слов/год)

В таких масштабах разница в throughput PE в 700 слов/час означает 5 000-7 000 € в год на затраты труда - больше, чем разброс в стоимости API. Именно поэтому пилот throughput PE из шага 5 - самое важное число в вашей модели TCO.

Таймлайн bake-off и роли¶

Минимальный bake-off для двух движков занимает 3-4 недели:

Кто что делает: - Инженер по локализации / руководитель проекта: подготовка корпуса, настройка API, анонимизация, подсчёт метрик - 2-3 старших редактора: слепая прямая оценка и хронометрированный пилот PE - Финансы или операции: модель TCO и проверка контракта API

Человек, настраивавший API, не должен проводить экспертную оценку - он уже видел, какой движок есть какой.

Распространённые сокращения, аннулирующие bake-off¶

• Показ оценщикам названий движков до завершения оценки
• Использование тестового корпуса из опубликованных бенчмарков поставщика (отобранных для демонстрации благоприятных результатов)
• Использование TM-сегментов, которые движок мог видеть при обучении
• Пропуск хронометрированного пилота PE из-за того, что он “занимает слишком много времени” - это устраняет единственное прямо бизнес-значимое измерение

Шаблон оценки и принятия решения¶

Заполните этот шаблон после завершения всех оценок, до обсуждения результатов с командой:

Скоркард bake-off MT-движков
Языковая пара: _______________   Домен: _______________   Дата: ___________

                                    Вес     Движок A   Движок B   Движок C
Оценка COMET                        25%       ___        ___        ___
Штрафная оценка MQM                 10%       ___        ___        ___
Throughput PE (слов/час)            30%       ___        ___        ___
Соответствие интеграции CAT         15%       ___        ___        ___
TCO год 1                           10%       ___        ___        ___
Покрытие языков                      5%       ___        ___        ___
Соответствие безопасности данных     5%       ___        ___        ___
                                    ---
Взвешенная итоговая оценка         100%       ___        ___        ___

Представляйте взвешенные итоги до обсуждения отдельных оценок. Это предотвращает ситуацию, когда мнение самого высокооплачиваемого человека в комнате определяет решение ещё до того, как данные оказались на столе.

FAQ¶

В чём разница между bake-off и пилотом?¶

Bake-off - это структурированная оценка для выбора движка. Пилот - это реальный производственный запуск (как правило, 15 000-25 000 слов) с движком-победителем, используемый для проверки бизнес-показателей до полного внедрения. Они последовательны: сначала bake-off, затем пилот.

Стоит ли включать LLM-перевод (GPT-4, Claude) в bake-off?¶

Стоит тестировать для вашего типа контента. LLM-перевод хорошо справляется с контекстом и нюансами и конкурентоспособен со специализированными MT-движками для короткоформатного, маркетингового и контекстно-зависимого контента. Практические ограничения для рабочих процессов агентств: непредсказуемая задержка, более высокая стоимость символа, отсутствие нативных CAT-плагинов и поддержки обработки файлов в формате CAT без кастомной интеграции. Если ваш рабочий процесс ориентирован на CAT, LLM-перевод сейчас требует значительных разработческих усилий для интеграции.

Как оценить редкие языковые пары, где у нас нет штатных лингвистов?¶

Два варианта: (а) привлеките фрилансера-лингвиста для конкретной языковой пары специально для оценки bake-off - единственный полностью надёжный вариант; (б) используйте COMET-QE (режим оценки качества, без эталона) как прокси, но проверяйте хотя бы небольшой человеческой выборкой. Не полагайтесь исключительно на автоматические метрики для языков, которые вы не можете проверить.

Оправдан ли bake-off для агентств с небольшим объёмом?¶

Это оправдано, как только ваш МП-объём превышает примерно 1 миллион символов в месяц. Ниже этой отметки годовые различия в стоимости API измеряются сотнями долларов и не оправдывают 4 недели оценки. Используйте бесплатные триалы поставщиков для тестирования на вашем контенте, обращайтесь к независимым бенчмаркам, таким как ежегодные результаты WMT, и начинайте с того движка, который наиболее опытным лингвистам проще пост-редактировать.

Как часто нужно повторно проводить bake-off после выбора движка?¶

Основные движки обновляют свои модели 2-4 раза в год. Запускайте быструю проверку автоматических метрик на фиксированном отложенном наборе ежеквартально. Проводите полноценный bake-off, когда: конкурентный движок выпускает крупную версию, претендующую на превосходство над вашим текущим выбором; ваш языковой состав существенно меняется; или вы приближаетесь к продлению годового контракта на API.