Идентификация проблемы

Уточняется задача, планируется движение разработки прототипа экспертной совокупности, определяются:

нужные ресурсы (время, люди, ЭВМ и т.д.);

источники знаний (книги, дополнительные специалисты, методики);

имеющиеся подобные экспертные совокупности;

цели (распространение опыта, автоматизация рутинных действий и др.);

классы решаемых задач и т.д.

Идентификация неприятности -обучение и знакомство коллектива разработчиков, и создание неформальной формулировки неприятности.

Средняя длительность 1 — 2 семь дней.

Извлечение знаний

Происходит перенос компетентности специалистов на инженеров по знаниям с применением разных способов:

анализ текстов;

диалоги;

экспертные игры;

лекции;

дискуссии;

интервью;

наблюдение и другие.

Извлечение знаний -получение инженером по знаниям самоё полного представления о предметной области и методах принятия ответа в ней.

Средняя длительность 1 -3 месяца.

Структурирование либо концептуализация знаний

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

терминология;

перечень главных их атрибутов и понятий;

отношения между понятиями;

структура входной и выходной информации;

стратегия принятия ответов;

ограничения стратегий и т.д.

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

Такое описание именуется полем знаний. Средняя длительность этапа 2 — 4 семь дней.

Формализация.

Строится формализованное представление концепций предметной области на базе выбранного языка представления знаний (ЯПЗ). Традиционно на этом этапе употребляются:

логические способы (исчисления предикатов I порядка и др.);

продукционные модели (с прямым и обратным выводом);

семантические сети;

фреймы;

объектно-ориентированные языки, основанные на иерархии классов, объектов и др.

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

Все чаще на данной стадии употребляется симбиоз языков представления знаний, к примеру, в совокупности ОМЕГА [7] — фреймы + семантические сети + полный комплект возможностей языка исчисленияпредикатов. Средняя длительность 1 — 2 месяца.

Реализация

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

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

программирование на специальных языках, используемых в задачах ИИ: LISP [14], FRL [I], SmallTalk [7] и др.;

применение инструментальных средств разработки ЭС типа СПЭИС [З], ПИЭС [11];

применение безлюдных ЭС либо оболочек типа СПЕЦИАЛИСТ [2], ФИАКР [7] и др.

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

Средняя длительность 1 — 2 месяца.

Тестирование

Оценивается и проверяется работа программ прототипа с целью приведения в соответствие с настоящими запросами пользователей. Прототип проверяется на:

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

• эффективность стратегии управления (порядок перебора,применение нечеткого вывода и др.);

• уровень качества проверочных примеров;

• корректность базы знаний (полнота инепротиворечивость правил).

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

Средняя длительность 1 — 2 семь дней.

ЭТАП 3: РАЗВИТИЕ ПРОТОТИПА ДО ПРОМЫШЛЕННОЙ ЭС

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

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

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

Понятие же коммерческой совокупности у нас входит в понятие промышленный программный продукт, либо промышленной ЭС в данной работе (табл. 16.1).

Таблица 6.1. Переход от прототипа к промышленной экспертной совокупности

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

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

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

ЭТАП 4: ОЦЕНКА СОВОКУПНОСТИ

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

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

критерии приглашенных специалистов (оценка рекомендаций-ответов, предлагаемых совокупностью, сравнение ее с собственными ответами, оценка системы объяснений и др.);

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

ЭТАП 5: СТЫКОВКА СОВОКУПНОСТИ

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

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

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

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

Пример 16.15. Удачно состыкована со своим окружением совокупность PUFF — экспертная совокупность для диагностики болезней легких [10]. По окончании того, как PUFF была закончена и все были удовлетворены ее работой, совокупность перекодировали с LISPa на Бейсик. После этого совокупность перенесли на ПК, которая уже трудилась и поликлинике. Со своей стороны, эта ПК была связана с измерительными устройствами. Эти с измерительных устройств сходу поступают в ПК. PUFF обрабатывает эти сведенья и печатает советы для доктора. Доктор в принципе не взаимодействует с PUFF. Совокупность всецело интегрирована со своим окружением — она представляет собой интеллектуальное расширение аппарата изучения легких, что доктора в далеком прошлом применяют.

Пример 16.16. Другая система, которая прекрасно функционирует в собственном окружении, — САТ-1 [8] — экспертная совокупность для диагностики неисправностей дизелей локомотивов.

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

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

ЭТАП 6: ПОМОЩЬ СОВОКУПНОСТИ

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

Пример 16.17. Успешным примером ЭС, внедренной так, есть XCON (R1) — ЭС, которую компания DEC применяет для комплектации ЭВМ семейства VAX. Одна из главных неприятностей, с которой столкнулась компания DEC, — необходимость постоянного внесения трансформаций для новых предположений оборудования, новых спецификаций и т.д. Для данной цели XCON поддерживается в программной среде OPS5.

Роберт Шафер — Кавказ и Россия: идентификация неприятности

Похожие статьи:

• Как мировоззренческая проблема
• Нарциссическая проблема
• Проблема: шимпанзе, который умеет ругаться