Методология построения ЭС
Методология построения ЭС.
1. Подход к проектированию ЭС.
Проектирование
ЭС имеет существенное отличие от проектирования традиционных информационных
систем в силу того, что постановка задач, решаемых экспертной системой может
уточняться во время всего цикла проектирования. Вследствие этого возникает
потребность модифицировать принципы и способы построения базы знаний и аппарата
лгического вывода в ходе проектирования по мере того, как увеличивается объем
знаний разработчиков о предметной области.
В
силу отмеченных особенностей при проектировании ЭС-м применяется концепция
“быстрого прототипа”. Ее суть: разработчики не пытаются сразу построить
законченный продукт. На начальном этапе создается прототип, к-рый должен
удовлетворять двум условиям:
1)
он должен решать типичные задачи предметной области;
2)
с другой стороны трудоемкость его разработки должна быть очень незначительной.
Для
удовлетворения этих условий при создании прототипа используются инструментальные
средства, позволяющие ускорить процесс программирования ЭС (скелетные языки,
оболочки ЭС). В случае успеха прототип должен расширяться дополнительными
знаниями из предметной области. При неудаче может потребоваться разработка
нового прототипа или проектировщики могут прийти к выводу о непригодности
методов искуственного интеллекта для данного приложения.
По
мере увеличения знаний о предметной области прототип может достичь такого
состояния, когда он успешно решает все требуемые задачи в рамках предметной
области. В этом случае требуется преобразование прототипа в конечный продукт
путем его перепрограммирования на языках “низкого уровня”, что обеспечит
увеличение быстродействия и эффективности программного продукта.
Кол-во
разработчиков ЭС не должно быть меньше 4 чел., из к-рых 1 явл-ся экспертом ПО,
2 - инженеры по знаниям или проектировщики ЭС, 1 - программист, осуществляющий
модификацию и согласование инструментальных средств.
В
дальнейшем, в процессе преобразования прототипа в конечный продукт, состав
программистов должен быть увеличен.
2. Основные этапы разработки ЭС.
1.
Идентификация.
2.
Концептуализация.
3.
Формализация.
4.
Выполнение.
6.
Тестирование.
a.
Переформулирование
b.
Переконструирование
c.
Усовершенствование
В
состав функций этапа 1 входит:
1)
определение команды проектировщиков, их роли, а также формы взаимоотоношений;
2)
определение целей разработок и ресурсов;
3)
описание общих характеристик проблемы, входных данных, предполагаемого вида
решения, ключевых понятий и отношений.
Типичные
ресурсы этого этапа: источники знаний, время разработки, вычислительные
ресурсы, объем финансирования.
На
этапе 2 эксперт и инжинер по знаниям формализуют ключевые понятия, отношения и
характеристики, которые выявлены на предыдущем этапе. Данный этап призвн решить
следующие вопросы:
определить
типы данных, выводимые понятия, используемые стратегии и гипотезы, виды
взаимосвязей между объектами, типы ограничений, накладываемых на процесс
решения задачи, состав знаний, которые используются для выработки и обоснования
решений.
Опыт
показывает, что для успешного решения вопросов этого этапа целесообразно
составлять протокол действий и рассуждений экспертов в процессе проектирования.
Такой протокол обеспечивает инженера по знаниям словарем терминов и вто же
время заставляет эксперта осмысленно относиться к своим словам.
На
этом этапе не требуется добиваться полной определенности и корректности всех
заключений, а следует наметить лишь основные типовые направления решения
проблемы.
На
этапе 3 производится описание всех ключевых понятий и отношений на формальном
языке. Инженер по знаниям производит анализ инструментальных систем и
определяет их пригодность для конкретного приложения. Выходом данного этапа
является формальное описание всего процесса решения жадачи на уровне
декларативных и процедурных знаний. Инженер по знаниям определяет структуру
пространства поиска решений, выбирает и обосновывает модель знаний, определяет
состав метазнаний, которые затем могут быть положены в механизм логического
вывода. При работе со знаниями изучается степень их достоверности,
согласованность и избыточность, реализуется функция принадлежности различных
оценочных показателей (например, коэффициентов уверенности), а также
закладывается определенная интерпретация знаний в формальных структурах.
Этап
4 заключается в разработке одного или нескольких прототипов. Этот этап
выполняется программистом и заключается в наполнении базы знаний
инструментальной системы конкретными знаниями, а также программировании
отдельных компонент системы. Обычная ошибка программиста заключается в том, что
процесс наполнения базы знаний реальными знаниями откладывается до окончания
программирования. Если база знаний заполняется с начала разработки прототипа,
то это позволяет своевременно уточнить структуру знаний и быстро изменить
программные компоненты.
Первый
прототип должен быть готов уже через 2 месяца. При работе с ним программист
доказывает, что выбранные структуры и методы пригодны для данного приложения и
могут быть в дальнейшем расширены. При этом он совсем не заботится об
эффективности машинной реализации. После завершения первого прототипа круг
задач расширяется и на этой основе формируется следующий прототип. После
достижения достаточно эффективного функционирования ЭС на базе прототипов,
совершенствуются структуры декларативных и процедурных знаний, а также
процедуры логического вывода. Основная трудность состоит в том, что очень часто
в системе имеются громоздкие правила или много похожих правил. Неверно
выбранные управляющие стратегии, в которых порядок выбора и анализа понятий
существенно отличается от технологии эксперта. На этом этапе очень важно
посвящать эксперта во все проблемы, связанные с получением решений, и
внимательно проводить анализ мнения эксперта о недостатках системы.
Этап
5 оценивает пригодность ЭС для конечного пользователя. При этом разработчики
стараются привлечь как можно больше пользователей различной квалификации,
которые могут обращаться к системе для реализации разнообразных запросов. Для
того, чтобы не дискредитировать систему в глазах пользователя, разработчики
перед этим этапом должны устранить все ошибки в работе системы, даже мелкие
технические ошибки. Пользователь анализирует систему с точки зрения полезности
(возможность системы в ходе диалога определить потребности пользователя,
выявить и устранить причины его неудач в работе) и удобства (настраиваемость на
уровень квалификации пользователя, а также устойчивость к ошибкам).
По
результатам 5-го этапа может понадобиться не только модификация программного
обеспечения, но и идеологии разработки интерфейса.
Этап
6. Призван осуществлять оценку системы в целом. Тут необходимо особое внимание
уделить подбору тестовых примеров. В них должны найти отражение следующие
случаи:
неверно
сформулированныые вопросы пользователя;
присутствие
неопределенности в вопросах пользователя;
доступность
для пользователя лексики системы;
доступность
для пользователя объяснений, которые выдает система;
проиворечивость
и неполнота правил;
По
результатам 6-го этапа осуществляется модификация системы. Наиболее простым её
видом явл-ся усовершенствование прототипов. Этот вид затрагивает только этапы 4
и 6.
Более
серьёзным видом модификации явл-ся переконструирование представлений. Этот вид
модификации необходим в том случае, если обнаруживается, что желаемое поведение
системы не достигнуто. Предполагается возврат на этап формализации и далее
осуществляется весь цикл проектирования. Если проблемы функционирования системы
еще более серьёзны, то приходится возвращаться на этапы 2 и 1 для
переформулирования требований к системе и основных понятий.
3. Практические аспекты разработки и
внедрения ЭС.
В
соответствии с результатами тестирования ЭС может находиться на одной из
следующих стадий:
1)
демонстрационный прототип (решает только часть задач в рамках ПО, демонстрируя
правильность выбранного аппарата логического вывода). Срок доведения системы до
этой стадии - около 3-х мес., кол-во правил в базе знаний - 50-100.
2)
исследовательский прототип (решает все задачи в рамках ПО, на недостаточно
устойчива в работе, не полностью проверена). Срок доведения - 1-2 года, кол-во
правил - 200-500.
3)
действующий прототип (решает стабильно все задачи в рамках ПО, но недостаточно
эффективна в работе, в том числе нерациональное использование памяти, невысокое
быстродействие). 2-3 г., 500-1000.
4)
промышленная система (обеспчивает эффективную работу и высокое качество
решений, содержит по сравнению со стадией 3 намного больше правил в базе
знаний, программное обеспечение по сравнению с 3) переписано на язык низкого
уровня). 2-4 г., 1000-1500.
5)
коммерческая система (предполагает обобщение задач, уход от специфики ПО,
предназначается для продажи другим потребителям. Развита по сравнинию с 4)
система редактирования знаний, интерфейса с конкретным пользователем,
обучения). 3-6 лет, 1000-3000.
В
процессе проектирования ЭС следует учитывать тот отрицательный опыт, который
накоплен разработчиками на каждой стадии проектирования.
На
этапе 1 может оказаться, что система или задача настолько трудна, что её нельзя
реализовать в рамках выдеенной проектировщиком системы ресурсов (время, деньги
и т. д.). Проектировщики должны очень внимательно подойти к вопросу, сможет ли
решение задачи принести существенную пользу, для пресонала, который её
эксплуатирует. Следует учесть, что для сокращения времени проектирования нельзя
расширять состав проектировщиков, так как процесс проектирования итеративный и
категории проектировщиков не могут в сжатые сроки осмыслить все этапы
проектирования.
Традиционной
ошибкой этапа 3 явл-ся подгонка инструментального средства под понятия и
взаимосвязи конкретной ПО.
Нельзя
соглашаться при разработке прототипа на программирования сразу же на языках
низкого уровня, т. е. без использования инструментальной системы.
На
всех стадиях проектирования инженер по знаниям работает с экспертом и при этом
возникает целый ряд трудностей, которые заранее надо учитывать:
эксперты
всегда должны быть высококвалифицированными, их нужно заинтересовывать
материально;
эксперт
никогда не может найти время на работу с инженером по знаниям;
в
системе обязательно должна использоваться та же терминология, что и у экспертов
ПО; только в этом случае эксперт может успешно понимать структуру базы знаний и
вносить в неё соответствующие изменения;
с
течением времени эксперт теряет интерес к проекту системы и постоянно сокращает
время работы с проектировщиком. Для устранения этого проектировщик вносит
изменения в систему только вместе с экспертом, тестирует также вместе с ним;
эксперт
незнаком, как правило, с компьютером, поэтому РС устанавливается на его рабочем
месте и доработка системы производится там же;
при
извлечении знаний эксперта проектировщику очень трудно отделить знания ПО от
метазнаний, поэтому работа с экспертом должна происходить не по всем вопросам в
целом, а по строго спланированным инженером по знаниям порциям.
При
разработке первого прототипа необходимо стремиться к тому, чтобы в базу знаний
попали простые универсальные правила и сокращать количество специфических
правил.
На
этапе 6 следует учитывать, что если размер правил превышает 300, то их
исправление и добавление может привести к появлению новых ошибок, поэтому
должен существовать специальный тест, который проверяет систему на
непротиворечивость правил.
Список литературы
Для
подготовки данной работы были использованы материалы с сайта http://www.parny.by.ru/