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

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

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

Чтобы разработка ЭС была возможной (для данного приложения), необходимо одновременное выполнение по крайней мере следующих требований (рисунок 1):

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

Рисунок 1. Требования, необходимые для возможности разработки экспертной системы

Использование ЭС в данном приложении может быть возможно, но не оправдано. Применение ЭС будет оправдано одним из следующих факторов (рисунок 2):

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

Рисунок 2. Условия, при которых разработка экспертной системы оправдана

Приложение соответствует методам ЭС, если решаемая задача обладает совокупностью следующих характеристик (рисунок 3):

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

Рисунок 3. Особенности предметной области, делающие применение экспертной системы подходящим

При разработке ЭС используется концепция «быстрого прототипа». Суть ее состоит в том, что разработчики не пытаются сразу создать конечный продукт. На начальном этапе они проектируют прототип (прототипы) ЭС, который должен удовлетворять двум противоречивым требованиям: с одной стороны, решать типичные задачи конкретного приложения, а с другой — иметь весьма незначительные время и трудоемкость разработки, чтобы можно было максимально «запараллелить» процесс накопления и отладки знаний (осуществляемый экспертом) с процессом выбора (разработки) программных средств (осуществляемым инженером по знаниям и программистом). Для удовлетворения указанных требований при создании прототипа, как правило, используются разнообразные ИС, ускоряющие процесс проектирования.

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

Рисунок 4. Технология разработки ЭС.

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

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

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

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

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

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

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