Атомно не может быть правильным словом. При моделировании клеточных автоматов или нейронных сетей обычно у вас есть две копии состояния системы. Один из них - текущее состояние, а одно - состояние следующего шага, который вы обновляете. Это гарантирует согласованность, что состояние системы в целом остается неизменным при выполнении всех правил для определения следующего шага. Например, если вы запускаете правила для одной ячейки/нейрона для определения состояния этого для следующего шага, вы затем запускаете правила для следующей ячейки, это сосед, вы хотите использовать в качестве входных данных для этих правил текущее состояние соседней ячейки, а не ее обновленное состояние.Expert/Rule Engine, который обновляет факты атомарно?
Это может показаться неэффективным из-за того, что каждый шаг требует, чтобы вы скопировали все текущие состояния шага в состояния следующего шага перед их обновлением, однако важно сделать это, чтобы точно имитировать систему, как если бы все ячейки/нейроны фактически обрабатывались одновременно, и поэтому все входы для правил/функций стрельбы были текущими состояниями.
Что-то, что меня беспокоило при разработке правил для экспертных систем, - это то, как одно правило может работать, обновлять некоторые факты, которые должны запускать другие правила для запуска, и у вас может быть 100 правил, стоящих в очереди, чтобы работать в ответ, но значимость используется как хрупкий способ обеспечить, чтобы действительно важные выполнялись в первую очередь. По мере выполнения этих правил система меняет больше. Состояние фактов постоянно меняется, поэтому к тому времени, когда вы переходите на обработку 100-го правила, состояние системы значительно изменилось с момента его добавления в очередь, когда оно действительно реагировало на первое изменение факта. Возможно, это изменилось настолько резко, что правило не имеет возможности реагировать на исходное состояние системы, когда оно действительно должно быть. Обычно в качестве обходного пути вы тщательно корректируете свою значимость, но затем это перемещает другие правила вниз по списку, и вы сталкиваетесь с проблемой курицы или яйца. Другие обходные пути включают добавление фактов «флага обработки», которые служат механизмом блокировки для подавления определенных правил до тех пор, пока не будут выполняться другие правила. Все это похоже на хаки и приводит к тому, что правила включают критерии, выходящие за рамки модели основного домена.
Если вы построите действительно сложную систему, которая точно смоделировала проблему, вы действительно хотите, чтобы изменения в фактах были поставлены в отдельную очередь «обновлений», которая не влияет на текущие факты, пока очередь правил не будет пустой , Поэтому давайте скажем, что вы делаете изменение факта, которое заполняет очередь правил, чтобы выполнить 100 правил. Все эти правила будут выполняться, но ни один из них не будет обновлять факты в текущем списке фактов, любое изменение, которое они создают, попадает в очередь на список изменений и гарантирует, что никакие другие правила не активируются, пока текущая партия не обрабатывает. После того как все правила будут обработаны, изменения фактов будут немедленно применяться к текущему списку фактов, а затем активируются новые правила. Повторное полоскание. Поэтому становится очень похоже на то, как обрабатываются нейронные сети или клеточные автоматы. Запуск всех правил в отношении неизменного текущего состояния, изменения очереди, после запуска всех правил применяются изменения текущего состояния.
Этот режим работы представляет собой концепцию, существующую в академическом мире экспертных систем? Мне интересно, есть ли для этого термин.
Имеет ли Drools возможность работать таким образом, чтобы все правила выполнялись без ущерба для текущих фактов, а факт очереди меняется отдельно до тех пор, пока не будут выполнены все правила? Если да, то как? Я не ожидаю, что вы напишите код для меня, но просто некоторые ключевые слова того, что он назвал или ключевые слова в API, некоторые отправные точки, которые помогут мне выполнить поиск.
Есть ли у других двигателей-экспертов/правил эти возможности?
Обратите внимание, что в таком случае правила заказа уже не имеют значения, поскольку все правила, стоящие в очереди для запуска, будут видеть только текущее состояние.Таким образом, когда очередь правил запущена и очищена, Ни одно из правил не видит никаких изменений, которые другие правила делают, поскольку все они выполняются против текущего набора фактов. Таким образом, заказ становится неактуальным, и сложность управления порядком выполнения правил уходит. Все изменения фактов ожидаются и не применяются к текущему состоянию, пока все правила не будут очищены от очереди. Затем все эти изменения применяются сразу и, следовательно, снова приводят к необходимости повторять очередные правила. Поэтому моя цель состоит не в том, чтобы иметь больше контроля над порядком, в котором выполняются правила, а , чтобы полностью исключить порядок выполнения правил, используя механизм, который имитирует одновременное выполнение правил.
То, что вы описываете, звучит для меня скорее как сложная обработка событий. В противном случае, если вы ищете более сильные механизмы для обеспечения порядка, в котором могут работать правила, тогда Drools предлагает такие инструменты, как группы по повестке, но я предпочитаю сами разрабатывать правила, чтобы обеспечить их активизацию. Для типичного шаблона для этого взгляните на «Факты маркера» здесь: https: //engage.redhat.com/forms/rule-design-patterns – Steve
В теории было бы здорово иметь модель основного домена, которая не знает Drools. Тем не менее, на практике, слюни могут стать настолько сложными, что имеет смысл просто сказать, что ваш домен также слюни (на самом деле: он управляется правилами, поэтому вам решать, что правила могут быть рассмотрены в некоторых путь вашего домена). У меня есть много фактов, чтобы мои правила обрабатывались в правильном порядке, это часть моей бизнес-логики. Лично я предпочитаю этот компромисс вместо того, чтобы в значительной степени полагаться на значимость (с «магическими» номерами) или группой участников (со скрытым смыслом, если они вызваны из внешнего DRL). – zenbeni
Спасибо за отзыв. Пытаясь избежать обходных решений, связанных с управлением порядком выполнения правил, см. Обновление. Я действительно рассматривал использование маркерных фактов для подражания одновременному исполнению, отмечая все новые факты как «следующие», и все правила исключали бы эти факты. Тогда одно последнее правило с наименьшим приоритетом удалит «следующий» маркер. Таким образом, «следующие» факты были бы «применены» только после того, как будут выполнены все правила. Мне также пришлось бы обрабатывать изменения и удалять факты аналогичным образом, а не удалять их, но откладывать удаление до тех пор, пока все остальные правила не будут выполнены. – AaronLS