Реализация возможностей экспертных систем в образовательных целях

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

 

 

 

 

 

 

 

 

 

 

 

 

 

2.2.Методы поиска решений в экспертных системах

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

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

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

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

методы  поиска при неточных и неполных данных ;

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Заключение:

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

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

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

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

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

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

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

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

 

 

 

 

 

 

Литература:

 

1. Автоматизированные информационные технологии в экономике: Учебник / Под ред. проф. Г. А. Титоренко. М.: Компьютер, ЮНИТИ, 2003.
2. Автоматизированные рабочие места 2004г.
3. «Инспектор+ : интеллектуальный охранный комплекс» 2005г.
4. Информационные системы для руководителей / Под ред. Ф. И. Перегудова. - М.: Финансы и статистика, 2001
5. Мишенин А. И. Теория экономических информационных систем: Учебник. – М.: Финансы и статистика, 2003.
6. Таунсенд К., Фохт Д. Проектирование и программная реализация экспертных систем на персональных ЭВМ: Пер. с англ. В. А. Кондратенко, С. В. Трубицына. — М.: Финансы и статистика, 1990. — 320 с.