Моделирование экспертной системы

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

Применение сетевой объектно-ориентированной базы знаний в моделировании экспертной системы на основе семантической нейронной сети

Описана реализация продукционной экспертной системы, база знаний которой выполнена на основе семантической нейронной сети. Описана реализация семантической нейронной сети на основе сетевой объектно-ориентированной базы данных. Описана реализация сетевой объектно-ориентированной базы данных в среде Microsoft .NET Framework 1.1

Возможности и архитектура системы

Основная цель данной разработки - создать виртуальную машину, поддерживающую нейронные сети со свободной топологией и числом нейронов до 2 млрд в одном хранилище. Данная возможность обеспечивается путем реализации системы управления сетевой объектно-ориентированной базы знаний (СООБЗ). Текущая версия СООБЗ Cerebrum представляет собой однопользовательскую файловую (desktop) базу. Поддерживаются однопользовательские одноуровневые транзакции. Во время транзакции файловое хранилище отключается, и все изменения объектов накапливаются в оперативной памяти. В будущем предполагается реализации поддержки иерархических транзакций, блокировок объектов, управление версиями (versioning) объектов, конкурентного доступа, многопользовательского режима и клиент-серверной архитектуры.

Система управления сетевой объектно-ориентированной базой знаний обладает следующими возможностями:

• Сохранять текущее состояние графа объектов или нейронной сети в СООБЗ между сеансами работы с  пользователем. В том числе сохраняется текущая топология сети объектов. При  повторном запуске приложения не понадобится создавать сеть объектов заново.
• При большем количестве экземпляров объектов ограничить объем памяти, используемый графом объектов или нейронной сетью. Наиболее часто используемые объекты остаются в оперативной памяти, остальные вытесняются в файловое хранилище и загружаются в оперативную память по мере необходимости. При загрузке экземпляра в оперативную память он вытесняет другие, редко используемые объекты.
• Ограничение объема памяти позволяет избавиться от использования файла подкачки операционной системы, что значительно повышает производительность моделирования сетей с большим количеством экземпляров объектов (при суммарном размере всех экземпляров большем, чем размер текущей свободной памяти в системе). В случае, если объем сети объектов меньше чем размер текущей свободной памяти в системе, вся сеть находится в оперативной памяти и потерь производительности, связанных с сериализацией-десериализацией .не возникает.
• Применение СООБЗ не накладывает никаких ограничений на используемую бизнес логику или математическую модель нейрона, которую можно реализовать как методы объектов, находящихся в СООБЗ. Основное требование - организовать связи между объектами в сети не с помощью указателей, а с помощью ID объектов.

Уровень ядра VNPI – хранение и управление временем жизни объектов

Ядро системы включает в себя уровень взаимодействия с операционной системой и уровень хранения и управления объектами. Уровень взаимодействия с операционной системой должен обеспечить адаптацию функций операционной системы к нуждам виртуальной машины, реализующей нейронную сеть. Уровень хранения объектов должен обеспечить хранение и быстрый доступ к объектам и их связям, а также управление временем жизни объектов. Совокупность API всех уровней виртуальной машины, для определенности, названа Virtual Neural Programming Interface, далее VNPI.

К эффективности языка реализации ядра виртуальной машины, эмулирующей нейронную сеть со многими миллионами эмулируемых нейронов, предъявляются повышенные требования. Ядро необходимо разработать учитывая современные компонентные технологии. Ядро VNPI предоставляет компоненты базового уровня для реализации объектно-сетевой базы. Оно включает в себя компоненты взаимодействия с операционной системой, управления памятью с подсистемой сборки мусора, управления структурированным хранилищем объектов,  подсистему кэширования объектами и управления их временем жизни в оперативной памяти.

Уровень моста .NET-VNPI

Уровень реализации пользовательских объектов должен быть удобным для использования прикладными программистами. На данный момент этому требованию наиболее полно соответствует Microsoft .NET Framework. Для обеспечения интеграции .NET Framework и ядра VNPI необходим мост VNPI - .NET. Мост VNPI - .NET обеспечивает доступ к VNPI из среды .NET Framework. Он так же позволяет реализовывать объекты в среде .NET управляемые подсистемами ядра VNPI.

Учитывая различные цели и требования стоящие перед .NET Framework и VNPI идеология системы сборки мусора кардинально отличается. Так в .NET уничтожение объекта возможно только после того как не останется возможности его использования в текущем процессе. В отличие от этого в ядре VNPI сборка мусора осуществляется, когда исчерпана память допустимая для размещения объектов. В этом случае ненужные объекты вытесняются на устройство долговременного хранения. Уничтожение объектов является частью модели предметной области и поэтому выполняется только в ручную. Мост осуществляет подсчет ссылок на объекты ядра VNPI используемые .NET и препятствует вытеснению объектов, которые могут быть доступны через обращения из контекста .NET

В системе реализована собственная версия Garbage Collector с альтернативным алгоритмом выполнения. Когда память исчерпывается, самые старые объекты вытесняются на диск, освобождая место более нужным в данный момент. Таким образом, объекты, которые находятся в использовании, нужно защищать от принудительной выгрузки из оперативной памяти. Если не выполнить блокировку, то объект может быть разрушен в памяти еще до момента окончания его модификации. Об этом говорит сайт https://intellect.icu . Типичный прецедент вызова метода у пользовательского объекта выглядит следующим образом:

• NativeHandle someObjectHandle = ...;
• IConnector someConnector = ...;
• using(IContainer container = someConnector.GetContainer() as IContainer)
• {
• using(IConnector connector
• = container.AttachConnector(someObjectHandle))
• {
• (connector.Component as CMyType).MyMethod();
• }
• }

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

Уровень сетевой объектно-ориентированной базы

Уровень сетевой объектно-ориентированной базы отвечает за создание экземпляров пользовательских объектов, а так же за работу с атрибутами объектов. Каждый объект сетевой объектно-ориентированной базы может иметь несколько атрибутов. В качестве значений атрибутов могут выступать другие объекты или простейшие (скалярные) типы данных. Однотипные экземпляры объектов (с совместимыми наборами атрибутов) удобно представлять таблицами и управлять ими с помощью интерфейса пользователя ориентированного на обработку таблиц. Однотипные объекты имеют одинаковый набор атрибутов. Поэтому возможно представить коллекции однотипных объектов в виде таблицы, в которой сроки являются объектами, а колонки - атрибутами этих объектов.

Для создания объектов необходимо иметь информацию об их типах. Средствами сетевой объектно-ориентированной базы можно реализовать табличную структуру, близкую к структуре реляционной базы данных. Поэтому, для унификации информации о типах объектов, используемая этим уровнем, организованна в виде связанных друг с другом таблиц. Информация об объектах зарегистрированных в системе организована в виде нескольких таблиц Types, Attributes, Tables. Это позволяет определять в БД типы объектов .NET в унифицированном виде. Однако, свойства таблиц, строк и колонок в ОО базе отличаются от свойств, принятых в реляционных базах данных. Объектно-ориентированная база позволяет хранить не строки таблиц, как это принято в табличных базах данных, а экземпляры объектов. В пространстве имен Cerebrum.Reflection этим таблицам соответствуют классы TypeDescriptor, AttributeDescriptor, TableDescriptor. Класс MemberDescriptor представляет собой базовый класс, от которого унаследованы классы TypeDescriptor, AttributeDescriptor, TableDescriptor.

• public class MemberDescriptor : Cerebrum.Integrator.GenericComponent
• {
• public string Name
• public string DisplayName
• public string Description
• }

где Name - имя экземпляра; DisplayName - дружественное имя экземпляра предъявляемое пользователю; Description - описание данного экземпляра. MemberDescriptor - это базовый класс для классов которые обладают атрибутами имя, дружественное имя и описание. Многие объекты могут иметь такие атрибуты, поэтому удобно наследовать такие объекты от MemberDescriptor.

Колонка таблицы представляет собой сущность, отдельную и независимую от таблицы. Одна и та же колонка может принадлежать разным таблицам. Колонка таблицы описывает некоторый атрибут объекта. Таблица Attributes содержит информацию об атрибутах объектов, находящихся в сетевой объектно-ориентированной базе. Эта таблица содержит экземпляры класса AttributeDescriptor. Дескриптор атрибута описывает имя некоторого атрибута объекта. Он расширяет объект MemberDescriptor добавляя свойства AttributeType, AttributeTypeHandle а также метод GetTypeDescriptor().

• public class AttributeDescriptor : MemberDescriptor
• {
• public Cerebrum.Runtime.NativeHandle AttributeTypeHandle
• public System.Type AttributeType
• public Cerebrum.Runtime.IConnector GetTypeDescriptor()
• }

где AttributeType возвращает тип данного атрибута; AttributeTypeHandle возвращает handle типа; GetTypeDescriptor() возвращает объект-дескриптор типа данного атрибута. Если в базе находится несколько объектов, которые имеют атрибут имя, то значениями для этого атрибута (колонки) являются имена этих объектов. Атрибуты (колонки) так же являются объектами ООБД. Например, объект-атрибут "Object name" так же имеет имя, так как класс AttributeDescriptor унаследован от класса MemberDescriptor. Очевидно что, значением атрибута "Object Name" для экземпляра класса AttributeDescriptor, описывающего имя объекта является строка "Object name".

Рассмотрим пример. Для свойства Name объекта MemberDescriptor в ООБД создается экземпляр объекта AttributeDescriptor с значениями свойств соответственно:

• Name = “Name”;
• DisplayName = “Name”;
• Description = “Object name”;
• AttributeType = typeof(System.String);
• GetTypeDescriptor() = экземпляр TypeDescriptor описывающий System.String.

Таким образом экземпляры класса AttributeDescriptor описывают свойства объектов, хранимых в ООБД, в том числе и свойства собственно класса AttributeDescriptor. Таблица Types содержит описание типов данных (включая пользовательские), которые известны системе и на основе которых система создает экземпляры объектов, помещаемые в сетевую базу. Эта таблица содержит экземпляры классов TypeDescriptor.

• public class TypeDescriptor : MemberDescriptor
• {
• public string QualifiedTypeName
• public Cerebrum.Runtime.KernelObjectClass KernelObjectClass
• public System.Type ComponentType
• }

где QualifiedTypeName - возвращает имя .NET класса на основе которого создаются пользовательские объекты, например “System.String” ; KernelObjectClass - возвращает тип объекта ядра VNPI ассоциированного с экземплярами описываемого типа; ComponentType - возвращает typeof(QualifiedTypeName) тоесть .NET тип описываемый дескриптором. Свойства, унаследованные от MemberDescriptor были описаны ранее. Рассмотрим пример. Для свойства QualifiedTypeName создается экземпляр AttributeDescriptor у которого

• Name = “QualifiedTypeName”
• DisplayName = “Qualified Type Name”
• Description = “.NET Qualified Type Name”
• AttributeType = typeof(System.String)
• GetTypeDescriptor() = экземпляр TypeDescriptor описывающий System.String

Данная структура позволяет описывать типы классов объектов, содержащиеся в ООБД. Описатели типов также являются объектами, содержащимися в ООБД. Поэтому описатели типов описывают сами себя.

Каждая таблица имеет две коллекции указателей на объекты. Коллекцию атрибутов (колонок) и коллекцию компонентов (строк). Каждая строка любой таблицы это тоже объект. Если в коллекцию указателей на строки включить указатель на саму таблицу, то таблица станет собственной строкой. Таблица Tables содержит сама себя в качестве строки. И таблица Tables и строка Tables в таблице Tables - это один и тот же экземпляр одного и того же класса TableDescriptor. Этот экземпляр расположен по одному и тому же адресу в памяти. Значениями для колонок таблицы являются значения атрибутов объектов находящихся в строках таблицы. А значением ее колонки "SelectedAttributes" является коллекция колонок этой же таблицы. Хотя желательно держать в одной и той же таблице объекты одного и того же типа - это вовсе не обязательно. Главное чтоб у этих объектов были атрибуты, хотя бы частично совпадающие с колонками данной таблицы. Я рекомендую держать в одной таблице объекты, классы которых унаследованы от некоторого, базового класса, который содержит все колонки данной таблицы в качестве собственных атрибутов. Например колонка "Object name" имеет смыл практически в любой таблице. Объекты могут входить одновременно в разные таблицы как их строки. Дескрипторы атрибутов объектов сами являются объектами и зарегистрированы в таблице атрибутов. Класс TableDescriptor описывает таблицу из экземпляров некоторых объектов. Свойства, унаследованные от MemberDescriptor соответсвенно описывают имя, дружественное имя и описание данной таблицы.

• public class TableDescriptor : MemberDescriptor, System.ComponentModel.IListSource
• {
• public Cerebrum.Runtime.NativeVector GetSelectedAttributesVector()
• public Cerebrum.Runtime.NativeVector GetSelectedComponentsVector()
• public System.Type ComponentType
• }

где GetSelectedAttributesVector - метод возвращает коллекцию атрибутов таблицы; GetSelectedComponentsVector - метод возвращает коллекцию строк таблицы; ComponentType - свойство возвращает тип объектов содержащихся в строках таблицы.Методу GetSelectedAttributesVector соответствует экземпляр AttributeDescriptor укоторого

• Name = “SelectedAttributes”
• DisplayName = “SelectedAttributes”
• Description = “SelectedAttributes collection”
• AttributeType = typeof(System.ComponentModel.IBindingList)

Метод GetSelectedComponentsVector возвращает коллекцию объектов - строк, этомуметоду соответсвует экземпляр AttributeDescriptor у которого

• Name = “SelectedComponents”
• DisplayName = “SelectedComponents”
• Description = “SelectedComponentscollection”
• AttributeType = typeof(System.ComponentModel.IBindingList)

Все экземпляры AttributeDescriptor перечислинны в таблице TableDescriptor.Name = “Attributes”. Все экземпляры TypeDescriptor перечислинны в таблицеTableDescriptor.Name = “Types”. Все экземпляры TableDescriptor перечислинны втаблице TableDescriptor.Name = “Tables”. При этом экземпляр классаAttributeDescriptor.Name = “Name” содержится в коллекции строк таблицы Attributes, атак же в коллекциях атрибутов (колонок) таблиц “Attributes”, “Types” и “Tables”.Экземпляр класса TableDescriptor.Name = “Tables” хранится в своей же коллекции строктаблицы (SelectedComponents). Следовательно, применение тавтологии для эмуляции РБД на основе ООБД является оправданным и полезным. Надо заметить, что экземпляры объектов могут одновременно входить в разные таблицы при этом важно, чтоб они поддерживали все атрибуты, являющиеся колонками таблиц в которые они входят в качестве строк.

Пользователь имеет возможность создавать новые таблицы путем добавления новых записей в таблицу Tables. Созданные экземпляры таблиц, атрибутов и других объектов так же не обязательно регистрировать в соответствующих таблицах. Однако практика регистрации таких объектов в соответствующих таблицах является рекомендуемой, так как позволяет изменять их атрибуты через унифицированный интерфейс пользователя. Обязательным требованием является регистрация пользовательского типа в таблице Types. В этом случае Integrator.Acivator при необходимости автоматически произведет создание нового экземпляра. В противном случае программист будет обязан реализовать собственную версию интерфейса IActivator.

В ООБД поддерживаются полноценные C# объекты, у объектов поддерживаются методы, свойства, поля и события. В данной разработке статические методы классов - просто обычные статические методы в .NET а экземплярные методы - обычные методы объектов. Рекомендуется создавать свойства для поддерживаемых классом атрибутов. Механизм делегатов и событий не будет поддерживаться, в случае если связь реализуется между объектами, хранящимися в БД. Это связанно с ограничениями по времени жизни экземпляров. Во время, когда БД остановлена, все объекты хранятся в сериализированном (serialized) виде. Если время жизни у приемников или источников сообщений может быть изолированно от времени жизни объектов БД, то механизмы делегатов - сообщений работают в пределах подсети объектов развернутых в памяти .NET Framework. Система разрабатывается в первую очередь для поддержки нейронных сетей со свободной топологией и числом нейронов до 2 млрд в одном хранилище. Поэтому только часть ОО БД находится в данный момент в RAM. Большая часть объектов заморожена в файловом хранилище и десериализируется (deserializing) по мере необходимости.

Уровень семантической нейронной сети

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

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