Представление знаний в информационных системах

     В книге [Hayes-Roth et al, 1983] проблема выбора инструментальных средств представлена в терминах схемы рис. 2. Выяснив характеристики проблемы, решаемой проектируемой экспертной системой, можно определиться со свойствами пространства решений, которые перечислены выше. Затем они рассматриваются совместно с предполагаемыми характеристиками разрабатываемой системы — характеристиками порождающих правил, прямой цепочки вывода или возможностями формирования пояснений, — и вырабатываются желаемые характеристики инструментальной среды. Последние и позволяют подобрать нужную модель инструментальной среды. Нужно сказать, что все это прекрасно выглядит на картинке, но очень сложно реализуется на практике, хотя вряд ли кто-нибудь будет спорить с тем, что такой подход более логичен, чем какой-либо другой. Как показывает практика, большинство разработчиков явно или неявно следует именно такому подходу при создании экспертных систем. 

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

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

     Эта среда предоставляет в распоряжение разработчика большее разнообразие парадигм программирования, чем какая-либо другая.

     Среда оснащена лучшими средствами интерфейса и более развитыми средствами редактирования.

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

     Проанализировав возможные варианты, разработчики остановились на выборе в качестве основного инструментального  средства компонента COTS среды КЕЕ.

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

3.3. Практическое  освоение инструментальных средств 

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

     В работе [Ward and Sleeman, 1987] представлены результаты мониторинга процесса изучения опытными программистами методики работы с оболочкой  для проектирования экспертных систем S.1 [Teknowledge, 1985]. Прародителем S.1 является известная система EMYCIN, а дальнейшим развитием — система М.4. Базы знаний в S.1 содержат множество объектов разного назначения — управляющие  выражения, классы, типы классов, порождающие  правила, иерархии значений и функций. Таким образом, выбранная для S.1 архитектура, с одной стороны, позволила расширить  возможности, которыми обладала система EMYCIN, а с другой — весьма усложнила  саму систему. Это замечание еще  более справедливо в отношении  системы М.4.

Среда S.1 поддерживает четыре режима работы:

подготовка  и редактирование базы знаний; 

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

выявление и устранение ошибок на стадии компиляции; 

выявление и устранение ошибок на стадии выполнения. 

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

     Анализ  опыта освоения этой инструментальной среды также показал, что если программисты отдают предпочтение простейшей стратегии отладки (эта стратегия  включает этапы ввода данных, обращения  к системе с запросом о значении какого-либо параметра на основе анализа  небольшого множества правил и вывода результата), то они сталкиваются с  рядом проблем, касающихся методов  представления информации и управления поиском. По мере увеличения сложности  проектируемой системы — увеличение объема базы знаний, включение в  рассмотрение неопределенностей разного  рода, включение в алгоритм работы системы дополнительных режимов  — стратегия проектирования требует  все более тщательной предварительной  подготовки. Авторы обзора [Ward and Sleeman, 1987] пришли к выводу, что хотя освоение системы S.1 и не сложнее освоения нового языка программирования уровня PASCAL, но утверждать, что эта система  проще, тоже нельзя.

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

     В своих аналитических заметках Робинсон [Robinson, 1987] обращает внимание на то, что  выбор инструментальной среды разработки экспертной системы представляет собой  достаточно сложную задачу по следующим  причинам:

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

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

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

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

Заключение.

     Тема  искусственного интеллекта всегда была в информатике "страной плохишей", населенной массой "неправильных" проблем, не поддающихся решению  традиционными способами. Эта область  привлекла внимание прежде всего  разносторонних специалистов, которых  не испугало ее открытое, лишенное всякой организации пространство, — людей, которых влечет задача узнать, как  мы мыслим. Такие исследователи, как  Марвин Минский (Marvin Minsky), Джон Мак-Карти (John McCarthy), Герберт Саймон (Herbert Simon), Пат  Хейес (Pat Hayes), Дональд Мичи (Donald Michie) и Бернард Мельтцер (Bernard Meltzer), стали  первопроходцами для тех, кто  следовал за ними по пути, пролегающем  через информатику, психологию и  математическую логику. Я предлагаю  вам задуматься над вопоосами: "Зачем  при построении экспертных систем нам  вообще нужны технологии, используемые в задачах искусственного интеллекта? Почему нас не устраивают традиционные информационные технологии, такие как  матемагическое моделирование? Или, другими  словами, тот факт, что экспертные системы начали развиваться в  русле задач искусственного интеллекта, является случайностью либо в этом была своя логика?" Не вдаваясь в  длительные рассуждения, можно ответить, что нет ничего плохого в использовании  для построения экспертных систем подходящих традиционных технологий, если это  приводит к желаемому результату. Например, генерация гипотез в  системе DENDRAL (см. главу 20) основана на алгоритме  перечисления вершин плоского графа, а  в системе MYCIN (см. главу 3) использован  статистический подход для выбора способа  лечения на основе анализа чувствительности организма к тем или иным лекарственным  препаратам. Использование методов  поиска или языков программирования, характерных для систем искусственного интеллекта, не запрещает инженерам  по знаниям применять методики, заимствованные из прикладной математики, исследования операций или других подходящих дисциплин. Для некоторой части рассматриваемой  проблемы решение может быть получено чисто алгоритмически или математически, и было бы непозволительной роскошью отказываться от таких методов, если они способствуют достижению нужного результата. Более пространный ответ (который я также постараюсь изложить покороче) состоит в том, что экспертные системы не смогли бы получить столь широкого распространения в настоящее время, если бы в свое время в их развитие не внесли существенный вклад идеи искусственного интеллекта. То, что предлагает искусственный интеллект, — это множество концепций, технологий и архитектур, пригодных для решения комплексных проблем в тех случаях, когда чисто арифметические или математические решения либо неизвестны, либо малоэффективны. За последние 30 лет появился ряд работ, в которых предпринималась попытка приспособить к проблематике экспертных систем теоретические и практические результаты, полученные в соответствующих областях математики, информатики или общественных наук. Однако, как правило, оказывалось, что перенос результатов из других дисциплин сопряжен с появлением новых нетривиальных проблем представления информации и управления процессом. 

     Список  использованной литературы