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

Лекция 9

Разберем пример. Был робот Шейки, мы уже говорили о нем, у него была «рука». Были разные геометрические объекты: кубы, пирамиды и другое. Рука – Р, и три кубика А, В, С. Робот видит кубики, понимает что это буква А, а это С. Если дать ему задание построить кубики в алфавитном порядке, он бы поставил (два варианта АВС или СВА).

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

кубиков. В зависимости от этого свойства они делятся на два класса – С и В взять можно, а А – нельзя. Теперь надо думать о втором типе предложений. Надо брать пары и смотреть есть между ними отношения или нет (кубики и стол).

Так нам нужны предикаты как для свойств, так и для отношений:

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

Цель: чтобы рука осталась пустой, А на столе, а С пустое, В на А и С на В. Нам надо узнать как следует из того что мы видим, то что мы должна получить (стрелка). Все эти предложения логические, все они единица. И

между ними «и». Нас интересует ход и чтобы мы могли с этим ходом разобраться нам нужны действия. Эти действия у нас двух сортов, будем различать: положить на стол и положить на кубик, потому что на кубик положить сложнее, там есть кубики на которые положить нельзя.

Если мы хотим брать со стола нам необходимо проверять закрыт этот кубик или нет. И если закрыт, то взять мы не сможем.

Мы принимаем решение работать с четырьмя действиями, и у этих действий есть предусловия и есть что нужно сделать. Если мы к состоянию применим одно из этих четырех действий, то это состояние измениться, это значит в описание придется, что-то удалять, а что-то добавлять. Поэтому мы действуем прямолинейно – все наши действия приводим к тому, что нам надо что-то удалить, а что-то добавить.

Действия – взять со стола, положить на стол, взять со стопки, положить на стопку. Если мы хотим работать со столом, у нас предусловие: то что мы должны взять у нас должно быть на столе – ONTABLE(X), рука робота должна быть не занята, поверхность того кубика, который я беру должна быть чистой. Если мы это действие выполнили или приказали выполнить роботу, то произойдут изменения: если мы взяли со стола – его не будет, он будет в руке робота. Значит вычеркиваем: рука робота занята, кубик уже не на столе и Clear уже ни к чему, потеряло свою актуальность. Три предложения вычеркиваем, добавить, что этот кубик держит кубик. По остальным действиям надо также думать.

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

как на слайде. Если вы работаете по плану, может что-то помешать вашей работе в реальность? Робот у нас игрушка, а мы хотим составлять программы, которые бы решали человеческие задачи реальной жизни, значит мы обязательно должны предусмотреть такие возможности. Роботу Шейки может помешать: кубик со стола упал, стол маленький, кубик сорвался с манипулятора и т.д. Т.е. у робота который живет в нереальном мире очень много причин, по которым может его план сорваться.

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

ЭКСПЕРТНЫЕ СИСТЕМЫ

Мы рассмотрели три классических метода решения задач. Универсального метода решения задач нет. Различных вариантов действий по решению задач много, в частности частичное планирование очень похоже на экспертные системы. Что то сделал, смотрю где оказался, спрашиваю совет. Сократ говорил, что если не знаешь что делать спроси у других, может получишь дельный совет. Не забывайте, что вся идеология Сократа строится на диалогах, они вопросы любил задавать.

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

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

Самое главное что есть деревья и по ним надо двигаться сверху вниз и эти деревья выводят на так называемые продукции. В этих продукциях:

ЕСЛИ <условие> ТО <совет, рекомендация, …>. Значит, в базе знаний лежат эти деревья, а вы продвигаетесь, как пользователь по трассам ЭС. Вот здесь она приведена на уровне общей блок-схемы ЭС.

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

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

Подводные камни:

1.Очень многие специалисты самые свои нужные знания просто забывают, т.е. забывают как они выражены в словах. Ему не надо их запоминать, он их хорошо делает. Знания у него перешли в навыки.

2.Зачастую тот кто знает не хочет этими знаниями делится.

Лекция 10

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

посредник в виде инженера – когнитолога или нет, второй вопрос. Все равно эксперты есть. А эксперт, даже если посредник, но там система приобретения знаний стоит, в любом случае она будет что-то обрабатывать. Она будет обрабатывать протоколы и интервью, интервью между когнитологом и экспертом. Даже если эксперт один, все равно протоколы и интервью – это вопрос и ответы. Ответы, там тексты идут, формулы какие-то. В любом случае вот эти процессы и интервьюирование, и протоколирование они здесь важны. Что хорошо знает эксперт, он забыл. Он хорошо это знает на уровне навыков, а когда это начинает кодировать словами, он делает тьму-тьмущую ошибок и разобраться в том что он там сказал, описал, даже ему трудно. Значит как факт, человеческий фактор на уровне эксперта здесь важен, на уровне знаний, опыта, обработки. Что-то надо делать с интервью. Надо от туда извлекать опыт. Это очень большое направление извлекать опыт, извлекать знания – это термины. Берем инженера – когнитолога, здесь для него, если он посредник, он и выполняет эту работу по извлечению знаний, обрабатывает протоколы, а что он может, он же не специалист, например, в механике. Он только может опыт в форму положить то, что эксперт сказал. И в эти формы он там кладет. Он кладет со своим пониманием, а значит вносит те дефекты связанные с человеческими психологическими характеристиками. Т.е. память, восприятие, представление и т.д. А вот в организации знаний он в принципе силен, что там, структуры данных. Структуризация данных, а тем более структуризация знаний – это очень ответственная работа. Чем хуже вы выбрали структуру данных, тем сложнее обработка.

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

Машинная часть. Вы видели структуру, там интерпретатор, подсистема объяснения знания, рабочая память, сама база. Там многое хранится, с этим приходится работать. Факты, правила, коэффициенты определенности, вывод, логика. Когда человек знает, с чем ему придется столкнуться в разработке экспертной системы, он вооружен.

Экспертных систем, с момента начала работ в этом направлении, было разработано громадное число. Были моменты, когда на

международных конференциях, вопросы по экспертным системам были основные.

Классификация. Вот с каких позиций подходят к классификации, здесь изображено. Вот беру я первую колонку "задача". С позиции логики предикатов вы же ее знаете. Рас знаете, значит вы можете на место поставить предметные единицы, а потом вызывать экземпляры. Т.е. если вот так поступать, четыре места в скобках, а перед скобкой тип. То у вас и появятся вариации с разными значениями экземпляров, причем здесь приведен пример. Вот задачи основные – это диагностика, проектирование, прогнозирование, планирование, обучение. Если задача этого класса, там много проблем, причем экспертных. И большая вероятность, если вам надо разрабатывать там систему, то лучше ее разрабатывать как экспертную. От времени большая зависимость из-за того, что очень многие приложения вычислительной техники, это приложения реального времени. Реальное время – это очень важный параметр. Если вы разрабатываете систему реального времени, там много проблем, потому, что временем ограничен счет и вы должны успеть провести обработку за интервал такта или другой. Может быть псевдо время, динамический процесс, а может быть реальное время. Но две последние колонки я не расшифровываю, они прозрачные.

Что же там происходит в экспертной системе? На этом слайде цикл управления, цикл работы. Это значит базовый шаг, а потом точно такой же, но с другими данными и в других условиях и т.д. Вот здесь показано, вот вход. Это вход запроса, здесь пользователь должен, когда он начинает работу, описать ситуацию в которой он оказался. От него не требуют запроса в каком-то формальном виде, логика чтобы была выражена, и строго синтаксис какой-то учитывался, нет. Здесь естественный языковой вход, но на ограниченном профессиональном языке. Т.е. описание ситуации, в которой оказался человек. Если он описал, то это описание и является самим запросом. Но он знает язык, полуформализованный какой-то, но в тоже время это плохо, лучше, когда естественный язык. Вот первая часть действия экспертной системы – это она ваш текст описания структурирует. Она оттуда что-то извлекает для себя. Обычно это ключи. Хорошо, если вы это подчеркнули. Считайте, что

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

…

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

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

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

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

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

автоматически работать, даже классификационный распрос, он и то автоматизированный, к человеку обращения происходят. Так и здесь. Что за форму для настройки выбрали это уже решать какая помощь нужна пользователю экспертной системы. В информационной части хранится информация о продуктах. Форм хранения много, но в любом случае есть ядро, а в этом ядре как раз самое главное "если - то". Данные лежат в библиотеке. А в библиотеке есть каталоги, есть разделы, в разделах чтото лежит, туда нужно обращаться, от туда нужно доставать.

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

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

– это то, что они придумали проверять то, что человек говорит, опытом.

Это произошло не так давно. Двое Бекконов это придумали, один жил в 13ом веке, другой в 16-ом. Но они н е родственники. Второй Беккон и дал основные законы индуктивного рассуждения. Он их сформулировал словами, а не формально. А 150 лет назад все законы индуктивных рассуждений переформулировали строго. Появился раздел индуктивных логик, который имеет отношение к обработке экспериментальных данных. Новую страницу в индуктивной логике дал Морган. С ним много спорили, но все уже устоялось. В принципе индуктивные рассуждения они совершенно нормальные, вписываются в практику экспертных систем, потому что эксперт – это специалист, который обладает определенным опытом, который n-раз что-то применял, и мы хотим n+1-й раз что-то применить, то что он применял, нам нужны обобщения. Ну по аналогиям ясно, что образцы. Образцы, которые похожи друг на друга, но об одном я зная много, а про тот, который похож, мало, и я начинаю по аналогии переносить знания. В объектно-ориентрованном программировании мы так с объектом знания переносим на экземпляр. Одной из характеристик правдоподобных рассуждений, из-за чего они и правдоподобны, является то, что присутствует степень неопределенности. Эта степень неопределенности о правдоподобии. Раз присутствует неопределенность, значит надо знать, какие вообще неопределенности есть, с которыми сталкивался человек. Эти неопределенности приведены ниже. Это опять другие типы, кроме пяти, которые названы. На остальных я немного остановлюсь. Одним из ложных ключей является один из типов неопределенности, который является популярным. Этот тип неопределенности связан с расплывчатостью и с нечеткими рассуждениями, с одним из видов рассуждений. Но в каждой конкретной задаче могут быть адекватные ей конкретные типы рассуждений. Если там индуктивные, то с какой стати нечеткие механизмы применять – это же ошибка. А вот люди, которые не понимают и не знают этого, а это обычно слабо эрудированные люди. Расплывчатость – важный вид неопределенности, но он не универсален и он специфический, и применять механизмы его нужно тогда, когда для этого есть условие. Вот это направление связано с нечетким множествами Заде, которые популярны сейчас, хотя Заде их открыл 40 лет назад. Надо знать если условия не позволяют надо применять другое, а не свое нечеткое толкать.

Лучше всего о неопределенностях разного типа написано у Шапира. Он свою книгу написал лет 20 назад. Он ее написал исходя из критики Заде. Я у него эту градацию взял. Вот первый тип неопределенностей совершенно прозрачный. Вот вы проводите эксперимент, взвешиваете на весах какую-то массу. У вас стрелка остановилась на каком-то делении, вы прочитали, зафиксировали в табличке. Провели 100 измерений. У вас там постоянно разные числа. Возникает вопрос, чему же равна неопределенность, измерения. Много было споров на счет этого. Максимум до чего договорились измерять в среднеквадратичных каких-то отклонениях. Здесь неточность самая понятная, но не думайте, что она

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

Следующий тип неопределенности – это незнание. Незнание – это достаточно понятный фактор. Это значит, тот кто записывает запрос к экспертной системе, если он что-то не знает, он не включает в запрос, а эксперт это знает он предусмотрел.

Лекция 11 обьяснения

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

более инвариантные чем масса = 2 кг например, или вероятность равна 50%, это события какие-то вы их оцениваете по частотности и всему прочему. Т.е. там числа совершенно нормальные получаются. Вам приходится оценивать не факты, а их набор, а если нужно оценить какойто сложный параметр по 5-ти измеряемым параметрам и вы не знаете как их сложить, но в теории вероятности есть методы сложения, но нужно знать закон распределения. Предположим мы с вероятностных позиций будем подходить оценивать, правило у нас есть, то и это надо оценивать. Если подходить к проблеме оценивания в экспертных системах, то поступают следующим образом: определяют достоверные факторы, определяют достоверность правил и вводят интегрированный фактор достоверности, его вводят на основании вероятностных теорий в виде алгебраической конструкции, где X и Y вычисляют из вероятностей. Здесь я показываю наиболее распространенный пример оценивания в экспертных системах. Здесь показывается, что эти законы хорошо работают, а насколько они адекватны задаче сказать трудно – это всего лишь одна из версий. При разрабатывании экспертных систем, не обойтись без оценивания, приписывания каких-то коэффициентов, характеризующих какую-то достоверность, проще всего использовать то что опробированно и испытанно другими людьми. Очень часто хорошую оценку дает вероятностные меры, которые представлены на следующем слайде. Фактор достоверности в экспертных системах ключ ко всему. Задач в экспертных системах много и в принципе для конкретной задачи чаще всего подходит конкретная мера и если с ней автор работал и говорит что у него эта мера лучше, то приходится ему верить. На доверии в экспертных системах и искусственном интеллекте очень многое и вопрос доверия очень важный. Поговорим поглубже на тему доверия, если оценивание – это большой фронт, который приходится включать в экспертные системы, то обоснование – другой фронт. Этот фронт приходиться включать из-за того, что человек привык что бы ему обязательно что-нибудь объясняли, обосновывали, доказывали. Это правило хорошего тона. Если нет объяснений что-то не то и разработчики экспертных систем знают об этом и они говорят - будем объяснять. На слайде начинается объяснение - это вывод, объясняемый из каких-то оснований. Обоснование, объяснение, основание – это в чем-то синонимы, когда они употребляются с позиции работы по убеждению и показаны варианты с которыми мы уже сталкивались: доказательство – если можно доказать, то хорошо, строго логически, но это редко бывает, но иногда бывает, поэтому когда удается доказать, хорошо, должна так работать система объяснений. В логике предикатов приводился пример, что графы опровержения и все остальное, их можно применять для демонстрации того, как был выведен ответ, вот когда вы показываете саму трассу вывода, вы уже человеком воспринимаетесь серьезно. Если вам говорят: обоснуйте пожалуйста, а вы представляете доказательство, видят что человек серьезный. Если вам не удается дать доказательство, то не

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

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

Доказательство бывают следующих типов: дедуктивное, индуктивное, детективное.

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

Аргументация.

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

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

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

Обоснование. Здесь вам приходиться убеждать, что ваши действия разумные, т. е. что их можно растолковать, оправдать ваши действия. Разумные действия – это если вы думали и от этого остался след, пусть в толкованиях, пусть в чем угодно. Чаще всего растолковывают библию. Был момент в толковании библии, когда родилась целая наука толкования, растолковывания – берминептика. Там свои законы, они отличаются от доказательства, аргументации. Очень близкий к толкованию процесс – это процесс интерпретации, когда вы просто поясняете что за этим стоит. Если вы хотите понять что человек говорит, спросите что стоит за его словами и пусть он попробует нарисовать картину, что стоит за его словами. Нарисует картину, хорошо, - это он вам дал интерпретацию.

Объяснение – это работа, объяснить глагол, если глагол, то необходимо в программировании применять логику предикатов 1-го

порядка. Потому что есть процесс, есть работа, формирование требований, определение спецификаций – это стандартные работы. Если такой вид работы не проводиться программистом, значит он не квалифицированный. Например, приходится разрабатывать подсистему объяснений, эта подсистема объяснений будет реализовывать экземпляры предиката объяснить, а у этого предиката предметная единица цель, объект, способы, адресат,… Предикатов может быть много местный. Вот здесь он 4-х местный объяснить и 4-е позиции цель, объект, способы, адресат. При разработке конкретной системы объяснений, я говорю, по позиции цель моего предиката есть константы. В зависимости от того, кто какие цели преследовал при создании системы объяснений, получить решение с помощью системы объяснений, сократить трудоемкость, повысить квалификацию пользователя. Экспертные знания классифицированы, пользователь массовый, я на систему объяснений кладу такую нагрузку, пусть она обучающую функцию частично выполняет и пусть она каким то образом на пользователя оставляет следы, он учиться и учится все. Я взял четыре экземпляра, повысить квалификацию, получить решение, повысить доверие, но если бы повысить доверие не было, то это была бы ущербная. То я могу в подсистему вложить две подсистемы, одна чтобы повышала квалификацию, а другая повышала доверие, а третья пусть решение, я могу как угодно. Но в тоже время сам факт деления и выделения на месте предметной единицы и констант мне дает спецификации, которые я буду вкладывать в разработку какой то подсистемы, там то мне придется программировать. Если экспертные системы работают в ситуации, а в ситуации те единицы, связь между которыми, они сами образуют ситуации. Может мне придется объяснять что-то об этих единицах, а может мне связности придется объяснять, так вот с этих позиций область интерпретации, она как раз и делит на те фрагменты, о которых возможно и придется объясняться с пользователем. Если я выбираю любую позицию, значит, у меня появляется спецификация, значит, при разработке подсистемы объяснений я должен что-то конструктивно туда вложить, у меня это значение было присутствовало, нельзя просто так разрабатывать системы, нужно указать буквально по всем позициям, что она поддерживает, какие спецификации обеспечивает, эти спецификации могут быть скрытыми. Они могут быть вообще за несколько ступеней до обобщения.

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

надо на каком-то уровне останавливаться, считая, что остальное объяснять не надо, это пользователь знает, а их несколько типов: эксперт знает, инженер по знаниям знает, пользователь экспертной системы знает. Адресат – это пользователь разного типа, их у нас три.

Теперь мы переходим непосредственно к динамике и к формам. Берем объяснение, которое чаще всего используется. Чаще используются следующие типы объяснений: записанные, значит они скрыты, если они встроены в исходные коды через write или другие какие-то средства вывода информации – это значит, на уровне исходного кода вы должны были найти точки и там предусмотреть вывод какой-то информации. Эта задача разбросать выводы по исходному коду очень сложно. По сложности сходна с задачей разбрасывания комментариев по телу исходного модуля. Программирование по степени сложности оценивается в 1%, от всего труда, который приходится затрачивать на разработку программы. Комментарии существенно больше 1%. Почти не удается сохранить исходный код, если происходит замена программиста.

Встраивать write в программу задача очень сложная, потому что кому вы что-то хотите сказать – это всегда вопрос сложный. Например, вы хотите сказать, не беспокойся у меня программа работает, значит надо знать с какой частотой выводить это сообщение. Проблем много, как и с help'ом, ведь он по сути дела те же комментарии, т.е. раньше они были рассыпаны по исходному модулю, а теперь они о чем-то в общем говорят. Вопрос help'а важный, как и в чем помогать. Это определенный тип объяснений, он достаточно распространен. Генерируемый протокол, трассировка исполнений – это наиболее популярный, трек зафиксировать исполнение. Если вы в экспертной системе вы спрашиваете, как ты получила это, а она говорит, я вот что выполняла, трек вам выдает и слова разумные там в этом треке расставлены, т.е. вся трасса работы расписана. Протоколы, трассировка исполнений – это одна из версий объяснений, в то же время она может быть дополнительной для этих