AI-система оценки качества перевода: QE без эталонов

Почему Quality Estimation ломается без эталонных переводов

Эталонные метрики качества перевода держатся на одном допущении: у каждого сегмента есть эталон. На практике он есть только для контрольного набора, а основной поток — интерфейсы, документация, маркетинговые тексты — идёт без него. Как только эталон исчезает, оценка качества перевода перестаёт быть измерением и превращается в мнение.

Тогда включается ручная проверка, и она быстро становится бутылочным горлышком. Лингвист разбирает сегмент за сегментом: скорость предсказуема — минуты на фрагмент, — а объём контента растёт быстрее. Оценка приходит через дни после публикации, когда правки уже внесены, и на качество больше не влияет.

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

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

Что даёт автоматический контроль качества на потоке

Автоматический контроль качества переводит вычитку из сплошной в выборочную. Модель оценивает каждый сегмент относительно исходного текста, и лингвист открывает только то, что ниже порога. На рабочих языковых парах это снимает 70–85% объёма ручной проверки: время редакторов уходит на спорные места и глоссарии, а не на повторное чтение стабильных фрагментов.

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

Единую шкалу оценки дают открытые метрики семейства COMET — стандарт в области Quality Estimation. Они обучены на человеческих оценках и потому сопоставимы между языками, командами и подрядчиками. Вместо пяти разных «хорошо/плохо» в отчёте появляется одно число и формальная граница приёмки — спорить можно по существу, а не по вкусу.

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

Quality Estimation: сравнение подходов без эталонов

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

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

Сравнивать режимы корректно на своей выборке: 300–500 сегментов с ручной оценкой по многомерной шкале в духе MQM показывают, где модель ошибается системно. В гибриде отбор делают стратифицированным — рискованные сегменты уходят редактору целиком, остальные попадают в случайную выборку 5–10%, и по ней считают долю пропущенных дефектов.

Этапы внедрения: от аудита данных до передачи системы

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

1. Аудит исторических переводов. Собираем корпус из уже принятых заказчиком работ, размечаем по шкале прямых ошибок — смысл, терминология, оформление, — выявляем домены, языковые пары и типы сегментов, убираем дубли и обрезанные строки.
2. Проектирование схемы оценки. Фиксируем, что считаем критичной ошибкой, а что допустимой вариативностью, кодируем правила в разметку и делим корпус на обучающую, контрольную и отложенную части.
3. Настройка модели. Обучаем оценщик на парах «перевод — вердикт редактора», отдельно обрабатываем редкие домены, чтобы смещение по частотным темам не переносилось на остальные.
4. Настройка порогов. Подбираем границы, при которых сегмент уходит на ручную проверку: считаем полноту и точность на контрольной части и балансируем нагрузку редакторов — слишком узкий порог заваливает их работой, слишком широкий пропускает смысловые ошибки.
5. Проверка на отложенной выборке. Прогоняем систему на сегментах, не участвовавших в обучении, со стратификацией по доменам и языковым парам, сверяем с оценками редакторов и разбираем каждое расхождение из верхней части диапазона.
6. Передача системы. Отдаём конфигурации, регламент разметки, схему переобучения и порядок обновления корпуса, обучаем команду заказчика запускать оценку и читать отчёты самостоятельно.

После передачи остаётся контроль дрейфа: раз в квартал сверяем оценки с ручной проверкой, обновляем разметку на новых доменах и переобучаем модель. Опишите задачу и объём исторических переводов — вернёмся с оценкой и планом этапов.

Что передаём на руки: конфигурации и регламенты

Передаём не только работающую систему, но и комплект артефактов, по которому её можно эксплуатировать и развивать без нас. Состав ниже — типовой для внедрения оценки качества перевода (Quality Estimation): он закрывает и повседневную работу, и спорные ситуации, когда автоматический балл расходится с мнением редактора.

• Конфигурации оценки — профили под каждую языковую пару и тип контента: пороги, веса признаков, список исключений. Меняются в отдельном файле, без правки кода.
• Схема интеграции — где система подключается к вашему контуру перевода: сервисный вызов, пакетная обработка файлов, выгрузка из памяти переводов. С форматами обмена и поведением при недоступности сервиса.
• Описание правил оценки — как формируется балл по сегменту, какие признаки на него влияют, что отключено и почему: результат перестаёт быть «чёрным ящиком».
• Регламент разбора спорных случаев — кто и в какой срок рассматривает расхождение между автоматической оценкой и живым редактором, как решение возвращается в настройки.
• Набор эталонных сегментов — размеченная выборка, на которой систему прогоняют после каждого изменения порогов: видно, стало точнее или просто иначе.
• Инструкции по эксплуатации — запуск, контроль показателей, признаки деградации и порядок действий, когда качество просело.
• Журнал решений и калибровки — зафиксированные договорённости по сложным сегментам, порядок добавления новой языковой пары и данные, на которых проверяют результат.

Кейс: контроль качества перевода на восьми языковых парах

До: выборочный контроль вместо системы

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

Что настроили

Построили оценку качества без эталонов (Quality Estimation) на COMET: модель предсказывает качество сегмента по паре «источник — перевод», не требуя заранее подготовленного образца. Разметкой стали накопленные правки — то, что редактор менял, модель училась считать отклонением, а не вариантом нормы. Для каждой языковой пары подобрали свои пороги: уверенные сегменты принимаются автоматически, пограничные уходят в очередь к живому редактору вместе с оценкой и флагом причины.

Что стало с метриками

Доля автоматических решений выросла с трети до трёх четвертей сегментов, объём ручной вычитки сократился примерно втрое. Разброс оценок между языковыми парами сжался: раньше одна пара стабильно получала завышенные баллы, теперь шкала сведена к общему виду и сравнима между языками. Время цикла выпуска сократилось с девяти дней до четырёх — узким местом перестала быть очередь на согласование, а спорные сегменты стали видны на входе, а не после вычитки.

Что делать, если уже развёрнут свой контроль качества?

Если контроль качества уже работает, начинать с нуля не нужно — вопрос в том, чего именно не хватает: покрытия редких языковых пар, свежести сигнала или независимости оценки от своей команды. От этого зависит выбор — достраивать контур своими силами или подключать внешнюю оценку без эталонов.

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

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

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

Технические сомнения: где ошибается автоматическая оценка

Оценка без эталона (Quality Estimation) предсказывает качество перевода по паре «источник — результат», не имея подготовленного образца. На типовых парах и ровной разметке модель держит высокое согласие с экспертом, но проседает там, где и человек-оценщик расходится сам с собой: редкие языковые пары, узкая терминология, длинные сегменты с перестроенным порядком слов.

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

Что делать с пограничными сегментами?

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

Держится ли оценка при смене домена или языка?

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

Обсудим задачу: как строится система оценки качества

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

Чтобы посчитать сроки по вашим данным, а не средние по рынку, нужен минимум вводных:

• 2-5 тысяч сегментов «источник — перевод» в рабочем формате: xliff, tmx или простой tsv из вашей системы переводов.
• правила качества и разметка ошибок, если она велась: гайдлайны, шкала, примеры спорных случаев.
• один-два оценщика, готовых разметить 300-500 сегментов: по их вердиктам мы калибруем модель и считаем расхождения.
• описание потока: на каком шаге человек сейчас вычитывает текст, где решение принимается и что с ним происходит дальше.
• ограничения по контуру: какие данные нельзя выводить за пределы вашей инфраструктуры и в каком режиме должна работать оценка.

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

Если части данных нет — не блокер: корпус мы соберём и разметим сами, но тогда к срокам добавится этап подготовки. Опишите задачу в таком виде — вернёмся с планом работ и оценкой.