1. Підхід до проектування ЕС.
Проектування ЕС має істотну відмінність від проектування традиційних інформаційних систем в силу того, що постановка завдань, що вирішуються експертною системою може уточнюватися під час всього циклу проектування. Внаслідок цього виникає потреба модифіковані принципи і способи побудови бази знань та апарату лгіческого виводу в ході проектування в міру того, як збільшується обсяг знань розробників про предметної області.
У силу зазначених особливостей при проектуванні ЕС-м застосовується концепція "швидкого прототипу". Її суть: розробники не намагаються відразу побудувати закінчений продукт. На початковому етапі створюється прототип, к-рий повинен відповідати двом умовам:
1) він повинен вирішувати типові завдання предметної області;
2) з іншого боку трудомісткість його розробки повинна бути дуже незначною.
Для задоволення цих умов під час створення прототипу використовуються інструментальні засоби, що дозволяють прискорити процес програмування ЕС (скелетні мови, оболонки ЕС). У разі успіху прототип повинен розширюватися додатковими знаннями з предметної області. При невдачі може знадобитися розробка нового прототипу чи проектувальники можуть прийти до висновку про непридатність методів штучного інтелекту для цього додатка.
У міру збільшення знань про предметну область прототип може досягти такого стану, коли він успішно вирішує всі необхідні завдання в рамках предметної області. У цьому випадку потрібно перетворення прототипу в кінцевий продукт шляхом його перепрограмування на мовах "низького рівня", що забезпечить збільшення швидкодії та ефективності програмного продукту.
Кількість розробників ЕС не повинно бути менше 4 чол., З яких брало 1 явл-ся експертом ПО, 2 - інженери за знаннями чи проектувальники ЕС, 1 - програміст, здійснює модифікацію і узгодження інструментальних засобів.
У подальшому, в процесі перетворення прототипу в кінцевий продукт, склад програмістів повинен бути збільшений.
2. Основні етапи розробки ЕС.
1. Ідентифікація.
2. Концептуалізація.
3. Формалізація.
4. Виконання.
6. Тестування.
a. Переформулювання
b. Переконструирование
c. Удосконалення
d. Завершення
До складу функцій етапу 1 входить:
1) визначення команди проектувальників, їх ролі, а також форми взаімоотоношеній;
2) визначення цілей розробок та ресурсів;
3) опис загальних характеристик проблеми, вхідних даних, запланованого рішення, ключових понять і відносин.
Типові ресурси цього етапу: джерела знань, час розробки, обчислювальні ресурси, обсяг фінансування.
На етапі 2 експерт і инжинер за знаннями формалізують ключові поняття, відносини і характеристики, які виявлені на попередньому етапі. Даний етап прізвн вирішити наступні питання:
визначити типи даних, виведені поняття, використовувані стратегії та гіпотези, види взаємозв'язків між об'єктами, типи обмежень, накладених на процес вирішення завдання, склад знань, які використовуються для вироблення й обгрунтування рішень.
Досвід показує, що для успішного вирішення питань цього етапу доцільно складати протокол дій і міркувань експертів у процесі проектування. Такий протокол забезпечує інженера по знаннях словником термінів і сот час змушує експерта осмислено ставитися до своїх слів.
На цьому етапі не потрібно домагатися повної визначеності і коректності усіх висновків, а слід намітити лише основні типові напрямки вирішення проблеми.
На етапі 3 проводиться опис всіх ключових понять і відносин на формальній мові. Інженер по знаннях робить аналіз інструментальних систем і визначає їх придатність для конкретного застосування. Виходом даного етапу є формальний опис всього процесу рішення жадачі на рівні декларативних і процедурних знань. Інженер по знаннях визначає структуру простору пошуку рішень, вибирає й обгрунтовує модель знань, визначає склад метазнаній, які потім можуть бути покладені в механізм логічного висновку. При роботі зі знаннями вивчається ступінь їх достовірності, узгодженість і надмірність, реалізується функція належності різних оціночних показників (наприклад, коефіцієнтів впевненості), а також закладається певна інтерпретація знань у формальних структурах.
Етап 4 полягає в розробці одного або декількох прототипів. Цей етап виконується програмістом і полягає в наповненні бази знань інструментальної системи конкретними знаннями, а також програмуванні окремих компонент системи. Звичайна помилка програміста полягає в тому, що процес наповнення бази знань реальними знаннями відкладається до закінчення програмування. Якщо база знань заповнюється з початку розробки прототипу, то це дозволяє своєчасно уточнити структуру знань і швидко змінити програмні компоненти.
Перший прототип повинен бути готовий вже через 2 місяці. При роботі з ним програміст доводить, що обрані структури і методи придатні для цього додатка і можуть бути в подальшому розширені. При цьому він зовсім не піклується про ефективність машинної реалізації. Після завершення першого прототипу коло завдань розширюється і на цій основі формується наступний прототип. Після досягнення досить ефективного функціонування ЕС на базі прототипів, удосконалюються структури декларативних і процедурних знань, а також процедури логічного висновку. Основна складність полягає в тому, що дуже часто в системі є громіздкі правила або багато схожих правил. Невірно обрані керуючі стратегії, в яких порядок вибору та аналізу понять істотно відрізняється від технології експерта. На цьому етапі дуже важливо присвячувати експерта у всі проблеми, пов'язані з отриманням рішень, і уважно проводити аналіз думки експерта про недоліки системи.
Етап 5 оцінює придатність ЕС для кінцевого користувача. При цьому розробники намагаються залучити якомога більше користувачів різної кваліфікації, які можуть звертатися до системи для реалізації різноманітних запитів. Для того, щоб не дискредитувати систему в очах користувача, розробники перед цим етапом повинні усунути всі помилки в роботі системи, навіть дрібні технічні помилки. Користувач аналізує систему з точки зору корисності (можливість системи в ході діалогу визначити потреби користувача, виявити та усунути причини його невдач у роботі) і зручності (настроюваність на рівень кваліфікації користувача, а також стійкість до помилок).
За результатами 5-го етапу може знадобитися не тільки модифікація програмного забезпечення, але й ідеології розробки інтерфейсу.
Етап 6. Покликаний здійснювати оцінку системи в цілому. Тут необхідно особливу увагу приділити добору тестових прикладів. У них повинні знайти відображення такі випадки:
невірно сформулірованниие питання користувача;
присутність невизначеності в питаннях користувача;
доступність для користувача лексики системи;
доступність для користувача пояснень, які видає система;
проіворечівость і неповнота правил;
узгодження контекстів дії правил.
За результатами 6-го етапу здійснюється модифікація системи. Найбільш простим її виглядом явл-ся удосконалення прототипів. Цей вид зачіпає тільки етапи 4 і 6.
Більш серйозним виглядом модифікації явл-ся переконструирование уявлень. Цей вид модифікації необхідним у тому випадку, якщо виявляється, що бажане поведінка системи не досягнуто. Передбачається повернення на етап формалізації і далі здійснюється весь цикл проектування. Якщо проблеми функціонування системи ще більш серйозні, то доводиться повертатися на етапи 2 і 1 для переформулювання вимог до системи і основних понять.
3. Практичні аспекти розробки і впровадження ЕС.
Відповідно до результатів тестування ЕС може перебувати на одній з наступних стадій:
1) демонстраційний прототип (вирішує лише частину завдань в рамках ПЗ, демонструючи правильність обраного апарату логічного висновку). Термін доведення системи до цієї стадії - близько 3-х міс., К-ть правил в базі знань - 50-100.
2) дослідницький прототип (вирішує всі завдання в рамках ПЗ, на недостатньо стійка в роботі, не повністю перевірена). Термін доведення - 1-2 року, кол-во правил - 200-500.
3) діючий прототип (вирішує стабільно всі завдання в рамках ПЗ, але недостатньо ефективна в роботі, в тому числі нераціональне використання пам'яті, невисока швидкодія). 2-3 р., 500-1000.
4) промислова система (обеспчівает ефективну роботу і високу якість рішень, містить у порівнянні зі стадією 3 набагато більше правил в базі знань, програмне забезпечення в порівнянні з 3) переписано на мову низького рівня). 2-4 р., 1000-1500.
5) комерційна система (передбачає узагальнення завдань, відхід від специфіки ПЗ, призначається для продажу іншим споживачам. Розвинена по Порівняно з 4) система редагування знань, інтерфейсу з конкретним користувачем, навчання). 3-6 років, 1000-3000.
У процесі проектування ЕС слід враховувати той негативний досвід, який накопичено розробниками на кожній стадії проектування.
На етапі 1 може виявитися, що система або задача настільки важка, що її не можна реалізувати в рамках видеенной проектувальником системи ресурсів (час, гроші і т. д.). Проектувальники повинні дуже уважно підійти до питання, чи зможе рішення завдання принести істотну користь, для пресонала, який її експлуатує. Слід врахувати, що для скорочення часу проектування не можна розширювати склад проектувальників, так як процес проектування ітеративний і категорії проектувальників не можуть у стислі терміни осмислити всі етапи проектування.
Традиційною помилкою етапу 3 явл-ся підгонка інструментального засобу під поняття і взаємозв'язку конкретної ПЗ.
Не можна погоджуватися при розробці прототипу на програмування відразу ж на мовах низького рівня, тобто без використання інструментальної системи.
На всіх стадіях проектування інженер по знаннях працює з експертом і при цьому виникає цілий ряд труднощів, які заздалегідь треба враховувати:
експерти завжди повинні бути висококваліфікованими, їх потрібно зацікавлювати матеріально;
експерт ніколи не може знайти час на роботу з інженером по знаннях;
в системі обов'язково повинна використовуватися та ж термінологія, що і у експертів ПО, тільки в цьому випадку експерт може успішно розуміти структуру бази знань та вносити до неї відповідні зміни;
з плином часу експерт втрачає інтерес до проекту системи та постійно скорочує час роботи з проектувальником. Для усунення цього проектувальник вносить зміни в систему тільки разом з експертом, тестує також разом з ним;
експерт незнайомий, як правило, з комп'ютером, тому РС встановлюється на його робочому місці і доопрацювання системи виробляється там же;
при добуванні знань експерта проектувальнику дуже важко відокремити знання ПЗ від метазнаній, тому робота з експертом має відбуватися не з усіх питань в цілому, а по строго спланованим інженером по знаннях порцій.
На етапі 4 при розробці прототипу слід прагнути не розробляти самостійно кошти пояснення, а використовувати тільки ті, що є в інструментальній системі.
При розробці першого прототипу необхідно прагнути до того, щоб в базу знань потрапили прості універсальні правила і скорочувати кількість специфічних правил.
На етапі 6 слід враховувати, що якщо розмір правил перевищує 300, то їх виправлення і додавання може призвести до появи нових помилок, тому повинен існувати спеціальний тест, який перевіряє систему на несуперечність правил.