Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Ваша задача — разработать три новых управляющих правила, которые организуют работу правил clash, start и finish.Содержание книги
Поиск на нашем сайте
I) Правило fixstart будет активизироваться в случае, если предложения, сформированные всеми прочими правилами для подцели start, будут нарушать ограничения. Это новое правило выделяет вектор schedule для задачи и присваивает его полю start значение, которое хранится в слоте latest элемента errand. II) Измените существующее правило unstart таким образом, чтобы оно заменяло подцель в выражении goal с start на fix вместо прежней замены start на finish. III) Разработайте правило unfix, которое будет заменять подцель в выражении goal с fix на finish. Затем выполните следующее. IV) Протестируйте программу и убедитесь, что она справляется с проблемой на наборе исходных данных, установленном в упр. 5. V) Эвристика, использованная в правиле clash, не может справиться со всеми возможными случаями. Постарайтесь найти такой вариант исходных данных, который поставит программу "в тупик", несмотря на то, что построить расписание возможно. 7. В программе составления расписания используется единственный вид ограничений — ограничения по времени, запрещающие наложение мероприятий. Давайте добавим в нее пару ограничений, специфических для мероприятий определенного вида, — это будут своего рода специфические знания о предметной области. Например, логично ввести ограничение, отражающее тот факт, что для выполнения покупки или посещения какого-либо заведения сети обслуживания нужно располагать некоторой суммой денег. Следовательно, перед тем как отправляться за покупками, нужно зайти в банк. I) В шаблон мероприятия errand добавьте поле kind (вид). Допустимые значения этого поля — одна из трех символических констант: goods (вещи), service (обслуживание), visit (визит). Такие мероприятия, как посещение банка или врача, относятся к группе visit, посещение парикмахерской (haircut) или ресторана (lunch) — к группе service, а поход в овощную лавку (groceries) или музыкальный салон (guitar-shopping) — к группе goods. II) Включите в число возможных предложений в процессе решения проблемы новую фазу (подцель) tune, которая должна следовать за подцелью start перед fix. Таким образом, можно будет проанализировать введенные специфические ограничения перед тем, как браться за корректировку расписания (подцель fix). При изменении программы вам придется модифицировать правила, манипулирующие лексемами подцели. III) Добавьте правило money, которое будет активизироваться только в том случае, когда -текущей подцелью в рабочей памяти является tune. Правило должно распознавать ситуацию, в которой мероприятие, требующее присутствия определенной наличности в бумажнике, оказывается в расписании раньше, чем посещение банка. Правило должно корректировать расписание, сдвигая в нем такое мероприятие на позднее время, т.е. на время после посещения банка. Если такая коррекция приведет к возникновению конфликтной ситуации в расписании, она будет устранена правилом fix. IV) Протестируйте скорректированную программу на следующем наборе входных данных (фактов): (deffacts the-facts (goal (subgoal start)) (errand (name hospital) (kind visit) (earliest 930) (latest 930) (duration 200) (priority 1)) (errand (name lunch) (kind service) (earliest 1130) (latest 1430) (duration 100) (priority 2)) (errand (name guitar-shop) (kind goods) (earliest 1000) (latest 1700) (duration 100) (priority 3)) (errand (name haircut) (kind service) (earliest 900) (latest 1700) (duration 30) (priority 4)) (errand (name groceries) (kind goods) (earliest 900) (latest 1800) (duration 130) (priority 5)) (errand (name bank) (kind visit) (earliest 930) (latest 1530) (duration 30) (priority 2)) ) 8. Как вы оцениваете методику последовательного уточнения программы, которая была использована при выполнении упр. 4-7? Какие, по-вашему, существуют доводы за и против использования такой методики разработки? ГЛАВА 16. Средства формирования пояснений Формирование пояснений на основе знаний Подсистема формирования пояснений в MYCIN Формирование пояснений в системах, производных от MYCIN Формирование пояснений на основе фреймов Организация вывода пояснений в системе CENTAUR Использование мультимедийного интерфейса для формирования пояснений Формирование пояснений и автоматическое программирование Автоматическое программирование в системе XPLAN Проект Explainable Expert Systems Планирование текстов пояснений и модели пользователей в PEA Перспективы дальнейших исследований методов формирования пояснений Рекомендуемая литература Упражнения ГЛАВА 16. Средства формирования пояснений Формирование пояснений на основе знаний Формирование пояснений и автоматическое программирование Перспективы дальнейших исследований методов формирования пояснений Рекомендуемая литература Упражнения Существуют две причины, которые побуждают разработчиков экспертных систем делать их по возможности "прозрачными" для пользователя. Под прозрачностью при этом понимается способность системы объяснить пользователю, почему принято именно такое решение, вследствие каких рассуждений система пришла к тому или иному выводу. Клиент, который обращается к экспертной системе за советом, должен знать, на основе каких логических доводов этот совет был сформирован. Только получив исчерпывающую информацию о ходе рассуждений, клиент может с доверием отнестись к полученному совету, поскольку за последствия неверно принятого решения расплачиваться придется не столько "советчику", сколько чересчур доверчивому клиенту. Инженер, обслуживающий экспертную систему, должен быть уверен в правильности работы всех подсистем, а проверить это он может, только получив от экспертной системы всю возможную информацию о ходе рассуждений в процессе решения задач. Эту главу мы начнем с краткого обзора ранних работ, касающихся включения в экспертные системы специальных средств, формирующих для пользователя информацию о ходе рассуждений (в дальнейшем для краткости мы будем называть ее поясняющей информацией). Затем более детально будут рассмотрены средства формирования пояснений экспертной системы CENTAUR, о которой уже упоминалось в главе 13. И в заключение мы обсудим одно из последних исследований в этой области, выполненное в рамках проекта Explainable Expert Systems, в котором основное внимание было уделено обеспечению прозрачности экспертной системы с точки зрения инженеров по знаниям, т.е. была предпринята попытка рассмотреть в комплексе вопросы формирования поясняющей информации и извлечения знаний Формирование пояснений на основе знаний На начальном этапе исследований в области экспертных систем, которые выполнялись в Станфордском университете в 60-70-х годах/поясняющая информация предоставлялась в виде трассировки процесса выполнения программы и использовалась в основном для отладки разрабатываемых систем. Этого было достаточно для разработчиков экспериментальных систем, подобных MYCIN, но не соответствовало тому уровню сервиса пользователя, который необходим для коммерческого программного продукта. Впоследствии вопросу формирования информации, которая давала бы возможность пользователю четко представить себе ход рассуждений программы, стало уделяться значительно больше внимания. Исследователи пришли к заключению, что автоматическое формирование пояснений требует доступа к модели предметной области точно так же, как и извлечение знаний (см. об этом в главе 10). Другими словами, представление о знаниях в конкретной области необходимо для предоставления пользователю информации о поведении системы в процессе формирования результата точно так же, как и для приобретения новых знаний. Такое знание позволит перекинуть мост между деталями реализации процесса вывода (например, в какой последовательности активизировались правила) и стратегией поведения системы (например, какие соображения побудили систему выбрать ту или иную гипотезу из множества конкурирующих). В последние десятилетия специалисты серьезно потрудились над развитием этой идеи, и обзор некоторых из полученных результатов читатель найдет в разделе 16.2. Совершенно очевидно, что проблемы извлечения знаний и формирования пояснений тесно связаны. По сути, они представляют две стороны одной медали. Существенным толчком для совершенствования средств, используемых для предоставления пользователю пояснений, как, впрочем, и для извлечения знаний, стало развитие методов графического интерфейса в современных операционных системах, которые обеспечивают возможность вывода не только статической, но и динамической видеоинформации со звуковым сопровождением.
|
||||
Последнее изменение этой страницы: 2016-04-07; просмотров: 221; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 52.14.176.111 (0.01 с.) |