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

Добре побудована ЭС має можливість самонавчатися на розв'язуваних задачах, поповнюючи автоматично свою БЗ результатами отриманих висновків і рішень.

6.   Відмінність експертних систем від традиційних програм

Особливості ЭС, що відрізняють їх від звичайних програм, полягають у тім, що вони повинні володіти:

1. Компетентністю, а саме:

?     Досягати експертного рівня рішень (тобто в конкретній предметній області мати той же рівень професіоналізму, що й експерти-люди).

?     Мати активну працездатність (тобто застосовувати знання ефективно і швидко, уникаючи, як і люди, непотрібних обчислень).

?     Мати адекватну працездатність (тобто здатність лише поступово знижувати якість роботи з міри наближення до границь діапазону компетентності або припустимої надійності даних).

2. Можливістю до символьних міркувань, а саме:

?     Представляти знання в символьному виді

?     Переформулювати символьні знання. На жаргоні штучного інтелекту символ — це рядок знаків, що відповідає змісту деякого поняття. Символи поєднують, щоб виразити відносини між ними. Коли відносини представлені в ЭС вони називаються символьними структурами.

3. Глибиною, а саме:

?     Працювати в предметній області, що містить важкі задачі

?     Використовувати складні правила (тобто використовувати або складні конструкції правил, або велику їхню кількість)

4. Самосвідомістю, а саме:

?     Досліджувати свої міркування (тобто перевіряти їхня правильність)

?     Пояснювати свої дії

Існує ще одна важлива відмінність ЭС. Якщо звичайні програми розробляються так, щоб щораз породжувати правильний результат, то ЭС розроблені для того, щоб поводитися як експерти. Вони, як правило, дають правильні відповіді, але іноді, як і люди, здатні помилятися.

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

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

Технологія їхньої розробки ЭС, містить у собі шість етапів (мал.5): етапи ідентифікації, концептуалізації, формалізації, виконання, тестування, досвідченої експлуатації. Розглянемо більш докладно послідовності дій, які необхідно виконати на кожнім з етапів.

1)  На етапі ідентифікації необхідно виконати наступні дії:

?     визначення задачі, що підлягають рішенню і меті розробки,

?     визначення експертів і типу користувачів.

2)  На етапі концептуалізації:

?     проводиться змістовний аналіз предметної області,

?     виділяються основні поняття і їхні взаємозв'язки,

?     визначаються методи рішення задач.

3)  На етапі формалізації:

?     вибираються програмні засоби розробки ЭС,

?     визначаються способи представлення усіх видів знань,

?     формалізуються основні поняття.

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

?     на "витяг" знань з експерта,

?     на організацію знань, що забезпечує ефективну роботу ЭС,

?     на представлення знань у виді, зрозумілому для ЭС.

Процес придбання знань здійснюється інженером по знаннях на основі діяльності експерта.

5)  На етапі тестування експерт і інженер по знаннях з використанням діалогових і пояснювальних засобів перевіряють компетентність ЭС. Процес тестування продовжується доти, поки експерт не вирішить, що система досягла необхідного рівня компетентності.

6)  На етапі досвідченої експлуатації перевіряється придатність ЭС для кінцевих користувачів. За результатами цього етапу можлива істотна модернізація ЭС.

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

Висновки

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

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

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

При розробці експертної системи прийнято поділяти її на три основних модулі:

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

Машина логічного висновку вміє активно використовувати інформацію, що міститься в базі знань.

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

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

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