Развитие прототипа до промышленной ЭС

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

Если первоначально выбранные объекты или свойства оказываются непод­ходящими, их необходимо изменить. Можно сделать оценку общего числа эвристических правил, необходимых для создания окончательного варианта экспертной системы. Иногда [Хювянен, Сеппянен, 1991] при разработке промышленной и/или коммерческой системы выделяют следующие дополнительные этапы для перехода (табл. 1.2):

Ø демонстрационный прототип;

Ø исследовательский прототип;

Ø действующий прототип;

Ø промышленная система;

Ø коммерческая система.

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

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

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

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

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

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

Оценка системы

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

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

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

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

Стыковка системы

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

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

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

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

Так успешно была состыкована со своим окружением система PUFF — экспертная система для диагностики заболеваний легких [Хейес-Рот и др., 1987]. После того как PUFF была закончена и все были удовлетворены ее работой, систему перекодировали с LISP на Бейсик. Затем систему перене­сли на ПЭВМ, которая уже работала в больнице. В свою очередь, эта ПЭВМ была связана с измерительными приборами. Данные с измеритель­ных приборов сразу поступают в ПЭВМ. PUFF обрабатывает эти данные и печатает рекомендации для врача. Врач в принципе не взаимодействует с PUFF. Система полностью интегрирована со своим окружением — она представляет собой интеллектуальное расширение аппарата исследования легких, который врачи давно используют.

Другой системой, которая хорошо функционирует в своем окружении, являлась САТ-1 [Уотермен, 1990] — экспертная система для диагностики не­исправностей дизелей локомотивов.

Эта система была разработана также на языке LISP, а затем была переведе­на на FORTH с тем, чтобы ее можно было более эффективно использовать в различных локомотивных цехах. Мастер по ремонту запрашивает систему о возможных причинах неисправности дизеля. Система связана с видеодис­ком, с помощью которого мастеру показывают визуальные объяснения и подсказки, касающиеся более подробных проверок, которые он должен сделать.

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

Поддержка системы

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

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