На заре исследований по ИИ считалось, что знание расфасовано «пакетами» размером с предложение, и что лучшим способом ввода знаний в программу был бы некий метод, позволяющий переводить факты в пассивные пакеты данных. Таким образом, каждый факт соответствовал бы куску данных, которые могли бы использоваться программой. Примером такого подхода являлись шахматные программы, в которых позиции на доске были закодированы в форме матриц или неких списков и записаны в памяти, откуда они могли быть вызваны и обработаны с помощью подпрограмм.
Тот факт, что люди сохраняют информацию гораздо более сложным способом, был известен психологам уже давно, но специалисты по ИИ открыли его для себя сравнительно недавно. Теперь они стоят перед проблемой «блочных» знаний и разницы между декларативным и процедурным знаниями (эта разница связана, как мы видели в главе XI, с тем, какие знания доступны для интроспекции).
В самом деле, наивному предположению о том, что все знание должно быть закодировано в виде пассивных фрагментов данных, противоречит основной факт конструкции компьютеров: их умение складывать, вычитать, умножать и так далее не является закодированным в пакеты данных и записанным в памяти; это знание находится не в памяти, а в самих схемах аппаратуры. Карманный калькулятор не хранит в памяти умения складывать; это знание закодировано в его «внутренностях». В памяти нет такого места, на которое можно было бы указать, если бы кто-нибудь спросил: «Покажите мне, где в этой машине находится умение складывать?»
Тем не менее, в ИИ был проделан большой объем работы по изучению систем, в которых большинство знаний хранится в определенных местах — то есть декларативно. Само собой разумеется, что какое-то знание должно заключаться в программах — иначе у нас была бы не программа, а энциклопедия. Вопрос в том, как разделить знание между программой и данными (которые далеко не всегда легко отличить друг от друга). Надеюсь, что это было достаточно хорошо объяснено в главе XVI. Если в процессе развития системы программист интуитивно воспримет некий объект как часть данных (или как часть программы), это может иметь значительное влияние на структуру системы, поскольку, программируя, мы обычно различаем между объектами, похожими на данные, и объектами, похожими на программу.
Важно иметь в виду, что в принципе любой способ кодирования информации в схему данных или процедур так же хорош, как и все остальные, в том смысле, что все то, что можно сделать, работая с одной схемой, можно сделать и с другой — если вас не слишком волнует эффективность. Однако можно привести доводы, доказывающие, что один метод определенно лучше другого. Взгляните, например, на следующий аргумент в пользу исключительно процедурного представления: «Когда вы пытаетесь закодировать достаточно сложную информацию в виде данных, вам приходится развивать для этого нечто вроде нового языка или формализма. Таким образом, на самом деле, структура ваших данных начинает напоминать программу, части которой работают как интерпретатор. Не лучше ли сразу представить ту же информацию в процедурной форме и избежать лишнего уровня интерпретации?»
ДНК и белки дают некоторую перспективу
Этот довод звучит весьма убедительно; тем не менее, если интерпретировать его немного свободнее, он может быть понят как аргумент против ДНК и РНК. Зачем кодировать генетическую информацию в ДНК, если, сохраняя ее прямо в белках, можно избежать не одного, а двух лишних уровней интерпретации? Оказывается, что иметь одну и ту же информацию, закодированную в нескольких разных формах для разных целей, очень полезно. Одно из преимуществ кодирования генетической информации в ДНК в модулярной форме (в форме данных) заключается в том, что таким образом два индивидуальных гена могут быть скомбинированы для формирования нового генотипа. Это было бы очень трудно, если бы информация содержалась только в белках. Вторым доводом в пользу хранения информации в ДНК является то, что это облегчает транскрипцию и трансляцию ее в белки. Когда информация не нужна, она не занимает много места; когда она нужна, она извлекается и служит эталоном. Не существует механизма для копирования одного белка на основе другого — их третичная укладка сделала бы такое копирование слишком громоздким. Кроме того, генетическая информация почти неизбежно должна быть представлена в трехмерных структурах, таких, как энзимы, поскольку узнавание молекул и манипуляция ими по природе являются трехмерными операциями. Поэтому в контексте клеток довод в пользу исключительно процедурного представления информации кажется неверным. Это говорит о том, что в возможности перехода от процедурной к декларативной информации и обратно есть свои преимущества. Это, возможно, верно и для ИИ.
Этот вопрос был затронут Фрэнсисом Криком на конференции по общению с внеземными культурами:
Мы видим, что на земле есть две молекулы, одна из которых хороша для копирования (ДНК), а другая — для действия (белки). Возможно ли разработать такую систему, в которой одна и та же молекула выполняла бы обе функции? Или же существуют веские, основанные на анализе системы аргументы, доказывающие, что деление этой работы на две части дает значительное преимущество? Ответа на этот вопрос я не знаю. [73]
Модульность знания
Другой вопрос, возникающий по поводу представления знания, это модульность. Насколько легко ввести новое знание? Насколько легко получить доступ к старому знанию? Насколько модулярны книги? Все это зависит от многих факторов. Если из книги, в которой главы тесно связаны между собой и ссылаются друг на друга, убрать одну главу, то эту книгу станет практически невозможно понять. Так, потянув за одну паутинку, вы разрушаете всю паутину. С другой стороны, книги, главы которых менее зависимы друг от друга, гораздно более модулярны.
Рассмотрим прямолинейную программу, производящую теоремы на основе аксиом и правил вывода ТТЧ. У «знаний» подобной программы — два аспекта. Они находятся косвенно в аксиомах и правилах и явно — в произведенных теоремах. В зависимости от того, под каким углом вы смотрите на знания, вы скажете, что они либо модулярны, либо распространены по всей программе и совершенно не модулярны. Представьте себе, например, что вы написали такую программу, но забыли включить в нее Аксиому I из списка аксиом. После того, как программа вывела тысячи теорем, вы обнаруживаете свою ошибку и вставляете новую аксиому. Тот факт, что вам это легко удается, показывает, что неявные знания системы модулярны; однако вклад новой аксиомы в явные знания системы станет заметен не скоро — после того, как произведенный ею эффект распространится по системе, подобно тому, как по комнате, в которой разбили флакон с духами, медленно распространяется аромат. В этом смысле, новое знание включается в систему постепенно. Более того, если бы вы захотели вернуться назад и заменить Аксиому I на ее отрицание, для этого вам пришлось бы убрать все теоремы, в деривации которых участвовала Аксиома I. Ясно, что явные знания системы далеко не так модулярны, как ее неявные знания.
Было бы полезно научиться делать пересадку знания в модулярной форме. Тогда, чтобы обучить человека французскому языку, нужно было бы лишь, проникнув в его мозг, определенным образом изменить его нейронную структуру, — и человек бегло заговорил бы по-французски! Разумеется, все это только юмористические мечтания.
Другой аспект представления знаний зависит от того, как мы хотим эти знания использовать. Должны ли мы, получив новую информацию, сразу делать выводы? Должны ли мы постоянно делать сравнения и проводить аналогии между новой и старой информацией? В шахматной программе, например, если вы хотите получить дерево анализа вариантов, то построение, включающее позиции на доске и минимум ненужных повторений, будет предпочтительнее, чем построение, повторяющее одну и ту же информацию в различной форме. Но если вы хотите, чтобы ваша программа «понимала» позицию, глядя на структуры на доске и сравнивая их с уже известными ей структурами, тогда повторение одной и той информации в разных формах будет более полезным.
