загрузка...
загрузка...
На головну

Етапи розробки експертних систем.

  1. I. НОРМАТИВНА БАЗА ДЛЯ РОЗРОБКИ ПОЛОЖЕННЯ ПРО ПЕРВИННОЇ ОРГАНІЗАЦІЇ ПРОФСПІЛКИ
  2. III. Основні етапи міжнародних відносин в Новий час.
  3. А) Основні етапи китайської філософії.
  4. Автоматизація розробки ПОС
  5. Автоматизація розробки ППР
  6. Аналіз процесу розробки родовищ.
  7. Апологетика, патристика і схоластика як етапи розвитку середньовічної філософії.

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

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

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

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

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


 Якщо ЕС-2 успішно пройшла етап тестування, то вона може класифікуватися як промислова експертна система. Етап тестування.
 В ході даного етапу проводиться оцінка обраного способу представлення знань в ЕС в цілому. Для цього інженер по знаннях підбирає приклади, що забезпечують перевірку всіх можливостей розробленої ЕС.
 Розрізняють такі джерела невдач в роботі системи: тестові приклади, введення-виведення, правила виведення, керуючі стратегії. Показові тестові приклади є найбільш очевидною причиною невдалої роботи ЕС. У гіршому випадку тестові приклади можуть виявитися взагалі поза предметної області, на яку розрахована ЕС, однак частіше безліч тестових прикладів виявляється занадто однорідним і не охоплює всю предметну область. Тому при підготовці тестових прикладів слід класифікувати їх за підпроблеми предметної області, виділяючи стандартні випадки, визначаючи кордону важких ситуацій і т.п.
 Введення-виведення характеризується даними, отриманими в ході діалогу з експертом, і висновками, пред'явленими ЕС в ході пояснень. Методи придбання даних можуть не давати необхідних результатів, так як, наприклад, задавалися неправильні питання або зібрана не вся необхідна інформація. Крім того, питання системи можуть бути важкими для розуміння, багатозначними і не відповідають знань користувача. Помилки при введенні можуть виникати також через незручне для користувача вхідного мови. У ряді додатки для користувача зручний введення не тільки в друкованій, але і в графічній або звуковий формі.
 Вихідні повідомлення (висновку) системи можуть виявитися незрозумілими користувачеві (експерту) з різних причин. Наприклад, їх може бути занадто багато або, навпаки, занадто мало. Також причиною помилок може бути невдала організація, упорядкованість висновків або невідповідний користувачеві рівень абстракцій з незрозумілою йому лексикою.
 Найбільш поширений джерело помилок в міркуваннях стосується правил виведення. Важлива причина тут часто криється у відсутності обліку взаємозалежності сформованих правил. Інша причина полягає в помилковості, суперечливості та неповноти використовуваних правил. Якщо невірна посилка правила, то це може привести до вживання правила в невідповідному контексті. Якщо помилково дію правила, то важко передбачити кінцевий результат. Правило може бути помилково, якщо при коректності його умови і дії порушено відповідність між ними.
 Нерідко до помилок в роботі ЕС призводять застосовуються керуючі стратегії. Зміна стратегії буває необхідно, наприклад, якщо ЕС аналізує суті в порядку, відмінному від "природного" для експерта. Послідовність, в якій дані розглядаються ЕС, не тільки впливає на ефективність роботи системи, але і може призводити до зміни кінцевого результату. Так, розгляд правила А до правила У здатне привести до того, що правило У завжди буде ігноруватися системою. Зміна стратегії буває також необхідно і в разі неефективної роботи ЕС. Крім того, недоліки в керуючих стратегіях можуть привести до надмірно складним висновками і поясненням ЕС.
 Критерії оцінки ЕС залежать від точки зору. Наприклад, при тестуванні ЕС-1 головним в оцінці роботи системи є повнота і безпомилковість правил виведення. При тестуванні промислової системи превалює точка зору інженера по знаннях, якого в першу чергу цікавить питання оптимізації уявлення і маніпулювання знаннями. І, нарешті, при тестуванні ЕС після дослідної експлуатації оцінка проводиться з точки зору користувача, зацікавленого в зручності роботи і отримання практичної користі

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

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


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

6.3 Розробка прототипу експертної системи[18]:


 При розробці практично всіх інструментальних засобів за основу приймається методологія автоматизації проектування на базі використання прототипів. Які не стосуються програмного забезпечення термін прототип означає "працюючу модель програми, яка функціонально еквівалентна подмножеству кінцевого продукту". Ідея полягає в тому, щоб на ранній стадії роботи над проектом розробити спрощену версію кінцевої програми, яка могла б послужити доказом продуктивності основних ідей, покладених в основу проекту. Прототип повинен бути здатний вирішувати будь-яку з нетривіальних завдань, характерних для заданої області застосування. На основі аналізу досвіду роботи з прототипом розробники можуть уточнити вимоги до системи в цілому і її Основним функціональним характеристикам. Працездатність прототипу може послужити очевидним доказом можливості вирішення проблем за допомогою створюваної системи ще до того, як на її розробку будуть витрачені значні кошти.
 Після всебічного аналізу прототип відкладається в сторону і починається розробка робочої версії програми, яка повинна вирішувати весь комплекс завдань, визначених у специфікації проекту. Процес розробки експертної системи, як правило, складається з послідовності окремих етапів, на яких нарощуються можливості системи, причому кожен з етапів поділяється на фази проектування, реалізації, компонування і тестування. В результаті після кожного етапу нарощування можливостей в розпорядженні користувача є система, яка здатна справлятися з усе більш складними варіантами проблеми.
 Така методика проектування дещо відрізняється від методики розробки програм інших видів. При створенні більшості програмних продуктів частіше використовується інша модель процесу-спочатку розробляється специфікація продукту, потім виконується планування, проектування компонентів, їх реалізація, компоновка комплексу і тестування кінцевого варіанту. Той факт, що при розробці експертних систем є можливість спочатку побудувати і всебічно випробувати прототип, дозволяє уникнути безлічі переробок в процесі створення робочої версії системи. Але технологія послідовного нарощування функціональних можливостей таїть в собі і проблему інтеграції нових функцій з реалізованими в попередніх варіантах. Інструментальні засоби розробки експертних систем і створювалися, в першу чергу, з метою подолання виникаючих при цьому складнощів на основі модульного представлення знань.
 При незадовільному функціонуванні прототипу експерт і інженер по знаннях мають можливість оцінити, що саме буде включено в розробку остаточного варіанту системи.
 Якщо спочатку вибрані об'єкти або властивості виявляються невідповідними, їх необхідно змінити. Можна зробити оцінку загального числа евристичних правил, необхідних для створення остаточного варіанта експертної системи. Іноді при розробці промислової системи виділяють додаткові етапи [22]:

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


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

  • Демонстраційний прототип ЕС Система вирішує частину завдань, демонструючи ж з нездатність півходу (кілька десятків правил або понять)
  • Дослідницький прототип ЕС Система вирішує більшість завдань, але не стійка в роботі і не повністю перевірена [кілька сотень правил або понять)
  • Діючий прототип ЕС

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

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


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



Попередня   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30

Пошук методом редукції. | Пошук рішень в ієрархії просторів. | Пошук рішень в альтернативних просторах. | Вибір методу рішення задач. | Класифікація інструментальних засобів. | Об'єктно-орієнтовані мови | Мови інженерії знань. | Багатофункціональні програмні середовища | CLIPS як багатофункціональне середовище програмування (інженерії знань) | Засоби автоматизації розробки експертних систем. |

загрузка...
© um.co.ua - учбові матеріали та реферати