Процесс приобретения знаний

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

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

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

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

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

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

Чтобы построить базу знаний системы искусственного интеллекта, эксперт взаимодействует с инженером или программой (рис. 5.1). Возможны различные способы этого взаимодействия. Эксперт может работать с инженером знаний так же, как и при ручном формировании знаний.

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

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

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

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

Рис. 5.4. Понимание текста – передача знаний из литературы в базу знаний через программу понимающую текст

5.2. Основные стадии приобретения знаний

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

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

Рис. 5.2. Стадии процесса приобретения знаний

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

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

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

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

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

В процессе идентификации проблемы важно решить следующие вопросы.

· Определить предполагаемые для решения задачи и подзадачи.

· Определить необходимые и имеющиеся для решения данные.

· Определить основные понятия в проблеме и их взаимосвязи.

· Определить вид решения и используемые в нем концепции.

· Выявить важный для решения проблемы опыт эксперта.

· Выявить природу и объем знаний, используемых экспертом.

· Выявить возможные ситуации, препятствующие решению.

· Выявить возможные помехи для работы экспертной системы.

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

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

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

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

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

· Какие имеются типы данных?

· Что задано и что должно быть выведено?

· Имеют ли подзадачи наименования?

· Имеют ли стратегии наименования?

· Имеются ли гипотезы и как широко они используются?

· Как связаны между собой объекты предметной области?

· Какие процессы участвуют в решении задачи?

· Какие ограничения наложены на эти процессы?

· Как осуществляется передача информации?

· Можно ли построить иерархическую структуру, отражающую отношения часть-целое, род-вид, причина-следствие и т. п.?

· Можно ли определить и разделить знания, необходимые для получения решения, и знания, используемые для обоснования решения?

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

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

В процессе формализации имеются три важных фактора: пространство гипотез, модель процесса и характеристики данных.

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

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

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

· Откуда и как можно получить данные и какова стоимость приобретения данных?

· Являются ли данные редкими и недостаточными или обильными и избыточными?

· Являются ли данные надежными, точными, однозначными или они ненадежны, неточны, неоднозначны?

· Являются ли данные непротиворечивыми и полными для решения поставленных задач?

· Зависит ли логическая интерпретация данных от порядка их появления во времени?

· Какие характеристики данных можно получить на основании выборки из непрерывного потока данных, из графиков и рисунков, из грамматического разбора ввода на естественном языке?

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

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

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

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

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

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

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

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

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

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

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

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