Анализ интеллектуальных систем с позиции организации интерфейсной компоненты

Рассмотрим класс интеллектуальных систем, ориентированных на знания. Такого рода системы отличаются тем, что в них упор делается не на данные в их классическом фактуальном представлении, а на знания — т.е. метаданные о характере и связях объектов и явлений какой-либо предметной области. Отметим, что указанное разделение не представляет собой абсолютный критерий классификации, это скорее качественный показатель. Каждая конкретная реализация достаточно мощной ИС содержит как признаки первого, так и второго рода. Однако описанное деление является весьма значимым при проектировании систем вследствие того, что оказывает определяющее воздействие на выбор метода реализации отдельных компонентов — от способа организации данных/знаний до реализации подсистемы пользовательского интерфейса.

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

В течение последних двадцати лет в литературе господствует мнение о том, что оптимальным способом взаимодействия пользователя с интеллектуальными системами является естественный язык, а ограничения, накладываемые на язык взаимодействия человека и компьютерных систем в некоторых реализациях подобного подхода (например, ОЕЯ), воспринимаются как вынужденная мера. Регламентированные языки (языки меню, запросов, форм и шаблонов) трактуются как еще более узкие и изначально ограниченные средства общения. При этом подразумевается, что в любой ситуации общения пользователя с системой ЕЯ обладает преимуществами на том основании, что он является наиболее привычным средством общения для человека. Принимая во внимание, что, по данным психологов, человек до 90% информации принимает по зрительному каналу, отметим, что ЕЯ как средство общения органичен в области коммуникации человека с человеком, а происхождение тезиса о том, что с помощью этого средства можно достичь и наибольшей эффективности при взаимодействии человека с компьютерными системами, явственно просматривается в стане апологетов искусственного интеллекта.

Два способа организации взаимодействия ЭС с пользователем отражают два подхода к разрабатываемым системам. Первый — подход от баз данных, когда основу системы составляет фактуальная информация, организованная и структурированная классическими методами СУБД, а “знаниями” нагружается ИПС, обеспечивающая доступ к БД. Второй — когда основное содержание системы составляют заложенные в нее концептуальные знания, а не чисто информационный набор фактов. На наш взгляд, только в первом случае уместно говорить о естественном языке как о наиболее приемлемом способе общения с системой, поскольку к системе (как к информационно-поисковой) предъявляется требование обработки запросов достаточно большой степени сложности (по совокупности нескольких параметров, с использованием условных конструкций и т.д.), кроме того, как правило, пользователи такого рода систем не обладают достаточным уровнем профессиональной подготовки. К системам другого рода, пользователями которых являются подготовленные специалисты (очевидно не только в своей предметной области, но также имеющие развитые навыки общения с компьютерными информационными системами), предъявляются несколько иные требования. В рассматриваемом классе ориентированных на знания систем (это в большинстве своем ЭС диагностики, анализа ситуации, поддержки принятия решения, мониторинга) на первый план выдвигается удобство и скорость обмена информацией участниками общения. Достаточный объем умолчаний, заранее определенная задача, которая известна участникам до начала процесса коммуникации, делают естественный язык преградой на пути повышения эффективности общения. В данном случае целесообразно использование регламентированных языков, использующих умолчания и соглашения, оперирующих специализированными понятиями, очевидными участникам общения в контексте решаемой ими задачи.

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

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

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

Так, к области экспертных систем с определенной степенью приближения можно отнести системы:

• диагностики,
• анализа ситуации,
• поддержки принятия решения,
• мониторинга.

Требования к системам

Требования к системам представления знаний (в том числе к интерфейсу взаимодействия человека с системой):

1. Для систематизированного управления сложными знаниями большого объема желательно организовывать все знания на основе концептуальных объектов.
2. В целях увеличения гибкости системы следует сделать возможным представление в виде комбинации декларативных и процедурных знаний для описания связанных с ними концептуальных объектов.
3. Поскольку концепт обычно имеет иерархическую структуру, связанную с некоторой степенью абстракции, то и для представления знаний следует применять иерархическую структуру.
4. При решении сложных проблем считается, что различные состояния вывода применяются в комбинациях в соответствии с ситуацией. Поэтому и в представлении знаний необходимы функции, учитывающие это обстоятельство.
5. Создание сложных систем, основанных на знаниях, есть во многом эмпирический процесс. Это выражается в том, что удельный вес процессов отладки и доведения системы до нужного уровня достоверности выводов превышает затраты на описание и ввод модели (по крайней мере в той их части, которая протекает во взаимодействии со средой разработки). Отладка моделей сложных моделей есть путь проб и ошибок, поэтому способ организации знаний должен предоставлять возможность свободного проектирования, заключающегося в применении и испытании различных способов управления выводом на едином пространстве понятий и решений предметной области.
6. Дальнейшим развитием принципа свободного проектирования служит возможность дополнения системы различными функциями.

Требования к средствам проектирования интерфейса взаимодействия человека с выделенным классом интеллектуальных систем:

1. Возможность генерации кадров диалога, включающих разнотипные интерфейсные элементы.
2. Реализация запросов на ввод текстовой информации.
3. Реализация меню-ориентированных запросов текстового и графического типов.
4. Наличие средств поддержки создания динамических сценариев отображения графической и вывода звуковой информации с возможностью взаимной синхронизации.
5. Наличие удобных средств компоновки и редактирования кадров диалога.
6. Наличие системы архивирования и навигации в среде хранилища интерфейсных объектов (кадров диалога).

Структура базы знаний

Процесс создания ЭС заключается в описании структуры понятий ПО, выборе модели для представления знаний и формализации знаний с помощью выбранных средств описания (т.е. наполнения БЗ). На выбор типа модели наиболее значимое воздействие оказывают по крайней мере 2 фактора:

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

Опыт создания ЭС в разных ПО показывает, что часто оказывается целесообразным построение ЭС разных типов в одной ПО. Иными словами, перед разработчиками ЭС встает задача создания разнотипных моделей знаний на едином пространстве понятий и фактов.

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

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

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

В процессе реализации ЭС в режиме консультации выбор типа модели определяет, какой именно решатель из логической компоненты должен быть активизирован. Совокупность загруженной модели и конкретного решателя образуют процесс. Каждый процесс имеет доступ к данным только своей модели (это данные процесса), а также полный доступ к общей части БЗ.

Обоснование выбора фреймовой модели

Фреймовая модель представляет собой систематизированную в виде единой теории психологическую модель памяти человека и его сознания.

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

Математическая постановка задачи проектирования интерфейсной модели

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

Можно выделить по крайней мере два способа выделения подмножества объектов для организации кадра диалога:

1. Описание некоторого явления (события или ситуации в узком смысле этого слова), когда необходимо означить некоторую совокупность признаков объектов, объединенных временными или пространственными рамками.
2. Определение комплексного объекта, когда необходимо для означивания предъявить составляющие его объекты или показатели.

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

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

Обозначим множество объектов, используемых для получения информации о ситуации, через X, а объекты, означиваемые в процессе анализа ситуации, — через F.

Процесс взаимодействия пользователя с интеллектуальной системой носит дискретный характер. Каждый этап взаимодействия описывается структурой данных, которыми обмениваются система и пользователь. Определим эту структуру как кадр диалога K:

K_i = { x, f, s }, где

x (X,
f (F,
s (S, где S — множество шаблонов, описывающих структуру кадров диалога.

Система поддержки диалога D может быть представлена парой:

D = { h, v }, где

h (H — процедуры организации ввода значений параметров объектов,
v (V — процедуры поддержки вывода фактуальной информации.

Вывод фактуальной информации может быть реализован различными способами:

M = { V_t, V_i, V_a }, где

V_t — вывод текстовых сообщений. Необходимо отметить, что эту возможность можно реализовать несколькими способами, в зависимости от важности выводимой информации. Различные по содержанию текстовые сообщения в простейшем случае могут являться параметром для типового шаблона, при этом качество восприятия будет ниже, чем у специально созданных для данного вида сообщения шаблонов с использованием выделения различными шрифтами и цветом;
V_i — выбор изображения, заданного в качестве параметра или описанного в шаблоне;
V_a — выбор звукового сообщения.

В свою очередь процедура означивания признака может быть организована несколькими различными способами:

N = { H_m, H_l, H_i, H_t, H_n, H_d, H_b, H_s }, где

H_m — выбор значений из текстового меню, представляющего собой статический (т.е. определенный в шаблоне s) список текстовых альтернатив;
H_l — выбор атрибута из динамически формируемого списка значений;
H_i — ввод параметров путем указания на условном или схематическом изображении, хранимом в шаблоне s, состояния определенных фрагментов;
H_t — ввод произвольной текстовой строки;
H_n — ввод числового значения из заданного диапазона с клавиатуры;
H_d — означивание параметра путем опроса датчиков;
H_b — считывание значения параметра из базы данных;
H_s — получение значения посредством вызова внешней процедуры.

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

Рис. 1. Структурная схема математической модели интерфейса

Рассмотрим одну из возможных постановок задачи оптимизации на базе следующих функционалов. Введем показатели, оценивающие процесс означивания произвольного параметра x посредством процедуры h.

Быстрота восприятия кадра k есть функционал:

P = FUNC (s, n, b, m), где

n (N,
m (M, поскольку скорость восприятия информации может быть значительно повышена за счет задействования ассоциативных связей у человека путем правильного подбора фоновых объектов и элементов оформления при выводе определенного кадра. Определяющее воздействие в некоторых случаях может оказать правильно подобранное звуковое сопровождение кадра (например, в случае внештатной ситуации).

Скорость ввода G есть функционал:

G = FUNC (n, b).

Аналогично определяются показатели:

достоверности восприятия E=FUNC(s,n,b,m) и достоверности ввода Q=FUNC(n,b), (не вызывает сомнений, например, что при выборе из меню число ошибок будет меньшим по сравнению со способом ввода значения с клавиатуры).

При такой постановке оптимальной можно считать систему, построенную на наборе интерфейсных объектов, интегрированных в кадровую среду, обеспечивающую максимум функции:

, где .

Представление знаний в интегрированной оболочке
Image Expert