Экспертные системы, в которых поиск решений управляется данными, предполагают постоянный диалог с пользователем: система задаёт уточняющие вопросы, накапливает ответы и движется к решению итеративно. Это отличает их от классических запрос-ответных сервисов и создаёт нетривиальные требования к архитектуре — особенно когда пользователей несколько.
Существуют три принципиальных варианта организации доступа. Первый — локальная копия: база знаний реплицируется на каждое рабочее место, пользователь работает автономно. Плюс — независимость от сети; минус — необходимость синхронизировать изменения между копиями, что неизбежно порождает конфликты версий. Этот вариант удобен для разработки и отладки или для сугубо личного использования. Второй вариант — толстый клиент в локальной сети: база знаний хранится на сервере, механизм поиска работает на рабочей станции. Актуальность данных обеспечена централизованно, но конфликты при одновременном редактировании никуда не исчезают. Третий вариант — тонкий клиент: вся обработка на сервере, рабочее место не требует ресурсов. Проблема коллизий при записи остаётся той же.
| Вариант | Где хранится БЗ | Где выполняется поиск | Главное преимущество | Главная проблема |
|---|---|---|---|---|
| 1. Локально | На каждом рабочем месте (копия) | На рабочем месте | Автономность | Синхронизация копий и коллизии версий |
| 2. Толстый клиент (сеть) | На сервере | На рабочем месте | Единая актуальная БЗ | Коллизии при одновременном редактировании |
| 3. Тонкий клиент (сеть) | На сервере | На сервере | Минимальные требования к клиенту | Коллизии при одновременном редактировании |
Доступ через интернет — браузер или веб-клиент — теоретически может эмулировать все три варианта, но с существенной оговоркой. Веб-технологии построены на модели запрос-ответ: сервер не держит состояние процесса между обращениями. Для обычного диалога это приемлемо — данные накапливаются, но сам процесс обработки каждый раз начинается заново. Для поиска решений, управляемого данными, это критично: между запросами нужно сохранять репозитории информационных блоков, очереди параметров, флаги событий, промежуточные отчёты — весь контекст итеративного поиска.
Браузерный доступ требует заморозки состояния серверного процесса между запросами из-за отсутствия постоянного соединения.
Автор предлагает схему из 13 шагов, которая обходит это ограничение. Браузер передаёт данные и запускает серверный процесс, затем периодически опрашивает сервер на предмет готовности ответа. Серверный процесс выполняется до момента, когда нужны дополнительные данные от пользователя или решение найдено. Если решение не найдено, состояние процесса «замораживается»: сохраняются все накопленные данные, процесс завершается, выставляется флаг ожидания. Браузер забирает данные, анализирует управляющие сигналы и при необходимости передаёт уточнения, перезапуская процесс с точки остановки. Цикл повторяется до получения результата или явного требования остановки со стороны пользователя. Схему облегчает то, что поиск решений выполняется однотипными циклами — дополнительные данные могут потребоваться только по завершении очередного цикла.
Отдельный блок посвящён предотвращению коллизий при редактировании базы знаний. Проблема сложнее, чем в обычных базах данных: информационные блоки связаны через терминологический словарь, и простое сравнение записей по позиции не работает. Автор формулирует три правила. Правило первое: не вносить изменения в один информационный блок одновременно с разных мест доступа — на время редактирования остальные точки блокируются, либо конфликтующие изменения сохраняются как конфликтные документы для последующего разбора. Правило второе: любое изменение в блоке запускает каскадную проверку связанных блоков; до завершения синхронизации новые изменения не допускаются. Правило третье касается диапазонов допустимых значений: если в блоке А изменился диапазон входного параметра, необходимо проверить пересечение диапазонов для этого параметра во всех блоках, где он используется для определения того же результата — иначе система окажется в состоянии неопределённости.
Материал представляет собой часть серии статей об архитектуре экспертных систем с управляемым данными поиском решений. Терминологический словарь и состав информационных блоков рассматриваются в отдельных публикациях той же серии.
