Новости Энциклопедия переводчика Блоги Авторский дневник Форум Работа

Декларация О нас пишут Награды Читальня Конкурсы Опросы
Автор
Управление

Тёмный уголок

(Около)переводческие мысли из-за шкафа

Подписаться на RSS  |   На главную

«

(Полу)машинный (полу)перевод. Варианты раскрытия скобок.

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

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

При всём моем уважении к разработчикам МП и интересе к технологии я не могу согласиться с утверждением, что МП, пусть даже и нейронный (равно как и мозжечковый) сможет приемлемо переводить тексты требующие применения трансформаций (простите) которые невозможно   или очень сложно алгоритмизировать (для RBMT) или для которых существуют  устойчивые соответствия (для SMT). А что же делать с пресловутым «миром за текстом»? Ну, предположим, разработчик движка смог создать хороший набор правил, словари, чистый и релевантный тематике стомиллионный корпус и онтологию, которые при этом хорошо между собой согласуются… Я не уверен, что это возможно на данном этапе развития науки и техники, а если и возможно, то очень дорого. А вот письменный перевод (про устный даже не хочу думать) штука двунаправленная. Создав текст перевода мы можем его критически осмыслить и скорректировать, сопоставить с некоторым «внутренним эталоном» и опять вернуться к нему. МП, по крайней мере пока, так делать не умеет. То есть та самая пресловутая герменевтика, сколько бы её ни было в каждой конкретной ситуации письменного перевода, исчезает, а ведь именно этот герменевтический навык и маркирует разницу между переводчиком плохим и хорошим. Между белковой реализации функции замены слов одного языка на слова другого и тем, кто кое-чего в переводе понимает. Таким образом, загнав текст в движок МП мы получаем некий текст который может в определенных ситуациях выполнять функцию перевода, но не обязательно переводом являться.

Что же делать? Может быть выход в разумной, ограниченной и постепенной автоматизации? Тем более, что переводчики сами к такой автоматизации готовы. Я говорю о Lilt и технологиях субсегментного поиска по ТМ.

Начнем с подстановки кусочков сегментов, фактически n-грамм. Именно n-граммы обеспечивают статистическому МП пресловутую «гладкость» и вот если мне предложить не готовое решение, а подсказки в виде кусков сегментов (из ТМ или базы данных движка), то я охотнее соглашусь их использовать, ведь за меня никто не переводит. А проигнорировать два слова и придумать свой вариант всяко легче тем стереть предложение движка и разочаровываться в технологии. И вот если в той же САТ программе эту функцию можно реализовать с определенными ограничениями, то в движке МП больше возможностей как по настройке, так и по учету типа документа, уже подставленных сочетаний, статистики других пользователей (если NDA это допускает)…

И так мы подходим к адаптивному МП. У Lilt мне особенно понравилась следующая штука — перевод есть, он дается с вариантами, но не подставляется сразу в поле для ввода текста.  Иными словами МП имеет «совещательный голос»,  который можно и не слушать, а можно и слушать, если он говорит ерунду.

Иными словами, пока тренировка движков не станет проще, интуитивнее, прорыва не будет.

Ещё один важный фактор который искажает наше представление о состоянии машинного перевода это то, что большинство утверждений о нем базируются на данных т.н. «high-resource languages». Они хорошо описаны лингвистами, для них есть нормально прописанные грамматики, словари, корпусы и пр. Иными словами, успех движка переводящего с каталанского на испанский не есть победа всей технологии. Это локальный успех.

Вот как-то так.


20 Март 2017 John Gower | Комментариев (2)


комментариев (2) к (Полу)машинный (полу)перевод. Варианты раскрытия скобок.

  • Сергей, а есть у вас опыт постредактирования МП текстов, написанных не носителями? А то мне за последний год приходилось переводить с английского на русский довольно много текстов, написанных немцами и японцами. Там встречались и грамматические ошибки, и просто пропуски смысловых глаголов, и довольно причудливый выбор лексики. Если немцев я понять могу, обратившись к немецко-английскому словарю, например, то с японцами выручало только знание предметной области. И мне интуитивно кажется, что МП пока не может решать такого рода задачи.
    Насколько я знаю, создаются databases of non-native English, в том числе и для целей МП. Интересно, насколько успешно идёт «обучение».

  • Был в очень похожей ситуации, но с китайцами. Опять же заказчики БП для которых я делал постредактуру как сугубо частное лицо (просто фрилансер) упорно не хотели называть движок, которым это было сделано. Рискну предположить, что они просто не знали. Неносители тоже бывают разные, но да такие параллельные корпусы собирают, но вот насколько они идут в обучение движков…. Хотя Гугл гребёт всё )))

Оставить мнение

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>