Методика выбора оптимального инструментария для разработки экспертной системы

1. Главная
2. Экспертные системы
3. Методика выбора оптимального инструментария для разработки экспертной системы

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

При этом, рекомендуется придерживаться следующих общих правил:

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

Процесс решения вопроса выбора можно представить схематично как показано на рис.1. Рисунок 1 - Схема выбора инструментальных средств для разработки экспертной системы

Классификация проблем, которые способны решать экспертные системы

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

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

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

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

Аспекты выбора инструментария для экспертных систем

В процессе выбора инструментальной среды важное значение играют также следующие аспекты:

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

Как правило, типичное среда разработки экспертных систем поддерживает четыре режима работы:

• подготовка и редактирование базы знаний;
• использование базы знаний для выполнения консультаций, т.е. прогон программы;
• выявление и устранение ошибок на стадии компиляции;
• выявление и устранение ошибок на стадии выполнения.

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

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

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

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

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

Общие рекомендации программирования экспертных систем

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

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

1. Задача, которую предполагается решать с помощью экспертной системы, должна быть полностью по силам эксперту-человеку.
2. Задача должна быть четко сформулирована. Лучше создать систему, которая сможет надежно решать ограниченную задачу, чем систему, претендующая на решение широкого класса задач, однако дает верное решение лишь время от времени.
3. Начиная с первой стадии работы над системой необходимо определить, как она будет совершенствоваться и очертить пределы, которых она должна достичь в процессе эволюции.
4. Следует тщательно отработать поведение системы на наборе отдельных случаев и организовать библиотеку таких случаев. Есть примеры, которые применялись на этапе проектирования, должны быть представлены.
5. Нужно отделить те знания, которые являются специфическими для определенной предметной области, от знаний, касающихся общей методики решения проблем. Желательно, по возможности, упростить машину логического вывода в системе.
6. Необходимо на самых первых стадиях проектирования системы разработать однозначные соглашения об оформлении программ. Это придаст ей однообразный вид.
7. Желательно уступать производительности программы, если это сделает ее более понятной и упростит ее сопровождение. Это необходимо, поскольку в работе интерактивных экспертных систем большая часть времени уходит на диалог с пользователем и обращения к базам знаний.
8. Как только встанет вопрос о разработке нового прототипа системы, от предыдущего необходимо отказаться. Многие проекты потерпели неудачу лишь потому, что их авторы не смогли избавиться привязанности к первому варианту реализации собственных идей. Конечно, в процессе разработки нового прототипа нужно учитывать опыт создания предыдущего, но только опыт, а не код.
9. Разработка экспертной системы, которая будет способна успешно работать, требует настойчивости и терпения профессионального программиста, привлечение к работе опытного эксперта в соответствующей области и определенного уровня принуждения со стороны руководства.

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

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