Эксперт / Механизм Правил, который обновляет факты атомарно?
Атомно может быть не то слово. При моделировании клеточных автоматов или нейронных сетей обычно у вас есть две копии состояния системы. Один - это текущее состояние, а второй - состояние следующего шага, который вы обновляете. Это обеспечивает согласованность того, что состояние системы в целом остается неизменным при выполнении всех правил для определения следующего шага. Например, если вы запускаете правила для одной ячейки / нейрона, чтобы определить его состояние для следующего шага, вы затем запускаете правила для следующей ячейки, это сосед, вы хотите использовать в качестве входных данных для этих правил текущее состояние соседней ячейки, а не ее обновленное состояние.
Это может показаться неэффективным из-за того, что каждый шаг требует, чтобы вы скопировали все текущие состояния шага в состояния следующего шага перед их обновлением, однако важно сделать это, чтобы точно симулировать систему, как если бы все клетки / нейроны действительно были обрабатываются одновременно, и, таким образом, все входные данные для правил / функций запуска были текущими состояниями.
Что меня беспокоило при разработке правил для экспертных систем, так это то, как может работать одно правило, обновлять некоторые факты, которые должны запускать другие правила, и у вас может быть 100 правил, поставленных в очередь для выполнения в ответ, но отличие используется как хрупкое способ обеспечить действительно важные запускаются первыми. По мере выполнения этих правил система больше меняется. Состояние фактов постоянно меняется, поэтому к тому моменту, когда вы приступите к обработке 100-го правила, состояние системы значительно изменилось со времени, когда она была добавлена в очередь, когда она действительно реагировала на первое изменение факта. Возможно, оно изменилось настолько радикально, что у правила не было шансов отреагировать на исходное состояние системы, когда оно действительно должно было иметь место. Обычно в качестве обходного пути вы тщательно корректируете его значимость, но затем это перемещает другие правила вниз по списку, и вы сталкиваетесь с проблемой курицы или яйца. Другие обходные пути включают добавление фактов "флага обработки", которые служат механизмом блокировки для подавления определенных правил до тех пор, пока не будут обработаны другие правила. Все это похоже на хаки и приводит к тому, что правила включают критерии, выходящие за рамки базовой модели домена.
Если вы создадите действительно сложную систему, которая точно смоделировала проблему, вы бы действительно хотели, чтобы изменения в фактах были размещены в отдельной очереди "обновлений", которая не влияет на текущие факты, пока очередь правил не станет пустой. Допустим, вы вносите изменение факта, которое заполняет очередь правил для выполнения 100 правил. Все эти правила будут выполняться, но ни одно из них не будет обновлять факты в текущем списке фактов, любое внесенное ими изменение попадает в очередь в список изменений, и это гарантирует, что никакие другие правила не будут активированы во время обработки текущего пакета. Как только все правила обработаны, изменения фактов применяются к текущему списку фактов, все сразу, и тогда запускаются дополнительные правила. Промыть, повторить. Таким образом, становится очень похоже на то, как обрабатываются нейронные сети или клеточные автоматы. Запустите все правила против неизменного текущего состояния, изменения очереди, после выполнения всех правил примените изменения к текущему состоянию.
Является ли этот режим работы концепцией, существующей в академическом мире экспертных систем? Мне интересно, есть ли термин для этого.
Имеет ли Drools возможность работать таким образом, чтобы все правила могли работать без влияния на текущие факты, и факт очереди изменяется отдельно, пока не будут выполнены все правила? Если так, то как? Я не ожидаю, что вы напишите код для меня, но только некоторые ключевые слова того, как он называется, или ключевые слова в API, некоторая отправная точка, чтобы помочь мне искать.
Есть ли у других экспертов / правил правил эта возможность?
Обратите внимание, что в таком случае выполнение правил заказа больше не имеет значения, поскольку все правила, поставленные в очередь на запуск, будут видеть только текущее состояние. Таким образом, поскольку очередь правил запускается и очищается, ни одно из правил не видит каких-либо изменений, которые вносят другие правила, поскольку все они выполняются в соответствии с текущим набором фактов. Таким образом, порядок становится неактуальным, а сложности управления порядком исполнения правил исчезают. Все изменения фактов ожидают рассмотрения и не применяются к текущему состоянию, пока все правила не будут удалены из очереди. Затем все эти изменения применяются сразу, и поэтому соответствующие правила снова ставятся в очередь. Поэтому моя цель не в том, чтобы лучше контролировать порядок выполнения правил, а в том, чтобы полностью исключить проблему порядка выполнения правил, используя механизм, имитирующий одновременное выполнение правил.
2 ответа
Если я понимаю, что вы описываете:
- У вас есть один факт, который управляется многими правилами
- Каждое правило должно применяться к исходному значению вашего факта и не имеет права изменять значение факта (чтобы не изменять исполнения других правил)
- Затем вы пакетируете все обновления, сделанные по правилам вашего факта.
- Другие правила применяются к этому новому значению факта аналогичным образом "одновременно"
Мне кажется, что это шаблон проектирования Unit of Work, точно так же, как Hibernate реализует его (и многие другие ORM): http://www.codeproject.com/Articles/581487/Unit-of-Work-Design-Pattern
Обычно вы сохраняете в памяти все изменения (например, в "техническом" факте), а затем выполняете "транзакцию", когда все правила, основанные на начальном значении, запускаются, что обновляет значение факта, и так далее. Hibernate делает это со своим сеансом (вы изменяете прикрепленный объект, затем, когда требуется, он выполняет запрос на обновление базы данных, а не все модификации объекта java вызывают запросы к вашей базе данных).
Тем не менее, у вас будут проблемы, если конфликты обновлений (то же самое значение поля фактов изменено, какое значение выбрать? То же, что конфликт исходного управления версиями), вам придется определить детерминистский способ заказа обновлений, но он будет определен только один раз и доступен для всех правил и для других изменений это будет работать без проблем.
Эта работа может / не может работать на основе вашего довольно расплывчатого описания. Если вы действительно обеспокоены правилами, запускающими дальнейшие активации, почему бы не поставить промежуточное состояние в очередь самостоятельно. И как только текущая оценка будет завершена, вставьте эти новые факты в рабочую память.
Вы должны были бы призвать fireAllRules() после вставки каждого факта это может быть довольно дорого. И затем в правилах, вместо того, чтобы вставлять факты напрямую, помещать их в очередь. Как только вышеуказанный вызов вернется, пройдитесь по очереди, делая то же самое (или после полной вставки исходных фактов...)
Я полагаю, что это будет довольно медленно, чтобы ускорить процесс, вы могли бы иметь несколько параллельных рабочих воспоминаний с одинаковыми правилами и оценивать несколько фактов за один раз в несколько очередей и т. Д. Но все становится довольно волосатым...
Во всяком случае, просто идея, которая слишком длинна для комментариев...