Технология создания экспертных систем Этапы создания экспертной системы
На начальных этапах идентификации и концептуализации, связанных с определением контуров будущей системы, инженер по знаниям выступает в роли ученика, а эксперт – в роли учителя, мастера. На заключительных этапах реализации и тестирования инженер по знаниям демонстрирует результаты разработки, адекватность которых проблемной области оценивает эксперт. На этапе тестирования это могут быть совершенно другие эксперты.
На этапе тестирования созданные экспертные системы оцениваются с позиции двух основных групп критериев: точности и полезности.
С точностью работы связаны такие характеристики, как правильность делаемых заключений, адекватность базы знаний проблемной области, соответствие применяемых методов решения проблемы экспертным. Поэтому ключевые оценки системе ставят специалисты в проблемной области – эксперты. Полезность же экспертной системы характеризуется степенью удовлетворения требований пользователя в части получения необходимых рекомендаций, легкости и естественности взаимодействия с системой, надежности, производительности и стоимости эксплуатации, способности обоснования решений и обучения настройки на изменение потребностей. Оценивание экспертной системы осуществляется по набору текстовых примеров как из предшествующей практики экспертов, так и специально подобранных ситуаций. Результаты тестирования подлежат статистической обработке, после чего делаются выводы о степени точности работы экспертной системы.
Разработка экспертных систем на Prolog
Экспертная система — компьютерная программа, которая, как и любая другая программа, получает какие-то данные на вход и формирует другие данные на выходе. Особенность в том, что целью работы экспертной системы является замена эксперта (человека) в некоторой предметной области. Естественно, работают такие программы без магии, а по вполне определенному алгоритму. От некоторых других видов интеллектуальных систем они отличаются большим объемом знаний эксперта, необходимым для принятия решения. Например, система, которая контролирует температуру в мангале при жарке шашлыка не может называться экспертной системой.
Экспертные системы создаются для самых различных предметных областей, например:
- созданы системы медицинской диагностики, которые по набору симптомов назначают анализы, по результатам которых ставится диагноз и определяется курс лечения [1, 2];
- экспертные системы могут следить за соблюдением правил дорожного движения [3] и даже оценивать военную безопасность государства [4].
Так или иначе, в процессе использования в систему попадают факты пользователя, чаще всего это происходит в форме диалога, при этом система формирует вопросы исходя их данных в базе и данных ранее ответов. Например, система Akinator [5], угыдывающая задуманного пользователем персонажа мультфильма, может спросить «является ли ваш персонаж человеком?».
Важно, что все экспертные системы, вне зависимости от предметной области, имеют схожую структуру — на самом деле, какая разница «угадывает» система диагноз по симптомам или персонажа мультфильма по его параметрам? По этой причине для разработки часто используются специальные инструменты создания типовых систем или заготовки систем, в которые эксперту нужно лишь внести данные и правила, однако, в этой статье мы посмотрим как сделать простейшую экспертную систему на языке Prolog.
На рисунке ниже схематично приведена структура такой системы. В некоторых системах встречается модуль объяснения решения, который поясняет пользователю результаты работы (почему выставлен именно такой диагноз, например). Иногда, система обучается в процессе диалога с пользователем, при этом в базу данных заносятся новые факты.
Важно понимать, что база данных содержит факты, а база знаний — правила вывода решений на основе фактов и введенных пользователем данных. Правила представляют собой, по сути, исходный код программы, — именно поэтому для разработки экспертных систем удобно использовать языки типа SWI Prolog, ведь они позволяют добавлять новые правила в программу прямо во время ее исполнения. Чтобы понять как разработанная система работает и как запустить приведенный код стоит пройти по ссылкам [6, 7].
Ниже приведен пример разработки сильно упрощенной экспертной системы, помогающей студенту выбрать тему дипломной работы.
1 Обзор предметной области
Так как в основе любой экспертной системы находится база данных, то разработка начинается с анализа предметной области. Тут надо понять какие критерии стоит учитывать при подборе темы дипломной работы. Темы выпускных работ обычно формируют преподаватели исходя из своих интересов. Студент выбирает тему бакалаврской работы из набора имеющихся с учетом:
- желания работать с преподавателем, выдающим тему.
- своих интересов;
- сложности темы (по экспертной оценке руководителя темы);
- своих знаний по теме работы;
- владению необходимыми технологиями если они указаны руководителем как обязательные.
Например, если студент при обучении у преподавателя Пупкина с трудом получил тройку — маловероятно он пойдет к нему на дипломирование. Если студент ничего не знает в области блокчейна, но ему хотелось бы развиваться в этой сфере — возможно он выберет соответствующую тему. Тема работы «Разработка клиент-серверного приложения для игры в покер» может быть интересна студенту, но он не возьмет ее если руководитель требует писать сервер на Erlang, а студент не любит функциональное программирование.
Таким образом, предметная область задачи состоит из сущностей:
- руководитель ВКР;
- область интересов;
- тема ВКР;
- технология выполнения;
- студент.
Модель предметной области с использованием нотации диаграммы классов UML [8] приведена на рисунке: 
2 Наполнение базы данных
Исходя из информации, изложенной в обзоре предметной области, ясно, что хранить программа должна темы и данные студента. Однако, данные студента вводятся в процессе диалога с ним и не должны храниться после чтобы не влиять на работу с системой следующего пользователя. Таким образом, в базе надо хранить лишь информацию о темах.
Для наполнения базы были найдены темы ВКР, по первому запросу поисковая система выдала информацию о темах Высшей школы экономики [9]. Однако, опубликованный список тем содержит лишь информацию о названии и руководителе, остальная информация была сформирована мной и не является точной — данные в базу данных экспертной системы должен вносить эксперт (руководитель ВКР).
В результате создана такая база данных:
На этом этапе можно лишь перебрать все записи базы и вывести их запросом:
?- theme(Theme, Name, Complex, knowledge_areas(Areas), skills(Skills)).
3 Алгоритмы работы экспертной системы (формирование базы знаний)
3.1 Выбор руководителей
Чтобы посоветовать тему, экспертная система должна получить информацию о студенте. Для начала можно узнать с какими преподавателями он готов работать. Для этого соберем список из всех преподавателей и выведем ему их под номерами. Пусть студент введет номера подходящих ему руководителей.
Собрать всех преподавателей можно так:
Встроенный предикат findall находит все решения предиката, переданного вторым аргументом и формирует из решений список. Однако, имена в таком списке могут повторяться — если у одного преподавателя было несколько тем то интерпретатор найдет его имя несколько раз. Поэтому следом вызывается предикат list_to_set , который убирает из списка повторы.
Теперь надо вывести эти имена списком так, чтобы к каждому имени был привязан номер. Это позволит пользователю не вводя имя (в котором легко сделать опечатку) выбрать нужные имена. Для этого описан предикат, принимающий на вход список и начальный номер и выводящий элементы списка в столбик так, что у каждого следующего элемента номер на единицу больше. Также написан предикат, выполняющий запрос всех имен (как показано выше) и выводящий их:
Результат выполнения запроса:
Теперь можно запросить у пользователя список имен и выбрать соответствующих номерам преподавателей:
Тут предикат select_names после вывода списка преподавателей запрашивает список номеров и передает их в предикат nths_1 , который выбирает элементы списка соответствующие списку номеров (нумерация начинается с единицы). если введены неверные данные — то выведется сообщение об ошибке и процесс повторится (рекурсивно):
3.2 Выбор области знаний
Теперь, когда выбраны предполагаемые — можно собрать список областей знаний в которых у них есть темы и выдать их в виде такого же списка.
Сначала можно получить список всех областей в которых есть темы у выбранных руководителей:
этот предикат сначала перебирает руководителей с помощью встроенного предиката member , затем перебирает все темы этого руководителя в базе, для каждой из них получает список областей. Искомая область принадлежит этому списку. Перебрать все области опять помогает member .
Теперь можно собрать все эти области в список и убрать из него повторы:
Мы смогли получить по списку имен руководителей список областей в которых они работают без повторов, выведем этот список на экран чтобы студент смог выбрать интересующие его области:
В настоящий момент можно написать такую цель:
?- select_names(Names), select_areas(Names, Areas).
с ее помощью мы сначала просим выбрать имена, а затем области. Результат ее выполнения:
3.3 Указание компетенций студента
Аналогичным образом можно запросить у пользователя набор его компетенций. Для этого можно описать правила поиска всех компетенций, которые требуются в темах выбранных преподавателей по выбранным областям, примерно так:
Дадим пользователю выбрать навыки из имеющегося списка:
Дальше надо убрать из выдачи темы, для выполнения которых у студента не хватает компетенций…
3.4 Выбор темы
Для выбора тем, соответствующих всем выбранным критериям написан такой предикат:
Итак, он перебирает все темы в базе данных и для каждой из них проверяет следующее:
- имя преподавателя есть в списке Names ;
- среди областей знаний темы есть тема из выбранного пользователем списка (проверяется с помощью двух вызовов member — выбери такой Area в списке Areas , что такой же Area есть в списке ThemeAreas );
- проверяет что НЕТ такого навыка в теме, что им НЕ владеет студент.
Для реализации последней части используется два отрицания. Так:
\+ member(Skill, Skills)
проверяет что навыка Skill нет в списке Skills. Список Skills — навыки студента.
первый оператор \+ стоит перед группой (почти лямбда-функцией) и завершится успешно если вся группа «провалится». Группа провалится если среди навыков темы найдется такой Skill, что его нет у студента. Таким образом весь приведенный в последнем листинге фрагмент завершится если у студента есть все необходимые навыки для выполнения темы.
Все описанные выше предикаты собраны (вызываются) в предикате выбора темы так:
То есть если на каком то этапе оказалось что система не может помочь — например, нет преподавателя, с которым хотел бы работать студент — то процесс подбора темы прерывается с сообщением о проблеме.
Результат подбора темы:
На приведенном рисунке видно, что одна и та же тема выведена дважды. Чтобы убрать это — все названия помещаются в список, который преобразуется во множество:
4 Итоги
Видно, что для создания экспертной системы надо сначала проанализировать предметную область и понять какие данные стоит сохранять в системе, а также определиться с набором правил, по которым система может принимать решения. Затем, стоит описать данные и правила на языке программирования. В созданной тут системе нет никакого интерфейса для эксперта, таким образом система является статической.
Исходный код разработанной системы доступен в репозитории [10], пример ее использования: 
Предлагаю посмотреть несколько похожих по структуре экспертных систем, написанных на других диалектах языка Prolog:
13. Экспертные системы: технология, этапы создания, применение
DEF Экспертная система – коммерческое приложение идей искусственного интеллекта; система, основанная на знаниях; сложный программный комплекс, аккумулирующий знания специалистов в конкретных предметных областях и тиражирующий этот опыт для консультации менее квалифицированных пользователей. Экспертная система делается для людей, работающих в предметной области, но имеющих невысокую квалификацию.
В общем виде все системы, основанные на знаниях, можно разделить на
- Системы, решающие задачи синтеза. Множество задач потенциально неограниченно и строится на решении компонентов или подпроблем.
- Интерпретация данных
- Диагностика
- Поддержка принятия решений
- Проектирование
- Планирование
- Управление
Состав команды разработки экспертной системы:
Пользователь – специалист предметной области, для которой предназначена система. Обычно его квалификация недостаточно высока, поэтому он нуждается в помощи и поддержке.
Аналитик (инженер по знаниям, когнитолог, инженер-интерпретатор) – специалист в области искусственного интеллекта, играющий роль посредника между экспертом и базой знаний.
База знаний – ядро экспертной системы; совокупность знаний предметной области, представленная в форме, понятной эксперту и пользователю. Обычно на некотором языке, близком к естественному.
Решатель (дедуктивная машина, машина вывода, блок логического вывода) – программа, моделирующая ход рассуждений эксперта на основании знаний, имеющихся в базе знаний.
Подсистема объяснений – программа, позволяющая пользователю получить ответы на вопросы, как была получена та или иная рекомендация, почему машина приняла именно такое решение. Ответ на вопрос «как?» – трассировка всего процесса получения решения с указанием использованных фрагментов базы знаний. Ответ на вопрос «почему?» — ссылка на умозаключение, предшествовавшее полученному решению
Интеллектуальный редактор – программа, позволяющая аналитику создавать базу знаний в диалоговом режиме.
Классификация экспертных систем:
- По задаче:
- Интерпретация данных – определение смысла данных, результаты которого должны быть согласованными (осмысленными) и корректными. Обычно предусматривается многовариантный анализ данных.
- Диагностика – процесс соотнесения объекта с некоторым классом объектов и/или обнаружение неисправностей в некоторой системе. Неисправность – отклонение от нормы. Такая трактовка позволяет с единых теоретических позиций рассматривать и неисправности оборудования в технических системах, и заболевания живых организмов, и природные аномалии, и пр.
- Проектирование – подготовка спецификаций на создание объектов с заранее определёнными свойствами.
- Спецификация – весь набор необходимых документов. Основная проблема – получение чёткого структурного описания знаний об объекте. Для организации эффективного проектирования и, особенно, перепроектирования, необходимо формировать не только проектные решения, но и мотивы их принятия. В задачах такого класса тесно связаны процессы вывода и объяснения решения.
- Статические – разрабатываются в предметных областях, в которых база знаний и интерпретируемые данные не меняются во времени.
- Пример: диагностика неисправностей в автомобиле.
- Пример: микробиологические экспертные системы, в которых снимаются лабораторные измерения с технологического процесса. Полученные показатели и их динамика анализируются.
- На супер-ЭВМ
- На ЭВМ средней производительности (мейнфреймы)
- На символьных процессорах
- На рабочих станциях
- На ПК
- Автономные – работают непосредственно в режиме консультации с пользователем для специфических экспертных задач. В них не требуется привлекать традиционные методы обработки данных.
- Гибридные – программный комплекс, агрегирующий стандартные пакеты прикладных программ и средства манипулирования знаниями. Разработка таких систем гораздо сложнее автономных систем.
- Пример: интеллектуальная надстройка над пакетом прикладных программ.
Требования к команде разработки экспертной системы:
Пользователь. Основное требование – базовый уровень квалификации, позволяющий ему правильно истолковывать рекомендации системы. Должна быть полная совместимость терминологии системы с терминологией пользователя. Остальные требования: дружелюбие, отсутствие психологического барьера к использованию ЭВМ, умение объяснить, что он хочет от системы.
Эксперт. Основное требование – готовность поделиться знаниями. Остальные требования: умение объяснять, заинтересованность, высокий профессионализм в своей области.
Программист. Должен иметь хорошую квалификацию. Должен знать способы представления знаний, иметь представления о механизмах вывода, знать состояние отечественного и мирового рынка программного обеспечения.
Аналитик. Основное требование – владение эффективными навыками грамотного извлечения, формализации и концептуализации знаний: Z1 — Z5. Должен владеть двумя механизмами вывода (ассоциативный и психологический) и извлечения знаний (мозговой штурм и т.п.). Аналитик должен владеть методологией разработки системы; одним из языков программирования.
- Z1 – знания в памяти
- Z2 – знания в книгах
- Z3 – поле знаний (методология представления знаний)
- Z4 – модель знаний
- Z5 – база знаний
Технологии проектирования и разработки промышленных экспертных систем
Стадии разработки:
- Выбор проблемы – деятельность, предшествующая разработке конкретной экспертной системы. Критическая часть разработки. При выборе проблемы следует учитывать, что если знания, необходимые для решения задач постоянны, чётко сформулированы и связаны с вычислительной обработкой, то не обязательно создавать экспертную систему – возможно, будет проще создать обычный программный комплекс.
- Определение проблемной области задачи
- Нахождение эксперта и назначение коллектива разработчиков
- Определение предварительного подхода к решению проблемы
- Анализ расходов и прибыли от разработки
- Подготовка подробного плана разработки
Технологии быстрого прототипирования
Прототип системы – усечённая версия системы, ориентированная на проверку правильности кодирования фактов, знаний и стратегий рассуждения экспертов. Стандартный объём прототипа – несколько десятков правил.
Стадии прототипирования:
- Идентификация (переопределение) проблемы (эксперт, аналитики, пользователи).
- Уточняется задача
- Планируется ход разработки прототипа
- Определяются необходимые ресурсы (время, люди, машины), источники знаний (книги, методики, дополнительные эксперты)
- Определяются аналогичные экспертные системы
- Определяются цели
- Определяются классы решаемых задач
- Знакомство и обучение всех членов коллектива разработчиков
- Создание неформального описания проблемы
- Получение (извлечение) знаний (эксперт и аналитик) – получение аналитиком наиболее полного из возможных представления о предметной области и способах принятия решений в этой области. Средний срок стадии – 1-3 месяца.
- Структурирование (концептуализация) знаний (аналитик) – разработка неформального описания знаний о предметной области в виде таблиц, графов, обычного текста и т.п., которое отражает основные концепции и взаимосвязи между понятиями предметной области. Такое описание называется полем знаний. Выделяется терминология, список основных понятий и атрибутов, отношения между понятиями; структура входной и выходной информации, стратегия принятия решений, ограничения стратегии и т.д. Средний срок стадии – 3-4 недели.
- Формализация знаний (аналитик, программист) – разработка базы знаний на языке представления знаний (ЯПЗ). Средний срок – 1-2 месяца.
- Реализация прототипа (программист) – разработка программного комплекса, демонстрирующего жизнеспособность подхода в целом. Средний строк – 1-2 месяца.
- Тестирование (эксперт, аналитик, пользователи, программист) – выявление ошибок в подходе к реализации прототипа и выработка рекомендаций по доводке системы до промышленного варианта. Средний срок – 1-2 недели. Проверяется
- работа прототипа с целью приведения в соответствие реальными запросами пользователя – удобство и адекватность интерфейса (ввод и вывод, характер вопросов, связность генерируемого текста и т.п.).
- Эффективность стратегии управления
- Качество проверочных примеров
- Корректность (полнота и непротиворечивость) базы знаний
Развитие прототипа до промышленной экспертной системы
Стадии развития:
- Демонстрационный прототип. Система решает часть задач и демонстрирует жизнеспособность подхода. В неё входит несколько десятков правил, понятий и т.п.
- Исследовательский прототип. Система решает большинство задач, но неустойчива в работе и не полностью проверена. Содержит несколько сотен правил и понятий.
- Действующий прототип. Система надёжно решает все задачи на реальных примерах, но нет оптимизации ресурсов.
- Промышленная система. Система обеспечивает высокое качество решения при минимизации затрачиваемых ресурсов.
- Коммерческая система. Система, ко всему прочему, хорошо документирована, снабжена сервисом.
Оценка системы
Проводится тестирование системы в отношениях критериев эффективности. Для этого привлекаются другие эксперты, дабы проверить работоспособность системы на других примерах.
Классификация критериев оценки:
- Оценка пользователя (понятность и прозрачность системы, удобство пользования и т.д.)
- Критерии приглашённых экспертов (оценка советов и решений, сравнение их с собственными решениями, оценка подсистемы объяснений, и.т.д.)
- Критерии разработчика
- эффективность реализации
- производительность
- время отклика
- дизайн
- широта охвата предметной области
- непротиворечивость базы знаний
- количество тупиковых ситуаций
- анализ чувствительности программы к незначительным изменениям в представлении знаний, весовых коэффициентов в механизмах логического вывода
Стыковка системы
Стыковка экспертной системы с другими программами в среде, с которой она будет работать и обучение людей, которых она будет обслуживать. Иногда это означает внесение существенных изменений. В этом процессе участвуют аналитик и эксперт. После этого аналитик должен убедиться, что пользователи знают систему и могут её обслуживать. Для подтверждения полезности системы рекомендуется поставить пользователям свои задачи и получить решения. Необходимо представить систему как помощника, освобождающего пользователя от решения обременительных задач, а не как средство его (пользователя) замещения. Стыковка включает обеспечение связи экспертной системы с существующими базами данных и другими системами на предприятии, а также улучшение системных факторов, зависящих от времени, чтобы можно было обеспечить её более эффективную работу и улучшить характеристики технических средств, если система работает в необычной среде.
Поддержка системы
Если система сохраняет все знания о предметной области и эти знания не будут изменяться в ближайшем будущем, то она может быть перекодирована с использованием новых технологий с течением времени. Если же проблемная область изменяется, то необходимо поддерживать систему в инструментальной среде её разработки.
Topics:
13. Экспертные системы: технология, этапы создания, применение
Экспертные системы
DEF Экспертная система – коммерческое приложение идей искусственного интеллекта; система, основанная на знаниях; сложный программный комплекс, аккумулирующий знания специалистов в конкретных предметных областях и тиражирующий этот опыт для консультации менее квалифицированных пользователей. Экспертная система делается для людей, работающих в предметной области, но имеющих невысокую квалификацию.
В общем виде все системы, основанные на знаниях, можно разделить на
- Системы, решающие задачи синтеза. Множество задач потенциально неограниченно и строится на решении компонентов или подпроблем.
- Интерпретация данных
- Диагностика
- Поддержка принятия решений
- Проектирование
- Планирование
- Управление
Состав команды разработки экспертной системы:
Пользователь – специалист предметной области, для которой предназначена система. Обычно его квалификация недостаточно высока, поэтому он нуждается в помощи и поддержке.
Аналитик (инженер по знаниям, когнитолог, инженер-интерпретатор) – специалист в области искусственного интеллекта, играющий роль посредника между экспертом и базой знаний.
База знаний – ядро экспертной системы; совокупность знаний предметной области, представленная в форме, понятной эксперту и пользователю. Обычно на некотором языке, близком к естественному.
Решатель (дедуктивная машина, машина вывода, блок логического вывода) – программа, моделирующая ход рассуждений эксперта на основании знаний, имеющихся в базе знаний.
Подсистема объяснений – программа, позволяющая пользователю получить ответы на вопросы, как была получена та или иная рекомендация, почему машина приняла именно такое решение. Ответ на вопрос «как?» – трассировка всего процесса получения решения с указанием использованных фрагментов базы знаний. Ответ на вопрос «почему?» — ссылка на умозаключение, предшествовавшее полученному решению
Интеллектуальный редактор – программа, позволяющая аналитику создавать базу знаний в диалоговом режиме.
Классификация экспертных систем:
- По задаче:
- Интерпретация данных – определение смысла данных, результаты которого должны быть согласованными (осмысленными) и корректными. Обычно предусматривается многовариантный анализ данных.
- Диагностика – процесс соотнесения объекта с некоторым классом объектов и/или обнаружение неисправностей в некоторой системе. Неисправность – отклонение от нормы. Такая трактовка позволяет с единых теоретических позиций рассматривать и неисправности оборудования в технических системах, и заболевания живых организмов, и природные аномалии, и пр.
- Проектирование – подготовка спецификаций на создание объектов с заранее определёнными свойствами.
- Спецификация – весь набор необходимых документов. Основная проблема – получение чёткого структурного описания знаний об объекте. Для организации эффективного проектирования и, особенно, перепроектирования, необходимо формировать не только проектные решения, но и мотивы их принятия. В задачах такого класса тесно связаны процессы вывода и объяснения решения.
- Статические – разрабатываются в предметных областях, в которых база знаний и интерпретируемые данные не меняются во времени.
- Пример: диагностика неисправностей в автомобиле.
- Пример: микробиологические экспертные системы, в которых снимаются лабораторные измерения с технологического процесса. Полученные показатели и их динамика анализируются.
- На супер-ЭВМ
- На ЭВМ средней производительности (мейнфреймы)
- На символьных процессорах
- На рабочих станциях
- На ПК
- Автономные – работают непосредственно в режиме консультации с пользователем для специфических экспертных задач. В них не требуется привлекать традиционные методы обработки данных.
- Гибридные – программный комплекс, агрегирующий стандартные пакеты прикладных программ и средства манипулирования знаниями. Разработка таких систем гораздо сложнее автономных систем.
- Пример: интеллектуальная надстройка над пакетом прикладных программ.
Требования к команде разработки экспертной системы:
Пользователь. Основное требование – базовый уровень квалификации, позволяющий ему правильно истолковывать рекомендации системы. Должна быть полная совместимость терминологии системы с терминологией пользователя. Остальные требования: дружелюбие, отсутствие психологического барьера к использованию ЭВМ, умение объяснить, что он хочет от системы.
Эксперт. Основное требование – готовность поделиться знаниями. Остальные требования: умение объяснять, заинтересованность, высокий профессионализм в своей области.
Программист. Должен иметь хорошую квалификацию. Должен знать способы представления знаний, иметь представления о механизмах вывода, знать состояние отечественного и мирового рынка программного обеспечения.
Аналитик. Основное требование – владение эффективными навыками грамотного извлечения, формализации и концептуализации знаний: Z1 — Z5. Должен владеть двумя механизмами вывода (ассоциативный и психологический) и извлечения знаний (мозговой штурм и т.п.). Аналитик должен владеть методологией разработки системы; одним из языков программирования.
- Z1 – знания в памяти
- Z2 – знания в книгах
- Z3 – поле знаний (методология представления знаний)
- Z4 – модель знаний
- Z5 – база знаний
Технологии проектирования и разработки промышленных экспертных систем
Стадии разработки:
- Выбор проблемы – деятельность, предшествующая разработке конкретной экспертной системы. Критическая часть разработки. При выборе проблемы следует учитывать, что если знания, необходимые для решения задач постоянны, чётко сформулированы и связаны с вычислительной обработкой, то не обязательно создавать экспертную систему – возможно, будет проще создать обычный программный комплекс.
- Определение проблемной области задачи
- Нахождение эксперта и назначение коллектива разработчиков
- Определение предварительного подхода к решению проблемы
- Анализ расходов и прибыли от разработки
- Подготовка подробного плана разработки
Технологии быстрого прототипирования
Прототип системы – усечённая версия системы, ориентированная на проверку правильности кодирования фактов, знаний и стратегий рассуждения экспертов. Стандартный объём прототипа – несколько десятков правил.
Стадии прототипирования:
- Идентификация (переопределение) проблемы (эксперт, аналитики, пользователи).
- Уточняется задача
- Планируется ход разработки прототипа
- Определяются необходимые ресурсы (время, люди, машины), источники знаний (книги, методики, дополнительные эксперты)
- Определяются аналогичные экспертные системы
- Определяются цели
- Определяются классы решаемых задач
- Знакомство и обучение всех членов коллектива разработчиков
- Создание неформального описания проблемы
- Получение (извлечение) знаний (эксперт и аналитик) – получение аналитиком наиболее полного из возможных представления о предметной области и способах принятия решений в этой области. Средний срок стадии – 1-3 месяца.
- Структурирование (концептуализация) знаний (аналитик) – разработка неформального описания знаний о предметной области в виде таблиц, графов, обычного текста и т.п., которое отражает основные концепции и взаимосвязи между понятиями предметной области. Такое описание называется полем знаний. Выделяется терминология, список основных понятий и атрибутов, отношения между понятиями; структура входной и выходной информации, стратегия принятия решений, ограничения стратегии и т.д. Средний срок стадии – 3-4 недели.
- Формализация знаний (аналитик, программист) – разработка базы знаний на языке представления знаний (ЯПЗ). Средний срок – 1-2 месяца.
- Реализация прототипа (программист) – разработка программного комплекса, демонстрирующего жизнеспособность подхода в целом. Средний строк – 1-2 месяца.
- Тестирование (эксперт, аналитик, пользователи, программист) – выявление ошибок в подходе к реализации прототипа и выработка рекомендаций по доводке системы до промышленного варианта. Средний срок – 1-2 недели. Проверяется
- работа прототипа с целью приведения в соответствие реальными запросами пользователя – удобство и адекватность интерфейса (ввод и вывод, характер вопросов, связность генерируемого текста и т.п.).
- Эффективность стратегии управления
- Качество проверочных примеров
- Корректность (полнота и непротиворечивость) базы знаний
Развитие прототипа до промышленной экспертной системы
Стадии развития:
- Демонстрационный прототип. Система решает часть задач и демонстрирует жизнеспособность подхода. В неё входит несколько десятков правил, понятий и т.п.
- Исследовательский прототип. Система решает большинство задач, но неустойчива в работе и не полностью проверена. Содержит несколько сотен правил и понятий.
- Действующий прототип. Система надёжно решает все задачи на реальных примерах, но нет оптимизации ресурсов.
- Промышленная система. Система обеспечивает высокое качество решения при минимизации затрачиваемых ресурсов.
- Коммерческая система. Система, ко всему прочему, хорошо документирована, снабжена сервисом.
Оценка системы
Проводится тестирование системы в отношениях критериев эффективности. Для этого привлекаются другие эксперты, дабы проверить работоспособность системы на других примерах.
Классификация критериев оценки:
- Оценка пользователя (понятность и прозрачность системы, удобство пользования и т.д.)
- Критерии приглашённых экспертов (оценка советов и решений, сравнение их с собственными решениями, оценка подсистемы объяснений, и.т.д.)
- Критерии разработчика
- эффективность реализации
- производительность
- время отклика
- дизайн
- широта охвата предметной области
- непротиворечивость базы знаний
- количество тупиковых ситуаций
- анализ чувствительности программы к незначительным изменениям в представлении знаний, весовых коэффициентов в механизмах логического вывода
Стыковка системы
Стыковка экспертной системы с другими программами в среде, с которой она будет работать и обучение людей, которых она будет обслуживать. Иногда это означает внесение существенных изменений. В этом процессе участвуют аналитик и эксперт. После этого аналитик должен убедиться, что пользователи знают систему и могут её обслуживать. Для подтверждения полезности системы рекомендуется поставить пользователям свои задачи и получить решения. Необходимо представить систему как помощника, освобождающего пользователя от решения обременительных задач, а не как средство его (пользователя) замещения. Стыковка включает обеспечение связи экспертной системы с существующими базами данных и другими системами на предприятии, а также улучшение системных факторов, зависящих от времени, чтобы можно было обеспечить её более эффективную работу и улучшить характеристики технических средств, если система работает в необычной среде.
Поддержка системы
Если система сохраняет все знания о предметной области и эти знания не будут изменяться в ближайшем будущем, то она может быть перекодирована с использованием новых технологий с течением времени. Если же проблемная область изменяется, то необходимо поддерживать систему в инструментальной среде её разработки.
Экспертные системы (Разработка)
Разработка экспертных систем существенно отличается от создания обычного программного продукта. В технологии создания экспертных систем нельзя использовать принятые в традиционном программировании методики, так как это либо чрезмерно затягивает процесс создания ЭС, либо вообще приводит к отрицательному результату. Вообще же, использовать экспертные системы следует только тогда, когда их разработка возможна, оправдана и методы, на которых она построена, соответствуют решаемой задаче.
Содержание
Требования по созданию
Чтобы разработка ЭС была возможной для конкретного приложения, минимально необходимо одновременное выполнение следующих требований:
- существуют эксперты в данной области, которые решают задачу значительно лучше, чем начинающие специалисты
- эксперты сходятся в оценке предлагаемого решения, иначе нельзя будет оценить качество разработанной ЭС
- эксперты способны объяснить используемые ими в системе методы, иначе знания экспертов будет сложно внести в ЭС
- решение задачи требует только рассуждений, а не действий
- задача не должна быть слишком трудной (т.е. ее решение должно занимать у эксперта несколько часов или дней, не более)
- задача должна относиться к достаточно «понятной» и структурированной области, т.е. должны быть выделены основные понятия, отношения и известные алгоритмы решения задачи
- решение задачи не должно в значительной степени использовать абстрактное мышление
Оправданность использования
Бывают случаи, когда использование экспертной системы возможно, но не оправдано. А оправданным использование ЭС может считаться при наличии следующих факторов:
- решение задачи принесет значительный эффект, например экономический
- использование человека-эксперта невозможно либо из-за недостаточного количества экспертов, либо из-за необходимости выполнять экспертизу одновременно в различных местах
- при передаче информации эксперту происходит неприемлемая потеря времени или информации
- существует необходимость решать задачу в окружении, враждебном для человека
Соответствие приложения методам ЭС
Созданное приложение соответствует методам ЭС, если решаемая задача обладает совокупностью некоторых характеристик, а именно:
- задача может быть естественным образом решена с помощью символьных рассуждений, а не манипуляций с числами, как в математических методиках и в традиционном программировании
- задача должна иметь эвристическую, а не алгоритмическую природу. Задачи, которые могут быть гарантированно решены при соблюдении заданных ограничений с помощью некоторых формальных процедур, не подходят для применения ЭС
- задача должна быть сложна настолько, чтобы оправдать затраты на создание ЭС. Однако она не должна быть настолько сложной, чтобы экспертная система не смогла ее решить в приемлемое время
- задача должна быть достаточно узкой и практически значимой
Концепция быстрого прототипа
Концепция быстрого прототипа, как правило, используется при создании экспертных систем. Суть концепции состоит в том, что разработчики не имеют целью сразу построить конечный продукт. Сначала происходит создание одного или нескольких прототипов ЭС. Прототип должен удовлетворять двум противоречивым требованиям: с одной стороны, они должны решать типичные задачи конкретного приложения, с другой стороны, время и трудоемкость их разработки должны быть весьма незначительны. Последнее требование необходимо, чтобы можно было максимально совместить процесс накопления и отладки знаний, осуществляемый экспертом, с процессом разработки программных средств. Для соблюдения этих требований при создании прототипа используются разнообразные средства, ускоряющие процесс создания.
Методы прототипа экспертной системы, кроме того, должны подходить для конкретной программы. В случае успеха знания прототипа о проблемной области подвергаются расширению. При неудаче может потребоваться разработка нового прототипа, или принимается решение о непригодности методов ЭС для данного приложения. По мере расширения базы знаний прототип может достигнуть такого состояния, когда все задачи данного приложения решаются успешно. Преобразование прототипа в конечный продукт обычно связано с перепрограммированием системы на языках низкого уровня, обеспечивающих как увеличение быстродействия ЭС, так и уменьшение требуемой памяти. Трудоемкость и время создания ЭС в значительной степени зависят от типа инструментов создания.
Этапы разработки
В ходе многолетних работ по созданию ЭС сложилась определенная технология их разработки, включающая шесть последовательных этапов:
- идентификация
- концептуализация
- формализация
- выполнение
- тестирование
- опытная эксплуатация
На этапе идентификации определяют задачи, подлежащие решению, выявляются цели разработки, определяются эксперты и типы пользователей.
В ходе концептуализации проводится подробный анализ проблемной области, выявляются понятия и их взаимосвязи, определяются методы решения задач.
Формализация подразумевает выбор инструментов и способов представления всех видов знаний. На этом этапе формализуются основные понятия, определяются способы интерпретации знаний, моделируется работа системы, оценивается адекватность целям системы зафиксированных понятий, методов решений, средств представления знаний и управления ими.
На этапе выполнения происходит наполнение системы знаниями. В связи с тем, что основой ЭС являются знания, этот этап превосходит все остальные по своей важности и трудоемкости. Процесс наполнения базы знаний делится на «извлечение знаний» из эксперта, их организацию, обеспечивающую эффективную работу системы, и интерпретацию знаний в понятном ЭС виде. Процесс приобретения знаний осуществляется инженером по знаниям на основе анализа деятельности эксперта по решению реальных задач.