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

Если взглянуть на (возможно, более старые) руководства по Drools или некоторым другим движкам правил, то одной из иллюстраций их добавленной стоимости является решение головоломок, таких как головоломка Miss Manners (руководство по Drools). Теперь такие головоломки естественным образом формулируются и решаются с использованием Prolog или более поздних языков программирования с ограничениями, и возникает вопрос, зачем кому-то использовать Drools для этой цели. Дополнительной ценностью, которую Prolog и CPL придают в этом случае, является их способность естественным образом формулировать головоломку как набор логических предикатов и автоматически искать пространство решений (с CPL, более эффективным в этом отношении). Но какова добавленная стоимость таких продуктов, как Drools (я имею в виду, помимо всего прочего, взятие, например, файла Excel и перевод его в набор правил)?

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

С другой стороны, хотя ясно, что алгоритм Rete кэширует набор правил в виде некоторой структуры (структур) данных, таким образом (насколько я понимаю) более эффективно оценивать выходные данные, если некоторые входные данные изменились, и предоставляя средства для эффективного обновления этой структуры данных для постепенных изменений, мне (для меня) трудно понять основную идею и, тем более, ее эффективность (по сравнению с тем, что от «Пролог» до CLP)? К сожалению, трудно найти хорошие ссылки, которые рассматривают алгоритм Rete в этом более широком контексте.

Документация Drools, к сожалению, не очень информативна в этом отношении. Максимум, что я смог найти, было: «Алгоритм Rete, алгоритм Leaps и его потомки, такие как Drools Reteoo (и Leaps), предоставляют очень эффективные способы сопоставления шаблонов правил с данными ваших доменных объектов. Они особенно эффективны, когда у вас есть наборы данных, которые не меняются полностью (так как механизм правил может помнить прошлые матчи). Эти алгоритмы проверены битвой ». Очень эффективно - по сравнению с чем? Битва доказана - можно ли указывать на реальные приложения?

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

Я думаю, что аргумент для многих коммерческих систем бизнес-правил, использующих механизмы прямого связывания (например, Drools) против обратного связывания (Prolog), заключается в том, что многие «программисты Джо» привыкли иметь дело с логикой IF / THEN / ELSE - и это делает ее целым намного легче продать в массы. Я не думаю, что технические достоинства имеют какое-либо отношение к этому.

Я публикую это как вики сообщества, потому что это мое довольно цветное мнение, а не реальный ответ.

Слюни недавно добавили обратную цепочку, плавно переходя на язык drl. Так что теперь вы получаете преимущества обоих слов.

Он еще не обладает всеми функциями пролога, например, «вырезать». Но это результаты дерева объединения и деривации будут работать так, как ожидают прологи, то есть полная поддержка транзитивных замыканий. И функции будут продолжать расти, такие как поддержка табуляции, вырезания, унификация выражений.

Вы можете использовать правила прямого «реактивного» или обратного «запроса» по отдельности или использовать их вместе; где правило реагирования может объединяться с результатами запроса.

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

Смотрите разделы New & Noteworth о том, когда было добавлено «обратное сцепление»: http://blog.athico.com/2012/05/drools-540final-released.html

Поэтому я думаю, что ваш вопрос был бы лучше сформулирован, зачем вам использовать что-то еще, когда у вас есть Гибридная система рассуждений, такая как Drools? http://blog.athico.com/2012/05/drools-54-artificial-intelligence.html

Я согласен с вами, что Пролог является более мощным, чем Drools. Но я думаю, что Drools привлекателен для корпоративных клиентов из-за причудливых интерфейсных инструментов и интеграций, которые Drools имеет с другими популярными корпоративными приложениями. Я думаю, что эти правила затем сохраняются в базе данных, где многие движки Drools могут использовать их немедленно.

Изменение правил во время выполнения - довольно динамичный способ использования движка Drools, и он поддерживается. Я полагаю, что у Пролога могла бы быть подобная система, но это не существует AFAIK. Куда пойдут эти правила или отредактированные правила? заявлено в БД программы? При перезапуске эти правила будут потеряны. Будем ли мы сохранять их в общей базе данных, а затем включать их в программу по мере необходимости? Prolog может быть полезен, но Drools уже хорошо интегрирован в стек корпоративных приложений, так зачем же сводить себя с ума (кроме веселья)?

«Я согласен с вами, что Prolog более мощный, чем Drools. Но я думаю, что Drools привлекателен для корпоративных клиентов из-за причудливых интерфейсных инструментов и интеграций, которые Drools имеет с другими популярными корпоративными приложениями»

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

Слюни начались с того, что были основаны на CLIPS . CLIPS была более старой « производственной системой », и, как и все производственные системы, представляет собой систему прямой цепочки. Многие исследования Rete «потемнели», так как создатель в итоге пошел работать на компании, где алгоритмы были интеллектуальной собственностью. Rete версии 3 принадлежит людям, которые делают оценки FICO , так что да, это «доказано сражение».