Атомно не может быть правильным словом. При моделировании клеточных автоматов или нейронных сетей обычно у вас есть две копии состояния системы. Один из них - текущее состояние, а одно - состояние следующего шага, который вы обновляете. Это гарантирует согласованность, что состояние системы в целом остается неизменным при выполнении всех правил для определения следующего шага. Например, если вы выполняете правила для одной ячейки/нейрона для определения состояния этого для следующего шага, вы затем запускаете правила для следующей ячейки, это сосед, вы хотите использовать в качестве входных данных для этих правил текущее состояние соседней ячейки, а не ее обновленное состояние.
Это может показаться неэффективным из-за того, что каждый шаг требует, чтобы вы скопировали все текущие состояния шага в состояния следующего шага перед их обновлением, однако важно сделать это, чтобы точно имитировать систему, как если бы все клетки/нейроны фактически обрабатывались одновременно, и поэтому все входы для правил/функций запуска были текущими состояниями.
Что-то, что беспокоило меня при разработке правил для экспертных систем, - это то, как можно запускать одно правило, обновлять некоторые факты, которые должны приводить к запуску других правил для запуска, и у вас может быть 100 правил, стоящих в очереди, чтобы работать в ответ, но характер используется как хрупкий способ гарантировать, что действительно важные из них выполняются первыми. По мере выполнения этих правил система меняет больше. Состояние фактов постоянно меняется, поэтому к тому времени, когда вы переходите на обработку 100-го правила, состояние системы значительно изменилось с момента его добавления в очередь, когда оно действительно реагировало на первое изменение факта. Возможно, это изменилось настолько резко, что правило не имеет возможности реагировать на исходное состояние системы, когда оно действительно должно быть. Обычно в качестве обходного пути вы тщательно корректируете свою значимость, но затем это перемещает другие правила вниз по списку, и вы сталкиваетесь с проблемой курицы или яйца. Другие обходные пути включают добавление фактов "флага обработки", которые служат механизмом блокировки для подавления определенных правил до тех пор, пока не будут выполняться другие правила. Все они чувствуют себя как хаки и вызывают правила, которые включают критерии, выходящие за рамки только основной модели домена.
Если вы построите действительно сложную систему, которая точно смоделировала проблему, вы действительно хотите, чтобы изменения в фактах были поставлены в отдельную очередь "обновлений", которая не влияет на текущие факты, пока очередь правил не будет пустой. Поэтому давайте скажем, что вы делаете изменение факта, которое заполняет очередь правил, чтобы выполнить 100 правил. Все эти правила будут выполняться, но ни один из них не будет обновлять факты в текущем списке фактов, любое изменение, которое они создают, попадает в очередь на список изменений и гарантирует, что никакие другие правила не активируются, пока текущая партия не обрабатывает. После того как все правила будут обработаны, изменения фактов будут немедленно применяться к текущему списку фактов, а затем активируются новые правила. Повторное полоскание. Поэтому становится очень похоже на то, как обрабатываются нейронные сети или клеточные автоматы. Запустить все правила в отношении неизменного текущего состояния, изменения очереди, после запуска всех правил применяются изменения в текущем состоянии.
Является ли этот режим работы концепцией, существующей в академическом мире экспертных систем? Мне интересно, есть ли для этого термин.
Имеет ли Drools возможность работать таким образом, чтобы все правила запускались без влияния на текущие факты, а факт очереди меняется отдельно до тех пор, пока не будут выполнены все правила? Если да, то как? Я не ожидаю, что вы напишите код для меня, но только некоторые ключевые слова того, что он назвал или ключевые слова в API, некоторые отправные точки, чтобы помочь мне выполнить поиск.
Есть ли у других двигателей-экспертов/правил эти возможности?
Обратите внимание, что в таком случае правила порядка уже не имеют значения, потому что все правила, стоящие в очереди для запуска, будут видеть только текущее состояние. Таким образом, когда очередь правил запущена и очищена, ни одно из правил не видит изменений, которые другие правила делают, потому что все они выполняются против текущего набора фактов. Таким образом, порядок становится неактуальным и сложность управления порядком выполнения правил уходит.Все изменения фактов ожидаются и не применяются к текущему состоянию, пока все правила не будут удалены из очереди. Затем все эти изменения применяются сразу и, следовательно, снова приводят к необходимости повторять очередные правила. Поэтому моя цель состоит не в том, чтобы иметь больше контроля над порядком, в котором выполняются правила, а , чтобы полностью избежать выполнения порядка выполнения правил, используя механизм, который имитирует одновременное выполнение правил.
