Вы загружаете 40 000 слов в МП-движок в понедельник. В среду редактор пишет: “Качество этого батча хуже обычного - трачу вдвое больше времени на сегмент”. А вы уже зафиксировали сроки и ставку для MTPE в договоре с клиентом.
Вот что происходит, когда качество МП не измеряется до начала проекта. Уметь оценить качество перед тем, как взять обязательства, и иметь систему, которая ловит деградацию когда она начинается, - это то, что отличает агентства, которые зарабатывают на MTPE, от тех, что поглощают убытки.
Почему измерение качества МП - это бизнес-решение, а не академическое упражнение¶
Оценка качества перевода существует в двух мирах. Исследователи отслеживают корреляции метрик до сотых долей процента. Агентствам в продакшне нужны ответы на три конкретных вопроса:
- Достаточно ли хорош этот МП-аутпут, чтобы запустить MTPE по той ставке, которую я обозначил?
- Какой движок лучше для этого типа контента и языковой пары?
- Деградировало ли качество в середине проекта - и насколько?
Автоматические метрики вроде BLEU получают много критики в научных кругах - и значительная её часть справедлива. Но для агентств их ценность не в идеальной корреляции с человеческими суждениями. Она в том, что они быстрые, бесплатные и достаточно последовательные, чтобы ловить крупные падения качества до того, как они станут дорогой проблемой.
Автоматические метрики: что они измеряют и когда использовать¶
Автоматические метрики сравнивают МП-аутпут с эталонным переводом - обычно человеческой пост-редакцией - и выдают балл. Никаких человеческих рецензентов, результат за секунды. Компромисс: все автоматические метрики измеряют поверхностное совпадение с эталоном, а не реальное качество перевода.
BLEU - отраслевой стандарт, который нужно понимать¶
BLEU (Bilingual Evaluation Understudy) опубликовали Papineni et al. из IBM Research в 2002 году - и с тех пор это дефолтная метрика оценки МП. Она измеряет, сколько n-грамм (последовательностей слов) из МП-аутпута также встречаются в эталонном переводе. Балл от 0 до 100, выше - больше совпадений с эталоном.
Почему агентства до сих пор используют BLEU: - Быстрый и бесплатный (sacrebleu - стандартная реализация с открытым кодом) - Воспроизводимый - при одинаковых данных два исполнителя получат одинаковый балл - Сравниваемый между движками при одинаковом тестовом наборе и токенизации
Почему на BLEU нельзя полагаться как на единственную метрику: - Измеряет совпадение слов, а не смысл. Предложение, правильно передающее значение, но другими словами, получит меньший балл, чем предложение, совпадающее с эталоном, но тонко ошибочное. - Чувствителен к стилю эталона - если эталон отражает выбор одного переводчика, МП с равноценными, но другими формулировками получит низкий балл. - Плохо коррелирует с человеческой оценкой - особенно для творческого контента, языков со свободным порядком слов, малоресурсных языковых пар.
Ориентировочные диапазоны для технического контента в крупных языковых парах:
| Диапазон BLEU | Что означает | Ожидаемый уровень пост-редактирования |
|---|---|---|
| < 25 | Плохое качество, значительная доработка | FPE или перевести заново |
| 25-40 | Среднее качество | FPE необходим |
| 40-50 | Хорошее качество | LPE скорее всего достаточно |
| > 50 | Высокое качество (доменный контент) | LPE или лёгкая проверка |
Эти диапазоны существенно меняются в зависимости от языковой пары и домена. EN-FR технический контент при BLEU 40 - совершенно другая ситуация, чем EN-AR юридический при BLEU 40.
TER - непосредственно полезен для оценки усилий редактирования¶
Translation Edit Rate (TER) измеряет, сколько правок - вставок, удалений, замен и перестановок - нужно, чтобы превратить МП-аутпут в эталон, делённое на длину эталона. TER 0,3 означает, что примерно 30% слов требуют редактирования. Ниже - лучше.
TER естественно вписывается в MTPE-воркфлоу, потому что напрямую моделирует усилия редактирования. Агентства, отслеживающие TER по проектам, могут накапливать эмпирические данные о том, какой порог предсказывает приемлемую скорость пост-редактирования для их конкретных редакторов и типов контента.
Практические пороговые значения на основе отраслевых бенчмарков:
| Диапазон TER | Что означает | Действие |
|---|---|---|
| < 0,3 | Высокое качество МП | LPE подходит, ставьте соответствующую цену |
| 0,3-0,5 | Среднее качество | FPE необходим, заложите время редактора |
| > 0,5 | Плохое качество | Усилия редактирования приближаются к полному переводу - пересмотрите цену или перенаправьте |
Оговорка: TER не учитывает сложность отдельных правок. Исправление терминологической ошибки, которое заняло 10 минут на исследование, считается так же, как добавить пропущенный предлог. Поэтому человеческие данные пилота всегда точнее TER.
chrF - лучше для языков с богатой морфологией¶
Character n-gram F-score (chrF) работает на уровне символов, а не слов - это делает её чувствительнее к морфологическим вариациям. Для языков, где окончания слов существенно меняются в зависимости от грамматического контекста - для русского, украинского, финского, венгерского, польского - chrF часто лучше коррелирует с качеством, чем BLEU.
Если ваше агентство активно работает с восточноевропейскими или агглютинативными языковыми парами, chrF ничего не стоит дополнительно (она в sacrebleu рядом с BLEU) и даёт надёжнее сигнал для этих пар.
COMET - лучшая автоматическая метрика прямо сейчас¶
COMET (Crosslingual Optimized Metric for Evaluation of Translation), разработанный Unbabel, использует нейронную сеть, обученную на человеческих оценках качества из кампаний WMT. Это лучшая автоматическая метрика в WMT Metrics Shared Tasks стабильно с 2020 года.
Практическое отличие от BLEU: COMET лучше улавливает, семантически ли правилен перевод, а не только использует ли он те же слова, что и эталон. Два перевода, передающие один смысл, но формулирующие его по-разному, получат очень разные баллы BLEU, но схожие баллы COMET.
Когда использовать COMET: - Выбор движка - сравнение DeepL, Google Translate, Microsoft Translator или собственного движка для вашего типа контента - Регрессионное тестирование - обнаружение падения качества после обновления движка - Бенчмаркинг языковых пар - понимание, для каких пар МП надёжно выдаёт качественный результат
Сводка метрик:
| Метрика | Нужен эталон? | Лучше всего для | Основное ограничение |
|---|---|---|---|
| BLEU | Да | Быстрый сигнал, сравнение движков | Плохая корреляция со смыслом |
| TER | Да | Оценка усилий редактирования | Не учитывает сложность правок |
| chrF | Да | Морфологически богатые языки | Поверхностная метрика |
| COMET | Да (DA-версия) | Лучший автоматический сигнал | Требует настройки Python |
MQM: профессиональный стандарт для человеческой оценки качества¶
Автоматические метрики показывают, насколько МП-аутпут похож на эталон. MQM (Multidimensional Quality Metrics) показывает, что именно в нём не так.
MQM - это таксономия ошибок: структурированный способ для человеческих рецензентов категоризировать и оценивать ошибки перевода. Используется командой качества Google Translate, Microsoft и государственными переводческими службами. Категории ошибок дают вам действенные данные, а не просто балл.
Основные категории ошибок MQM:
Ошибки точности (передаёт ли перевод то, что сказано в источнике?): - Неправильный перевод: передан неправильный смысл - Неполный перевод: контент источника пропущен - Избыточный перевод: добавлен контент, которого нет в источнике - Не переведено: текст источника оставлен без перевода
Ошибки беглости (читается ли перевод естественно?): - Грамматика: неправильная морфология, синтаксис, согласование - Типографика: знаки препинания, регистр, пробелы - Регистр: неправильный уровень формальности для контекста
Терминологические ошибки: - Неправильный технический термин (против утверждённого глоссария) - Непоследовательное использование термина в документе
Стилистические ошибки: - Не соответствует голосу бренда или стайлгайду - Неловкая формулировка, технически правильная, но так не пишут носители
Каждая ошибка получает степень критичности: критическая (наносит вред или создаёт правовые проблемы), значительная (существенно влияет на качество), незначительная (мелкая, не влияет на понимание). Балл MQM рассчитывается из количества ошибок, взвешенных по критичности, относительно порогов, которые вы сами устанавливаете для каждого типа контента.
Когда агентствам нужен MQM: - Контракты с клиентами, предусматривающие формальные метрики качества - Процессы соответствия ISO 17100 или 18587 - Формальный выбор между конкурентными движками - Точечные проверки текущего MTPE-аутпута относительно базовой линии
Когда полный MQM не нужен: - Внутренний контент без формальных требований к QA - Высокообъёмный MTPE низкого риска, где прокси качества является расстояние редактирования
Даже если вы не проводите формальные MQM-аудиты, категории ошибок полезны как чеклист для человеческих рецензентов. Обучить рецензентов классифицировать найденные ошибки - точность vs беглость vs терминология - значит генерировать данные, которые помогут выявить системные слабости МП в конкретных доменах или языковых парах.
Quality Estimation: оценка качества без эталонного перевода¶
Метрики с эталоном (BLEU, TER, COMET-DA) требуют человеческой пост-редакции для сравнения. Проблема: данные о качестве нужны до пост-редактирования, чтобы решить, как его проводить.
Quality Estimation (QE) решает это, прогнозируя качество перевода напрямую из источника и МП-аутпута, без какого-либо эталона. Это практический инструмент для маршрутизации в продакшне.
Модели QE обучаются на человеческих оценках и учатся прогнозировать баллы качества для пар источник-МП. Они могут помечать отдельные сегменты, которые потребуют серьёзного редактирования - до того как редактор до них дойдёт, что позволяет автоматически маршрутизировать потоки в больших объёмах.
Инструменты QE, доступные в 2026 году:
COMET-Kiwi (открытый код, от Unbabel): текущая топовая QE-модель в WMT. Прогнозирует баллы качества на уровне сегмента без эталона. Требует Python, запускается локально.
ModelFront: коммерческий QE-инструмент для агентств и LSP, специально для автоматической маршрутизации воркфлоу. Интегрируется с основными TMS-платформами.
DeepL Quality Check: собственная система баллов уверенности DeepL, доступная через API рядом с переводами.
Phrase (бывший Memsource): встроенный QE от нескольких провайдеров, доступен без отдельной настройки.
Практические сценарии использования QE:
Автоматическая маршрутизация: сегменты выше порога уверенности идут на LPE, ниже - помечаются для FPE или полного человеческого перевода. В больших объёмах это может снизить усилия пост-редактирования на 20-30%.
Оценка риска перед проектом: запустите исходный файл через QE до того, как взять обязательства. Если средние баллы QE низкие - этот проект потребует тяжёлого пост-редактирования, и ваша цена должна это отражать.
Сравнение движков без эталонного набора: сравните баллы QE двух движков на одном источнике. Менее надёжно, чем метрики с эталоном, но полезно, когда нет золотого стандарта для нового типа контента.
Пилотное тестирование: единственная проверка, которая реально работает¶
Автоматические метрики дают сигналы. QE даёт прогнозы. Ни то ни другое не заменит то, что вы получите от человеческого пилота на реальном контенте.
Перед тем как взять значительный проект на MTPE - особенно для новой языковой пары, нового типа контента или нового МП-движка - проведите человеческий пилот. Он занимает несколько часов. Он может предотвратить недели убытков.
Протокол пилота:
Шаг 1 - Выберите выборку. 3 000-5 000 слов, репрезентативных для реального проекта. Не выбирайте только лёгкие сегменты. Если в проекте есть таблицы, юридические пункты и технические спецификации - включите все три в выборку.
Шаг 2 - Сгенерируйте МП. Используйте именно тот движок и те настройки, что и для всего проекта. Не тестируйте на другой версии движка или с другой предобработкой.
Шаг 3 - Пост-редактирование с отслеживанием. Попросите надёжного лингвиста отредактировать выборку, фиксируя: время на сегмент (большинство CAT-инструментов логируют автоматически), расстояние редактирования (насколько изменили относительно МП-аутпута), сегменты, которые пришлось переписать полностью.
Шаг 4 - Расчёт и интерпретация. Из данных пилота: - Слов/час: если ниже 500 - проект приближается к усилиям полного перевода, ваша MTPE-цена скорее всего не сработает - Средний TER: надёжная оценка усилий для всего проекта - Процент полностью переписанных сегментов: выше 20% - МП-движок не справляется с этим типом контента
Шаг 5 - Решение. Если данные пилота подтверждают пригодность MTPE - ставьте цену соответственно. Если нет - или переставьте цену на уровень FPE, или порекомендуйте клиенту человеческий перевод, или обозначьте это до того, как взять обязательства.
Как показывает анализ продуктивности SwissGlobal 2026, производительность МП существенно отличается между языковыми парами: для EN-FR они зафиксировали прирост скорости +130% при MTPE, а для EN-SE - минус 7% (медленнее человеческого перевода). Этот разрыв обнаруживается только через пилотное тестирование для каждой пары отдельно.
Практическое замечание: когда в 2025 году опросили переводчиков о качестве МП-аутпута, 66% фрилансеров назвали МП “приемлемым, но требующим значительного редактирования” - и только 12,74% оценили его как высококачественный. Это ваша базовая ожидаемая производительность для крупных языковых пар с нынешними нейронными МП-системами.
Отслеживание качества во времени: базовые линии и обнаружение деградации¶
Единоразовая проверка перед проектом недостаточна. МП-движки обновляются без предупреждения. Типы контента меняются. Редакторы меняются. Качество может медленно деградировать месяцами, пока кто-то не пришлёт жалобу от клиента.
Сформируйте базовую линию качества и регулярно сравнивайте с ней.
Что отслеживать: - Баллы BLEU или COMET на фиксированном тестовом наборе (те же сегменты всегда - никогда не меняйте тестовый набор) - TER по проектам для одной языковой пары и типа контента - Скорость пост-редактирования (слов/час) для каждого лингвиста по типу контента - в логах TMS - Плотность ошибок при человеческих проверках (ошибок на 1 000 слов по категориям MQM)
Когда запускать проверку: - После любого обновления или смены МП-движка - Когда редактор сообщает, что качество изменилось - Когда время пост-редактирования на проект стабильно растёт - Ежеквартальная точечная проверка для наибольших по объёму языковых пар
Фиксированный тестовый набор из 1 000-2 000 сегментов, один раз отредактированный надёжным лингвистом и навсегда замороженный, даёт воспроизводимый бенчмарк. Запуск COMET на свежем МП-аутпуте относительно этого эталона занимает минуты и сразу показывает, изменилось ли качество.
Именно эту проблему фиксирует отчёт Nimdzi MTPE Efficiency Gap: агентства, маршрутизирующие контент на MTPE без отслеживания качества, часто платят за пост-редактирование, приближающееся к усилиям полного перевода, при ценах MTPE.
Метрики качества МП vs качество перевода - это разные вещи¶
Важное различие, которое часто путают: метрики качества МП оценивают, насколько хорош сырой МП-аутпут. Оценка качества перевода (по ISO 18587:2017 и ISO 17100) оценивает финальный пост-редактированный результат.
Для клиентских контрактов и гарантий качества важно качество финального аутпута, а не сырого МП. Плохой МП может дать отличный финальный результат после работы опытного редактора. Хороший МП может остаться с ошибками после невнимательного редактора.
Это значит: метрики качества МП должны управлять вашими внутренними решениями - маршрутизацией, ценообразованием, выбором движка. Человеческая проверка пост-редактированного аутпута управляет клиентскими гарантиями качества.
Исключение: если клиент требует подтверждения, что AI-инструменты не использовались, или что перевод является “авторским человеческим переводом” - это юридически-договорные требования, которые метрики качества МП не могут удовлетворить независимо от баллов.
Где в этом всём AI-платформы для документов¶
Для агентств, обрабатывающих большие объёмы документального перевода - технические мануалы, каталоги продуктов, стандартные договоры - слой работы с файлами (извлечение текста, сохранение форматирования, сборка переведённого файла) часто создаёт столько же трений, как и лингвистическое качество.
Платформы типа ChatsControl берут на себя загрузку документов и генерацию отформатированного черновика (DOCX, PDF с сохранением макета), после чего результат идёт к редактору. Оценка качества МП всё равно применяется для определения маршрутизации - платформа берёт на себя работу с файлами, а не оценку качества. Для сертифицированного или нотариального перевода не подходит.
Частые вопросы¶
Как сравнить два МП-движка и выбрать один для агентства?¶
Запустите оба на одном тестовом наборе из 500-1 000 сегментов, репрезентативных для вашего реального контента. Рассчитайте BLEU и COMET для каждого аутпута. Затем попросите одного редактора отредактировать 100-200 сегментов от каждого движка, отдельно отслеживая время. Автоматические баллы покажут относительный рейтинг. Человеческий пилот - действительно ли лучший по рейтингу движок заметно быстрее на практике.
Не проводите оценку на общих интернет-тестовых наборах - они не отражают ваш домен и не предсказывают реальную производительность.
Нужно ли строить собственные эталонные переводы?¶
Для постоянной оценки - да, нужны собственные отраслевые эталоны. Общие эталоны из наборов данных WMT не отражают качество технического или юридического перевода и дают вводящие в заблуждение баллы.
Стройте эталонный набор из работы, которую уже делаете. После каждого значимого проекта сохраняйте 200-500 пост-редактированных сегментов с источниками как постоянный тестовый набор для этой языковой пары и типа контента. За 6 месяцев у вас будут надёжные данные для оценки наиболее частых пар.
Как измерять качество МП в продакшне без эталонных переводов?¶
Используйте инструменты Quality Estimation. COMET-Kiwi, ModelFront или встроенный QE в Phrase могут оценить МП-аутпут без эталона. Они прогнозируют качество, а не измеряют относительно стандарта, но для решений о маршрутизации - какой сегмент требует тяжёлого vs лёгкого редактирования - баллы QE хорошо работают на практике.
Также можно использовать сам процесс пост-редактирования как данные о качестве: отслеживайте расстояние редактирования на сегмент по мере работы редакторов. После накопления 10 000+ сегментов данных у вас будет реальная эмпирическая база для понимания, что такое хороший и плохой МП-аутпут в ваших конкретных воркфлоу.
Какая реальная разница в усилиях между BLEU 35 и BLEU 45?¶
Для технического EN-DE контента: BLEU 35 обычно означает 35-45% сегментов требуют значительного редактирования, BLEU 45 - примерно 20-30%. Это приблизительно 600-700 слов/час при BLEU 35 против 800-1 000 слов/час при BLEU 45 для FPE. Существенна ли эта разница для вашей маржи - зависит от ставки клиента и оплаты редактора.
Для творческого или маркетингового контента те же баллы BLEU в основном бессмысленны как предикторы усилий - МП может быть беглым и при этом требовать почти полного перевода, потому что он культурно неправильный.
Можно ли вписать метрики качества МП в клиентские контракты?¶
Да, но осторожно. Если вы указываете минимальный BLEU или порог ошибок в контракте, вы и клиент должны согласовать методологию: одинаковый тестовый набор, одинаковый эталон, одинаковый инструмент оценки. MQM-контракты более защищены, потому что категории ошибок понятны: “никаких критических ошибок точности по таксономии MQM” яснее и лучше поддаётся аудиту, чем “BLEU выше 45.”
Источники¶
- Papineni et al. (2002) - BLEU: A Method for Automatic Evaluation of Machine Translation
- Unbabel/COMET - Crosslingual Optimized Metric for Evaluation of Translation
- ISO 18587:2017 - Post-editing of machine translation output
- GTS Translation - The State of MTPE in 2025: What Translators Think
- SwissGlobal - Translation productivity 2026: human translation vs MTPE
- Slator - How Fast Should You Post-edit Machine Translation?
- Nimdzi - The MTPE Efficiency Gap
- Hunnect - Fair Pricing Strategies for MTPE