Как должен выглядеть машинный перевод в 2025 г

Давайте признаемся, что мы уже устали от рассказов про то, что вышел новый движок, который делает машинные переводы «almost human-like» или «вообще не требует человеческого ревью». При этом движки действительно становятся все качественнее: дуумвират Google-Deepl разрушен, а новые языковые модели показывают немыслимые результаты на бенчмарках. Но почему мы все еще уверены, что хорошие бенчмарки нам не помогут? Как встроить движок МТ в процесс перевода так, чтобы он действительно помогал, а не мешал?

Результаты оценки движков МТ на WMT-2025. Источник ^[1] 

Перед вами результаты работы движков МТ на WMT-2025 — датасете-бенчмарке для оценки качества переводов. На первый взгляд итоги впечатляют, но в чем же загвоздка? 

Проблема в том, что все они дают результаты в первую очередь на «ванильных» датасетах. Но мы гораздо чаще переводим не статьи из  «Википедии», а узкоспециализированные тексты с сотнями отдельно стоящих слов и уникальными субъектами, а не общеизвестными Д’Артаньяном и капитаном Немо. Однако это не самая большая сложность. 

Главная проблема машинного перевода

Основная боль ^[2] в том, что движок МТ воспринимает каждую новую строку с чистого листа. Когда вы отправляете строки на перевод одну за одной, движок МТ не знает, что он переводил до этого. Для него каждая строка существует отдельно от всех предыдущих и от проекта в целом. Здесь-то и возникают проблемы — например, когда в соседних строках одно и то же имя переведено по-разному. Или когда на первой  строчке движок догадался, что звучит вопрос к персонажу, убившему динозавра, а на следующей — не понял, что это его ответ. 

Работая над проектом, профессиональный лингвист учитывает перечисленные проблемы. Более того, в CAT-тулзах ему на помощь приходят память ^[3] переводов (ТМ) и терминологическая база (TB) — главные инструменты, без которых не должен переводиться ни один уважающий себя проект. Они хранят переводы уже подтвержденных переводчиком строчек проекта, а также слова, которые были им вынесены как термины. Это позволяет лингвистам меньше загружать голову и быстрее вспоминать ^[4], что подходит в процессе перевода. 

RAG MT спешит на помощь

Некоторые МТ имеют возможность добавить к промту память переводов и глоссарий — и тогда нейросеть должна выдать перевод с учетом ТМ и ТB. Эта функция получила название «Adaptive translation», «AI translation» или даже «Never-Before-Seen Technology», хотя по сути внутри технология RAG ^[5]. Она позволяет делать так называемый «адаптивный» машинный перевод и идеально ложится на задачи контекстного перевода. 

Суть RAG в том, что перед генерацией ответа модель сначала ищет релевантную информацию в предоставленных ей базах знаний (TM, TB). Затем она обогащает (augments) свой исходный запрос, добавляя к нему найденные контекстуальные подсказки, и только после этого генерирует перевод.

Таким образом, RAG действует как «искусственная память» для МТ-движка. Вместо того чтобы гадать, перевести Karl или Karel, модель запрашивает базу терминов и память переводов, находит там нужный вариант и использует его для обеспечения согласованности. Это кардинально повышает консистентность перевода, особенно в больших и сложных проектах, где важна каждая деталь повествования.

Зачем нужна Ad hoc память переводов

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

Это важно, чтобы продолжая работать над переводом, движок помнил, что он только что перевел. Конечно, вы можете переводить предложения одно за одним и добавлять результаты в ТМ итеративно, но кому нужен такой мартышкин труд?  

Максимизируем силу промта

Итак, у нас есть ТМ, TB и ad hoc ТМ — что дальше? Думаю, все согласны с выражением «контекста мало не бывает». Кроме предыдущих фраз, нужный для перевода контекст строк может находиться где угодно: в ID строки, переводах на другие языки, developers’ notes, в соседних «столбиках» от колонки перевода или даже в прямых указаниях от разработчиков. Зачастую именно из этих источников переводчик узнает самую важную информацию: кто и кому говорит, какое назначение у строки — название квеста или само задание, лимит строки по длине, что хотят видеть разработчики и на какие строчки из ТМ нужно опираться при переводе. А еще есть стилистические руководства и энциклопедии. Чтобы у ИИ условия были не хуже, чем у лингвиста, важно дать ему всю информацию. 

В итоге основная работа должна быть направлена на то, чтобы собрать нужный промпт. Он сильно распухнет, и внимание ^[6] нейросети может быть рассеяно. Но бояться этого не нужно: современные движки относятся к этим инструкциям бережно, а цена за токены не такая уж большая. В конечном счете длина контекста, добавляемого в промт, должна быть в разы больше, чем сам текст на перевод. К примеру, объем слов для перевода на одном из наших проектов был около 90 000, а расход токенов с учетом контекста составил несколько миллионов.

И тут уже не важно, какую именно LLM вы используете — возьмите любую из топа на картинке сверху, исходя из финансовых возможностей (там есть и опенсорсные). Любая LLM, выпущенная в 2024-25 гг. с использованием правильного подхода даст для вашего проекта результат значительно лучше, чем в голом виде. Такой процесс дает ИИ возможность получить столько же информации, сколько было бы у лингвиста во время перевода. 

Проверьте вашего поставщика MT

Спросите, способно ли ваше LSP/TMS/CAT поддержать такой техпроцесс машинного перевода или просто обещает, что всё ляжет идеально out of the box и не требует «человеческого вмешательства».  Вот небольшой чек-лист, чтобы это можно было проверить:

• Какой движок/модель используется для перевода и почему был выбран именно он?

• Какие объективные метрики качества он показал на бенчмарках или на вашем внутреннем тестовом наборе данных?

• Учитывается ли контекст строк в памяти переводов?

• Учитывается ли ad hoc память переводов — то, что было переведено движком только что в рамках этой же задачи, но еще не добавлено в TM?

• Поддерживает ли их система кастомизированный промпт, который позволяет добавить необходимую информацию для каждой строки?

• Учитывается ли при переводе информация из технических полей: ID строки, комментарии разработчиков, теги, ограничения по длине? Учитывается ли название файла и путь к нему как источник контекста?

• Как система определяет уверенность (match score) в рекомендациях из TM/ad-hoc памяти?

• Учитываются ли уже выполненные переводы на другие языки в этом проекте, если они есть?

• Можно ли прикрепить к проекту целые файлы с дополнительным контекстом (библии персонажей, ТЗ, гайдлайны) для их использования при поиске?

@t.me/muzzicalsoup ^[7]