Что такое гибридные механизмы вывода?

Question

Я пытался много искать по этому поводу, даже если я сделал похожий пост, прошу прощения.

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

Кроме того, если я хотел бы создать движок с обоими методами логического вывода, улучшается ли используемый алгоритм сопоставления (Rete, Treat и т. Д.) Для начала?

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

Спасибо!

Answer 1

Я бы посоветовал взглянуть на Джесс и Друлс. Оба эти инструмента реализуют прямое и обратное сцепление, поэтому вы можете посмотреть, как это практически реализовано.

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

(defrule determine-engine-state ""
   (not (engine-starts ?))
   (not (repair ?))
   =>
   (assert (engine-starts (yes-or-no-p "Does the engine start (yes/no)? "))))

(defrule determine-rotation-state ""
   (engine-starts no)
   (not (repair ?))   
   =>
   (assert (engine-rotates (yes-or-no-p "Does the engine rotate (yes/no)? "))))

(defrule determine-gas-level ""
   (engine-starts no)
   (engine-rotates yes)
   (not (repair ?))
   =>
   (assert (tank-has-gas
              (yes-or-no-p "Does the tank have any gas in it (yes/no)? "))))

(defrule tank-out-of-gas ""
   (tank-has-gas no)
   (not (repair ?))
   =>
   (assert (repair "Add gas.")))

Правила задания вопросов содержат предварительную информацию, содержащуюся в условиях, которые сложнее поддерживать.

При автоматической генерации целей правила можно переписать так:

(defrule determine-engine-state ""
   (goal (engine-starts ?))
   =>
   (assert (engine-starts (yes-or-no-p "Does the engine start (yes/no)? "))))

(defrule determine-rotation-state ""
   (goal (engine-rotates ?))
   =>
   (assert (engine-rotates (yes-or-no-p "Does the engine rotate (yes/no)? "))))

(defrule determine-gas-level ""
   (goal (tank-has-gas ?))
   =>
   (assert (tank-has-gas
              (yes-or-no-p "Does the tank have any gas in it (yes/no)? "))))

(defrule tank-out-of-gas ""
   (not (repair ?))
   (engine-starts no)
   (engine-rotates yes)
   (tank-has-gas no)
   =>
   (assert (repair "Add gas.")))

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

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