ГРАФІЧНИЙ РЕДАКТОР Corel draw 12

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

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

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

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

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

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

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

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

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

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

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

Под коллективом разработчиков (КР) будем понимать группу специалистов, от­ветственных за создание ЭС.

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

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

- потребность как в проблемных, так и системных программистах.

На Западе в этот коллектив дополнительно тра­диционно включают менеджера и одного технического помощника.

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

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

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

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

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

Эксперт.

Под­готовка и квалификация эксперта определяет уровень компетенции базы знаний. Желательны доброжелательность; готовность поделиться своим опытом; педагогические навыки; заинтересованность (моральная, а лучше материальная). Количество экспертов – открытый вопрос для каждой ПО.

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

Программист.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот этап определяет деятельность, предшествующую решению начать разраба­тывать конкретную ЭС. Он включает:

• определение проблемной области и задачи;

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

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

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

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

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

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

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

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

После того как инженер по знаниям убедился, что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• диалоги;

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

• лекции;

• дискуссии;

• интервью;

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

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

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

Структурирование или концептуализация знаний

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

• терминология;

• список основных понятий и их атрибутов;

• отношения между понятиями;

• структура входной и выходной информации;

• стратегия принятия решений;

• ограничения стратегий и т. д.

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

Такое описание называется полем знаний. Средняя продолжительность этапа 2-4 недели. Подробно стадия структурирования будет рассмотрена далее.

Формализация

Строится формализованное представление концепций предметной области на основе выбранного языка представления знаний (ЯПЗ). Традиционно на этом этапе используются:

• логические методы (исчисления предикатов 1-го порядка и др.);

• продукционные модели (с прямым и обратным выводом);

• семантические сети;

• фреймы;

• объектно-ориентиров. языки, основанные на иерархии классов и объек­тов.

Формализация знаний — разработка базы знаний на языке представления знаний, ко­торый, с одной стороны, соответствует структуре поля знаний, а с другой — позволяет реализовать прототип системы на следующей стадии программной реализации.

Все чаще на этой стадии используется симбиоз языков представления знаний, например, в системе ОМЕГА — фреймы + семанти­ческие сети + полный набор возможностей языка исчисления предикатов.

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

Реализация

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

• программирование на традиционных языках типа Pascal, C++ и др.;

• программирование на специализированных языках, применяемых в задачах искусственного интеллекта: LISP, FRL, SMALLTALK и др.;

• использование инструментальных средств разработки ЭС типа СПЭИС, ПИЭС, G2;

использование «пустых» ЭС или «оболочек» типа ЭКСПЕРТ , ФИАКР и др.

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

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

Тестирование

Оценивается и проверяется работа программ прототипа с целью приведения в соответствие с реальными запросами пользователей. Прототип проверяется на:

• удобство и адекватность интерфейсов ввода/вывода (характер вопросов в ди­алоге, связность выводимого текста результата и др.);

• эффективность стратегии управления (порядок перебора, использование не­четкого вывода и др.);

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

• корректность базы знаний (полнота и непротиворечивость правил).

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

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

12. Финальные этапы создания экспертной системы

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

Если первоначально выбранные объекты или свойства оказываются неподходя­щими, их необходимо изменить. Можно сделать оценку общего числа эвристи­ческих правил, необходимых для создания окончательного варианта экспертной системы. Иногда при разработке промышленной и/или коммерческой системы выделяют дополнительные этапы для перехода (табл. 2.1).

демонстрационный прототип —> действующий прототип —> промышленная система —> коммерческая система

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

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

Таблица 2. Переход от прототипа к промышленной экспертной системе

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

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

• критерии пользователей (понятность и «прозрачность» работы системы, удоб­ство интерфейсов и др.);

• критерии приглашенных экспертов (оценка советов-решений, предлагаемых системой, сравнение ее с собственными решениями, оценка подсистемы объяс­нений и др.);

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

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

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

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

Пример 12.1

Успешно состыкована со своим окружением система PUFF — экспертная система для диагностики заболеваний легких. После того как PUFF была закончена и все были удовлетворены ее работой, систему перекодировали с LISP на Бейсик. Затем систему перенесли на ПЭВМ, которая уже работала в больнице. В свою очередь, эта ПЭВМ была связана с измерительными приборами. Данные с измеритель­ных приборов сразу поступают в ПЭВМ. PUFF обрабатывает эти данные и печатает рекомендации для врача. Врач в принципе не взаимодействует с PUFF. Система пол­ностью интегрирована со своим окружением — она представляет собой интеллектуаль­ное расширение аппарата исследования легких, который врачи давно используют.

Пример 12.2

Другой системой, которая хорошо функционируете своем окружении, является САТ-1 — экспертная система для диагностики Неисправностей дизелей ло­комотивов.

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

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

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

Пример 12.3

Удачным примером ЭС, внедренной таким образом, является XCON (R1) — ЭС, кото­рую фирма DEC использует для комплектации ЭВМ семейства VAX. Одной из клю­чевых проблем, с которой столкнулась фирма DEC, является необходимость постоян­ного внесения изменений для новых версий оборудования, новых спецификаций и т. д. Дли этой цели XCON поддерживается в программной среде OPS5.

13. Поле знаний

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

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

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

О языке описания поля знаний

Поле знаний формируется на третьей стадии разработки ЭС — ста­дии структурирования.

Поле знаний, как первый шаг к формализации, представляет модель знаний о предметной области, в том виде, в каком ее сумел выразить аналитик на некотором «своем» языке. Что это за язык? Известно, что словарь языка конкретной на­уки формируется путем пополнения общеупотребительного языка специальны­ми терминами и знаками, которые либо заимствуются из повседневного языка, либо изобретаются. Назовем этот язык L и рассмотрим его же­лаемые свойства, учитывая, что стандарта этого языка пока не существует, а каж­дый инженер по знаниям вынужден сам его изобретать.

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

Во-вторых, желательно не использовать в нем терминов иных наук в другом, то есть новом, смысле. Это вызывает недоразумения.

В-третьих, язык L, видимо, будет либо символьным языком, либо языком графи­ческим (схемы, рисунки, пиктограммы). При выборе языка описания поля знаний не следует забывать, что на стадии формализации необходимо его заменить на машинно-реализуемый язык пред­ставления знаний (ЯПЗ), выбор которого зависит от структуры поля знаний.

В некотором смысле создание языка L очень близко к идеям разработки универ­сальных языков науки. К XVII веку сложились два подхода в разработке универсальных языков: создание языков-классификаций и логико-конструктивных языков. К первому примыкают проекты, восходящие к идее Ф. Бэкона, — это языки Вилкинса и Далгарно. Второй подход связан с исследо­ваниями в рамках поиска универсального метода познания, наиболее четко выс­казанного Р. Декартом, а затем в проекте универсальной характеристики Г. Лейб­ница. Именно Лейбниц наметил основные контуры учения о символах, которые в соответствии с его замыслами в XVIII веке развивал Г. Ламберт, который дал имя науке «семиотика». Семиотика в основном нашла своих адептов в сфере гу­манитарных наук.

14. Стратегии получения знаний

При формировании поля знаний ключевым вопросом является сам процесс по­лучения знаний, когда происходит перенос компетентности экспертов на инже­неров по знаниям. Для названия этого процесса в литературе по ЭС получило распространение несколько терминов: приобретение, добыча, извлечение, полу­чение, выявление, формирование знаний. В англоязычной специальной литера­туре в основном используются два: acquisition (приобретение) и elicitation (вы­явление, извлечение, установление).

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

Извлечение знаний (knowledge elicitation) — это процедура взаимодействия эксперта с источником знаний, в результате которой становятся явными процесс рассуждений спе­циалистов при принятии решения и структура их представлений о предметной области.

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

• организационные неувязки;

• неудачный метод извлечения, не совпадающий со структурой знаний в данной области;

• неадекватная модель (язык) для представления знаний;

• неумение наладить контакт с экспертом;

• терминологический разнобой;

• отсутствие целостной системы знаний в результате извлечения только «фраг­ментов»;

• упрощение «картины мира» эксперта и др.

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

Во-первых, большая часть знаний эксперта — это результат многочисленных на­слоений, ступеней опыта. И часто, зная, что из А следует В, эксперт не отдает себе отчета, что цепочка его рассуждений была гораздо длиннее, например А —> D —> С ->В или А -> Q-> R -> В.

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

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

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

Приобретение знаний (knowledge acquisition) — процесс наполнения базы знаний экспертом с использованием специализированных программных средств.

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

Формирование знаний (machine learning) — процесс анализа данных и выявление скрытых закономерностей с использованием специального математического аппарата и программных средств.

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

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

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

• обеспечить механизм сопряжения независимо созданных баз данных, имею­щих различные схемы, с базами знаний интеллектуальных систем;

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

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

Помимо перечисленных существуют также и другие стратегии получения знаний, например, в случае обучения на примерах (case-based reasoning), ког­да источник знаний — это множество примеров предметной области. Обучение на основе примеров (прецедентов) включает настройку алгоритма распознавания на задачу по­средством предъявления примеров, классификация которых известна.

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

1. С использованием ЭВМ при наличии подходящего программного инструмен­тария, иначе приобретение знаний.

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

Процессы извлечения и приобрете­ния знаний являются наиболее эффективными и перспективными на современном этапе разработки ЭС.

15. Теоретические аспекты структурирования знаний

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

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

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

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

Иерархический подход (тоже!!! )

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

В теории САПР такой подход называется блочно-иерархическим (БИП). Одно из преимуществ БИП состоит в том, что сложная задача большой размерности разбивается на последовательно решаемые группы задач малой размерности.

На каждом уровне вводятся свои представления о системе и элементах. Элемент го уровня является системой для уровня . Продвижение от уровня к уров­ню имеет строгую направленность, определяемую стратегией проектирования — сверху вниз или снизу вверх.

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

Нисходящая концепция (top-down) декларирует движение от , где — -й уровень иерархии понятий ПО (предметной области) с последующей детализа­цией понятий, принадлежащим соответствующим уровням.

Восходящая концепция (bottom-up) предписывает движение с последова­тельным обобщением понятий.

Основанием для прекращения накопления и разделения является пол­ное использование словаря терминов, которым пользуется эксперт, при этом чис­ло уровней является значимым фактором успешности структурирования.

Традиционные методологии структурирования

Существующие подходы к проектированию сложных систем можно разделить на два больших класса:

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

• Объектный подход, связанный с декомпозицией и выделением не процессов, а объектов, при этом каждый объект рассматривается как экземпляр определен­ного класса.

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

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

Объектный (объектно-ориентированный) подход (ООП), возникший как техно­логия программирования больших программных продуктов, основан на следую­щих основных элементарных понятиях:

- объекты, классы как объекты, связанные общностью структуры и свойств, и классификации как средства упо­рядочения знаний;

- иерархии с наследованием свойств; инкапсуляции как сред­ства ограничения доступа;

- методы и полиморфизм для определения функций и отношений.

ООП имеет свою систему условных обозначений и предлагает богатый набор логических и физических моделей для проектирования систем высокой степени сложности, при этом эти системы хорошо структурированы, что порождает лег­кость их модификации. Широкое распространение объектно-ориентированных языков программирова­ния VBA, C++, Delphi, Perl и др. успешно демонстрирует жизнеспособность и перспективность этого подхода.

16. Объектно-структурный анализ (ОСА)

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

Основные постулаты этого подхода заимствованы из ООП и расширены.

1. Системность (взаимосвязь между понятиями).

2. Абстрагирование (выявление существенных характеристик понятия, кото­рые отличают его от других).

3. Иерархия (ранжирование на упорядоченные системы абстракций).

4. Типизация (выделение классов понятий с частичным наследованием свойств в подклассах).

5. Модульность (разбиение задачи на подзадачи или «возможные миры»).

6. Наглядность и простота нотации.

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

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

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

Стратификация знаний

ОСА подразумевает дезагрегацию ПО, как правило, на восемь страт или слоев. Номера страт, соответствующие им вопросы и выполняемый на каждом слое вид анализа приведены в таблице 3.

Таблица 3. Стратификация знаний (основные страты)

Объектно-структурный анализ подразумевает разработку и использование мат­рицы ОСА (представлена в виде таблицы 4), которая позволяет всю собранную информацию разложить последовательно по слоям-стратам (вертикальный анализ), а затем по уровням — от уровня проблемы до уровня подзадачи (горизонтальный ана­лиз). Или наоборот — сначала по уровням, а потом по стратам.

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

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

, (1)

Таблица 4. Матрица объектно-структурного анализа

Уровни Страты	Уровень области	Уровень проблемы	Уровень задачи	Уровень подзадачи	...
Стратегический анализ
Организационный анализ
Концептуальный анализ
Функциональный анализ
Пространственный анализ
Временной анализ
Каузальный анализ
Экономический анализ
. . .

Алгоритм ОСА

Алгоритм ОСА (объектно-структурного анализа) предназначен для детального практического структурирования знаний ПО. В основе ОСА заложен алгоритм заполнения ОСА-матрицы . Алгоритм содержит последовательность аналити­ческих процедур, позволяющих упростить и оптимизировать процесс структури­рования. Алгоритм разделяется на две составляющие:

• А_1. Глобальный (вертикальный) анализ, включающий разбиение ПО на мето­дологические страты (что-знания, как-знания и т. д.) на уровне всей ПО. В ре­зультате заполняется первый столбец матрицы (табл. 4).

• А_2. Анализ страт (горизонтальный), включающий построение многоуров­невых структур по отдельным стратам. Число уровней определяется особен­ностями стратифицированных знаний ПО и может существенно отличаться для разных страт. С точки зрения методологии свидетельствует о слабой проработке ПО.

Первый уровень соответствует уровню всей ПО (уровень области). Второй — уровню проблемы, выделенной для решения. Третий — уровню конкретной ре­шаемой задачи. Дальнейшие уровни соответствуют подзадачам, если имеет смысл их выделять.

При этом возможно как последовательное применение восходящей (bottom-up) и нисходящей концепций (top-down), так и их одновременное применение.

Глобальный анализ

Технология глобального анализа сводится к разбиению пространства основной задачи структурирования ПО на подзадачи, соответствующие особенностям ПО. Для разработки интеллектуальных систем существует минимальный набор s-страт, обеспечивающий формирование БЗ. Минимальный набор включает три страты:

• — формирование концептуальной .структуры ;

• — формирование функциональной структуры ;

• — формирование подсистемы объяснений .

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

Алгоритм А_1 глобального анализа может быть кратко сформулирован следую­щим образом:

• А_1_1. Собрать все материалы по идентификации задачи и по результатам извлечения знаний.

• А_1_2. Выбрать набор страт N, подлежащих формированию (Nmin=3).

• А_1_3. Отобрать всю информацию по первой выбранной страте (i-1, где i — номер из выбранного набора страт N).

• А_1_4. Повторить шаг А_1_3 для i+1 для всех выбранных страт до i <= N.

• А_1_5. Если часть информации останется неиспользованной, увеличить чис­ло страт и повторить для новых страт шаг А_1_3; иначе перейти к последова­тельной реализации алгоритмов горизонтального анализа страт А_2.

Анализ страт

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

Ниже предлагается алгоритм ОСА для одной из обязательных страт (ЧТО-анализ), результатом которого является формирование концептуальной структуры предметной области .

• А_2_3_1. Из группы информации, соответствующей ЧТО-страте, выбрать все значимые понятия и сформулировать соответствующие концепты.

• А_2_3_2. Выявить имеющиеся иерархии и зафиксировать их графически в виде структуры.

• А_2_3_3. Детализировать концепты, пользуясь нисходящей концепцией (top-down).

• А_2_3_4. Образовать метапонятия по концепции (bottom-up).

• А_2_3_5. Исключить повторы, избыточность и синонимию.

• А_2_3_6. Обсудить понятия, не вошедшие в синтезированную структуру с экспертом и пере­нести их в другие страты или исключить.

• А_2_3_7. Полученный граф или набор графов разделить на уровни и обозна­чить — согласно матрице ОСА (табл. 4).

Аналогичные алгоритмы разработаны для всех страт и апробированы при разра­ботке экспертных систем ПРОГОР и АВЭКС.

ГРАФІЧНИЙ РЕДАКТОР Corel draw 12

Формування геометричних фігур

До складу програми COREL DRAW 12 входять чотири групи робочих інструментів, призначені для створення векторних об'єктів стандартних геометричних форм, які називаються фігурами.

Перерахуємо їх:

1. Перша група включає п'ять інструментів, що створюють стандартні геометричні фігури, вказані в назвах цих інструментів: Rectangle(Прямокутник), Ellipse(Еліпс), Polygon(Багатокутник), Spiral(Спіраль) і Graph Paper(Сітка);

2. Друга група включає два інструменти, що створюють фігури прямокутників і еліпсів альтернативним способом: 3 Point Rectangle(Прямокутник по трьох крапках) і 3 Point Ellipse(Еліпс по трьох крапках);

3. Третя група включає новий інструмент Smart Drawing(Розумне малювання), що дозволяє створювати геометричні фігури шляхом автоматичного перетворення в них початкових фігур, намальованих від руки;

4. Четверта група включає п'ять інструментів, що створюють так звані автофігури: Basic Shapes(Базові форми), Arrow Shapes(Форми стрілок), Flowchart Shapes(Форми блок-схем), Star Shapes (Формизірок) і Callout Shapes(Форми винесень).

Для всіх інструментів першої і четвертої груп порядок формування фігур буде аналогічним.

1. Виберіть необхідний інструмент.

2. Встановіть покажчик у вільному місці документа.

3. Натисніть кнопку миші і перемістіть покажчик по діагоналі в потрібне місце документа, після чого кнопку відпустите. В результаті сформується відповідна фігура, розміри якої співпадатимуть з розмірами уявного прямокутника, по діагоналі якого перемішався покажчик.

Якщо в процесі перетягання покажчика була натиснута клавіша <Ctrl>, то буде створена правильна фігура, а при натисненні клавіші <Shift> формування фігури відбуватиметься не з кута, а з її центру, що знаходиться в місці розташування покажчика у момент натиснення кнопки миші.

Розглянемо можливості вказаних інструментів, а також порядок роботи з ними.

***

Инструмент Rectangle

Робочий інструмент Rectangle(Прямоугольник) призначений для формування прямокутників і квадратів, в яких допускається округляти кути. Передбачена як індивідуальне регулювання радіусу скруглення кожного кута прямокутника, так і групова для всіх кутів відразу.

Пояснимо призначення елементів управління панелі властивостей, доступних для використання при роботі з інструментом Rectangle:

[1] - два поля Object(s) Position,в яких указуються координати геометричного центру об'єкту, що є фігурою прямокутника;

[2] - два поля Object(s) Size,використовувані для введення розмірів об'єкту;

[3] - два поля Scale Factor,задаючі коефіцієнти масштабування об'єкту по горизонталі і вертикалі;

[4] - кнопка Nonproportional Scaling/Sizing Ratio,що підключає режим непропорційного масштабування;

[5] - поле Angle of Rotation,в якому указується кут повороту об'єкту;

[6] - дві кнопки Mirror Buttons,що виконують дзеркальні розвороти об'єкту по горизонталі і вертикалі;

[7] - два поля (з лічильниками) Left Rectangle Corner Roundness,використовувані для введення коефіцієнтів скруглення лівих кутів прямокутника;

[8] - два поля (з лічильниками) Right Rectangle Corner Roundness,призначені для введення коефіцієнтів скруглення правих кутів прямокутника;

Примітка. Коефіцієнти скруглення кутів прямокутника задаються у відносних одиницях в діапазоні від 0 до 100. При нульовому значенні даного параметра скруглення відповідного кута відсутнє, а при максимальному значенні, рівному 100, радіус скруглення рівний половині мінімального розміру прямокутника.

[9] - кнопка Round Corner Together,активізуюча режим групового регулювання радіусів скруглення кутів прямокутника, коли величина цього радіусу буде однакова для всіх кутів;

[10] - кнопка Wrap Paragraph Text,що відкриває панель управління з параметрами налаштування обтікання текстом вибраного об'єкту.;

[11]- розгортаючийся список (з редагованим полем) Outline Width, в якому проводиться вибір (або введення) товщини лінії обведення об'єкту;

[12] - кнопка Те Front,що переміщає об'єкт на передній план поточного шару документа;

[13] - кнопка Те Back,що переміщає об'єкт на задній план даного шару;

[14] - кнопка Convert To Curves,що перетворює контур прямокутника в криву Без`є.

Інструмент 3 Point Rectangle (Прямоугольник по трем точкам)

Призначений для формування прямокутників і квадратів, в яких допускається округляти кути, і відрізняється від прямокутника лише способом створення фігури.

Цей спосіб полягає у формуванні прямокутника по трьох крапках. Початкова сторона фігури задається шляхом переміщення покажчика при натиснутій кнопці миші, а перпендикулярна їй сторона - подальшим клацанням миші після переміщення покажчика при віджатій даній кнопці.

При роботі з інструментом 3 Point Rectangleпанель властивостей приймає той же вигляд, що і для інструменту Rectangle.

***

Інструмент Ellipse

Робочий інструмент Ellipse(Еліпс) призначений для формування еліпса та кола, а також їх окремих частин (сектора і дуги). Вибір типу фігури, що створюється інструментом, проводиться на панелі властивостей. Там же задаються кути повороту утворюючих радіусів, що визначають форму сектора або дуги.

Пояснимо призначення елементів управління панелі властивостей, доступних для використання при роботі з інструментом Ellipse:

[1] - два поля Object(s) Position,в яких указуються координати геометричного центру об'єкту, що є фігурою еліпса, чи сектора дуги (для останніх двох фігур тут вказуються координати створюючого еліпса);

[2] - два поля Object(s) Size,що визначають розміри об'єкту;

[3] - два поля Scale Factor,в яких задаються коефіцієнти масштабування об'єкту, по горизонталі і вертикалі;

[4] - кнопка Nonproportional Scaling/Sizing Ratio,що підключає режим непропорційного масштабування об'єкту;

[5] - поле Angle of Rotation,в якому указується кут повороту об'єкту;

[6] - дві кнопки Mirror Buttons,що виконують дзеркальні розвороти об'єкту по горизонталі і вертикалі;

[7] - кнопка Ellipse,задає режим створення фігури у формі еліпса;

[8] - кнопка Pie,підключає режим створення фігури у формі сектора;

[9] - кнопка Arc, активізуюча режим створення фігури у формі дуги;

[10] - два поля (з лічильниками) Starting and Ending Angles,в яких указуються кути повороту утворюючих радіусів (у напрямі проти годинникової стрілки), визначальні форму сектори або дуги;

[11] кнопка Clockwise/Counterclockwise Arcs or Pies,що управляє напрямом переходу від першого створюючого радіусу до другого при формуванні сектора або дуги;

[12] - кнопка Wrap Paragraph Text,що відкриває панель управління з параметрами настройки текстового волана для вибраного об'єкту;

[13] - список (з редагованим полем) Outline Width, що розкривається,в якому проводиться вибір (введення) товщини лінії обведення;

[14] - кнопка Те Front,що переміщає об'єкт на передній план поточного шару документа;

[15] - кнопка Те Back,переміщає об'єкт на задній план даного шару;

[16] - кнопка Convert To Curves,що перетворює контур фігури в криву Без`є.

Інструмент 3 Point Ellipse(Еліпс по трьох крапках)

Аналогічний інструменту прямокутник по трьом точкам

***