Лекція-6.

Технології розробки експертних систем

Колектив розробників. Технологія проектування і розробки експертних систем.

6.1. Колектив розробників

Під колективом розробників (КР) будемо розуміти групу фахівців, що відповідальні за створення ЕС.

Рис. 5.1. Структура експертної системи

Як видно з рис.5.1, до складу КР входять принаймні троє осіб — користувач, експерт і інженер по знаннях. На рисунку не видно програміста. Таким чином, мінімальний склад КР включає чотири особи; реально ж він розростається до 8-10 людей. Чисельне збільшення колективу розробників відбувається за наступних причинах: необхідність обліку думок декількох користувачів, допомоги декількох експертів; потреба як у проблемних, так і системних програмістах. На Заході в цей колектив додатково традиційно включають менеджера й одного технічного помічника,

У цілому рівень і чисельність групи залежать від характеристик поставленої задачі.

Нижче приведені два аспекти характеристик членів КР: 1 — психофізіологічний, 2—професійний.

Користувач

1. До користувача пред'являються найслабші вимоги, оскільки його не вибирають. Він є в деякому роді замовником системи. Бажані якості:

а) дружелюбність;

б) уміння пояснити, що ж він хоче від системи;

в) відсутність психологічного бар'єра до використання обчислювальної техніки;

г) інтерес до нового.

2. Необхідно, щоб користувач мав деякий базовий рівень кваліфікації, що дозволить йому правильно зрозуміти рекомендації ЕС. Крім того, повинна бути повна сумісність у термінології інтерфейсу ЕС з тією, котра звична і зручна для користувача.

Експерт

1. Експерт — надзвичайно важлива фігура в групі КР. У кінцевому рахунку, його підготовка визначає рівень компетенції бази знань. Бажані якості:

а) доброзичливість;

б) готовність поділитися своїм досвідом;

в) уміння пояснити (педагогічні навички);

г) зацікавленість (моральна, а краще ще і матеріальна) в успішності розробки

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

Програміст

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

а) товариськість;

б) здатність відмовитися від традиційних навичок і освоїти нові методи;

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

2. Оскільки сучасні ЕС — дуже складні і дорогі програмні комплекси, програмісти в КР повинні мати досвід і навички розробки програм.

Інженер по знаннях

1. Існують такі професії і види діяльності, для яких природні якості особистості (спрямованість, здібності, темперамент) можуть мати характер абсолютного показання чи протипоказання до занять. Очевидно, інженерія знань належить до таких професій. За різними оцінками, це одна із самих нечисленних, високооплачуваних і дефіцитних у світі спеціальностей.

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

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

Стиль спілкування. Делікатність, уважність, інтелігентність, ненав'язливість, скромність, уміння слухати і задавати питання, гарна комунікабельність і в той же час впевненість у собі — стиль спілкування, що рекомендується.

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

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

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

6.2.1. Проблеми розробки промислових ЕС

Процес розробки промислової експертної системи практично для будь-якої предметної області можна розділити на шість більш-менш незалежних етапів (рис.6.2).

Рис. 6.2. Етапи розробки ЕС

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

6.2.2. Вибір придатної проблеми

Цей етап визначає діяльність, що передує рішенню почати розробляти конкретну ЕС. Він включає:

• визначення проблемної області і задачі;

• знаходження експерта, який бажає співпрацювати при вирішенні проблеми, і призначення колективу розробників;

• визначення попереднього підходу до вирішення проблеми;

• аналіз витрат і прибутків від розробки;

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

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

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

Експертна система ні в якому разі не усуне потребу в реляційних базах даних, статистичному програмному забезпеченні, електронних таблицях і системах текстової обробки. Але якщо результативність задачі залежить від знання, яке є суб'єктивним, що змінюється, символьним чи частково виходячими з висновків здорового глузду, тоді область може обґрунтовано виступати претендентом на експертну систему. Звичайно експертні системи розробляються шляхом одержання специфічних знань від експерта і введення їх у систему. Деякі системи можуть містити стратегії одного індивіда. Отже, знайти придатного експерта — це ключовий крок у створенні експертних систем. У процесі розробки і наступного розширення системи, інженер по знаннях і експерт звичайно працюють разом. Інженер по знаннях допомагає експерту структурувати знання, визначати і формалізувати поняття і правила, необхідні для рішення проблеми.

6.2.3. Технологія швидкого прототипування

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

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

Рис. 6.3. Стадії розробки прототипу ЕС

Ролі розробників (експерт, програміст, користувач і аналітик) є постійними протягом усієї розробки. Суміщення ролей небажано.

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

Уточнюється задача, планується хід розробки прототипу експертної системи, визначаються:

• необхідні ресурси (час, люди, ЕОМ і т.д.);

• джерела знань (книги, додаткові експерти, методики);

• наявні аналогічні експертні системи;

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

• класи розв'язуваних задач і т.д.

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

Середня тривалість 1-2 тижні.

Витяжка знань

На цій стадії відбувається перенесення компетентності від експерта до інженера по знаннях, з використанням різних методів:

• аналіз текстів;

• діалоги;

• експертні ігри;

• лекції;

• дискусії;

• інтерв'ю;

• спостереження й інші.

Витяжка знань — одержання інженером по знаннях найбільш повного з можливих представлень про предметну область і способи прийняття рішення в ній.

Середня тривалість 1-3 місяці.

Структуризація чи концептуалізація знань

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

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

• список основних понять і їхніх атрибутів;

• відносини між поняттями;

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

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

• обмеження стратегій і т.д.

Структуризація (чи концептуалізація) знань — розробка неформального опису знань про предметну область у виді графа, таблиці, чи діаграми тексту, що відбиває основні концепції і взаємозв'язки між поняттями предметної області.

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

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

Будується формалізоване представлення концепцій предметної області на основі обраної мови представлення знань (МПЗ). Традиційно на цьому етапі використовуються;

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

• продукційні моделі (із прямим і зворотним висновком);

• семантичні мережі;

• фрейми;

• об’єктно-орієнтовані мови, що базуються на ієрархії класів, об'єктів.

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

Все частіше на цій стадії використовується симбіоз, мов представлення знань, наприклад, у системі ОМЕГА [Довідник по ИИ, 1990] — фрейми + семантичні мережі + повний набір можливостей мови числення предикатів. Середня тривалість 1-2 місяці. Більш детальніше див. у розділах 3, 4.

Реалізація

Створюється прототип експертної системи, що включає базу знань і інші блоки, за допомогою одного з наступних способів:

• програмування на традиційних мовах типу Pascal, C++ і ін.;

• програмування на спеціалізованих мовах, що застосовуються у задачах штучного інтелекту: LISP [Хювянен, Сеппянен, 1991], FRL [Байдун, Бунін, 1990], SMALLTALK [Довідник по ИИ, 1990] і ін.;

• використання інструментальних засобів розробки;

• використання «порожніх» ЕС чи «оболонок» типу ЕКСПЕРТ, ФІАКР і ін.

Реалізація — розробка програмного комплексу, що демонструє життєздатність підходу в цілому. Найчастіше перший прототип відкидається на етапі реалізації діючої ЕС.

Середня тривалість 1-2 місяці. Більш детально ці питання розглядаються в розділі 6.

Тестування

Оцінюється і перевіряється робота програм прототипу з метою приведення у відповідність з реальними запитами користувачів. Прототип перевіряється на:

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

• ефективність стратегії керування (порядок перебору, використання нечіткого висновку й ін.);

• якість перевірочних прикладів;

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

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

Середня тривалість 1-2 тижні.

2.4.4. Розвиток прототипу до промислової ЕС

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

демонстраційний прототип → діючий прототип → промислова система → комерційна система

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

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

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

Таблиця 2.1. Перехід від прототипу до промислової експертної системи

Система	Опис
Демонстраційний прототип ЕС	Система вирішує частину задач, демонструючи життєздатність підходу (кілька десятків правил чи понять)
Дослідницький прототип ЕС	Система вирішує більшість задач, але нестійка в роботі і не цілком перевірена (кілька сотень правил чи понять)
Діючий прототип ЕС	Система надійно вирішує всі задачі на реальних прикладах, але для складної задачі вимагає багато часу і пам'яті
Промислова система	Система забезпечує високу якість рішень при мінімізації необхідного часу і пам'яті; переписується з використанням більш ефективних засобів представлення знань
Комерційна система	Промислова система, придатна до продажу, тобто добре документована і підтримується сервісною службою