авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 | 2 || 4 | 5 |

«Национальный исследовательский университет “Высшая школа экономики” На правах рукописи Кириллов Антон ...»

-- [ Страница 3 ] --

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

Вопросами о достижении целей будем называть предложения, в которых запрашивается информация, касающаяся результатов функционирования того или иного объекта или системы. Другими словами, это вопросы, касающиеся успехов либо неудач рассматриваемых объектов или систем. В [29] такие вопросы названы вопросами о достижениях и неудачах.

Примеры вопросов о достижении целей: “Какие успехи были у сборной России по футболу в 2009 году?”, “Какие неудачи испытала компания Sun в 2010 году?”, "Каковы успехи компании Intel за 2010 год?". Из представленных примеров видно, что если подать их на вход поисковой системе в таком виде, то результаты поиска будут низкого качества и не будут содержать в себе ответов на поставленный вопрос.

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

Рисунок 3.1. Фрагмент дерева целей компании Анализ данного дерева целей, а также деревьев целей других компаний показал, что успешность компании определяется фактами достижения компанией поставленных целей. Дальнейшая детализация целей и формирование фраз-индикаторов, определяющих нахождение в тексте указания на достижение цели, продемонстрировали, что, действительно, указания на детализированные цели встречаются в электронных документах гораздо чаще, чем описание непосредственно успехов или неудач каждой конкретной компании. Рассмотрим примеры текстов, извлеченных поисковой системой, указывающих на достижение некоторых из представленных показателей:

Таблица 3.1. Примеры текстов, соответствующих целям Цели Примеры текстов Увеличивать выручку Выручка индийской компании в отчетный период увеличилась в 3,2 раза - до 31,5 млн долл.

Увеличивать доход Доход компании Nycomed в I квартале увеличился на 30 %.

Увеличивать прибыль Чистая прибыль компании ЛУКОЙЛ за первое полугодие 2006 года увеличилась на 55 процентов.

Снижать затраты Совет директоров ЛУКОЙЛа принял решение, что капитальные затраты компании в 2009 году будут снижены почти вдвое.

Применять новейшие Компания внедрила в линейку бизнес Lenovo технологии и ресурсы ноутбуков ThinkPad технологию NVIDIA Optimus.

соблюдение Производство компании «Союз-Виктан» соответствует стандартов стандартам ISO (ИСО) 14000.

Выход на новые Компания вышла на рынок WELHOME рынки инвестиционных услуг с новыми предложением.

Таким образом, чтобы обнаружить документы, содержащие в себе информацию об успехах либо неудачах компании, необходимо декомпозировать первоначальный ЕЯ-запрос на множество словосочетаний – индикаторов: ЕЯ-выражений, наличие которых в тексте документов позволяет определить соответствие этого документа первоначальному запросу. Анализ целей нескольких компаний позволил обобщить эти цели и сформировать факты, указывающие на достижение компаниями целей.

Рисунок 3.2. Графическое представление содержания базы целей В данной схеме обозначение pos соответствует тому факту, что данное событие является индикатором успешности деятельности компании, neg соответствует неудаче. Пара (+, pos) обозначает, что рост данного показателя является позитивным фактором, (-, pos) обозначает, что снижение данного показателя является позитивным фактором. На представленной схеме видно, что факторы достижения успеха имеют общую форму.

3.2. Формальная модель базы знаний для представления целей В монографиях В.А. Фомичева [22, 26, 29, 63] определен класс формальных объектов, названных концептуальными базисами (к.б.) и задающих базовые сведения о системе первичных концептуальных единиц, используемой прикладной интеллектуальной системой. Введем ряд определений для формального описания базы целей.

Определение 3.1. Упорядоченная тройка вида (B, цел, рац) называется концептуальным базисом с числовой разметкой когда B – произвольный концептуальный базис, цел и рац – два различных сорта из St(B), и выполняются следующие условия: (1) первичный информационный универсум X(B) включает подмножества Natural, Pos-rational, Z1, Z2, Numbers, где Natural – множество всех цепочек вида d1 …dn, где n = 1, и для k =1,…, n dk – цифра из множества {‘0’,’1’,…,’9’}, причем из d1 = 0 следует, что n = 1;

Pos-rational – множество всех цепочек вида bcd, где b, d Natural, c - запятая;

Z1 объединение множества Natural и множества всех цепочек вида -nb, где nb – цепочка из множества Natural;

Z2 - объединение множества Pos-rational и множества всех цепочек вида -numb, где numb – цепочка из множества Pos rational;

Numbers - объединение множеств Z1и Z2;

(2) для каждого элемента d множества Z1 типом tp(d) является сорт цел, и для каждого элемента h множества Z2 типом tp(h) является сорт рац;

(3) сорт цел является конкретизацией сорта рац для отношения общности Gen.

Пример. Множество Natural включает цепочки 123 и 4125;

множество Numbers включает, в частности, цепочки 12,78, -0,315 и –542.

Пусть произвольный расширенный 3.2. Extbs – Определение концептуальный базис (р.к.б) вида (S, Cobs, Ql), где S — произвольная аспектно-ориентированная сортовая система, размеченная Cobs — концептуально-объектная система вида (X, V, tp, F, Qf, Chr, Fgn), согласованная с S, и Ql — система кванторов и логических связок;

концептуальный базис B является семантическим ядром Extbs. Тогда концептуальной базой целей (к.б.ц.), согласованной с р.к.б Extbs, называется набор Gbase вида (B, цел, рац, событие, Goals), (3.1) где тройка (B, цел, рац) является концептуальным базисом с числовой разметкой, событие - выделенный сорт из множества St(B), и выполняются следующие условия: (1) множество Acts(B) = { y из X(B) | tp(y) = событие} не пусто и конечно;

(2) первичный информационный универсум X(B) включает такой элемент #Объект-интереса, что тип tp(#Объект-интереса) является конкретизацией базового типа [объект];

(3) X(B) включает элементы (обозначения тематических ролей) Агент и Роль2, причем tp(Агент) = {(событие, s)}, tp(Роль2) = {(событие, t)}, где s и t – сорта из St(B), причем ни один из этих сортов не является конкретизацией сорта P (сорт «смысл сообщения») или сорта событие;

(4) Goals является некоторым конечным множеством выражений СК-языка Ls(B) вида event-concept * (Агент, d1)(Роль2, d2), estimation, где event-concept принадлежит множеству Acts(B), d1 и d2 – различные элементы универсума X(B), причем какой-либо из этих элементов является символом #Объект-интереса, estimation – элемент множества Numbers, обозначающий рациональное число от -1 до 1, отличное от 0.

Пример. Множество Goals может включать цепочку поглощение-орг * (Агент, #Объект-интереса)(Роль2, нек фирма1), 1.

Данная модель позволяет учитывать факты успехов либо неудач компании.

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

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

Определение 3.3. Пусть Gbase - концептуальная база целей (к.б.ц.) вида (3.1), Morph-values – конечное множество символов, интерпретируемых как значения различных морфологических признаков (существит, глагол, прош-время, наст время, пассив-залог и т.д.). Тогда шаблоном семантической трансформации, порожденным к.б.ц. Gbase и множеством Morph-values, называется произвольный упорядоченный набор вида (sem-pattern, X, Y, Z, prop-chain), (3.2) где sem-pattern – элемент множества Goals, (X, Y, Z) – произвольная перестановка без повторений из символов #A#, #Pred#, #B#, и prop-chain – цепочка вида v1 * v2 * … * vk, где 1 k, v1, …, vk – элементы множества Morph values.

Пример. Пусть sem-pattern – цепочка поглощение-орг * (Агент, #Объект интереса)(Роль2, нек фирма1), 1. Тогда набор (sem-pattern, #A#, #Pred#, #B#, глаг * прош-время) является одним из возможных шаблонов семантической трансформации.

3.3. Анализ структуры запросов достижения целей Рассмотрим более подробно структуру и конкретные примеры входных запросов, представленные в таблице 3.3. При рассмотрении будут использованы шаблоны стем-формы, описанные в параграфе 2.6.

Таблица 3.3. Шаблоны стем-форм и примеры входов для вопросов достижения целей Шаблон стем-формы Пример {какой|каков} + … + ОИ1(сущ.) + Какие успехи были у компании Х в {иметь|{быть}+у|добиться|достигнуть} прошлом году?

+ОИ2+{[{[за|в|к]}+[прошедший|прошл Достижения X позапрошлый год ый|позапрошлый|текущий]+год} каковы основные неудачи Х в прошедшем году?

ОИ1 = успех, неудача, достижение Каких успехов добилось за X текущий год?

{какой|каков} + … + ОИ1(сущ.) + Какие неудачи были у компании Х в {иметь|{быть}+у|добиться|достигнуть} 2010?

Достижения X 11 год +ОИ2+{[{[за|в|к]}+(цифра)+{год}]} главные неудачи Х в 2009 году?

ОИ1 = успех, неудача, достижение Каких успехов добилось X к 2008?

{какой|каков} + … + ОИ1(сущ.) + Какие неудачи имела компания Х год {иметь|{быть}+у|добиться|достигнуть} назад?

успехи X 11 лет назад +ОИ2+{[{(цифра)}+год+назад]} главные успехи Х 5 лет назад ОИ1 = успех, неудача, достижение Что+[добился|достиг]+ОИ2+{[{[за|в|к] Чего добилась компания Х в }+[прошедший|прошлый|позапрошлый прошлом году?

Чего достиг холдинг X текущий год |текущий]+год} Что+[добился|достиг]+ОИ2+{[{[за|в|к] Чего достигло Х в 2009 году?

Чего добились X к 2008?

}+(цифра)+{год}]} Что+[добился|достиг]+ОИ2+{[{(цифра Чего добилась компания Х год назад?

Чего достиг X 9 лет назад )}+год+назад]} При указании временного периода путем фраз вида «... лет назад» будут использоваться числительные только до 10, исходя из предположения, что более длительную отсылку назад во времени более удобно осуществить при помощи ввода года (например, 1998 год).

3.4. Разработка алгоритма определения типа вопросов достижения целей и их объектов интереса При анализе и разборе структуры запросов достижения целей используется принцип, основанный на использовании словарей специфических слов индикаторов, описанный в параграфе 2.9. Для определения типа запроса происходит анализ каждого слова запроса на соответствие записям в словаре.

Запрос представляется в виде массива элементов, имеющих тип Расш_Слово.

Определение типа запроса происходит при помощи проверки вхождения базовой формы одного из слов запроса в словарь с элементами типа ХС.

Полный список записей находится в приложении 3. Рассмотрим записи словаря, соответствующие запросам достижения целей (Таблица 3.4):

Таблица Записи словарей, содержащие слова-участники и 3.4.

соответствующие им типы индикаторов для запросов достижения целей Тип индикатора Множество слов-участников ХС "успех","неудача","достижение", "добиваться", "достигать" ТР "иметь", "что", "у","какой", "каков", "за", "в", "к", "быть" ДОП_УК "один", "два", "три", "четыре", "пять", "шесть", "семь", "восемь", "девять", "десять" ДОП_ТР "прошедший", "прошлый", "позапрошлый", "текущий" СТ_С "что" Из соображений целостности, определение типа данного запроса может быть интегрировано в алгоритм «Опр_ТЗ», описанный в параграфе 2.8.1. Для этого необходимо дополнить список типов запросов, поступающих на вход алгоритма, типом В_ДЦ и добавить дополнительную проверку в главный цикл алгоритма. Данный фрагмент будет выглядеть следующим образом:

...

если Допуст_Типы(j) == В_ДЦ если Вхождение_слова_в_словарь( Запрос(i)::Баз_Формы, Словарь::Получить_Словарь(В_ДЦ, ХС)) Тип_Запр := В_ДЦ выход цикл кесли кесли...

Таким образом, при наличии словаря, содержащего слова-индикаторы для запросов достижения целей, происходит дополнение алгоритма «Опр_ТЗ»

возможностью определять тип запроса достижения целей.

Спецификой запросов достижения целей является присутствие указания на временной период, который интересует пользователя. Т. е. пользователя интересуют успехи, либо неудачи компании за конкретный период. Для этих целей был разработан подалгоритм «Определение_Даты», описание которого доступно в приложении 4.

Рассмотрим алгоритм получения объектов интереса запроса.

Внешняя спецификация алгоритма «Разбор_Запроса_Достижения_Целей»

Назначение: Алгоритм предназначен для разбора запроса достижения целей.

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

Вход: Запрос — массив элементов типа Расш_Слово, представляющий входной запрос;

Словарь_Доп_Слов — словарь допустимых слов-индикаторов;

Словарь_Запр_Слов — словарь незначимых слов-индикаторов, т. е. продукций пустых цепочек.

Выход: Отличит_Слово — слово-индикатор, по которому был определен тип запроса, имеет тип Расш_Слово;

ОИ — массив элементов типа Расш_Слово, представляющий объект интереса. Объект интереса может состоять из нескольких слов, поэтому все они должны быть возвращены как значимые;

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

Алгоритм «Разбор_Запроса_Достижения_Целей»

нач i := f := пока Запрос(i) nil цикл если Вхождение_Слова_В_Словарь(Запрос(i)::Баз_Формы, Словарь_Доп_Слов) Отличит_Слово := Запрос(i) j := i+ пока Запрос(j) nil цикл если ! Вхождение_Слова_В_Словарь( Запрос(j)::Баз_Формы, Словарь_Запр_Слов) И ! Вхождение_Слова_В_Словарь( Запрос(j)::Баз_Формы, Словарь_Доп_Слов) Дата := Определение_Даты(Запрос, j, В_ДЦ) если Дата nil выход ОИ(f) := Запрос(j);

f := f+ кесли;

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

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

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

указателей на присутствие упоминания того или иного факта в документе.

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

Метод порождения результирующих индикаторов.

1.По входному запросу находится информационная единица Studied-object, обо значающая объект интереса запроса.

2. По шаблону вида (3.2) строится цепочка X Y Z.

3. В цепочке X Y Z символ #A# заменяется на произвольную лексическую еди ницу, которой соответствует информационная единица Studied-object.

4. Пусть sem-pattern – цепочка вида event-concept * (Агент, d1)(Роль2, d2), es timation. Тогда в цепочке, полученной на Шаге 3, символ #Pred# заменяет ся на произвольную лексическую единицу pred-word-form, которой соответ ствует информационная единица event-concept, причем словоформа pred word-form должна обладать значениями морфологических признаков, зада ваемыми цепочкой prop-chain.

5. В цепочке, полученной на Шаге 4, символ #B# заменяется на произвольную лексическую единицу, соответствующую той из семантических единиц d и d2, которая отлична от символа #Объект-интереса в исходном шаблоне.

Пример 1. Пусть Studied-object = firm-Oracle, sem-pattern – цепочка поглощение-орг * (Агент, #Объект-интереса)(Роль2, нек фирма1), 1.

Тогда по шаблону семантической трансформации вида (sem-pattern, #A#, #Pred#, #B#, глаг * ПрошВр) в соответствии с данным алгоритмом может быть построен результирующий индикатор Oracle поглотил компания.

Пример 2. Пусть запрос W="Каковы успехи компании Oracle?". После определения типа запроса и объекта интереса как пары (успех, Oracle) можно переходить к построению расширенного множества запросов.

На основе предложенного метода был разработан алгоритм построения множества преобразованных запросов ExtSet для запросов достижения целей.

Рассмотрим внешнюю спецификацию алгоритма «Расширение_В_ДЦ», полное описание которого доступно в Приложении 4.

Внешняя спецификация алгоритма «Расширение_В_ДЦ»

Алгоритм предназначен для построения множества Назначение:

семантически преобразованных запросов ExtSet для запросов о достижении целей. Алгоритм использует подалгоритм «Получить_Факты_ДЦ», который обращается к базе знаний и производит выборку фактов для поданных на вход объекта интереса и характеристического слова запроса. В алгоритме использованы стандартные операции со строками, реализованные в практически любом языке программирования высокого уровня.

Вход: Отличит_Слово - слово-индикатор, по которому был определен тип запроса;

ОИ — массив элементов типа Расш_Слово, представляющий объект интереса;

Доп_ОИ — дополнительный значимый объект интереса, влияющий на смысл запроса.

Выход: ExtSet — множество семантически преобразованных запросов.

Внутренние переменные: Факты_ДЦ – массив для хранения извлеченных из базы фактов, представляющих собой структуру данных, содержащую текстовое поле с записью факта, поле, содержащее массив всех правил трансформации, записанных для данного факта, и поле, содержащее зависимое от факта слово (например, в словосочетании «поглощение компании» фактом является слово «поглощение», а дополнением слово «компании»). Правило_ТР – массив строк, представляющих правила трансформации, прикрепленные к конкретному факту.

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

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

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

Примеры таких вопросов: "Как изменился состав совета директоров компании X?", "Какие кадровые изменения были в компании X?", "Как изменился состав профсоюза Y?" и т.д.

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

Далее сконцентрируем внимание на запросах вида "Какие изменения были в руководстве компании Х?". Для корректного преобразования запроса к расширенному виду необходимо определить понятия, на которые декомпозируется целевое множество "руководство". Другими словами, составляющие элементы данного множества. В реальной практике данный анализ проводится инженерами знаний (экспертами предметной области) в соответствии с требованиями, предъявляемыми к семантическому анализатору.

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

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

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

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

Представляется, что ответ на любой вопрос об изменениях состава какого либо множества содержит в себе информацию о действиях с элементами рассматриваемого множества. В приложении рассматриваются дополнительные примеры для понятий "компания" и “департамент”. Таким образом, построение расширенного множества запросов основывается на информации об элементах, составляющих множество, а также о действиях, которые необходимо произвести с данными элементами для того, чтобы зафиксировать факт изменения качественного или количественного состава рассматриваемого множества. Рассмотрим пример некоторых множеств, их составляющих и действий с ними (таблица 3.7).

Таблица 3.7. Действия с составляющими элементами множеств.

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

3.7. Разработка формальной модели базы знаний для описания изменений состава множеств Представим запись о объекте "компания" и его составляющих элементах в виде графической схемы(рисунок 3.5):

Рисунок 3.5. Пример структуры базы знаний об изменениях множества вида "Компания" Под целевым множеством будем понимать множество, являющееся предметом интереса запроса, составляющий элемент множества – это те сущности, на которые декомпозируется целевое множество. Индикатор изменения – это фрагмент текста, присутствие которого в документе вместе с составляющим элементом множества говорит о том, что с целевым множеством произошло изменение. Под индикатором изменений также понимается действие, совершенное с элементом множества. Введем формальное определение базы знаний об изменениях множеств.

Определение 3.4. Пусть Extbs – произвольный расширенный концеп туальный базис (р.к.б.) вида (S, Cobs, Ql), где S — произвольная аспектно ориентированная сортовая система, Cobs — размеченная концептуально объектная система вида (X, V, tp, F, Qf, Chr, Fgn), согласованная с S, Ql — система кванторов и логических связок для сортовой системы S и концептуально-объектной системы Ct = (X, V, tp, F);

концептуальный базис B является семантическим ядром р.к.б. Extbs. Тогда базой знаний об изменениях согласованной с р.к.б. называется произвольная множеств, Extbs, упорядоченная пятерка SetsKb вида (C, Comp, fdecomp, Ind, h), где (а) C и Comp – конечные подмножества множества X(B), и для любого элемента d из C и Comp тип tp(d) начинается с символа " " (т.е. элементы множеств C и Comp интерпретируются как понятия);

(б) fdecomp – функция, ставящая в соответствие произвольному элементу из C некоторое подмножество множества Comp (данная функция интерпретируется как декомпозирующая);

(в) Ind – конечное множество произвольных символов, которые интерпретируются как индикаторы изменений (действий, совершаемых с элементами множества Comp);

(г) h – функция, ставящая в соответствие элементу из Comp подмножество индикаторов из Ind. Назовем данную функцию детерминантом индикаторов изменений для элементов целевого множества Comp.

Пример. Если C и Comp включают соответственно элементы фирма1 и отдел, и отдел – элемент множества fdecomp(фирма1), то h(отдел) = {создан, объединен, расформирован, реорганизован, разделен}.

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

Наполненная база знаний, имеющая представленную структуру, позволяет генерировать результирующие словосочетания-индикаторы, являющиеся результатом семантического преобразования поискового запроса. Рассмотрим методику данного преобразования.

3.8. Анализ структуры запросов об изменениях составов множеств Рассмотрим основные структуры входных текстов алгоритма анализа запросов об изменениях множеств, а также проиллюстрируем их примерами.

Структуры представлены как разновидности стем-формы, описанной в параграфе 2.5, которая более близка к естественному языку и использует лишь символы "{","}","[","]","|". Структура {указатель временного интервала} используется так же, как и в примерах структур текстов алгоритма анализа вопросов достижения целей, и в данном разделе не рассматривается.

изменения в} {Какие|Каковы} {были [структуре/составе] [компании|фирмы|предприятия] Х {в} {департаменте|руководстве}{указа-тель временного интервала}?

Примеры: (1) Какие изменения были в структуре компании Х в департаменте У? (2)Изменения структуры компании Х (3) Какие изменения были в структуре фирмы Х? (4) Каковы изменения структуры предприятия Х в департаменте У?

изменения {Какие|Каковы} {структурные} [затронули/коснулись/ произошли] {в} {составе/структуре} {департамента|руководства} [компании| фирмы|предприятия] Х {указатель временного интервала}?

Примеры: (1) Какие структурные изменения коснулись департамента У компании Х? (2)Какие изменения произошли в составе компании Х? (3)Какие изменения затронули состав руководства компании Х? Каковы (4) структурные изменения руководства компании Х?

изменения {Какие|Каковы} {в} [составе|структуре] {руководства| департамента} у Х{указатель {были} [компании|фирмы|предприятия] временного интервала}?

Примеры: (1) Какие изменения в составе руководства были у компании Х?

(2) Изменения структуры департамента У компании Х (3) Каковы изменения состава руководства предприятия Х?

{Какие|Каковы} изменения {были {в|у}} [компании|фирме|предприятии] Х в составе {руководства|департамента} {указатель временного интервала}?

Примеры: (1) Какие изменения у компании Х в составе департамента У? (2) Изменения компании Х в структуре руководства (3) Каковы изменения компании Х в составе департамента У?

изменилось [Что|Как] {в} [структуре|составе] [компании|фирмы| предприятия] Х временного {в} {департаменте|руководстве}{указатель интервала}?

Примеры: (1) Что изменилось в составе компании Х в департаменте У? (2) Что изменилось в структуре компании Х? (3) Как изменилась структура компании Х департамента У? (4) Как изменился состав компании Х в руководстве?

[Что|Как] изменилось {в} [составе|структуре] {руководства| департамента} у Х временного {были} [компании|фирмы|предприятия] {указатель интервала}?

Примеры: (1) Что изменилось в составе руководства предприятия Х? (2) Как изменилась структура руководства фирмы Х? (3) Что изменилось в составе департамента У компании Х? (4) Как изменился состав департамента У компании Х?

Что изменилось в [компании|фирме|предприятии] Х в [составе|структуре] {руководства|департамента} {указатель временного интервала}?

Примеры: (1)Что изменилось в компании Х в составе руководства? (2)Что изменилось в фирме Х в структуре департамента У?

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

Примером могут послужить следующие два запроса: "... изменения в департаменте разработок и внедрения компании Яндекс.

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

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

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

Таблица Записи словарей, содержащих слова-участники и 3.8.

соответствующие им типы индикаторов для запросов об изменениях состава множеств Тип индикатора Множество слов-участников ХС "изменение", "изменяться" ХС_2 "структурный", "структура", "состав" ТР "иметь", "что", "как", "у", "за", "к", "быть", "в", "какой", "каков", "касаться", "затрагивать", "происходить" ДОМ_С "компания", "департамент", "отдел", "руководство", "фирма", "предприятие" ДОП_УК "один", "два", "три", "четыре", "пять", "шесть", "семь", "восемь", "девять", "десять" ДОП_ТР "прошедший", "прошлый", "позапрошлый", "текущий" СТ_С "что","как" Из соображений целостности, определение типа данного запроса может быть интегрировано в алгоритм «Опр_ТЗ», описанный в параграфе 2.10.1. Для этого необходимо дополнить список типов запросов, поступающих на вход алгоритма, типом В_ИМ и добавить дополнительную проверку в главный цикл алгоритма. Данный фрагмент будет выглядеть так:

если Допуст_Типы(j) == В_ИМ если Вхождение_слова_в_словарь(Запрос(i)::Баз_Формы, Словарь::Получить_Словарь(В_ИМ, ХС)) Тип_Запр := В_ИМ выход цикл кесли кесли Таким образом, при наличии словаря, содержащего слова-индикаторы для запросов достижения целей, происходит дополнение алгоритма «Опр_ТЗ»

возможностью определять тип запроса об изменениях состава множеств.

Для запросов данного типа также характерно присутствие в запросе временного интервала. Пользователей интересуют изменения в составе какого либо множества за конкретный период. Для этого будет использоваться подалго ритм «Определение_Даты», описание которого доступно в Приложении 4.

Рассмотрим алгоритм получения объектов интереса запроса.

Внешняя спецификация алгоритма «Разбор_Запроса_Изменения_Множеств»

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

Вход: Запрос - массив элементов типа Расш_Слово, представляющий входной запрос;

Словарь_Доп_Слов - словарь допустимых слов-индикаторов (СИ);

Словарь_Доп_Слов_2 - словарь допустимых второстепенных СИ;

Словарь_Домен_Слов - словарь допустимых доменных СИ;

Словарь_Запр_Слов - словарь незначимых СИ, т. е. продукций пустых цепочек.

Выход: Отличит_Слово — слово-индикатор, по которому был определен тип запроса. Имеет тип Расш_Слово;

ОИ1 — массив элементов типа Расш_Слово, представляющий первый объект интереса. Объект интереса может состоять из нескольких слов, поэтому все они должны быть возвращены как значимые;

ОИ2 — массив элементов типа Расш_Слово, представляющий второй объект интереса;

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

Внутренние переменные: Объект_1_Найден — индикатор ситуации, когда первостепенный объект интереса найден;

Объект_2_Найден — индикатор ситуации, когда второстепенный объект интереса найден.

Алгоритм «Разбор_Запроса_Изменения_Множеств»

нач Объект_1_Найден := Объект_2_Найден := ложь i := f := пока Запрос(i) nil цикл если Вхождение_Слова_В_Словарь(Запрос(i)::Баз_Формы, Словарь_Доп_Слов) Отличит_Слово := Запрос(i) j := i+ пока Запрос(j) nil цикл если ! Вхождение_Слова_В_Словарь( Запрос(i)::Баз_Формы, Словарь_Запр_Слов) И ! Вхождение_Слова_В_Словарь( Запрос(i)::Баз_Формы, Словарь_Доп_Слов_2) если Объект_1_Найден И Вхождение_Слова_В_Словарь( Запрос(i)::Баз_Формы, Словарь_Домен_Слов) Объект_2_Найден := истина кесли если Вхождение_Слова_В_Словарь( Запрос(i)::Баз_Формы, Словарь_Домен_Слов) Объект_1_Найден := истина кесли Дата := Определение_Даты(Запрос, j, В_ИМ) если Дата nil выход если Объект_1_Найден ИЛИ Объект_2_Найден выход кесли если Объект_1_Найден И ! Объект_2_Найден ОИ1(f) := Запрос(j) f := f+ иначе если Объект_1_Найден И Объект_2_Найден ОИ2(s) := Запрос(j);

s:= s+ кесли кесли кесли;

j := j+ кцикл;

i := i+ кесли кцикл кон Данный алгоритм позволяет определять объекты интереса запросов об изменениях состава множеств, а также дату, относительно которой запрашивается информация.

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

Естественным первым шагом будет являться анализ поступившего на вход семантического анализатора поискового запроса W для определения его типа и объекта интереса. Определение типа запроса происходит при помощи алгоритма «Опр_ТЗ». Так, поисковый запрос W = "Какие изменения были в составе компании Газпром?" будет распознан как вопрос об изменениях состава множеств, и его объектом интереса будет являться 1 = «компания Газпром».

Элемент D, адресующий временной интервал, в данном запросе отсутствует.

После того, как определено целевое множество поискового запроса W, а также его название («Газпром»), можно приступать к генерации множества семантически преобразованных запросов, порождаемых запросом W.

Результирующие запросы формируются на основании заполненной базы знаний об изменениях множеств SetsKb вида (C, Comp, fdecomp, Ind, h). Сначала происходит поиск по базе знаний элемента 1[0] =" компания" с целью извлечения информации о составляющих элементах компании и индикаторов изменений.

Значение функции для будет следующим:

1[0] =" компания" fdecomp = {департамент, отдел, служба}, а функции h( fdecomp(1 [0]) i ) = fdecomp (1 [0]) объединен, расформирован, реорганизован, разделен}, где {создан, fdecomp ( w1 [0]) i - один из компонентов целевого множества 1, полученный при помощи функции fdecomp.

После того, как информация извлечена из базы знаний, необходимо сгенерировать цепочки вида X+ fdecomp( w1 [0]) i + h( fdecomp(1 [0]) i ) j + D, где X= 1[1], т.е. непосредственно название компании, i – это индекс элемента из fdecomp (1 [0]), а j – индекс индикатора из множества индикаторов, полученного при помощи функции h. D – опциональный параметр, указывающий на временной интервал, в рамках которого необходимо анализировать изменения в составе объекта X. Для генерации полного множества результирующих запросов ExtSet необходимо сгенерировать все возможные сочетания элементов и h( fdecomp(1 [0]) i ). Сгенерированный набор из множеств fdecomp (1 [0]) словосочетаний затем передается на вход традиционной поисковой системы.

На основе этого метода был разработан алгоритм построения множества преобразованных запросов ExtSet для запросов об изменениях состава множеств. Рассмотрим внешнюю спецификацию алгоритма «Расширение_В_ИМ», полное описание которого доступно в приложении 4.

Внешняя спецификация алгоритма «Расширение_В_ИМ»

Наначение: Алгоритм строит множество семантически преобразованных запросов ExtSet для запросов об изменениях состава множеств. Использует подалгоритм «Получить_Состав_Множества», обращающийся к базе знаний и производящий выборку составляющих элементов для поданного на вход понятия, обозначающего множество.

Вход: Отличит_Слово - слово-индикатор, по которому был определен тип запроса;

ОИ — массив элементов типа Расш_Слово, представляющий объект интереса;

ОИ2 — массив элементов типа Расш_Слово, представляющий второй объект интереса (уточняющее понятие в запросах данного типа);

Доп_ОИ — дополнительный значимый объект интереса, влияющий на смысл запроса.

Выход: ExtSet — множество семантически преобразованных запросов массив элементов, Мас_Сост_Эл – Внутренние переменные:

составляющих заданное множество, каждый элемент содержит поле, являющееся массивом индикаторов изменений (ИндИзм) для данного элемента.

Мас_Инд – промежуточный массив для хранения ИндИзм.

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

3.11.Разработка итоговой модели базы знаний для поддержки поиска Основываясь на результатах, полученных в Главе 2 и в параграфах 3.2 и 3.6, построим математическую модель базы знаний для поддержки семантического преобразования запросов и поиска.

В параграфе 2.5 был определен класс формальных объектов, называемых расширенными концептуальными базисами (р.к.б.). Каждый р.к.б. является упорядоченным набором Extbs вида (S, Cobs, Ql), где S — произвольная аспектно-ориентированная сортовая система, размеченная Cobs — концептуально-объектная система вида (X, V, tp, F, Qf, Chr, Fgn), согласованная с S, и Ql — система кванторов и логических связок для сортовой системы S и концептуально-объектной системы Ct=(X, V, tp, F).

В параграфе 3.2 была построена математическая модель концептуальной базы целей (к.б.ц.), согласованной с рассматриваемым р.к.б Extbs.

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

Базой знаний для поддержки семантического 3.5.

Определение будет называться произвольная преобразования запросов и поиска упорядоченная тройка SearchKb вида (Extbs, Gbase, SetsKb), где Extbs – произвольный расширенный концептуальный базис (р.к.б.), Gbase – произвольная концептуальная база целей, согласованная с р.к.б. Extbs, и SetsKb – произвольная база знаний об изменениях множеств, согласованная с р.к.б.

Extbs.

Серия определений 2.1 – 2.5, 3.1 – 3.5 задает математическую модель базы знаний для поддержки семантического преобразования запросов и поиска. Эта модель послужила отправной точкой для разработки в данной диссертации алгоритма семантического преобразования аспектно-ориентированных запросов, запросов о достижении цели и запросов об изменениях состава множеств.

3.12. Выводы по главе В данной главе получены следующие основные результаты:

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

Предложено математическое описание многообразия шаблонов 2.

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

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

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

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

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

Глава Программная реализация системы семантически 4.

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

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

лингвистической базы знаний, аспектно-ориентирован-ной базы знаний и подсистемы анализа и расширения запросов – AOS Engine.

Далее в главе разрабатывается итоговый алгоритм построения расширенного множества запросов для любого из рассмотренных типов и подтипов, основанный на предложенном методе.

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

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

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

Рисунок 4.1. Процесс преобразования запроса и поиска документов с точки зрения логических компонентов.

Поисковый запрос первоначально поступает на вход анализатора запросов.

В анализаторе запросов реализованы описанные в главах 2 и 3 алгоритмы определения типа и объектов интереса запроса. Для приведения слов запроса в стем-форму используется компонент стемминга, содержащий в себе логику и библиотеки для определения нормальной формы слов. На выходе из анализатора запросов создается расширенная форма запроса, содержащая тип, объекты интереса и дополнительные объекты (например, указатель временного периода).

Проанализированный запрос поступает на вход компонента семантического расширения. В зависимости от типа запроса при построении результирующего множества запросов используются различные источники информации. Для аспектно-ориентированных запросов используется компонент ЛБЗ (Лингвистическая База Знаний), позволяющий определять концептуальное окружение характеристических объектов запросов, а также компонент АОБЗ(Аспектно-Ориентированная База Знаний), предоставляющий информацию об аспектах различных понятий. Для вопросов достижения целей используется база целей, содержащая в себе информацию о декомпозиции целей объекта интереса запроса, а также правила трансформации для построения множества преобразованных запросов. Для запросов об изменениях состава множеств используется база множеств (база знаний об изменениях множеств), содержащая в себе информацию о компонентах объекта интереса запроса и индикаторы, позволяющие найти факты об их изменениях.

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

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

Рассмотрим ключевые логические компоненты и опишем их назначение в сводной таблице (Таблица 4.1).

Таблица 4.1. Логические компоненты системы и их назначение Компонент системы Назначение Анализатор запросов Определение типа запроса, определение характеристического объекта, определение объектов интереса запроса, определение дополнительных объектов запроса.

Компонент стемминга Преобразование поступившего на вход слова в массив его нормальных форм (например, для слова «прошлом» будет возвращен массив, состоящий из элементов «прошлый», «прошлое»).

Словари Извлечение слов-терминаторов различного типа из базы данных.

Компонент расширения Построение множества преобразованных запросов в запросов зависимости от выделенных типа и объектов интереса запроса.

Лингвистическая база Хранение и предоставление информации о знаний (ЛБЗ) значениях, синонимах, гипонимах и гиперонимах слов.

База целей (БЦ) Хранение и предоставление информации о целях и их значениях с точки зрения успехов либо неудач заданного объекта интереса. Хранение шаблонов семантических трансформаций для построения преобразованных запросов.


База знаний об Хранение и предоставление информации о изменениях в составах составляющих целевые множества (объекты множеств (База интереса) компонентах и индикаторах их изменений.

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

Компонент Анализ множества возвращенных поисковой ранжирования системой документов с целью их ранжирования по семантической релевантности.

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

знаний (АОБЗ) 4.1.2 Разработка компонентной архитектуры программного комплекса 4.1.2.1 Общая архитектура программного комплекса и выбор платформы реализации Предлагается выполнить реорганизацию логических компонентов с целью максимального соответствия требованиям модульности, масштабируемости и взаимозаменяемости [49, 96, 37]. Рассмотрим компонентную архитектуру программного комплекса (рисунок 4.2).

Программный комплекс получил название AOS Engine от английского Aspect-Oriented Search Engine (Аспектно-Ориентированная Поисковая Система) и состоит из трех основных подсистем: AOS Engine (Аспектно Ориентированная Поисковая Система), ЛБЗ (Лингвистическая База Знаний) и АОБЗ (Аспектно-Ориентированная База Знаний). Рассмотрим каждую из этих подсистем в отдельности.

Следует отметить, что во всех подсистемах, взаимодействующих с базами данных, будет использоваться система объектно-реляционного связывания (ORM, Object-Relational Mapping) и пул соединений. Использование ORM обусловлено сокращением времени цикла проектирование-разработка, а использование пула соединений позволяет сократить время на создание новых соединений с базой данных, что сокращает время доступа к данным.

Рисунок Диаграмма подсистем и компонентов программного 4.2.

комплекса.

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

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

В качестве источника данных для лингвистической базы знаний (ЛБЗ) была выбрана коллективно разрабатываемая база знаний Wiktionary[100], которая имеет ряд преимуществ по сравнению с традиционными решениями, такими как WordNet [50] и некоторые его разновидности [100]. Согласно [50], актуальность информации и частота ее обновлений в коллективно разрабатываемых базах знаний выше, чем в традиционных (таблица 4.2).

Таблица 4.2. Сравнение коллективно разрабатываемых (КРЛБЗ) и традиционных лингвистических баз знаний (ТЛБЗ) ТЛБЗ КРБЗ Создатели Лингвисты Волонтеры, не профессионалы Процесс создания Основан на теоретической Основан на следовании модели и доказательствах указаниям по заполнению Стоимость создания Значительная Бесплатно Актуальность Быстро устаревают Практически всегда данных актуальные Объем Ограничен бюджетом Огромный или быстро растущий Качество данных Редакторский контроль Социальный контроль сообщества Доступные языки Основные языки Многие взаимосвязанные языки Тем не менее, этот источник данных не является полностью приемлемым в силу различных ограничений как структурных, так и технологических. Это обусловлено тем, что статьи в Wiktionary хранятся в такой форме записи, которая затем обрабатывается специализированными программными компонентами, предназначенными для генерации графического веб интерфейса. Структура базы данных Wiktionary представлена на рисунке 4.3.

Рисунок 4.3. Схема БД Wiktionary.

Рассмотрим фрагмент статьи Wiktionary для слова «характеристика»

(Таблица 4.3).

Таблица 4.3. Фрагмент текста статьи Wiktionary ===Морфологические и синтаксические свойства=== {{сущ ru f ina 3a |основа=характеристик |слоги={{по слогам|ха|рак|те|ри|сти|ка}} |show-text=1}} {{морфо||характеристик||а}} ===Произношение=== {{transcriptions||}} ===Семантические свойства=== ====Значение==== # описание отличительных, характерных свойств кого-либо или чего-либо # официальный документ с отзывом о качествах и прошлой деятельности человека. {{пример|К заявлению приложите характеристику с места работы}} # ''матем., физ.'' функция, описывающая некоторое свойство объекта.

{{пример|Амплитудно-частотная характеристика показывает зависимость модуля некоторой комплекснозначной функции от частоты}} обычно мн. ч.'' технические параметры оборудования.

# ''техн., {{пример|Тактико-технические характеристики нового танка}} ====Синонимы==== # [[портрет]], [[описание]] # ====Антонимы==== # # ====Гиперонимы==== # [[описание]] # ====Гипонимы==== # # [[отзыв]], [[рекомендация]] Как видно из представленного фрагмента, документ содержит много данных, не являющихся важными при заполнении ЛБЗ. Для извлечения из данного текста необходимых фрагментов был разработан алгоритм «Разбор_Wiki_Статьи», который представлен в приложении 4. Таким образом, предусмотрена возможность обновления базы за счет повторного разбора наиболее актуальной копии базы Wiktionary.

После извлечения текста статьи из БД (значимым является поле text.oldText, а большинство полей других таблиц необходимы для управления историей страниц и пользовательской статистики) он непригоден для использования. Извлеченную статью необходимо обработать, убрав незначимые элементы. Основной информацией, хранимой в ЛБЗ и необходимой для алгоритмов расширения запросов в AOS Engine является концептуальное окружение слова (синонимы, гипонимы и гиперонимы), поэтому для хранения данной информации в предлагаемом решении используется таблица Word (рисунок 4.4).

Рисунок 4.4. Схема данных разработанной ЛБЗ Таблица Stem предназначена для хранения слов и их базовых форм. Данная информация хранится в отдельной таблице исключительно из соображений скорости доступа к ней.

Помимо непосредственно базы данных, в подсистеме представлен компонент стемминга. В силу того, что в данной диссертационной работе тема морфологии рассматривается исключительно в контексте приведения слов к базовой форме, данный компонент представляет собой «обертку» (wrapper) для внешней программы И.Сегаловича mystem[88]. В силу того, что данная программа обладает очень высоким качеством, но у нее отсутствует API для обращения из внешних программ, получение результатов ее работы производится через файловую систему, что крайне неэффективно с точки зрения производительности. Именно по этой причине результаты каждого нового обращения к компоненту стемминга сначала запрашиваются из базы данных, а затем (в случае, если они там не были обнаружены) происходит вызов программы, передача ответа пользователю и следующая за этим запись полученных данных в базу. Таким образом, количество обращений к внешней программе постоянно уменьшается.

Модуль взаимодействия с ЛБЗ представляет собой ядро подсистемы и содержит основную логику, связанную с чтением данных из базы, т. е., другими словами, предоставляет удобный API для доступа к данным.

Веб-сервис ЛБЗ предоставляет два метода для внешних клиентов: метод получения базовых форм для поданного на вход слова и метод получения концептуального окружения для поданного на вход слова. Данный компонент, по сути, является промежуточным интерфейсом к модулю взаимодействия с ЛБЗ.

4.1.2.3 Аспектно-ориентированная база знаний Основное назначение аспектно-ориентированной базы знаний (АОБЗ) заключается в хранении и предоставлении доступа к информации об аспектах понятий. Однако помимо этого база предназначена для работы инженеров по знаниям и предоставляет возможность ввода данных и сбора статистики. В АОБЗ хранятся такие объекты, как ЕЯ-запрос, соответствующие ему тип и объекты интереса, аспекты заданного понятия и примеры текстов, содержащие ответы на первоначальный запрос. Таким образом, при правильном наполнении АОБЗ можно использовать для улучшения алгоритмов анализа поисковых запросов путем машинного обучения. Система предоставляет открытый доступ с возможностью ввода данных через графический интерфейс, а также предоставляет веб-интерфейс для доступа к данным. По сути, данная подсистема является автономным веб-приложением, которое может быть использовано в любом контексте. Данное архитектурное решение, также как и в случае с ЛБЗ, обусловлено тем, что доступ к лингвистическим данным должен быть максимально открыт для сообщества.

Так как данная подсистема использовалась в учебном процессе, в ней был предусмотрен модуль отчетности, позволяющий получать отчеты в формате Microsoft Excel, содержащие информацию по введенным пользователем данным. Фрагмент отчета доступен в приложении 7.

Рассмотрим структуру базы данных, использующуюся в АОБЗ (рисунок 4.5). Так как система обладает мощным компонентом отчетности, это наложило существенный отпечаток на структуру БД, однако позволило фиксировать абсолютно любые изменения в данных, сделанные любым пользователем системы.

Кратко рассмотрим назначение таблиц. Author — таблица, представляющая учетные данные пользователя в системе. Она связана с таблицей History, хранящей историю действий пользователя. Такими действиями могут быть либо создание новой записи (Page), либо внесение изменений в существующие (Addition). Ключевыми таблицами с точки зрения хранения данных являются Question — запрос, IObject — объекты интереса, принадлежащие запросу, Aspect — аспекты, принадлежащие понятию, представляющему объект интереса и Example — пример текста, содержащего ответ на заданный вопрос.


Рисунок 4.5. Структура базы данных АОБЗ Модуль взаимодействия с АОБЗ является ядром подсистемы и содержит основную логику, связанную с чтением и записью данных в базу, т. е., другими словами, предоставляет удобный API для доступа к данным. Веб-сервис АОБЗ и модуль графического интерфейса используют API данного компонента.

Модуль графического интерфейса пользователя предоставляет графический интерфейс для работы с АОБЗ и имеет несколько экранных форм, которые представлены в приложении 7.

Веб-сервис АОБЗ предоставляет один метод для внешних клиентов: метод получения аспектов для поданного на вход слова. Данный компонент, по сути, является промежуточным интерфейсом к модулю взаимодействия с АОБЗ.

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

База знаний для поддержки поиска содержит в себе словарь слов индикаторов, базу целей и базу множеств. Структура базы знаний представлена на рисунке 4.6.

Таблица GoalFact содержит в себе информацию о фактах достижения целей и привязанные к ним шаблоны семантических трансформаций (таблица Таблица содержит информацию о TransformationRule). SetEntity рассматриваемых множествах, их компонентах (таблица SetComponent) и индикаторах изменений в составе множеств (таблица ChangeIndicator). Таблица IndicatorWord хранит в себе информацию о словах-индикаторах, являясь, по сути, словарем.

Рисунок 4.6. Структура базы знаний для поддержки поиска.

Модуль анализа и расширения поисковых запросов содержит в себе логику, реализующую разработанные алгоритмы определения типа и объектов интереса поисковых запросов, а также алгоритмы построения расширенного множества данных запросов. При работе модуль использует базу знаний для поддержки поиска, а также клиенты к веб-сервисам лингвистической базы знаний (ЛБЗ) и аспектно-ориентированной базы знаний (АОБЗ). Взаимодействие с веб сервисами происходит стандартными средствами выбранной платформы реализции.

Модуль взаимодействия с поисковой системой является независимым и может быть использован как компонент любой другой системы. В данном случае в модуле реализована логика взаимодействия с поисковой системой Яндекс посредством Яндекс.XML API. Компонент предоставляет простой интерфейс для получения результатов поисковой системы.

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

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

Рисунок 4.7. Стартовая страница AOS Engine.

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

Требования к Лингвистической Базе Знаний: (1) поддержка взаимодействия с базой данных;

(2) наличие системы ORM;

(3) поддержка пула соединений с базой данных;

(4) поддержка сетевого взаимодействия;

(5) поддержка работы с файловой системой;

(6) поддержка веб-сервисов.

Требования к Аспектно-Ориентированной Базе Знаний: (1) поддержка взаимодействия с базой данных;

(2) наличие системы ORM;

(3) поддержка пула соединений с базой данных;

(4) поддержка сетевого взаимодействия;

(5) поддержка работы с форматом Microsoft Excel;

(6) поддержка веб-сервисов;

(7) наличие веб-интерфейса.

Требования к подсистеме AOS Engine: (1) поддержка взаимодействия с базой данных;

(2) наличие системы ORM;

(3) поддержка пула соединений с базой данных;

(4) поддержка сетевого взаимодействия;

(5) поддержка взаимодействия с веб-сервисами;

(6) поддержка обработки формата XML;

(7) наличие веб-интерфейса.

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

Рассмотрим существующие решения для данной платформы, удовлетворяющие поставленным требованиям (таблица 4.4).

Таблица Соответствие программных решений предъявляемым 4.4.

требованиям Требование Решение Описание решения Взаимодействия JDBC Платформенно-независимый промышленный с базой данных стандарт взаимодействия с Java-приложений различными СУБД, реализованный в виде пакета java.sql, входящего в состав Java SE [69].

Система ORM Hibernate Библиотека для языка программирования Java, предназначенная для решения задач объектно реляционного проецирования (object-relational Данная библиотека mapping - ORM).

предоставляет лёгкий в использовании каркас для отображения объектно (фреймворк) ориентированной модели данных в традиционные реляционные базы данных [86].

Пул соединений c3p0 Простой в использовании пул соединений, с базой данных интегрированный с Hibernate [43].

Сетевое java.net.* Пакет для сетевого взаимодействия, входящий в взаимодействие стандартный комплект поставки JDK.

Работа с java.io.* Пакет для работы с файловой системой, входящий файловой в стандартный комплект поставки JDK.

системой Веб-сервисы JAX-WS Прикладной программный интерфейс языка Java для создания веб-сервисов, являющийся частью платформы предоставляет Java. JAX-WS документо-ориентированную модель сообщений и упрощает разработку веб-сервисов за счёт использования аннотаций [71].

Работа с POI Набор библиотек Apache Foundation, написанных документами на Java и предназначенных для обработки и создания файлов формата Microsoft Office, таких Microsoft Excel как Word, PowerPoint и Excel [34].

Обработка XML JDOM для Cвободная Java-реализация DOM XML, созданная с учетом особенностей языка и платформы Java. JDOM интегрируется с Document Object Model (DOM) и Simple API for XML (SAX), поддерживает XPath и XSLT [70].

Веб-интерфейс GWT Google Web Toolkit (GWT) - Java-фреймворк, который позволяет веб-разработчикам создавать Ajax-приложения на основе Java [66].

Помимо частных компонентов, необходимых для обеспечения функциональности подсистем программного комплекса, также необходимы сервер баз данных и контейнер для обработки HTTP-запросов к компонентам, предоставляющим доступ по HTTP. В качестве сервера баз данных был выбран MySQL Server [77], поскольку он является бесплатным и разрабатывается тем же производителем, что и платформа Java. Помимо этого, сервер выдерживает высокие нагрузки и поддерживает различные модели репликации. В качестве веб-контейнера был выбран Apache Tomcat[35] в силу того, что данный продукт успешно используется в промышленной эксплуатации и имеет простую настройку при больших возможностях.

В процессе разработки будет использоваться централизованный репозиторий исходного кода code.google.com с установленной системой контроля версий Git[65]. Также при разработке программного комплекса будет использоваться система автоматизированной сборки приложений Maven [33] для обеспечения большей стабильности и переносимости исходного кода.

Исходные коды подсистем Лингвистической Базы Знаний и AOS Engine доступны по адресу Исходные коды http://code.google.com/p/aosengine/.

подсистемы Аспектно-Ориентированая База Знаний доступны по адресу http://code.google.com/p/aokb/.

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

Таблица 4.5. Ссылки на исходный код подалгоритмов извлечения данных из базы.

Алгоритм Ссылка на исходный код Получение аспектов для http://code.google.com/p/aokb/source/browse/server/sr понятия c/main/java/ru/agiledev/akb/ws/AKBServiceImpl.java Получение http://code.google.com/p/aosengine/source/browse/wiki концептуального /wikiservice/src/main/java/ru/agiledev/wikiservice/Wik окружения слова, а также tionaryServiceImpl.java стемминг слова Извлечение информации http://code.google.com/p/aosengine/source/browse/core из базы целей и базы /src/main/java/ru/agiledev/aos/analyzer/QueryExtender.

множеств java Рассмотрим итоговый алгоритм анализа и расширения поисковых запросов аспектно-ориентированного типа, вопросов достижения целей и вопросов изменения состава множеств.

Внешняя спецификация алгоритма «Анализ_и_Расш_Запр»

Вход: Текст - Цепочка W Linput - входной запрос;

Словарь_Старт_Слов — словарь стартовых слов, содержащий типы запросов, которые могут начинаться с того или иного слова;

РассмТипы — массив, содержащий строки, соответствующие всем типам запросов Выход: ExtSet — множество семантически преобразованных запросов.

Внутренние переменные: Тип_Запр — тип запроса;

Допустимые_Типы — массив, содержащий строки, соответствующие типам запросов;

Отличит_Слово — слово-индикатор, по которому был определен тип запроса;

ОИ — массив элементов типа Расш_Слово, представляющий объект интереса;

ОИ2 — массив элементов типа Расш_Слово, представляющий второй объект интереса;

Доп_ОИ — дополнительный значимый объект интереса, влияющий на смысл запроса.

Алгоритм «Анализ_и_Расш_Запр»

нач ПредОбр_Запр := Первичная_Обработка_Запроса(Текст) Доп_Типы := Опр_Тип_Запр_По_СТ_С(ПредОбр_Запр(0)) Тип_Запр := nil если Доп_Типы nil то Тип_Запр := Опр_ТЗ(ПредОбр_Запр, Доп_Типы, ХС) иначе Тип_Запр := Опр_ТЗ(ПредОбр_Запр, РассмТипы, ХС) кесли если Тип_Запр == nil то выход Отличит_Слово := ОИ := ОИ2 := Доп_ОИ := nil если Тип_Запр == В_ДЦ Расширение_В_ДЦ(Отличит_Слово, ОИ, ОИ2, Доп_ОИ, ExtSet) иначе если Тип_Запр == В_ИМ Расширение_В_ИМ(Отличит_Слово, ОИ, ОИ2, Доп_ОИ, ExtSet) иначе Расширение_АО_Запр(Тип_Запр, Отличит_Слово, ОИ, ОИ2, Доп_ОИ, ExtSet) кесли кон Результаты тестирования итогового алгоритма приведены в приложении 8 и демонстрируют высокое качество работы алгоритма на достаточно большом объеме различных запросов. Ссылки на исходный код программы, реализующий представленные алгоритмы, представлены в таблице 4.6.

Таблица 4.6. Ссылки на исходный код алгоритмов Алгоритм Ссылка Определение типа http://code.google.com/p/aosengine/source/browse/core/sr запроса c/main/java/ru/agiledev/aos/analyzer/QueryAnalyzer.java Определение объектов http://code.google.com/p/aosengine/source/browse/core/sr интереса запроса c/main/java/ru/agiledev/aos/analyzer/QueryParser.java Построение http://code.google.com/p/aosengine/source/browse/core/sr семантического c/main/java/ru/agiledev/aos/analyzer/QueryExtender.java расширения запросов Ранжирование http://code.google.com/p/aosengine/source/browse/core/sr результатов c/main/java/ru/agiledev/aos/core/ResultsRanker.java Алгоритм ранжирования результатов в силу его простоты не приводится.

Алгоритм определяет релевантность следующим образом: итерируя по массиву возвращенных поисковой системой документов, алгоритм сначала определяет наличие объектов интереса в представленном системой сниппете, а затем определяет повторные вхождения одного и того же документа в выборку, используя в качестве уникального ключа URL страницы. Если было обнаружено повторное вхождение, то повышается рейтинг документа, который уже содержится в выборке. После этого полученное множество сортируется по значению данного рейтинга.

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

Таблица 4.7. URL-адреса разработанных подсистем Подсистема/Компонент URL AOS Engine www.aosengine.ru Лингвистическая База Знаний (веб-сервис) www.aosengine.ru/wikiser vice Аспектно-ориентированная база знаний (интерфейс) www.aosengine.ru/akb Аспектно-ориентированная база знаний (веб-сервис) www.aosengine.ru/akb/ws 4.3 Исследование полученных результатов Необходимо исследовать полученные результаты разработки метода преобразования поисковых запросов различных типов (аспектно ориентированные запросы, запросы о достижении целей, запросы об изменениях в составе множеств). Для этого необходимо, во-первых, провести тестирование алгоритмов определения типа, объектов интереса запроса и построения множества преобразованных запросов Во-вторых, ExtSet.

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

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

Для тестирования алгоритмов определения типа и объектов интереса поисковых запросов было выбрано множество запросов, которые принадлежат формальному языку входных запросов Linput.

Тестирование алгоритмов определения типа и объектов интереса поисковых запросов производилось методом белого ящика в автоматическом режиме при помощи библиотеки тестирования JUnit. Было сформировано множество из более чем 300 уникальных поисковых запросов различных типов, элементы которого последовательно подавались на вход алгоритмам, затем средствами фреймворка JUnit производился анализ соответствия результатов работы алгоритма ожидаемым. Из соображений компактности листинг результатов не приводится, однако множество запросов и логика тестирования доступны в исходном коде комплекса. В таблице 4.8 приведены классы, в которых производится тестирование, и их назначение.

Таблица 4.8. Ссылки на исходный код классов автоматизированного тестирования Назначение Ссылка Тестирование алгоритмов http://code.google.com/p/aosengine/source/ определения типа и объектов browse/core/src/test/java/ru/agiledev/aos/an интереса для аспектно- alyzer/QueryAnalyzerTest.java ориентированных запросов.

Тестирование алгоритмов http://code.google.com/p/aosengine/source/ определения типа и объектов browse/core/src/test/java/ru/agiledev/aos/an интереса для запросов о достижении alyzer/QueryParserTest.java целей и запросов об изменении состава множеств.

Примеры результатов работы алгоритмов определения типа и объектов интереса запросов приведены в таблице 4.9.

Таблица 4.9. Примеры результатов работы алгоритмов определения типа и объектов интереса поисковых запросов.

Запрос Результат работы алгоритма Каких успехов добилось Query type: GOALS_DESCRIPTION Vimeo к 2008? Distinctive object: успехов Object of interest 1: vimeo Object of interest 2: не определен Additional object: не определен Date object: Каковы основные Query type: GOALS_DESCRIPTION неудачи в Distinctive object: неудачи Google прошедшем году? Object of interest 1: google Object of interest 2: не определен Additional object: не определен Date object: 2011 год Какие изменения Query type: SETS_CHANGES_DESCRIPTION затронули состав Distinctive object: изменения руководства компании Object of interest 1: руководство Неоторг в 2009 году ? Object of interest 2: компания неоторг Additional object: не определен Date object: 2009 год Какие структурные Query type: SETS_CHANGES_DESCRIPTION изменения коснулись Distinctive object: изменения департамента Object of interest 1: департамент проектирования и проектирования и разработки разработки компании Object of interest 2: компания luxoft в позапрошлом Additional object: не определен Luxoft году? Date object: Какой основной класс Query type: CORRESPONDS_TO_DESCRIPTION химических элементов Distinctive object: класс представляет хром? Object of interest 1: хром Object of interest 2: не определен Additional object: химических элементов Date object: не определен Как в металлургии в Query type: USAGE_DESCRIPTION основном применяется Distinctive object: применяется углерод? Object of interest 1: углерод Object of interest 2: не определен Additional object: металлургии Date object: не определен Какие же все-таки Query type: DIFFERENCES_DESCRIPTION различия есть у сервера и Distinctive object: несоответствия мейнфрейма? Object of interest 1: сервера Object of interest 2: мейнфрейма Additional object: не определен Date object: не определен Результаты тестирования алгоритмов определения типа и объектов интереса поисковых запросов показали их высокую устойчивость к измененному порядку слов в запросах и возможность манипулировать результатами работы алгоритмов без внесения изменений в их логику. Так как анализ запросов происходит на основании словарей, содержащих стоп-слова, то результаты работы можно корректировать, внося изменения в базу данных и без вмешательства в логику работы алгоритма. Алгоритмы используют большое количество подалгоритмов, покрывающих различные ситуации, связанные с особенностями структуры и порядком слов первоначальных запросов.

Для проведения исследования в аспектно-ориентированную базу знаний была внесена информация, позволяющая проводить расширение поисковых запросов для понятий «компьютер», «телефон» и «телевизор». В базу целей была внесена информация о достижении успехов и неудач для понятия а также внесены различные шаблоны семантических «компания», трансформаций. В базу множеств была внесена информация для понятий «компания», «руководство» и «департамент». Листинг внесенных данных доступен в приложении 8.

Алгоритмы построения множества сфокусированных запросов извлекают данные из баз знаний и комбинируют их с полученными на этапе анализа результатами. Тестирование данных алгоритмов проводилось в полу автоматическом режиме методом белого ящика. В силу большого объема результаты не приводятся, однако исходный код класса, в котором реализовано тестирование, доступен по адресу http://code.google.com/p/aosengine/source/browse/core/src/test/java/ru/agiledev/aos/ analyzer/QueryExtenderTest.java.

Анализ работоспособности программного комплекса проводился следующим образом: были выбраны наиболее типичные представители поисковых запросов различных типов и поданы на вход разработанного комплекса. Первые 10 возвращенных документов анализируются на предмет наличия в них детализаций, выполненных в соответствии с разработанным методом преобразования. Если в документе содержится какое-либо количество детализаций, то он признается условно релевантным. В таблице 4.10 приведен пример результатов по запросу каждого из типов.

Таблица 4.10. Количество условно релевантных документов по различным запросам № Запрос Документы Как работает телефон Samsung Galaxy S?

1 Каковы характеристики компьютера Lenovo W500?

2 Какая структура у телевизора Philips?

3 функции телефона Google Nexus S?

4 для чего предназначены компьютеры IBM?



Pages:     | 1 | 2 || 4 | 5 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.