Технология коллекторов знаний

«Будущее технологии — смещение в сторону того, что людям нравится делать, в сторону развлечений (entertainment)... Я говорю вам: все деньги и вся энергия в этой стране будут неизбежно направляться на проделывание разных вещей с вашим мозгом и временем»
Марвин Мински

Задуманная как логическое продолжение своей предшественницы («Технология информационных коллекторов», «Компьютерное Обозрение», № 46, 2000), эта статья неожиданно для самого автора образовала некую логическую последовательность. Один из главных ее героев — легендарный Марвин Мински, основоположник ряда направлений в современной теории Искусственного Интеллекта (ИИ), оказался «непосредственно причастным» к судьбе... Рэя Курцвейла (которому была посвящена недавняя рубрика «Идеи и судьбы», «Компьютерное Обозрение», № 45, 2000). А точнее, Курцвейл был... студентом у Мински в Массачусетском технологическом (как и не менее легендарная личность в мире нанотехнологий Эрик Дрекслер, и знаменитый основатель теории понимания естественных языков Терри Виноград). И учиться у Мински было чему — ведь еще в 1951 г.(!) им был создан первый симулятор нейронной сети, в 1957 г. — первый конфокальный сканирующий микроскоп, в 1963 г. — первая управляемая механическая «рука» для роботов, в 1967 г. — первая гидравлическая «рука» (ныне экспонат Бостонского музея науки), с конца 60-х Мински активно участвовал в разработке остающейся по сей день уникальной, незаслуженно забытой в образовании программной оболочки «для самых маленьких» под названием Logo и ее «старшего брата» — мощного языка функционального программирования Lisp.

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

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

ФРЕЙМЫ МИНСКИ

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

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

{Имя_фрейма}
(Имя_слота_1} [Значение_слота_1]
{Имя_слота_2} [Значение_слота_2]
{Имя_слота_3) [Значение_слота_3]
• • •
{Имя_слота_N} [Значениеслота_N]

При описании фрейма протофрейм подвергается так называемой процедуре конкретизации. Как всегда, за «страшным» термином кроется элементарный смысл — конкретизация подразумевает замену полей, помещенных в фигурные скобки «{},[]», конкретными значениями или именами. Причем допускается неполная конкретизация (не до конца заполненный протофрейм), а в полях «Значения_слота_...» может храниться что угодно — тексты наестественных языках или языках программирования, формулы или рисунки. Но есть один-единственный «самый главный» тип данных — ссылка на другой фрейм, позволяющая соединять разрозненные фреймы в сети. Следует отметить, что образуемая соединениями с помощью ссылок структура не обязана подчиняться каким-либо строгим требованиям: она может содержать циклы (последовательности ссылок, двигаясь по которым вы вернетесь в начальную точку) и даже петли (ссылку из фрейма на самого себя).

А теперь наступило время объясниться по поводу начала этого раздела статьи, а именно, вспомнить о... суперпопулярном сегодня метаязыке XML. Принципиальные отличия XML от фреймов найти трудно. За исключением одного -XML ограничивает область описываемых с его помощью структур только деревьями или их множествами — лесами (что совершенно не меняет ситуацию). Общий принципиальный недостаток XML и фреймов — необходимость реализации дополнительного программного кода для «понимания» содержимого уникальных тегов/слотов — можно (в силу его общности для двух технологий) не принимать во внимание. Остается только вспомнить время «изобретения» фреймов Мински — июнь 1974, первая публикация меморандума лаборатории искусственного интеллекта MIT № 306 «А Framework for Representing Knowledge».

ФРЕЙМЫ + СКРИПТИНГ = ...

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

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

FRAMERD

Распространяемая в исходных текстах на условиях либеральной лицензии GNU программная система FramerD разрабатывалась и совершенствовалась в MIT в течение более чем десяти лет (!). Если учесть весьма скромный размер дистрибутива последней версии FramerD (менее 1 МВ), такие затраты времени кажутся аномальными. Но давайте пока воздержимся от преждевременных суждений, ведь только теоретическое обоснование архитектуры системы потребовало почти пяти лет напряженной работы высококлассных специалистов. Главная проблема, которой в этот период посвящались исследования в подразделении искусственного интеллекта MIT, заключалась в преодолении барьера сложности: приблизительно с 1990 г. возможности дешевых вычислительных машин начали лихорадочно расти, и программное обеспечение представления знаний стало заметно отставать по ряду показателей от совершенствующегося «железа». Появляющаяся реальная перспектива создания гигантских баз знаний никак не поддерживалась программно, и эта ситуация ухудшалась с ростом пропускной способности локальных сетей — распределенные базы данных были (и, в принципе, остаются) чрезмерно дорогой и не слишком надежной экзотикой. Решение задачи создания эффективной распределенной базы знаний, ориентированной на хранение большой сети фреймов, описываемых скриптовым языком, получило название FramerD.

Первый прототип системы, разработанныи в 1992 г., — Dtype, представлял собой программу поддержки одноименного несложного сетевого протокола для обмена объектами, написанными на языке Lisp. Менее чем через два года Dtype была переписана на C++ и стала активно использоваться в MIT в качестве распределенной платформы скриптинга в сети MIT. Параллельно с Dtype велась разработка мобильной системы Framer, предназначенной для представления и обмена фрейм-ориентиро-ванными данными. Первая версия FramerD появилась в 1994 г. и фактически объединила концепции Framer и Dtype (что отражено в названии). Современная реализация FramerD, несмотря на скромные размеры кода, является достаточно сложной многоуровневой системой, объединяющей ряд серверов, отвечающих за поддержку мобильных форматов представления фреймов, протоколов сетевого обмена фреймами и объектно-ориентированную распределенную СУБД, поддерживающую персистентность объектов (более подробно о свойствах вышеупомянутых объектов рассказывалось в статье «Всеобщая «объектная ориентация»», «Компьютерное Обозрение», № 40, 2000).

С «высоты птичьего полета» множество соединенных по сети серверов FramerD представляют собой одно огромное пространство виртуальной памяти, в котором располагаются связанные ссылками объекты. И здесь уже начинаются цифры, буквально заставляющие с уважением отнестись к разработчикам из MIT, — виртуальная память FramerD действительно огромна, ведь она адресуется 64-разрядным словом (что соответствует приблизительно 4 млрд, гигабайт). Но это не главное (в конце концов существуют 64-битовые процессоры), главное — принципиальная и гарантированная способность FramerD при работе множества соединенных по сети серверов назначать каждому объекту «в ОЗУ» уникальный (!) идентификатор. Решение подобной задачи далеко не тривиально...

Идентификатор объекта (в терминах FramerD — OID, Object IDentifier) — это ключевая концепция системы. Фактически OID представляет собой уникальный 64-битовый адрес объекта в виртуальном «ОЗУ». Система управления FramerD гарантирует, что размещаемый в виртуальной памяти различными пользователями, программами, компьютерами и сетями объект займет свободное и уникальное место. Запись OID в содержимое поля [Значение_слота_i] некоторого фрейма представляет собой ссылку на фрейм. Но и это еще не все — слоты фреймов также являются адресуемыми объектами.

И даже более того — содержимое самих слотов представляет собой множество адресуемых объектов.

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

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

АЛМАЗЫ ПОД НОГАМИ...

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

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

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

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

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

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

В целом, универсальность FramerD как инструмента, за которую приходится расплачиваться трудностями с изучением системы, окупается сторицей и полностью оправдывает затраты времени и труда.

ЧТО, ГДЕ, КАК?

В отличие от «героини» предыдущей статьи, FramerD -инструментальная система, требующая от потенциального пользователя достаточно высокой квалификации. Знание языка Scheme необходимо. И следует заметить, что освоение этого замечательного инструмента целесообразно всем серьезно интересующимся инструментальным ПО. Ссылки на лучшие ресурсы в Сети, посвященные изучению Scheme, собраны на странице dmoz.org/Computers/Programming/ Languages/Lisp/Scheme/Teaching/. Исходные тексты FramerD, сопутствующая документация и реальный пример использования системы в области компьютерной лингвистики размещены на сайте www.framerd.org.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365