Базы знаний интеллектуальных


Классификация по связи с реальным временем



страница5/13
Дата22.05.2016
Размер3.92 Mb.
ТипРеферат
1   2   3   4   5   6   7   8   9   ...   13

2.2.2. Классификация по связи с реальным
временем

Статические ЭС разрабатываются в предметных областях, в которых база зна-


«ий и интерпретируемые данные не меняются во времени. Они стабильны.

Пример


Диагностика неисправностей в автомобиле.

Квазидинамические ЭС интерпретируют ситуацию, которая меняется с некото-


рым фиксированным интервалом времени.

Пример


Микробиологические ЭС, в которых снимаются лабораторные измерения с технологи-
ческого процесса один раз в 4-5 часов (производство лизина, например) и анализиру-
ется динамика полученных показателей по отношению к предыдущему измерению.

Динамические ЭС работают в сопряжении с датчиками объектов в режиме ре-


ального времени с непрерывной интерпретацией поступающих в систему дан-
ных.

Примеры


Управление гибкими производственными комплексами, мониторинг в реанимацион-
ных палатах;

программный инструментарий для разработки динамических систем — G2 [Попов,


1996].

2.2.3. Классификация по типу ЭВМ

На сегодняшний день существуют:



  • ЭС для уникальных стратегически важных задач на суперЭВМ (Эльбрус,
    CRAY, CONVEX и др.);

  • ЭС на ЭВМ средней производительности (типа ЕС ЭВМ, mainframe);



  • ЭС на символьных процессорах и рабочих станциях (SUN, Silicon Graphics,
    APOLLO);

  • ЭС на мини- и супермин-ЭВМ (VAX, micro-VAX и др.);

  • ЭС на персональных компьютерах (IBM PC, MAC II и т. п.).

2.2.4. Классификация по степени интеграции
с другими программами


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

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

Несмотря на внешнюю привлекательность гибридного подхода, следует отме-


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

2.3. Коллектив разработчиков

Под коллективом разработчиков (КР) будем понимать группу специалистов, от-


ветственных за создание ЭС.

Как видно из рис. 2.1, в состав КР входят по крайней мере три человека — пользо-


ватель, эксперт и инженер по знаниям. На рисунке не видно программиста. Та-
ким образом, минимальный состав КР включает четыре человека; реально же он
разрастается до 8-10 человек. Численное увеличение коллектива разработчиков
происходит по следующим причинам: необходимость учета мнения нескольких
пользователей, помощи нескольких экспертов; потребность как в проблемных,
так и системных программистах. На Западе в этот коллектив дополнительно тра-
диционно включают менеджера и одного технического помощника.
Если использовать аналогии из близких областей, то КР более всего схож с
группой администратора базы данных при построении интегрированных ин-
формационных систем или бригадой программистов, разрабатывающих слож-
ный программный комплекс. При отсутствии профессионального менеджера
руководителем КР, участвующим во всех стадиях разработки, является инженер
по знаниям, поэтому к его квалификации предъявляются самые высокие требо-
вания. В целом уровень и численность группы зависят от характеристик постав-
ленной задачи.

Для обеспечения эффективности сотрудничества любой творческой группы, в


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

В настоящий момент в психологии существует несколько десятков методик по


определению свойств личности, широко используемых в вопросах профессио-
нальной ориентации. Эти психодиагностические методики, часть из которых уже
автоматизирована, различаются направленностью, глубиной, временем опроса и
способами интерпретации. В частности, система АВАНТЕСТ (Автоматический
Анализ ТЕСТов) [Гаврилова, 1984] позволяет моделировать рассуждения психо-
лога при анализе результатов тестирования по 16-факторному опроснику Р. Кэт-
тела и выдает связное психологическое заключение на естественном русском язы-
ке, характеризующее такие свойства личности, как общительность, аналитичность,
добросовестность, самоконтроль и т. п. Модифицированная база знаний системы
АВТАНТЕСТ позднее была использована в ЭС «Cattell» (см. параграф 7.3).

Ниже приведены два аспекта характеристик членов КР: 1 — психофизиологиче-


ский, 2 — профессиональный.

Пользователь

1. К пользователю предъявляются самые слабые требования, поскольку его не


выбирают. Он является в некотором роде заказчиком системы. Желательные
качества:

а) дружелюбие;

б) умение объяснить, что же он хочет от системы;

в) отсутствие психологического барьера к применению вычислительной тех-


ники;

г) интерес к новому. От пользователя зависит, будет ли применяться разра-


ботанная ЭС. Замечено, что наиболее ярко качества в) и г) проявляются в
молодом возрасте, поэтому иногда такие пользователи охотнее применяют
ЭС, не испытывая при этом комплекса неполноценности оттого, что ЭВМ
им что-то подсказывает.

2. Необходимо, чтобы пользователь имел некоторый базовый уровень квалифи-


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

Эксперт

1. Эксперт — чрезвычайно важная фигура в группе КР. В конечном счете, его под-


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

а) доброжелательность;

б) готовность поделиться своим опытом;
в) умение объяснить (педагогические навыки);

г) заинтересованность (моральная, а лучше еще и материальная) в успешнос-


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

2. Помимо безусловно высокого профессионализма в выбранной предметной об-


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

Программист

1. Известно, что программисты обладают самой низкой потребностью в общении


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

а) общительность;

б) способность отказаться от традиционных навыков и освоить новые методы;

в) интерес к разработке.

2. Поскольку современные ЭС — сложнейшие и дорогостоящие программные ком-

плексы, программисты в КР должны иметь опыт и навыки разработки про-


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

Инженер по знаниям

1. Существуют такие профессии и виды деятельности, для которых природные


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

Интеллект. Это понятие вызывает самые бурные споры психологов; суще-
ствует до 50 определений^интеллекта, но с прагматической точки зрения оче-
видно, что специалист (в области искусственного интеллекта должен стре-
миться к максимальным4 оценкам по тестам как вербального, так и невербаль-
ного интеллекта.

Стиль общения. Инженер по знаниям «задает тон» в общении с экспертом, он
ведет диалог, и от него в конечном счете зависит его продуктивность. Можно
выделить два стиля общения: деловой (или жесткий) и дружеский (или мяг-
кий, деликатный). Нам кажется, что дружеский будет заведомо более успеш-
ным, так как снижает «эффект фасада» у эксперта, раскрепощает его. Дели-
катность, внимательность, интеллигентность, ненавязчивость, скромность,
умение слушать и задавать вопросы, хорошая коммуникабельность и в то же
время уверенность в себе — вот рекомендуемый стиль общения. Безусловно,
что это дар и искусство одновременно, однако занятия по психологическому
тренингу могут дать полезные навыки.

Портрет инженера по знаниям можно было бы дополнить другими характери-


стиками — широтой взглядов и интересов, артистичностью, чувством юмора,
обаянием и т. д.

2. При определении профессиональных требований к аналитику следует учиты-


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

Инженер по знаниям имеет дело со всеми формами знаний (см. параграф 1.3).

Z1 (знания в памяти) —> Z2 (знания в книгах) —> Z3 (поле знаний) —> Z4 (модель
знаний) -» Z5 (база знаний).

Работа на уровне Z1 требует от инженера по знаниям знакомства с элементами


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

Изучение и анализ текстов на уровне Z2 подразумевает широкую общенаучную


подготовку инженера; знакомство с методами реферирования и аннотирования
текстов; владение навыками быстрого чтения, а также текстологическими мето-
дами извлечения знаний.

Разработка поля знаний на уровне Z3 требует квалифицированного знакомства с


методологией представления знаний, системным анализом, теорией познания,
аппаратом многомерного шкалирования, кластерным и факторным анализом.
Разработка формализованного описания Z4 предусматривает предварительное
изучение аппарата математической логики и современных языков представле-
ния знаний. Модель знаний разрабатывается на основании результатов глубоко-
го анализа инструментальных средств разработки ЭС и имеющихся «оболочек».
Кроме того, инженеру по знаниям необходимо владеть методологией разработки
ЭС, включая методы быстрого прототипирования.
И наконец, реализация базы знаний Z5, в которой инженер по знаниям участвует
вместе с программистом, подразумевает овладение практическими навыками ра-
боты на ЭВМ и, возможно, одним из языков программирования.
Так как инженеров по знаниям «выращивают» из программистов, уровень Z5
обычно не вызывает затруднения, особенно если разработка ведется на традици-
онных языках типа С или Паскаль. Специализированные языки искусственного
интеллекта Лисп и Пролог требуют некоторой перестройки архаично-алгорит-
мического мышления.

Успешность выбора и подготовки коллектива разработчиков ЭС определяет эф-


фективность и продолжительность всего процесса разработки.

2.4. Технология проектирования
и разработки


2.4.1. Проблемы разработки промышленных ЭС

Р




Рис. 2.3. Этапы разработки ЭС

азработка программных комплексов экспертных систем как за рубежом, так и в
нашей стране находится на уровне скорее искусства, чем науки. Это связано с тем,
что долгое время системы искусственного интеллекта внедрялись в основном во
время фазы проектирования, а чаще всего разрабатывалось несколько прототип-
ных версий программ, и на их основе уже создавался конечный продукт. Такой
подход действует хорошо в исследовательских условиях, однако в коммерческих
условиях он является слишком дорогим, чтобы оправдать затраты на разработку.
Процесс разработки промышленной экспертной системы, опираясь на тради-
ционные технологии [Николов и др., 1990; Хейес-Рот и др., 1987; Tuthill, 1994],
практически для любой предметной области можно разделить на шесть более или
менее независимых этапов (рис. 2.3).

Последовательность этапов дана только с целью получения общего представле-


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

В целом за разработку экспертных систем целесообразно браться организации,


г/ц1 накоплен опыт по автоматизации рутинных процедур обработки информа-
ции, таких как:

  • формирование корпоративных информационных систем;

  • организация сложных расчетов;

  • работа с компьютерной графикой;

  • обработка текстов и автоматизированный документооборот.

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

2.4.2. Выбор подходящей проблемы

Этот этап определяет деятельность, предшествующую решению начать разраба-


тывать конкретную ЭС. Он включает [Николов и др., 1990]:

  • нахождение эксперта, желающего сотрудничать при решении проблемы, и на-
    значение коллектива разработчиков;

  • определение предварительного подхода к решению проблемы;

  • анализ расходов и прибылей от разработки;

  • подготовку подробного плана разработки.

Лраппльный выбор проблемы представляет самую критическую часть разработ-
ки в целом. Если выбрать неподходящую проблему, можно очень быстро увяз-
нуть в «болоте» проектирования задач, которые никто не знает, как решать. Не-
подходящая проблема может также привести к созданию экспертной системы,
которая стоит намного больше, чем экономит. Дело будет обстоять еще хуже,
если разработать систему, которая работает, но неприемлема для пользователей.
Даже если разработка выполняется самой организацией для собственных целей,
эта фаза является подходящим моментом для получения рекомендаций извне,
чтобы гарантировать удачно выбранный и осуществимый с технической точки
зрения первоначальный проект.

При выборе области применения следует учитывать, что если знание, необходи-


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

Обычно экспертные системы разрабатываются путем получения специфически)!


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

В процессе разработки и последующего расширения системы инженер по знани-


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

Во время первоначальных бесед они должны решить, будет ли их сотрудничестве


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

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


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

После того как задача определена, необходимо подсчитать расходы и прибыль о'


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

Прибыль может быть получена за счет снижения цены продукции, повышение


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

Можно ожидать развития тенденции разработки менее дорогостоящих систем


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

  • данная задача может быть решена с помощью экспертной системы;

  • экспертную систему можно создать предлагаемыми на рынке средствами;

• имеется подходящий эксперт;

» предложенные критерии производительности являются разумными;

> затраты и срок их окупаемости приемлемы для заказчика,

эн составляет план разработки. План определяет шаги процесса разработки и не-

эбходимые затраты, а также ожидаемые результаты.

2.4.3. Технология быстрого прототипирования

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

Объем прототипа — несколько десятков правил, фреймов или примеров. На


рис. 2.4 изображено шесть стадий разработки прототипа и минимальный коллек-
тив разработчиков, занятых на каждой из стадий (пять стадий заимствовано из
работы [Хейес-Рот и др., 1987]). Приведем краткую характеристику каждой из
стадий, хотя эта схема представляет собой грубое приближение к сложному, ите-
ративному процессу.




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

Сроки приведены условно, так как зависят от квалификации специалистов и осо-


бенностей задачи.

Идентификация проблемы

Уточняется задача, планируется ход разработки прототипа экспертной системы,


определяются:

  • необходимые ресурсы (время, люди, ЭВМ и т. д.);

  • источники знаний (книги, дополнительные эксперты, методики);

  • имеющиеся аналогичные экспертные системы;

  • цели (распространение опыта, автоматизация рутинных действий и др.);

  • классы решаемых задач и т. д.



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

Средняя продолжительность 1 -2 недели.

Извлечение знаний

На этой стадии происходит перенос компетентности от эксперта к инженеру по


знаниям, с использованием различных методов (см. главу 4):

  • анализ текстов;

  • диалоги;

  • экспертные игры;

  • лекции;

  • дискуссии;

  • интервью;

  • наблюдение и другие.



Извлечение знаний — получение инженером по знаниям наиболее полного из возможных
представлений о предметной области и способах принятия решения в ней.

Средняя продолжительность 1-3 месяца.



Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   13


База данных защищена авторским правом ©dogmon.org 2019
обратиться к администрации

    Главная страница