База знаний рассматриваемого примера следующая:

  BadElecSys:

  IF    car:SparkPlugCondition #= Bad Or

      car:Timing #= OutOfSynch Or

      car:Battery #= Low;

  THEN car:ElectricalSystem = Bad;

  GoodElecSys:

  IF    car:SparkPlugCondition #= Ok And

      car:Timing #= InSynch And

      car:Battery #= Charged;

  THEN car:ElectricalSystem = Ok;

  BadEngineSys:

  IF    car:IgnitionKey #= Off Or

      car:GasSystem #= Bad Or

      car:ElectricalSystem #= Bad;

  THEN car:Status = Stopped;

  GoodEngSys:

  IF    car:IgnitionKey #= On And

      car:GasSystem #= Ok And

      car:ElectricalSystem #= Ok;

  THEN car:Status = Running;

  BrighLights:

  IF    car:LightSwitch #= On And

      car:Battery #= Charged;

  THEN car:LightsAppearance = Bright;

  DimLights:

  IF    car:LightSwitch #= On And

      car:Battery #= Low;

  THEN car:LightsAppearance = Dim;

  BriskTurnover:

  IF    car:IgnitionKey #= On And

      car:ElectricalSystem #= Low;

  THEN car:EngineTurnover = Brisk;

  SluggishTurnover:

  IF    car:IgnitionKey #= On And

      car:ElectricalSystem #= Bad;

  THEN car:EngineTurnover = Sluggish; 

  В процессе прямого вывода правило, у которого составной факт в левой части примет значение ИСТИНА, добавляется в список правил в соответствии с его приоритетом. Строго говоря, оценка истинности или ложности проводится, когда правило уже находится в списке правил. Как только левая часть правила получит значение ИСТИНА, другие правила из списка правил удаляются. Agenda должна быть пуста перед тем, как следующее правило из списка правил начнет проверяться.

  Текущая база фактов:

  car:Battery = Charged; car:ElectricalSystem=NULL

  car:EngineTurnover=NULL; car:IgnitionKey=On

  car:LightsAppearance=NULL; car:LightSwitch=On; car:GasSystem #= Ok;

  car:Status=NULL; car:SparkPlugCondition#=Ok; car:Timing #= InSynch.

  Assert(сar, Battery); — команда начала поиска решения. 

  При выполнении этой команды сar:Battery помещается в Agenda и проверяются левые части правил базы знаний. 

 

  Проверяется на соответствие с левыми частями  правил пара Car:Battery, и добавляются в список правил те из них, у которых совпадение установлено по одному из элементарных фактов: 

 

  Проверяется правило BadElecSys. Результат проверки FALSE. Правило удаляется из списка правил. 

 

  Проверяется правило GoodElecSys. Результат проверки TRUE. Правило применяется, т. е. выполняются действия из его правой части. Это вносит изменения в базу фактов — слот в паре Car:ElectricalSystem принимает значение Oк. Пара Car:ElectricalSystem добавляется в Agenda. Список правил очищается. 

 

  Оцениваются и добавляются в список правил те правила, у которых один из элементарных фактов включает пару Car:ElectricalSystem. 

 

  Проверяется правило BadEngineSys. Результат FALSE. Правило удаляется из списка правил. 

 

  Поверяется  правило GoodEngSys, Результат TRUE. Правило применяется (выполняются действия из его правой части), Car:Status принимает значение Running. Вывод закончен.

  В результате рассмотренного процесса ИСУ вырабатывает следующую информацию:

      Car:ElectricalStatus = Oк;

      Car:Status = Running.

      «Проблем  в электрической системе автомобиля нет,

      разрешен  запуск автомобиля».

  Разработка  ЭС имеет существенные отличия от разработки обычного программного продукта. При разработке ЭС, как правило, используется концепция «быстрого прототипа». Суть этой концепции состоит в том, что разработчики не пытаются сразу построить конечный продукт. На начальном этапе они создают прототип (прототипы) ЭС, который должен продемонстрировать пригодность методов инженерии знаний для данного приложения (или для решения данной задачи). В случае успеха эксперт с помощью инженера по знаниям расширяет знания прототипа о проблемной области. При неудаче может потребоваться разработка нового прототипа или разработчики могут прийти к выводу о непригодности методов ЭС для данного приложения. По мере увеличения знаний прототип может достигнуть такого состояния, когда он успешно решает все задачи данного приложения. Преобразование прототипа ЭС в конечный продукт обычно приводит к перепрограммированию ЭС на языках низкого уровня, обеспечивающих как увеличение быстродействия ЭС, так и уменьшение требуемой памяти. Трудоемкость и время создания ЭС в значительной степени зависят от типа используемого инструментария. В ходе работ по созданию ЭС сложилась определенная технология их разработки, включающая шесть следующих этапов (рис. 33): идентификацию, концептуализацию, формализацию, выполнение, тестирование, опытную эксплуатацию.  

 

 
 

 

Рис. 33. Технология разработки ЭС 

  На этапе  идентификации определяются задачи, которые подлежат решению, выявляются цели разработки, определяются эксперты и типы пользователей.

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

  На этапе  формализации определяются способы представления всех видов знаний, формализуются основные понятия, определяются способы интерпретации знаний, моделируется работа системы, оценивается адекватность целям системы зафиксированных понятий, методов решений, средств представления и манипулирования знаниями.

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

     Нечеткая  логика.

     Математическая  теория нечетких множеств (fuzzy sets) и нечеткая логика (fuzzy logic) являются обобщениями классической теории множеств и классической формальной логики. Данные понятия были впервые предложены американским ученым Лотфи Заде (Lotfi Zadeh) в 1965 г. Основной причиной появления новой теории стало наличие нечетких и приближенных рассуждений при описании человеком процессов, систем, объектов.

  Одной из основных характеристик нечеткой логики является лингвистическая переменная, которая определяется набором вербальных (словесных) характеристик некоторого свойства. Рассмотрим лингвистическую переменную «скорость», которую можно характеризовать через набор следующих понятий-значений: «малая», «средняя» и «большая», данные значения называются термами.

     

  Следующей основополагающей характеристикой нечеткой логики является понятие функции принадлежности. Функция принадлежности определяет, насколько мы уверены в том, что данное значение лингвистической переменной (например, скорость) можно отнести к соответствующим ей категориям (в частности для лингвистической переменной скорость к категориям «малая», «средняя», «большая»).

  На  следующем рисунке (первая часть) отражено, как одни и те же значения лингвистической переменной могут соответствовать различным понятиям-значениям или термам. Тогда функции принадлежности, характеризующие нечеткие множества понятий скорости, можно выразить графически, в более привычном математическом виде (рис. 35, вторая часть).

     

  Из рисунка видно, что степень, с которой численное значение скорости, например v = 53, совместимо с понятием «большая», есть 0,7, в то время как совместимость значений скорости, равных 48 и 45, с тем же понятием есть 0,5 и 0,1 соответственно.

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

  Треугольная функция принадлежности определяется тройкой чисел (a,b,c), и ее значение в точке x вычисляется согласно выражению:

     При (b-a)=(c-b) имеем случай симметричной треугольной функции принадлежности, которая может быть однозначно задана двумя параметрами из тройки (a,b,c).

     Аналогично  для задания трапецеидальной  функции принадлежности необходима четверка чисел (a,b,c,d):

При (b-a)=(d-c) трапецеидальная  функция принадлежности принимает  симметричный вид.

 
Рисунок 1. Типовые кусочно-линейные функции принадлежности.

Функция принадлежности гауссова типа описывается формулой

и оперирует  двумя параметрами. Параметр c обозначает центр нечеткого множества, а параметр отвечает за крутизну функции.

 
Рисунок 2. Гауссова функция принадлежности.

Совокупность  функций принадлежности для каждого  терма из базового терм-множества T обычно изображаются вместе на одном  графике. На рисунке  приведен пример описанной лингвистической переменной "Цена акции".

 
Рис. Описание лингвистической переменной "Цена акции".

     Количество  термов в лингвистической переменной редко превышает 7.