3. Представление

Вид материала

Обзор

Содержание 24.4. Решение практических проблем 24.5. Архитектура экспертных систем

Подобный материал:

• Вопросы к экзамену по курсу " ЭВМ и периферийные устройства" для групп К2-121, -122,, 75.03kb.
• И представление налоговой отчетности, 357.06kb.
• И представление налоговой отчетности, 394.07kb.
• Дать детям представление о речевом этикете, как о правилах поведения в различных ситуациях;, 241.98kb.
• Дать общее представление о витаминах, познакомить учащихся с их классификацией, представителями, 180.08kb.
• Урок Окружающий мир 2 класс умк «Перспективная начальная школа», 44.76kb.
• Задачи:; развивать обобщенное представление о казахстанцах; сформировать представление, 49.53kb.
• Урок 57 Источники права Цель, 56.46kb.
• Вопросы для подготовки к экзамену по архитектуре ЭВМ, 79.1kb.
• Отчет об оказании юридических услуг за 20 г. Представляют, 89.3kb.

^

24.4. Решение практических проблем

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

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

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

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

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

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

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

^

24.5. Архитектура экспертных систем

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

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

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

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

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

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

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

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

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