Как правильно провести человеческую оценку качества MT-вывода

Вендор прислал подробный бенчмарк: кастомизированный EN→RU движок набрал 47.2 BLEU на тестовом наборе технической документации, против 39.8 шесть месяцев назад. Ты пустил через него 30% объема. Через три недели крупный клиент возвращает партию переведенных технических инструкций - неправильные единицы измерения, перевернутые правила безопасности, один пункт означает ровно противоположное оригиналу.

BLEU ничего из этого не поймал. Бенчмарк вендора ничего не поймал. Человек-оценщик, читая вывод как конечный пользователь, поймал бы всё за десять минут.

Именно это решает человеческая оценка качества МТ - и именно поэтому большинство агентств проводят её неправильно.

Почему автоматических метрик недостаточно¶

BLEU, COMET, TER - эти метрики полезны для отслеживания развития MT-движка от версии к версии. Они измеряют то что быстро и дешево считается: совпадение n-грамм, нейронную схожесть, редакционное расстояние. Они не измеряют то, означает ли переведенное предложение то же что оригинал. Они не ловят перевернутые отрицания, неправильные отраслевые термины, отсутствующие предупреждения безопасности или вывод который грамматически безупречен но фактически неверен.

CSA Research в своей практической оценке назвала автоматические MT-метрики “искусственными и нерелевантными для производственных сред перевода”. Это резко, но суть правильная: ни одна автоматическая метрика сейчас не скажет тебе подходит ли переведенный контент для своего назначения со своей аудиторией.

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

Три основных фреймворка¶

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

Direct Assessment (DA)¶

DA - протокол оценки на уровне сегмента от WMT. Оценщики видят исходный сегмент и один перевод (не видят референс и не знают какая система его сделала), затем выставляют общее качество на непрерывном ползунке 0-100. Несколько оценщиков оценивают каждый сегмент; оценки z-score нормализуются по оценщику чтобы убрать масштабный сдвиг (70 одного оценщика может соответствовать 85 другого если их внутренние шкалы разные).

На что отвечает: “Как система A ранжируется относительно системы B на этом контенте?” Быстро в администрировании, хорошо для сравнения нескольких систем когда нужно относительное ранжирование без глубокого анализа ошибок.

На что не отвечает: где ошибки, какого они типа, и соответствует ли вывод конкретному порогу качества. Оценка 72 не скажет тебе - эта 28-балльная разница одна критическая ошибка перевода или сотня незначительных пунктуационных.

MQM (Multidimensional Quality Metrics)¶

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

Типы ошибок в MQM:

Веса серьезности (из themqm.org):

Формула MQM-балла: (Критические × 25 + Значительные × 5 + Незначительные × 1) ÷ количество слов × 1000

Меньше - лучше. Большинство производственных порогов для публикуемого контента - до 5-10 баллов MQM на 1000 слов; для юридических и медицинских материалов - до 2.

На что отвечает MQM: именно где качество ломается, в каких категориях и какой серьезности. Если движок производит точный но неестественный вывод - MQM скажет что это проблема Беглости, а не Точности. Это определяет вкладывать ли в дообучение, пост-редактирование или работу со стайлгайдом.

Error Span Annotation¶

Более легкий вариант между DA и полным MQM. Оценщики отмечают фрагменты с ошибками без полной классификации. Проще обучать оценщиков, быстрее проводить. Статья 2024 года об Error Span Annotation показала корреляцию с MQM при затрате на 30-40% меньше времени на сегмент.

Полезно когда нужно больше сигнала чем от DA, но нет бюджета или времени на полный MQM.

Выбор оценщиков - решение которое определяет всё¶

Любое другое решение в дизайне оценки вторично относительно этого. Неправильные оценщики дадут тебе уверенно выглядящие цифры которые не отражают реальное качество.

Что делает оценщика квалифицированным¶

Носитель целевого языка - без исключений. Даже очень свободный неноситель пропустит проблемы естественности и регистра которые любой носитель заметит сразу.

Профессиональный переводчик с доменным опытом. Исследование опубликованное в TACL (MIT Press) подтвердило то что практики уже знали: профессиональные переводчики находят значительно больше ошибок чем билингвы без переводческого образования, особенно тонких - неправильная доменная терминология, нарушения связности между сегментами, прагматические ошибки. Краудворкеры “более терпимы к MT-выводу” и систематически ставят ему более высокие оценки, что смещает результаты в сторону переоценки качества.

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

WMT пересмотрел свои процедуры оценки именно потому что краудворкеры “менее способны обнаруживать тонкие MT-ошибки” - из-за этого WMT перешел от краудсорсинга к пулам профессиональных переводчиков для качественной оценки.

Сколько оценщиков¶

Минимум 3 на сегмент для MQM. Большинство серьезных оценок используют 2-3 аннотатора на сегмент с протоколом арбитража для разногласий. Меньше 3 оценщиков - расчет межоценочного согласия становится ненадежным.

Обучение оценщиков - обязательно минимум 2 часа¶

Оценщики должны быть откалиброваны прежде чем коснутся реальных данных. Минимально: 1. Проведи их через инструкции аннотации (не просто дай PDF) 2. Попроси аннотировать 20-30 предварительно размеченных обучающих сегментов где ты знаешь правильные ответы 3. Вместе просмотри их аннотации, обсуди разногласия 4. Начинай считать рейтинги только после этой калибровочной фазы

Исследовательские гайдлайны рекомендуют “минимум 2 часа обучения на оценщика”. На практике для MQM на специализированном контенте планируй полдня калибровочной сессии.

Дизайн тестового набора¶

Плохой дизайн тестового набора - вторая по частоте причина провала оценки.

Размер¶

Гайдлайны MQM-сэмплинга на themqm.org четки: идеал - оценивать весь переведенный контент; при сэмплинге минимум 500-1000 слов. Для сравнения двух производственных систем с достаточной статистической мощностью - цель 1000-5000 сегментов.

Ниже 500 сегментов - недостаточно данных чтобы отличить реальную разницу качества от вариативности контента.

Практический ориентир: - Быстрый скрининг MT-движка: 500-1000 слов - Сравнение вендоров перед контрактом: 1000-2000 сегментов - Валидация производственного порога качества: 2000-5000 сегментов

Репрезентативность контента¶

Тестовый набор должен выглядеть как твой реальный производственный контент. Не используй простой хорошо отформатированный образец если твой производственный контент включает таблицы, сноски, юридические перекрестные ссылки и доменные аббревиатуры - именно там МТ ломается чаще всего.

Если контент неоднородный (технические руководства + маркетинговые тексты + FAQ поддержки) - стратифицируй выборку чтобы включить все типы. Одна цифра по смешанному тестовому набору будет скрывать что движок отлично справляется с руководствами и ужасно с маркетингом.

Изоляция тестового набора¶

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

Проведение оценки¶

Слепая подача¶

Каждый оценщик видит: - Исходный сегмент - Один перевод - (Для MQM) Референсный перевод, если используется

Что оценщики не должны видеть: - Какая система что сделала - Аннотации других оценщиков на том же сегменте - Результаты разных систем рядом

Подавай системы в разном случайном порядке каждому оценщику. Аннотируй несколько систем в перемешанном порядке чтобы оценщики не формировали ментальную модель “это выглядит как система A”. То же самое что слепое тестирование вкуса в пищевой оценке - и здесь это так же важно.

Исследование WMT подтвердило: “исследователи проявляли незначительное предпочтение своих систем” даже при якобы слепой оценке. Убери возможность для предвзятости.

Контрольные сегменты¶

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

Команда eBay описала этот подход: профессиональные суждения “вставляются случайным образом по всему заданию оценки” и используются для исключения судей показывающих ниже порога на контролях.

Если оценщик проваливает более 20-25% контрольных сегментов - его аннотации нужно проверить перед включением.

Инструкции аннотации¶

Пиши инструкции аннотации до того как набираешь оценщиков - не после, и не в процессе. Инструкции должны охватывать:

• Как работать с неоднозначным исходным текстом (не штрафуй МТ за неоднозначность которая уже есть в источнике)
• Как работать с несколькими правильными переводами (синонимы означающие то же самое - не ошибки)
• Область оценки: оцениваешь сырой MT-вывод или MT после легкого редактирования?
• Какие категории MQM применяются к твоему типу контента
• Примеры каждого уровня серьезности из реального доменного контента

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

Расчет межоценочного согласия¶

Если у тебя 3 оценщика и пропустишь этот шаг - доверяешь числу которое может быть обусловлено одним нетипичным оценщиком.

Cohen’s kappa (для двух оценщиков) и Fleiss’ kappa (для 3+) измеряют насколько оценщики соглашаются сверх того что предполагает случай:

Для MQM-аннотации ошибок среднее в исследованиях - kappa около 0.51, “умеренный” диапазон. Исследования с хорошо обученными специалистами достигали 0.92-0.95.

Если kappa ниже 0.3: остановись прежде чем анализировать результаты, пересмотри инструкции вместе с оценщиками, вместе аннотируйте выборку, исправь разногласия - затем продолжай.

Низкая kappa не означает что оценщики ошибаются - она означает что инструкции оставляют слишком много пространства для интерпретации.

Типичные ошибки которые уничтожают результаты¶

Оценивание сегментов вне контекста документа. Сегмент “Не нажимайте эту кнопку” может означать совсем разное в зависимости от контекста. Оценка на уровне предложения слепа к проблемам связности и когерентности. Для чего-либо серьезнее быстрого ранжирования - показывай предыдущий и следующий сегменты.

Отсутствие контроля сложности исходного текста. Легкий контент (короткие сегменты, общий словарь) завышает MT-оценки относительно сложного. Если сравниваешь общий движок на легком контенте с адаптированным на сложном - измерил контент, а не движки.

Смешивание уровней опыта оценщиков. Один профессиональный переводчик и два двуязычных непереводчика - это не три эквивалентных точки данных. Либо используй всех профессионалов, либо анализируй отдельно.

Использование беглости как заменителя точности. MT-системы намного лучше в производстве беглого вывода чем точного - это одна из самых стабильных находок в MT-исследованиях. Оценщики, особенно непереводчики, систематически путают беглость с качеством. MQM предотвращает это разделяя измерения; DA поощряет эту путаницу.

Оценивание без доменного референса. Оценщики без знания домена пропустят терминологические ошибки. В переводе юридических документов неправильно переведенный термин может изменить смысл обязательств - и это заметит только юридический переводчик.

Знание оценщиками какая система какая. Даже тонкие подсказки - “система A это наш новый движок” - вносят предвзятость. Слепая оценка не опция если нужны достоверные результаты.

Что делать с результатами¶

Результаты MQM говорят где вмешиваться¶

Если MQM-вывод показывает: - Много ошибок точности: движок недостаточно понимает смысл источника. Файнтюн на доменных параллельных данных или этот тип контента не подходит для сырого МТ. - Много ошибок беглости: вывод точный но неестественный. Хороший стайлгайд + MTPE-воркфлоу исправит это дешевле чем перевод. - Много терминологических ошибок: движок пропускает доменный словарь. Исправляй инжекцией глоссария, терминологическим файнтюнингом или инструментами контроля терминов. - Много ошибок локальных конвенций: проблема конфигурации - форматы дат, системы единиц. Обычно исправляется постобработкой или конфигурацией движка.

Этот диагноз возможен только с MQM. DA-оценка 65 говорит тебе что качество не оптимально; MQM говорит вкладывать ли в файнтюнинг, пост-редактирование или работу со словарем.

Установка порогов проход/провал¶

Типичные производственные пороги по типу контента (MQM-баллы на 1000 слов):

Эти числа не универсальны - калибруй под свой контент и требования клиентов. Но они дают начальную рамку.

Передавай результаты вендорам¶

Человеческая оценка производящая только число - упущенная возможность. Поделись с MT-вендором распределением MQM-ошибок - они могут использовать это для приоритизации файнтюнинга. “Ваш движок имеет в 3 раза больше критических ошибок точности в придаточных предложениях” - это действенная инженерная информация которую дельта BLEU предоставить не может.

FAQ¶

Сколько занимает человеческая оценка МТ?¶

Для MQM-аннотации опытный профессиональный переводчик аннотирует примерно 400-600 слов в час (учитывая отметку ошибочных фрагментов, классификацию и серьезность). Оценка 2000 сегментов с 3 оценщиками занимает около 30-40 человеко-часов плюс 4-6 часов обучения и калибровки. Планируй 1-2 недели на расписание и выполнение.

Можно ли использовать одних и тех же оценщиков для нескольких оценок?¶

Да, и это имеет реальные преимущества - обученные оценщики откалиброваны под твои инструкции, что повышает консистентность. Риск - усталость оценщика и “якорение” к предыдущим оценкам. Если оцениваешь тот же тип контента со временем - ротируй минимум одного оценщика каждые несколько оценок чтобы обнаружить дрейф.

Какая разница между оценкой качества и оценкой качества без референса (QE)?¶

Человеческая оценка (MQM, DA) измеряет фактическое качество людьми читающими вывод. Quality estimation (QE) - автоматизированная - она предсказывает показатели качества без референсного перевода, используя модели обученные на данных человеческой оценки. COMET-QE, например, предсказывает MQM-подобные оценки на уровне сегмента. QE намного дешевле и быстрее; человеческая оценка - это ground truth которую QE пытается приблизить.

Оценивать сырой MT или отредактированный?¶

Оба, но для разных целей. Оценка сырого МТ говорит подходит ли движок для типа контента. Оценка MTPE-вывода говорит производит ли твой MTPE-воркфлоу приемлемое финальное качество. Смешивание двух дает оценку которая реально измеряет твоих пост-редакторов, а не движок.

Источники¶

• MQM Framework - themqm.org
• MQM Sampling Guidelines
• Slator - How to Fix the 5 Flaws in Evaluating Machine Translation
• Experts, Errors, and Context - TACL/MIT Press
• eBay - Human Evaluation of Machine Translation
• Machine Translate - Human evaluation metrics
• Error Span Annotation: A Balanced Approach (2024)