Трудности разработки экспертных систем - Разработка интеллектуальных подсистем САПР

При разработке ЭС разработчиков поджидают различные трудности:

Глобальные, имеющие отношение ко всему процессу разработки или к нескольким этапам разработки;

Локальные, проявляющиеся в основном на некотором этапе разработки.

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

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

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

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

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

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

Локальные Трудности. Инженер по знаниям на разных этапах создания ЭС может столкнуться с локальными трудностями.

На этапе идентификации основные трудности возникают при решении следующих проблем:

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

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

Задача может быть решена ЭС, но пользователь не получит от ее решения существенной пользы;

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

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

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

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

На этапе концептуализации могут встретиться следующие трудности:

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

На этапе формализации основные проблемы относятся к выбору и использованию инструментальных средств. Можно выделить следующие трудности.

    1. При использовании выбранного ИС инженеры по знаниям (разработчики) приходят к выводу, что в нем трудно представлять как понятия области экспертизы, так и управляющие структуры, необходимые для решения задачи. Выбор ИС и определение его пригодности для данного приложения весьма сложны и неформальны. Поэтому разработчики, как правило, могут оценить сделанный выбор только после разработки в нем небольшого прототипа. Если разработчики приходят к выводу, что выбранное инструментальное средство не подходит для данной проблемы, то необходимо либо выбрать другое ИС, либо разрабатывать новое (в этом случае практически дело сводится к откладыванию разработки ЭС на неопределенный срок). 2. Инженер по знаниям выбирает то ИС, которым он хорошо владеет, а не то, которое наиболее соответствует данной проблемной области. При этом, если ИС явно плохо подходит, инженер прилагает усилия к изменению исходной задачи (что может снизить или устранить практическую значимость создаваемой ЭС), чтобы она подходила под выбранное им ИС. Для устранения подобных затруднений руководитель проекта по разработке ЭС должен при выборе ИС проконсультироваться с несколькими инженерами по знаниям, чтобы убедиться в обоснованности сделанного выбора. Кроме того, сам инженер по знаниям должен осознавать наличие подобной ловушки и тщательно подходить к проблеме выбора инструментального средства. 3. В качестве ИС выбирается (на начальных этапах разработки ЭС) один из общецелевых языков программирования (например, Паскаль, Си, Фортран), что приводит к чрезмерному увеличению времени разработки ЭС или к полной неудаче всего проекта. Ошибочность подобного выбора состоит в том, что для выполнения таких наиболее трудоемких работ, как наполнение экспертной системы знаниями, тестирование и корректировка БЗ, общецелевые языки плохо приспособлены. Более правильно разработать ЭС, используя инструментальные средства, ориентированные на разработку экспертных систем, и затем, если ЭС будет работать медленно, переписать ее, используя общецелевые языки программирования. 4. Выбранное ИС содержит ошибки, препятствующие использованию многих из его свойств. Для предотвращения указанной трудности рекомендуется: избегать ИС, не находившихся в употреблении; не использовать инструментальные средства, которые более не сопровождаются разработчиком; выбирать то ИС, которое сопровождается разработчиком и было успешно использовано в других применениях.

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

    1. Эксперт теряет интерес к разработке ЭС. Время, которое он выделяет на работу с инженером по знаниям, постоянно сокращается. В подобных ситуациях рекомендуется: поддерживать интерес эксперта к работе, обеспечивая; дружественную обстановку; объяснять, что для успеха необходимы регулярные контакты (не реже 2-3 раз в неделю); помнить, что эксперт не специалист в программировании и ЭС, и не требовать от эксперта того, что он не умеет делать; предоставить эксперту возможность непосредственного наблюдения за результатами предлагаемых им изменений БЗ. 2. Эксперт при корректировке БЗ прототипа не совсем понимает, как система интерпретирует правила. Чтобы избежать указанного затруднения, рекомендуется: использовать в правилах ту же терминологию, которую использует эксперт; хранить в системе определения всех используемых понятий и иметь возможность выдавать их по требованию пользователя; если правила во внутреннем представлении "нечитаемы", то иметь средства для преобразования правил в вид, понятный пользователю. 3. Правила, введенные экспертом, в сложных ситуациях не позволяют прототипу ЭС получить качественные решения. Для преодоления данного затруднения рекомендуется: ориентировать эксперта на решение реальных, а не "игрушечных" задач; наблюдать за работой эксперта, стремясь выделить все типы возможных задач (подзадач); привлекать для оценки работы прототипа других экспертов. 4. Для построения ЭС было выбрано ИС без объяснительных способностей. После отработки ЭС разработчики пытаются дополнить ЭС этим механизмом, однако обычно сделать это чрезвычайно трудно. Чтобы не сталкиваться с подобными трудностями, разработчики должны выбирать ИС с объяснительными способностями. Объяснения ускоряют отладку, тестирование, модификацию прототипа и обеспечивают удобство для конечного пользователя и эксперта. 5. В процессе разработки ЭС знания об области экспертизы переплетаются с общими знаниями о решении задач (проблемно-независимыми знаниями), что затрудняет (делает невозможным) проведение модификации и развития ЭС. По сути дела, нарушается основной принцип разработки ЭС отделение знаний эксперта от остальных знаний и представление знаний эксперта в явном виде.

На этапе тестирования и опытной эксплуатации могут встретиться следующие трудности:

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

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




Трудности разработки экспертных систем - Разработка интеллектуальных подсистем САПР

Предыдущая | Следующая