Разработка экспертной системы: Экспертные системы (Разработка)

Экспертные системы (Разработка)

2010/05/25 16:49:40

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

Требования по созданию

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

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

Оправданность использования

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

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

Технология создания экспертной системы

Соответствие приложения методам ЭС

Созданное приложение соответствует методам ЭС, если решаемая задача обладает совокупностью некоторых характеристик, а именно:

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

Концепция быстрого прототипа

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

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

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

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

• идентификация
• концептуализация
• формализация
• выполнение
• тестирование
• опытная эксплуатация

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

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

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

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

Связанные темы

Ссылки

Экспертные системы (Архитектура)

В структуру экспертной системы входят:

• решатель
• рабочая память или база данных
• база знаний (БЗ)
• компоненты приобретения знаний
• объяснительный компонент
• диалоговый компонент

Решатель

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

База данных

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

База знаний

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

Компоненты приобретения знаний

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

Объяснительный компонент

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

Диалоговый компонент

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

Работа экспертной системы

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

Режим приобретения знаний

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

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

Режим консультации

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

Представление знаний в экспертных системах

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

Вопрос формулирования знаний можно разделить на две достаточно независимые задачи: как организовать знания и как представить знания в нужной форме.

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

• определение состава представляемых знаний
• организация знаний
• представление знаний

При определении состава знаний учитываются следующие факторы:

• проблемная среда
• архитектура экспертной системы
• потребности и цели пользователей
• язык общения

С учетом архитектуры экспертной системы знания разделяют на интерпретируемые и неинтерпретируемые.
Первый тип: те знания, которые способен интерпретировать решатель. Все остальные относятся ко второму типу. Решатель не знает ни их структуры, ни содержания. Если эти
знания используются каким-либо компонентом системы, то он не «осознает» этих знаний.

Неинтерпретируемые знания

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

Интерпретируемые знания

Интерпретируемые знания можно разделить на предметные знания, управляющие знания и знания о представлении. Знания о представлении содержат информацию о том, каким образом в системе представлены интерпретируемые знания.

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

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

Связанные темы

Ссылки

Разработка экспертных систем

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

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

Этап 1. Идентификация

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

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

Этап 2. Концептуализация

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

Этап 3. Формализация

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

Этап 4. Реализация

Создается прототип экспертной системы, включающий базу знаний и другие подсистемы. На данном этапе применяются следующие инструментальные средства: программирование на обычных языках (Паскаль, Си и др.), программирование на специализированных языках, применяемых в задачах искусственного интеллекта (LISP, FRL, SmallTalk и др.) и др. Четвертый этап разработки экспертных систем в какой-то степени является ключевым, так как здесь происходит создание программного комплекса, демонстрирующего жизнеспособность подхода в целом. Средняя длительность 1-2 месяца.

Этап 5. Тестирование

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

Этап 6. Опытная эксплуатация

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

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

Экспертные системы. Принципы разработки и программирование

Description:

Книга «Экспертные системы: принципы разработки и программирование» представляет собой известный во всем мире учебник по экспертным системам и языку экспертных систем — CLIPS. В книгу включены сведения, относящиеся к двум основным направлениям: первое — излагается теория экспертных систем и показано, какое место занимают экспертные системы во всем объеме компьютерных наук. Второе направление представлено сведениями по программированию с помощью языка C-LIPS. Еще одним новым средством, описанным в данном издании, является объектно-ориентированный язык программирования COOL. В начале книги содержится отдельное введение в тематику искусственного интеллекта, объем которого достаточен для изучения экспертных систем
<P>
Теоретический материал в книге «Экспертные системы: принципы разработки и программирование» изложен на уровне, доступном для восприятия студентов старших курсов и аспирантов, интересующихся экспертными системами, которые специализируются в области компьютерных наук, информационных управленческих систем, в программотехнике и других областях.
<P>
Книга «Экспертные системы: принципы разработки и программирование» может оказаться полезной для широкого круга читателей, желающих применить экспертные системы в своей работе. <p><b>Оглавление:</b><p>Введение<br>
Глава 1. Введение в экспертные системы <br>
Глава 2. Представление знаний<br>
Глава 3. Методы логического вывода<br>
Глава 4. Рассуждения в условиях неопределенности <br>
Глава 5. Нестрогие рассуждения <br>
Глава 6. Проектирование экспертных систем <br>
Глава 7. Введение в CLIPS <br>
Глава 8. Развитые средства сопоставления с шаблонами <br>
Глава 9. Модульное проектирование, управление выполнением и эффективность правил <br>
Глава 10. Процедурное программирование <br>
Глава 11. Классы, экземпляры и обработчики сообщений <br>
Глава 12. Примеры проектов экспертных систем
<br>
Приложение А. Некоторые широко применяемые эквивалентности <br>
Приложение Б. Некоторые элементарные кванторы и их значение <br>
Приложение В. Некоторые свойства множеств <br>
Приложение Г. Информация о поддержке CLIPS <br>
Приложение Д. Общие сведения о командах и функциях CLIPS <br>
Приложение Е. Определение языка в нормальной форме Бэкуса–Наура <br>
Приложение Ж. Программные ресурсы <br>
Приложение З. Литература <br>
Предметный указатель

2. Структура экспертных систем. Базы данных: конспект лекций

2. Структура экспертных систем

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

Экспертные системы в общем случае подразделяются на статические и динамические.

Для начала рассмотрим статическую экспертную систему.

Стандартная статическая экспертная система состоит из следующих основных компонентов:

1) рабочей памяти, называемой также базой данных;

2) базы знаний;

3) решателя, называемого также интерпретатором;

4) компонентов приобретения знаний;

5) объяснительного компонента;

6) диалогового компонента.

Рассмотрим теперь каждый компонент более подробно.

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

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

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

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

Компонент объяснений разъясняет, как система получила решение данной задачи, или почему она это решение не получила и какие знания она при этом использовала. Иначе говоря, компонент объяснений создает отчет о проделанной работе.

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

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

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

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

Итак, на этом закончим пока рассмотрение статистической экспертной системы, перейдем к анализу экспертной системы динамической.

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

В отличие от статической экспертной системы в структуру динамической экспертной системы дополнительно вводятся два следующих компонента:

1) подсистема моделирования внешнего мира;

2) подсистема связей с внешним окружением.

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

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

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

Пример динамической экспертной системы – управление производством различных медикаментов в фармацевтической промышленности.

Поделитесь на страничке

Следующая глава >

Что такое медицинские экспертные системы (МЭС)

Что собой представляют экспертные системы, и какова их роль в сфере здравоохранения? Какие задачи они решают, и сможет ли компьютер однажды полностью заменить врача? Разбираемся, как устроена МЭС и чем она может быть полезна 

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

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

Какие задачи решают МЭС

Кадр из кинофильма “Люси” (Lucy)/ Universal Pictures

К медицинским задачам, которые могут быть решены с помощью ЭС, относятся:

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

Кто и где использует МЭС

Кадр из фильма “Мстители” (The Avengers)/​Marvel Studios, Paramount Pictures, Walt Disney Studios Motion Pictures

Первой разработкой экспертного ПО в медицине считается система MYCIN («Мицин»). Она была создана специалистами Стэнфордского университета в начале 70-​хх для определения возбудителей тяжелых инфекционных болезней и расчета нужных доз антибиотиков. Эффективность программы оценивалась в 69% – в стольких случаях было назначено корректное лечение. Важно отметить, что этот показатель был даже выше, чем у врачей-​инфекционистов, которые участвовали в исследовании. К сожалению, MYCIN не получил практического применения из-​за несовершенства технологий того времени.

Сейчас существует много примеров успешной разработки и использования МЭС в медицинской практике. Среди них можно выделить систему диагностики детских неотложных состояний «ДИН» (Московское НИИ педиатрии и детской хирургии), программу «АЙБОЛИТ» для выявления, типологии и уточнения терапии острых нарушений циркуляции крови у детей (Национальный медицинский исследовательский центр сердечно-​сосудистой хирургии им. А.Н. Бакулева), систему определения ведущей патологии и сопутствующего лечения с удаленным мониторингом тяжелых пациентов «ДИНАР» (Санкт-​Петербургский государственный педиатрический медицинский университет, Свердловская областная детская клиническая больница, при участии сотрудников Института биофизики УроРАН).

Классификация экспертных систем

Кадр из анимационного фильма «ВАЛЛ‑И» (WALL‑E)/​Walt Disney Studios Motion Pictures, Pixar Animation Studios

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

В зависимости от профиля решаемых задач, ЭС бывают:

• диагностические
• мониторинговые
• проектные
• прогностические
• планирующие
• обучающие
• интерпретирующие
• поддерживающие принятие решения

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

Еще экспертные системы делят по динамичности или по связи с реальным временем. Они могут быть статическими, динамическими или квазидинамическими, в зависимости от постоянства исходных данных, которые использует система. В квазидинамических ЭС изменения происходят интервально. Медицинские экспертные системы относятся к динамическому типу.

Компоненты МЭС

Кадр из фильма «Железный человек 2» (Iron Man II)/​Marvel Entertainment, Marvel Studios, Fairview Entertainment, Paramount Pictures

Любая экспертная система, вне зависимости от области ее применения, включает в себя следующие компоненты:

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

Рассмотрим, как все эти компоненты взаимодействуют друг с другом на практике.

Постановка диагноза при помощи МЭС

Кадр из фильма “РобоКоп” (RoboCop)/​Columbia Pictures MGM Strike Entertainment

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

Сначала выполняется сбор вводной информации об известных факторах, которые могут влиять на появление болезни, и их значимости. Это можно сделать, например, при помощи анкетирования пациентов с подтвержденным диагнозом, а также группы людей, у которых точно отсутствует рассматриваемая патология – в качестве контрольной группы. Далее методами многомерного анализа процедуру принятия решения по имеющимся исходным данным раскладывают на составляющие, воспроизводя аналитический процесс врача-​эксперта. На выходе получают некий набор признаков болезни (и ее отсутствия) и правил распределения пациентов между группами «риск» и «норма». Алгоритм тестируется на новой выборке и корректируется при выявлении ошибок. Итоговый набор правил вносится в базу знаний ЭС.

Кадр из фильма “Мой друг робот” (Robbi, Tobbi und das Fliewatüüt)/​StudioCanal

На приеме врач собирает анамнез (исходные данные) и вводит его в систему, используя персональный компьютер. Это может происходить в режиме диалога с программой (вопрос-​ответ) или выглядеть как заполнение определенной формы-​опросника, которая структурирует информацию для ЭС. Эти сведения попадают в рабочую память. Далее ЭС «прогоняет» их через логические правила, которые заложены в ее базу знаний, выдает ответ, с пояснением, как программа пришла к такому заключению. Пояснение может быть представлено как в графической, так и в письменной форме. Достоверность суждения экспертной системы выражается коэффициентом уверенности (K) – числовой характеристикой ложности или справедливости вывода. «K» находится в диапазоне от 1 до 0. Заключение ЭС может выглядеть следующим образом: «Пациент с низкой степенью уверенности (К=0,344) отнесен к группе риска по развитию атеросклероза». Или: «Пациент с высокой степенью уверенности (К=0,943) отнесен к группе риска по развитию атеросклероза. Рекомендовано УЗИ сердца».

Кадр из фильма “Мой друг робот” (Robbi, Tobbi und das Fliewatüüt)/​StudioCanal

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

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

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

Читайте еще: «Практика разработки и внедрения системы менеджмента качества в медицинской организации»

System ekspertowy — Википедия, wolna encyklopedia

System ekspertowy — pojęcie zakresu sztucznej inteligencji, oznacza system komputerowy, który emuluje w podejłjiowania 9000.

Systemy ekspertowe rozwiązuj złożone problemy na podstawie analysis bazy wiedzy, a nie realizacji prostego algorytmu, jak to ma miejsce w przypadku programów tradycyjnych ^{000 [2]} . .

Systemy ekspertowe składają się z co najmniej dwóch elementów:

• «silnika» — programu umożliwiającego zadawanie pytań i szukającego odpowiedzi na zadane pytania,
• bazy danych, na podstawie analizy której udzielane są odpowiedzi ^[5] .

Система экспертного брака Фейгенбаума [edytuj | эдитуй код]

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

Przykładowe obszary zastosowań systemów ekspertowych [edytuj | эдитуй код]

• диагностика цвета
• poszukiwanie złóż minerałów
• Идентификационная структура молекулярных
• udzielanie porad prawnych
• диагностика проблемы (нп.nieprawidłowego działania urządzenia)
• dokonywanie wycen i kalkulacji kosztów naprawy pojazdów przez zakłady ubezpieczeniowe
• прогноз погоды
• роботы, автоматические пояса, ракеты czy статками космические
• анализ notowań giełdowych

Szkielety systemów ekspertowych [edytuj | эдитуй код]

Klasycznym językiem używanym przy tworzeniu systemów eksperckich jest Prolog. Obecnie zamiast tworzyć je od podstaw, używa się gotowych szkieletów systemów ekspertowych (англ. оболочка экспертной системы ). Szkielet taki to właściwie gotowy system ekspertowy pozbawiony wiedzy.

Najpopularniejsze, dostępne bezpłatnie szkielety systemów ekspertowych:

Równie popularny, płatny szkielet systemu ekspertowego:

Składniki systemu ekspertowego to:

• szkielet systemu składający się z:
  • interfejsu użytkownika — który umożliwia zadawanie pytań, udzielanie informacji systemowi oraz odbieranie od systemu odpowiedzi i wyjaśnień,
  • edytora bazy wiedzy — który pozwala na modyfikację wiedzy zawartej w systemie, umożliwiając tym samym jego rozbudowę,
  • Mechanizmu wnioskowania — który jest głównym składnikiem systemu ekspertowego wykonującym cały process rozumowania w trakcie rozwiązywania problemu postawionego przez użytkownika,
  • Mechanizmu wyjaśniającego — jednego z elementów interfejsu pomiędzy systemem a użytkownikiem, który umożliwia użytkownikowi uzyskanie odpowiedzi dlaczego system, udzieliło dlaczego system, udzieli
• baza wiedzy — шутка о декларации постац wiedzy ekspertów z danej dziedziny zapisana za pomocą wybranego sposobu репрезентация wiedzy, najczęściej reguł lub ram;
• baza danych zmiennych — która jest pamięcią roboczą przechowującą pewne fakty wprowadzone w trakcie dialogu z użytkownikiem; baza ta umożliwia odtworzenie sposobu wnioskowania systemu i przedstawienie go użytkownikowi za pomocą mechanizmu wyjaśniającego.

Ekstrakcj wiedzy od ekspertów zajmują się na ogół inżynierowie wiedzy. Jest to zwykle długi i mudnycesses, ponieważ wiedza stosowana przez ekspertów ma charakter intuicyjno-praktyczny, często trudny do zwerbalizowania.

1. ↑ Питер Джексон: Введение в экспертные системы . Wyd. 3. Эддисон Уэсли, 1998, с. 2. ISBN 978-0-201-87686-4.
2. ↑ Нвигбо Стелла и Агбо Окечуку Чукс, Школа естественнонаучного образования, Экспертная система: катализатор развития образования в Нигерии: „ Способность этой системы объяснять процесс рассуждений с помощью обратных трассировок (…) предоставляет дополнительную функцию, которую обычное программирование не поддерживает ».
3. ↑ Регина Барзилай, Дэрил Маккалоу, Оуэн Рэмбоу, Джонатан ДеКристофаро, Таня Корельски, Бенуа Лавуа: «Новый подход к объяснению экспертных систем».
4. ↑ Обычное программирование.
5. ↑ Нвигбо Стелла и Агбо Окечуку Чукс, Школа естественнонаучного образования, Экспертная система: катализатор развития образования в Нигерии: « Системы, основанные на знаниях, собирают небольшие фрагменты человеческого ноу-хау в базу знаний, которая используется для рассуждений. через проблему, используя знания, которые присваиваются ».
6. ↑ Pozyskiwanie wiedzy 1997 , www.kkiem.agh.edu.pl [dostęp 2016-06-28].

Инструмент разработки экспертных систем Exsys Corvid

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

Corvid — это результат более чем 28-летнего сотрудничества с предприятиями и организациями над созданием инструмента, основанного на том, что разработчикам необходимо для создания реальных систем. Он требует очень прагматичного подхода к разработке системы — облегчить разработчикам создание и внедрение систем как можно быстрее. Используя онлайн-руководства, большинство пользователей могут начать создавать небольшие системы за несколько часов. Несмотря на простоту в использовании, Corvid использовался для создания очень сложных систем.

Corvid решает 3 основных вопроса при разработке экспертной системы:

• Полное описание логики принятия решений и процесса эксперта в предметной области
• Обертывание системы в пользовательском интерфейсе с желаемым внешним видом
• Интеграция с другими ИТ-ресурсами

Если экспертная система не содержит необходимой логики для решения проблемы, все остальное не имеет значения. Corvid предоставляет несколько способов описания логики, поэтому можно использовать соответствующий подход к проблеме.Corvid использует «эвристические» правила If / Then, основанные на переменных. Существует 7 типов переменных, от довольно стандартных числовых и строковых переменных до переменных-коллекций для динамических отчетов или доверительных переменных, которые упрощают построение вероятностных систем. Переменные имеют связанные методы и свойства, позволяющие использовать их разными способами.

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

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

В дополнение к логическим блокам и блокам действий, которые содержат правила, Corvid имеет блоки команд, которые описывают процедурный поток выполнения системы.Командные блоки больше похожи на скрипт, но также допускают циклы IF, WHILE и FOR. Отделив процедурный контроль от логики правил, намного проще создавать, поддерживать и обновлять системы.

Некоторые проблемы носят более процедурный характер, и Corvid поддерживает их с опцией прямой цепочки. Другие используют правила истинным «эвристическим» способом, вызывая и используя правила динамически, по мере необходимости, посредством обратной цепочки. Exsys Inference Engine предоставляет оба варианта, и они могут быть смешаны для максимальной гибкости.

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

После того, как логика заработает, следующим шагом будет разработка пользовательского интерфейса. Corvid также упрощает этот шаг и не требует от разработчика знания HTML для онлайн-доставки. Системы Corvid могут работать либо с Exsys Inference Engine как Java-апплет, либо как программа Java Servlet Runtime.В режиме апплета по умолчанию экраны определяются установкой шрифтов, цветов, позиций, изображений и т. Д. Это похоже на форматирование документа Word. Для более сложных интерфейсов можно использовать карты изображений. Среда выполнения Corvid будет использовать настройки для управления тем, как будут задаваться вопросы и как будут представлены результаты. Более продвинутые системы могут создавать отчеты в формате HTML, RTF или PDF. При использовании Applet Runtime Corvid автоматически генерирует все файлы, необходимые для размещения системы на веб-сервере.

Для систем, которым требуется больший контроль над пользовательским интерфейсом или которые будут работать на стороне сервера, существует Corvid Servlet Runtime. Эта дополнительная программа реализует механизм вывода Corvid как сервлет Java. В этом режиме пользовательский интерфейс определяется шаблонами HTML. Вместе с Corvid предоставляется множество базовых шаблонов, которые можно легко редактировать с помощью любого редактора HTML. Здесь необходимы небольшие знания HTML, но можно создавать очень сложные и продвинутые пользовательские интерфейсы.

Для наиболее сложных пользовательских интерфейсов системы Corvid могут быть интегрированы с Adobe Flash с помощью Corvid Servlet Runtime. Приложение Flash отправляет данные в среду выполнения Corvid, которая обрабатывает их и отправляет обратно XML-данные во Flash. Это может повторяться много раз, что позволяет интегрировать Flash-приложения с мощными аналитическими возможностями ваших экспертных систем Corvid.

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

Экспертным системам часто требуется интегрироваться с другими ресурсами для получения данных, сохранения результатов или мониторинга процессов. Corvid упрощает подключение к базам данных с помощью команд SQL и данных XML с помощью команд XPath. Corvid может читать файлы данных или потоки и может отправлять информацию широкому кругу программ. Для наивысшего уровня контроля в программы Corvid Runtime можно добавить собственный Java-код, добавив любые специальные функции, которые могут понадобиться тесно интегрированной системе.

Corvid позволяет быстро создавать системы. Простой читаемый синтаксис правил позволяет экспертам в предметной области либо создавать системы самостоятельно, либо эффективно работать с группами разработчиков. Пользовательские интерфейсы могут быть добавлены в соответствии с внешним видом веб-сайта или добавлены командой дизайнеров независимо от системной логики. Интерфейсы к внешним ресурсам гибкие и простые в настройке.

Corvid сделает разработку вашей экспертной системы успешной. Загрузите 30-дневную демо-версию Corvid, чтобы попробовать ее.Запустите онлайн-руководства, и вы будете создавать небольшие системы за несколько часов. Свяжитесь с нами, чтобы обсудить, как Corvid может наилучшим образом вписаться в ваши планы развития экспертной системы.

Бесплатная IDE для Linux, macOS, Windows, встраиваемых систем

Загрузите бесплатные ознакомительные версии SwiftForth и SwiftX. Все системы SwiftForth и SwiftX включают полную документацию и справочные материалы в файлах PDF. (Требуется Adobe Reader.) У наших ознакомительных версий нет ограничений по времени. Используйте их столько, сколько хотите; обновитесь до полностью лицензионной версии, когда будете готовы.

SwiftForth для Windows, Linux и macOS

SwiftForth — это быстрая и эффективная система разработки ANS Forth для сред Windows, Linux и macOS.

* SwiftForth для Linux и macOS распространяется в виде архива. Пожалуйста, прочтите инструкции по установке для получения информации о том, как распаковать tarball и настроить SwiftForth для использования. Не волнуйтесь, это просто.

После установки документацию SwiftForth можно найти в каталоге SwiftForth / doc.Полная информация о настройке, настройке вашего собственного редактора и использовании SwiftForth находится в каталоге doc. Так что начните сначала с этого!

Системные требования:

• i386-совместимый процессор
• SwiftForth для Windows: Windows Vista или более поздняя версия
• SwiftForth для Linux: ядро ​​Linux 2.6 с поддержкой 32-битной библиотеки
• SwiftForth для macOS: macOS до 10.14 (Mojave )
  (Примечание: SwiftForth требует 32-битных библиотек и не будет работать на Catalina.)

SwiftX для встраиваемых систем

SwiftX — это интерактивная среда разработки (IDE) и кросс-компилятор для разработки, отладки и тестирования кода прошивки для микроконтроллеров и микропроцессоров. SwiftX доступен для процессорных ядер ARM, ColdFire, MSP430, AVR, 68HCS08, 68HC12, 68K, 68HC11 и 8051. SwiftX также доступен для микропроцессоров Rad-Hard UT69R000 и RTX2010RH для использования в космических и радиационно-интенсивных приложениях.

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

После установки документацию SwiftX можно найти в каталоге SwiftX / doc. Мы настоятельно рекомендуем устанавливать каждую ознакомительную версию SwiftX по пути по умолчанию, предлагаемому установщиком Windows.

Требования к хост-системе:

• Windows Vista или новее
• USB или COM-порт для интерфейса отладки

PC AI — Expert Systems

О Научном центре медицинской экспертизы Продукция

Федеральное государственное бюджетное учреждение «Научный центр экспертизы лекарственных средств» Министерства здравоохранения Российской Федерации (ФГБУ «НЦЭМП» Министерства здравоохранения Российской Федерации) — бюджетная организация, действующая независимо от разработчиков. и производители фармацевтических препаратов.ФГБУ «ГЦЭМП» Минздрава России проводит оценку лекарственных средств в соответствии с принципом, изложенным в Федеральном законе № 61-ФЗ «Об обращении лекарственных средств». Оценка лекарственных средств проводится исключительно для Министерства здравоохранения Российской Федерации в рамках задания на тестирование.

Минздрав Российской Федерации использует заключения ФГБУ «ГЦВЭМП» Минздрава России в качестве основания для разрешения на проведение клинических исследований и разрешения на продажу лекарственных средств.

ФГБУ «НЦЭМП Минздрава России» — ведущая организация в области экспертной оценки лекарственных средств, производимых как в России, так и за рубежом. Специалисты ФГБУ «НЦЭМП» Минздрава России проводят различные виды оценки в контексте следующих нормативных процедур: одобрение клинических исследований, выдача регистрационных свидетельств и утверждение постмаркетинговых изменений уже разрешенных лекарственных средств. .Специалисты ФГБУ «НЦЭМП» Минздрава РФ проверяют лекарственные средства на качество и потенциальную пользу для пациентов.

Лаборатории ФГБУ «НЦЭМП» Минздрава России оснащены современным лабораторным оборудованием для оценки качества лекарственных средств. Лаборатория ежегодно обновляется. Это позволяет нам проводить лабораторную оценку инновационных лекарственных средств, разработанных на основе современных биомедицинских технологий, в том числе клеточных.

Миссия

В соответствии с его ролью в системе государственного регулирования, миссия ФГБУ «ГЦЭМПЗ» Министерства здравоохранения Российской Федерации заключается в обеспечении предоставления лекарственных средств надлежащего качества и эффективности, соответствующих требованиям фармацевтической и биологической безопасности, а также обеспечить российскую систему здравоохранения качественными, безопасными и эффективными лекарствами, произведенными как в России, так и за рубежом.

Наша команда

Оценка лекарственных средств в ФГБУ «ГЦЭМП» Минздрава РФ проводится только специалистами соответствующей квалификации, сдавшими профессиональные аттестационные экзамены Минздрава РФ.Каждые пять лет эксперты должны подтверждать свою квалификацию, и для этого они должны сдавать квалификационные экзамены (включая тесты и собеседования по соответствующим специальностям), которые проводит специальная комиссия Министерства здравоохранения Российской Федерации. Любой специалист с медицинским, биологическим, химическим или фармацевтическим образованием или со степенью в любой из этих научных областей может подать заявку на должность эксперта в ФГБУ «ГЦЭМПЗ» Министерства здравоохранения Российской Федерации.

Экспертные знания сотрудников и технические возможности ФГБУ «ГЦЭМПЗ» Минздрава России позволяют развивать и совершенствовать подходы к оценке лекарственных средств посредством научных исследований; выполнение различных заданий Минздрава России по оценке лекарственных средств; повышение компетентности заинтересованных сторон в сфере обращения лекарственных средств через образовательные и обучающие программы.

Помимо экспертной оценки лекарственных средств, ФГБУ «ГЦЭМП» Минздрава России осуществляет следующие виды деятельности:

• сертификация иммунобиологических препаратов

• оценка безопасности лекарственных средств

• определение взаимозаменяемости лекарственных средств

• разработка монографий

• экспертно-аналитическое обеспечение Государственного реестра лекарственных средств

• организация тренингов и образовательных программ с целью повышения профессиональной компетентности заинтересованных сторон в сфере обращения лекарственных средств.Тренинги охватывают широкий спектр тем, в том числе: государственное регулирование обращения лекарственных средств, требования GMP, GLP и GCP

.

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

• распространение промышленных образцов фармацевтических субстанций и штаммов микроорганизмов.

Использование передового международного опыта

ФГБУ «ГЦВЭМП» Минздрава России использует передовой мировой опыт.

Семь лабораторий Испытательного центра оценки качества лекарственных средств ФГБУ «ГЦНИМП» Минздрава России имеют статус «Лабораторий контроля качества, прошедших преквалификацию ВОЗ». Эти лаборатории полагаются на рекомендованные ВОЗ стандарты качества в своей повседневной деятельности и могут быть уполномочены агентствами ООН для проведения тестирования лекарственных препаратов. В России всего две организации, которые имеют лаборатории по контролю качества, прошедшие преквалификацию ВОЗ, и ФГБУ «ГЦВЭМП» Минздрава России — одна из них.

Кроме того, четыре лаборатории ФГБУ «SCEEMP» Министерства здравоохранения Российской Федерации были аттестованы EDQM (Европейским директоратом по качеству лекарственных средств и медицинской помощи) посредством взаимных совместных аудитов (MJA). Это означает, что лаборатории Испытательного центра соответствуют требованиям европейских стандартов.

Иностранные партнеры

ФГБУ «SCEEMP» Министерства здравоохранения Российской Федерации представляет Российскую Федерацию в Программе ВОЗ по международному мониторингу лекарственных средств.Россия участвует в этой программе с 1997 года. В рамках программы ФГБУ «ГЦЭМП» Минздрава России, а именно Испытательный центр экспертизы качества лекарственных средств, вправе представить индивидуальный случай. отчеты о безопасности (ICSR), составляемые в России в Сотрудничающий центр ВОЗ по международному мониторингу лекарственных средств (UMC) на регулярной основе (не реже одного раза в 3 месяца).

Специалисты ФГБУ «SCEEMP» Минздрава России, занимающиеся написанием монографий, тесно сотрудничают со своими коллегами из Международной фармакопеи ВОЗ, региональной Европейской фармакопеи, национальных фармакопей США, Великобритании, Франции, Япония, Украина, Республика Беларусь, Республика Казахстан и другие страны.Такое сотрудничество способствует гармонизации российских и международных требований к качеству лекарственных средств.

ФГБУ «ГЦЭМП» Минздрава РФ участвует в работе Европейского экономического союза, а именно в формировании единого рынка лекарственных средств.

В конце 2016 года был подписан Меморандум о взаимопонимании между национальными регулирующими органами России и Республики Куба. Сотрудничество между Центром государственного контроля над лекарственными средствами Республики Куба и ФГБУ «ГКНЛС» Министерства здравоохранения Российской Федерации осуществляется в основном в сфере регулирования обращения лекарственных средств и сопровождения проектов, связанных с трансфером технологий.