Экспертная модель: Экспертиза промышленной безопасности

Содержание

Представления знаний в интеллектуальных системах, экспертные системы / Хабр

Введение

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

Экскурс в историю экспертных систем

История экспертных систем берет свое начало в 1965 году. Брюс Бучанан и Эдвард Фейгенбаум начали работу над созданием информационной системы для определения структуры химических соединений.

Результатом работы была система под названием Dendral. В основе системы формировалась последовательность правил подобных к «IF – THEN». Информационная система не перестала развиваться и получила множество наследников, таких как ONCOIN – информационная система для диагностики раковых заболеваний, MYCIN – информационная система для диагностики легочных инфекционных заболеваний.

Следующим этапом стали 70-е годы. Период не выделялся особыми разработками. Было создано множество разных прототипов системы Dendral. Примером служит система PROSPECTOR, областью деятельности которой являлась геологические ископаемые и их разведка.

В 80-ых годах появляются профессия – инженер по знаниям. Экспертные системы набирают популярность и выходят на новый этап эволюции интеллектуальных систем. Появились новые медицинские системы INTERNIS, CASNE.

С 90-ых годов развитие интеллектуальных систем приобретает новые и новые методы и особенности. Нововведением становится парадигма проектирования эффективных и перспективных систем. Гибкость, четкость решения поставленных задач дало новое название – мультиагентных систем. Агент – фоновый процесс который действует в целях пользователя. Каждый агент имеет свою цель, «разум» и отвечает за свою область деятельности. Все агенты в совокупности образуют некий интеллект. Агенты вступают в конкуренцию, настраивают отношения, кооперируются, все как у людей.

В 21 век, интеллектуальной системой уже не удивишь никого. Множество фирм внедряет экспертные системы в области своей деятельности.

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

G2 – экспертная система от фирмы Gensym, направленная на работу с динамическими объектами. Особенность этой системы состоит в том, что в нее внедрили распараллеливание процессов мышления, что делает ее быстрее и эффективней.

Структура экспертной системы

1. База знаний

Знания — это правила, законы, закономерности получены в результате профессиональной деятельности в пределах предметной области.

База знаний — база данных содержащая правила вывода и информацию о человеческом опыте и знаниях в некоторой предметной области. Другими словами, это набор таких закономерностей, которые устанавливают связи между вводимой и выводимой информацией.

2. Данные

Данные — это совокупность фактов и идей представленных в формализованном виде.

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

3. Модель представления данных

Самая интересная часть экспертной системы.

Модель представления знаний (далее по тексту — МПЗ) — это способ задания знаний для хранения, удобного доступа и взаимодействия с ними, который подходит под задачу интеллектуальной системы.

4. Механизм логического вывода данных(Подсистема вывода)

Механизм логического вывода(далее по тексту — МЛВ) данных выполняет анализ и проделывает работу по получению новых знаний исходя из сопоставления исходных данных из базы данных и правил из базы знаний. Механизм логического вывода в структуре интеллектуальной системы занимает наиболее важное место.

Механизм логического вывода данных концептуально можно представить в виде <A,B,C,D>:

А — функция выбора из базы знаний и из базы данных закономерностей и фактов соответственно

B — функция проверки правил, результатом которой определяется множество фактов из базы данных к которым применимы правила

С — функция, которая определяет порядок применения правил, если в результате правила указаны одинаковые факты

D — функция, которая применяет действие.

Какие существуют модели представления знаний?

Распространены четыре основных МПЗ:

Продукционная МПЗ

Семантическая сеть МПЗ

Фреймовая МПЗ

Формально логическая МПЗ

Продукционная МПЗ

В основе продукционной модели представления знаний находится конструктивная часть, продукция(правило):
IF <условие>, THEN <действие>

Продукция состоит из двух частей: условие — антецендент, действие — консеквент. Условия можно сочетать с помощью логических функций AND, OR.

Антецеденты и консеквенты составленных правил формируются из атрибутов и значений. Пример: IF температура реактора подымается THEN добавить стержни в реактор

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

Пример

Диагноз	Температура	Давление	Кашель
Грипп	39	100-120	Есть
Бронхит	40	110-130	Есть
Аллергия	38	120-130	Нет

Пример продукции:
IF Температура = 39 AND Кашель = Есть AND Давление = 110-130 THEN Бронхит

Продукционная модель представления знаний нашла широкое применение в АСУТП

Среды разработки продукционных систем(CLIPS)

CLIPS (C Language Integrated Production System) — среда разработки продукционной модели разработана NASA в 1984 году. Среда реализована на языке С, именно потому является быстрой и эффективной.

Пример:

(defrule bronchitis    // deftule зарезервированное слово, которое вводит новое правило за ним следует название правила
(symptoms (temperature 39) (cough true)(pressure "110-130"))  //симптом с температурой 39, наличием кашля, и давлением 110-130
=> (printout t "Диагноз - бронхит" crlf))   //это симптомы бронхита

Подобное правило будет активировано только тогда, когда в базе данных появится факт симптома с подобными параметрами.

Семантическая сеть МПЗ

В основе продукционной модели лежит ориентированный граф. Вершины графа — понятия, дуги — отношения между понятиями.

Особенностью является наличие трех типов отношений:

класс — подкласс

свойство — значение

пример элемента класса

По количеству типов отношений выделяют однородные и неоднородные семантические сети. Однородные имею один тип отношения между всеми понятиями, следовательно, не однородные имею множество типов отношений.

Все типы отношений:

часть — целое

класс — подкласс

элемент — количество

атрибутивный

логический

лингвистический

Пример

Недостатком МПЗ является сложность в извлечении знаний, особенно при большой сети, нужно обходить граф.

Фреймовая МПЗ

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

Слот может хранить другой фрейм, тогда фреймовая модель вырождается в сеть фреймов.

Пример

Пример вырождающейся в сеть фреймов

На своей практике, мне доводилось встречать системы на основе фреймовой МПЗ. В университете в Финляндии была установлена система для управления электроэнергией во всем здании.

Языки разработки фреймовых моделей (Frame Representation Language)

FRL (Frame Representation Language) — технология создана для проектирования интеллектуальных систем на основе фреймовой модели представления знаний. В основном применяется для проектирования вырождающихся в сеть фреймовой модели.

Запись фрейма на языке FRL будет иметь вид:

(frame Room // вводим новый фрейм Room
     (windows (value(4), demon(open))) //Слот windows со значением 4 и демоном open
     (doors (value(1), demon(open))) //Слот doors со значением 1 и демоном open
     (conditioners (value(2), demon(turn on))) //Слот conditioners со значением 2 и демоном turn on
     (sokets (value(10), demon(turn on))) //Слот sokets со значением 10 и демоном turn on
)

Существуют и другие среды: KRL (Knowledge Representation Language), фреймовая оболочка Kappa, PILOT/2.

Формально логическая МПЗ

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

Пример

A1 = <идет дождь> A2 = <небо в тучах> A3 = <солнечно>; IF A1 AND A2 THEN <взять зонтик>

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

Важно

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

Заключение

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

Спасибо за внимание!

Проходим госэкспертизу информационной модели правильно

Рисунок 5 — Свойствам IfcEntityType, IfcObjectType и IfcName заданы нужные значения, поэтому при экспорте у этих объектов будет переопределен Класс, Тип и Имя

Кроме них, в Renga можно переопределять следующие параметры IFC:

IfcTag – Соответствует параметру объекта Марка,

IfcName – Используется для указания короткого имени или номера объекта,

IfcLongName – Используется для указания полного имени объекта,

IfcDescription – Описание объекта.

Это очень мощный инструмент. Единственное, что от Вас требуется – это разобраться в описании классов IFC. Тут Вам понадобится под рукой справочник IFC[9]

II. Настраиваемый экспорт в IFC4

Мы подготовили модель к экспорту и подошли к моменту, когда нам нужно уже нажать кнопку «Экспорт в IFC», но не торопитесь! Далее нам надо будет совершить еще один очень важный шаг – указать Renga по каким наборам свойств/параметров/расчетных характеристик будут выгружаться данные по тому или иному типу объектов.

Сопоставление параметров при экспорте (Маппирование)

Помните иллюстрацию, где мы сравнивали требования к перекрытиям от двух экспертиз (рис. 1)? Мы должны не просто выгрузить заполненные свойства, но и указать в каком наборе они должны находится и под каким именем! Именно это и выполняет функциональность под названием «Маппирование» (mapping), т.е. сопоставление параметров, пользовательских свойств и расчетных характеристик моделей Renga и IFC (рис. 6).

Рисунок 6 — Схема маппинга параметров перекрытия из модели Renga в модель IFC

Каким же образом в Renga происходит маппирование? Все правила описываются в файле сопоставления параметров. При экспорте модели в IFC4, Renga обращается к нему и выполняет экспорт по описанным правилам. Путь к этому файлу указывается в настройках программы в меню «Экспорт» (рис. 7).

Рисунок 7 — Параметра настройки экспорта в IFC4

Мы остаемся приверженцами идеи, что программа должна оставаться инструментом проектировщиков, поэтому не стали нагружать интерфейс техническим функционалом. Описание правил происходит в файле формата JSON. В комплекте с дистрибутивом Renga идёт подготовленный нами файл маппинга – «export_attr_qto_pset.json». Он используется при экспорте по умолчанию и формирует модель IFC по нашим правилам.

Он подойдёт для общих случаев экспорта данных в формат IFC4, но в случае подготовки модели на госэкспертизу необходимо подготовить собственный файл маппинга (по правилам госэкспертизы). Формат JSON широко распространен, поэтому в создании такого файла не возникнет трудности – существует много редакторов. BIM-менеджер может выбрать по своему вкусу.

Описание классов IFC выполняется следующим образом (рис. 8):

Рисунок 8 — Схема описания классов IFC

В наборах описываются параметры по правилу «ключ: значение». «Ключ» – это наименование атрибута модели IFC, в который будет экспортирован атрибут Renga. «Значение» – это наименование атрибута модели Renga, который будет экспортирован в IFC.

Рассмотрим на примере описания объектов «Стена» (IfcWall). Ниже представлена иллюстрация части файла маппинга, созданного по правилам Мосгосэскпертизы, сопоставленная со списком свойств объектов «Стена» модели Renga (Рис. 9)

Рисунок 9 — Фрагмент файла маппинга и свойства стен в Renga. (цветом выделены группы и относящиеся к ним параметры)

Класс IfcWall имеет 3 группы атрибутов: «attributes» (параметры), «psets» (наборы пользовательских свойств) и «qsets» (наборы расчетных характеристик). В «attributes» определены нами 2 параметра: «Имя», которое принимает при экспорте в IFCнаименование «Name», и «Марка», которое принимает при экспорте в IFC наименование «Tag». Параметры определены по правилу «Ключ: значение», т.е. «Tag: Марка». Далее можно расширить список параметров по вашему усмотрению. В группе «psets» определены 2 набора пользовательских свойств: «Pset_WallCommon» и «ExpCheck_Wall», каждый из которых имеет набор атрибутов. Откуда они взялись? Из требований Мосгосэкспертизы [10]. По той же причине в группе «qsets» определен набор расчетных характеристик «Qto_WallBaseQuantities».

На рис. 9 не случайно приведен список свойств модели Renga. При переопределении параметров вы должны брать название такое, какое он имеет в Renga.

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

III. Проверка на ошибки

Журнал ошибок

В процессе экспорта модели IFC создается журнал (лог), в который записываются возникающие ошибки. Обязательно загляните в него. Он создается в той же папке экспорта и имеет то же имя, что и модель. Журнал без ошибок будет содержать только дату создания, а с ошибками будет имеет следующую структуру (Рис. 10):

Рисунок 10 — Журнал ошибок экспортированной модели

В 1-й колонке указывается уникальный идентификатор объекта GUID(это обращение к конкретному экземпляру, в котором произошла ошибка при экспорте). Во 2-й колонке указывается имя объекта Renga. В 3-й колонке указывается класс IFC экспортируемого объекта. В 4-й — причина возникшей ошибки.

Если в Вашем журнале есть ошибки – это причина заглянуть ещё раз в файл сопоставления параметров. Возможно, Вы просто разместили набор пользовательских свойств, не в той группе атрибутов. И проверить в модели Renga объекты, попавшие в журнал. По GUID Вы сможете точно его идентифицировать и проверить все ли атрибуты правильно наименованы, создав, например, по нему фильтр или найдя объект по GUID через спецификацию.

В заключении мне осталось описать еще одну функциональность, которая решает проблему коллизий, упомянутой во 2-й части статьи. Эта функциональность работает автоматически при экспорте модели в IFC. Теперь все объекты модели экспортируются с учетом подрезок, возникающих от взаимодействия с другими объектами в Renga. Я говорю о взаимодействия между конструктивными элементами (стена – перекрытие, перекрытие – колонна, колонна – балка и т.д.). Эта логика существует в Renga довольно уже давно, она определяет приоритет конструкций во взаимодействиях с другими элементами, например, перекрытие вырезает объем у стены, если мы его заведем во внутрь, смоделировав таким образом опирание, или крыша обрезает верх любых объектов, которые находятся под ней и пересекают ее и т.д. (рис. 11).

Рисунок 11 — Экспорт в IFC сучетом подрезки объектов

Эта функциональность поможет Вам избежать коллизий, вызванных взаимопересечением конструктивных элементов здания. Но она не заменит проверку модели в специализированном ПО (например, РусБИМЭксперт, Solibri Model Checker, Navisworks и т.п.). Ряд экспертиз (например, Санкт-Петербургская госэкспертиза) вместе с предоставляемой моделью требуют отчет о коллизиях из вышеперечисленного ПО. Это традиционный вопрос о том, что информационная модель никогда не создается с помощью одного инструмента – такого нет во всем мире. По-настоящему эффективная работа предполагает использование набора специализированного ПО.

Вот мы и подошли к концу данной статьи. Вся функциональность, о которой шла речь, родилась не просто так, а в процессе обсуждения с пользователями и экспертами. И была подтверждена практикой! Мы надеемся, что она будет востребована Вами и принесет Вам пользу. Тема экспорта в IFC4 – очень обширна, и мы только начали погружение в этот мир. Остаемся на связи. До новых встреч!

[3] Формат файлов IFC (Industry Foundation Classes) разработан компанией buildingSMART®. Это открытый международный стандарт (ISO 16739-1: 2018), позволяющий обмениваться данными между различными приложениями.

[4] Пример создания строительного объема здания см. видео.

[5] Cм. п. 8.8 Общих требований к ЦИМ СПб ГАУ «ЦГЭ» (редакция 2.0) или п. 9.2 Общие требования к параметрам цифровых моделей ГАУ «МГЭ» (редакция 4.1)

[6] См. п. 8.3 Требование к отсутствию коллизий ГАУ «МГЭ» (редакция 4.1)

Автор: Евгений Кирьян, маркетинг-менеджер Renga Software

Агентное моделирование как инструмент исследования экспертной оценки объекта Текст научной статьи по специальности «Компьютерные и информационные науки»

АГЕНТНОЕ МОДЕЛИРОВАНИЕ КАК ИНСТРУМЕНТ ИССЛЕДОВАНИЯ ЭКСПЕРТНОЙ ОЦЕНКИ ОБЪЕКТА

Л.В. Гайкова, канд. экон. наук, доцент

Новосибирский государственный университет экономики и управления (Россия, г. Новосибирск)

DOI: 10.24411/2411-0450-2019-10616

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

Ключевые слова: эксперт, экспертная оценка, достоверность экспертного заключения, имитационное моделирование, агентное моделирование.

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

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

группы экспертов, и что обобщенное коллективное мнение является достоверным [1]. Оценить степень достоверности полученного заключения возможно в среде агентного моделирования, которое в последнее время становится одним из современных инструментов исследования экономических процессов и объектов.

Для достижения поставленной цели необходимо было выполнить ряд задач: создать ментальную карту предметной области; построить процессную модель в нотации IDEF3 и имитационную агентную модель исследуемого процесса в среде ЛпуЬо§1е; провести опыты на модели; проанализировать полученные результаты.

Ментальные карты отображают всю картину в целом, что позволяет установить взаимосвязи между объектами, которые изначально были не так очевидны [2]. На рисунке 1 представлена ментальная карта, описывающая структуру экспертной оценки объекта в целом.

Рис. 1. Ментальная карта процесса экспертной оценки объекта

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

Для эффективного управления любым процессом, необходимо иметь детальное

представление о причинно-следственных связях между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или объект (рис. 2). Для решения данной задачи была использована методология ГОББЗ-диаграмм [3].

Рис. 2. Диаграмма процесса экспертной оценки объекта в среде ГОББЗ

Процесс экспертной оценки объекта начинается с заключения договора с клиентом. После того как поступил договор, определяется руководитель экспертной группы. Если руководитель не был определен, то этап повторяется заново. После определения руководителя экспертной группы начинаются выполнения четырех параллельных процедур: выбор формы проведения экспертной оценки объекта, выбор времени сбора отчетов, определе-

ние содержательной части документа, подбор экспертной группы.

Если подбор экспертной группы не был закончен, процесс начинается заново. Аналогичные действия выполняются с процедурами определения времени сбора отчетов и определения содержательной части отчета. По окончании выполнения процедур определения времени сбора отчетов и определения содержательной части отчета проверяется, выполнены ли процедуры выбора формы проведения экс-

пертной оценки объекта и выбора времени сбора отчетов. После чего экспертная группа выезжает на оценку объекта и осуществляет экспертную оценку.

Ментальная карта и диаграммы нотации ГОЕБЗ, имеющие в своей основе взаимо-

связь теоретических основ информатики с классической и неклассическими логиками [4], легли в основу создания имитационной агентной модели экспертной оценки объекта (рис. 3).

Рис. 3. Имитационная модель экспертной оценки объекта

Агентная модель представляет реальный мир в виде отдельно специфицируемых активных подсистем, называемых агентами, и состоит из множества индивидуальных агентов и их окружения. Каждый из агентов взаимодействует с другими агентами и внешней средой и в процессе функционирования может изменять как свое поведение, так и внешнюю среду. Агенты функционируют независимо, по своим законам, асинхронно, обычно в таких системах не существует централизованного управления [5].

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

стики поведения всей системы формируются как интегральные характеристики поведения совокупности агентов, составляющих систему [5].

Для разработки имитационной модели выбрано российское программное обеспечение ЛпуЬо§ю, которое построено на концепции объектно-ориентированного программирования, что позволяет наделять создаваемые объекты уникальными свойствами и методами, осуществлять взаимодействие между различными объектами и гибко настраивать систему для создания сложных моделей [5].

Агентное моделирование в AnyLogic предлагает широкие возможности для проведения экспериментов и анализа результатов моделирования [6]. Машинные эксперименты в среде AnyLogic задаются конфигурационными настройками, поддерживающими несколько типов имитаций, каждый из которых соответствует своей задаче моделирования.

В таблице представлены параметры и значения п-го эксперимента, в результате которого были выявлены оптимальные показатели, при которых процесс экспертной оценки объекта функционирует достоверно.

Таблица 1. Параметры и значения эксперимента

Параметр Значение

Количество сотрудников 8

Интенсивность заявок (заявок\час) 1

Время определения руководителя (час) 1

Время подбора экспертной группы (час) 1

Время определения содержательной части документа (час) 1

Эксперименты показали, что для рав- Агентное моделирование является од-

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

Библиографический список

1. Записки маркетолога: Процесс экспертной оценки объекта. [Электронный ресурс]. -Режим доступа: http://www.marketch.ru/marketing_dictionary/je/ekspertnaya_otsenka/

2. Russell J., Russell R. Mind Manager. — М.: Книга по Требованию, 2012. — 160 с.

3. Russell J., Cohn R. CA ER win Data Modeler. — М.: Книга по Требованию, 2012. — 90 с.

4. Гайкова Л.В. Взаимосвязь информатики с классической и неклассической логиками / Информационные технологии в прикладных исследованиях: сборник научных трудов / под ред. А.Л. Осипова. — Новосибирск: НГУЭУ, 2012. — С. 182-193.

5. Каталевский Д.Ю. Основы имитационного моделирования и системного анализа в управлении: Учебное пособие. — М.: Изд-во Московского университета, 2015. — 304 с.

6. Гайкова Л.В., Изотов О.Е. Агентное моделирование как инструмент аналитической обработки данных / Информационные технологии в прикладных исследованиях: Сборник научных трудов // под ред. А.Л. Осипова. — Новосибирск: НГУЭУ, 2013. — С. 123-132.

AGENT MODELING AS A RESEARCH TOOL FOR THE EXPERT ASSESSMENT OF

THE OBJECT

L.V. Gajkova, candidate of economic sciences, associate professor Novosibirsk state university of economics and management (Russia, Novosibirsk)

Abstract. The choice of forms and methods of expert surveys, approaches to processing the results of the survey depends on the specific task and conditions of the examination. Expert methods are used in situations where the choice, justification and assessment of the consequences of decisions cannot be performed on the basis of accurate calculations. Such situations often arise in solving modern problems of production management and, especially, in forecasting and long-term planning. The possibility of using agent modeling of expert evaluation of the object to justify the degree of reliability of the conclusion drawn up by a group of experts is considered.

Keywords: expert, expert evaluation, reliability of expert opinion, simulation, agent modeling.

Экспертная система — Википедия

Материал из Википедии — свободной энциклопедии

Экспе́ртная систе́ма (ЭС, англ. expert system) — компьютерная система, способная частично заменить специалиста-эксперта в разрешении проблемной ситуации. Современные экспертные системы начали разрабатываться исследователями искусственного интеллекта в 1970-х годах, а в 1980-х годах получили коммерческое подкрепление. Предшественники экспертных систем были предложены в 1832 году С. Н. Корсаковым, создавшим механические устройства, так называемые «интеллектуальные машины», позволявшие находить решения по заданным условиям, например, определять наиболее подходящие лекарства по наблюдаемым у пациента симптомам заболевания^[1].

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

Похожие действия выполняет такой программный инструмент как «Мастер» (англ. Wizard). Мастера применяются как в системных программах, так и в прикладных для упрощения интерактивного общения с пользователем (например, при установке ПО). Главное отличие мастеров от экспертных систем — отсутствие базы знаний — все действия жёстко запрограммированы. Это просто набор форм для заполнения пользователем.

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

В настоящее время «классическая» концепция экспертных систем, сложившаяся в 1970-1980 годах, переживает серьёзный кризис, по всей видимости связанный с её глубокой ориентацией на общепринятый в те годы текстовый человеко-машинный интерфейс, который в настоящее время в пользовательских приложениях почти полностью вытеснен графическим (GUI). Кроме того, «классический» подход к построению экспертных систем плохо согласуется с реляционной моделью данных, что делает невозможным эффективное использование современных промышленных СУБД для организации баз знаний таких систем.

Нередко в качестве маркетингового хода экспертными системами объявляются современные программные продукты, в «классическом» понимании таковыми не являющиеся (например, компьютерные справочно-правовые системы). Предпринимаемые энтузиастами попытки объединить «классические» подходы к разработке экспертных систем с современными подходами к построению пользовательского интерфейса (проекты CLIPS Java Native Interface, CLIPS.NET и др.) не находят поддержки среди крупных компаний-производителей программного обеспечения и по этой причине остаются пока в экспериментальной стадии.

Структура ЭС интеллектуальных систем

Книга^[2] представляет следующую структуру ЭС:

База знаний состоит из правил анализа информации от пользователя по конкретной проблеме.
ЭС анализирует ситуацию и, в зависимости от направленности ЭС, даёт рекомендации по разрешению проблемы.

Как правило, база знаний экспертной системы содержит факты (статические сведения о предметной области) и правила — набор инструкций, применяя которые к известным фактам можно получать новые факты.

В рамках логической модели баз данных и базы знаний записываются на языке Пролог с помощью языка предикатов для описания фактов и правил логического вывода, выражающих правила определения понятий, для описания обобщённых и конкретных сведений, а также конкретных и обобщённых запросов к базам данных и базам знаний.

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

Обычно факты в базе знаний описывают те явления, которые являются постоянными
для данной предметной области. Характеристики, значения которых зависят от условий конкретной
задачи, ЭС получает от пользователя в процессе работы, и сохраняет их в рабочей памяти.
Например, в медицинской ЭС факт «У здорового человека 2 ноги» хранится в базе знаний, а факт «У пациента одна нога»
— в рабочей памяти.

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

эксперты той проблемной области, к которой относятся задачи, решаемые ЭС;
инженеры по знаниям, являющиеся специалистами по разработке ИИС;
программисты, осуществляющие реализацию ЭС.

Режимы функционирования

ЭС может функционировать в 2-х режимах.

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

Классификация ЭС

Классификация ЭС по решаемой задаче

Классификация ЭС по связи с реальным временем

Статические — решающие задачи в условиях не изменяющихся во времени исходных данных и знаний.
Квазидинамические — интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени.
Динамические — решающие задачи в условиях изменяющихся во времени исходных данных и знаний.

Этапы разработки ЭС

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

Наиболее известные ЭС

CLIPS — весьма популярная оболочка для построения ЭС (public domain)
OpenCyc — мощная динамическая ЭС с глобальной онтологической моделью и поддержкой независимых контекстов
WolframAlpha — база знаний и набор вычислительных алгоритмов, интеллектуальный «вычислительный движок знаний»
MYCIN — наиболее известная диагностическая система, которая предназначена для диагностики и наблюдения за состоянием больного при менингите и бактериальных инфекциях.
HASP/SIAP — интерпретирующая система, которая определяет местоположение и типы судов в Тихом океане по данным акустических систем слежения.
Акинатор — интернет-игра. Игрок должен загадать любого персонажа, а Акинатор должен его отгадать, задавая вопросы. База знаний автоматически пополняется, поэтому программа может отгадать практически любого известного персонажа.
IBM Watson — суперкомпьютер фирмы IBM, способный понимать вопросы, сформулированные на естественном языке, и находить на них ответы в базе данных.

См. также

Ссылки

Литература

Экспертная система. Классификация. Обзор существующих экспертных систем

Keywords: expert system, structure expert system, classification of expert systems.

Экспертная система (ЭС, англ.expertsystem) — компьютерная система, способная частично заменить специалиста-эксперта в разрешении проблемной ситуации. Современные экспертные системы взяли свое начало в 1970-х годах с трудов исследователей искусственного интеллекта, а в 1980-х получили коммерческое подкрепление. Первые подобия экспертных систем были предложены в 1832 году С. Н. Корсаковым, создавшим механические устройства, так называемые «интеллектуальные машины», позволявшие отыскать решения по некоторым условиям. Примером такой системы является система, позволяющая подбирать необходимые медицинские препараты по симптомам заболевания пациента.

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

Подобные задачи выполняет программный продукт, называемый «Мастер» (англ. Wizard). Мастера применяются в прикладных и системных программах для упрощения интерактивного общения с пользователем. Основным отличием данных программ — это отсутствие базы знаний — все действия запрограммированы.

Другие подобные программы — поисковые или справочные (энциклопедические) системы. Они предоставляют релевантные, т. е. подходящие запросу пользователя, разделы базы статей.

В настоящее время «классическая» концепция экспертных систем 70–80 годов переживает серьезный кризис, связанный с её сильной ориентацией на текстовый человеко-машинный интерфейс, почти полностью вытесненный графическим интерфейсом (GUI). Помимо этого, «классическая» концепция экспертных систем плохо согласуется с реляционной моделью данных, что создает сложности в работе с современными промышленными системами управления базами данных (СУБД). Время от времени энтузиастами предпринимаются попытки объединить «классический» и современный подход к построению пользовательского интерфейса, но они не находят поддержки среди крупных компаний-производителей.

Структура ЭС

В состав ЭС входят следующие элементы:

‒ Интерфейс пользователя

‒ Пользователь

‒ Интеллектуальный редактор базы знаний

‒ Эксперт

‒ Инженер по знаниям

‒ Рабочая (оперативная) память

‒ База знаний

‒ Решатель (механизм вывода)

‒ Подсистема объяснений

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

База знаний состоит из двух составляющих:

 факты — статические сведения о предметной области;

 правила — набор инструкций, который позволяет выводить новые факты, исходя из уже известных.

В рамках логической модели базы знаний формируются на языке Пролог с помощью предикатов для описания фактов и правил логического вывода.

Обычно факты в базе знаний описывают те явления, которые являются постоянными для данной предметной области. Данные, зависящие от условий конкретной задачи, ЭС получает от пользователя в процессе работы и сохраняет в рабочей памяти.

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

эксперты той проблемной области, к которой относятся задачи, решаемые ЭС;
инженеры по знаниям, являющиеся специалистами по разработке ИИС;
программисты, осуществляющие реализацию ЭС.

Режимы функционирования

ЭС может функционировать в 2-х режимах:

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

Классификация ЭС

По решаемой задаче:

‒ Интерпретация данных;

‒ Диагностирование;

‒ Мониторинг;

‒ Проектирование;

‒ Прогнозирование;

‒ Сводное планирование;

‒ Оптимизация;

‒ Обучение;

‒ Управление;

‒ Ремонт;

‒ Отладка.

По связи среальным временем:

 Статические — решающие задачи в условиях, не изменяющихся во времени исходных данных и знаний.

 Квазидинамические — интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени.

 Динамические — решающие задачи в условиях изменяющихся во времени исходных данных и знаний.

Этапы разработки ЭС

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

‒ Этап извлечения знаний — проводится содержательный анализ проблемной области, выявляются используемые понятия и их взаимосвязи, определяются методы решения задач.

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

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

‒ Реализация ЭС — создается один или несколько прототипов ЭС, решающие требуемые задачи.

‒ Этап тестирования — производится оценка выбранного способа представления знаний в ЭС в целом.

Наиболее известные ЭС

 CLIPS — весьма популярная оболочка для построения ЭС. CLIPS является продукционной системой. Реализация вывода использует алгоритм Rete. CLIPS является одной из наиболее широко используемых инструментальных сред для разработки экспертных систем благодаря своей скорости, эффективности и бесплатности.CLIPS разработан для применения в качестве языка прямогологического вывода(forward chaining) и в своей оригинальной версии не поддерживает обратного вывода (backward chaining). Как и другие экспертные системы, CLIPS имеет дело с правилами и фактами.

 OpenCyc — мощная динамическая ЭС с глобальной онтологической моделью и поддержкой независимых контекстов. OpenCyc является сокращенным открытый вариантомбазы знаний Cyc. В БД OpenCyc содержится 47000 понятий и 300000 фактов.

 WolframAlpha — база знаний и набор вычислительных алгоритмов, интеллектуальный «вычислительный движок знаний». Wolfram Alpha вычисляет ответы на большое количество разнообразных вопросов. Для подбора ответов механизм использует встроенные модели из разных областей знаний, заполненные данными и алгоритмами, которые и представляют собой реальные познания.

 MYCIN — наиболее известная диагностическая система, которая предназначена для диагностики и наблюдения за состоянием больного при менингите и бактериальных инфекциях. Также Mycin использовалась для диагностики заболеваний свертываемости крови. MYCIN оперировала с помощью довольно простоймашины вывода, и базы знаний из ~600 правил.

 HASP/SIAP — интерпретирующая система, которая определяет местоположение и типы судов в Тихом океане по данным акустических систем слежения. Данные имеют вид сонограмм, являющихся аналоговыми записями спектров принятой датчиками звуковой энергии. Для их интерпретации система применяет знания о характерных особенностях сонограмм различных типов кораблей.

 Акинатор — интернет-игра. Игрок должен загадать любого персонажа, а Акинатор должен его отгадать, задавая вопросы. База знаний автоматически пополняется, поэтому программа может отгадать практически любого известного персонажа. На каждом вопросе Акинатор пытается выбрать такой вопрос, который отсеет наибольшее количество вариантов. Каждый раз после вашего ответа у Акинатора «в голове» остаётся список персонажей, которые соответствуют вашим ответам.

 IBMWatson — суперкомпьютер фирмы IBM, способный понимать вопросы, сформулированные на естественном языке, и находить на них ответы в базе данных. В первую очередь Watson стали учить медицине, а конкретно, онкологии. Архитектура Watson такова, что позволяет осуществлять параллельные и распределенные вычисления, т. е. сразу работать с множеством задач в параллельном режиме. Watson способен работать с супербольшими данными, т. е. структурированной и неструктурированной информацией.

Вывод

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

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

Литература:

Сложносистемное мышление: Материя, разум, человечество. Майнцер, Клаус. Серия:Синергетика: от прошлого к будущему
2009 г.; Изд-во: М.: Книжный дом «Либроком»
Интеллектуальные системы управления организационно-техническими системами. Антамошин, А.Н.; Близнова, О.В.; Большаков, А.А. и др. 2016 г.; Изд-во: М.: Горячая линия — Телеком.
Принятие решений. Интегрированные интеллектуальные системы. Арсеньев, Ю.Н.; Шелобаев, С.И.; Давыдова, Т.Ю. 2003 г.; Изд-во: М.: Юнити-Дана
Искусственный интеллект. Стратегии и методы решения сложных проблем. Люгер, Джордж Ф. 2003 г.; Изд-во: М.: Вильямс.
Масленникова, О.Е.; Попова, И. В. Основы искусственного интеллекта. 2008 г.; Изд-во: Магнитогорск: Магнитогорский государственный университет

Основные термины (генерируются автоматически): CLIPS, баз знаний, база знаний, система, MYCIN, задача, знание, логический вывод, предметная область, проблемная область.

Модель экспертных систем — Студопедия

Экспертные системы работают в диалоговом режиме (отвечают на поставленные пользователем вопросы), при этом, они должны уметь объяснять, откуда получено то или иное решение, любая экспертная система содержит как минимум пять компонентов или подсистем (рис. 30).

Рис. 30. Базовая структура экспертной системы

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

Инженер по знаниям — специалист в области искусственного интеллекта, работающий с экспертами и формирующий базу знаний. Синонимы: когнитолог, инженер-интерпретатор, аналитик.

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

База знаний — ядро экспертной системы, совокупность знаний предметной области, записанная на машинный носитель в форме, понятной эксперту и пользователю (обычно на некотором языке, приближенном к естественному).

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

Подсистема объяснений — программа, позволяющая пользователю получить ответы на вопросы: «Как была получена та или иная рекомендация?» и «Почему система приняла такое решение?» Ответ на вопрос «как» — это трассировка всего процесса получения решения с указанием использованных фрагментов базы знаний, т. е. всех шагов цепи умозаключений. Ответ на вопрос «почему» — ссылка на умозаключение, непосредственно предшествовавшее полученному решению, т. е. отход на один шаг назад. Развитые подсистемы объяснений поддерживают и другие типы вопросов.

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

Описанная структура является базовой и может расширяться (рис. 31).

Рис. 31. Структура экспертной системы

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

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

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

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

Экспертная система — Википедия

Материал из Википедии — свободной энциклопедии

Структура ЭС интеллектуальных систем

Книга^[2] представляет следующую структуру ЭС:

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

эксперты той проблемной области, к которой относятся задачи, решаемые ЭС;
инженеры по знаниям, являющиеся специалистами по разработке ИИС;
программисты, осуществляющие реализацию ЭС.

Режимы функционирования

ЭС может функционировать в 2-х режимах.

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

Классификация ЭС

Классификация ЭС по решаемой задаче

Классификация ЭС по связи с реальным временем

Статические — решающие задачи в условиях не изменяющихся во времени исходных данных и знаний.
Квазидинамические — интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени.
Динамические — решающие задачи в условиях изменяющихся во времени исходных данных и знаний.

Этапы разработки ЭС

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

Наиболее известные ЭС

CLIPS — весьма популярная оболочка для построения ЭС (public domain)
OpenCyc — мощная динамическая ЭС с глобальной онтологической моделью и поддержкой независимых контекстов
WolframAlpha — база знаний и набор вычислительных алгоритмов, интеллектуальный «вычислительный движок знаний»
MYCIN — наиболее известная диагностическая система, которая предназначена для диагностики и наблюдения за состоянием больного при менингите и бактериальных инфекциях.
HASP/SIAP — интерпретирующая система, которая определяет местоположение и типы судов в Тихом океане по данным акустических систем слежения.
Акинатор — интернет-игра. Игрок должен загадать любого персонажа, а Акинатор должен его отгадать, задавая вопросы. База знаний автоматически пополняется, поэтому программа может отгадать практически любого известного персонажа.
IBM Watson — суперкомпьютер фирмы IBM, способный понимать вопросы, сформулированные на естественном языке, и находить на них ответы в базе данных.

См. также

Ссылки

Литература

Как: экспорт и импорт модели

18.05.2015
6 минут на чтение

В этой статье

Применимо к: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

Модель — это набор элементов в заданном слое.Каждый слой состоит из одной или нескольких моделей. Модели можно экспортировать в файлы с расширением .axmodel. Эти файлы называются файлами моделей. Файлы модели — это артефакты развертывания, которые можно импортировать в хранилище моделей.

Модель постоянно связана со слоем, в котором создается. Если вам нужно переместить одну из ваших моделей из одного слоя в другой, вы должны создать проект из модели в AOT, экспортировать проект как файл xpo, создать целевая модель в желаемом слое, удалите исходную модель, чтобы не разрешать конфликты слоев, и импортируйте файл xpo в целевую модель.Если вы перемещаете элементы между моделями в одном слое, вы можете использовать команду Переместить в модель в AOT.

Для экспорта моделей в файлы моделей и импорта файлов моделей в хранилище моделей можно использовать командлеты Windows PowerShell или служебную программу командной строки AXUtil.

Важно

В Microsoft Dynamics AX 2012 идентификаторы элементов и дескрипторы элементов назначаются во время установки. Следовательно, вы должны избегать случайного выбора идентификаторов элементов и дескрипторов элементов при установке моделей.В общем, никогда не удаляйте модель и не устанавливайте ее заново. Всегда устанавливайте модель поверх существующей модели. Для получения дополнительной информации см. Раздел «Ведение идентификаторов элементов для конкретной установки и дескрипторов элементов».

Подготовка системы

Осушите клиентские соединения и проверьте разрешения

Разорвите клиентские подключения к экземпляру Application Object Server (AOS), с которым вы работаете. Дополнительные сведения см. В разделе Удаление пользователей из AOS.
Убедитесь, что у вас есть соответствующие разрешения для работы с хранилищем моделей:

Экспорт файлов модели

Вы можете экспортировать файл модели, если хотите распространить его внутри компании или среди клиентов.Если вы планируете распространять файл модели среди клиентов, мы рекомендуем вам подписать модель строгим именем. Чтобы подписать модель строгим именем, необходимо использовать средство строгого имени, SN.exe, для создания файла пары ключей.

Экспорт файла .axmodel (Windows PowerShell)

В меню Пуск выберите Все программы , укажите Администрирование , а затем щелкните Оболочка управления Microsoft Dynamics AX .
В командной строке Windows PowerShell PS C: \> введите следующую команду и нажмите клавишу ВВОД.
```
  Export-AXModel –Model <имя> -File 
  
```
В этом примере указанная модель экспортируется в файл с указанным именем.
Вы можете использовать параметры –Server, –Config или –Database, чтобы указать среду для экспорта.
Вы также можете использовать параметр -Key, чтобы указать файл пары ключей строгого имени, который будет использоваться для подписи модели.
Для получения дополнительной информации см. Export-AXModel.
Вы также можете использовать Sign Tool, чтобы подписать файл цифровым сертификатом, или команду AXUtil genlicense, чтобы Authenticode подписать файл.Для получения дополнительной информации см .:

Экспорт файла .axmodel (AXUtil)

В меню Пуск щелкните Командная строка .
Перейдите в каталог утилит управления. Обычно этот каталог находится в% ProgramFiles% \ Microsoft Dynamics AX \ 60 \ ManagementUtilities.
В командной строке введите следующую команду и нажмите клавишу ВВОД.
```
  axutil экспорт / модель: <имя модели> / файл: <имя файла> / подробный
  
```
В этом примере указанная модель экспортируется в файл с указанным именем.
Вы можете использовать параметр [/ key: SNK-file], чтобы указать файл пары ключей строгого имени, который будет использоваться для подписи модели.
Вы также можете использовать Sign Tool, чтобы подписать файл цифровым сертификатом, или команду AXUtil genlicense, чтобы Authenticode подписать файл. Для получения дополнительной информации см .:

Импорт файла .axmodel

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

По умолчанию при импорте модели из Windows PowerShell или AXUtil в режиме установки отображается контрольный список обновления кода модели при запуске клиента Microsoft Dynamics AX. Если вы импортируете модель с помощью Setup.exe, по умолчанию в режиме установки не отображается контрольный список обновления кода модели.Дополнительные сведения об импорте модели с помощью Setup.exe см .:

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

Импорт файла .axmodel (Windows PowerShell)

В меню Пуск выберите Все программы , укажите Администрирование , а затем щелкните Оболочка управления Microsoft Dynamics AX .

В командной строке Windows PowerShell PS C: \> введите следующую команду и нажмите клавишу ВВОД.

  Install-AXModel -File  -Details

Эта команда устанавливает указанный файл на том же уровне, из которого он был экспортирован.

Вы можете использовать параметры –Server, –Config или –Database, чтобы указать среду для импорта.

По умолчанию вам будет предложено установить модель в зависимости от того, подписана ли она.В следующей таблице описаны показанные запросы.

Сценарий	Подсказка
Файл модели не подписан.	Модель не подписана. Вы уверены, что хотите установить эту модель (Да / Нет)?
Издатель распознается по цифровому сертификату.	Модель подписана «{0}».Вы бы хотели продолжить (Да / Нет)?
Издатель недоступен из цифрового сертификата.	Сертификат на модель не распознан. Вы уверены, что хотите установить эту модель (Да / Нет)?
Неизвестный поставщик сертификата.	Сертификат на модель не распознан. Вы уверены, что хотите установить эту модель (Да / Нет)?

Если установка не удалась из-за конфликта, мы рекомендуем повторно запустить командлет и использовать опцию -Conflict Push , чтобы протолкнуть конфликтующий элемент на соответствующий уровень обновления.После этого можно разрешить конфликт. Дополнительные сведения см. В разделе Как разрешать конфликты после импорта модели.

Для получения дополнительной информации см. Install-AXModel.

Импорт файла .axmodel (AXUtil)

В меню Пуск щелкните Командная строка .
Перейдите в каталог утилит управления. Обычно этот каталог находится в% ProgramFiles% \ Microsoft Dynamics AX \ 60 \ ManagementUtilities.
В командной строке введите следующую команду и нажмите клавишу ВВОД.
```
  axutil import / file: <имя файла> / подробный
  
```
Эта команда устанавливает указанный файл на том же уровне, из которого он был экспортирован.
Если установка не удалась из-за конфликта, мы рекомендуем повторно запустить команду и использовать параметр / конфликт: push , чтобы отправить элемент, который имеет конфликт, на соответствующий уровень обновления. После этого можно разрешить конфликт.Дополнительные сведения см. В разделе Как разрешать конфликты после импорта модели.

См. Также

Модели, слои и магазин моделей

AxUtil и команды Windows PowerShell для развертывания моделей

Администрирование Microsoft Dynamics AX с помощью Windows PowerShell

Windows PowerShell для Microsoft Dynamics AX

Объявления: Новая книга: «Внутри Microsoft Dynamics AX 2012 R3» теперь доступна. Получите копию в магазине MS Press.

Экспорт моделей — документация по Stable Baselines 2.10.2a0

После обучения агента вы можете развернуть / использовать его на другом языке.
или фреймворк, например PyTorch или tensorflowjs.
Stable Baselines не включает инструменты для экспорта моделей в другие платформы, но
этот документ направлен на охват частей, которые необходимы для экспорта вместе с
более подробные истории от пользователей Stable Baselines.

Фон

В стабильных базовых версиях контроллер хранится внутри политик, которые преобразуют
наблюдения в действия.Каждый алгоритм обучения (например, DQN, A2C, SAC) содержит
одна или несколько политик, некоторые из которых используются только для обучения. Простой способ найти
политика заключается в проверке кода функции агента прогноз :
Эта функция должна вызывать только одну политику с простыми аргументами.

Политики

содержат необходимые заполнители и тензоры Tensorflow для выполнения
вывод (т.е. прогноз действий), поэтому достаточно экспортировать эти политики
сделать вывод в другой структуре.

Примечание

Алгоритмы обучения

также могут содержать другие заполнители Tensorflow, которые используются только для обучения и
не требуется для вывода.

Предупреждение

При использовании политик CNN наблюдение нормализуется внутренне (деление на 255 для получения значений в [0, 1])

Экспорт в PyTorch

Известное рабочее решение — использовать get_parameters
функция для получения параметров модели, построения сети вручную в PyTorch и правильного назначения параметров.

Предупреждение

PyTorch и Tensorflow имеют внутренние различия, например, с 2D свертки (см. Обсуждение по ссылке ниже).

Подробности см. В обсуждении №372.

Экспорт в C ++

Tensorflow, который является основой Stable Baselines, по сути, является библиотекой C / C ++, несмотря на то, что к ней чаще всего обращаются.
через слой внешнего интерфейса Python. Этот выбор дизайна означает, что модели, созданные на уровне Python, обычно должны быть
полностью совместим с соответствующей версией C ++ Tensorflow.

Предупреждение

Рекомендуется не смешивать разные версии библиотек Tensorflow, особенно с точки зрения состояния.Перемещение вычислительных графов обычно более снисходительно. Фактически, упомянутый ниже проект PPO_CPP использует
графики, созданные с помощью Python Tensorflow 1.x в версии C ++ Tensorflow 2.

Stable Baselines очень удобен, когда вы надеетесь перенести вычислительный граф и / или состояние (веса) как
существующие алгоритмы определяют для вас большую часть необходимых вычислений, поэтому вам не нужно заново воссоздавать ядро алгоритмов.
Именно эта идея была использована в проекте PPO_CPP, который выполняет обучение на уровне C ++ ради
вычислительная эффективность.Графики экспортируются из реализации PPO2 в Stable Baselines через tf.train.export_meta_graph
функция. В качестве альтернативы и, возможно, чаще, вы можете использовать слой C ++ только для вывода. Это может быть полезно
как этап развертывания серверных бэкэндов или оптимизации для более ограниченных устройств.

Предупреждение

В качестве предостережения, API уровня C ++ более важны, чем их аналоги на Python, или, проще говоря: грубее.
Это особенно заметно в Tensorflow 2.0, где декларативность Autograph существует только на уровне Python. В
Аналог C ++ по-прежнему работает с объектами Session, которые известны по более ранним версиям Tensorflow. В нашем случае использования
Доступность графиков, используемых Session, зависит от использования декораторов tf.function . Однако по состоянию на ноябрь 2019 г.
в основной версии используется Tensorflow 1.x, который немного проще использовать в контексте переносимости C ++.

Ручной экспорт

Вы также можете вручную экспортировать требуемые параметры (веса) и построить
сеть в желаемой структуре, как это сделано в приведенном выше примере PyTorch.

Доступ к параметрам модели через агентов.
get_parameters
функция. Если вы используете политики по умолчанию, вы можете найти архитектуру сетей в
источник политик. В противном случае, для DQN / SAC / DDPG или TD3 вам необходимо проверить файл policy.py , расположенный
в соответствующих папках.

Как: экспорт и импорт магазина моделей

18.05.2015
5 минут на чтение

В этой статье

Применимо к: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

Вы можете экспортировать и импортировать магазин моделей как единое целое.Если вам необходимо создать похожие среды, предпочтительным методом является экспорт и импорт хранилища моделей. Кроме того, мы рекомендуем использовать этот метод при развертывании серьезных изменений в производственной среде. Дополнительные сведения о том, как выбрать метод, который вы используете для развертывания решения, см. В разделе Модели, слои и хранилище моделей.

Когда вы экспортируете или импортируете хранилище моделей, вы влияете на все элементы модели, слои и модели.

Для управления хранилищем моделей можно использовать командлеты Windows PowerShell или служебную программу командной строки AXUtil.

Подготовка системы

Проверить разрешения

Экспорт магазина моделей

Хранилище модели, которое вы экспортируете, остается в исходной среде. Магазин моделей не удаляется.

Экспорт магазина моделей (Windows PowerShell)

В меню Пуск выберите Все программы , укажите Администрирование , а затем щелкните Оболочка управления Microsoft Dynamics AX .
В командной строке Windows PowerShell PS C: \> введите следующую команду и нажмите клавишу ВВОД.
```
  Export-AXModelStore -File <имя файла> -Details
  
```
Эта команда экспортирует хранилище модели в файл .axmodelstore.
Для получения дополнительной информации см. Export-AXModelStore.

Экспорт магазина моделей (AXUtil)

В меню Пуск щелкните Командная строка .
Перейдите в каталог утилит управления. Обычно этот каталог находится в% ProgramFiles% \ Microsoft Dynamics AX \ 60 \ ManagementUtilities.
В командной строке введите следующую команду и нажмите клавишу ВВОД.
```
  axutil exportstore / file: filename [/ verbose]
  
```
Эта команда экспортирует хранилище модели в файл .axmodelstore.

Импорт модели магазина

Когда вы импортируете хранилище моделей, вы можете импортировать хранилище новых моделей непосредственно в схему по умолчанию, dbo. Кроме того, вы можете импортировать хранилище модели в другую схему, а затем применить хранилище модели к схеме по умолчанию.

Если вы импортируете хранилище новой модели непосредственно в схему dbo, время простоя, вероятно, будет больше, потому что вы должны остановить все экземпляры Application Object Server (AOS), пока хранилище модели импортируется.
Если вы импортируете файл хранилища модели в схему, отличную от схемы по умолчанию, время простоя может быть меньше, поскольку экземпляры AOS могут оставаться активными на протяжении всего процесса импорта.

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

Когда вы импортируете хранилище моделей, вы можете выполнить резервное копирование существующего хранилища моделей в другую схему. Схема, для которой вы создаете резервную копию хранилища моделей, не может существовать до того, как вы импортируете хранилище моделей.

По умолчанию, если во время импорта файла .axmodelstore возникает конфликт идентификаторов элементов, импорт останавливается.

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

Импорт хранилища моделей в схему dbo (Windows PowerShell)

Удалите все клиентские подключения из экземпляра AOS, с которым вы работаете. Дополнительные сведения см. В разделе Удаление пользователей из AOS.
В командной строке Windows PowerShell PS C: \> введите следующую команду и нажмите клавишу ВВОД.
```
  Import-AXModelStore -File <имя файла>
  
```
Эта команда импортирует хранилище модели в базу данных Microsoft Dynamics AX и связывает хранилище модели со схемой по умолчанию, dbo.Вы также можете использовать параметр -BackupSchema, чтобы скопировать перезаписанное хранилище модели в новую схему. Схема, указанная параметром -BackupSchema, не может существовать во время выполнения командлета.
Для получения дополнительной информации см. Import-AXModelStore.

Установить магазин моделей в схему dbo (AXUtil)

Удалите все клиентские подключения из экземпляра AOS, с которым вы работаете. Дополнительные сведения см. В разделе Удаление пользователей из AOS.
В меню Пуск щелкните Командная строка .
Перейдите в каталог утилит управления. Обычно этот каталог находится в% ProgramFiles% \ Microsoft Dynamics AX \ 60 \ ManagementUtilities.
В командной строке введите следующую команду и нажмите клавишу ВВОД.
```
  axutil importstore / файл: имя файла
  
```
Эта команда импортирует хранилище модели в базу данных Microsoft Dynamics AX и связывает хранилище модели со схемой по умолчанию, dbo.Вы также можете использовать параметр / BackupSchema для копирования перезаписанного хранилища модели в новую схему. Схема, указанная параметром / BackupSchema, не может существовать во время запуска AXUtil.

Импортировать хранилище модели во временную схему, а затем применить хранилище модели (Windows PowerShell)

В этом примере схема не по умолчанию называется TemporarySchema.
В командной строке Windows PowerShell PS C: \> введите следующую команду и нажмите клавишу ВВОД.
```
  Import-AXModelStore -File Staging.axmodelstore -SchemaName TemporarySchema
  
```
Эта команда устанавливает файл хранилища модели в указанной вами схеме.
Примечание
Хранилище модели, которое вы импортируете в схему, отличную от схемы по умолчанию, не отображается в Microsoft Dynamics AX.
После импорта хранилища модели удалите все клиентские подключения из экземпляра AOS, с которым вы работаете. Дополнительные сведения см. В разделе Удаление пользователей из AOS.
После закрытия всех соединений AOS введите следующую команду и нажмите клавишу ВВОД.
```
  Import-AXModelStore -Apply: TemporarySchema
  
```
Эта команда применяет хранилище моделей, которое было связано со схемой, отличной от стандартной, TemporarySchema, к схеме dbo. После этого хранилище модели становится видимым для Microsoft Dynamics AX.
Для получения дополнительной информации см. Import-AXModelStore.

Установите хранилище моделей во временную схему, а затем примените хранилище моделей (AXUtil)

В этом примере схема не по умолчанию называется TemporarySchema.
В меню Пуск щелкните Командная строка .
Перейдите в каталог утилит управления. Обычно этот каталог находится в% ProgramFiles% \ Microsoft Dynamics AX \ 60 \ ManagementUtilities.
В командной строке введите следующую команду и нажмите клавишу ВВОД.
```
  axutil importstore / файл: имя файла / имя схемы: имя / подробный
  
```
Эта команда устанавливает файл хранилища модели в указанной вами схеме.
Примечание
Хранилище модели, которое вы импортируете в схему, отличную от схемы по умолчанию, не отображается в Microsoft Dynamics AX.
Осушите клиентские соединения, подключенные к экземпляру AOS, с которым вы работаете. Дополнительные сведения см. В разделе Удаление пользователей из AOS.
В командной строке введите следующую команду и нажмите клавишу ВВОД.
```
  axutil importstore / применить / имя_схемы: временная схема / подробный
  
```
Эта команда применяет хранилище моделей, которое было связано со схемой, отличной от стандартной, TemporarySchema, к схеме dbo.После этого хранилище модели становится видимым для Microsoft Dynamics AX.

См. Также

Модели, слои и магазин моделей

AxUtil и команды Windows PowerShell для развертывания моделей

Администрирование Microsoft Dynamics AX с помощью Windows PowerShell

Windows PowerShell для Microsoft Dynamics AX

Объявления: Новая книга: «Внутри Microsoft Dynamics AX 2012 R3» теперь доступна. Получите копию в магазине MS Press.

Экспорт моделей — pydantic

Помимо прямого доступа к атрибутам модели через их имена (например, model.foobar ), модели могут быть преобразованы
и экспортировано несколькими способами:

`модель.dict (...)`

Это основной способ преобразования модели в словарь.Подмодели будут рекурсивно преобразованы в словари.

Аргументы:

включает : поля для включения в возвращаемый словарь; см. ниже
exclude : поля для исключения из возвращаемого словаря; см. ниже
by_alias : следует ли использовать псевдонимы полей в качестве ключей в возвращаемом словаре; по умолчанию Ложь
exclude_unset : должны ли поля, которые не были явно заданы при создании модели
быть исключенным из возвращенного словаря; по умолчанию Ложь .До v1.0 , exclude_unset был известен как skip_defaults ; использование skip_defaults теперь устарело
exclude_defaults : должны ли поля, которые равны их значениям по умолчанию (установленным или иным образом)
быть исключенным из возвращенного словаря; по умолчанию Ложь
exclude_none : следует ли исключать поля, равные None , из возвращаемого словаря; дефолт
Неверно

Пример:

  из pydantic import BaseModel


класс BarModel (BaseModel):
    что угодно: int


класс FooBarModel (BaseModel):
    банан: плавать
    foo: str
    бар: BarModel


m = FooBarModel (банан = 3.14, foo = 'hello', bar = {'что угодно': 123})

# возвращает словарь:
печать (m.dict ())
"" "
{
    'банан': 3,14,
    'foo': 'привет',
    'bar': {'что угодно': 123},
}
"" "
print (m.dict (include = {'foo', 'bar'}))
#> {'foo': 'hello', 'bar': {'что угодно': 123}}
print (m.dict (exclude = {'foo', 'bar'}))
#> {'банан': 3.14}

(Этот сценарий готов, он должен работать «как есть»)

`dict (модель)` и итерация

Модели

pydantic также можно преобразовать в словари с помощью dict (model) , и вы также можете
перебирать поле модели, используя для field_name, значение в модели: .При таком подходе необработанные значения поля
возвращается, поэтому подмодели не будут преобразованы в словари.

Пример:

  из pydantic import BaseModel


класс BarModel (BaseModel):
    что угодно: int


класс FooBarModel (BaseModel):
    банан: плавать
    foo: str
    бар: BarModel


m = FooBarModel (банан = 3.14, foo = 'привет', bar = {'что угодно': 123})

печать (dict (m))
"" "
{
    'банан': 3,14,
    'foo': 'привет',
    'бар': BarModel (
        независимо = 123,
    ),
}
"" "
для имени, значение в м:
    print (f '{имя}: {значение}')
    #> банан: 3.14
    #> foo: привет
    #> bar: независимо = 123

(Этот сценарий готов, он должен работать «как есть»)

`модель. Копия (...)`

copy () позволяет дублировать модели, что особенно полезно для неизменяемых моделей.

Аргументы:

включает : поля для включения в возвращаемый словарь; см. ниже
exclude : поля для исключения из возвращаемого словаря; см. ниже
обновление : словарь значений, которые нужно изменить при создании скопированной модели
deep : делать ли глубокую копию новой модели; по умолчанию Ложь

Пример:

  из pydantic import BaseModel


класс BarModel (BaseModel):
    что угодно: int


класс FooBarModel (BaseModel):
    банан: плавать
    foo: str
    бар: BarModel


m = FooBarModel (банан = 3.14, foo = 'hello', bar = {'что угодно': 123})

print (m.copy (include = {'foo', 'bar'}))
#> foo = 'hello' bar = BarModel (без разницы = 123)
print (m.copy (exclude = {'foo', 'bar'}))
#> банан = 3,14
print (m.copy (update = {'банан': 0}))
#> banana = 0 foo = 'hello' bar = BarModel (безотносительно = 123)
print (id (m.bar), id (m.copy (). bar))
#> 139868119420992 139868119420992
# обычная копия дает такую же ссылку на объект для `bar`
print (id (m.bar), id (m.copy (deep = True) .bar))
#> 139868119420992 139868119423296
# глубокая копия дает ссылку на новый объект для `bar`

(Этот сценарий готов, он должен работать «как есть»)

`модель.json (...)`

Метод .json () сериализует модель в JSON. Обычно .json () в свою очередь вызывает .dict () и
сериализует свой результат. (Для моделей с настраиваемым корневым типом после вызова .dict () ,
сериализуется только значение ключа __root__ )

Аргументы:

включает : поля для включения в возвращаемый словарь; см. ниже
exclude : поля для исключения из возвращаемого словаря; см. ниже
by_alias : следует ли использовать псевдонимы полей в качестве ключей в возвращаемом словаре; по умолчанию Ложь
exclude_unset : должны ли поля, которые не были установлены при создании модели и имеют значения по умолчанию,
быть исключенным из возвращенного словаря; по умолчанию Ложь .До v1.0 , exclude_unset был известен как skip_defaults ; использование skip_defaults теперь устарело
exclude_defaults : должны ли поля, которые равны их значениям по умолчанию (установленным или иным образом)
быть исключенным из возвращенного словаря; по умолчанию Ложь
exclude_none : следует ли исключать поля, равные None , из возвращаемого словаря; дефолт
Неверно
кодировщик : пользовательская функция кодировщика, переданная аргументу default для json.свалки () ; по умолчанию на заказ
энкодер разработан для работы со всеми распространенными типами
** dumps_kwargs : любые другие аргументы ключевого слова передаются в json.dumps () , например , отступ .

pydantic может сериализовать многие часто используемые типы в JSON (например, datetime , date или UUID ), что обычно
не удалось выполнить с помощью простого json.dumps (foobar) .

  из datetime import datetime
из pydantic import BaseModel


класс BarModel (BaseModel):
    что угодно: int


класс FooBarModel (BaseModel):
    foo: datetime
    бар: BarModel


m = FooBarModel (foo = datetime (2032, 6, 1, 12, 13, 14), bar = {'что угодно': 123})
печать (м.json ())
#> {"foo": "2032-06-01T12: 13: 14", "bar": {"что угодно": 123}}

(Этот сценарий готов, он должен работать «как есть»)

`json_encoders`

Сериализацию можно настроить на модели с помощью свойства конфигурации json_encoders ; ключи должны быть типами, а
значения должны быть функциями, которые сериализуют этот тип (см. пример ниже):

  из datetime import datetime, timedelta
из pydantic import BaseModel
от pydantic.json импорт timedelta_isoformat


класс WithCustomEncoders (BaseModel):
    dt: datetime
    diff: timedelta

    класс Config:
        json_encoders = {
            datetime: лямбда v: v.timestamp (),
            timedelta: timedelta_isoformat,
        }


m = WithCustomEncoders (dt = datetime (2032, 6, 1), diff = timedelta (часы = 100))
печать (m.json ())
#> {"dt": 1969660800.0, "diff": "P4DT4H0M0.000000S"}

(Этот сценарий готов, он должен работать «как есть»)

По умолчанию timedelta кодируется как простое число с плавающей точкой из общего числа секунд.Предоставляется timedelta_isoformat
в качестве дополнительной альтернативы, которая реализует кодирование разницы во времени ISO 8601.

Сериализация подклассов

Примечание

Новое в версии v1.5 .

Подклассы общих типов не были автоматически сериализованы в JSON до версии v1.5 .

Подклассы общих типов автоматически кодируются как их суперклассы:

  от даты импорта даты и времени, timedelta
из pydantic import BaseModel
от pydantic.валидаторы импортируют int_validator


класс DayThisYear (дата):
    "" "
    Надуманный пример особого типа даты, который
    принимает int и интерпретирует его как день текущего года
    "" "

    @classmethod
    def __get_validators __ (cls):
        yield int_validator
        yield cls.validate

    @classmethod
    def validate (cls, v: int):
        return date.today (). replace (месяц = 1, день = 1) + timedelta (days = v)


класс FooModel (BaseModel):
    дата: DayThisYear


m = FooModel (дата = 300)
печать (м.json ())
#> {"date": "2020-10-27"}

(Этот сценарий готов, он должен работать «как есть»)

Пользовательская (де) сериализация JSON

Для повышения производительности кодирования и декодирования JSON альтернативные реализации JSON
(например, ujson) можно использовать через
json_loads и json_dumps свойств Config .

  из datetime import datetime
импорт ujson
из pydantic import BaseModel


класс User (BaseModel):
    id: int
    name = 'Джон Доу'
    signup_ts: datetime = Нет

    класс Config:
        json_loads = ujson.грузы


user = User.parse_raw ('{"id": 123, "signup_ts": 1234567890, "name": "Джон Доу"}')
печать (пользователь)
#> id = 123 signup_ts = datetime.datetime (2009, 2, 13, 23, 31, 30,
#> tzinfo = datetime.timezone.utc) name = 'Джон Доу'

(Этот сценарий готов, он должен работать «как есть»)

ujson обычно не может использоваться для дампа JSON, поскольку он не поддерживает кодирование таких объектов, как datetime, и делает
не принимать аргумент резервной функции по умолчанию .Для этого вы можете использовать другую библиотеку, например
orjson.

  из datetime import datetime
импорт orjson
из pydantic import BaseModel


def orjson_dumps (v, *, по умолчанию):
    # orjson.dumps возвращает байты, чтобы соответствовать стандартным json.dumps, которые нам нужно декодировать
    вернуть orjson.dumps (v, по умолчанию = по умолчанию) .decode ()


класс User (BaseModel):
    id: int
    name = 'Джон Доу'
    signup_ts: datetime = Нет

    класс Config:
        json_loads = orjson.loads
        json_dumps = orjson_dumps


user = Пользователь.parse_raw ('{"id": 123, "signup_ts": 1234567890, "name": "Джон Доу"}')
печать (user.json ())
#> {"id": 123, "signup_ts": "2009-02-13T23: 31: 30 + 00: 00", "name": "John Doe"}

(Этот сценарий готов, он должен работать «как есть»)

Обратите внимание, что orjson изначально заботится о кодировке datetime , что делает его быстрее, чем json.dumps , но
это означает, что вы не всегда можете настроить кодировку с помощью Config.json_encoders .

`рассол.свалки (модель)`

Использование той же сантехники, что и copy (). , pydantic Модели поддерживают эффективное травление и распаковку.

  маринад импортный
из pydantic import BaseModel


класс FooBarModel (BaseModel):
    а: ул
    b: int


m = FooBarModel (a = 'привет', b = 123)
печать (м)
#> a = 'привет' b = 123
data = pickle.dumps (м)
печать (данные)
"" "
b '\ x80 \ x04 \ x95m \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x8c \ x17exporting_models_pickle \ x9
4 \ x8c \ x0bFooBarModel \ x94 \ x93 \ x94) \ x81 \ x94} \ x94 (\ x8c \ x08__dict __ \ x94} \ x94 (\ x8c
\ x01a \ x94 \ x8c \ x05hello \ x94 \ x8c \ x01b \ x94K {u \ x8c \ x0e__fields_set __ \ x94 \ x8f \ x94 (
ч \ й \ х07 \ х90уб.'
"" "
m2 = pickle.loads (данные)
печать (м2)
#> a = 'привет' b = 123

(Этот сценарий готов, он должен работать «как есть»)

Расширенный включить и исключить

dict , json и copy методы поддерживают включают и исключают аргумента, которые могут быть
наборы или словари. Это позволяет вложенный выбор полей для экспорта:

  из pydantic import BaseModel, SecretStr


класс User (BaseModel):
    id: int
    имя пользователя: str
    пароль: SecretStr


класс Transaction (BaseModel):
    id: str
    пользователь: Пользователь
    значение: int


t = транзакция (
   ,
    user = Пользователь (
        id = 42,
        username = 'JohnDoe',
        пароль = 'hashedpassword'
    ),
    значение = 9876543210,
)

# используя набор:
печать (т.dict (exclude = {'пользователь', 'значение'}))
#> {'id': '1234567890'}

# используя dict:
print (t.dict (exclude = {'user': {'username', 'password'}, 'value': ...}))
#> {'id': '1234567890', 'user': {'id': 42}}

print (t.dict (include = {'id': ..., 'user': {'id'}}))
#> {'id': '1234567890', 'user': {'id': 42}}

Многоточие ( ... ) означает, что мы хотим исключить или включить весь ключ, как если бы мы включили его в набор.
Конечно, то же самое можно сделать на любом уровне глубины.

Следует проявлять особую осторожность при включении или исключении полей из списка или кортежа подмоделей или словарей.В этом сценарии
dict и связанные методы ожидают целочисленные ключи для поэлементного включения или исключения. Чтобы исключить поле из каждые
член списка или кортежа, ключ словаря '__all__' может использоваться следующим образом:

  импорт datetime
от ввода списка импорта

из pydantic import BaseModel, SecretStr


класс Country (BaseModel):
    имя: ул.
    phone_code: int


Адрес класса (BaseModel):
    post_code: int
    страна: Country


класс CardDetails (BaseModel):
    номер: SecretStr
    истекает: дата и время.Дата


класс Хобби (BaseModel):
    имя: ул.
    информация: ул.


класс User (BaseModel):
    first_name: str
    второе_имя: str
    адрес: Адрес
    card_details: CardDetails
    хобби: Список [Хобби]


пользователь = Пользователь (
    first_name = 'Джон',
    second_name = 'Лань',
    адрес = Адрес (
        post_code = 123456,
        country = Страна (
            name = 'США',
            phone_code = 1
        )
    ),
    card_details = CardDetails (
        number = 4212934504460000,
        expires = datetime.date (2020, 5, 1)
    ),
    хобби = [
        Хобби (name = 'Программирование', info = 'Написание кода и прочее'),
        Хобби (name = 'Gaming', info = 'Hell Yeah !!!'),
    ],
)

exclude_keys = {
    'фамилия': ...,
    'address': {'post_code': ..., 'country': {'phone_code'}},
    'реквизиты карты': ...,
    # Вы можете исключить поля из определенных членов кортежа / списка по индексу:
    'хобби': {-1: {'info'}},
}

include_keys = {
    'Имя': ...,
    'address': {'country': {'name'}},
    'хобби': {0: ..., -1: {'name'}},
}

# будет таким же, как user.dict (exclude = exclude_keys) в этом случае:
печать (user.dict (include = include_keys))
"" "
{
    'first_name': 'Джон',
    'address': {'country': {'name': 'USA'}},
    'увлечения': [
        {
            'name': 'Программирование',
            'info': 'Написание кода и прочее',
        },
        {'name': 'Gaming'},
    ],
}
"" "

# Чтобы исключить поле из всех членов вложенного списка или кортежа, используйте «__all__»:
печать (пользователь.dict (exclude = {'хобби': {'__all__': {'info'}}}))
"" "
{
    'first_name': 'Джон',
    'второе_имя': 'Лань',
    'адрес': {
        'post_code': 123456,
        'country': {'name': 'USA', 'phone_code': 1},
    },
    'реквизиты карты': {
        'номер': SecretStr ('**********'),
        'истекает': datetime.date (2020, 5, 1),
    },
    'хобби': [{'name': 'Программирование'}, {'name': 'Игры'}],
}
"" "

То же самое справедливо для методов json и copy .

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Экспертная модель: Экспертиза промышленной безопасности

Представления знаний в интеллектуальных системах, экспертные системы / Хабр

Введение

Экскурс в историю экспертных систем

Структура экспертной системы

Какие существуют модели представления знаний?

Продукционная МПЗ

Пример

Среды разработки продукционных систем(CLIPS)

Семантическая сеть МПЗ

Пример

Фреймовая МПЗ

Пример

Пример вырождающейся в сеть фреймов

Языки разработки фреймовых моделей (Frame Representation Language)

Формально логическая МПЗ

Пример

Важно

Заключение

Проходим госэкспертизу информационной модели правильно

II. Настраиваемый экспорт в IFC4

III. Проверка на ошибки

Агентное моделирование как инструмент исследования экспертной оценки объекта Текст научной статьи по специальности «Компьютерные и информационные науки»

Экспертная система — Википедия

Структура ЭС интеллектуальных систем

Режимы функционирования

Классификация ЭС

Классификация ЭС по решаемой задаче

Классификация ЭС по связи с реальным временем

Этапы разработки ЭС

Наиболее известные ЭС

См. также

Ссылки

Литература

Экспертная система. Классификация. Обзор существующих экспертных систем

Модель экспертных систем — Студопедия

Экспертная система — Википедия

Структура ЭС интеллектуальных систем

Режимы функционирования

Классификация ЭС

Классификация ЭС по решаемой задаче

Классификация ЭС по связи с реальным временем

Этапы разработки ЭС

Наиболее известные ЭС

См. также

Ссылки

Литература

Как: экспорт и импорт модели

В этой статье

Подготовка системы

Осушите клиентские соединения и проверьте разрешения

Экспорт файлов модели

Экспорт файла .axmodel (Windows PowerShell)

Экспорт файла .axmodel (AXUtil)

Импорт файла .axmodel

Импорт файла .axmodel (Windows PowerShell)

Импорт файла .axmodel (AXUtil)

См. Также

Экспорт моделей — документация по Stable Baselines 2.10.2a0

Фон

Экспорт в PyTorch

Экспорт в C ++

Ручной экспорт

Как: экспорт и импорт магазина моделей

В этой статье

Подготовка системы

Проверить разрешения

Экспорт магазина моделей

Экспорт магазина моделей (Windows PowerShell)

Экспорт магазина моделей (AXUtil)

Импорт модели магазина

Импорт хранилища моделей в схему dbo (Windows PowerShell)

Установить магазин моделей в схему dbo (AXUtil)

Импортировать хранилище модели во временную схему, а затем применить хранилище модели (Windows PowerShell)

Установите хранилище моделей во временную схему, а затем примените хранилище моделей (AXUtil)

См. Также

Экспорт моделей — pydantic

модель.dict (...)

dict (модель) и итерация

модель. Копия (...)

`модель.dict (...)`

`dict (модель)` и итерация

`модель. Копия (...)`

`модель.json (...)`

`json_encoders`

`рассол.свалки (модель)`