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

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

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

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

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

« »

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

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

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

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

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

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

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

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

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

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

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


20 марта 2017 John Gower | 6 комментариев


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

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

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

  • Сергей, а я правильно понимаю, что n-граммы — это уже имеющийся во многих кошках внутрисегментный поиск по ТМ?
    И очень верное замечание насчет high-resource languages. С русским тут все плохо. Как я понимаю, в корпусе, который ведет Институт русского языка, собрано в 2-2,5 раза меньше слов, чем в корпусе английского, и это явно не про причине бедности русского вокабуляра. А нормальной алгоритмической модели русской грамматики нет и не предвидится, поэтому по-прежнему даже просто автоматически слепить грамотную фразу на русском не выходит.

    P.S. Пока GT переводит «Yesterday I bought a table» как «Вчера я купил таблицу», опасаться нечего ))))

    • Это скорее субсегментный поиск, фактически, когда в том же Trados Studio создаешь словарь AutoSuggest, ты фактически создаешь такой набор n-грамм,т.е. слов которые в этомтексте близко встречаются, условно, если собрать много русских текстов про буровые установки, то там очень слово «забойный» будет часто встречаться со словом «двигатель», то есть это будет биграмма. С НКРЯ ситуация сложная, они должны соблюдать некий баланс, т.е. представлять весь язык. Очень тяжело собирать устную речь, там много правовых моментов при снятии которых наблюдается «эффект испытуемого». Новую академическую грамматику вроде как пишут, но процесс идет не очень быстро, там тоже свои конфликты интересов, парадигм и пр.

  • > нормальной алгоритмической модели русской грамматики нет и не предвидится

    Несогласная я. Алгоритмически, кмк, многое про русский довольно давно было изложено неплохо (этим с полвека не самые тупицы занимаются). Другое дело, что на наработанное пару десятков лет чихали. Сначала, ссылаясь на то, что новые процессоры (пентиум) нам позволяют наплевать на то, что не было реализовано в 70-е, а потом — на SMT как двигатель прогресса.

    • Тут дело такое, одно дело, то, что рождалось в том же ИППИ АН им.Харкевича, и другое дело то, что можно реализовать коммерчески. Мой educated guess — что-то вполне себе реализовано в Compreno (сужу по 3,5 открытых научных публикаций. Что-то на базе концепции смысл-текст и далее по мотивам, плюс достижения стаистики).

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

 

 

 

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

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