Abstract (English):
The article considers an approach that facilitates the improvement of the transfer, storage and retrieval of knowledge in the field of user support in IT departments. The proposed approach is based on the integration of the case-based reasoning approach and the ontology. The description of the main concepts of ontology is presented. A Precedent class structure is proposed that allows you to enter information about cases in the field of IT-consulting, as well as to establish a relation with the ontology of the application domain. Instances of the Precedent class are specific cases of consulting users of the IT departments. The method proposed assesses the closeness of cases to each other by means of the semantic closeness of ontology concepts associated with cases, based on determination of weighted associative relations from the cases to the ontology concepts. The approach can be used for retrieving cases taking into account their semantic closeness.

Keywords:
decision support system, precedent, knowledge retrieval, ontology, knowledge management

Введение В настоящее время информационные технологии являются жизненно важной частью любой компании и играют значительную роль в ее функционировании. В связи с частыми изменениями законодательства, быстрым появлением новых интерфейсов и сервисов сотрудники организаций испытывают проблемы с использованием программных продуктов. Для помощи в решении данных проблем традиционно используются консультанты-аналитики - сотрудники ИТ-отделов компаний, занятые специальным консультированием в области ИТ-поддержки программных продуктов. В ходе ежедневного консультирования пользователей задача консультанта-аналитика сводится к идентификации вопроса от пользователя, анализу наработанной базы знаний и последующему формулированию варианта ответа пользователю. Вопросы, которые поступают от пользователей к консультантам-аналитикам, можно условно разделить на следующие группы: - простые вопросы - вопросы, на которые при наличии определенного опыта работы с системой (около года) консультант может отвечать сразу. Затраты времени на решение такого вопроса составляют от 15 до 25 минут; - вопросы средней сложности - вопросы, которые требуют анализа сложившейся ситуации, обращения к системе, анализа работы пользователя, восстановления последовательности действий. Затраты времени на решение вопроса составляют от 25 до 60 минут; - сложные вопросы - вопросы, которые требуют детальной проработки, анализа сложившейся ситуации. Не исключено, что решением вопроса в данном случае будет доработка системы программистами. Затраты времени на решение вопроса составляют от 60 до 120 минут; - технические задания (простые) на доработку системы. В связи с изменениями в области законодательства возникает необходимость дорабатывать определенные модули системы. В этом случае затраты времени варьируются от степени сложности доработки системы. Это могут быть и 24 часа, и несколько дней, иногда и месяц. Написание технических заданий связано либо с необходимостью совершенствования системы или процессов, либо в целом с внедрением нового модуля (т. е. изучением запросов пользователей, описанием бизнес-процессов и их реализацией для решения определенных видов задач). Для того чтобы корректно ответить на вопросы пользователей, консультанту необходимо определить сферу возникновения ошибки, проанализировать первичную информацию и, используя личный опыт и (или) справочные материалы, сформулировать ответ на вопрос, а затем подтвердить его, используя тестовую базу. Среднее время, затрачиваемое консультантом, зависит от опыта его работы и сложности задачи. В таблице приведены усредненные результаты экспертного оценивания аналитиками времени, затрачиваемого на решение проблем пользователей. Согласно данным таблицы, если неопытный консультант использует предшествующие свои или чужие наработки, то в среднем он затрачивает меньше времени на решение проблемы. Это объясняется тем, что при консультировании у различных пользователей часто возникают одни и те же или очень похожие проблемы. Затраты времени на решение вопроса Категория Опытный консультант Неопытный консультант Самообучение Использование прецедентов на бумажных носителях без функции поиска Использование прецедентов с функцией поиска (MS Word) Простые вопросы 7-10 15-25 12-20 10-17 Вопросы средней сложности 10-25 25-60 20-50 17-45 Сложные вопросы 25-45 60-120 50-110 45-100 Технические задания > 45 > 120 > 110 > 100 Таким образом, можно сделать следующий вывод: использование даже очень простых средств записи и извлечения знаний о решении проблем позволяет приблизить эффективность неопытного консультанта к эффективности опытного специалиста-аналитика. Именно поэтому представляется перспективным построение в области ИТ-поддержки полноценной интеллектуальной системы управления знаниями, помогающей накапливать, систематизировать, интегрировать и эффективно использовать опыт аналитиков по консультированию сотрудников организации. Важным начальным этапом построения эффективной системы управления знаниями является выбор модели представления знаний, на которой строится база знаний интеллектуальной системы. Первые системы, основанные на знаниях (СОЗ), появившиеся в 1970-е гг., строились на основе правил. Такие системы позволяют применять алгоритмы логического вывода к известным правилам и фактам для извлечения из базы знаний новых (неизвестных) фактов. Правила являются удобными и выразительными конструкциями для представления знаний в различных предметных областях. Именно с этим способом представления знаний связывают развитие в научной области искусственного интеллекта, когда искусственный интеллект вышел из области простейших решений в сферу реальных приложений. При внедрении интеллектуальных систем, основанных на правилах, разработчики столкнулись с рядом проблем. Очень скоро выяснилось, что каким бы точным и эффективным не был механизм логического вывода, лежащий в основе извлечения новых знаний, определяющую роль в системе, основанной на знаниях, играют уже накопленные в ней знания, на основе которых производится логический вывод. Однако проблема получения экспертных знаний и их представления в виде правил оказалась узким местом при работе со сложными предметными областями. Чаще всего эксперты интуитивно принимают те или иные решения, основываясь на своем богатом опыте и не задумываясь над тем, какие правила они применяют в том или ином случае. Разбиение специфического поведения экспертов на отдельные мелкие кирпичики в форме правил является сложной проблемой, для решения которой требуются высококвалифицированные аналитики (инженеры по знаниям). Таким образом, извлечение знаний из экспертов является ключевой проблемой систем, основанных на правилах. Другой проблемой является несоответствие между сложностью реальных предметных областей и очень простой структурой правила ЕСЛИ - ТО. Однако последняя проблема частично решается с использованием новых средств объектно-ориентированного описания составных частей правила [1, 2]. С 1980-х гг. альтернативная парадигма представления знаний стала привлекать все большее внимание исследователей. Метод рассуждения на основе прецедентов (Case-Based Reasoning (CBR)) позволяет решать новые проблемы, извлекая прошлые успешные прецеденты и адаптируя их к новым условиям. Данный подход с успехом используется в медицинской диагностике, в юридическом консультировании. На наш взгляд, именно этот метод органически подходит для создания системы консультирования пользователей, использующей опыт решения подобных задач в прошлом. В основе метода прецедентов лежит фундаментальная идея, согласно которой именно таким образом часто поступает лицо, принимающее решения, находя в своей памяти информацию, относящуюся к решаемой задаче, и адаптируя прошлые условия к новым реалиям. Считается, что базовые принципы CBR-подхода были изложены в работах Р. С. Шенка (R. S. Schank) [3, 4], впервые предложившего обобщить знания о прошлых ситуациях в форме так называемых скриптов, контейнеров знаний, которые можно использовать как в процессе обучения, так и в процессе принятия решений. Эта модель, называемая динамической памятью Шенка, явилась в последующие годы фундаментом для создания большого числа систем, основанных на прецедентном подходе:MEDIATOR [5], CHEF [6], PERSUADER [7], CASEY [8] и JULIA [9]. Прецедентный подход позволил преодолеть ряд ограничений, свойственных системам, использующим модель на основе правил [10]. Он не требует построения явной модели предметной области, сложный процесс приобретения знаний сводится к задаче накопления случаев принятия решений в прошлом (прецедентов), а также анализа результатов принятия решений (положительных или отрицательных). Реализация интеллектуальной системы на основе прецедентного подхода в простейшем случае сводится к идентификации основных переменных (атрибутов), описывающих прецедент, и накоплению случаев, описываемых данным набором атрибутов, с использованием развитых технологий создания баз данных, что является намного более простой задачей, чем извлечение экспертных знаний в виде правил. Однако с развитием прецедентного подхода проявились два основных его недостатка. Первый недостаток - простая модель описания прецедентов не учитывает реальную сложность объектов предметной области и взаимосвязей между ними, что ограничивает и его выразительные возможности. Другой недостаток начинает проявляться при накоплении очень большой базы прецедентов. При этом возникают проблемы извлечения релевантных прецедентов из огромного количества больших данных. Для преодоления указанных выше недостатков прецедентного подхода предлагались различные варианты его интеграции с другими методами при создании информационных систем в различных предметных областях, например [11, 12]. Ряд систем (ADIOP, CADRE, CADSYN, CHARADE, COMPOSER, IDIOM, JULIA) интегрировали метод прецедентов с алгоритмом решения проблемы удовлетворения ограничений. Другие системы (ANAPRON, AUGUSTE, CAMPER, CABARET, GREBE, GYMEL, SAXEX, CABARET, MARS) использовали комбинирование моделей представления знаний в виде прецедентов и в виде правил. Нам представляется, что количество недостатков метода прецедентов могут быть существенно уменьшено на основе его интеграции с моделями представления знаний о предметной области в виде онтологии. В [13] представление предметной области в области IT-технологий использовалось для совершенствования семантического поиска документов, основанного на индексировании документов концептами онтологии, в то время как обычное индексирование осуществляется по ключевым словам. Мы предлагаем оригинальный метод интеграции прецедентов IT-консультирования с онтологиями предметной области IT-консультирования на основе установления ассоциативных связей прецедентов с концептами онтологии. Каждый прецедент может быть связан не с одним, а с несколькими концептами онтологии, находящимися на различных уровнях иерархии, что позволяет наиболее адекватным способом описать семантику того или иного прецедента консультирования пользователей средствами онтологии. Предлагаемый метод индексирования прецедентов может быть использован для последующего эффективного извлечения прецедентов, релевантных текущей ситуации, с использованием метода построения нечетких лингвистических правил, предложенного в [14, 15]. Это преимущество особенно ощутимо при накоплении большой базы знаний, когда актуальным становится вопрос об извлечении наиболее семантически близкого прецедента из очень большого набора данных. Интеграция прецедентов с онтологией предметной области увеличивает выразительные возможности прецедентного подхода. Онтология предметной области в области IT-консультирования В предлагаемом подходе к извлечению прецедентов из базы знаний базовым компонентом является индексирование прецедентов на основе онтологии предметной области. Онтологии - формальные явные описания терминов предметной области и отношений между ними [16]. Онтологию формально можно представить следующим кортежем [17]: , где - конечное непустое множество классов (концептов), описывающих основные понятия предметной области; - конечное множество бинарных отношений, заданных на классах, , , где - антисимметричное, транзитивное, нерефлексивное отношение иерархии «класс-подкласс», задающее частичный порядок на множестве классов; - ассоциативное отношение, которое будет использовано для установления связи между прецедентами и концептами онтологии; - конечное множество слотов (свойств класса); - конечное множество фасетов (свойств слота); - конечное множество экземпляров классов; - конечное непустое множество, определяющее контролируемый словарь терминов предметной области, построенный на множестве базовых терминов , составляющих множество имен классов онтологии: Структура класса определяется следующим образом: где - классы онтологии, связанные отношением иерархии ; - слоты фрейма; - имя класса, являющееся базовым термином словаря T. Таксономия классов образуется посредством указания в подклассе связи «isa» и имени класса-родителя cparent. Назовем классы, не имеющие потомков, терминальными концептами онтологии (терминалами). Терминалы будут играть роль ключевых слов при индексировании прецедентов. Структура слота определяется следующим образом: где - слот класса - фасеты (свойства слота); - имя слота. Онтология позволяет описывать данные графически в виде онтологического графа, а также в виде концептуальной и логической моделей. Онтология была создана в редакторе Protégé 4.2. Редактор онтологий Protégé 4.2 -это свободное программное обеспечение для построения онтологий. Онтологии, построенные в этом редакторе, экспортируются во множество форматов, данное программное обеспечение имеет открытую и легко расширяемую архитектуру. Фрагмент таксономии (иерархии) концептов верхнего уровня, являющихся непосредственными потомками , представлен на рис. 1. Рис. 1. Онтологический граф концептов верхнего уровня Основными концептами верхнего уровня онтологии являются Accounting, Payroll и ContractUnit. Концепт Accounting описывает основные подразделы бухгалтерского учета. Бухгалтерский учет представляет собой упорядоченную систему сбора, регистрации и обобщения информации в денежном выражении об имуществе, обязательствах организаций и их движении путем сплошного, непрерывного и документального учета всех хозяйственных операций. Accounting образует таксономию, которая формируется двенадцатью подчиненными концептами (рис. 2). Концепты Bank и Cash отражают ведение операций с денежными средствами, за безналичные и наличные расчеты соответственно. Концепт Sale отражает оформление операций по продаже товаров и оказанию услуг клиентам, этот концепт является одним из основных для ведения деятельности предприятия. Концепт Purchase предназначен для учета ведения операций по покупкам товаров и услуг у поставщиков и имеет подчиненные концепты. Концепт Warehouse отражает учет движения материалов на складе и т. д. Данные и подчиненные концепты помогают выразить смысл вопросов, возникающих у пользователей. Например, вопрос пользователя «В поступлении товара ставка в номенклатуре проставляется без НДС, почему?» целесообразно связать с концептом Purchase. Рис. 2. Онтологический граф концепта Accounting (бухгалтерский учет) Концепт Payroll описывает основные подразделы таксономии «Расчеты с персоналом». В этой таксономии решаются задачи автоматизации деятельности как менеджеров, принимающих решения по зарплате персонала, так и бухгалтеров-расчетчиков зарплаты; обеспечивается также ведение взаиморасчетов с работниками предприятия, осуществляется учет затрат на оплату труда в составе себестоимости продукции и услуг, начиная с ввода документов о фактической выработке, об оплате больничных листов и отпусков, вплоть до формирования документов на выплату зарплаты и отчетности в государственные надзорные органы. У пользователей могут возникать различные вопросы, связанные с данными концептами. Например, у сотрудника отдела кадров могут возникнуть следующие вопросы: «При создании сотрудника возникает ошибка, что физическое лицо уже существует, что делать?», «Как внести больничный лист?». Эти вопросы можно отнести к концепту PersonnelRecords. Пользователи, которые могут задавать вопросы, связанные с таксономией Payroll, - это бухгалтеры по заработной плате, кадровики, табельщики, т. е. пользователи отдела расчетов с персоналом. Фрагмент онтологии концепта Payroll представлен на рис. 3. Рис. 3. Онтологический граф концепта Payroll (расчеты с персоналом) Концепт ContractUnit (фрагмент онтологического графа представлен на рис. 4) описывает основные подразделы предметной области «Договорной блок». Договорной блок предназначен для автоматизации работы пользователей в сфере оформления и ведения договоров контрагентов. Договорной блок состоит из концептов Contractors - описание основных реквизитов контрагентов, ContractCounterparties - оформление договоров контрагентов, AdditionalAgreements - учет дополнительных соглашений для введения в действие договоров контрагентов и автоматического формирования пакета документов для оформления оказания услуги контрагенту, AmendmentOfContract - изменение реквизитов договоров, ChangeConsoleRooms - изменение пультовых номеров, - настройка тарифов контрагентов, Reports- формирование отчетов по оказанию услуг контрагентам. Например, у договорника могут возникнуть следующие вопросы: «Как ввести договор в действие?», «Почему нет начислений по договору?». Эти вопросы относятся к концепту ContractCounterparties. Пользователи, которые могут задавать вопросы по концепту ContractUnit, - это бухгалтеры по договорам или договорники. Созданная в Protégé 4.2 иерархия концептов содержит 71 концепт таксономии Payroll, 82 концепта таксономии Accounting и 11 концептов таксономии ContractUnit. Рис. 4. Онтологический граф концепта ContractUnit (договорной блок) Таким образом, вышеописанная онтология предметной области представляет собой объединение трех таксономий концептов, связанных иерархическими отношениями. В принципе, если потомки некоторого родителя имеют неодинаковое влияние на родительский концепт, то возможно введение в таксономию весовых коэффициентов. Для этого каждому концепту, имеющему родителя, добавляется слот - вес концепта. В настоящей версии онтологии предполагается, что все дети одного родителя имеют одинаковый вес, равный , где - число детей данного родителя. Описание класса Precedent и его реализация Рассуждения на основе аналогии, или метод прецедентов (CBR) - это подход, который позволяет решить новую проблему, используя или адаптируя решение, ранее уже принятое в аналогичной ситуации. В [18] вводится следующее определение прецедента: «Прецедент - это описание проблемы или ситуации в совокупности с подробным указанием действий, предпринимаемых в данной ситуации или для решения данной проблемы». Когда рассматривается новая ситуация, система находит подобный прецедент в базе знаний как аналог решаемой задачи и пытается использовать решение найденного прецедента. Если необходимо, близкий прецедент адаптируется к текущей ситуации. После применения решения, полученного на основе рассуждения по аналогии, к текущей проблеме, осуществляется анализ полученных результатов, после чего новый прецедент заносится в базу прецедентов для его использования в будущем. Прецедент должен включать следующие элементы: - описание ситуации с помощью атрибутов; - решение, которое было принято в этой ситуации; - обоснование (результат) применения решения. Описание ситуации содержит по возможности всю информацию, которая необходима для достижения цели (выбора наиболее подходящего решения). Чем более подробно пользователь опишет вопрос, тем быстрее будет найден ответ. Достаточно часто пользователи формируют запрос очень кратко, например: «Возникла проблема в кадровом приказе». При этом непонятно, в каком приказе возникла ошибка, т. к. номер приказа не указан, не уточняется, какая именно проблема возникла. На уточнение вопроса тратится время, и решение будет дано пользователю не сразу, а через некоторое время. Решение содержит: набор операций, которые необходимо выполнить для получения успешного результата, т. е. для решения вопроса пользователя. В описание решения могут входить ссылки на другие прецеденты, текстовая информация, вложенный документ с инструкцией и т. п. Обоснование применения решения - это обратная связь, которая возникает при применении решения к текущей ситуации. Прецедент должен содержать либо положительный, либо отрицательный исходы. Даже если проблему не удалось решить при использовании адаптированного прецедента в текущей ситуации, эта информация (отрицательный исход) полезна и может быть использована для дальнейшего анализа. Удалять такой прецедент не следует, т. к. более глубокий анализ может показать направление дальнейший действий для решения вопроса. Достаточно поместить прецедент в отдельный класс прецедентов с отрицательными исходами. Прецедент можно представить различными способами, например древовидными структурами, строками в базах данных, фреймами и т. п. Важно понимать, что выбирать представление прецедента необходимо исходя из общих целей системы. Главными проблемами при представлении прецедента являются: выбор информации, которую необходимо включить в описание прецедента, поиск удобной структуры прецедента и организация базы знаний для оптимального и эффективного поиска. Первоначальное описание прецедента может быть простым (линейным): , где - значения атрибутов прецедента, идентифицирующих ситуацию; - решение проблемы, определенное в прецеденте. В последующем, по мере углубления в проблемную область, возможно усложнение структуры прецедента, введение иерархических и других отношений между признаками. Для интеграции онтологии предметной области с описанием прецедентов оказания IT-поддержки пользователям в онтологии был создан класс Precedent. Данный класс не обладает разветвленной иерархической структурой, как другие классы (концепты) онтологии, он вообще не имеет подклассов. Назначение класса Precedent - создать наиболее полную структуру для ввода информации о прецедентах консультирования (решения задачи пользователя), вводимой консультантом-аналитиком, а также установить связь с онтологией предметной области. Данный класс включает три группы свойств (слоты) - Main, Changes и Files, цель которых - структурно и содержательно разделить информацию, включенную в описание прецедента (рис. 5). Рис. 5. Свойства класса Precedent Слот Main имеет следующие подчиненные слоты: - Decision (решение)- полное описание последовательности действий пользователя (технологии) для решения проблемы; - DescriptonUser (описание пользователя) - информация о проблеме, которую пользователь дает консультанту при составлении запроса; - Error (ошибка)- техническая ошибка, которая может быть решена только путем перепрограммирования (заполнено или нет); - Keyword 1…3 (ключевые слова 1…3) - один или несколько слотов ключевых слов, характеризующих проблему. По этим слотам прецедент связан с онтологией; - SoftwareProduct (программный продукт) - программный продукт, где возникла ошибка пользователя, выбор из списка (1С, Axapta и т. д.); - UserRole (роль пользователя) - пользователь может быть сотрудником отдела кадров, бухгалтером, табельщиком, главным бухгалтером, заместителем главного бухгалтера, аудитором и т. д. Функциональность, которая может быть использована для решения проблемы пользователем, зависит от роли пользователя; - VersionProgram (версия программного продукта) - релиз или версия. Программные продукты постоянно обновляются, разработчики исправляют ошибки, поэтому, прежде чем ответить на вопрос пользователя, необходимо понять, на каком релизе работает пользователь. Слот Changes класса Precedent полезен для случая, когда несколько консультантов работают с базой данных. Всегда можно понять, кто и когда вносил изменения в прецедент. Данный слот имеет следующие подчиненные слоты: - Period (период) - дата и время, когда был создан прецедент или были внесены изменения; - User (консультант) - имя пользователя, внесшего изменения. Слот Files имеет следующие подчиненные слоты: - FilesDescription (описание файла)- краткое описание файла; - FileName (имя файла) - путь к файлу, прикрепленному к прецеденту. Это может быть файл с ошибкой, которая возникает в этом запросе, или файл с инструкцией по устранению неполадок. Структура прецедента, которая была описана выше, обладает необходимой полнотой и неизбыточностью, т. к. она задает основные характеристики запроса пользователя: описание пользователем, ошибку, набор ключевых слов, программный продукт, версию программного продукта, роль пользователя и, наконец, решение проблемы пользователя. Консультант дает профессиональное описание, характеризующее проблему пользователя, определяет место проблемы в онтологии с помощью ассоциативных связей с концептами онтологии, задавая таким образом семантику прецедента. Прецедент содержит также сведения о внесении изменений в прецедент: дату, когда изменения были сделаны, кем они были сделаны, так что есть возможность проанализировать внесенные изменения. К прецеденту можно прикрепить файл, содержащий инструкции по решению проблемы, или ошибки пользователя, которые могут быть приобщены к прецеденту. Этой информации достаточно, чтобы решить проблему пользователя и оперативно найти подходящий прецедент. Интеграция прецедентов с концептами онтологии В традиционном методе CBR для извлечения прецедентов используется мера близости (расстояние) в многомерном пространстве, задаваемом атрибутами прецедента. В этом случае в базе прецедентов производится поиск случая, наиболее близкого к текущей проблеме для заданного подмножества значений атрибутов, после чего найденный прецедент (прецеденты) адаптируется к текущей ситуации. Однако далеко не всегда наиболее близкий (в терминах расстояния в многомерном пространстве) прецедент является наиболее релевантным, когда достигается наилучшее семантическое соответствие найденного прецедента текущей проблеме. Нам представляется перспективным осуществлять сравнение между текущей ситуацией и прецедентами, оценивая степень их связи с концептами онтологии. Это означает, что близость прецедентов друг к другу оценивается степенью семантической близости связанных с этими прецедентами концептов. Для этого на этапе создания базы знаний при внесении каждого нового прецедента необходимо установить смысловые связи вновь вводимого прецедента с концептами онтологии. Связь экземпляров класса Precedent с концептами онтологии осуществляется путем задания ассоциативного отношения для слотов группы Keywords класса Precedent (слота Main). Отношение устанавливается путем явного указания в качестве значения слота класса Precedent имени связанного с ним класса - концепта онтологии, а также типа связи, существующей между этими классами. Для реализации указанной ассоциативной связи в качестве типа группы слотов Keywords используется тип (тип Задание типа для каждого из слотов Keywords предполагает указание дополнительного аргумента - ассоциированного класса, концепта онтологии. Если, например, i-й слот группы Keywords имеет тип с ассоциированным классом , то в качестве значений слота при создании экземпляров класса Precedent могут быть использованы классы множества - транзитивного замыкания концепта по отношению , включающего класс и все его подклассы ниже по иерархии , где , - максимальная глубина потомков класса . В этом случае классы Precedent и связаны ассоциативным отношением . Устанавливая связи некоторого прецедента с онтологией, аналитик выбирает концепты, наиболее близкие по смыслу с данным прецедентом. Это могут быть как терминальные (не имеющие потомков), наиболее четко семантически оформленные концепты, так и нетерминальные (промежуточные) концепты, имеющие более общий смысл. Необходимость в нетерминальных концептах возникает в том случае, если возникающая проблема не может быть однозначно отнесена к терминальному концепту или аналитик не имеет достаточного опыта и ему проще отнести прецедент к более общему по смыслу понятию. Необходимо подчеркнуть, что в нашем подходе мы допускаем установление не одной, а нескольких связей прецедента с концептами онтологии. Это расширяет выразительные возможности нашего подхода и может быть использовано в случае, когда проблема возникает на стыке нескольких понятий и ее адекватное описание требует учета этой междисциплинарности. Пусть в качестве фасета для i-го слота группы Keywords задается весовое значение ,, , устанавливающее силу связи прецедента с соответствующим концептом онтологии. Вес тем больше, чем ближе по смыслу прецедент к данному понятию предметной области. Рассмотрим теперь, как можно организовать процедуру классификации и извлечения семантически близких прецедентов, используя вышеописанную интегрированную модель. Мы будем различать терминальные и нетерминальные концепты. Назовем терминальные концепты онтологии ключевыми словами. Пусть в онтологии имеется ключевых слов. Поставим в соответствие каждому прецеденту вектор размерности весовых коэффициентов. Процедуру вычисления весовых коэффициентов можно организовать следующим образом. Без ограничения общности предположим, что концепты онтологии, с которыми связан прецедент, не входят в транзитивное замыкание друг друга (т.е. они не должны быть расположены на одной иерархической ветке). Данное предположение вполне естественно, т. к. если мы можем отнести прецедент к более конкретному концепту-потомку, то отпадает надобность в его связи с более общим концептом-предком. В этом случае процедура формирования вектора весовых коэффициентов , ключевых слов , может быть представлена следующим образом. Предположим, что рассматриваемый прецедент связан с концептами . 1. Положим сначала 2. Цикл для всех связанных с прецедентом концептов : - если является терминальным концептом (), то; - если не является терминальным концептом , то , где - веса терминальных концептов онтологии - вес связи от концепта-родителя к концепту-ребенку на пути от ассоциированного с прецедентом концепта к терминальному концепту . Иллюстрация последнего варианта вычисления представлена на рис. 6. Веса концептов, подчиненных одному родителю онтологии, как отмечалось выше, считаются одинаковыми. Рис. 6. Вычисление силы связи прецедента с ключевыми словами Проиллюстрируем вычисление весов ключевых слов на конкретном примере. Предположим, что мы имеем в базе знаний конкретный прецедент, связанный только с концептами, принадлежащими транзитивному замыканию класса PersonellOrders по отношению . Фрагмент онтологии с полностью развернутым классом PersonellOrders (до терминальных концептов) представлен на рис. 7. Эксперт-аналитик установил три ассоциативные связи от прецедента к онтологии. Две связи установлены к терминальным концептам TransferOrder и OtherOrders. Веса ключевых слов TransferOrder и OtherOrders соответственно полагаются равными соответствующим установленным аналитиком весам и . Третья связь установлена к нетерминальному концепту Staffing, являющемуся родителем трех терминальных концептов - ключевых слов DepartmentDirectory, PostsDirectory и StaffingSpecification. Соответственно, и вес , установленный аналитиком для связи прецедента с концептом Staffing, делится на данные ключевые слова поровну. Соответствующие данным ключевым словам веса равны . Остальные ключевые слова остались несвязанными с прецедентом и, соответственно, имеют по отношению к нему нулевые веса. Таким образом, для подмножества из восьми терминальных концептов (ключевых слов) OrderOnAdmission, TransferOrder, OrderOfAssignmentOfClassRank, OtherOrders, OrderOfDismissal, DepartmentDirectory, PostsDirectory, StaffingSpecification (рис. 7) имеем следующий подвектор весов, соответствующий рассматриваемому прецеденту. Так как прецедент имеет связи только с концептами этого фрагмента онтологии, то остальные ключевые слова имеют нулевые веса. Рис. 7. Пример вычисления силы связи прецедента с ключевыми словами Фрагмент онтологии, реализованной в Protégé 4.2 с выделенным классом Precedent, списком хранящихся экземпляров прецедентов и концептов, соответствующих текущему прецеденту, представлен на рис. 8. Рис. 8. Фрагмент онтологии с выделенным классом Precedent Таким образом, все прецеденты, хранящиеся в базе знаний, индексируются с помощью концептов онтологии и соответствующих им ключевых слов. Каждое ключевое слово включено в представление прецедента с весом, рассчитанным на основе ассоциативных связей между прецедентом и понятиями онтологии. К полученной таблице данных далее можно применять методы анализа данных, извлечения знаний из данных. Например, возможно проведение кластерного анализа с целью разбиения прецедентов на классы семантически близких случаев. После выделения классов прецедентов процедура извлечения прецедента, релевантного проблеме пользователя, заключается в следующем. Описывая текущую ситуацию, аналитик должен связать ее с концептами онтологии, как это делалось с прецедентами, составляющими базу знаний. В результате мы будем иметь строку весов ключевых слов, соответствующую решаемой проблеме. В данном случае задачу извлечения прецедентов, релевантных текущей проблеме, можно свести к задаче классификации. Наиболее подходящим здесь методом является классификация прецедентов на основе построения системы нечетких лингвистических правил, предложенная в [14, 15, 19]. В данных публикациях на тестовых данных подтверждена высокая точность классификации прецедентов. Кроме того, данный метод предполагает получение из прецедентов знаний более высокого уровня организации - правил, которые могут быть проанализированы экспертом и добавлены в базу знаний для непосредственного использования. Выводы По результатам исследования предложен оригинальный метод интеграции прецедентов с концептами онтологии. На основе анализа предметной области построена онтология для помощи аналитикам в работе IT-подразделения, состоящая из трех таксономий: по бухгалтерскому учету, расчетам с персоналом, договорному блоку. Описаны основные понятия прецедентного подхода, предложена структура прецедента, которая используется для извлечения и оказания помощи пользователям программных продуктов. Предлагаемый подход основан на идее индексирования прецедентов с помощью установления их связей с концептами онтологии, в результате чего удается повысить семантическую близость извлекаемых прецедентов решаемой задаче, ускорить процесс поиска подходящего прецедента для ответа на вопрос пользователя и, как следствие, повысить эффективность работы IT-подразделения.

1. Alexander J. H., Freiling M. J., Shulman S. J., Staley J. L., Rehfuss S., Messick S. L. Knowledge level engineering: ontological analysis // AAAI-86. 1986. Vol. 21. P. 963-968.

2. Bakaev M., Avdeenko T. Indexing and comparison of multi-dimensional entities in a recommender system based on ontological approach. Computación y Sistemas. 2013. Vol. 17, no. 1. P. 5-13.

3. Schank R. C., Abelson R. P. Scripts, Plans, Goals and Understanding: An inquiry into human knowledge structures. Hillsdale (N. J.): Erlbaum, 1977. 248 p.

4. Schank R. C. Dynamic Memory: A theory of reminding and learning in computers and people. Cambridge University Press, 1982. 272 p.

5. Simpson R. L. A Computer Model of Case-Based Reasoning in Problem Solving: An Investigation in the Domain of Dispute Mediation // Technical Report GIT-ICS-85/18, Georgia Institute of Technology, School of Information and Computer Science, 1985.

6. Hammond K. J. CHEF: A model of case-based planning. In: Proc. American Association for Artificial Intelligence, AAAI-86, Philadelphia, PA, 1986.

7. Sycara E. P. Resolving adversarial conflicts: An approach to Integrating Case-Based and Analytic Method // Technical Report GIT-ICS-87/26, Georgia Institute of Technology, School of Information and Computer Science, 1987.

8. Koton P. Using experience in learning and problem solving. Ph.D. thesis, Massachusetts Institute Technology, Laboratory of Computer Science, 1989.

9. Hinrichs T. R. Problem Solving in Open Worlds: A Case Study in Design. Lawrence Erlbaum, 1992.

10. Watson I., Marir F. Case-based reasoning: A review. The Knowledge Engineering Review. 1994. 9 (4). P. 327-354.

11. Marling C., Sqalli M., Rissland E., Hector M. A., Aha D. Case-based reasoning integrations // AI Magazine. 2002. 23 (1). P. 69-86.

12. Yang H. L., Wang C. S. Two stages of case-based reasoning - Integrating genetic algorithm with data mining mechanism // Expert Systems with Applications. 2008. 35. P. 262-272.

13. Shanavas N., Asokan S. Ontology-Based Document Mining System for IT Support Service // Procedia Computer Science. International Conference on Information and Communication Technologies (ICICT 2014). 2015. 46. P. 329-336.

14. Avdeenko T. V., Makarova E. S. Metod opredeleniya relevantnosti precedentov na osnove nechetkih lingvisticheskih pravil // Nauch. vestn. Novosibirsk. gos. tehn. un-ta. 2016. T. 62, № 1. S. 17-34.

15. Makarova E. S. Issledovanie vliyaniya parametrov nechetkoy modeli na tochnost' klassifikacii precedentov // Vestn. Astrahan. gos. tehn. un-ta. Ser.: Upravlenie, vychislitel'naya tehnika i informatika. 2016. № 4. S. 7-18.

16. Gruber T. R. Ontolingua: A Mechanism to Support Portable Ontologies. Technical Report KSL 91-66, 1992. Knowledge Systems Laboratory, Stanford University.

17. Avdeenko T. V., Bakaev M. A. Gibridnaya model' predstavleniya znaniy dlya realizacii vyvoda vo freymovoy ontologii // Nauch. vestn. Novosibirsk. gos. tehn. un-ta. 2013. № 3. S. 84-90.

18. Karpov L. E., Yudin V. N. Metody dobychi dannyh pri postroenii lokal'noy metriki v sistemah vyvoda po precedentam. M.: ISPRAN, preprint № 18, 2006.

19. Xiong N. Fuzzy rule-based similarity model enables learning from small case bases // Applied Soft Computing. 2013. 13. P. 2057-2064.