Продукционная модель знаний: факты, правила и разрешение конфликтов
Продукционная модель знаний используется в системах символьного вывода, которые применяют правила вида «условие — действие» к рабочему набору фактов. Система находит подходящие правила, выбирает, какое из них выполнить, и обновляет факты или выполняет заданное действие. Разрешение конфликтов важно, потому что несколько правил могут соответствовать одной ситуации, предлагая разные следующие шаги.
Здесь «продукция» означает правило, которое порождает следствие при выполнении его условий. Речь не о производственной линии и не просто о приложении ИИ, работающем в рабочей среде.
Автор: Ai Flowi · Опубликовано
Факты, продукционные правила и цикл управления
Рабочая память хранит факты, доступные интерпретатору в данный момент. База правил содержит определения условий и действий. Механизм управления сопоставляет условия правил с рабочей памятью, разрешает конкуренцию между подходящими правилами и выполняет выбранное правило. После изменения при сопоставлении нужно использовать обновлённые факты.
Например, case_state = ready — факт в небольшом упражнении по проверке запроса. Продукционное правило может гласить: если дело готово и следующее действие ещё не выбрано, запросить проверку. Факт фиксирует состояние; правило выражает допустимый переход. Ни то ни другое не означает, что модель самостоятельно обучилась находить этот переход.
Соответствие означает, что условия правила выполнены, а не что его действие уже произошло. Разделяйте набор подходящих правил и запись о выполненных правилах. Иначе объяснение может ошибочно представить все допустимые действия как завершённые.
Синтетический случай с конкурирующими правилами
Это вымышленная трассировка символьного вывода, а не запись выполнения Workflow. Запрос отмечен как готовый к проверке, но заявитель его отозвал. Все действия в примере остаются внутри записи состояния: сообщения не отправляются, внешние документы не изменяются.
На узком экране прокручивайте таблицы фактов и правил по горизонтали. Переведите фокус на таблицу с клавиатуры и используйте клавиши со стрелками, чтобы просмотреть остальные столбцы.
| Факт | Значение | Смысл в этом упражнении |
|---|---|---|
| request_state | withdrawn | Для этого запроса зафиксирован подтверждённый отзыв. |
| case_state | ready | Дело было готово до обработки отзыва. |
| next_action | undecided | Следующий шаг ещё не выбран. |
Два правила ниже намеренно пересекаются. Приоритет — явно заданная политика этого вымышленного интерпретатора: выбирается правило с большим числовым приоритетом. Это не встроенное поле приоритета компонента Condition в AI Flowi Workflow.
| Правило / приоритет | Условия | Действие при выполнении |
|---|---|---|
| R1 / 20 | request_state имеет значение withdrawn; next_action имеет значение undecided. | Установить case_state = closed и next_action = archive_request. |
| R2 / 10 | case_state имеет значение ready; next_action имеет значение undecided. | Установить next_action = request_review. |
Изначально подходят и R1, и R2. Если сначала выполнить R2, проверка будет выбрана до обработки отзыва. Поэтому в примере R1 имеет преимущество. Числа выражают это решение; они не являются оценками уверенности или показателями качества правил.
Сопоставить, разрешить конфликт, выполнить и сопоставить снова
| Этап | Подходящие правила | Решение и факты |
|---|---|---|
| Начальное сопоставление | R1, R2 | Исходные факты в рабочей памяти удовлетворяют условиям обоих правил. |
| Разрешение конфликта | Выбрано R1 | Приоритет 20 выше приоритета 10. |
| Выполнение R1 | R2 не выполнено | case_state становится closed; next_action становится archive_request. |
| Повторное сопоставление | Нет | Оба правила требуют значения undecided для next_action; R2 также требует значения ready для дела. |
| Завершение цикла | Нет | Вернуть archive_request как выбранный следующий шаг. |
Трассировка завершается, потому что выбранное действие меняет факты, удовлетворявшие условиям правил. Если лишь написать «архивировать запрос» в объяснении, оставив next_action в состоянии undecided, условия R1 снова окажутся выполненными. Обновление должно быть частью перехода состояния интерпретатора.
Завершение этого цикла принятия решения не означает, что запрос архивирован. Если действие нужно, его должна подтвердить отдельная санкционированная процедура. Интерпретатор правил выбрал следующий шаг, но не выполнил его.
Почему для разрешения конфликтов в рабочей системе нужна явно заданная стратегия?
Приоритет — одна из возможных стратегий. Другие интерпретаторы могут предпочитать более конкретное подходящее правило, учитывать свежесть фактов или использовать постоянный порядок правил. Укажите действующую политику, не предполагая, что смысл «более конкретного» очевиден. Правило с большим числом условий не обязательно уместнее.
Если у двух правил одинаковый приоритет, упражнение останавливается для проверки, а не делает неявный выбор. Если ни одно правило не подходит, возвращается «Нет применимого правила», что отличается от завершённой задачи. Реальному интерпретатору также нужна политика повторного выполнения правил и обработки фактов, изменённых действиями. Эти решения относятся к его механизму управления.
Явные правила помогают проверяющим понять, почему выбрано действие. Они не исправляют неверный факт или противоречивую базу правил. Даже аккуратная трассировка может отражать точное выполнение ошибочной стратегии, поэтому проверяйте и происхождение фактов рабочей памяти, и предполагаемые последствия каждого правила.
Что иллюстрирует один узел Condition
Описание интерфейса сравнения см. в справочнике Condition; иллюстрация R1 здесь имеет статус документировано: документирована в каталоге, но не проверена Ai Flowi в промышленной эксплуатации.
пример конфигурации, а не запись теста
Для сравнения из R1 в рабочем пространстве Workflow подключите синтетическую запись фактов к Condition.data_input и задайте key_name = request_state, operator = "equals" и compare_value = withdrawn; используйте конфигурацию из справочника для изучения результата ветвления.
Здесь показано сравнение одного ключа из R1. Оно не проверяет полное составное условие R1, не поддерживает рабочую память, не назначает приоритеты, не обновляет case_state и не запускает цикл сопоставления и выполнения. В экспортированном интерфейсе Condition не указаны ни список правил к выполнению, ни вход приоритета. Для реализации этой семантики нужна дополнительная, отдельно проверенная логика приложения.
Сравните две гипотетические записи фактов: в одной request_state = withdrawn и next_action = undecided; в другой тот же отзыв, но next_action = archive_request. Сравнение одного ключа определит отзыв в обеих, тогда как полное R1 подходит только к первой. Это различие показывает, почему результат ветвления нельзя считать подтверждением соответствия продукционному правилу. Для локального сравнения не нужны учётные данные провайдера модели; полная трассировка правил остаётся отдельным учебным упражнением.
Типичные ошибки и связанные понятия
Не называйте набор визуальных ветвей механизмом логического вывода, если не реализованы семантика сопоставления, разрешения конфликтов и обновления состояния. Не утверждайте, что выполнение правил демонстрирует обучение. Правила можно составить вручную; их изменение после проверки является настройкой, если не определён реальный процесс обучения.
Фиксированного условия достаточно, когда одно проверенное поле определяет следующую ветвь. Для этой более узкой задачи используйте существующее руководство по маршрутизации If-Else. Не усложняйте эту задачу созданием интерпретатора правил, если не нужны конкурирующие правила или повторные обновления фактов.
Примеры интеллектуальных агентов классифицируют способы выбора действий. ReAct рассматривает циклы действий и наблюдений. Планирование действий агента объясняет предварительные условия выполнения шагов; продукционное правило может выбрать одно следующее действие без построения такого плана.