Лекция 16. Технология проектирования и разработки экспертных систем.

Термины: экспертные системы.

План темы:

· 16.1. Технология проектирования и разработки экспертных систем.

· 16.2. Построение экспертных систем.

· 16.3. Методология построения экспертных систем.

· 16.4. Этапы разработки ЭС.

· 16.5.Современное состояние разработки экспертных систем и инструментальных средств для их построения.

Вспомнить вопросы:

· Что такое экспертная система?

16.1. Технология проектирования и разработки экспертных систем.

Промышленная технология создания интеллектуальных сис­тем включает следующие этапы:

· исследование выполнимости проекта;

· разработку общей концепции системы;

· разработку и тестирование серии прототипов;

· разработку и испытание головного образца;

· разработку и проверку расширенных версий системы;

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

Проектирование ЭС основано на трех главных принципах:

1. Мощность экспертной системы обусловлена прежде всего мощностью БЗ и возможностями ее пополнения и только затем - используемыми методами (процедурами) обработки информации.

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

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

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

Чтобы разработка ЭС была возможной для данного приложе­ния, необходимо выполнение, по крайней мере, следующих тре­бований:

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

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

· эксперты способны вербализовать (выразить на естественном языке) и объяснить используемые ими методы, иначе трудно рассчитывать на то, что знания экспертов будут «извлечены» и заложены в ЭС;

· решение задачи требует только рассуждений, а не действий; в задача не должна быть слишком трудной (т.е. ее решение

· должно занимать у эксперта несколько часов или дней, а не недель или лет);

· задача хотя и не должна быть выражена в формальном виде, но все же должна относиться к достаточно «понятной» и структурированной области, т.е. должна существовать возможность выделения основных понятий, отношений и способов получения решения задачи;

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

Приложение соответствует методам ЭС, если решаемая за­дача обладает совокупностью следующих характеристик:

· задача может быть естественным образом решена посредст­вом манипулирования символами (с помощью символических рассуждений), а не манипулирования числами, как принято в ма­тематических методах и в традиционном программировании;

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

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

Традиционная технология реализации ЭС включает шесть ос­новных этапов (рис. 16.1): идентификацию,

концептуализацию, формализацию, выполнение, тестирование, опытную эксплуата­цию.

Рисунок 16.1. Этапы разработки экспертных систем.

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

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

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

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

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

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

Процесс создания ЭС не сводится к строгой последователь­ности перечисленных выше этапов. В ходе разработки приходит­ся неоднократно возвращаться на более ранние этапы и пересма­тривать принятые там решения.

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

· подход, базирующийся на поверхностных знаниях;

· структурный подход;

· подход, основанный на глубинных знаниях;

· смешанный подход, опирающийся на использование по­верхностных и глубинных знаний.

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

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

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

экспертизы.

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

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

16.2. Построение экспертных систем.

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

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

Рис.16.2. Схема обобщенной экспертной системы.

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

1) преобразует входные данные, представленные на ограниченном естественном языке, в представление на внутреннем языке системы; 2) преобразует сообщения системы, выраженные на внутреннем языке, в сообщения на ограниченном естественном языке. Интерпретатор на основе входных данных, продукционных правил и общих фактов о проблемной области формирует решение задачи. Если ответ системы не понятен пользователю, то он может потребовать, чтобы система объяснила, как этот ответ был получен. Обычно объяснительный блок сообщает следующее: 1) как правила используют информацию пользователя; 2) почему использовались (не использовались) данные правила; 3) какие были сделаны выводы. Все объяснения даются на ограниченном естественном языке.

Схема экспертной системы, приведенная на рис. 16.2, является весьма обобщенной и ни в коей мере не претендует на универсальность. Задача этой схемы - дать предварительное представление об ЭС, которое уточняется в последующих главах (см. § 6.1). Важно отметить, что архитектура реальных экспертных систем различается в первую очередь по следующим характеристикам: 1) способ представления данных и знаний; 2) состав используемых знаний; 3) методы работы интерпретатора. Выбор тех или иных характеристик при проектировании экспертной системы определяется в основном свойствами решаемых задач и желаемыми свойствами системы (см. гл. 3, 5 и 6).

16.3. Методология построения экспертных систем.

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

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

Трудоемкость и время создания прототипа в значительной степени зависят от типа используемого инструментария. Существуют различные классификации инструментария. Возможна, например, следующая классификация: 1) процедурные языки программирования, ориентированные на обработку символьной информации (LISP, INTERLISP и др.); 2) языки инженерии знаний, т.е. языки ориентированные на разработку ЭС (например, языки PROLOG и ОРS_5 - см. п. 1.5.6); 3) средства автоматизации процесса конструирования, использования и модификации ЭС (например. RLL, НЕАRSАУ-III, ТЕIRESIAS и Др. см. § 1.5); 4) пустые (базовые) ЭС, т.е. ЭС, не содержащие знаний ни о какой проблемной области (например, ЕМУСIМ, КАS и др. - см. § 1.5). В приведенной классификации инструментарии расположены в порядке убывания трудоемкости, требуемой для создания с их помощью прототипа. Действительно, при использовании инструментария первого типа в задачу разработчика входит программирование всех компонент ЭС на языке довольно низкого уровня. Использование инструментария второго типа позволяет значительно повысить уровень языка, что, как правило, влечет за собой снижение эффективности. Инструментальные средства третьего типа позволяют разработчику не программировать некоторые или все компоненты ЭС, а выбирать их из заранее составленного набора. Обычно инструментарии этого типа подразделяют на средства, автоматизирующие построение ЭС (например, RLL, НЕАRSАУ-III), и средства автоматизирующие процесс приобретения знаний (например, ТЕIRESIAS).

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

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

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

Рис.16.3. Этапы разработки экспертной системы.

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

16.4. Этапы разработки ЭС.