• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

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

ЛЕКЦІЯ-6.

Методи визначення відношень

Якщо на стадії 4 (див. Рис. 4.10) ми виявили зв'язки між поняттями й використали їх на стадіях 5 і 6 для одержання піраміди знань, то на стадії 7 ми даємо імена зв'язкам, тобто перетворюємо їх у відношення.

У роботі [Поспєлов, 1986] вказується на наявність більше 200 базових видів різних відношень, що існують між поняттями. Запропоновано різні класифікації відносин [Келасьев, 1984; Поспелов, 1986]. Варто тільки підкреслити, що крім універсальних відношень (просторових, тимчасових, причинно-наслідкових) існують ще й специфічні відношення, властиві ті або інші предметної області [Гаврилова, Червинская, Яшин, 1988].

Цікаві можливості до структурування знань додають системи когнітивної графіки. Так, у системі OPAL [Olton., Muser, Combs et al., 1987] експерт може маніпулювати на екрані дисплея зображеннями найпростіших понять і будувати схеми лікування захворювань, позначаючи відношення явними лініями, які потім іменуються.

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

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

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

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

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

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

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

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

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

В даний момент у психології існує кілька десятків методик по визначенню властивостей особистості, які широко використовуються у питаннях професійної орієнтації. Ці психодіагностичні методики, частина з яких вже автоматизована, розрізняються спрямованістю, глибиною, часом опитування і способами інтерпретації. Зокрема, система АВАНТЕСТ (Автоматичний Аналіз Тестів) [Гаврилова, 1984] дозволяє моделювати міркування психолога при аналізі результатів тестування по 16-факторному наборі запитань Р. Кеттела і видає зв'язний психологічний висновок на природній російській мові, що характеризує такі властивості особистості, як товариськість, аналітичність, сумлінність, самоконтроль і т.п. Модифікована база знань системи АВТАНТЕСТ пізніше була використана в ЕС «Cattell» (див. параграф 7.3).

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

Користувач

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

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

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

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

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

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

Експерт

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

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

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

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

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

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

Програміст

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

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

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

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

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

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

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

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

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

Стиль спілкування. Інженер по знаннях «задає тон» у спілкуванні з експертом, він веде діалог, і від нього в кінцевому рахунку залежить його продуктивність. Можна виділити два стилі спілкування: діловий (чи твердий) і дружній (чи м'який, делікатний). Нам здається, що дружній буде свідомо більш успішним, тому що знижує «ефект фасаду» в експерта, заставляє його вільно почуватися. Делікатність, уважність, інтелігентність, ненав'язливість, скромність, уміння слухати і задавати питання, гарна комунікабельність і в той же час впевненість у собі — стиль спілкування, що рекомендується. Безумовно, що це одночасно природній дар і мистецтво, однак заняття по психологічному тренінгу можуть дати корисні навички.

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

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

Інженер по знаннях має справу з усіма формами знань (див. параграф 1.3).

Z1 (знання в пам'яті) → Z2 (знання в книгах) → Z3 (поле знань) → Z4 (модель знань) → Z5 (база знань).

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

Вивчення й аналіз текстів на рівні Z2 має на увазі широку загальнонаукову підготовку інженера; знайомство з методами реферування й анотування текстів; володіння навичками швидкого читання, а також текстологічними методами витягу знань.

Розробка поля знань на рівні Z3 вимагає кваліфікованого ознайомленя з методологією представлення знань, системним аналізом, теорією пізнання, апаратом багатомірного шкалювання, кластерним і факторним аналізом.

Розробка формалізованого опису Z4 передбачає попереднє вивчення апарату математичної логіки і сучасних мов представлення знань. Моделі знань розробляються на підставі результатів глибокого аналізу інструментальних засобів розробки ЕС і наявних «оболонок». Крім того, інженеру по знаннях необхідно володіти методологією розробки ЕС, включаючи методи швидкого прототипування.

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

Так як інженерів по знаннях «вирощують» із програмістів, то рівень Z5 звичайно не викликає труднощів, особливо якщо розробка ведеться на традиційних мовах типу C чи Pascal. Спеціалізовані мови штучного інтелекту Лісп і Пролог вимагають деякої перебудови архаїчного-алгоритмічного мислення.

Успішність вибору і підготовки колективу розроблювачів ЕС визначає ефективність і тривалість усього процесу розробки.

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

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

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

Процес розробки промислової експертної системи, спираючись на традиційні технології [Ніколов і ін., 1990; Хейес-Рот і ін., 1987; Tuthill, 1994], практично для будь-якої предметної області можна розділити на шість більш-менш незалежних етапів (рис.6.2).

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

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

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

· формування корпоративних інформаційних систем;

· організація складних розрахунків;

· робота з комп'ютерною графікою;

· обробка текстів і автоматизований документообіг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· дана задача може бути вирішена за допомогою експертної системи;

· експертну систему можна створити запропонованими на ринку засобами;

· є придатний експерт;

· запропоновані критерії продуктивності є розумними;

· витрати і термін їхньої окупності прийнятні для замовника,

тоді він складає план розробки. План визначає кроки процесу розробки і необхідних витрат, а також очікувані результати.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· діалоги;

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

· лекції;

· дискусії;

· інтерв'ю;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· фрейми;

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

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

Реалізація

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

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

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

· використання інструментальних засобів розробки ЕС типу СПЕІС [Ковригин, Перфильев, 1988], ПІЕС [Хорошевский, 1993], G2 [Попов, Фомін, Кисіль, 1996];

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

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

Тестування

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

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

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

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

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

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

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

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

Якщо спочатку обрані об'єкти чи властивості виявляються невідповідними, їх необхідно замінити. Можна зробити оцінку загального числа евристичних правил, необхідних для створення кінцевого варіанту експертної системи. Іноді [Хювянен, Сеппянен, 1991] при розробці промислової та/або комерційної системи виділяють додаткові етапи для переходу (табл. 2.1).

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

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

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

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

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

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

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

Читайте також:

1. Active-HDL як сучасна система автоматизованого проектування ВІС.
2. D і 3D технології креслення в AutoCAD
3. I. Органи і системи, що забезпечують функцію виділення
4. I. Особливості аферентних і еферентних шляхів вегетативного і соматичного відділів нервової системи
5. II. Анатомічний склад лімфатичної системи
6. II. Бреттон-Вудська система (створена в 1944 р.)
7. III етап. Системний підхід
8. III. Етапи розробки програмного забезпечення
9. IV. Розподіл нервової системи
10. IV. Система зв’язків всередині центральної нервової системи
11. IV. УЗАГАЛЬНЕННЯ І СИСТЕМАТИЗАЦІЯ ВИВЧЕНОГО
12. IV. Філогенез кровоносної системи

Переглядів: 1982