Привет, я продолжаю дальше свое повествование и подумал, что было бы неплохо
описать в этой главе эвристическую классификацию. Помнишь я упоминал про систему
порождающих правил и поиск решения в глубину и ширину? Правильно, что не
помнишь, потому что не упоминал. Поиск решения в глубину и ширину может
потребоваться при проектировании интеллектуальных игр. Значит, я обязан
рассказать про систему порождающих правил поподробнее, также я расскажу более
подробно представление неопределенности знаний в системе. ЭС это не просто
приложение, это ЭС! Тут каждая деталь способна решать многое, и неверно
построенная модель вначале проектирования может привести к большим
разочарованиям и убыткам! Что такое эвристическая классификация? Это
классификация, которая может разделить единую систему на подсистемы, и после
работать для каждой подсистемы более ответственно. Теперь непосредственно к
теме. Хейс-рот создал классификацию ЭС:
- Интерпретирующие – т.е. обработка сигналов от внешних источников –
сенсоров, инфракрасных датчиков и т.д. - Прогнозирующие
- Диагностические (надеюсь, ты выполнил ДЗ и почитал доп. литературу про
MYCIN) - Системы контроля – предназначены для управления сложных роботов (но лишь
только для самой физической системой) - Система проектирования
- Система планирования
- Система мониторинга – не сложно, но полезно.
- Наладочные системы
- Системы оказания помощи при ремонте
- Обучающие системы
Конечно, я бы с удовольствием доработал эту работу (я иногда на
www.aicommunity.org
чисто теоретические статьи пишу). Многие с этим и не согласны – я же буду пока
опираться на существующую систему классификации. В нашем роботе будет
задействовано 8 или 9 пунктов теоретически. Пример эвристической классификации,
основанный на распознавании врага по внешнему отличию (довольно тупой пример, но
для реалистичности я сделал, что у солдат якобы еще имеется маячок со
специальным сигналом, вшитый под кожу, комментарием в CLIPS служит знак “;;”)
;; Объявляем
правило-шаблон «Распознавание» (deftemplate Recognition (field name (type symbol))
;; подразумевается наличие у солдат маячка с
сигналом
;; 0 невозможно расшифровать
;; 1 уже расшифрован
;; -1 и не поступал
(field signal(type INTEGER))
(field weapon(type SYNBOL))
(field race(type SYMBOL))
)
(deftemplate Ours
(field name (type SYMBOL)))
(deffacts soldiers
(soldier(name RUSSIA))
(Signal 1)(race ?M)
;; небольшое усилие для лучшей работы
(weapon ?N)
)
(deftemplate enemy
(field name(type SYMBOL)))
(deffacts soldiers
(soldier (name American))
(Signal 0)(race European)
;; американцы пользуются разным оружием
;; поэтому переменная
(weapon ?N)
(deffacts soldiers
(soldier (name China)
(Signal 0)(race Asian)
(weapon Russia)
(deffacts any
;; в таких случаях надо использовать только
переменные
;; но хотя бы с одним точным фактом
;; для снижения затрат машинных ресурсов
(soldier (name ?N)(signal 0)
(race ?M)(weapon ?Y)
;; в принципе вся тема находится в этом исключающем
правиле
(defrule eavil
(? except <-(soldier name ?B)(signal -1)
(race ?M)(weapon 0)
?mistake <-(enemy)(name ?B)=>
(retract ?mistake)(retract ?except))
;; можно просто из меню выбрать команду reset
(reset)
(defrule Fire
“see enemy”
(salience 9999)
;; враг в зоне огня
(The enemy in a zone of fire)=>
(assert (Fire)
;; выбрать позицию
(assert (To choose a position)
;; применять тактику
(assert (To apply tactics)
;; уничтожить любой ценой
;; это правило будет действовать после конца
патронов
(assert (To destroy at any cost))
(reset)
(defrule The end
“Hopelessly”
(salience 10000)
(Shells were terminated)
(The spare battery is included)
(50 % of mechanisms are damaged)=>
(assert(destroy itself))
Я постарался сделать в этом примере робота более-менее надежным, хотя я никогда
бы этот код не откомпилировал на машине – это может стоить жизни. Последнее
правило разработано на случай, когда робот может попасть в руки врагов, и он
себя самоликвидирует.
Неопределенность знаний
В прошлой статье я
описал простейший пример поддержки. Но даже в таком простом примере может
возникнуть неопределенность знаний. Одной из таких проблем являются сенсоры.
Потому что робот будет все видеть не так, как мы. В лучшем случае это будет
красивое представление из несколько десятков цветов. Использование тории
вероятности может вызвать трудности, главная из которых – машинные ресурсы. На
Earth Simulator это вообще не проблема, но робот должен быть мобильным, а не
шкафчиком. Поэтому ученые стали использовать нечеткую логику (уверен на
99.9999%, что вы уже сталкивались с этим понятием). ЭС не стоит, поэтому ученые
выдвинули формулу:
P (d|s) = (s|d) P(d)/P(s)
d – Событие, которое наступит при условии s (далее вышка). То есть
вероятность возникновения замыкания (d) при попадания снаряда (s) в генератор. P
(d|s) – это сама вероятность события, s|d условная вероятность (очень часто
бывает известна). Поэтому иногда придется попотеть и посмотреть вероятность
возникновения какого-либо события
Если событий несколько, то формула примет вид:
P(d|s1^…^sn) =P(s1^…sn|d) P(d)/P(s1^…sn)
(Домашнее задание: напиши программу на любом языке, составь список
событий и вероятностей и рассчитай вероятность возникновения события).
С теорией я познакомил, но на практике у меня проблемы представления знаний
нет – слишком все просто. Если писать сложную систему, то количество читателей
будет X=min.
Злоключение
Я знаю, как тяжело понимать эти примерчики, но сделать ничего не могу, т.к.
за это время не пришло ни одного письма с просьбой объяснить значение каких-либо
сложностей языка. Такое ощущение, что людей интересует только хак…
Я только повторю мысли Норберта Винера: атом служит людям и в помощь и во зло.
Также и робототехника – она может не то, что уничтожить мир, она может просто
внести социальный взрыв на планете. Всем известны из истории бунты против машин.
Нам кажется, что людей компьютерной профессии эта проблема вообще не коснется, и
считаем себя полубогами. Я точно знаю, что коснется. Кому хочется держать на
работе администратора, который не может обеспечить 100% защиту да еще как
профессионал требует хорошую зарплату. Гораздо проще купить самообучающуюся ЭС и
жить в гармонии и счастье. Это даже меня касается – одно время я буду писать ЭС.
Но когда- нибудь будет создана ЭС, пишущая ЭС. Это уже дыра. Моё мнение – это
все же доверить работу людям, а роботов оставить только в виде помощников, а не
альтернативы. Я почувствовал эту опасность. Не надо рыть яму самим себе. Не надо
лишать людей работы – это бумеранг – обязательно вернется. А уж если доверить
науку роботам, то скоро мы почувствуем себя явно лишними на планете… (Unreal –
неплохой пример – будущее, но роботов нет, зато используется техника и
разработки для ВПК). Т.к. основные проблемы мы решили, то 3 статью я посвящу
методам разработки, а 4-ую посвящу либо уже чисто программированию ЭС, либо
сильной практике.
