Compreno abbyy что это

Содержание

Технология Compreno предназначена для создания систем анализа, перевода и поиска текстов на различных языках.

Compreno - это технология перевода любого человеческого языка на универсальный язык понятий. Соответственно, Compreno включает в себя и сам этот универсальный язык понятий, который ABBYY тайком разрабатывала с 1990-х годов в своих исследовательских лабораториях.

2015: Старт продвижения Compreno в корпоративном сегменте

25 марта 2015 года компания ABBYY сообщила о развитии направления корпоративного бизнеса в сфере интеллектуальной обработки информации, которое является неотъемлемой частью рынков ECM, ERP, текстовой аналитики и поиска.

На 25 марта 2015 года на платформе ABBYY Compreno реализованы три решения:

• ABBYY InfoExtractor SDK,
• ABBYY Smart Classifier SDK
• ABBYY Intelligent Search SDK.

Пилотные проекты с использованием Compreno стартовали в Государственной Думе, КЭС-Холдинге, крупной нефтяной, энергетической и других компаниях из разных отраслей. Решения ABBYY Compreno позволяют:

• анализировать и извлекать нужную информацию из массивов неструктурированных данных (внутренних и внешних источников);
• распределять поток входящих документов по департаментам и ответственным;
• усовершенствовать поисковые системы.

«Учитывая огромный рост объема неструктурированных данных, в мире присутствует большой, постоянно растущий спрос на решения в области интеллектуальной обработки информации. Это направление является неотъемлемой частью рынков ECM и ERP, текстовой аналитики, поиска. Технологии ABBYY могут быть встроены в различные информационные системы, расширяя и дополняя их уникальными возможностями извлечения, анализа и поиска необходимой информации», – отметил Максим Михайлов, cтарший вице-президент, директор департамента ABBYY Compreno.

Технологии интеллектуальной обработки информации, 2014

2012: Анонс революционной технологии Compreno

В 2012 году Abbyy представила технологию Compreno. Универсальная Семантическая Иерархия (УСИ) - ядро языка понятий - насчитывает в это время 60 тысяч элементов в универсальном разделе когнитивной модели, 80 тысяч - в русском разделе, и 90 тысяч - в английском. Ничего даже отдаленного в мире не существует.

На февраль 2012 года мировых аналогов у Compreno нет, хотя в некоторых университетах и ведутся разработки в аналогичных направления. Однако фора в 15 лет, задействованные огромные человеческие ресурсы и материальные затраты позволяют надеяться, что ABBYY таки сумеет застолбить для себя эксклюзивное место первопроходца. На руку компании играет и то обстоятельство, что последние 10 лет подавляющая масса исследований в мире велась в русле статистической модели машинного перевода.

Compreno - это полноценная, не имеющая аналогов в истории технологическая революция. Масштаб этой революции, значение ее для людей (именно для всех людей, а не только для любителей компьютеров) сопоставимы разве что с изобретением World Wide Web или электронной почты. Никак не меньше. Для наглядности можно перевести эту революцию в понятные материально-купюрные реалии: если ABBYY спокойно, без суеты коммерциализирует Compreno хотя бы в десятой части возможных ее практических применений, а затем выйдет на фондовый рынок, капитализация компании затмит всех кумиров сегодняшнего дня - от Apple, грамотно и стильно эксплуатирующего весьма и весьма посредственные в технологическом отношении решения, до Google, умудряющегося заводить в тупик охапками большую часть собственных перспективных начинаний. (Сергей Голубицкий, обозреватель "Компьютерры", февраль 2012 года [1] )

Как работает Compreno

Традиционные модели перевода

Успех обеспечил и правильный изначальный выбор направления для разработки системы автоматического перевода. В 1990-е в мире правила одна королева - Rule-Based Translation Model, классическая модель перевода, основанная на ограниченном наборе готовых правил для некоторой пары языков. Одна из проблем RBTM - в накоплении все новых и новых правил, которые в какой-то момент просто начинают конфликтовать между собой. Анализируя предложение, мы можем применить разные комплекты правил, при этом машине неведомы приоритеты. Перевод, основанный на RBTM, как правило, не озабочен полным синтаксическим анализом: вместо него предложение делится на фреймы, на которые затем интерполируют существующие в системе правила для получения перевода. RBMT системы не учитывают семантику [1] .

В начале XXI века усилиями Google мир подсел на иглу нового алгоритма перевода - так называемой статистической модели. Основа СМ - наличие обширной базы разнонаправленных переводов. Мы задаем статистическому движку предложение для перевода, он ищет в базе данных как в словаре варианты уже существующих переводов аналогичного текста и после незначительных изменений выдает вполне приличный результат.

Изменения не самые существенные. Предположим нам нужно перевести предложение «в комнате стоит красный стул», а в статистической базе уже есть переведенная фраза «в комнате стоит зеленый стол» - решение элементарно: берется уже существующий шаблон перевода и новые слова просто заменяются по словарю.

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

Все замечательно, однако, лишь до тех пор, пока дело не касается переводов в направлениях с так называемым низким покрытием (скажем, каким-нибудь, румынско-русским или тайско-венгерским).

Где брать аналоги? По словам Сергея Андреева опасность подстерегает также при уходе в предметные области на массовых направлениях, потому что параллельных текстов становится сильно меньше, чем в бытовой и разговорной тематике. Сочетание ухода в предметную область и не самого массового направления перевода приводит к слабым результатам. Скажем, IT. Казалось бы, какие сложности могут возникнуть у машинного перевода с текстом на тему информационных технологий? В самом деле - никаких, если мы занимаемся русско-английским переводом. Зато они тут же возникнут на русско-французской ниве! Статистическая база в этом направлении чрезвычайно скудная и лакуны возникают на каждом шагу.

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

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

Помимо сложностей с низкой плотностью переводов по направлениям, выпадающим из узкого мейнстрима, у СМ еще множество мелких изъянов. Например, статистическая модель совершенно убого справляется с переводами имен собственных. Многие помнят о переводе Ющенко, как Януковича, а России как Канады. Отрицание (частичка «не») - это очень сложное препятствие. Частичку «не» можно правильно позиционировать в результате лингвистического анализа текста, а СМ таковым не занимается. В результате предложения, содержащие отрицание, часто переводятся движками на статистической модели с точностью до наоборот.

Как бы там ни было, ABBYY изначально отказалась от Rule Based Translation Model и замахнулась на систему компьютерного перевода нового поколения. Надо сказать, что придумывать особо ничего не требовалось. Универсальный язык понятий существует в структурной лингвистике в виде давней и несбыточной мечты еще со времен Людвига Витгенштейна. Даже Наум Хомский в своих ранних трудах лишь углублял существующую утопию.

Универсальная Семантическая Иерархия (УСИ)

Проект Compreno исходил из трех основополагающих посылок:

• использование качественного и бескомпромиссного синтаксического анализа.

• создание универсальной когнитивной модели языка, возможность которой определяется аксиомой о том, что люди, хоть и живут в разных условиях и говорят на разных языках, однако в массе своей мыслят одинаково. Формы выражения мысли разные, а вот понятийный аппарат совпадает.

• автоматизированное корпусное дообучение - лингвистические описания верифицируются и дополняются на основании статистической обработки корпусных данных.

Исходя из этих посылок была сформулирована идея Универсальной Семантической Иерархии (УСИ), способной описывать явления от общего к частному. На составление этой иерархии у ABBYY и ушло 15 лет. На февраль 2012 года это 70 тысяч понятий в универсальной части когнитивной модели, более 80 тысяч - в русской, более 90 - в английской.

Алгоритм машинного перевода на УСИ

Алгоритм машинного перевода, основанного на УСИ, выглядит следующим образом:

• Лексический анализ текста (выделение слов, знаков препинания, цифр и прочих текстовых единиц);

• Морфологический анализ (определение грамматических характеристик лексем);

• Синтаксический анализ (установление структуры предложения);

• Семантический анализ (выявление выражаемого значения в системе языка);

• Синтез из универсальной семантической структуры предложения на выходном языке.

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

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

В УСИ предусмотрены взаимосвязи между элементами структуры, относящимися к разным классам, и эти связи также структурированы и формализированы, что позволяет выполнять многоуровневый понятийный анализ текста, также повышающий качество перевода [1] .

Меня зовут Илья Булгаков, я программист отдела извлечения информации в ABBYY. В серии из двух постов я расскажу вам наш главный секрет – как работает технология Извлечения Информации в ABBYY Compreno.

О чем это вы вообще?

Мы анализируем тексты на естественном языке с использованием технологии ABBYY Compreno. Нашей задачей является извлечение важной для заказчика информации, представленной сущностями, фактами и их атрибутами.

Онтоинженер Даня в 2014 году написал пост на Хабр

На вход системе извлечения информации поступают деревья разбора, полученные семантико-синтаксическим парсером, которые выглядят вот так:

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

Система применяет правила к разным фрагментам дерева разбора: если фрагмент удовлетворяет шаблону, то правило генерирует утверждения (например, создать объект Персона, добавить атрибут-Фамилию и т.п.). Они добавляются в «мешок утверждений», если не противоречат уже содержащимся в нём утверждениям. Когда больше ни одно правило применить нельзя, система строит RDF-граф (формат представления извлеченной информации) по утверждениям из мешка.

Сложность системе добавляет то, что шаблоны строятся для семантико-синтаксических деревьев, существует большое разнообразие возможных утверждений, правила можно писать, почти не заботясь о порядке их применения, выходной RDF-граф должен соответствовать определенной онтологии и еще много других особенностей. Но давайте обо всем по порядку.

Система извлечения информации

В работе системы можно выделить два этапа:

1. Подготовка онтологий и компиляция моделей
2. Анализ текста:
   
   • Семантико-синтаксический разбор текстов на естественном языке
   • Извлечение информации и генерация финального RDF-графа
   
   

Подготовка онтологических данных и компиляция модели

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

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

В модель попадают:

• Онтологии
• Правила извлечения информации
• Правила идентификации

Семантико-синтаксический разбор текстов

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

Что нам важно знать про парсер:

Парсер генерирует деревья семантико-синтаксических разборов предложений (по одному дереву на одно предложение). Поддеревья мы называем составляющими. Как правило, узлы дерева соответствуют словам входного текста, но бывают и исключения: иногда несколько слов группируются в одну составляющую (например, текст в кавычках), иногда появляются и нулевые узлы (вместо опущенных слов). Узлы и дуги размечены.

Пример семантического класса и лексических классов, специфичных для разных языков.

Пример восстановленного субъекта (к нему ведет стрелка розового цвета).
Онтоинженер Даня сидел и писал пост.

Снятие омонимии происходит благодаря двум факторам:

• Учитываются все ограничения, заложенные в семантическую иерархию.
  Узлы деревьев, порождаемые парсером, всегда привязаны к некоторому лексическому классу семантической иерархии. Это означает, что в процессе анализа парсер снимает лексическую многозначность.
  
• Используется статистика сочетаемости, собранная на корпусах параллельных текстов (это такие коллекции текстов, в которых тексты на одном языке идут вместе с их переводами на другой язык). Идея подхода состоит в том, что, имея двуязычный парсер, работающий над единой семантической иерархией, можно собрать качественную статистику сочетаемости на выровненных параллельных корпусах без дополнительной разметки.
  При сборе статистики учитываются только те выровненные пары предложений, для которых итоговые семантические структуры оказываются сопоставимы. Последнее означает успешность разрешения омонимии, поскольку омонимия в подавляющем числе случаев несимметрична в разных языках.
  Отсутствие необходимости дополнительной разметки позволяет использовать корпуса большого размера.
  

Слово об информационных объектах

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

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

Над объектами можно проводить следующие операции:

• Создавать
• Аннотировать фрагментами текста
• Привязывать к классам онтологии
• Заполнять атрибуты
• Связывать с составляющими с помощью механизма «якорей»

Механизм «якорей» занимает очень важное место в системе. Один информационный объект может быть, в общем случае, связан «якорями» с некоторым набором узлов семантико-синтаксических деревьев. Привязка к «якорям» позволяет повторно обращаться к объектам в правилах.

Рассмотрим пример.
Онтоинженер Даня Скоринкин написал хороший пост

Приведенное ниже правило создает персону «Даня Скоринкин» и связывает ее с двумя составляющими.

Первая часть правила (до знака => ) представляет собой шаблон на дерево разбора. В шаблоне участвуют две составляющие с семантическими классами «PERSON_BY_FIRSTNAME» и «PERSON_BY_LASTNAME» . С ними сопоставились две переменные – name и surname . Во второй части правила в первой строке создается персона P на составляющей, которая сопоставилась с переменной name . Эта составляющая связывается «якорем» с объектом автоматически. Второй строчкой Anchor(P, surname) мы явно связываем c объектом вторую составляющую, которая сопоставилась с переменной surname .

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

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

Данное правило сработает только в том случае, если к составляющей с семантическим классом «PERSON_BY_LASTNAME» был приякорен объект класса Person.

Почему данная техника важна для нас?

• Вся система выделения фактов опирается на уже извлеченные информационные объекты.
  Например, при заполнении атрибута «автор» у факта публикации, правило опирается на созданный ранее объект-персону.
  
• Техника помогает при декомпозиции правил и улучшает их поддержку.
  К примеру, одно правило может только создавать персону, а несколько других могут выделять отдельные свойства (имя, фамилия, отчество и т.п.).
  

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

Эта возможность очень важна для повышения полноты выделения фактов – выделяемые информационные объекты автоматически связываются со всеми узлами, которые парсер счел кореферентными, после чего правила, выделяющие факты, начинают «видеть» их в новых контекстах.

Ниже приведен пример на кореференцию. Анализируем текст «Вопросы любви и смерти не волновали Ипполита Матвеевича Воробьянинова, хотя этими вопросами, по роду своей службы, он ведал с 9 утра до 5 вечера ежедневно, с получасовым перерывом для завтрака».

Парсер восстанавливает семантический класс «IPPOLIT» для узла «Он». Узлы связаны кореференциальной недревесной связью (обозначена фиолетовой стрелкой).

Следующая конструкция в правилах позволяет связать якорем объект P не только с узлом, который сопоставился с переменной this, но и с теми узлами, которые связаны с ним кореференциальной связью (т.е. пройти по фиолетовым стрелкам).

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

Следующий пост, который выйдет завтра, мы сразу начнем с обсуждения того, как устроен «движок» извлечения информации и какие идеи в него заложены.

Compreno – платформа анализа и понимания текстов на естественном языке, разработанная компанией ABBYY. На ней базируется ряд продуктов, а именно: Intelligent Search, Smart Classifier и InfoExtractor. Среди сценариев их использования есть и те, что могут быть применены для решения задач в области управление корпоративным контентом.

Compreno для ECM – это попытка решить три основные задачи: умный и эффективный поиск (Intelligent Search), автоматическая классификация контента (Smart Classifier) и автоматическое извлечение структурированных данных из текстов документов (InfoExtractor).

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

Применение Compreno для поиска информации в ECM

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

По сути все поисковые сценарии – это комбинации трех составляющих: способ поиска – то, как мы формируем поисковой запрос; область поиска – это набор объектов системы к которым мы применяем запрос; ожидаемый результат – сколько и каких объектов мы хотим увидеть в результате.

Можно выделить шесть основных способов поиска:

1. Запрос по атрибутам (key – value). Например, «Тип документа = договор, Дата создания = вчера».
2. Запрос вхождения в тело документа:
   • По образцу. Когда мы ищем точную фразу с незначительными морфологическими или синтаксическими отклонениями. Например, вспоминаем, что был документ, где фигурировала фраза «ABBYY Compreno Pricing».
   • По смыслу. Когда ищутся все данные, связанные по смыслу с запросом. Например, хотим найти всю информацию, связанную с архитектурой Compreno (процесс проектирования, технические проекты, презентации и т.д.).
3. Запрос/вопрос на естественном языке:
   • Запрос. Включает в себя упоминание атрибутов со значениями и часть для поиска по вхождению. Например, «Все договоры нашей организации за 2013 год по продаже модуля «Канцелярия».
   • Вопрос. Например, «Где был описан порядок лицензирования продукта X».
4. Навигация по смысловым (онтологическим) категориям:
   • Навигация по сущностям (объектам). Например, последовательное уточнение запроса по выделенным из документов категориям «Договор», «Петров», «Москва» выдаст все договоры, заключенные Петровым или с Петровым, с упоминанием города Москва.
   • Навигация по фактам (отношениям). Например, запрос по факту «является стороной в договоре» с уточнением названия организации поможет быстро найти нужный документ.
5. Навигация по папкам. Визуальный поиск среди набора папок («Договоры» / «Договоры на закупку» / «Договоры на закупку в ООО «Буревестник»).
6. Навигация по связям с документами:
   • Поиск по формальным связям документа (договор – приложения).
   • Поиск по связям, содержащимся в тексте (договор – нормативные акты, которыми руководствуется договор).

Три области поиска:

1. Все документы системы.
2. Папка или набор папок.
3. Результаты предыдущего поиска (уточнение поиска).

И три основных категории результатов:

1. Конкретный документ (например, договор с организацией за определенную дату с определенным номером).
2. Подборка документов (например, все методические документы, связанные с управлением проектами).
3. Информация:
   • Часть документа (например, подсвеченное предложение из текста документа, где явно дается ответ на запрос)
   • Сгенерированный ответ. Ответ на вопрос может отсутствовать во всех данных системы в явном виде, но генерируется на их основе (например, как составить заявление на отпуск).

Помимо всего этого на процесс поиска влияет ряд фич , которые может поддерживать поисковой движок информационной системы:

1. Учет словоформ.
2. Учет переводов и транслитераций.
3. Исправление ошибок в тексте поискового запроса.
4. Учет синонимов.
5. Учет плотности вхождения (расстояние между словами в тексте).

Теперь посмотрим какие сценарии уже покрывается базовым функционалом среднестатистической ECM-системы.

1. Всевозможные виды атрибутивного поиска, с возможностью поиска во всем объеме данных, в определенном каталоге системы. Результат выдается в виде конкретного документа или подборки документов.
2. Навигация по всему объему данных или определенным каталогам и подборкам документов через проводник системы.
3. Поиск по связям между объектами во всем объеме данных, в каталоге, подборке (через связанные объекты и гиперссылки).
4. Полнотекстовый поиск, т.е. запрос по вхождению – образцу во всем наборе данных, в каталоге или подборке.
5. Комбинация сценариев 1 и 4.

Оценим, что нам может дать применение Compreno и Intelligent Search в частности:

1. Запросы с вхождением по смыслу.
2. Реализация поиска в результатах поиска на основе найденной в них информации (постепенное уточнение). Этот вид поиска особенно привлекателен, весьма эффективный и интуитивно понятный.
3. Навигация по смысловым категориям (онтологиям, в терминах Compreno), в т.ч. использование их при построении запроса.
4. Реализация ряда «фишек», а именно:
   • Учет словоформ (альтернатива тому, что дает MS SQL).
   • Исправление ошибок (альтернатива существующим open source реализациям).
   • Учет переводов и транслитераций.
   • Учет синонимов.
   • Учет плотности вхождения. Релевантность на основе расстояния между целевыми словами.

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

1. Не расширяется словарь синонимов. Например, КАС в нашем контексте, это «Комплексная Автоматизированная Система». Compreno этого не знает, и обеспечить это знание не представляется возможным из-за отсутствия соответствующих инструментов в поставляемом API.
2. Не расширяются виды сущностей. Существует набор доступных базовых сущностей (персона, организация и т.д.), однако среди них нет важных для предметной области СЭД понятий, например сущности «документ» (договоры, заявления).
3. Низкая релевантность при работе со смысловыми категориям (онтологиями). Например «договоры ТНК», Compreno поймет что ТНК – это организация (хотя не факт, см. п.1), но этого недостаточно, так как будут найдены все документы содержащие эти слова (сущности), а нужен только документ – договор.
4. Низкая скорость индексирования. Например, 2500 стандартных документов (docx, xlsx, pdf) индексировались несколько дней на выделенном сервере с хорошей вычислительной мощностью. Если речь пойдет об индексировании целой базы, к примеру 100 000 документов и среднее время на 1 документ – 5 минут, то это займет 8333 часа или 347(!) дней. Станция обработки, на которой проводились замеры, согласно консоли управления Compreno, имеет 3 обработчика (4 ядра процессора). По заявлению представителя ABBYY для индексации такого объема документов рекомендованная вычислительная мощность 100 ядер процессора, индексация займет 4 дня.
5. Низкая скорость поиска относительно существующих в ECM-системе механизмов.
6. Выделение онтологий нестабильно (например, «Бик» – это не организация, а «Синицын» и «Синицыну» – одно и то же лицо).

Если мы закроем глаза на описанные выше недостатки, то Compreno и Intelligent Search в частности, могут помочь в улучшении качества поиска в ECM, приблизить его к поиску «как в google». Однако это палка о двух концах, и сейчас я объясню почему.

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

Используя поиск КИС мы не хотим узнать рецепт борща или дату выхода новых «Звездных Войн», мы ищем конкретный документ или набор документов (объектов), которые обладают легко формализуемыми критериями и признаками, на основе которых и строятся поисковые запросы. Отсюда вытекает ряд особенностей, например, чрезмерное обобщение и учет ненужных синонимов может увеличить число выдаваемых по запросу документов и тем самым уменьшит такой важный для ИПС показатель как точность поиска, снизив тем самым общую релевантность результатов.

Кроме того, стоит понимать, что Intelligent Search это не компонент, который «вшивается» внутрь вашей КИС, а отдельный инфраструктурный модуль стоящий рядом. Отсюда и основные ограничения: необходимость держать отдельные сервера, медленный поиск (относительно поиска напрямую из платформы КИС), проблемы с безопасностью (учет прав доступа, маршрутизации контента между поисковым сервером и основной базой данных, полнотекстовые индексы хранятся за пределами системы), медленная индексация (в этом виновата не только описанная выше проблема, но и особенности алгоритмов анализа Compreno, они имеют большую вычислительную сложность).

Резюмируя вышеизложенное можно заключить, что ряд ограничений наверняка получится обойти при доработке и кастомизации Compreno Intelligent Search под конкретную систему, однако, это потребует дополнительных финансовых затрат, что прибавит стоимости и без того прожорливому продукту. Кроме того, решение в том виде, в котором его видели мы, явно требует оптимизации в плане скорости работы и требуемых ресурсов. Нужно понимать, что Compreno не решает критически важных и новых бизнес-задач в области поиска корпоративной информации, а лишь частично модифицирует и преображает существующие инструменты.

При этом Compreno Intelligent Search – это определенно новое слово в поисковых технологиях, и если ваша компания готова взять на себя все риски и затраты по внедрению, в будущем вы можете стать владельцем инновационной поисковой платформы.

В следующей части статьи будут рассмотрены продукты Smart Classifier и InfoExtractor, отвечающие за решение задачи интеллектуального ввода данных.

Описание Compreno, сколковского проекта ABBYY (грант — 475 млн рублей, собственные инвестиции компании более 50 млн долларов), стоит начать с реального примера ее применения — в художественной кинематографии. Это примитивный мультипликационный фильм, демонстрирующий артисту и прочим участникам съемочного процесса то, что предстоит снимать: перемещения действующих лиц, реплики, взаимодействия с другими персонажами и объектами.

Изготовить мультик дешевле, чем тратить на разъяснения дорогое съемочное время, а Compreno позволяет автоматизировать эту работу. В компьютер подаются текст сценария и перечень объектов, на выходе — готовое видео.

Как перевести ковбоя

В 1998 году, когда проект задумывался, ничто не предвещало такого применения. ABBYY, известная своими словарями и софтом для распознавания символов, решила добавить еще один продукт — машинный перевод.

Офис компании ABBYY

Фото: Евгений Дудин, Коммерсантъ

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

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

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

Чужие недостатки

Compreno — это протест против непреодолимых ограничений существующих систем машинного перевода. Одни системы основаны на алгоритмических правилах перевода для пары языков (пример — российская Promt); другие — статистические, используют готовые образцы перевода словосочетаний из так называемых параллельных (профессионально переведенных, эталонных) текстов (переводчик Google). В чистом виде оба типа встречаются редко — на практике их сочетают.

Неотъемлемые проблемы алгоритмических систем, говорит Татьяна Даниэлян (она инженер-системотехник, а в ABBYY управляет разработкой лингвистической платформы Compreno), связаны прежде всего со сложностью правил перевода. Чем подробнее и тщательнее разработчик описывает эти правила, тем больше обнаруживается исключений: алгоритм неконтролируемо ветвится. Алгоритмическая система, кроме того, — раб словарей. Чтобы выбрать при переводе слово из десятка вариантов, который дает словарь, алгоритма не придумаешь, сетует она.

А фундаментальная проблема статистических систем, по мнению разработчиков, — недостаток параллельных текстов для множества предметных областей и пар языков. Из-за этого, например, перевод с португальского на французский исполняется по схеме "португальский -> английский -> французский" с очевидной потерей смысла. Статистический перевод плохо работает и с отрицаниями. Встретив во фразе частицу "не", система вынуждена гадать, к чему именно это "не" относится: с точки зрения статистики, две фразы, отличающиеся только частицей "не", едва ли не идентичны. Похожесть фраз вообще играет со статистическими системами злые шутки: бывает, они переводят "Ющенко" как "Yanukovich": это диктуется схожестью образцов перевода из параллельных текстов. А что? Обе фамилии встречаются в окружении одних и тех же слов ("президент", "Украина", "политика" и т.д.).

Семантическая иерархия понятий

Compreno решил идти своим путем — строить независимую от конкретного языка универсальную семантическую иерархию понятий.

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

Составление такого универсального семантического дерева и описание его в лингвистических терминах — основной результат Compreno.

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

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

Школьная программа

Татьяна Даниэлян, руководитель проекта Compreno

Фото: Евгений Дудин, Коммерсантъ

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

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

Например, table — таблица и стол? Если во фразе с table связан глагол "сидеть" — стол. "Заполнять" — таблица. Compreno цепляется за смысл каждого слова, и число вариантов разбора предложения становится обозримым. Получается универсальное, не зависящее от языка представление предложения, от которого можно переходить к синтезу текста на другом языке.

Если Compreno допускает два смысловых толкования фразы, то она оказывается двусмысленной и для человека. Пример: "Мальчик положил книгу на стол, он подошел к этажерке". К этажерке мог подойти и мальчик (ногами), и стол (по стилю).

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

Машинный переводчик перевел

To have another language is to possess a second soul

Иметь другой язык — это владеть второй душой

A sheep baas, but sheep baa

Овца блеет, но овцы блеют

Оригинал: The pools do not constitute separate entities and are not directly accessible to investors

Пулы не составляют отдельные организации и не напрямую доступны для инвесторов

The biggest drop in exports in more than two years is the main reason economists expect weaker second-quarter growth

Самое большее снижение в экспорте более чем за два года является главной причиной, по которой экономисты ожидают более слабый рост на второй квартал

The time it takes to develop a program depends upon the size (and the complexity) of the components

Время, которое требуется, чтобы разработать программу, зависит от размера (и сложности) компонентов

Читайте также:

  
• Как отключить модем мтс на ноутбуке
  
• Можно ли переносить ноутбук в спящем режиме
  
• Как снять защиту с файла опен офис
  
• Перископ как смотреть трансляции с компьютера
  
• Как восстановить файлы удаленные мимо корзины