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

Якщо переглядати (можливо, старші) посібники з Drools або деякі інші двигуни правил, однією з ілюстрацій їх додаткової вартості є розгадування загадок, таких як головоломка «Міс Маннерс» (посібник з Drools). Тепер такі головоломки природно формулюються та вирішуються за допомогою Prolog або новіших мов програмування обмежень, і виникає питання, чому хтось би використовував Drools для цієї мети. Додана цінність, яку надають Prolog та CPL в цьому випадку, полягає в їх здатності природним чином складати головоломку як набір логічних предикатів і автоматично шукати простір рішень (CPL є більш ефективним у цьому відношенні). Але яка додаткова цінність такого продукту, як Drools (я маю на увазі, окрім дзвіночків, як взяти, наприклад, файл Excel та перекласти його на набір правил)?

Більш конкретно, Prolog здійснює пошук зворотних треків, CLP здійснює пошук зворотних треків із поширенням обмежень, і тому замість пошуку, так би мовити, всього декартового продукту просторів для окремих змінних, вони вирізають великі частини цього простору продукту. Саме це робить їх ефективними та корисними. І Пролог, і CLP широко обговорюються в літературі.

З іншого боку, хоча зрозуміло, що алгоритм Rete кешує набір правил у вигляді деяких структур даних, таким чином (наскільки я розумію), що робить його більш ефективним для оцінки результатів, якщо деякі з вхідних даних були змінені, і надаючи засоби для ефективного оновлення цієї структури даних для поступових змін, мені складно (для мене) зрозуміти основну ідею, а тим більше її ефективність (порівняно з тим, що? Prolog? до CLP)? На жаль, важко знайти хороші посилання, які переглядають алгоритм Rete в цьому більш широкому контексті.

Документація щодо Drools, на жаль, не дуже інформативна в цьому відношенні. Найбільше, що я міг знайти, це "Алгоритм Rete, алгоритм стрибків та його нащадки, такі як Reteoo Drools (і Leaps), забезпечують дуже ефективні способи відповідності шаблонів правил до даних вашого об'єкта домену. Це особливо ефективно, коли у вас є набори даних, які не змінюйте повністю (оскільки двигун правил може запам'ятати минулі матчі). Ці алгоритми підтверджені в битві ". Дуже ефективний - порівняно з чим? Битва доведена - чи можна вказувати на реальні програми?

Я був би вдячний, якщо можна було б кинути трохи світла на цю тему або дати справжню інформацію.

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

Я публікую це як вікі спільноти, оскільки це моя досить кольорова думка, а не реальна відповідь.

Drools, нещодавно додавши назад ланцюжок, легко перекладається на мову drl. Тож тепер ви отримуєте переваги обох слів.

Він ще не має всіх можливостей prolog, наприклад, немає "cut". Але результати об’єднання та дериваційного дерева працюватимуть так, як очікують прологи, тобто повна підтримка транзитивних закриттів. І функції будуть продовжувати зростати, такі як підтримка табуляції, вирізання, об'єднання в виразах.

Ви можете використовувати окремі "реактивні" або "зворотні" правила запиту окремо або використовувати їх разом; де правило реакції може приєднатися до результатів запиту.

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

Дивіться розділи Нові та Нотаріати щодо того, коли було додано "зворотні ланцюги": http://blog.athico.com/2012/05/drools-540final-released.html

Тому я думаю, що ваше питання було б чіткіше сформульоване, чому ви хочете використовувати що-небудь інше, якщо у вас є система гібридної розвідки, як Drools? http://blog.athico.com/2012/05/drools-54-artificial-intelligence.html

Я згоден з вами, що Prolog є потужнішим за Drools. Але я думаю, що Drools приваблює корпоративного клієнта через вишукані інструменти передньої частини та інтеграції, які Drools має з іншими популярними програмами для підприємств. Я думаю, що ці правила потім зберігаються в базі даних, де багато двигуни Drools можуть використовувати їх негайно.

Зміна правил під час виконання - досить динамічний спосіб використання двигуна Drools, і він підтримується. Я вважаю, що Prolog міг би мати подібну систему, але це не існує AFAIK. Куди поділися ці правила чи редаговані правила? стверджується в db програми? При перезапуску ці правила будуть втрачені. Чи будемо ми зберігати їх до спільного db і потім за необхідності стверджувати їх у програмі? Prolog може бути корисним, але Drools вже добре інтегрований у стек додатків для підприємств, то чому навіщо зводити з розуму (крім розваги)?

"Я згоден з вами, що Prolog є більш потужним, ніж Drools. Але я думаю, що Drools приваблює корпоративного клієнта через вигадливі інструменти передньої частини та інтеграції, які Drools має в інших популярних корпоративних додатках"

Відповідно до мого коментаря вище, Drools тепер реалізує дерева деривації на основі мети так само, як і Prolog. Далі Drools може щось зробити з тим деревом девіації, що не може більшість інших систем Prolog. Drools може матеріалізувати дерево деривації у подання та отримувати реактивні оновлення у міру зміни базових термінів групи.

Drools почали, базуючись на CLIPS . CLIPS була старшою " виробничою системою ", і як і всі виробничі системи, це система прямого ланцюга. Чимало досліджень щодо Рете "потемніло", оскільки розробник закінчив працювати над компаніями, де алгоритми були інтелектуальною власністю. Версія 3 Rete належить людям, які роблять бали FICO , так що так, це "бій перевірений".