Этапы разработки экспертных систем

Рассмотрим более детально этапы разработки ЭС (рисунок 4).

Этап идентификации. На данном этапе идентифицирует­ся задача (задачи), определяются участники процесса проектирования, их роли, ресурсы и цели.

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

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

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

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

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

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

При проектировании ЭС типичными ресурсами являются: источники знаний, время разработки, вычислительные средства (возможности ЭВМ и программного ИС) и объем финансирования. Для достижения успеха эксперт и инженер должны использовать при построении ЭС все доступные им источники знаний. Для эксперта источниками знаний могут быть его предшествующий опыт по решению задачи, книги, конкретные примеры задач и реализованных решений, а для инженера по знаниям — опыт в решении аналогичных задач, методы решения и представления знаний, программное ИС. При установлении (назначении) времени разработки необходимо иметь а виду, что сроки разработки и внедрения ЭС составляют (за редким исключением) не менее года (при трудоемкости 5 чел./лет). Задача определения ресурсов является весьма важной, поскольку ограниченность какого-либо ресурса существенно влияет на процесс разработки. Так, при недостаточном объеме финансирования предпочтение может быть отдано не разработке оригинальной новой системы, а адаптации существующей.

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

На первом этапе инженер по знаниям должен ответить на основной вопрос: подходят ли методы инженерии знаний для решения предложенной задачи. Для положительного ответа на этот вопрос необходимо, чтобы задача относилась к узкой, специальной области знаний и для ее решения не требовалось использовать то, что принято называть «здравым смыслом». Кроме того, качество ЭС зависит в конечном итоге от уровня сложности решаемой задачи и ясности ее формулировки. Задача не должна быть ни слишком легкой, ни слишком трудной. Говоря другими словами, назначение ЭС в том, чтобы решать некоторую задачу в данной области, а не в том, чтобы быть экспертом в этой области. Для обеспечения ясности формулировки задачи следует обратить внимание на точное описание входа-вы­хо­да и наличие разнообразных примеров решения рассматриваемой задачи.

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

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

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

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

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

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

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

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

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

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

Часто на этапе формализации выясняется, что для различных частей общей задачи нужны различные языки или ИС.

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

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

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

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

После разработки первого прототипа необходимо расширить круг задач, решаемых системой для того, чтобы собрать пожелания и замечания, которые будут учтены в очередной версии системы (ЭС-2). Для этого осуществляется развитие ЭС-1 путем добавления следующих компонентов: «дружественного» интерфейса; средств для исследования как БЗ, так и цепочек выводов, генерируемых системой (что обеспечивает прозрачность системы и понимаемость ее разработчиком); средств хранения библиотеки задач, решенных системой. Библиотека необходима для того, чтобы при каждой модификации системы можно было проверить, решаются ли все старые задачи и в новой версии. Расширенная версия ЭС-1 может рассматриваться как исследовательский прототип ЭС.

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

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

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

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

— анализ функционирования системы при значительном расширении БЗ;

— исследование возможностей системы в решении более широкого круга задач и принятие мер для обеспечения таких возможностей;

— анализ мнения пользователя о недостатках систем, о том, какую дополнительную помощь он хочет получить от ЭС
и т. п.;

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

Если ЭС успешно прошла этап тестирования, то она
может классифицироваться как промышленная система.

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

Обычно выделяют следующие источники неудач в рабо-
те системы: тестовые примеры, ввод-вывод, правила вывода, управляющие стратегии.

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

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

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

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

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

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

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

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

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

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

Усовершенствование прототипа осуществляется в процессе циклического прохождения через этапы выполнения и тестирования для отладки процедур вывода. Циклы повторяются до тех пор, пока система не будет вести себя ожидаемым образом. Изменения, осуществляемые при усовершенствовании, зависят от выбранного способа представления и класса задач, решаемых ЭС. Если в процессе усовершенствования желаемое поведение не достигается, то необходимо осуществить более серьезные модификации архитектуры и БЗ.

Возврат от этапа тестирования на этап формализации приводит к пересмотру выбранного ранее способа представления знаний. Данный цикл называют переконструированием.

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