В режимі рішення задач в спілкуванні з експертною системою бере участь користувач, якого цікавить результат і (або) спосіб отримання рішення. Необхідно відзначити, що залежно від призначення ЕС користувач може або не бути фахівцем в даній проблемній області (в цьому випадку він, не уміючи отримати відповідь саму, звертається до ЕС за порадою), або бути фахівцем (в цьому випадку користувач може і сам отримати результат, але звертається до ЕС з метою прискорити процес отримання результату або з метою покласти на ЕС рутинну роботу) [6, c.12].

В режимі отримання знань експерт вводить в систему продукції про область експертизи. Продукції (в більш загальному трактуванні правила) представляються на природній для користувача мові. Об'єднання знову введених продукций з базою знань здійснюється компонентой придбання знань. Для того, щоб переконатися в достатності знань (тобто переконатися в том, що процес відладки задачі завершений), експерт дає системі тестові приклади. У випадку, якщо результат, отриманий системою, не задовольняє експерта, він за допомогою пояснювальної компоненти одержує відомості про те, як був сформований результат. Після закінчення процесу відладки система передається в експлуатацію користувачам. В режимі рішення дані про задачу користувача після обробки їх лінгвістичним процесором поступають в робочу пам'ять [7, c.13].

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

Розробка програмних комплексів експертних систем як за рубежем, так і в нашій країні знаходиться на рівні швидше мистецтва, ніж науки. Це зв'язано з тим, що довгий час системи штучного інтелекту упроваджувалися здебільшого під час фази проектування, а частіше всього розроблялося декілька прототипних версій програм, перш ніж був отриманий кінцевий продукт. Такий підхід діє добре в дослідницьких умовах, проте в комерційних умовах він є дуже дорогим, щоб виправдати комерційно життєвий продукт [5, c.606].

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

Прототип повинен продемонструвати придатність методів інженерії знань для даного додатку. У разі успіху експерт за допомогою інженера по знаннях розширює знання прототипу про проблемну область. При невдачі може бути потрібно розробка нового прототипу або розробники можуть прийти до висновку про непридатність методів ЕС для даного додатку. У міру збільшення знань прототип може досягти такого стану, коли він успішно вирішує всі задачі даного додатку [6, c.14].

Оскільки процес проектування ЕС відпрацьований недостатньо, слід мати на увазі, що розробка конкретних систем може мати свої особливості. Ціль -- виділити основні проблеми проектування, з якими стикалися розробники експертних систем за п'ятнадцятирічну історію їх існування.

Перш ніж перейти до розгляду окремих етапів розробки ЕС, перерахуємо спеціальності учасників даного процесу: експерт в тій проблемній області, задачі якої вирішуватиме ЕС; інженер по знаннях -- фахівець по розробці ЕС; програміст, здійснюючий модифікацію і узгодження інструментальних засобів. Звичайно в розробці ЕС бере участь не менше чотирьох чоловік (1 експерт, 2 інженера по знаннях і 1 програміст). Необхідно особливо підкреслити, що відсутність серед учасників інженера по знаннях (тобто заміна їх програмістами) або приводить до невдачі процесу розробки ЕС, або значно подовжує цей процес.

Перейдемо до етапів побудови ЕС. На етапі ідентифікації розв'язуються наступні задачі: визначаються учасники процесу проектування і їх ролі, ідентифікується проблема, визначаються ресурси і цілі. Задача визначення учасників і їх ролей зводиться до визначення кількості експертів і інженерів по знаннях, а також форми їх взаємостосунків (наприклад, експерт може виступати або в ролі вчителя, або в ролі інформуючого). На цьому ж етапі визначаються джерела знань (книги і інструкції). Ідентифікація проблеми полягає в складанні неформального (вербального) опису вирішуваної проблеми. В цьому описі указуються загальні характеристики проблеми; підпроблеми, що виділяються усередині даної проблеми; ключові поняття і відносини: вхідні дані; гаданий вид рішення; знання, релевантні вирішуваний проблеми. Якщо початкова проблема виявляється дуже складною з погляду ресурсів, що є, то етап ідентифікації може зажадати декілька ітерацій.

При проектуванні експертної системи типовими ресурсами є: джерела знань, час розробки, обчислювальні засоби і об'єм фінансування. При визначенні ресурсів необхідно мати на увазі, що терміни розробки і упровадження експертної системи складають. Задача визначення ресурсів є вельми важливою, оскільки обмеженість якого-небудь ресурсу істотно впливає на процес проектування [6, c.15].

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

На етапі формалізації всі ключові поняття і відносини, введені на етапі концептуалізації виражаються на деякій формальній мові, запропонованій інженером по знаннях. Тут він визначає, чи підходять інструментальні засоби, що є, для вирішення проблеми, що розглядається необхідні оригінальні розробки. Виходом етапу формалізації є опис процесу рішення проблеми, що розглядається, на запропонованій формальній мові, тобто на даному етапі визначається склад і способи представлення декларативних і процедурних знань системи [6, c.17].

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

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

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

Створення першого прототипу повинне підтвердити, що вибрані методи рішень і способи уявлення придатні для успішного вирішення принаймні ряду задач з області експертизи. Після завершення першого прототипу необхідно розширити коло задач, вирішуваних системою, для того, щоб зібрати побажання і зауваження, які будуть враховані в черговій версії системи (ЕС-2). Для отримання вказаної інформації необхідно розвинути версію ЕС-1, шляхом додавання в неї засобів для збору зауважень користувачів (без участі інженера по знанням), і средств зберігання бібліотеки задач, вирішених системою [6, c.18].

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

В ході етапу тестування здійснюється оцінка вибраного способу представлення знань і всієї системи в цілому. Як тільки система виявляється в змозі обробити від початку до кінця два або три приклади, необхідно починати перевірку на більш широкому крузі прикладів для того, щоб визначити недоліки бази знань і управляючого механізму (процедур виведення). Задача інженера по знаннях полягає в підборі прикладів, забезпечуючих усесторонню перевірку експертної системи. Звичайно виділяють наступні джерела невдач в роботі системи: тестові приклади: введення/виведення: правила виведення; управляючі стратегії.

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

На етапі досвідченої експлуатації перевіряється придатність експертної системи для кінцевого користувача. Тут система займається рішенням всіх можливих задач при роботі з різними користувачами. Доцільно організувати роботу системи не на стенді розробника, а на місці роботи користувачів. До цього етапу слід переходити лише після того, як система, на думку експерта, успішно вирішуватиме практично всі задачі, що вимагаються, щоб помилки в рішеннях не створювали у користувача негативне уявлення про систему [6, c.21]. Придатність системи для користувача визначається в основному зручністю роботи з нею і її корисністю. Під корисністю системи розуміється здатність системи в ході діалогу визначити потреби користувача, виявити і усунути причини невдач в роботі і задовольнити потреби користувача (тобто вирішити поставлені задачі). Кажучи іншими словами, користувачу важливо "довести до свідомості" системи свою інформаційну потребу, не дивлячись на можливі помилки, що допускаються їм у зв'язку з недостатнім знанням системи. Звичайно, для користувача важлива також повнота і правильність рішень, але ці характеристики повинні бути є перевірені експертом на попередньому етапі.

В ході побудови експертної системи майже постійно здійснюється її модифікація. Удосконалення прототипу здійснюється в процесі циклічного проходження через етапи виконання і тестування з метою відладки правил і процедур виведення. Цикли повторюються до тих пір, поки система не поводитиметься очікуваним чином. Зміни, здійснювані при удосконаленні, залежать від вибраного способу уявлення і від класу задач, вирішуваних експертною системою. Якщо в процесі удосконалення бажана поведінка не досягається, то необхідно здійснити більш значні модифікації архітектури системи і бази знань. Повернення з етапу тестування на етап формалізації приводить до перегляду вибраного раніше способу представлення знань. Даний цикл називають переконструюванням. Якщо виниклі проблеми ще більш серйозні, то після невдачі на етапі тестування може бути потрібно повернення на етапи концептуалізації і ідентифікації. В цьому випадку йтиметься про переформулировании понять, що використовуються в системі, тобто про проектування всієї системи практично наново [6, c.22].

Страницы: 1, 2, 3, 4, 5