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

 

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

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

 

1) процедурные языки программирования, ориентированные на обработку символьной информации (LISP, INTERLISP и др.);

2) языки инженерии знаний, т.е. языки, ориентированные на разработку ЭС (например, языки PROLOG и OPS_5);

3) средства автоматизации процесса конструирования, использования и модификации ЭС (например, RLL, HEARSAY-III, и др.);

4) пустые (базовые) ЭС, т.е. ЭС, не содержащие знаний ни о какой проблемной области (например, EMYCIN, KAS и др.).

В приведенной классификации инструментарии расположены в порядке убывания трудоемкости, требуемой для создания с их помощью прототипа. При использовании инструментария первого типа в задачу разработчика входит программирование всех компонент ЭС на языке довольно низкого уровня. Использование инструментария второго типа позволяет значительно повысить уровень языка, что, как правило, влечет за собой снижение эффективности. Инструментальные средства третьего типа позволяют разработчику не программировать некоторые или все компоненты ЭС, а выбирать их из заранее составленного набора. Обычно инструментарии этого типа подразделяют на средства, автоматизирующие построение ЭС (например, RLL, HEARSAY-III), и средства, автоматизирующие процесс приобретения знаний (например, TEIRESIAS).

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

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

2) язык представления знаний, принятый в базовой системе, может не подходить для данного приложения.

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

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

Перед тем, как перейти к рассмотрению отдельных этапов разработки ЭС, перечислим специальности участников данного процесса:

1) эксперт в той проблемной области, задачи которой будет решать ЭС;

2) инженер по знаниям - специалист по разработке ЭС;

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

 

Требования

 

 

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

 

Этап идентификации.

На данном этапе решаются следующие задачи:

· определяются участники процесса проектирования и их роли;

· идентифицируется проблема;

· определяются ресурсы и цели.

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

Идентификация проблемы заключается в составлении неформального (вербального) описания решаемой проблемы. В этом описании указываются:

общие характеристики проблемы;

подпроблемы, выделяемые внутри данной проблемы;

ключевые понятия и отношения;

входные данные;

предположительный вид решения;

знания, релевантные решаемой проблеме.

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

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

 

Этап концептуализации.

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

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

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

 

Этап формализации.

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

Процесс формализации зависит от трех основных факторов:

1) структуры пространства поиска, характеризующей особенности решаемой задачи;

2) модели, лежащей в основе проблемы;

3) свойств данных рассматриваемой проблемы.

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

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

1) данные достоверны (надежны и точны) / недостоверны (ненадежны и неточны);

2) данные полны (достаточны), согласованы, неизбыточны / неполны, несогласованы, избыточны;

3) данные характеризуются / не характеризуются коэффициентом определенности;

4) интерпретация данных зависит / не зависит от порядка их появления во времени.

Большое значение имеют также способ и стоимость приобретения данных.

 

Этап выполнения

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

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

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

При разработке ЭС-2 решаются следующие задачи:

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

2) осуществление структурирования знаний;

3) анализ функционирования системы при значительном расширении базы знаний;

4) исследование возможностей системы в решении более широкого круга задач и принятие мер для обеспечения таких возможностей;

5) анализ мнения пользователей о недостатках системы, о том, какую дополнительную помощь пользователь хочет получать от системы и т.п.;

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

 

Этап тестирования

В ходе этого этапа осуществляется оценка выбранного способа представления знаний и всей системы в целом. Задача инженера по знаниям заключается в подборе примеров, обеспечивающих всестороннюю проверку ЭС. Обычно выделяют следующие источники неудач в работе системы: 1) тестовые примеры; 2) ввод/вывод; 3) правила вывода; 4) управляющие стратегии.

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

 

Этап опытной эксплуатации

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

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

 

Модификация системы

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

Стадии ЭС и инструментариев

Стадии характеризуют степень проработанности и отлаженности ЭС и инструментариев. Выделяют следующие стадии существования ЭС:

1) демонстрационный прототип; 2) исследовательский прототип; 3) действующий прототип; 4) промышленная система; 5) коммерческая система.

Демонстрационный прототип - ЭС, которая решает часть требуемых задач, демонстрируя жизнеспособность метода ЭС. При наличии развитых инструментальных средств для разработки демонстрационного прототипа требуется в среднем примерно 3 месяца. Демонстрационный прототип работает при наличии в базе знаний порядка 50-100 правил.

Исследовательский прототип - ЭС, которая решает все требуемые задачи, но неустойчива в работе и неполностью проверена. На доведение ЭС до стадии исследовательского прототипа уходит примерно 1-2 года. Исследовательский прототип обычно имеет в базе знаний 200-500 правил, описывающих проблемную область.

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

Промышленная система обеспечивает высокое качество решений всех задач при минимуме времени и памяти. Процесс преобразования действующего прототипа в промышленную систему состоит в расширении знаний (до 1000-1500 правил) и в переписывании ЭС с использованием более эффективных инструментальных средств. Доведение ЭС до стадии промышленной системы требует примерно 2-4 года.

Обобщение задач, решаемых ЭС на стадии промышленной системы, позволяет перейти к стадии коммерческой системы, т. е. к системе, пригодной не только для собственного использования, но и для продажи различным потребителям. Доведение до стадии коммерческой системы требует примерно 3-6 лет; при этом база знаний системы увеличивается до 1000-3000 правил.

Программные инструментальные средства по степени их отработанности обычно классифицируются на три стадии:

1) экспериментальные системы;

2) исследовательские системы;

3) коммерческие системы.

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