Базы знаний интеллектуальных


Структурирование или концептуализация знаний



страница6/13
Дата22.05.2016
Размер3.92 Mb.
ТипРеферат
1   2   3   4   5   6   7   8   9   ...   13

Структурирование или концептуализация знаний

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


ляются:

  • терминология;

  • список основных понятий и их атрибутов;

  • отношения между понятиями;

  • структура входной и выходной информации;

  • стратегия принятия решений;

  • ограничения стратегий и т. д.

• использование «пустых» ЭС или «оболочек» типа ЭКСПЕРТ [Кирсанов, По-


пов, 1990], ФИАКР [Соловьев, Соловьева, 1989] и др.

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


Структурирование (или концептуализация) знаний — разработка неформального опи-
сания знаний о предметной области в виде графа, таблицы, диаграммы или текста, ко-
торое отражает основные концепции и взаимосвязи между понятиями предметной об-
ласти.

Такое описание называется полем знаний. Средняя продолжительность этапа 2-4
недели. Подробно стадия структурирования описана в главе 3.

Формализация

Строится формализованное представление концепций предметной области на


основе выбранного языка представления знаний (ЯПЗ). Традиционно на этом
этапе используются:

  • логические методы (исчисления предикатов 1-го порядка и др.);

  • продукционные модели (с прямым и обратным выводом);

  • семантические сети;

  • фреймы;

  • объектно-ориентированные языки, основанные на иерархии классов, объек-
    тов.



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

Все чаще на этой стадии используется симбиоз языков представления знаний,
например, в системе ОМЕГА [Справочник по ИИ, 1990] — фреймы + семанти-
ческие сети + полный набор возможностей языка исчисления предикатов. Сред-
няя продолжительность 1-2 месяца. Подробно см. в главах 3, 4.

Реализация

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


блоки, при помощи одного из следующих способов:

  • программирование на традиционных языках типа Pascal, C++ и др.;

  • программирование на специализированных языках, применяемых в задачах
    искусственного интеллекта: LISP [Хювянен, Сеппянен, 1991], FRL [Байдун,
    Бунин, 1990], SMALLTALK [Справочник по ИИ, 1990] и др.;

  • использование инструментальных средств разработки ЭС типа СПЭИС [Ков-
    ригин, Перфильев, 1988], ПИЭС [Хорошевский, 1993], G2 [Попов, Фоминых,
    Кисель, 1996];

Средняя продолжительность 1-2 месяца. Более подробно эти вопросы рассмат-


риваются в главе 6.

Тестирование

Оценивается и проверяется работа программ прототипа с целью приведения в


соответствие с реальными запросами пользователей. Прототип проверяется на:

  • удобство и адекватность интерфейсов ввода/вывода (характер вопросов в ди-
    алоге, связность выводимого текста результата и др.);

  • эффективность стратегии управления (порядок перебора, использование не-
    четкого вывода и др.);

  • качество проверочных примеров;

  • корректность базы знаний (полнота и непротиворечивость правил).



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

Средняя продолжительность 1-2 недели.

2.4.4. Развитие прототипа до промышленной ЭС

При неудовлетворительном функционировании прототипа эксперт и инженер по


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

Если первоначально выбранные объекты или свойства оказываются неподходя-


щими, их необходимо изменить. Можно сделать оценку общего числа эвристи-
ческих правил, необходимых для создания окончательного варианта экспертной
системы. Иногда [Хювянен, Сеппянен, 1991] при разработке промышленной и/
или коммерческой системы выделяют дополнительные этапы для перехода
(табл. 2.1).

демонстрационный прототип —» действующий прототип —> промышленная система —>
коммерческая система

Однако чаще реализуется плавный переход от демонстрационного прототипа к


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

Понятие же коммерческой системы в нашей стране входит в понятие «промыш-


ленный программный продукт», или «промышленная ЭС» (в этой работе).


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

'аблица 2.1. Переход от прототипа к промышленной экспертной системе

Система

Описание

Демонстрационный прототип ЭС

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

Исследовательский прототип ЭС

Система решает большинство задач, но неустойчива
в работе и не полностью проверена (несколько
сотен правил или понятий)

Действующий прототип ЭС

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

Промышленная система

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

Коммерческая система

Промышленная система, пригодная к продаже,
то есть хорошо документирована и снабжена сервисом

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

Ша этом этапе разработки большинство экспертов узнают достаточно о вводе пра-


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

22.4.5. Оценка системы

I После завершения этапа разработки промышленной экспертной системы необ-


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

  • критерии пользователей (понятность и «прозрачность» работы системы, удоб-
    ство интерфейсов и др.);

  • критерии приглашенных экспертов (оценка советов-решений, предлагаемых
    системой, сравнение ее с собственными решениями, оценка подсистемы объяс-
    нений и др.);

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

2.4.6. Стыковка системы

На этом этапе осуществляется стыковка экспертной системы с другими программ-


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

Когда экспертная система уже готова, инженер по знаниям должен убедиться в


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

Для подтверждения полезности системы важно предоставить каждому из пользо-


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

Стыковка включает обеспечение связи ЭС с существующими базами данных и


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

Пример 2.1

Успешно состыкована со своим окружением система PUFF - экспертная система для

диагностики заболеваний легких [Хейес-Рот и др., 1987]. После того как PUFF была



закончена и все были удовлетворены ее работой, систему перекодировали с LISP на
Бейсик. Затем систему перенесли на ПЭВМ, которая уже работала в больнице. В свою
очередь, эта ПЭВМ была связана с измерительными приборами. Данные с измеритель-
ных приборов сразу поступают в ПЭВМ. PUFF обрабатывает эти данные и печатает
рекомендации для врача. Врач в принципе не взаимодействует с PUFF. Система пол-
ностью интегрирована со своим окружением — она представляет собой интеллектуаль-
ное расширение аппарата исследования легких, который врачи давно используют.

Пример 2.2

Другой системой, которая хорошо функционирует в своем окружении, является CAT-1
[Уотермен, 1990] — экспертная система для диагностики неисправностей дизелей ло-
комотивов.

Эта система была разработана также на LISP, а затем была переведена на FORTH с тем,


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

Кроме того, если оператор не уверен в том, как устранить неисправность, система пре-


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

2.4.7. Поддержка системы

При перекодировании системы на язык, подобный С, повышается ее быстродей-


:твие и увеличивается переносимость, однако гибкость при этом уменьшается.
Это приемлемо лишь в том случае, если система сохраняет все знания проблем-
ной области и это знание не будет изменяться в ближайшем будущем. Однако
если экспертная система создана именно из-за того, что проблемная область изме-
няется, то необходимо поддерживать систему в ее инструментальной среде разра-
ботки.

Пример 2.3

Удачным примером ЭС, внедренной таким образом, является XCON (R1) — ЭС, кото-
рую фирма DEC использует для комплектации ЭВМ семейства VAX. Одной из клю-
чевых проблем, с которой столкнулась фирма DEC, является необходимость постоян-
ного внесения изменений для новых версий оборудования, новых спецификаций и т. д.
Для этой цели XCON поддерживается в программной среде OPS5.


Т

еоретические
аспекты инженерии
знаний


d Поле знаний

D Стратегии получения знаний

D Теоретические аспекты извлечения знаний

о Теоретические аспекты структурирования знаний



3.1. Поле знаний

Инженерия знания — достаточно молодое направление искусственного интел-


лекта, появившееся тогда, когда практические разработчики столкнулись с весь-
ма нетривиальными проблемами трудности «добычи» и формализации знаний.
В первых книгах по ИИ эти факты обычно только постулировались, в дальней-
шем начались серьезные исследования по выявлению оптимальных стратегий
выявления знаний [Boose, 1990; Wielinga, Schreiber, Breuker, 1992; Tuthill, 1994;
Adeli, 1994].

Данная глава целиком посвящена теоретическим проблемам инженерии знаний,


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

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

3.1.1. О языке описания поля знаний

Поле знаний Pz формируется на третьей стадии разработки ЭС (см. п. 2.4) — ста-


дии структурирования.

Поле знаний, как первый шаг к формализации, представляет модель .iiiaiinii о


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

ром «своем» языке. Что это за язык? Известно, что словарь языка конкретной на-
уки формируется путем пополнения общеупотребительного языка специальны-
ми терминами и знаками, которые либо заимствуются из повседневного языка,
либо изобретаются [Кузичева, 1987]. Назовем этот язык L и рассмотрим его же-
лаемые свойства, учитывая, что стандарта этого языка пока не существует, а каж-
дый инженер по знаниям вынужден сам его изобретать.

Во-первых, как и в языке любой науки, в нем должно быть как можно меньше не-


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

Во-вторых, желательно не использовать в нем терминов иных наук в другом, то


есть новом, смысле. Это вызывает недоразумения.

В-третьих, язык L, видимо, будет либо символьным языком, либо языком графи-


ческим (схемы, рисунки, пиктограммы).

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


формализации необходимо его заменить на машинно-реализуемый язык пред-
ставления знаний
(ЯПЗ), выбор которого зависит от структуры поля знаний.
Существует ряд языков, достаточно универсальных, чтобы претендовать на роль
языка инженерии знаний, — это структурно-логический язык SLL, включающий
аппарат лямбда-конверсии [Вольфенгаген и др., 1979], язык К-систем [Кузнецов,
1989], УСК [Мартынов, 1977] и др. Однако они не нашли широкого применения.
В некотором смысле создание языка L очень близко к идеям разработки универ-
сальных языков науки [Кузичева, 1987]. К XVII веку сложились два подхода в
разработке универсальных языков: создание языков-классификаций и логико-
конструктивных языков.
К первому примыкают проекты, восходящие к идее
Ф. Бэкона, — это языки Вилкинса и Далгарно. Второй подход связан с исследо-
ваниями в рамках поиска универсального метода познания, наиболее четко выс-
казанного Р. Декартом, а затем в проекте универсальной характеристики Г. Лейб-
ница. Именно Лейбниц наметил основные контуры учения о символах, которые
в соответствии с его замыслами в XVIII веке развивал Г. Ламберт, который дал
имя науке «семиотика». Семиотика в основном нашла своих адептов в сфере гу-
манитарных наук. В последнее время сложилась также новая ветвь семиотики -
прикладная семиотика [Pospelov, 1995].

Представители естественных наук еще не до конца осознали достоинства семи-


отики только из-за того, что имеют дело с достаточно простыми и «жесткими»
предметными областями. Им хватает аппарата традиционной математики. В ин-
женерии знаний, однако, мы имеем дело с «мягкими» предметными областями,
где явно не хватает выразительной адекватности классического математичес-
кого аппарата и где большое значение имеет эффективность нотации (ее ком-
пактность, простота модификации, ясность интерпретации, наглядность и т. д.).
В главе 8 рассматриваются современные тенденции в этой области и вводится
понятие систологического инжиниринга, как одного из подходов к семиотичес-
кому моделированию предметной области.
Языки семиотического моделирования [Осипов, 1988; Поспелов, 1986] как есте-
ственное развитие языков ситуационного управления являются, как нам кажет-
ся, первым приближением к языку инженерии знаний. Именно изменчивость и
условность знаков делают семиотическую модель применимой к сложным сфе-
рам реальной человеческой деятельности. Поэтому главное на стадии концептуа-
лизации — сохранение естественной структуры поля знаний, а не выразительные
возможности языка.

Традиционно семиотика включает (рис. 3.1):



  • синтаксис (совокупность правил построения языка или отношения межд>
    знаками);

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

  • прагматику (отношения между знаками и их пользователями).



Рис. 3.1. Структура семиотики

3.1.2. Семиотическая модель поля знаний

Поле знаний Pz является некоторой семиотической моделью, которая может


быть представлена как граф, рисунок, таблица, диаграмма, формула или текст i
зависимости от вкуса инженера по знаниям и особенностей предметной области

Особенности ПО могут оказать существенное влияние на форму и содержанш


компонентов структуры Pz.








Рассмотрим соответствующие компоненты Pz (рис. 3.2).
Рис. 3.3. Концептуальная составляющая поля знаний





Рис. 3.2. Структура поля знаний

Синтаксис. Обобщенно синтаксическую структуру поля знаний можно предста-


вить как

П-(1,0,М),

где I - структура исходных данных, подлежащих обработке и интерпретации в
экспертной системе;

О - структура выходных данных, то есть результата работы системы;


М - операциональная модель предметной области, на основании которой про-
исходит модификация I в О.

Включение компонентов I и О в Р обусловлено тем, что составляющие и структу-


ра этих интерфейсных компонентов имплицитно (то есть неявно) присутствуют
в модели репрезентации в памяти эксперта. Операциональная модель М может
быть представлена как совокупность концептуальной структуры Sk, отражающей
понятийную структуру предметной области, и функциональной структуры S,, мо-
делирующей схему рассуждений эксперта:

М = (Sk,Sf).

Sk выступает как статическая, неизменная составляющая Р, в то время как Sf пред-
ставляет динамическую, изменяемую составляющую.

Формирование Sk основано на выявлении понятийной структуры предметной


области. Параграф 3.4. описывает достаточно универсальный алгоритм проведе-
ния концептуального анализа на основе модификации парадигмы структурного
анализа [Yourdon, 1989] и построения иерархии понятий (так называемая «пира-
мида знаний»). Пример Sk и Sf представлен на рис. 3.3 и 3.4.



Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   13


База данных защищена авторским правом ©dogmon.org 2019
обратиться к администрации

    Главная страница