Обговорення:Експертна система

Ця стаття є частиною Проєкту:Комп'ютерні науки (рівень: 3, важливість: висока)
	Мета проєкту — створення якісних та інформативних статей на теми, пов'язані з інформатикою і комп'ютерними науками. Ви можете покращити цю статтю, відредагувавши її, а на сторінці проєкту вказано, чим ще можна допомогти. Учасники проєкту будуть вам вдячні.
III (у розвитку)	Ця стаття за шкалою оцінок статей Проєкту:Комп'ютерні науки має рівень «стаття у розвитку».
Висока	Важливість цієї статті для проєкту Комп'ютерні науки: «висока»
	Чим допомогти:

Текст статті Експертна система

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

Призначення експертної компоненти

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

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

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

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

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

Таким чином, на даному рівні можна вимагати від експертної компоненти адміністрування БД и супроводження модельного представлення, побудованого на нечітких зв'язках.

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

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

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

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

Рівень технологічний підготовки виробництва не розглядається детально в рефераті. На це є декілька причин. Технологічна підготовка виробництва в основному визначається трьома факторами: 1) проектування контрольно-юстувальної апаратури й тестів програмних продуктів; 2) розробка технологічного забезпечення 3) розробка технологічних процесів.

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

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

Розглянувши специфічні особливості експертного супроводу кожного з рівнів проектування, необхідно доповнити перелік вимог до експертної компоненти вимогами, інваріантними як до ієрархічного рівня, так і до структури САП. Ці вимоги стосуються, насамперед, організації лінгвістичного забезпечення. Необхідність створення інструментального середовища, супроводжуваного проектантами, обумовлює необхідність загальної мови, що забезпечує спілкування й обмін знаннями між проектантами. Причому, це не обов'язково повинна бути тільки природна мова, але в значній мірі це повинна бути й мова вирахування предикатів, мова формул математичних і мова інженерних формул. Якщо для чисто експертних систем ці формули будуються на відносинах типу «ЯКЩО» — «ТО» — «ІНАКШЕ», то для експертної компоненти САП (у якогму сполучаться формалізовані й евристичні процедури й модельні подання) такими «інженерними формулами», що кодують інженерні знання можуть стати маршрути проектування, віднесені до певних класів і навіть типів об'єктів проектування, сукупність яких утворює БД (можна, напевно, сказати й «бази знань»).

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

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

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

Структури експертних компонентів САП

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

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

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

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

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

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

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

програмного забезпечення єдиною евристичною програмою, що має властивістю адаптації до умов застосування залежно від того, з яким програмним модулем основної структури вона взаємодіє (рис. 47).

Основною функцією цієї евристичної програми є настроювання програм — ключів (К1-К4) на певну взаємодію з монітором. Це дозволяє назвати її умовно програмою логічного управління. Сукупність програм — ключів, лінгвістичного процесора і програми логічного керування утворює в цьому випадку експертний компонент. У такій конфігурації програмного забезпечення програми К1-К4 кодують нечіткі стосунки, що визначають області адекватності модельного подання об'єкта проектування залежно від опису, запропонованого користувачем. Поріг, що визначає «спрацьовування» цих «ключів», є нечіткою змінною, значення якої або встановлюється, а потім зберігається в БД системи (якщо система функціонує в режимі навчання), або вибирається по опису об'єкта або процесу проектування, зробленому користувачем. При такій організації програмного забезпечення можливе використання будь-якого лінгвістичного процесора, зокрема, універсального програмного продукту. Програма логічного управління тут є досить універсальною й простою, оскільки вона може бути побудована як інваріантна до каналів управління.

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

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

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

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

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

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

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

Групова операція дозволяє постулювати ядро проблемного забезпечення, що реалізує чисельний метод, підгрупу чисельних методів, якщо групова операція піддається декомпозиції, або існує декілька способів утворення підгрупи над множиною компонент. Власне програмні реалізації в даній структурі можуть здійснюватися або на метамові розділу аналізу (будь-яка алгоритмічна мова розроблена як інструментальний засіб по САП даного рівня), або за допомогою мови аналітичних перетворень. Програмні системи для реалізації аналітичних перетворень на ЕОМ широко поширені серед математиків і інженерів ще з часу розробки мови «Аналітик» для ЕОМ «МИР-2». В даний час реалізація програмних систем здійснюється в ПРОЛОГ- або РЕФАЛ-машинах.