Впрочем, шпионаж — это лишь в моей голове, поскольку, разумеется, беседа наша состоялась в момент, когда Abbyy вышла на финишную прямую и была готова раскрыть миру свои карты.
Подробности Compreno я донесу читателям со слов Сергея Андреева и Татьяны Даниэлян — не потому, что не доверяю собственным суждениям, а потому что рассказ у обоих получился гладким и содержательным, зачем же плодить сущности?
Начало разработки Compreno пришлось на 90е годы, когда в арсенале ABBYY (в те годы — еще BIT Software) уже числилось два ледокола: словари Lingvo и программа для распознавания текста FineReader. Продукты продавались по всему миру, были хитами и приносили стабильную прибыль — манна небесная для романтических проектов вроде Compreno, стресс которых не пережил бы ни один сторонний инвестор (вкладывать миллионы долларов в нечто совершенно революционное да к тому же и с неизвестными перспективами? а вдруг ничего не получится? нет уж увольте!).
ABBYY обошлась без чужих денег и это спасло Compreno, позволив довести до победного конца проект со столь колоссальными материальными и людскими затратами.
Успех обеспечил и правильный изначальный выбор направления для разработки системы автоматического перевода. В 90-е в мире правила одна королева — Rule-Based Translation Model, классическая модель перевода, основанная на ограниченном наборе готовых правил для некоторой пары языков. Одна из проблем RBTM — в накоплении все новых и новых правил, которые в какой-то момент просто начинают конфликтовать между собой. Анализируя предложение, мы можем применить разные комплекты правил, при этом машине неведомы приоритеты. Перевод, основанный на RBTM, как правило, не озабочен полным синтаксическим анализом: вместо него предложение делится на фреймы, на которые затем интерполируют существующие в системе правила для получения перевода. RBMT системы не учитывают семантику.
В начале XXI века усилиями Google мир подсел на иглу нового алгоритма перевода — так называемой статистической модели. Основа СМ — наличие обширной базы разнонаправленных переводов. Мы задаем статистическому движку предложение для перевода, он ищет в базе данных как в словаре варианты уже существующих переводов аналогичного текста и после незначительных изменений выдает вполне приличный результат.
Изменения не самые существенные. Предположим нам нужно перевести предложение «в комнате стоит красный стул», а в статистической базе уже есть переведенная фраза «в комнате стоит зеленый стол» — решение элементарно: берется уже существующий шаблон перевода и новые слова просто заменяются по словарю.
Поскольку в СМ используются уже готовые человеческие переводы заведомо высокого качества, то на выходе получается весьма недурственный результат, ибо для осуществления перевода не нужно погружаться в синтаксис, специфику фразеологии конкретного языка и проч.
Все замечательно, однако, лишь до тех пор, пока дело не касается переводов в направлениях с так называемым низким покрытием (скажем, каким-нибудь, румынско-русским или тайско-венгерским).
Где брать аналоги? По словам Сергея Андреева опасность подстерегает также при уходе в предметные области на массовых направлениях, потому что параллельных текстов становится сильно меньше, чем в бытовой и разговорной тематике. Сочетание ухода в предметную область и не самого массового направления перевода приводит к слабым результатам. Скажем, IT. Казалось бы, какие сложности могут возникнуть у машинного перевода с текстом на тему информационных технологий? В самом деле — никаких, если мы занимаемся русско-английским переводом. Зато они тут же возникнут на русско-французской ниве! Статистическая база в этом направлении чрезвычайно скудная и лакуны возникают на каждом шагу.
Выход в рамках СМ для подобных ситуаций найден лишь паллиативный: работая с языками / темами низкого покрытия в качестве посредника используется английский язык. То есть сперва делается перевод с русского на английский, а затем уже с английского на, скажем, румынский, или тайский. В результате получается очень заметное снижение качества перевода.
