Трудности разработки экспертных систем - Разработка интеллектуальных подсистем САПР
При разработке ЭС разработчиков поджидают различные трудности:
Глобальные, имеющие отношение ко всему процессу разработки или к нескольким этапам разработки;
Локальные, проявляющиеся в основном на некотором этапе разработки.
Глобальные Трудности. Это общие проблемы, с которыми сталкивается коллектив, пытающийся применить технологию ЭС для решения своих задач.
Источником глобальных трудностей являются, по крайней мере, следующие факторы: недостаток ресурсов; ограничения существующих ЭС; длительность разработки ЭС. Рассмотрим эти факторы подробнее.
Недостаток ресурсов для создания ЭС выражается в нехватке человеческих, программных и аппаратных ресурсов. В связи с относительной новизной направления практически отсутствуют инженеры по знаниям, очень мало специалистов по разработке инструментальных средств (ИС) для систем ИИ и ЭС.
Ограничения программных ресурсов выражаются в слабом развитии ИС, что приводит к чрезмерной длительности и трудоемкости разработки ЭС.
Ограничения существующих ЭС можно разделить на ограничения, присущие существующим ИС, и на ограничения, присущие собственно ЭС. К ограничениям собственно ЭС следует отнести следующие: крайне слабые возможности по работе с динамическими мирами, требующими представления времени и (или) пространства; недостаточные возможности ЭС по генерации умозаключений, основанных на "здравом смысле"; ЭС плохо распознают ситуации, когда пользователь выходит за рамки их возможностей (что приводит к непредвиденным неудачам); как правило, ЭС не способны определить несогласованность (противоречивость) знаний, объяснить причину несогласованности и устранить ее. К ограничениям ИС можно отнести следующее: они могут оказать очень малую помощь в процессе приобретения и корректировки знаний в наиболее трудоемком аспекте разработки ЭС; существующие отечественные инструментальные средства, как правило, не позволяют использовать смешанное представление (например, правила и фреймы).
Процесс разработки ЭС довольно длительный, и это является существенным ограничением при выборе данного способа реализации задачи.
Локальные Трудности. Инженер по знаниям на разных этапах создания ЭС может столкнуться с локальными трудностями.
На этапе идентификации основные трудности возникают при решении следующих проблем:
1. Определение пригодности методов инженерии знаний для решения предлагаемой задачи. При решении данной проблемы могут возникнуть следующие препятствия:
Задача слишком сложна и не может быть решена доступными ресурсами в пределах заданных ограничений (время, тип ЭВМ и т. п.);
Задача может быть решена ЭС, но пользователь не получит от ее решения существенной пользы;
Задача может быть решена, но либо требуется ввести слишком много правил и объектов (что чрезмерно затянет процесс разработки), либо результирующая система работает слишком медленно.
Чтобы выявить сложность задачи, инженер должен разработать небольшой прототип ЭС, работа которого позволит надежно ответить на вопрос о приемлемости задачи. В простых случаях ответ на этот вопрос можно получить, имея опыт разработки ЭС, при анализе описания задачи. Для выявления полезности ЭС следует до ее разработки ответить на следующий вопрос: если ЭС буде работать хорошо, то будет ли это давать тот эффект, которого хочет достичь пользователь?
Другими словами, надо понять, не окажется ли, что для удовлетворения потребностей пользователя надо решать еще какие-то задачи, не предусмотренные в данной ЭС. Для преодоления последнего из перечисленных препятствий необходимо ограничить задачу или область ее приложения. Надежным средством выявления наличия или отсутствия данной трудности являете разработка прототипа.
- 2. Определение необходимых ресурсов. При решении этой проблемы возникают следующие препятствия: срок разработки ЭС назначается на основании анализа, выполненного инженером по знаниям, а потребностей пользователей (интерактивная природа процесса приобретения знаний существенно ограничивает эффективность ускорения разработки ЭС за счет увеличения числа разработчиков); попытка разработать ЭС без инженеров по знаниям, а только с помощью программистов приводит либо к чрезмерному увеличению сроков разработки, либо к ее полной неудаче. 3. Выбор эксперта. При работе с экспертом может оказаться, что процесс извлечения знаний протекает чрезвычайно неэффективно. Наиболее вероятной причиной этого обычно является неправильный выбор эксперта. При выборе эксперта к нему следует предъявлять следующие требования: высокая компетентность в данной проблемной области; способность ясно, просто и доходчиво выражать свои идеи и методы; наличие у эксперта заинтересованности в разработке ЭС; эксперт должен верить в полезность использования вычислительной техники при решении данной задачи (чем больше эксперт знает об ЭВМ и программировании, тем лучше); эксперт должен хотеть и быть способен уделять разработке ЭС примерно половину своего рабочего времени в первые полгода разработки и примерно одну треть времени в последующее время.
На этапе концептуализации могут встретиться следующие трудности:
- 1. К работе подключено излишне много экспертов. Инженер по знаниям, общаясь со всеми, не имеет возможности глубоко исследовать данную область. Инженеру рекомендуется работать только с одним или двумя экспертами. После построения прототипа для его тестирования и модификации целесообразно подключать дополнительных экспертов. 2. Инженер по знаниям выявляет правила, наблюдая за тем, как эксперт решает конкретные задачи, что может привести к образованию специфических правил. Для преодоления этой трудности инженер должен пытаться выявить общие принципы, используемые экспертом. Часто оказывается полезным введение понятий высокого уровня, которые эксперт фактически использует, но не называет, так как они им не вербализованы (в научной литературе такие понятия не введены). Введение этих понятий может позволить заменить несколько специфических правил одним общим. 3. После нескольких месяцев взаимодействия с экспертом инженер по знаниям выделил несколько сотен правил и представил их в выбранном языке. Однако начало проверки прототипа показывает, что многие фундаментальные понятия в приобретенных правилах отсутствуют (т. е. выявлены ошибки, допущенные на этапе концептуализации). Чтобы описанная выше ситуация не возникла, опытный инженер по знаниям осуществляет тестирование принятых решений в ходе всех этапов разработки, а не только по окончании этапа выполнения.
На этапе формализации основные проблемы относятся к выбору и использованию инструментальных средств. Можно выделить следующие трудности.
- 1. При использовании выбранного ИС инженеры по знаниям (разработчики) приходят к выводу, что в нем трудно представлять как понятия области экспертизы, так и управляющие структуры, необходимые для решения задачи. Выбор ИС и определение его пригодности для данного приложения весьма сложны и неформальны. Поэтому разработчики, как правило, могут оценить сделанный выбор только после разработки в нем небольшого прототипа. Если разработчики приходят к выводу, что выбранное инструментальное средство не подходит для данной проблемы, то необходимо либо выбрать другое ИС, либо разрабатывать новое (в этом случае практически дело сводится к откладыванию разработки ЭС на неопределенный срок). 2. Инженер по знаниям выбирает то ИС, которым он хорошо владеет, а не то, которое наиболее соответствует данной проблемной области. При этом, если ИС явно плохо подходит, инженер прилагает усилия к изменению исходной задачи (что может снизить или устранить практическую значимость создаваемой ЭС), чтобы она подходила под выбранное им ИС. Для устранения подобных затруднений руководитель проекта по разработке ЭС должен при выборе ИС проконсультироваться с несколькими инженерами по знаниям, чтобы убедиться в обоснованности сделанного выбора. Кроме того, сам инженер по знаниям должен осознавать наличие подобной ловушки и тщательно подходить к проблеме выбора инструментального средства. 3. В качестве ИС выбирается (на начальных этапах разработки ЭС) один из общецелевых языков программирования (например, Паскаль, Си, Фортран), что приводит к чрезмерному увеличению времени разработки ЭС или к полной неудаче всего проекта. Ошибочность подобного выбора состоит в том, что для выполнения таких наиболее трудоемких работ, как наполнение экспертной системы знаниями, тестирование и корректировка БЗ, общецелевые языки плохо приспособлены. Более правильно разработать ЭС, используя инструментальные средства, ориентированные на разработку экспертных систем, и затем, если ЭС будет работать медленно, переписать ее, используя общецелевые языки программирования. 4. Выбранное ИС содержит ошибки, препятствующие использованию многих из его свойств. Для предотвращения указанной трудности рекомендуется: избегать ИС, не находившихся в употреблении; не использовать инструментальные средства, которые более не сопровождаются разработчиком; выбирать то ИС, которое сопровождается разработчиком и было успешно использовано в других применениях.
В ходе этапа выполнения могут встретиться следующие основные трудности:
- 1. Эксперт теряет интерес к разработке ЭС. Время, которое он выделяет на работу с инженером по знаниям, постоянно сокращается. В подобных ситуациях рекомендуется: поддерживать интерес эксперта к работе, обеспечивая; дружественную обстановку; объяснять, что для успеха необходимы регулярные контакты (не реже 2-3 раз в неделю); помнить, что эксперт не специалист в программировании и ЭС, и не требовать от эксперта того, что он не умеет делать; предоставить эксперту возможность непосредственного наблюдения за результатами предлагаемых им изменений БЗ. 2. Эксперт при корректировке БЗ прототипа не совсем понимает, как система интерпретирует правила. Чтобы избежать указанного затруднения, рекомендуется: использовать в правилах ту же терминологию, которую использует эксперт; хранить в системе определения всех используемых понятий и иметь возможность выдавать их по требованию пользователя; если правила во внутреннем представлении "нечитаемы", то иметь средства для преобразования правил в вид, понятный пользователю. 3. Правила, введенные экспертом, в сложных ситуациях не позволяют прототипу ЭС получить качественные решения. Для преодоления данного затруднения рекомендуется: ориентировать эксперта на решение реальных, а не "игрушечных" задач; наблюдать за работой эксперта, стремясь выделить все типы возможных задач (подзадач); привлекать для оценки работы прототипа других экспертов. 4. Для построения ЭС было выбрано ИС без объяснительных способностей. После отработки ЭС разработчики пытаются дополнить ЭС этим механизмом, однако обычно сделать это чрезвычайно трудно. Чтобы не сталкиваться с подобными трудностями, разработчики должны выбирать ИС с объяснительными способностями. Объяснения ускоряют отладку, тестирование, модификацию прототипа и обеспечивают удобство для конечного пользователя и эксперта. 5. В процессе разработки ЭС знания об области экспертизы переплетаются с общими знаниями о решении задач (проблемно-независимыми знаниями), что затрудняет (делает невозможным) проведение модификации и развития ЭС. По сути дела, нарушается основной принцип разработки ЭС отделение знаний эксперта от остальных знаний и представление знаний эксперта в явном виде.
На этапе тестирования и опытной эксплуатации могут встретиться следующие трудности:
- 1. Тестирование не выполняется в ходе разработки, а впервые осуществляется после этапа выполнения. При подобном подходе вероятность отрицательной оценки ЭС очень велика. Кроме того, весьма вероятно, что перепроектирование ЭС придется начать с ранних этапов (идентификации и концептуализации). Общая рекомендация при разработке экспертных систем состоит в проведении тестирования и оценки как можно раньше. Поэтому на начальных этапах разработчики ЭС должны составить методику оценки пригодности и полезности конечного продукта, что позволит по ходу разработки (а не в ее конце) оценивать состояние проекта и прогнозировать срок его успешного завершения. 2. Пользователи (эксперты) находят процесс взаимодействия с ЭС трудным и неудобным: им не понятны сообщения системы, время реакции ее велико, возможности неочевидны и трудноиспользуемы и т. п. Для устранения подобных ситуаций целесообразно освободить пользователей от любой технической работы, непосредственно не связанной с областью экспертизы (работа с операционной системой, сопровождение словарей, взаимодействие с "недружественным" редактором). Недопустимо использовать аббревиатуры. 3. Если правил больше нескольких сотен, возникают затруднения с дальнейшей корректировкой и добавлением их, так как внесение одних изменений порождает цепь других, процесс перестает быть управляемым и кажется бесконечным. Выход из подобных ситуаций разработка системы сопровождения, запоминающей, какие задачи решены, какие получены результаты, какие правила использованы, когда и какие изменения внесены и т. п.
Похожие статьи
-
Прикладные интеллектуальные системы - Разработка интеллектуальных подсистем САПР
Экспертные Системы это наиболее распространенный класс ИС, ориентированный на тиражирование опыта высококвалифицированных специалистов в областях, где...
-
Чтобы не заканчивать эту главу на такой печальной ноте, я решил включить в последний раздел избранные максимы о построении экспертных систем, почерпнутые...
-
При разработке практически всех инструментальных средств за основу принимается методология автоматизации проектирования на базе использования прототипов....
-
- Статические ЭС разрабатываются в предметных областях, в которых база знаний и интерпретируемые данные не меняются во времени. Они стабильны. Пример:...
-
Введение в экспертные системы. Определение и структура - Разработка интеллектуальных подсистем САПР
В качестве рабочего определения экспертной системы примем следующее. Экспертные Системы это сложные программные комплексы, аккумулирующие знания...
-
Введение - Разработка интеллектуальных подсистем САПР
Разработка интеллектуальных подсистем САПР производится в рамках теории искусственного интеллекта. Искусственный интеллект (ИИ) это область исследований,...
-
Типы экспертных систем - Теоретические основы информационных технологий
Можно назвать несколько Типов современных экспертных систем . 1) Экспертные системы первого поколения. Предназначены для решения хорошо структурированных...
-
Экспертные информационные системы - Системы поддержки принятия решений
Наибольший прогресс среди компьютерных информационных систем отмечен в области разработки экспертных систем. Экспертные системы дают возможность...
-
Объектно-ориентированные языки - Инструментальные средства разработки экспертных систем
В главе 12 мы уже обращали ваше внимание на то, что формат правил хорошо согласуется с представлением знаний в форме "при выполнении условий СЬ ..., С"...
-
Подсистема приобретения знаний, База знаний - Экспертные системы
Подсистема приобретения знаний предназначена для добавления в базу знаний новых правил и модификации имеющихся. В ее задачу входит приведение правила к...
-
Класс ЭС сегодня объединяет несколько тысяч различных программных комплексов, которые можно классифицировать по различным критериям. Классификация по...
-
Экспертные системы - Теоретические основы информационных технологий
Наибольший прогресс среди компьютерных информационных систем отмечен в области разработки экспертных систем (ЭС), основанных на использовании элементов...
-
Концептуализации - Экспертные системы, методика построения
На данном этапе проводится содержательный анализ проблемной области, выявляются используемые понятия и их взаимосвязи, определяются методы решения задач....
-
Экспертные системы (ЭС) - История создания и развития автоматизированных информационных систем
Наибольший прогресс среди компьютерных информационных систем отмечен в области разработки экспертных систем, основанных на использовании искусственного...
-
Определение экспертных систем. Главное достоинство и назначение экспертных систем. Экспертные системы (ЭС)- это яркое и быстро прогрессирующее...
-
Языки программирования высокого уровня - Инструментальные средства разработки экспертных систем
Языки высокого уровня являются в руках опытного программиста прекрасным средством быстрого создания прототипа экспертной системы, позволяют обеспечить...
-
Основные компоненты - История создания и развития автоматизированных информационных систем
Основными компонентами информационной технологии, используемой в экспертной системе, являются (рис. 3.2.2): интерфейс пользователя, база знаний,...
-
Если множество элементов объединено в систему по определенному признаку, то всегда можно ввести некоторые дополнительные признаки для разделения этого...
-
Хорошо продуманный интерфейс, подобно хорошему учителю и учебникам, обеспечивает плодотворное взаимодействие пользователя и компьютера. Удачные...
-
В работе использовались следующее программное обеспечение для решения поставленных задач: AutoCAD, ANSYS Workbench, ANSYS Icepak. Система AutoCAD...
-
Корпоративная интеграционная подсистема на базе IBM WebSphere Business Integration Message Broker [28] отвечает за выстраивание корпоративной...
-
В настоящее время существует большое количество поисковых систем, но большинство из них основано на методе, в соответствии с которым документы...
-
Планирование., Интерпретация., Контроль и управление. - Экспертные системы
Под планированием понимается нахождение планов действий, относящихся к объектам, способным выполнять некоторые функции. В таких экспертных системах...
-
Области применения экспертных систем - Экспертные системы
Области применения систем, основанных на знаниях, могут быть сгруппированы в несколько основных классов: медицинская диагностика, контроль и управление,...
-
Результатом развития современных интеллектуальных технологий является возникновение понятия "искусственный интеллект". Искусственный интеллект - это...
-
Языки описания порождающих правил - Инструментальные средства разработки экспертных систем
Но, естественно, возможности языков высокого уровня также не беспредельны -- каждый из них имеет свои ограничения. Например, в языке OPS5 возможности...
-
Кроме поддержки интерпретатора порождающих правил, описанного в главе 5, CLIPS обладает следующими функциональными возможностями: - для определения...
-
Подсистема интеллектуального анализа данных используется специальной категорией пользователей-аналитиков, которые на основе ИХ обнаруживают...
-
Основные средства администрирования системы 1С:Предприятие реализованы в составе конфигуратора. Однако есть ряд механизмов и утилит, которые не входят в...
-
Системы поддержки принятия решений - Системы поддержки принятия решений
Система поддержки принятия решений или СППР (Decision Support Systems, DSS) -- это компьютерная система, которая путем сбора и анализа большого...
-
В ходе эксплуатации возможны сбои и неисправности в работе компьютерной системы. Все неисправностей, которые по тем или иным причинам возникают в ПК или...
-
Введение - Разработка и тестирование автоматизированной системы контроля успеваемости студентов
Тема разработки автоматизированной системы контроля успеваемости и вычисления оценок слабо освещена в научной литературе со стороны вычислительной части...
-
Предложенный подход к решению задач исследования Используя в качестве основы присутствующее в наличии программное обеспечение, которое применимо к...
-
Выбор системы управления базами данных является одним из важных этапов при разработке автоматизированной системы расписания занятий. Выбранный...
-
Задача составления расписаний являются предметом научных исследований с середины прошлого века. Область их применения включает в себя различные сферы...
-
В связи с увеличением числа сотрудников, работающих в компании, а также с расширением рабочего проекта, возникла проблема, связанная с версионностью...
-
Техническое задание - Разработка информационно-справочной системы "Аптека"
Техническое задание представляет собой документ, в котором сформулированы основные цели разработки, требования к программному продукту, определены сроки...
-
Компонент вывода - Экспертные системы
Его действия основаны на применении правила вывода, обычно называемого модус поненс, суть которого состоит в следующем: пусть известно, что истинно...
-
В результате проведенной работы были спроектированы и реализованы модули редактора и вебсайта. Были решены поставленные в работе задачи в полном объеме....
-
Стадии создания САПР - Состав систем автоматизированного проектирования
Создание и развитие САПР осуществляется самой проектной организацией с привлечением (при необходимости) других организации-соисполнителей, в том числе...
Трудности разработки экспертных систем - Разработка интеллектуальных подсистем САПР