Прототип повинен продемонструвати придатність методів інженерії знань для даного додатку. У разі успіху експерт за допомогою інженера по знаннях розширює знання прототипу про проблемну область. При невдачі може бути потрібно розробка нового прототипу або розробники можуть прийти до висновку про непридатність методів ЕС для даного додатку. У міру збільшення знань прототип може досягти такого стану, коли він успішно вирішує всі задачі даного додатку [6, c.14].
Оскільки процес проектування ЕС відпрацьований недостатньо, слід мати на увазі, що розробка конкретних систем може мати свої особливості. Ціль — виділити основні проблеми проектування, з якими стикалися розробники експертних систем за п'ятнадцятирічну історію їх існування.
Перш ніж перейти до розгляду окремих етапів розробки ЕС, перерахуємо спеціальності учасників даного процесу: експерт в тій проблемній області, задачі якої вирішуватиме ЕС; інженер по знаннях — фахівець по розробці ЕС; програміст, здійснюючий модифікацію і узгодження інструментальних засобів. Звичайно в розробці ЕС бере участь не менше чотирьох чоловік (1 експерт, 2 інженера по знаннях і 1 програміст). Необхідно особливо підкреслити, що відсутність серед учасників інженера по знаннях (тобто заміна їх програмістами) або приводить до невдачі процесу розробки ЕС, або значно подовжує цей процес.
Перейдемо до етапів побудови ЕС. На етапі ідентифікації розв'язуються наступні задачі: визначаються учасники процесу проектування і їх ролі, ідентифікується проблема, визначаються ресурси і цілі. Задача визначення учасників і їх ролей зводиться до визначення кількості експертів і інженерів по знаннях, а також форми їх взаємостосунків (наприклад, експерт може виступати або в ролі вчителя, або в ролі інформуючого). На цьому ж етапі визначаються джерела знань (книги і інструкції). Ідентифікація проблеми полягає в складанні неформального (вербального) опису вирішуваної проблеми. В цьому описі указуються загальні характеристики проблеми; підпроблеми, що виділяються усередині даної проблеми; ключові поняття і відносини: вхідні дані; гаданий вид рішення; знання, релевантні вирішуваний проблеми. Якщо початкова проблема виявляється дуже складною з погляду ресурсів, що є, то етап ідентифікації може зажадати декілька ітерацій.
При проектуванні експертної системи типовими ресурсами є: джерела знань, час розробки, обчислювальні засоби і об'єм фінансування. При визначенні ресурсів необхідно мати на увазі, що терміни розробки і упровадження експертної системи складають. Задача визначення ресурсів є вельми важливою, оскільки обмеженість якого-небудь ресурсу істотно впливає на процес проектування [6, c.15].
На етапі концептуалізації експерт і інженер по знаннях використовують ключові поняття, відносини (згадані на етапі ідентифікації) і характеристики, необхідні для опису процесу рішення проблеми. На цьому етапі визначаються наступні особливості проблеми: типи доступних даних; дані, що виводяться; підпроблеми загальної проблеми; стратегії, що використовуються, і гіпотези; види взаємозв'язків між об'єктами області; типи відносин, що використовуються; типи обмежень, що накладаються на процес рішення; склад знань, що використовуються для отримання і обгрунтовування рішення. Досвід показує, що для визначення перерахованих характеристик проблеми доцільно скласти детальний протокол дій і міркувань експерта в процесі рішення хоча б однієї конкретної задачі. Такий протокол забезпечує інженера по знаннях словником термінів і деяким приблизним уявленням про ті стратегії, які використовує експерт. Крім того, протокол допомагає відповісти на багато інших питань, виникаючих в ході розробки. На цьому етапі інженер по знаннях розглядає деякі питання, що відносяться до представлення знань і методів рішення, але говорити про вибір конкретних чинів і методів тут ще рано.
На етапі формалізації всі ключові поняття і відносини, введені на етапі концептуалізації виражаються на деякій формальній мові, запропонованій інженером по знаннях. Тут він визначає, чи підходять інструментальні засоби, що є, для вирішення проблеми, що розглядається необхідні оригінальні розробки. Виходом етапу формалізації є опис процесу рішення проблеми, що розглядається, на запропонованій формальній мові, тобто на даному етапі визначається склад і способи представлення декларативних і процедурних знань системи [6, c.17].
Процес формалізації залежить від трьох основних чинників: структури простору пошуку, характеризуючої особливості вирішуваний задача; моделі, лежачої в основі проблеми; властивостей даних проблеми, що розглядається.
Важливим кроком в процесі формалізації знань є побудова моделі досліджуваної проблеми, оскільки саме знання моделі дозволяє генерувати рішення. Якщо в процесі міркувань і аргументування експерт використовує хоча б найпростішу модель, то аналіз цієї моделі дозволить виробити важливі поняття багато кого і відносини.
Задача етапу виконання полягає в створенні одного або декількох прототипів ЕС, вирішальних задачі, що вимагаються. Потім за наслідками етапів тестування і досвідченої експлуатації на даному етапі створюється кінцевий продукт, придатний для промислового використовування. Розробка прототипу полягає в програмуванні його компонентів. Звичайна помилка розробників при створенні прототипу полягає в тому, що процес придбання знань відкладають до повного завершення програмування. Тим самим, по-перше, ця сама трудомістка частина роботи відсовується на пізні етапи, і, по-друге, в процесі накопичення знань доводиться вносити зміни у вже готові програми. Тому необхідно починати придбання знань, як тільки складена програми, дозволяючи працювати з найпростішим представленням знань і з найпростішими управляючими структурами. Такий підхід дозволяє максимально рано почати виконання окремих підзадач і знайти, що у ряді випадків для їх вирішення необхідне додаткові знання. Іншими словами, перший прототип експертної системи (ЕС-1) повинен з'явитися через декілька місяців, а не через роки після початку роботи.
Створення першого прототипу повинне підтвердити, що вибрані методи рішень і способи уявлення придатні для успішного вирішення принаймні ряду задач з області експертизи. Після завершення першого прототипу необхідно розширити коло задач, вирішуваних системою, для того, щоб зібрати побажання і зауваження, які будуть враховані в черговій версії системи (ЕС-2). Для отримання вказаної інформації необхідно розвинути версію ЕС-1, шляхом додавання в неї засобів для збору зауважень користувачів (без участі інженера по знанням), і средств зберігання бібліотеки задач, вирішених системою [6, c.18].
Для досягнення ефективного функціонування експертної системи необхідно здійснити структуризацію знань. Найважливішим засобом для структуризації знань є абстрактні поняття проміжного рівня. У багатьох випадках ці поняття можуть явно не згадуватися (а можливо, і не усвідомлюватися) експертом. Задача інженера по знаннях — виділити такі поняття, знайшовши схожі дії експерта при обробці різних ситуацій.
В ході етапу тестування здійснюється оцінка вибраного способу представлення знань і всієї системи в цілому. Як тільки система виявляється в змозі обробити від початку до кінця два або три приклади, необхідно починати перевірку на більш широкому крузі прикладів для того, щоб визначити недоліки бази знань і управляючого механізму (процедур виведення). Задача інженера по знаннях полягає в підборі прикладів, забезпечуючих усесторонню перевірку експертної системи. Звичайно виділяють наступні джерела невдач в роботі системи: тестові приклади: введення/виведення: правила виведення; управляючі стратегії.
Найочевиднішою причиною невдалої роботи системи є недостатньо показові тестові приклади. У гіршому разі тестові приклади можуть виявитися взагалі зовні проблемної області, на яку розрахована ЕС, проте частіше безліч тестових прикладів знаходиться в проблемній області, що розглядається, але є однорідним і не дозволяє охопити всю проблемну область.
На етапі досвідченої експлуатації перевіряється придатність експертної системи для кінцевого користувача. Тут система займається рішенням всіх можливих задач при роботі з різними користувачами. Доцільно організувати роботу системи не на стенді розробника, а на місці роботи користувачів. До цього етапу слід переходити лише після того, як система, на думку експерта, успішно вирішуватиме практично всі задачі, що вимагаються, щоб помилки в рішеннях не створювали у користувача негативне уявлення про систему [6, c.21]. Придатність системи для користувача визначається в основному зручністю роботи з нею і її корисністю. Під корисністю системи розуміється здатність системи в ході діалогу визначити потреби користувача, виявити і усунути причини невдач в роботі і задовольнити потреби користувача (тобто вирішити поставлені задачі). Кажучи іншими словами, користувачу важливо "довести до свідомості" системи свою інформаційну потребу, не дивлячись на можливі помилки, що допускаються їм у зв'язку з недостатнім знанням системи. Звичайно, для користувача важлива також повнота і правильність рішень, але ці характеристики повинні бути є перевірені експертом на попередньому етапі.