CC BY
77
МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «ИННОВАЦИОННАЯ НАУКА»
№12/2015
2410-6070
материалами, качество исполнения обязательств подрядчиками. В процессе анализа оцениваются предельные значения факторов риска. В целом, анализ чувствительности помогает выявить факторы, оказывающие максимальное влияние на результаты проекта, и выбрать наиболее устойчивый к рискам вариант реализации проекта [1]. Однако в данной методике не подвергается анализу корреляционная взаимосвязь, а также взаимозависимость между показателями и не исследуется возможность принятия альтернативных решений.
С помощью анализа вероятностного распределения доходности можно проанализировать риск с учетом фактора времени, но есть и отрицательная сторона - субъективность полученных значений доходности и вероятностей их осуществления.
Имитационная модель позволяет анализировать, подвергать оценке варианты принимаемого решения, а также одновременно учитывать несколько факторов риска. Слабой стороной данной методики является то, что в рисковой ситуации сложно найти альтернативные пути решения, а если анализу подвергается ситуация, которая не имеет аналогов, то применять данную методику затруднительно.
Посредством методики оценки риска на основе экспертного метода, а
также анализа качества кредита можно найти самые существенные риски и средние вероятности их наступления, но полученные результаты будут носить субъективный характер.
Методика на основе комплексного показателя риска дает возможность учесть наиболее важные факторы всех сторон производственной деятельности предприятия, позволяет проанализировать влияние факторных показателей на результирующий в их взаимозависимости и определить группы факторов, наиболее влияющие на степень риска. Недостаток данной методики в отраслевой применяемости.
Благодаря модели, основанной на применении цепей Маркова можно определить поведение производственной системы в любой период, отдаленный от начального. Минусом являются математические трудности при построении переходной матрицы при анализе экономических объектов, а также сложный подбор достоверных сведений [3, с.12].
Таким образом, в результате строительства объектов возникают строительные риски, которые можно разделить на внешние и внутренние. Поскольку внешние риски не поддаются воздействию, основное внимание направлено на управление внутренними рисками. Для оценки рисков в строительстве, используют различные методики. Однако, применяя какую-либо методику, всегда надо учитывать и ее отрицательные стороны.
Список использованной литературы:
1. Кошелев В.А., Сосунова Л.А. Анализ рисков в жилищном строительстве: методы и инструменты / / Российское предпринимательство. 2014. № 3(249). С. 34-41
2. Грачева М.В. Риск-анализ инвестиционного проекта. — М.: ЮНИТИ ДАНА, 2001. — 351 с.
3. Шульженко С.Н. Формирование комплексных строительных программ в вероятностных условиях градостроительства. - М.: Тульский полиграфист, 2009. - 139 с.
© Шнырова А.И., 2015
УДК 004.62
Д.А.Щербаков,
аспирант, НГТУ им.Р.Е.Алексеева, г. Нижний Новгород, Российская Федерация, dm [email protected]
СИНТЕЗ И РАНЖИРОВАНИЕ ОТВЕТОВ В ПОИСКОВЫХ СИСТЕМАХ ТИПА ВОПРОС-ОТВЕТ, ОСНОВАННЫХ НА ОНТОЛОГИЧЕСКОЙ РЕКУРРЕНТНОЙ СТРУКТУРЕ СВЯЗНЫХ ДАННЫХ
Аннотация
В данной работе представлен алгоритм синтеза и ранжирования ответов в поисковых системах типа вопрос-ответ (ВО). Рассмотрены проблемы синтеза ответов с приведенными решениями и инструментами.
153
МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «ИННОВАЦИОННАЯ НАУКА» №12/2015 ISSN 2410-6070
Так же представлен архитектурный блок поиска кандидатов в ВО системах, основанных на онтологической рекуррентной структуре данных.
Ключевые слова
Информационный поиск, поисковые системы, Word2Vec, онтология, RDF
Введение. Задача поисковой системы типа вопрос-ответ - предоставить пользователю возможное решение, именуемое "ответом", а не контекст, в котором найдено совпадение по ключевой фрезе (что является отличительной чертой классических поисковых систем, таких как Yandex, Google, Yahoo и прочих). Данная специфика работы накладывает ряд ограничений как на структуру данных, так и на алгоритмы синтеза ответов. Инвертированный индекс такой поисковой системы должен содержать множество параметров, которые характеризуют данные не только адресом извлечения, но и рядом коэффициентов: контекст цитирования (тематика сущности, темпоральные признаки), рекуррентные пути отношения в контексте прилегающих сущностей (как ключевая сущность связана с прилегающими), свойства отношений между сущностями, а также ряд других признаков. Такие данные обладают онтологической структурой, в которой каждые последующие в цепочки связности зависят от предыдущих (прилегающих). Описание данной структуры можно найти в [1], а методы извлечения и наполнения такими данными в [2].
На основе представленной структуры необходимо производить поиск пользовательского запроса. Качественная поисковая система типа вопрос-ответ должна предоставлять ответ даже в том случае, когда он отсутствует в явном виде в инвертированном индексе системы (при условии наличия необходимого объема уточняющих данных, по которым можно сделать гипотезы и синтезировать ответ). Ответ должен иметь отношение к определенном контексту: если контекст пользовательского запроса является технической тематикой, то и поиск ответа должен быть произведен в кластерах технической тематики (и в максимально близких прилегающих кластерах, но с меньшим приоритетом).
Так же, при решении задачи поиска ответа, необходимо произвести анализ пользовательского запроса. Полученные данные анализа будут в дальнейшем использованы для параметризации алгоритма поиска.
На основании всего вышесказанного, можно предположить, что при проектировании поисковых систем типа вопрос-ответ, необходимо решить как ряд технических, так и ряд математических задач. Далее будут приведены методы их решения, а так же архитектура поисковой системы, с акцентом на основные представленные подзадачи.
1. Анализ пользовательских запросов. Для поиска ответа на вопрос или контекста данных в информационной системе пользователь формулирует цель на естественном языке. Пример запроса в поисковой системе типа вопрос-ответ может быть следующим: "Какие компании используют в своих разработках технологию защиты данных Adobe Primetime?". Прежде чем осуществлять поиск, необходимо проанализировать сам "запрос" и извлечь из него ключевую информацию. Основные категории информации, которые требуются для поиска ответа, рассматриваются ниже.
1.1 Центральная и ближайшие к ней категории принадлежности пользовательского запрос. На российском телевидении существует передача "Своя игра", в которой игроки отвечают на вопросы по выбранной категории. Такие категории существенно сужают перечень вопросов и относят ответы к заданному контексту. В поисковой системе данный принцип так же соблюдается, т.к. их база знаний содержит большой объемом информации. Осуществлять последовательный анализ всех данных от первой позиции до последней является нерациональным подходом: требуются значительные вычислительные мощности и, как следствие, это требует значительное время на выполнение. Анализ всего корпуса данных так же приводит к синтезу ошибочного ответа, который может быть связан с синонимией (в том числе при близком и коротком контексте). Соответственно, сужение области данных приводит как к повышению производительности системы, так и к минимизации ложных кандидатов на ответы.
В поисковых системах принуждать выбирать тематику запроса не является "дружественным" отношением к пользователю такой системы. Тематику можно определить основываясь на данных в запросе и имеющейся базе знаний. Для этого необходимо представить запрос в виде вектора и рассчитать косинусное расстояние [3, с.137-141] между вектором запроса и векторами центров кластеров в базе знаний (см.формулу 1). При помощи такого подхода дальнейший анализ данных для поиска ответа сокращается с N кластеров до
МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «ИННОВАЦИОННАЯ НАУКА» №12/2015 ISSN 2410-6070
одного главного (с минимальным косинусным расстоянием) и ограниченным множеством прилегающих к главному кластеру.
score(d,q) = , (1)
4 ||V(q)||||V(d)||
где V(d) является вектором документа, а V(q) - вектором пользовательского запроса. Числитель представляет скалярное произведение векторов, а знаменатель - произведение евклидовых норм. Данная формула позволяет компенсировать влияние длин документа и запроса.
Из векторов необходимо убрать "стоп слова" и привести каждый токен к базовой форме (произвести лемматизацию).
1.2 Извлечение "предмета" из пользовательского запроса. Пользователь, формулирующий запрос на естественном языке, преследует цель: получить ответ по заданным критериям для описанной "идеи" или действующего субъекта в запросе. Такой субъект является смысловым центром запроса. В приведенном выше запросе таким центром является сущность "компании". Непосредственно о компаниях формулируется вопрос начинающийся словами "какие компании". Из данного анализа можно сделать ряд выводов, которые позволят фильтровать кандидатов на потенциальные ответы: типы сущностей (ответы) должны быть именованными сущностями, имеющие значение типа - компания. Т.е. в базе знаний должен быть триплет типа: <раШ/ИмяКомпании> :является :<раШ/компанией>. Соответственно, поиск ответа необходимо начинать от смежных сущностей с данным триплетом (см.раздел "Поиск приоритетных кандидатов" для дальнейшего алгоритма поиска). "Предмет" запроса в большинстве случаев располагается в начале пользовательского запроса в непосредственной близости с вопросительным местоимением.
1.3 Определение типа ответов. Тип ответов основывается на двух параметрах: "предмете" запроса (см. предыдущий раздел) и ряде морфологических признаков вопросительного местоимения. Примеры вопросительных местоимений: что, где, когда, почему и т.д. В приведенном выше примере используется вопросительное местоимение "какие". Результаты анализа данной сущности предоставляет информацию о типе ответа: число и род. Данные атрибуты являются важными признаками для дальнейшего анализа и фильтрации потенциальных кандидатов. Ввиду того, что количество данных вопросительных местоимений мало, то оптимальным методом хранения признаков, которые накладывают ограничения на тип ответа является хранение таблицы с тремя полями: идентификатор местоимения, род, число.
1.4 Определение частей речи, числа, рода ключевых сущностей. Определить часть речи можно при
помощи инструмента разметки токенов в заданном контексте данных (в нашем случае в пользовательском
запросе). Одним из оптимальных инструментов для этих целей является TreeTagger [4][5]. Данный
инструмент позволяет как привести слово к базовой словоформе, так и получить служебную информацию
по каждому слову в контексте (часть речи, тип лексикона, род, числительное, одушевленное/неодушевленное
и др.). Пример разбора приведенного выше пользовательского запроса приведен на рисунке 1:
[ User ]$ echo 'Какие компании используют и своих разработках технологию защиты данных Adobe Primetime?' | cmd/tree-tagger-russian reading parameters ... tagging...
Какие Р—pna какой
компании Ncfpnn компания
используют Vmip3p-a-c использовать
в Sp-1 в
Своих P—pla СВОЙ
разработках Ncfpln разработка
технологию Ncfsan технология
защиты Ncfsgn защита
данных Ncmpgn данные
Adobe ■ adobe
Primetime - <unknown>
? SENT ?
finished.
Рисунок 1 - разбор пользовательского запроса инструментом TreeTagger для русского языка
МЕЖДУНАРОДНЫЙ НАУЧНЫЙ ЖУРНАЛ «ИННОВАЦИОННАЯ НАУКА» №12/2015 ISSN 2410-6070
Данный разбор был осуществлен при помощи модели специфичной для русского языка, соответственно, английские слова на были размечены. Разметку английских слов можно произвести, сделав разбор на модели специфичной для английского языка отдельно.
На данном этапе анализа пользовательского запроса важнейшей информацией для последующего поиска ответа являются атрибуты токенов "какие" и "компании". На основе полученных данных можно предположить, что ответом может являться список компаний (т.е. более одной), в котором каждый элемент ответа является женского рода (что по сути очевидно из атрибутов токена "компани(и/я)") и единственного числа. Инструмент TreeTagger так же можно использовать для нормализации данных в базе знаний и пользовательского запроса (приведение слов к базовой словоформе и фильтрации токенов, ненесущих смысловой нагрузки, по частям речи).
1.5 Моделирование триплетов запроса. Для эффективного поиска кандидатов на пользовательский запрос необходимо смоделировать триплеты на основе запроса. Такой подход необходим для сохранения однотипной структуры базы знаний и запроса к базе. Смоделированный список триплетов имеет входную точку от "предмета" запроса. Другие параметры анализа, разобранные выше, используются в конце процесса поиска для фильтрации (см. раздел "Архитектура"). На первом этапе моделирования строятся представленные ниже рекуррентные триплеты:
<компания> :использует [ "Adobe Primetime" :г.ле "в_своих_разработках" ] "Adobe Primetime" :являетея "технология защиты данных" Рисунок 2 - первый этап моделирования триплетов на основе пользовательского запроса
Данные триплеты можно нормализовать, с учетом краткой онтологии предикатов:
^ ' " techiAdobePrimetime context:i7ie "в_своих_ра1работках" ]
Рисунок 3 - нормализованные триплеты
Поиск по таким триплетам в базе знаний позволяет осуществить ранжирование потенциальных кандидатов с учетом их типа и контекста.
2. Поиск приоритетных кандидатов. Поиск кандидатов осуществляется в несколько этапов и сопровождается рядом требованием к структуре базы знаний.
2.1 Устранение дубликатов из базы знаний. Источники, которые используются для наполнения базы знаний, могут содержать близкие контексты. В ряде случаев полностью идентичные. Например, в двух разных источниках может быть представлена информация о одних и тех же сущностях. Если эти источники имеют разную структуру описания, то они являются приемлемыми кандидатами для наполнения базы знаний, иначе либо оба источника, либо один из них трактуется как плагиат, а следовательно, нет необходимости индексировать все плагиат-источники. С целью нормализации индекса базы знаний необходимо нормализовать источники данных, исключив данные коллизии плагиата. Оптимальный метод исключения плагиата, основанный на медоидной мере сходства, применительно к поисковым системам, изложен в [6].
2.2 Синонимия кандидатов. Одним из подходов к увеличению шансов на успешный поиск кандидатов является моделирование синонимов слов в пользовательском запросе. Например, слово "компания" имеет синоним "организация", а "данные" - "информация". Моделировать список синонимов можно автоматически на основе данных WordNet [7] и Word2Vec [8]. Последний, в свою очередь, позволяет моделировать не жесткие (лингвистические) синонимы, а контекстные, т.е. такие слова, которыми можно было бы заменить в таком же контексте, не теряя смысл.
2.3 Автоматический перевод на другие языки. Описываемый подход поиска ответов, а также все выше разобранные проблемы и методы справедливы исключительно для онтологической поисковой системы типа вопрос-ответ. Все сущности в базе знаний такой системы обладают иерархической структурой предикатов. Например, предикат "компания" может иметь структуру <рус/бизнес/коммерция/компания>.
Начало иерархии такого пути содержит идентификатор языка. Изменив идентификатор "рус", на "еп", путь должен сохраниться, а язык измениться. Таким образом, онтологическая структура данных поисковой системы может автоматически переключаться между языковыми контекстами и производить поиск на других языках с минимальными модификациями в реализацию.
2.4 Регулирование полноты и точности потенциальных кандидатов. При увеличении полноты системы (повышение количества и вероятности поиска нужного кандидата) снижается точность выборки (в списке кандидатов могут появляться шумовые ответы). При снижении полноты - точность увеличивается, однако, результирующий список кандидатов может не включать нужных кандидатов. Баланс между полнотой и точностью можно оценить и подсчитать при помощи F-меры[9]:
2 Precision • Recall F = (р +1)-
(2)
Р • Precision + Recall
где Precision - точность, а Recall - полнота. В зависимости от задачи, F-мера может смещаться в сторону полноты (в находится в диапазоне [0;1)), или точности (при приоритетности обоих показателей в принимает значение равное 1).
Точность ответа напрямую зависит от количества включенных синонимов в результирующий поиск, а также переключения на контексты других языков. Т.е. при исключении синонимов пользовательского запроса и устранении переключения на другие языковые контексты повышается точность кандидатов, и наоборот: включение в алгоритм поиска синонимов и возможности переключения на другие языковые контексты повышает полноту и снижает точность кандидатов.
2.5 Алгоритм поиска. При наличии нормализованного пользовательского запроса (в соответствии с
пунктами выше) производится первый этап поиска потенциальных кандидатов на основе статистических
данных о часто цитируемых указанных в запросе сущностях. Для этих целей применяем Word2Vec,
передавая в качестве параметров ключевые предикаты из смоделированных триплетов (adobe primetime). В
качестве усложнения примера используем так же предикат "технология_защиты_данных" с переводом на
английский язык и с учетом синонимии. Результатом такой операции является токен DRM (аббревиатура
технологии защиты данных). Пример поиска по данным предикатам приведен ниже на рисунке 4:
Enter word or sentence (EXIT to break): drm adobe primetime Word: drm Position in vocabulary: 451342 Word: adobe Position in vocabulary: 56457 Word: primetime Position in vocabulary: 26901 Word Cosine distance
microsoft
windows_xp
macintosh
adobe photoshop
autüdesk
mozilla
matlab
unix
precio microsoft autodeskinventor precio adohc openoffiee.org windows vista api
microsoft_ofiice
cs3 cs4
buy_p hoto shop cs5 frccbsd
photoshop_cs4 adobc_cs4 buylightroom buy_cubase photos li op
0.676496 0.668915 0.667122 0.662124 0.654275 0.653597 0.650620 0.645056 0.643696 0.642958 0.642761 0.637899 0.636556 0.636273 0.636048 0.629608 0.629184 0.627944 0.626810 0.626640 0.625126 0.624370 0.624213 0.623754
Рисунок 4 - результат поиска при помощи Word2Vec по токенам "drm", "adobe", "primetime"
Данный поиск был произведен, используя тренированную выборку сущностей Google-News, которая содержит индекс трех миллионов слов и фраз. В онтологических поисковых системах типа вопрос-ответ необходимо обучить данную модель на основе нормализованной базы знаний триплетов. Это позволит на основе разделенных контекстов получить более точные кандидаты. Результат такого первичного поиска необходимо отфильтровать не только по косинусному расстоянию, но и по атрибутам описанным в пунктах "Определение типа ответов" и "Определение частей речи, числа, рода ключевых сущностей". Т.е. идеальный кандидат должен как минимум иметь тип "компания". Таким условиям соответствуют сущности: microsoft (которая использует adobe primetime в своей технологии SilverLight), autodesk и mozilla (которая использует данную технологию в своих плагинах для браузера). В результате, в качестве ответа имеем список трех потенциальных кандидатов, которые отсортированы на основе косинусного расстояния (с учетом контекста цитирования в СМИ) и отфильтрованны из промежуточных результатов на основе рассмотренных в предыдущих пунктах критериев.
3. Архитектура. На рисунке 5 представлен архитектурный блок той части системы, который отвечает за анализ пользовательского запроса и поиска потенциальных кандидатов.
[ I
Рисунок 5 - архитектурный блок поиска кандидатов
Блок "Raw query" является началом анализа и первоначальным пользовательским запросом без обработки. На основе данного блока система выполняет первоначальный анализ запроса на предмет разметки инструментом TreeTagger, результаты которого будут использоваться для фильтрации промежуточного вектора кандидатов (блок "Raw vector result"). Итоги данного анализа сохраняются в блок системы "Filter model". Другой выходной точкой "Raw query" является блок "Normalized query". Это блок содержит нормализованный пользовательский запрос: удаление "стоп-слов" и привидение токенов к базовой словоформе. Далее, в зависимости от баланса полноты и точности начинается либо синтез триплетов пользовательского запроса (блок "Query triplets"), либо моделирование схожих запросов (расширение контекста) за счет синонимичных ключевых слов/фраз и перевода на другие языки (см.разделы "Синонимия кандидатов" и "Автоматический перевод на другие языки"), блоки "Syn-ext query" (синонимия) и "Lan-ext query" (онтологический перевод). Затем, при успешном моделировании триплетов осуществляется процесс поиска (блок "Word2Vec") на основе обученной модели (блок "Pre-trained entities vector") по базе знаний поисковой системы (блок "Knowledge db"), содержащей триплеты. Блок "Raw vector result" является промежуточным вектором кандидатов (иллюстрированный на рисунке 4). При помощи данных "Filter model"
МЕЖДУНАРОД НЫЙ НАУЧНЫЙ ЖУРНАЛ «ИННОВАЦИОННАЯ НАУКА» №12/2015 ISSN 2410-6070
осуществляем фильтрацию промежуточных кандидатов, результатом чего является блок "Final vector result". В случае необходимости уточнения запроса, на основе полученных данных или рекуррентных запросов (в них задается вопрос о нескольких контекстах, в которых каждый последующий связан с предыдущим), осуществляется рекурсивный метод поиска, следуя от блока "Final vector result" в начало - "Raw query".
Итоги. Поисковые системы типа вопрос-ответ имеют специфику (в сравнении с традиционными индексными системами), которая отражается в требованиях к структуре хранения данных, анализе пользовательского запроса и последующего поиска кандидатов. В данном исследовании был рассмотрен ряд проблем, которые необходимо решить при проектировании таких поисковых систем: обработка запросов, моделирование триплетов, поиск смежных кластеров, разделение контекстов, включение синонимичности терминов и автоматический онтологический перевод. Приведен пример пользовательского запроса и детально проанали-зирован. Так же были провидены примеры инструментов для анализа, первичного поиска кандидатов и подход к фильтрации промежуточного вектора кандидатов. Первичное ранжирование кандидатов осуществляется на основе косинусного расстояния. Так же приведен архитектурный блок поиска потенциальных кандидатов, который удовлетворяет потребности поиска как одноконтекстных пользовательских запросов, так и рекуррентных запросов (множественные зависимые контексты). Само исследование строится на применении исключительно онтологических поисковых систем типа вопрос-ответ. Предоставлены ссылки на зависимые исследования, более детально определяющие как структуру онтологической поисковой системы, так и подходы к ее наполнению.
Список используемой литературы:
1. Щербаков Д.А. "Онтологические связные данные в поисковых системах типа вопрос-ответ" // Инновационная наука, №11 (часть 2 из 3), 2015. - С. 140-143
2. Щербаков Д.А. "Методы вероятностного определения связей между именованными сущностями в текстовых данных" // Системы управления и информационные технологии, №3.1 (61), 2015. - С. 186-190
3. Маннинг К.Д. "Введение в информационный поиск" // Прибхакар Рагхаван, Хайнрих Шютце / М.: ООО "И.Д.Вильямс", 2011. - 528 с.
4. TreeTagger, http://www.cis.uni-muenchen.de/~schmid/tools/TreeTagger
5. Russian TreeTagger resource, https://nlpub.ru/TreeTagger
6. Щербаков Д.А. "Метод минимизации времени на поиск «почти дубликатов» на основе медоидного радиуса в кластере" // Ширяев М.В. / Системы управления и информационные технологии, №4(62), 2015. - С. 51-55
7. WordNet, http://wordnet.princeton.edu
8. Word2Vec, https://code.google.com/pZword2vec
9. Nan Ye. "Optimizing F-measure: A Tale of Two Approaches" // Kian Ming A. Chai, Wee Sun Lee, Hai Leong Chieu / Appearing in Proceedings of the 29 th International Conference on Machine Learning, Edinburgh, Scotland, UK, 2012
© Щербаков Д.А., 2015
