Модуль (компонент) пояснення

Як показано на рис. 5, ЕС повинна мати модуль пояснення. Без механізму пояснень користувач не довірятиме отриманим результатам і ЕС не матиме попиту. Призначення модуля пояснень – зробити ЕС „прозорою” для користувача, тобто надати можливість користувачу розуміти логіку дій ЕС, дати надійну гарантію правильності отриманих результатів.

У деяких випадках важливість пояснення для користувача дещо переоцінюють, тому що воно не завжди корисне для нього. Це має місце через природу „інтелекту” ЕС.

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

• Автомобіль заводиться? – Ні.

• Двигун прокручується? – Так.

• Пахне бензином? – Так.

• Порада: Почекайте 5 хвилин і спробуйте завести знову.

• Чому?

• Я застосував правило: якщо автомобіль не заводиться, двигун прокручується і пахне бензином, тоді порада така: „Почекайте 5 хвилин і спробуйте завести знову”.

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

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

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

У той час як пояснення системи інколи не має значення для користувача, для розробника ЕС воно дуже важливе. Пояснення ЕС відіграє ту ж діагностичну роль, як і трасування для звичайних програм. Якщо система поводиться некоректно, експерт може застосувати пояснення для визначення помилкового правила. Інженер із знань застосовує пояснення для кращого настроювання БЗ з метою забезпечити більш реалістичний діалог із користувачем.

Існує чотири типи пояснень, звичайно застосовні в ЕС:

• трасування правил, яке повідомляє про прогрес консультації;

• пояснення того, як система дійшла певного висновку;

• пояснення стосовно того, чому система ставить запитання;

• пояснення щодо того, чому система не дала висновку.