Программные продукты и системы

Эффективность формирования БЗ зависит от способа представления знаний. При выборе надлежащего способа можно избежать чрезмерного усложнения системы и упростить переход от одних инструментальных средств к другим. Конечно, выбор оптимального способа представления знаний во многом зависит от характера и сложности решаемых прикладных задач.

Можно выделить следующие основные формы представления знаний: 1) данные, которые включают в себя факты и, в частности, текстовую информацию, такую как различные документы, учебники, пояснения, библиографию и т.д.; 2) алгоритмы, реализуемые либо с помощью программ на языках программирования, либо с помощью языков логического программирования; 3) правила, которые также могут быть записаны с помощью средств представления логических правил типа продукционных систем или языков типа Пролог; 4) диалоги с пользователем, которые реализуются с помощью графических и языковых средств.

СЛОВАРИ-СПРАВОЧНИКИ ЭКСПЕРТНОЙ СИСТЕМЫ

В настоящей работе рассматривается только реляционная модель данных, из которой другие модели могут быть получены путем соответствующего преобразования [2].

На первом шаге создания базы данных экспертной системы необходимо средствами языка описания данных используемой СУБД создать описание справочников системы. В свою очередь справочники могут быть тоже организованы в виде реляционной базы данных [б].

Будем задавать описание отношения в виде R(A1,A2, .... Ak), где R - имя отношения, Ai - имя атрибута.

Кодированные имена отношений и атрибутов используются авторами из реального проекта гибридной экспертной системы экспериментального моделирования [9].

Рассмотрим структуру справочников системы.

Самым нижним уровнем информационного фонда экспертной системы является набор текстовой информации, подготовленной с помощью различных текстовых редакторов (например Лексикон или ChiWriter). Эта информация включает в себя документы, библиографию, инструкции, пояснения, объяснения логического вывода и т.д.

Чтобы иметь возможность обмениваться текстовой информацией между различными экспертными системами, эта информация должна быть отделена от текстов программ или от логических правил. Естественно поместить данную информацию в базу данных и организовать ее в виде отношения. В этом случае модель текстовых данных будет иметь следующую структуру:

EDOCUM (PAGE, NLIN, TEXT), где PAGE - номер страницы документа, NLIN - номер строки документа, TEXT ~ строка документа. Фрагменты текста в отношении могут располагаться в

любом порядке. С его помощью осуществляется прямой доступ к текстовой информации. Пример заполнения отношения показан на рисунке 1.

Существенным ограничением при такой организации текстовой информации является использование соответствующих шрифтов и возможности экспертной системы по отображению различных нестандартных символов. Так, например, если текст подготовлен с помощью редактора, поддерживающего графическое отображение символов, то его невозможно представить с помощью средств, рассчитанных только на шестнадцатиричные коды символов. Выходом здесь могло бы стать использование СУБД, поддерживающих битовые поля данных переменной длины, в которых можно хранить любую графическую информацию.

На первом шаге формирования справочников создается описание отношения EDOCUMf и с помощью утилиты загрузки данных вся текстовая информация переписывается из текстовых файлов в базу данных. При этом первоначально происходит преобразование обычного текстового файла в текстовой файл с размеченными страницами и строками. Как правило, каждый документ представляется одной страницей, номер которой задается в первой записи файла. Исходя из размера атрибута, отводимого под номер строки, количество строк в документе не должно превышать 1000.

Файлы с текстами могут поставляться уже размеченными, то есть каждая строка документа имеет вид, показанный на рисунке 1.

Общее описание отношений базы данных содержится в справочнике отношений ESPREL, который может иметь следующую структуру: ESPREL(KREL, RTXT, INDX, NPAG, NLNB, NLNE), где KREL — код отношения, RTXT — наименование отношения (краткая поясняющая информация к отношению), INDX - признак индексированности, то есть имя индекса, который необходимо создать к отношению, если необходимо, или код неопределенности, NPAG - номер страницы расположения фрагмента текста, поясняющего подробно назначение отношения в отношении EDOCUM, NLNB - номер начальной строки, NLNE - номер конечной строки текста. Атрибуты NPAG, NLNB, NLNE однозначно определяют место расположения информации поясняющего характера к отношению.

Путем операции естественного соединения отношений EDOCUM и ESPREL можно получить полное текстовое описание всех отношений, используемых в системе.

Отношение ESPATR предназначено для описания атрибутов всех отношений базы данных. Оно может иметь следующую структуру:

ESPATR(KREL, KATR, ATXT, FORM, PICT, NPAG, NLNB, NLNE).

Здесь KREL,NPAG,NLNB,NLNE описаны выше; KATR - код атрибута. На имя атрибута наложено жесткое ограничение в том, что его длина не должна превышать четырех символов. Это связано с тем, чтобы добиться универсальности схемы базы данных для различных СУБД; АТХТ-наименование атрибута, то есть краткая поясняющая информация к атрибуту; FORM - формат атрибута; PICT— шаблон для атрибута.

Отношение EDOMEN предназначено для описания множества возможных значений атрибутов (доменов). Оно имеет следующую структуру: EDOMEN (KREL, KATR, KODD, DTXT, NPAG, NLNB, NLNE).

Здесь KREL, KATR, NPAG, NLNB, NLNE описаны выше; KODD - код домена; DTXT- наименование домена, то есть краткая поясняющая информация к домену.

Следующей основной частью справочников системы должен быть тезаурус используемых терминов. При этом тезаурус поддерживает неструктурируемую модель данных предметной области, точнее в тезаурус включаются понятия и переменные, которые не вошли в реляционную модель данных.

Информационно-поисковый тезаурус может быть представлен в базе данных следующими тремя отношениями.

Отношение ETSAUR содержит список кодов и наименований дескрипторов, то есть основных понятий или ключевых слов. Схема отношения может быть представлена в виде: ETSAUR(KDSC, NDSCj. Здесь KDSC - код дескриптора, соответствующего некоторому понятию, NDSC -наименование дескриптора.

Отношение ETSDOC содержит ссылки на отношение EDOCUM с подробным описанием соответствующих дескрипторов, если это необходимо. Структура отношения следующая:

ETSDOCfKDSC, NPAG, NLNB, NLNE).

Все атрибуты отношения описаны выше.

Отношение ERELDS задает связи между понятиями, закодированными дескрипторами. Сюда входят такие связи, как синонимы, более широкие понятия, более узкие понятия и т.д. Структура отношения следующая: ERELDS(KDSC, KDS1, RODS).

Здесь KDSC - код первого дескриптора, KDS1 - код второго дескриптора, KODS - код связи между понятиями.

Имена поддерживаемых связей закодированы. Расшифровка кода связи приводится в тезаурусе ETSAUR.

КОНЦЕПЦИИ ИНТЕГРАЦИИ ЗНАНИЙ В ВИДЕ ПРАВИЛ

Качественные знания профессионала-эксперта о некотором мире трансформируются в процессе загрузки в БЗ. Процесс трансформации зависит от выбранного типа представления знаний в БЗ. Далее мы ограничиваемся только представлением знаний в виде систем продукций или в виде логических программ на Прологе. Выделим следующие этапы трансформации знаний:

Естественный язык (ЕЯ), включая искусственный (математические формулы).

Представление в пространстве ситуаций.

Язык исчисления предикатов.

Графовое представление в виде сети Петри с целью тестирования знаний. Конвертирование в

язык инструментальной среды (продукции или язык Пролог).

Представление знаний на ЕЯ - это структурированный текст выделенными из тезауруса системы прописными буквами (термами), и к которому должен иметь доступ когнитолог. Когкито-лог индексирует предложения из текста на ЕЯ, выделяя термины-дескрипторы, опираясь на содержимое тезауруса. В случае необходимости тезаурус пополняется. Для его использования в процессе формализации качественных знаний необходима поддержка тезаурусом метамодели описания знаний. В нем должен присутствовать дескриптор ЗНАНИЯ, играющий роль родового понятия самого высокого уровня. Видовыми понятиями по отношению к родовому являются ключевые слова, описывающие создаваемую ЕЗ. Например, если проектируется БЗ по статистической обработке, то видовым дескриптором для описания критерия согласия будет КРИТЕРИЙ СОГЛАСИЯ.

В свою очередь этот дескриптор является родовым по отношению к ключевым словам каждого предложения текста на ЕЯ, что может быть представлено следующей схемой.

ЦЕЛЬ род-вид МЕТОД

КРИТЕРИЙ СОГЛАСИЯ < * УСЛОВИЯ ПРИМЕНЕНИЯ

СТЕПЕНЬ ДОВЕРИЯ

Эти дескрипторы определяют некоторые типы объектов. Дополнительно в тезаурусе фиксируются значения объектов данного типа, например:

значение

КРИТЕРИЙ СОГЛАСИЯ* ^КРИТЕРИЙ КОЛМОГОРОВА

« ^КРИТЕРИЙ ХИ-КВАДРА Т

Все дескрипторы и связи между ними фиксируются в тезаурусе (отношения ETSAUR, ETSDOC, ERELDS, EDOMEN). Пример формирования тезауруса показан на рисунке 2. Формируется сцепленный дескриптор вида ЗНАНИЕ&КРИТЕРИЙ СОГЛАСИЯ&КРИТЕРИЙ КОЛМОГОРОВА (на уровне программ дескрипторы заменяются кодами из отношения ETSAUR), помещаемый в отношение ETSDOC для адресации страниц и строк в отношении EDOCUM.

Для трансформации представления знаний с ЕЯ в пространство ситуаций используется аппарат лингвистических переменных {ЛП) [5]. ЛП задается пятеркой {L, T, U, G, Л/}, где L - название ЛП; Т - множество терм-значений (выражений ЕЯ), принимающее ЛП; V - универсальное множество (шкала), с которым связаны значения ЛП; G - множество синтаксических правил, описывающих конструирование новых терм-значений из базовых; Ы - семантические правила, ставящие каждому терм-значению нечеткое подмножество шкалы U.

Описание конкретных лингвистических переменных и термов задается в тезаурусе. Значения элементов универсального множества и функции принадлежности загружаются в реляционную базу данных.

Схема нечетких рассуждений над множеством ЛП, описывающая пространство ситуаций, является основным представлением знаний, пригодным для загрузки в БЗ [1]. Ее можно представить в виде:

ЕСЛИ all, all, ..., alM ТО Ы CF cfl ИНАЧЕ ЕСЛИ а21, а22, ..., а2М ТО Ь2 СР с/2

ИНАЧЕ ЕСЛИ aNl, aN2, ..., aNM TO bN CF cfN,

где aij - значение j-ой ЛП в /-ой продукции; cfi - коэффициент доверия (степень уверенности), назначенный экспертом i-ой продукции.

Требованиям к представлению знаний присущи два противоречивых условия: независимость знаний друг от друга и согласованность как единого целого [8]. В продукции "ЕСЛИ ... ТО ..." представлению отдельных знаний присуща полная независимость, а свойство знаний как единого целого не затрагивается. Это создает возможность больших осложнений с позиций практической реализации баз знаний. Поэтому необходима трансформация к представлению знаний на языке исчисления предикатов.

С помощью логики предикатов можно выяснить, имеются или отсутствуют противоречия между новыми и уже существующими знаниями. Для большей наглядности процесса логического вывода над множеством формул исчисления предикатов в виде хорновских дизъюнктов, описывающих знания, можно использовать аппарат сетей Петри [7].

Сеть Петри задается пятеркой {Р, Т, I, О, М}, где Р - множество позиций сети (каждая позиция сети соответствует одному предикату); Т - множество переходов (каждый из которых соответствует формуле); / - множество входных инциденций (дуг) сети; О - множество выходных инциденций сети. Сеть для моделирования процесса вывода над множеством хорновских дизъюнктов "раскрашена". Особенностью этой сети является наличие специальных переходов-истоков, не имеющих входных дуг, они соответствуют фактам, и одного перехода-стока, не имеющего выходных дуг. Этот переход соответствует запросу. Процесс тестирования знаний сводится к решению проблемы достижимости состояния сети, обладающей некоторыми дополнительными свойствами,, такими как структурная ограниченность и безопасность.

Для решения проблемы достижимости могут быть использованы средства языка ПРОЛОГ, предоставляющие возможность сделать этот вывод не только детерминированным, но и стохастическим [4], что даст не один, а все возможные пути на сети, анализ которых поможет также в устранении избыточности знаний.

Конвертирование знаний из представления на языке исчисления предикатов в язык конкретной реализации системы программирования БЗ потребует, в основном, выполнения синтаксических ограничений и большей частью касается организации ввода-вывода и работы с базой данных.

ПРИКЛАДНЫЕ ПРОГРАММЫ

Проблема обмена прикладными программами между различными гибридами ЭС успешно решается благодаря стандартизации языков программирования. Основная трудность здесь появляется на стадии выполнения программы и сопряжена с выполнением рутинных операций ввода исходных данных и вывода результатов.

Рассмотрим возможный путь автоматизации процессов ввода-вывода при обмене прикладными программами между ЭС. Если обмен данными между прикладными программами и базами данных ЭС осуществляется на уровне файлов, то указанная задача сводится к автоматизированному формированию файлов обмена.

Формирование и чтение файлов обмена возможно, если известно, какие данные и в какой форме требуется предоставить или получить из прикладной программы. Это предполагает наличие общей информации о прикладной программе, включающей в себя описание программного модуля, название хранящей его библиотеки, языка, на котором написан данный модуль, описание его параметров, соглашение о связях, инструкции по его использованию и т.д. Такая информация должна содержаться в специальной базе данных о программных модулях ЭС. Поэтому при взаимодействии различных ЭС наряду с передачей программных модулей, должны передаваться и указанные сведения из базы данных, относящиеся к модулю. При этом также должен решаться вопрос о стандартизации форматов файлов {ASCII, DIF, DBF я пр.).

Входные данные для прикладных программ готовятся интерфейсными модулями подготовки данных, написанными с помощью языки" конкретной ЭС. Модуль подготовки данных взаимодействует с базой данных о программных модулях и базой данных, из которой выбирается информация для прикладной программы. Например, это может быть база экспериментальных данных в статистической ЭС.

Интерфейсный модуль подготовки данных помещает входные данные прикладных программ в файл со стандартным именем, например SYSIN.DAT. Прикладная программа в свою очередь создает стандартный файл, например SYSOUT.DAT с результатами обработки, содержимое которого затем переносится с помощью интерфейсных модулей записи результатов в базу данных ЭС. Для статистической ЭС это может быть база математических моделей. При этом модуль записи результатов также взаимодействует с базой данных о программных модулях-

Интерфейсные модули реализуются средствами выбранной инструментальной среды и конкретная их реализация существенно зависит от командного языка используемой оболочки [3].

Для каждой из прикладных программ готовится соответствующее описание в виде текстового файла. Оно загружается в отношение EDOCUM и используется для получения справочной информации.

Рассмотрим упрощенно основные отношения базы данных о программных модулях, которые можно использовать при формировании файлов обмена.

Отношение EMODUL(IMMD, KOLP, NAZV, NPAG, NLNB, NLNE) задает общее описание программного модуля и содержит следующие атрибуты: IMMD - имя модуля, KOLP - количество параметров модуля, NAZV- краткое название модуля на естественном языке, NPAG,NLNB,NLNE - ссылка на полное описание модуля в отношении EDOCUM.

Отношение EPARAM(IMMD, NOMP, TIPI, TIP2) задает описание параметров программного модуля. В него входят следующие дополнительные атрибуты: NOMP - номер параметра; TIPI — вид параметра (входной параметр, выходной параметр, рабочий параметр); TIP2 - задает тип параметра (скалярный, массив, структура и пр.).

Отношение ESKALR(IMMD, NOMP, TIPS, NPAG, NLNB, NLNE) служит для подробного описания скалярных параметров модуля. Атрибут Т1РЗ, входящий в него, задает форму представления элементов параметра (строка символов, двоичное число с фиксированной точкой, двоичное число с плавающей точкой, адресная константа и пр.).

Отношение EMASSV(IMMD, NOMP, RAZM, TlPi, SPXR, NPAG, NLNB, NLNE) задает описание параметров модуля типа массивов. В него дополнительно входят атрибут RAZM, необходимый для описания размерности массива, и атрибут SPXR, задающий способ упаковки массива.

Аналогичным образом описываются другие типы параметров, например структуры, подпрограммы и т.д.

В соответствии с приведенным описанием базы данных о программных модулях создание вводного файла может выполняться следующим образом. Анализируется отношение EMODUL, и для заданного кода модуля устанавливается количество параметров модуля. Затем для каждого входного параметра модуля с помощью отношения EPARAM устанавливается тип параметра и запускается процедура, помещающая во вводной файл значение параметра соответствующего типа. Указанный процесс повторяется до тех пор, пока не будут обработаны все входные параметры.

Загрузка результатов выполнения прикладных программ в Базу данных может выполняться по аналогичной схеме. Анализируется отношение EMODUL, и для заданного кода модуля устанавливается количество параметров модуля. Для каждого выходного параметра модуля с помощью отношения EPARAM устанавливается тип параметра и запускается процедура, помещающая значение параметра соответствующего типа в некоторое отношение базы данных. Процесс повторяется до окончания обработки всех выходных параметров.

ДИАЛОГИ С ПОЛЬЗОВАТЕЛЕМ

Существенным разделом базы знаний является описание диалогов с пользователем. Такие диалоги также могут быть выделены в отдельную форму представления знаний. Для формирования

диалогов необходимо иметь средства для написания их сценария. Такой сценарий должен содержать средства описания ввода информации (координаты экрана, форматы и шаблоны полей и т.д.), средства описания вывода информации (окна, меню, поля для текстовой информации, заставки и т.п.), средства взаимодействия с базой данных и некоторый набор логических операций для сравнения вводимых данных.

Сценарий диалога для передачи из одной системы в другую также должен быть описан вначале на естественном языке в виде текста, а затем представлен в специальном виде для дальнейшей интерпретации экспертной системой. Одной из форм представления сценариев диалога может быть описание его в виде, пригодном для загрузки в реляционную базу данных.

Список литературы

Аверкин А.Н., Батыршнн ИЗ,, Елншун А.Ф., Силон В.Б., Тарасов В.Б. Нечеткие множества в моделях управления и искусственного интеллекта. - М.: Наука, 1986. - 312 О.

Атре Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика, 1983. - 317 с.

Бондарев В.Н., Виленчик Д.В., Гольденберг СВ., Цуканов АД. Информационная технологи» построения математических моделей объектов // Электронное моделирование. - 1992. - N1. - С. 90-94.

Братко И. Программирование на языке Пролог для искусственного интеллекта. - М.: Мир, 1990. - 560 с.

Искусственный интеллект // В 3-х кн. - М.: Радио и связь, 1990. - Кн. 2. Модели я методы. - 340 с.

Леонг-Хонг Б,, Плагман Б. Системы словарей-справочников данных. - М.: Финансы и статистика, 1986. - 311 с.

Мурата Т. Сети Петри: свойства, анализ, приложения. - ТИИЭР, 1989. - Т. 77. - N4. - С. 41-82.

Представление и использование знаний / Под ред. X. Уэно, М. Исидзука. - М.: Мнр, 1989. - 220 с.

Цуканов А.В. Экспертные системы экспериментального моделирования в энергетике. - Киев; Знание, 1989. - 20 с.