Методологія побудови ЕС.

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, то їх виправлення і додавання може призвести до появи нових помилок, тому повинен існувати спеціальний тест, який перевіряє систему на несуперечність правил.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.parny.by.ru/