Канонические системы
5.1. Канонические системы
Порождения — это в действительности грамматические правила манипулирования строками символов и потому их иногда называют правилами переписывания (rewrite rules). Пост изучал свойства систем правил, базирующихся на порождениях, которые он назвал каноническими системами [Post, 1943]. Каноническая система — это разновидность формальной системы, основанной на следующих компонентах:
алфавит А, из символов которого формируются строки;
некоторое множество строк, которые рассматриваются как аксиомы,
множества порождений в форме
а1$1 ... am$m->b1$'1...bn$'1...bn$'n.
(I) каждое ai и bi; есть фиксированная строка;
(II) а1 и am, часто есть нуль;
(III) некоторые или все из ai или bi могут представлять собой нуль;
(IV) каждое $i является переменной строкой, которая также может быть нулем;
(V) каждое $i заменяется определенным $'i .
Определение канонической системы, возможно, станет более понятным, если привести пример. Пусть А — алфавит {а, b, с}, а аксиомы суть:
а, b, с, аа, bb, cc.
Тогда следующие порождения сгенерируют все палиндромы, базирующиеся на этом алфавите, приняв за отправную точку имеющиеся аксиомы:
(Р1)$->а$a (Р2) $ -> ab$ab (РЗ) $ -> с$с.
На первый взгляд канонические системы довольно тривиальны. Все, что можно сделать в рамках такой системы, — преобразовать одну строку символов в другую. Но если задуматься, то любое логическое или математическое исчисление в конце концов сводится к набору правил манипулирования символами. Мы упускаем это из виду, поскольку для нас часто важен определенный смысл логических и математических символов, чего не скажешь о строках типа abcba.
Отсюда следует, что любая формальная система может рассматриваться как каноническая (см., например, [Minsky, 1972, Chapter 12J). В действительности к этому нужно добавить тривиальную оговорку, что такая система может нуждаться еще в дополнительном алфавите, буквы которого будут использоваться в качестве знаков пунктуации в сложных доказательствах. Таким образом, для проверки доказательства в любой формальной системе или для того, чтобы выполнить любую эффективную процедуру, вполне достаточно способности прочесть строку символов, разделить ее на компоненты и переупорядочить (при этом, возможно, придется добавить еще какие-то символы или удалить существующие в исходной строке).
Синтаксис представления правил
5.2.1. Синтаксис представления правил
В настоящее время порождающие правила обычно реализуются в форме правил, манипулирующих с символическими структурами типа списка векторов, а не строк символов. В этом сказывается влияние языков программирования вроде LISP и тех структур данных, которые они поддерживают. (В ранних реализациях использовались языки манипулирования символами, например SNOBOL.)
В результате алфавит канонической символьной системы заменяется словарем символов или атомов и довольно простой грамматикой формирования символических структур. Словарь, как правило, состоит из трех подмножеств:
подмножества N имен объектов предметной области;
подмножества Р имен свойств, которые рассматриваются в качестве атрибутов объектов;
подмножества V допустимых значений атрибутов.
На практике подмножества N и V перекрываются.
Используемая грамматика, как правило, имеет вид триад объект-атрибут-значение. Триада (v, л, w) существует, если v принадлежит N и л принадлежит Р, w принадлежит V. Например, триада
(ОРГАНИЗМ-1, морфология, палочка)
Представленная синтаксическая форма обобщается в том случае, когда нужно для некоторого объекта v представить « вариантов пар атрибут-значение (л1,w1) ..., (лn,wn). В таком случае они объединяются в вектор в форме
(v, л1, w1,..., лn, wn).
(organism-1 (morphology rod) (aerobicity aerobic)).
Имея в своем распоряжении словарь символов и грамматику, регламентирующую порождение символических структур, можно представить в машинном виде исходное состояние интересующих нас проблем. Эти представления соответствуют аксиомам канонической системы — они представляют собой некоторую символическую структуру, которую нужно преобразовывать, применяя имеющиеся правила в определенном порядке.
Теперь перейдем к самим правилам. В этих правилах антецеденты должны соответствовать допустимым символическим структурам, а консеквенты — содержать специальные операторы манипулирования такими структурами. Детали этого процесса станут вам понятны после изучения следующего раздела, где будет описан вычислительный механизм применения таких правил.
Продукционная система (production system) состоит из множества правил (иногда этот набор правил называют продукционной памятью — production memory), интерпретатора правил, который решает, когда надлежит применить каждое из них, и рабочей памяти, содержащей данные, описание цели и промежуточные результаты, в совокупности определяющие текущее состояние проблемы. Именно структуры данных в рабочей памяти анализируются и преобразуются порождающими правилами. Обращение к правилам синхронизируется текущими данными, а интерпретатор правил управляет выбором и активизацией определенных правил в каждом цикле.
Схематически правила в продукционной системе имеют такую обобщенную форму:
P1,..., Pm,->Q1,..., Qn
которая читается следующим образом:
Предпосылки часто называются условиями, а действия — заключениями, поскольку один из видов действий — сделать заключение, если встретилось такое сочетание условий, которое делает истинным или вероятным определенное порождающее правило, как это было показано в главе 3. Иногда используется и другая терминология, согласно которой предпосылки называются левой частью правила, а действия — правой.
Предпосылки обычно бывают представлены в форме вектора объект-атрибут— значение, как, например:
(organism-1 (morphology rod) (aerobicity aerobic)).
Правило, которое включает такую предпосылку, на языке CLIPS имеет вид, показанный в листинге 5.1.
Рабочая память
5.2.2. Рабочая память
Основная функция рабочей памяти — хранить данные в формате векторов объект-атрибут-значение. Эти данные используются интерпретатором, который в случае присутствия (или отсутствия) определенного элемента данных в рабочей памяти активизирует те правила, предпосылки в которых удовлетворяются наличными данными. Как это делается, рассмотрим на примере.
Пусть в рабочей памяти содержатся векторы
(patient (name Jones) (age 40)
(organism organism-1))
(organism (name organism-1)
(morphology rod) (aerobicity .aerobic)).
Если предпосылка в правиле не содержит переменных, она удовлетворяется при точном совпадении выражений в правиле и в рабочей памяти. Если же предпосылка в правиле содержит переменные, т.е. является образцом, то она удовлетворяется, если в рабочей памяти содержится вектор, включающий такую пару атрибут-значение, которая остается постоянной при удовлетворении всех остальных условий в том же правиле.
В самом простом случае соответствие проверяется присвоением постоянных значений переменным, которые делают предпосылку совпадающей с вектором в рабочей памяти. Так, вектор состояния в рабочей памяти
(patient (name Jones) (age 40)
(organism organism-1))
удовлетворяет предпосылку в правиле
(patient (name ?pat) (organism ?org))
Обратите внимание на то, что мы опускаем при анализе соответствия пары, которые отсутствуют в предпосылке правила. Поскольку другая предпосылка в этом же правиле также удовлетворяется при указанной подстановке, то новый вектор
(organism (name organism-1)
(identify enterobacteriaceae) (confidence 0.8))
Поскольку для заключения правила значение ?pat безразлично, поле имени пациента можно в условии вообще игнорировать.
Теперь рассмотрим набор правил, представленный в листинге 5.3, вместе с множеством векторов в рабочей памяти. Этот пример основан на планировщике STRIPS, о котором шла речь в главе 3. Программа состоит из выражений трех типов:
деклараций (или шаблонов), которые определяют формат векторов в рабочей памяти;
определений фактов, которыми задается начальное состояние проблемы;
порождающих правил, которые определяют возможные трансформации состояния проблемы.
Строки, которые начинаются символами ";;", являются комментариями.
Системы порождающих правил для решения проблем
5.2. Системы порождающих правил для решения проблем
Хотя в приложении к экспертным системам порождающие правила и отличаются от тех правил переписывания, о которых шла речь выше, фундаментальные принципы и формальные свойства их остаются теми же. Но при этом нас интересует не столько сама по се-
бе грамматика символических структур, как в примере с палиндромами, сколько способы представления некоторой проблемы и преобразования этого представления, которое должно привести ее к виду, о котором можно сказать: "Это решение данной проблемы".
Разрешение конфликтов
5.3.1. Разрешение конфликтов
Как мы видели, в алгоритме функционирования продукционной системы введен специальный шаг принятия решения между шагами анализа ситуации и применения правила. В результате анализа соответствия текущих данных и предпосылок различных правил в имеющемся наборе можно сформировать список правил, которые могут быть применимы в данной ситуации. Такой набор иногда называют конфликтующий множеством (conflict set). В терминологии языка CLIPS этот список называется agenda — список заявок.
Цель процедуры разрешения конфликтов — выбрать из сформированного списка заявок единственное правило, которое должно быть применено в текущей ситуации. Поскольку стратегия разрешения конфликтов оказывает существенное влияние на производительность системы в целом, в большинстве программных систем предусматриваются определенные опции для подстройки этого механизма.
При выработке стратегии разрешения конфликтов обычно используется комбинация разных базовых механизмов, каждый из которых обладает свойственными только ему характеристиками. Производительность экспертной системы зависит от таких ключевых характеристик режима управления, как чувствительность и стабильность. Чувствительность характеризует, как быстро система будет реагировать на изменение среды, которое отражается в рабочей памяти, а стабильность характеризует степень консерватизма в поведении системы ([McDermott andForgy, 1978], [Brownston et al., 1985, Chapter 7]).
Свойства механизмов разрешения конфликтов, которые реально применяются в системах, при всем их разнообразии можно разделить на три довольно компактные группы.
Разнообразие. Не следует применять к одним и тем же данным правило, которое уже было к ним применено ранее. Самый простой вариант реализации этого механизма — удалять из списка заявок примененное ранее правило. Иногда используется другой вариант — из списка удаляется правило, активизированное в предыдущем цикле, — это предотвращает зацикливание, но если желательно именно повторять процедуру, то в распоряжение программиста предоставляется функция refresh, которая позволяет временно подавить механизм, действующий по умолчанию.
Новизна. Элементы в рабочей памяти в таких инструментальных системах, как CLIPS, снабжены специальным атрибутом времени порождения. Это позволяет системе ранжировать элементы в списке заявок соответственно тому, как давно введены в рабочую память данные, которые использовались при сопоставлении, а затем приоритет отдается правилам, "реагирующим" на более свежие данные. Идея состоит в том, чтобы следовать за "текущей волной" и меньше внимания уделять тем данным, которые были давно сформированы. К ним можно будет вернуться в дальнейшем, если текущая цепочка рассуждения натолкнется на какое-либо препятствие.
Специфика. Более специфичные правила, которые включают большее количество компонентов в предпосылках и соответственно труднее удовлетворяются, имеют приоритет перед более общими. Идея состоит в том, что использование таких правил должно принести больше "пользы", поскольку они принимают во внимание больше информации. Эту стратегию можно эффективно использовать при работе с исключениями из общих правил.
Не располагая механизмом разрешения конфликтов, продукционная система будет не в состоянии эффективно справляться с отсутствием детерминизма в наборе правил, обработкой исключений и переключением внимания на определенный стиль рассуждений. Другими словами, представление будет страдать отсутствием эвристических способностей, а управлять функционированием такой системы будет довольно трудно, даже если знания представлены вполне корректно.
В системе интерпретации CLIPS использованы все три описанные выше механизма, что дает хороший эффект. Кроме того, интерпретатор позволяет пользователю связать с любым правилом свойство salience (выпуклость), которое используется для того, чтобы отсортировать список заявок по классам выпуклости. В первом приближении можно считать, что список заявок сортируется сначала по классам выпуклости, а затем правила, имеющие одинаковую "выпуклость", отсортировываются по другим характеристикам механизма разрешения конфликтов.
Прямая и обратная цепочки рассуждений
5.3.2. Прямая и обратная цепочки рассуждений
На глобальном уровне управления последовательностью применения правил можно выделить две стратегии поведения — применять правила в прямом и обратном порядке. Прямой порядок означает, что цепь рассуждений строится, отталкиваясь от данных (условий, о которых известно, что они удовлетворяются), к гипотезам (состоянию проблемы, вытекающему из этих условий). Обратная цепочка означает, что рассуждения строятся, отталкиваясь от заданной цели (гипотезы, представляющие целевое состояние системы) к условиям, при которых возможно достижение этой цели. Здесь явно чувствуется аналогия с прямой и обратной стратегиями доказательства теорем (см. об этом в главе 8).
CLIPS представляет собой систему, в которой строится прямая цепочка рассуждений, а порождающие правила в системе MYCIN используются в большинстве случаев для построения обратной цепочки рассуждений, как было показано в главе 3. В CLIPS всегда сопоставляются состояние рабочей памяти и левые части правил, а затем выполняются действия, предусмотренные правой частью выбранного правила. А в MYCIN ведущей в рассуждениях является правая часть правила. Если мы задались целью установить природу некоторого микроорганизма, то отбираются все правила, в правой части которых дается соответствующее заключение, и затем анализируется, предпосылки какого из них удовлетворяются текущими данными.
Проще всего представить отличие между прямой и обратной цепочками рассуждений в терминах грамматических правил, аналогичных представленным в разделе 5.1. Как было показано, набор правил
(Р1) $ -> а$а
(Р2) $ -> b$b
(РЗ) $ -> с$с
Во-первых, их можно использовать для формирования палиндромов. Если задаться некоторым начальным символом из имеющегося алфавита, то любая последовательность применения правил приведет к формированию палиндрома. Так, применение правил Р1, Р1, РЗ, Р2, Р3 к исходному символу с приведет к формированию строк
аса, aacaa, caacaac, bcaacaacb, cbcaacaacbc.
Это пример прямой цепочки, поскольку с и каждая последующая сформированная строка сопоставляются с левой частью правила, а затем означивается правая часть правила.
Во-вторых, можно использовать этот же набор правил не для формирования, а для распознавания палиндромов. Мы уже видели ранее, что, задавшись некоторой строкой, например ЬасаЬ, можно проследить, в какой последовательности применялись правила при построении этой строки. Строка bасаb соответствует правой части правила Р2; можно сказать, что правая часть правила Р2 "допускает" строку bacab. Означенная левая часть правила Р2 — это строка аса, которая соответствует правой части правила PI, a означенная левая часть этого правила — аксиома с. Таким образом, процесс распознавания успешно завершился — мы доказали, что bacab представляет собой палиндром. Описанный процесс распознавания — это пример применения обратной цепочки рассуждений. Начальная строка bacab и каждая очередная подстрока анализируются на соответствие с правыми частями имеющихся правил, а результатом является означивание левой части выбранного правила. Если в качестве исходной мы зададимся строкой acbcb, то для нее не удастся найти в имеющемся наборе правил такое, правая часть которого "допускала" бы эту строку, а значит, исходная строка не может быть палиндромом.
В литературе по теории доказательства теорем прямая цепочка рассуждений, как правило, ассоциируется с "восходящим" процессом, т.е. рассуждениями от фактов к целям, а обратная цепочка — с "нисходящим" процессом, рассуждением от целей к фактам. Но, строго говоря, в отношении продукционных систем эти термины не являются синонимами. Например, вполне возможно реализовать нисходящий процесс в продукционной системе с прямой цепочкой рассуждений, если должным образом настроить локальный режим управления, например задать явное указание целей.
В листинге 5.4 показана простая программа построения башни из блоков. Эта программа переключается между двумя задачами: выбором очередного блока и установкой блока в башню.
В разделе шаблонов блоки представлены объектами, обладающими такими свойствами, как цвет, размер и положение. Если положение блока не определено, предполагается, что он находится в куче блоков (heap), еще не уложенных в башню. Шаблон on предоставляет в наше распоряжение средство, позволяющее описать размещение блоков одного (upper) на другом (lower). Информацию о текущей фазе решения проблемы (поиск или установка) несет шаблон goal.
Правила и метаправила
5.3.3. Правила и метаправила
Код каждого порождающего правила является самодостаточным, т.е. весь необходимый контекст активизации правила содержится только в его предпосылках. Не существует способа, который позволял бы одному правилу вызывать другое, как если бы правила были процедурами. Правило R, которое активизируется в цикле Сi, может облегчить последующую активизацию правила R' в цикле Ci+1, но единственный способ сделать это — изменить состояние рабочей памяти.
Иногда, для того чтобы решить, какое правило следует активизировать, желательно использовать конкретные знания, а не следовать общей стратегии разрешения конфликтов. С этой целью в некоторые интерпретаторы правил включены средства, позволяющие программисту сформулировать и ввести в программу метаправила. Эти метаправила определяют правила применения правил, т.е. правила, по которым выполняется отбор тех правил из претендующих на выполнение, которые следует рассматривать в первую очередь или, более того, выполнять обязательно, (Такая возможность отсутствует в интерпретаторе CLIPS.)
Метаправила, таким образом, существенно отличаются от обычных правил, поскольку они направляют ход рассуждений, а не принимают непосредственное участие в процессе формирования суждений. Часто это отличие формулируется в терминах разграничения уровней функционирования правил —метауровня и объектного уровня.
Например, в системе MYCIN набор порождающих правил индексирован по клиническим параметрам, которые упоминаются в его правой части (заключение правила). В результате появляется предпосылка для значительного ускорения процедуры извлечения правил, которые можно использовать для определения величины определенного параметра (лекарственного препарата). Эта информация используется метаправилами, которые применяются по отношению к правилам, с помощью которых достигается определенная подцель. Пусть, например, сформулирована очередная подцель G, скажем, классифицировать микроорганизм. Для достижения этой подцели в системе при данном состоянии рабочей памяти можно применить множество, например порядка 30 правил. Метаправила позволяют значительно сузить круг кандидатов на основании какого-либо критерия, заложенного программистом в формулировку этого правила.
Ниже представлено простое метаправило сокращения количества кандидатов в системе MYCIN, заимствованное из книги Бучанана и Шортлиффа [Buchanan and Shortliffe, 1984, Chapter 28].
МЕТАПРАВИЛO001
ЕСЛИ
культура получена не из стерильного источника, и существуют правила, в предпосылках которых упоминается предыдущий классифицированный организм, который может быть тем же самым, что и текущий,
с совершенной определенностью (1.0) можно предположить, что каждое из этих правил в данном случае не применимо.
Другие метаправила могут быть использованы для изменения порядка приоритетов правил. В них фактически заложены знания, рекомендующие: "сначала попробуйте этот способ, а уж потом — тот". Примером может служить приведенное ниже метаправило, также относящееся к системе MYCIN.
МЕТАПРАВИЛO002
ЕСЛИ
(1)инфекция относится к классу pelvic-abscess, и
(3)существуют правила, в предпосылках которых упоминается грамполохительная окраска,
ТО
есть основания предполагать (0.4), что приоритет следует отдать первым из перечисленных правил.
Последний пример демонстрирует метаправило, которое относится к общей стратегии решения проблем, а не к конкретным проблемам предметной области.
МЕТАПРАВИЛO00З
(1)существуют правила, в предпосылках которых не упоминается текущая цель, и
(2)существуют правила, в предпосылках которых упоминается текущая цель,
ТО
с совершенной определенностью (1.0) можно утверждать, что сначала следует активизировать первые из перечисленных правил.
Но очень важно, чтобы применение метаправил не увело нас в сторону, а для этого при их формулировке на основе существующих знаний нужно использовать определенный уровень абстрагирования. Например, метаправило
ЕСЛИ
(1)х алкоголик,
сначала следует рассмотреть правила, имеющие отношение к болезни А, а затем правила, имеющие отношение к болезни Б может быть сформулировано более абстрактно:
(2)существуют специальные правила, связанные именно с категорией Z,
ТО
применить эти правила прежде, чем попробовать другие, допустимые в данных условиях.
Мы еще вернемся к теме метаправил в главах 12, 15, 18 и 23, а сейчас только отметим, что это довольно продуктивная идея, которой, тем не менее, следует пользоваться осмотрительно. Если программа потратит значительную часть времени на определение того, какими правилами пользоваться, то это может сказаться отрицательно на ее производительности.
Управление функционированием интерпретатора
5.3. Управление функционированием интерпретатора
Процесс применения специфицированных правил можно описать в терминах цикла распознавание-действие, который состоит из следующих шагов.
(1) Сопоставить образцы в предпосылках правил и элементы данных в рабочей памяти.
(2) Если окажется, что можно активизировать более одного правила, выбрать одно из них; этот шаг называется разрешением конфликта.
(3) Применить выбранное правило. Результатом, скорее всего, будет добавление нового элемента данных в рабочую память и/или удаление какого-либо существующего элемента из рабочей памяти. Затем перейти к шагу 1.
Обычно перед началом этого циклического процесса в рабочую память вводится элемент, соответствующий исходному состоянию проблемы. На языке CLIPS такой элемент является вектором (initial-fact). Процесс останавливается, если будет обнаружен цикл, в котором ни одно из правил не может быть активизировано, или если активизированное правило явно содержит команду прекращения работы5. На шаге 2 система располагает набором пар, состоящих из правил и подстановок переменных, которые сформированы при сопоставлении образцов. Такие пары называются означиваниями (instantiations). Механизм разрешения конфликтов специфичен для каждой системы, т.е. для каждого интерпретатора правил. Можно, конечно, сформулировать и такой набор правил, что в любой ситуации только одно из них будет удовлетворяться (он называется детерминированным). Но в экспертных системах обычно используются недетерминированные наборы правил, поскольку в реальной жизни очень часто встречаются ситуации, которые позволяют использовать более одного правила.
Управление процессом функционирования системы, основанной на применении порождающих правил, выдвигает ряд нетривиальных проблем. Существуют две разновидности обобщенного подхода к управлению функционированием — локальный и глобальный. Глобальный подход имеет тенденцию к поиску решений, не связанных с особенностями определенной предметной области, а локальный, наоборот, на первый план выдвигает приемы, специфические для данной предметной области. Все стратегии, которые будут перечислены в следующем разделе, являются примерами использования глобального подхода и, как правило, "жестко" встраиваются в структуру интерпретатора правил, как это сделано в интерпретаторе CLIPS. Программист, использующий при построении конкретной системы такой интерпретатор, лишен возможности каким-либо образом изменить жестко заложенную в нем стратегию либо может варьировать ее в очень узких пределах.
Локальный подход предполагает использование специальных правил управления правилами — метаправил. Такие правила обычно программируются в явном виде разработчиком конкретной системы с учетом специфики ее применения.
Трассировка программы строительства башни
5.4. Трассировка программы строительства башни
При запуске программы в режиме трассировки будет сформирована следующая карта трассировки.
CLIPS> (reset)
==> f-0 (initial-fact)
==> f-1 (block (color red) (size 10) (place heap))
==>f-2 (block (color yellow) (size 20) (place heap))
==> f-3 (block (color blue) (size 30) (place heap))
CLIPS> (run)
TIRE 1 begin: f-0
==> f-4 (goal (task find))
FIRE 2 pick-up: f-4, f-3,
<== f-3 (block (color blue) (size 30) (place heap))
==> f-5 (block (color blue) (size 30) (place hand))
<== f-4 (goal (task find))
==> f-6 (goal (task build))
FIRE 3 place-first: f-6, f-5,
<== f-5 (block (color blue) (size 30) (place hand))
==> f-7 (block (color blue) (size 30) (place tower))
<== f-6 (goal (task build))
==> f-8 (goal (task find))
FIRE 4 pick-up: f-8, f-2,
<== f-2 (block (color yellow) (size 20) (place heap))
==> f-5 (block (color yellow) (size 20) (place hand))
<== f-8 (goal (task find))
==> f-10 (goal (task build))
FIRE 5 put-down: f-10, f-9, f-7,
<== f-9 (block (color yellow) (size 20) (place hand))
==>. f-11 (block (color yellow) (size 20) (place tower))
==> f-12 (on (upper yellow) (lower blue) (place tower))
<== f-10 (goal (task build))
==> f-13 (goal (task find))
FIRE 6 pick-up: f-13, f-1,
<== f-1 (block (color red) (size 10) (place heap))
==> f-5 (block (color red) (size 10) (place hand))
<== f-13 (goal (task find))
==> f-15 (goal (task build))
FIRE 7 put-down: f-15, f-14, f-11,
<== f-14 (block (color red) (size 10) (place hand))
==> f-16 (block (color red) (size 10) (place tower))
==> f-17 (on (upper red) (lower yellow) (place tower))
<== f-15 (goal (task build))
==> f-18 (goal (task find))
FIRE 8 stop: f-18,
<== f-18 (goal (task find))
CLIPS> (reset)
<== f-0 (initial-fact)
<== f-7 (block (color blue) (size 30) (place tower))
<== f-11 (block (color yellow) (size 20) (place tower))
<== f-12 (on (upper yellow) (lower blue) (place tower))
<== f-16 (block (color red) (size 10) (place tower))
<== f-17 (on (upper red) (lower yellow) (place tower))
Обратите внимание на манипулирование лексемой цели в ходе выполнения программы. Конечное состояние представлено при очистке рабочей памяти. Блоки в башне расположились в таком порядке: красный (red) — самый верхний, он стоит на желтом (yellow), который стоит на синем (blue).
(goal (task find)
(goal (task build)).
Иногда необходимо провести четкую границу между направленностью цепочки и направленностью действительных рассуждений. Эти две операции представляют разные уровни анализа. Очевидно, что цепочка является реализацией рассуждений, а не наоборот, но стратегия рассуждений управляет процессом построения цепочки, что в данном случае выполняется манипулированием лексемами цели. В главе 14 будет продемонстрирован гораздо более сложный пример использования этого метода в системе R1/XCON.
Это разделение высвечивает проблему, с которой очень часто приходится сталкиваться при обсуждении функционирования программ искусственного интеллекта. Большинство сложных систем, независимо от того, являются ли они программными системами, или физическими устройствами, или комбинацией тех и других, могут быть описаны на разных уровнях [Newell, 1982]. В соответствии с терминологией Ньюэлла, построение цепочки — это свойство символического уровня, где нас интересуют только левые и правые части правил, а рассуждение— это нечто, возникающее на уровне знаний, где можно провести разделение между фактами и задачами.
Ранее уже утверждалось, что большинство порождающих правил, представляющих реальный интерес с точки зрения приложений искусственного интеллекта, являются недетерминированными. При построении прямой цепочки рассуждений может оказаться, что текущие данные удовлетворяют предпосылки не одного правила, а нескольких. При построении обратной цепочки также зачастую оказывается, что одна и та же цель достигается при выполнении не единственного правила, а нескольких. Поэтому понятно, какая важная роль отводится механизму управления правилами в функционировании продукционной системы.
В главе 3 мы рассказывали о представлении пространства поиска, связанного с набором порождающих правил, с помощью И/ИЛИ-дерева. Узлы такого дерева соответствуют состояниям рабочей памяти, а дуги — правилам, которые при этом возможно применить. Древовидная схема очень хорошо согласуется с методикой обратной цепочки рассуждений, если считать, что корень дерева соответствует целевому состоянию, промежуточные узлы — подцелям, а терминальные узлы (листья) — данным.
В И/ИЛИ-дереве корень представляет исходное состояние проблемы, а листья — возможные варианты ее решения. Нетерминальные узлы могут быть двух видов: И-узлы и ИЛИ-узлы. И-узлы соответствуют применению нескольких правил, которые в совокупности формируют цель как объединение нескольких подцелей, а ИЛИ-узлы соответствуют наличию альтернативы при выборе возможных правил. Таким образом, используя терминологию главы 2, можно говорить о том, что возможные варианты применения правил формируют пространство поиска и определяют его структуру.
Программирование, основанное на правилах (логическое программирование), не снимает с повестки дня проблему комбинаторного взрыва, поскольку для любой проблемы И/ИЛИ-дерево может ветвиться по экспоненциальному закону. Но на практике стратегия разрешения конфликтов, реализованная в интерпретаторах правил, позволяет надеяться на отыскание разумного решения.
Системы, основанные на знаниях
ГЛАВА 5. Системы, основанные на знаниях 5.1. Канонические системы 5.2. Системы порождающих правил для решения проблем 5.2.1. Синтаксис представления правил 5.2.2. Рабочая память 5.3. Управление функционированием интерпретатора 5.3.1. Разрешение конфликтов 5.3.2. Прямая и обратная цепочки рассуждений 5.3.3. Правила и метаправила Рекомендуемая литература Упражнения
Оргправило системы MYCIN, записанное на языке CLIPS
Листинг 5.1. Оргправило системы MYCIN, записанное на языке CLIPS
(defrule diagnosis
(patient (name Jones)
(organism organism-1))
(organism (name organism-1)
(morphology rod)
(aerobicity aerobic)) =>
(assert
(organism
(name organism-1)
(identify enterobacteriaceae)
(confidence 0.8)))
(defrule <наименование правила>
<предпосылка1>
<предпосылка m >
=>
<действие 1>
<действие n>
(organism (name organism-1)
(identify enterobacteriaceae)
(confidence 0.8)).
Желание сформировать общие правила требует включения в него переменных, которые играют роль местодержателя. В правиле, представленном в листинге 5.2, такие переменные отличаются от прочих членов наличием префикса ? перед именем. Обратите внимание на то, что переменная ?pat не появляется в заключительной части правила, а значит, использование поля имени пациента в предпосылках правила действительно является избыточным.
Правило, в котором используются переменные
Листинг 5.2. Правило, в котором используются переменные
(defrule diagnosis
(patient (name ?pat)
(organism ?org))
(organism (name ?org)
(morphology rod)
(aerobicity aerobic)) =>
(assert
(organism
(name ?org)
(identify enterobacteriaceae) (confidence 0.8)))
Набор правил для проблемы в системе STRIPS
Листинг 5.3. Набор правил для проблемы в системе STRIPS
;; Шаблоны
;; Цель (goal) представляет собой вектор, состоящий из
;; четырех компонентов:
;; действие, которое нужно выполнить,
;; объект, над которым должно быть выполнено действие;
;; исходное положение;
;; положение, в которое нужно перейти.
(deftemplate goal
(field action (type SYMBOL))
(field object (type SYMBOL))
(field from (type SYMBOL))
(field to (type SYMBOL))
)
;; Вектор 'in' указывает, где находится объект, (deftemplate in
(field object (type SYMBOL))
(field location (type SYMBOL)) )
ФАКТЫ
;;Функция 'deffacts' вводит в рабочую память
;;описание исходного состояния.
;;Функция вызывается при перезапуске системы.
;;Исходное состояние объектов следующее.
;;Робот находится в комнате А,
;;ящик находится в комнате В,
;;цель - вытолкнуть ящик в комнату А.
(deffacts world
(in (object robot)
(location RoomA))
(in (object box)
(location RoomB))
(goal (action push)
(object box)
(from RoomB) (to RoomA))
)
;; ПРАВИЛА
;; Это правило утверждает:
;; Прекратить процесс, когда цель будет достигнута.
(defrule stop
(goal (object ?X) (to ?Y))
(in (object ?X) (location ?Y)) =>
(halt) )
;; Если робот отсутствует в том месте, где находится
;; объект, который нужно передвинуть,
;; переместить туда робот.
(defrule move
(goal (object ?X) (from ?Y))
(in (object ?X) (location ?Y))
?robot-position <- (in (object robot)
(location ?Z&~?Y)) =>
(modify ?robot-position (location ?Y))
;; Если робот и объект не в том помещении,
;; которое указано в цепи,
;; переместить туда робот и объект.
(defrule push
(goal (object ?X) (from ?Y) (to ?Z))
(in (object ?X) (location ?Y))
?object-position <- (in (object ?X) (location ?Y))
?robot-position <- (in (object robot) (location ?Y))
=>
(modify ?robot-position (location ?Z))
(modify ?object-position (location ?Z))
введите (reset),
затем введите (run).
С помощью команды watch посмотрите, в каком порядке будут использоваться специфицированные в программе правила. Во врезке 5.2 представлены трассировка выполнения этой программы и краткие пояснения.
Набор правил для построения башни из блоков
Листинг 5.4. Набор правил для построения башни из блоков
;; СТРАТЕГИЯ РАЗРЕШЕНИЯ КОНФЛИКТОВ
(declare (strategy mea))
;; Шаблоны
;; Объект block характеризуется цветом, размером и положением,
(deftemplate block
(field color (type SYMBOL))
(field size (type INTEGER))
(field place (type SYMBOL)) )
;; Вектор 'on' указывает, что блок <upper>
;; находится на блоке <lower>
. (deftemplate on
(field upper (type SYMBOL»
(field lower (type SYMBOL))
(field place (type SYMBOL) (default heap)] )
;; Текущая цель (goal) может быть либо 'найти' (find),
;; либо 'уложить' (build), (deftemplate goal
(field task (type SYMBOL)) )
;; ИНИЦИАЛИЗАЦИЯ
;; Имеются три блока разных цветов и размеров.
;; Предполагается, что они находятся в куче.
(deffacts the-facts
(block (color red) (size 10))
(block(color yellow) (size 20))
(block (color blue) (size 30))
)
;; ПРАВИЛА
;; Задать первую цель: найти первый блок,
(defrule begin
(initial-fact) =>
(assert (goal (task find))) )
;; Взять самый большой блок в куче (heap),
(defrule pick-up
?my-goal <- (goal (task find))
?my-block <- (block (size ?S1) (place heap))
(not (block (color ?C2) (size ?S2&:(>
-?S2 ?S1))
(place heap))) =>
(modify ?my-block (place hand))
(modify ?my-goal (task build)) )
;; Установить первый блок в основание башни (tower).
;; Этот блок не имеет под собой никакого другого,
(defrule place-first
?my-goal <- (goal (task build))
?my-block <- (block (place hand))
(not (block (place tower)))
=>
(modify ?my-block (place tower))
(modify ?my-goal (task find)) )
;; Установить последующие блоки на тот,
;; что лежит в основании башни,
(defrule put-down
?my-goal <- (goal (task build))
?my-block <- (block (color ?C0)
(place hand))
(block (color ?C1) (place tower)))
(not (on (upper ?C2) (lower ?C1)
(place tower)))
=>
(modify ?my-block (place tower))
(assert (on (upper ?CO) (lower ?C1)
(place tower)))
(modify ?my-goal (task find)) )
;; Если в куче больше нет блоков, прекратить процесс,
(defrule stop
?my-goal <- (goal (task find))
(not (block (place heap)))
=>
(retract ?my-goal) )
Набор диагностических правил заболеваний брюшной полости на языке CLIPS
Листинг 5.5. Набор диагностических правил заболеваний брюшной полости на языке CLIPS
;; Шаблоны
;; Объект 'sign' - это симптом, связанный с органом
;; или придатком,
(deftemplate sign
(field symptom (type SYMBOL))
(field organ (type SYMBOL))
(field site (type SYMBOL)) )
;; Вектор 'diagnosis' классифицирует патологию
;; некоторого органа.
(deftemplate diagnosis
(field disorder (type SYMBOL))
(field organ (type SYMBOL) (default NIL))
)
;; Факты
;; Некоторые простые симптомы.
(deffacts the-facts
(sign (symptom pain) (organ abdomen) (site lower))
(sign (symptom poor-appetite))
(sign (symptom weight-loss))
)
;; ПРАВИЛА
;; Признаки: боль в нижней части брюшной полости И
;; плохой аппетит, И потеря веса.
(defrule stomach-tumor
(sign (symptom pain) (organ abdomen) (site lower))
(sign (symptom poor-appetite))
(sign (symptom weight-loss)) =>
(assert (diagnosis (disorder tumor) (organ stomach)) )
;; Признаки: боль (pain)- в нижней части (lower)
;; брюшной полости ( abdomen ) ,
;; И понос (diarrhea), И рвота (nausea),
;; но высокой температуры нет.
(defrule inflammationl
(sign (symptom pain) (organ abdomen) (site lower))
(sign (symptom diarrhea) )
(sign (symptom nausea)) =>
(assert (diagnosis (disorder inflammation)
(organ large-intestine)))
)
;; Признаки: боль (pain) в нижней части (lower)
;; брюшной полости (abdomen),
;; И понос (diarrhea),
;; И высокая температура (fever).
(defrule inflamation2
(sign (symptom pain) (organ abdomen) (site lower))
(sign (symptom diarrhea))
(sign (symptom fever)) =>
(assert (diagnosis (disorder inflammation)
(organ large-intestine)))
)
;; Признаки: боль в верхней правой части брюшной полости
;; И отсутствие высокой температуры.
(defrule gallstones
(sign (symptom pain) (organ abdomen)
(site upper-right)) =>
(assert (diagnosis (disorder gallstones)
(organ gallbladder)))
)
;; Признаки: боль в верхней правой части брюшной полости,
;; И рвота, И высокая температура.
(defrule gallbladder
(sign (symptom pain) (organ abdomen)
(site upper-right)) (sign (symptom vomiting))
(sign (symptom fever)) =>
(assert (diagnosis (disorder inflammation)
(organ gallbladder))) )
Разрешение конфликтов в CUPS
В этой врезке будут описаны те стратегии разрешения конфликтов, которые используются в исполнительной системе языка CLIPS. Для краткости мы будем говорить о сортировке правил, хотя в действительности сортируются означивания правил, которые образуются в результате подстановки значений переменных и таким образом отражают соответствие между образцом, специфицированным в предпосылке правила, и действительными данными.
Стратегия глубины. Это воплощение стратегии новизны данных по отношению к правилам, имеющим одинаковый класс выпуклости. Правила, выбранные в список заявок на основании данных, которые были включены в рабочую память сравнительно недавно, располагаются в этом списке раньше правил, при выборе которых использованы более старые данные. Таким образом, предпочтение отдается принципу поиска в глубину в пространстве состояний проблемы, т.е. правила, которые являются следствием более поздних изменений состояния системы, имеют определенный приоритет. В системе CLIPS 6.0 эта стратегия реализуется по умолчанию.
Стратегия ширины. Эта стратегия обратна рассмотренной выше стратегии глубины и предназначается для реализации поиска в ширину в пространстве состояний проблемы. Правила, выбранные в список заявок на основании данных, которые были включены в рабочую память сравнительно давно, располагаются в этом, списке раньше правил, при выборе которых использованы более свежие данные.
Стратегия простоты. Сложность правила определяется количеством операций проверки, которые нужно выполнить при анализе условий данного правила. Более верхнее положение в списке заявок при реализации этой стратегии отдается тем правилам, сложность которых ниже.
Стратегия сложности. Использует тот же критерий, что и стратегия простоты, но располагает правила в обратном порядке — более сложные занимают более приоритетное место в списке.
LEX-стратегия. Предполагает сначала удаление из списка заявок всех правил, которые уже были ранее использованы. Оставшиеся правила с равным значением выпуклости затем отсортировываются по "новизне" используемых данных. Если окажется, что два правила используют данные одинаковой "свежести", то предпочтение отдается тому, которое вовлекает в анализ предпосылок больше данных.
МЕА-стратегия. Во многом аналогична предшествующей, но при анализе новизны принимаются во внимание только первые условия в предпосылках правил. Если окажется, что в списке заявок оказались два претендента с равными показателями, то для выбора между ними применяется механизм LEX-стратегии.
МЕА — это аббревиатура от наименования одной из первых методик решения задач искусственного интеллекта путем построения обратной цепочки рассуждений Mean-Ends Analysis (средство — анализ результата). Идея состоит в том, что стратегия должна быть использована вместе со специальными лексемами цели в рабочей памяти, которые направляют процесс рассуждений и которым соответствуют первые условия в предпосылках правил. Пример использования такой методики представлен в главе 14.
В системе OPS5, многие черты которой унаследовали более поздние программные средства построения экспертных систем, использовались только две последние из перечисленных стратегий — LEX и МЕА. Стратегия LEX показала себя как хорошая стратегия общего применения, в то время как МЕА является эффективной стратегией при решении более специфических задач, таких как планирование. Тривиальный пример использования этой стратегии в программе на языке CLIPS представлен в листинге 5.4.
Рекомендуемая литература
Рекомендуемая литература
Прекрасное изложение базовых принципов применения правил в задачах искусственного интеллекта читатель найдет в книге Нильсона [Nilsson, 1980]. Дэвис и Кинг обобщили большой материал, касающийся продукционных систем, и проанализировали слабые и сильные стороны этой парадигмы программирования [Davis and King, 1977]. Эта работа до сих пор остается наиболее подробной. Современные исследования, касающиеся возможности использовать параллелизм в продукционных системах, описаны в работе Шмольца [Schmolze, 1991].
Описание языка CLIPS, который можно рассматривать как одно из современных средств создания систем, базирующихся на правилах, читатель найдет в Приложении в конце данной книги. Естественно, что приведенное там описание не претендует на роль исчерпывающего справочника, но оно поможет представить, как на практике реализовать изложенные в этой книге концепции.
Читателей, интересующихся подробным описанием методики реализации стратегии управления производящими правилами, мы отсылаем к книге Браунстона [Brownston et ai, 1985].
Системы, основанные на знаниях
Системы, основанные на знаниях
5.1. Канонические системы
5.2. Системы порождающих правил для решения проблем
5.3. Управление функционированием интерпретатора
Рекомендуемая литература
Упражнения
В области искусственного интеллекта и в современной психологии утверждение, что разумное поведение направляется правилами, превратилось уже в аксиому. Даже в "большом" мире люди склонны связывать уровень интеллектуальности со следованием правилам, и мы все чаще при объяснении разумности обращаем внимание на то, насколько при этом соблюдаются правила. Возьмем для примера манеру разговаривать на естественном языке. Мы все ведем себя так, как если бы обладали знанием всех правил того языка, на котором говорим, например английского, хотя, конечно, мы знаем далеко не все. (Любой, кто запишет эти правила, может рассчитывать на ослепительную карьеру в лингвистике.)
Суть же заключается в том, что разумное поведение, такое как правильная речь, представляется нам как некоторый процесс, регламентируемый определенными правилами, даже в том случае, если мы не можем их точно сформулировать. В искусственном интеллекте правила играют даже более явно выраженную роль в формировании того, что мы называем разумным поведением. Мы говорим, что нечто (агент) ведет себя именно таким образом, поскольку оно располагает представлением правил, уместных для формирования поведенческого акта, который в таком случае претендует на разумность.
Набор порождающих правил — это формализм, который уже использовался в теории автоматов, формальной грамматике, разработке языков программирования, прежде чем стать на службу моделированию психофизиологической деятельности [Newell and Simon, 1972] и экспертных систем [Buchanan and Feigenbaum, 1978]. В литературе по экспертным системам их иногда называют правилами "условие — действие" или "ситуация — действие". Это связано с тем, что такие правила обычно используются для представления эмпирических ассоциативных связей между данными, предъявленными системе, и действиями, которые система должна предпринять в ответ.
В экспертных системах такие правила обычно задают, что нужно сделать с символической структурой, представляющей текущее состояние проблемы, чтобы перейти к представлению, более близкому к решению.
Смысл порождений
Пусть задано порождающее правило в форме
а1$1...am$m-> b1$'1...bn$'n
В нем a1$1 ... аm$m часто называют антецедентом (antecedent) правила, а b,$'1 ... bn$'n консеквентом (consequent) правила, по аналогии с условным выражением логики высказываний (см. главу 8). Условный оператор обычно записывается в виде
p U q1 что означает, "если р, то q", например "если вы упали в реку, то будете мокрым".
Однако часто значок 'U' заменяют значком '->', что вряд ли стоит делать, поскольку последний несет более императивный или разрешающий смысл. Как правило, он говорит не столько о логическом следствии, сколько о том, что нужно сделать, или о том, что можно было бы сделать.
Правило в форме Х->У говорит о том, что можно записать, сгенерировать или породить консеквент У при заданном анцеденте X. Оно не говорит о том, что набор X, У является неразрывно связанной последовательностью, как в примере с купанием в реке. Правила переписывания в теоретической лингвистике называются "порождениями", поскольку правило вида
S->NP+ VP
имеет следующую интерпретацию: "один из способов сформировать предложение S состоит в том, чтобы взять существительное (NР) и добавить к нему глагол (VP)".
Свойство выпуклости в CLIPS: пингвины обретают способность летать (или не обретают)
В языке CLIPS отсутствуют средства определения метаправил. Но в интерпретаторе этого языка имеется возможность анализировать свойство правил, названное разработчиками salience (выпуклость), и отдавать при разрешении конфликтов предпочтение тому правилу, которое характеризуется большим значением этого свойства.
Вспомним пример с классификацией пингвинов, рассмотренный в главе 2. Нужно так организовать систему правил, чтобы то правило, которое имеет отношение именно к пингвинам, имело более высокий приоритет перед более общим правилом, имеющим отношение ко всем птицам. Для этого правилу, касающемуся пингвинов, придается большая "выпуклость", чем правилу, относящемуся ко всем птицам. Это правило как бы выталкивается на авансцену. На языке CLIPS определение правил тогда будет иметь вид
(defrule (bird (type ?X))
(assert (yes))
) (defrule
(declare (salience 100))
(bird (type penguin))
=>
(assert (no)) )
По умолчанию любое правило имеет нулевое значение свойства salience, если оно явно не задано. Этому свойству можно придавать как положительное значение, "выталкивая" соответствующее правило вперед, а можно присвоить и отрицательное значение, насильно отправляя его в конец очереди.
С точки зрения теории не рекомендуется приписывать жесткие приоритеты правилам, поскольку в общем случае это влечет за собой много побочных следствий, но в отдельных конкретных случаях такой подход дает весьма неплохие результаты.
Трассировка программы управления роботом
Представленная ниже карта трассировки будет сформирована при запуске про-граммы в режиме трассировки.
Команда reset обеспечит перезагрузку описания исходного состояния в рабочую память, а команда run запустит программу на выполнение.
В карте трассировки каждая строка, которая начинается с символов ==>, представляет добавление вектора в рабочую память, а строка, которая начинается с символов, <==, — удаление вектора из рабочей памяти. Строки, которые начинаются с 'FIRE', представляют активизацию какого-либо правила. Остальные строки пока ,что игнорируйте.
(reset)
==> f-0 (initial-fact)
=> f-1 (in (object robot) (location RoomA))
==> f-2 (in (object box) (location RoomB))
==> f-3 (goal (action push) {object box)
(from RoomB) (to RoomA)) CLIPS>
(run) FIRE 1 move: f-3, f-2, f-1
<== f-1 (in (object robot) (location RoomA))
==> f-4 (in (object robot) (location RoomB))
FIRE 2 push: f-3, f-2, f-4 <== f_4
(in (object robot) (location RoomB))
==> f-5 (in (object robot) (location RoomA))
<== f-2 (in (object box) (location RoomB))
==> f-6 (in (object box) (location RoomA))
FIRE 3 stop: f-3, f-6
[PRCCODE4] Execution halted during the actions of defrule stop.
CLIPS> (reset)
<== f-0 (initial-fact)
<== f-3 (goal {action push)
(object box) (from RoomB) (to RoomA))
<== f-5 (in (object robot) (location RoomA))
<== f-6 (in (object box) (location RoomA))
CLIPS>
Обратите внимание на то, что выполнение программы останавливается правилом 'stop'.
в этом алфавите существуют аксиомы
Упражнения
1. Как вы понимаете термин "разрешение конфликтов"?
2. Пусть А — это алфавит {а, b} и пусть в этом алфавите существуют аксиомы ab, bа.
Какие строки будут сформированы следующими порождающими правилами:
(Р1) $a ->$ab
(Р2) $b -> $bа
3. Пусть А — это алфавит {а, b} и пусть в этом алфавите существуют аксиомы аа, bb.
Какой набор порождающих правил может сформировать строки вида аа, bb, aabb, bbaa, aabbaa, bbaabb, aabbaabb, bbaabbaa и т.д.
4. На языке CLIPS напишите программу, которая будет выполнять рассуждения на основании силлогизмов. Силлогизм — это множество правил, определяющих, какие умозаключения можно получить из множества суждений. Ниже приведен простой силлогизм
Все Аi являются Вi Все Вi являются Сi Все Аi являются Сi
Все Аi являются Еi Некоторые Аi являются С, Все Сi являются Вi
Все Аi являются Вi
Ни один из Сi не является Вi
Ни один из Сi не является Аi
Эти суждения несложно представить в виде диаграмм Венна. Смоделируйте их с помощью языка CLIPS в виде трех правил.
Вам понадобится единственный шаблон, в котором будет определено, что утверждение (statement) состоит из квантификатора (quantifier), который может принимать одно из трех значений: all (все), some (некоторые) или по (ни один) и двух множеств.
(deftemplate statement
(field quantifier (type SYMBOL))
(field setl (type SYMBOL))
(field set2 (type SYMBOL)) )
Так, выражение "Все А1 являются В" примет вид
(statement (quantifier all) (setl As) (set2 Bs))
Проверить, как работает программа, можно на таких фактах:
(deffacts the-facts
(statement (quantifier all) (setl puppies)
(set2 dogs)) (statement (quantifier all) (setl dogs)
(set2 mammals)) (statement (quantifier all) (setl mammals)
(set2 animals)) (statement (quantifier no) (setl sea-cretures)
(set2 dogs)) (statement (quantifier some) (setl sea-cretures)
(set2 mammals)) )
5. Проанализируйте программу диагностики болей в брюшной полости, представленную в листинге 5.5. (Предупреждаю ипохондриков: эти правила скопированы из первого попавшегося под руку справочника, поэтому не стоит пользоваться ими-для самодиагноза.)
В этой программе есть одно обычное для таких программ ограничение. В исходном состоянии рабочей памяти необходимо представить все симптомы, но многие пациенты говорят только о самом явном (боли) и могут даже и не упомянуть о других, например ссадине на лодыжке.
Модифицируйте программу таким образом, чтобы она запрашивала о забытых симптомах. Самый простой способ сделать это — добавить правила, которые в предпосылках имеют только одно условие — жалобы на боль. Такое условие, например, может иметь вид
(sign (symptom pain) (organ abdomen) (site lower))
Действие правила состоит в том, чтобы добавить в рабочую память вопрос, который нужно задать. Затем понадобится правило, которое собственно и задаст вопрос и поместит в рабочую память вектор sign, сформированный в соответствии с полученным ответом. Шаблон для вектора question (вопрос) имеет такой вид:
(deftemplate question
(field symptom (type SYMBOL))
(field organ (type SYMBOL) (default NIL))
(field answer (type SYMBOL) (default NIL)) )
Таким образом, и образец в левой части порождающего правила, и сопоставляемые с ним элементы в рабочей памяти должны соответствовать этим шаблонам.
В чем, по-вашему, состоит ограничение возможностей подхода, использующего свойство salience, описанное во врезке 5.5?
