Необходимость формального представления сведений о предметной области возникла еще на заре исследований в области искусственного интеллекта, когда был сформулирован критерий, разграничивающий понятия «данных» и «знаний», согласно которому, знания — это «данные плюс метаданные». Любая обработка знаний осуществляется на основе метаданных, описывающих способы преобразования, вспомогательные закономерности, форматы хранения информации и т. д. Изменение перечисленных компонентов позволяет модифицировать правила обработки информации, не затрагивая сами алгоритмы.

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

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

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

Получается, что при работе с семантическими сетями важно:

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

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

Языки RDF/RDFS как первооснова Semantic Web предназначены для работы с семантическими сетями и позволяют представлять информацию в виде графа, но его обработка в соответствии со спецификой предметной области реализуется уже на прикладном уровне. Средства более высокого уровня, такие как OWL, имеют встроенные механизмы для описания общеупотребительных типов семантических отношений («объект-атрибут», «вид-подвид», «часть-целое» и т. д.), но специфические для конкретной предметной области типы бинарных отношений остаются «за кадром».

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

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

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

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

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

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

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

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

Метаданные на практике

Подавляющая часть прикладных систем ориентирована на четко оговоренную концептуальную модель данных и решает четко поставленную задачу. Специфика предметной области может учитываться на всех уровнях системы, однако в большинстве случаев для хранения информации достаточно возможностей реляционной СУБД, и получается, что подавляющая часть программного обеспечения устроена по схеме «хранение данных + специфическая обработка». Алгоритмы обработки реализуются или непосредственно в пользовательском приложении, или на уровне промежуточного сервера (при использовании трехзвенной архитектуры). В любом случае изменение концептуальной модели информации требует доработки ПО, что очень неудобно, если пользователь до конца не знает предметную область. Ему может быть трудно предугадать, какие доработки потребуются, но известно, что в большинстве случаев будет необходимо выполнение только простейших операций: хранение информации, ввод, вывод, поиск. Возможна и другая ситуация, когда пользователь обладает исчерпывающей информацией о предметной области, но требующаяся функциональность системы реализуется очень сложными (но типовыми) алгоритмами. Их реализация «с нуля» может быть практически неосуществимой по ряду причин, и поэтому бывает целесообразно воспользоваться готовым, настраиваемым решением. Это очень распространено при создании средств анализа данных (OLAP, DataMining и т. д.) Используемые в этих системах алгоритмы сложны из-за необходимости быстрой обработки больших объемов информации, но применимы в самых различных областях.

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

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

Получается, что вся система укладывается в ту же самую схему «хранение данных + специфическая обработка», где вместо универсальной СУБД используется специализированная, имеющая встроенные средства интеллектуального анализа данных. С точки зрения модели представления информации эта система, обладая гибкими средствами для настройки на конкретную предметную область, не предоставляет принципиально новых возможностей по сравнению с РСУБД и не может рассматриваться, как средство хранения знаний.

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

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

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

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

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

Требования к моделям представления знаний

Система управления знаниями должна обеспечивать выполнение ряда условий.

  1. Любое клиентское приложение может иметь собственную модификацию предметной области.
  2. Любая модификация предметной области не требует действий на серверной стороне.
  3. Любая модификация предметной области не требует изменения других клиентских приложений.
  4. Любая модификация предметной области автоматически становится доступна другим клиентским приложениям, но они могут работать в рамках как старой, так и новой концептуальной модели информации.

Ни один из существующих подходов не удовлетворяет всем четырем требованиям. Либо предусматривается фиксированная предметная область, либо требуется корректировка приложений при изменении концептуальной модели данных. Возможно решение, когда клиентские приложения работают не напрямую с базой знаний, а с ее «витриной», неизменной при модификациях предметной области. Согласно этой концепции, информация выгружается из основного хранилища во вспомогательное, построенное на базе общеизвестного ПО, такого как Microsoft Analysis Server, Oracle Hyperion Essbase и т. д. В этом случае при изменении метаданных необходима доработка серверной стороны: корректировка старой витрины данных и реализация новой. Наконец, изменения предметной области можно делать локальными и хранить изолированно от других клиентов, но такой подход удовлетворяет всем требованиям, кроме четвертого.

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

***

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

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

Константин Селезнев (skostik@relex.ru) — старший инженер-программист НПП «Релэкс» (Воронеж).