ФОНЕТИЧЕСКИЙ звуко-буквенный разбор слов онлайн
 <<
>>

УМОЗАКЛЮЧЕНИЯ И ЗНАНИЯ (ЧАСТЬ II)[59] СИСТЕМА, БАЗИРУЮЩАЯСЯ НА ’’ДЕМОНАХ"

В конце нашей первой статьи мы рассмотрели язык про­граммирования PLANNER. Мы отметили, что в этом языке имеются определенные средства для вывода умозаключений и представления знаний.

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

Естественно, что названный недостаток затрудняет оп­ределение других недостатков. Для того чтобы выявить их, нам придется отвлечься от самого языка PLANNER и рассмотреть способы его использования. В частности, мы остановимся на работе Чарняка, посвященной анализу детских рассказов (С h а г п і а к, 1972).

Это поможет нам показать, что некоторые недостатки названной модели, в сущности, являются недостатками языка PLANNER как такового.

Задача модели (или системы) Чарняка совпадает с одной из задач, о которой говорилось в нашей первой статье: она состоит в генерации разумных ответов на вопросы по достаточно простым исходным текстам (детским рассказам).

Janet needed some money. She got her piggybank (PB), and started to shake it. Finally some money came out.

‘Дженет были нужны деньги. Она достала свою копилку и начала трясти ее. Наконец деньги вы­сыпались.’

Типичными вопросами будут следующие:

Why did Janet get the PB?

‘Почему Дженет достала копилку?’

Did Janet get the money?

‘Достала ли Дженет деньги?*

Why was the PB shaken?

‘Почему трясли копилку?’

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

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

Мы исходим из того, что рассказ, подающийся на вход модели, сразу же преобразуется в семантическое представ­ление, удобное для вывода умозаключений. Семантическим представлением фразы будем называть набор утверждений, записанных на языке MICRO-PLANNER. Модель будет пытаться "заполнить пробелы" рассказа, анализируя его пофразно. Так, она будет пытаться устанавливать связи между событиями рассказа (обычно это причинные связи) и вставлять пропущенные факты там, где это покажется важным.

’ДЕМОНЫ*4 И БАЗОВЫЕ СТАНДАРТНЫЕ ПОДПРОГРАММЫ

Рассмотрим следующий факт:

(1) If "it is (or will be) raining" and if "person P is out­side" then ”P will get wet".

‘Если ’’идет (пойдет) дождь" и если ’’лицо Р нахо­дится на улице", то ”Р промокнет".’

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

Мы вводим это убеждение в нашу систему, приписывая правило (1) единице rain ‘дождь’ с тем, чтобы при появле­нии в рассказе понятия ”rain“, встал вопрос о возможности использования правила (1). Будем говорить, что rain — это понятие -тема (или центральное понятие; topic concept) для правила (1). Когда в рассказе встречается некоторое понятие-тема, факты, приписанные этому понятию, могут быть использованы при выводе умозаключений.

(Будем так­же говорить, что эти факты подаются на вход аппарата умо­заключений в качестве исходных утверждений.) Итак, если понятие-тема, например ”цирк“, не встретилось, то про­грамма не сможет обратиться к тем фактам, которые при­писаны именно этому понятию.

Отметим, однако, что мы не требуем непосредственного упоминания в тексте слова rain, прежде чем мы сможем ис­пользовать (1). Необходимо только, чтобы в базу данных было введено утверждение о ’’дожде". Сформировать же утверждение о том, что идет дождь, программа может под воздействием фактов, содержащихся в других частях рас­сказа, например:

One afternoon Jack was outside playing with Bill. Bill looked up and noticed that the sky was getting dark. ”1 think we should stop" said Bill. ”We will get wet if we keep playing".

‘Однажды днем Джек играл на улице с Биллом. Билл посмотрел вверх и заметил, что небо темнеет. ”Я думаю,нам надо остановиться,— сказал Билл.— Если мы будем продолжать играть, мы промокнем".!

В этом примере предполагается, что если небо днем потем­нело, то это означает приближение дождя. Если данное соотношение занесено в базу данных, то этого будет доста­точно для того, чтобы вызвать факты, приписанные поня­тию ”дождь“.

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

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

Так, могут встретиться обе после­довательности:

(2) Jack was outside. It was raining.

‘Джек был на улице. Шел дождь.’

(3) It was raining. Jack was outside.

‘Шел дождь. Джек был на улице.’

Пример (2) не содержит трудностей. В тот момент, когда мы вводим понятие дождя, в нашем распоряжении имеется достаточная информация для использования правила (1) и вывода умозаключения о том, что Джек должен промок­нуть. В примере же (3) мы узнаем о том, что Джек был на улице уже после упоминания о дожде. Если мы хотим при­менить правило (1), мы должны уметь просматривать даль­нейший текст в поисках нужного нам факта. Для этого мы будем представлять факты в форме антецедентных теорем языка PLANNER, таким образом, чтобы факт состоял из двух частей — образца и "тела" (последнее может быть лю­бой программой на языке PLANNER). ”Тело“ теоремы при­меняется только тогда, когда в базу данных вводится ут­верждение, отвечающее образцу этой теоремы. Для (1) образцом будет ’’некто, находящийся на улице". Поэтому, когда при анализе текста (3) мы обращаемся к (1), в базе данных еще нет утверждения, которое отвечало бы образцу. Однако нужное нам утверждение содержится в следующей фразе, и потому программа, выводящая соответствующий факт, срабатывает. Мы будем называть поиск некоторого факта проспективным, когда понятие-тема встречается в тексте раньше, чем утверждение, отвечающее образцу. Те же случаи, когда утверждение, отвечающее образцу, пред­шествует понятию-теме, будем называть ретроспективным поиском (как в тексте (2)). (Это незначительное расширение антецедентных теорем в MICRO-PLANNER, которые могут пользоваться только проспективным поиском.)

Покажем на ряде примеров, насколько важную роль играет проспективный поиск.

(4) Janet was thinking of getting Jack a ball for his birthday. When she told Penny, Penny said, "Don’t do that. Jack has a ball".

‘Дженет собралась подарить Джеку на день рожде­ния мяч. Когда она сказала об этом Пенни, Пенни ответила: “Не делай этого.

У Джека есть мяч".’

Здесь фраза Jack has a ball ‘У Джека есть мяч’ интерпрети­руется в том смысле, что Джеку не нужен второй мяч. Общеизвестен факт, что во многих случаях человек, имею­щий X, не хочет получить еще один X. Этот факт, возможно, следует отнести к информации о том, "чем руководство­ваться при выборе подарков". В нашем случае соответ­ствующая ситуация была упомянута в предыдущей фразе, где было сказано, что Дженет собиралась сделать Джеку подарок.

(5) Bill offered to trade his pocket knife for Jack’s dog Tip. Jack said "I will ask Janet. Tip is her dog too". ‘Билл предложил обменять свой перочинный нож на собаку Джека по кличке Тип. Джек сказал: "Я по­советуюсь с Дженет. Тип — это и ее собака"/

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

(6) Janet wanted to get some money. She found her pig­gybank and started to shake it. She didn’t hear any­thing.

‘Дженет нужны были деньги. Она нашла свою ко­пилку и начала трясти ее. Она ничего не услышала.’

Последняя фраза означает, что копилка была пуста, что следует из знаний о копилках.

В каждом из приведенных примеров информация, ис­пользуемая для получения нужной интерпретации, со-

держится в одной из предшествующих фраз. Так, в при­мере (4) фраза Jack has a ball ‘У Джека есть мяч’ сама по себе не означает, что "не надо давать ему второй мяч". Если бы это было так, нам бы понадобилась специальная проверка для отсечения этого умозаключения в ситуациях типа:

Bill and Dick wanted to play baseball. When Jack came by Bill said. "There is Jack. He has a ball". ‘Билл и Дик хотели поиграть в бейсбол. Когда мимо проходил Джек, Билл сказал: ’’Вон Джек. У него есть мяч".’

Tom asked his father if he would buy him a ball. "Jack has a ball" said Tom.

‘Том спросил отца, купит ли он ему мяч. ”У Джека есть мяч",— сказал Том.’

Bill’s ball of string was stuck in the tree.

He asked Jane how he could get it out. Jane said, ’’You should hit it with something. Here comes Jack. He has a ball".

‘Веревочный клубок Джека застрял на дереве. Он спросил Джейн, как его достать. Джейн ска­зала: ’’Его надо чем-нибудь вышибить. Вон идет Джек. У него есть мяч".’

Факты были представлены нами в форме антецедентных теорем из-за очевидной необходимости проспективного по­иска. Далее, однако, мы будем называть эти факты не ан­тецедентными теоремами, а ”демонами", поскольку это более короткое и выразительное название.

Спецификация и «выключение» демонов. Следует под­черкнуть, что модель получает информацию, содержащуюся в демонах, не в результате самостоятельного ’’познания". Эта информация вводится создателем модели. С другой сто­роны, демоны не специфичны для того или иного текста, поскольку в них нет таких единиц, как red ball ‘красный мяч’ или Jack ‘Джек’. Они содержат обобщенные сведения типа a person X ‘лицо X’, которому в одном месте будет соответствовать имя Джек, а в другом — Билл. Мы пред­полагаем наличие механизма связывания некоторых пере­менных ("спецификации" демона) в момент, когда данный демон вводится в действие.

Далее, мы хотим, чтобы демоны действовали только тогда, когда они релевантны для рассказа. Рассказ может начаться с разговора о подарке Джеку, а потом перейти к играм, в которые играют дети у него в гостях. Нам нужны способы "выключения" демонов, которые уже не нужны на данном этапе рассказа. (Нерелевантный, но действующий демон не только отнимает время и место, но и может выз­вать неправильную интерпретацию фраз.) В первом при­ближении будем считать, что демон объявляется нереле­вантным по окончании обработки определенного количе­ства фраз в тексте.

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

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

Отношения между базовыми подпрограммами и демона­ми можно представить следующим образом:

Базовая стандартная
подпрограмма
центрального понятия
вызывает
ПРОГРАММА:
ИМЯ ДЕМОНА
(образец)

Эти базовые подпрограммы отвечают не только за обра­щение к демонам. Пусть нам сообщается, что у Джека есть мяч, а у Билла — волчок. Затем Джек обменивает свой мяч на волчок Билла. Теперь мы можем задать вопрос: "Кому сейчас принадлежит волчок?" Поскольку вопросы владения существенны для наших рассказов, мы хотим быть в курсе соответствующей информации. В нашем конкрет­ном случае о перемене владельцев предметов нам должно сигнализировать высказывание с упоминанием понятия trade ‘обмен’.

Итак, каждый раз, когда будет происходить обмен, нам нужно будет иметь сведения о перемене владельцев; по­этому при каждом появлении понятия trade мы должны за­пускать в действие соответствующую базовую подпрограм­му. Конечно, программа должна быть не столь прямоли­нейной, чтобы считать фиксацией обмена такие фразы, как I will trade... ‘Я обменяю...’ или Will you trade...? ‘Не обменяешь ли ты...?’

Хорошим тестом для проверки того, следует ли относить какой-либо факт к базовой подпрограмме или к демону, может служить то, в скольких фразах выразима соответ­ствующая информация. (Естественно, мы отвлекаемся от того, что фразы можно объединять в одну сочинительными союзами. Речь идет только об интуитивной проверке того, какое утверждение нам необходимо — сложное или доста­точно простое.) Так, мы видели, что фраза Jack has a ball ‘У Джека есть мяч’ сама по себе недостаточна для умоза­ключения о том, что Джеку не нужен второй мяч. Поэтому соответствующее отношение следует отнести к демону, а не к базовой подпрограмме.

УПОРЯДОЧЕНИЕ ФАКТОВ ВО ВРЕМЕНИ И ПОИСК ФАКТОВ

Состояние в текущий момент и упорядочение фактов во времени. Мы рассмотрели две части нашей модели — де­моны и базовые подпрограммы. В настоящем разделе будут описаны две ее оставшиеся части. Вернемся к ситуации, ког­да у Джека был мяч, у Билла — волчок, и они обменялись. Если мы теперь говорим, что у Билла есть мяч, то это им­плицирует отсутствие мяча у Джека. То есть мы должны некоторым способом убрать из базы данных утверждение о том, что Джек владеет мячом. Однако мы не хотим полно­стью забывать об этом факте, так как он нужен нам для от­ветов на вопросы о том, кто владел мячом до Билла. Вместо этого мы хотим пометить соответствующее утверждение как имевшее место в прошлом. Мы исходим из того, что суще­ствует специальный аппарат, достаточно независимый от других частей модели, который отвечает за постоянное об­новление информации. Назовем этот аппарат ”упорядоче­нием фактов во времени11 (book-keeping).

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

(7) Jack was in the house. Sometime later he was at the store.

‘Джек был в доме. Некоторое время спустя он был в магазине.’

Мы хотим, чтобы на вопрос Is Jack in the house? ‘Находится ли Джек в доме?’ система отвечала No, he is at the store. ‘Нет, он в магазине.’ Но как аппарат упорядочения фактов во времени получит этот ответ? В нем имеется простое пра­вило, согласно которому ((состояние) А В) сменяет ((сос­тояние) А С), где В=+С. Например, (AT JACK FARM) ‘(НА ДЖЕК ФЕРМА)’ может сменить (AT JACK NEW- YORK) ‘(В Джек Нью-Йорк)’. Но в примере (7) мы не мо­жем просто искать утверждение AT JACK (someplace which is not the store) ‘В ДЖЕК (некоторое место, не явля­ющееся магазином)’, поскольку Джек находится именно в доме. Еще более сложным примером является следующий:

Jack was in the house. Sometime later he was in the kitchen.

‘Джек был в доме. Некоторое время спустя он был на кухне.’

Для решения этой проблемы нам понадобится теорема (8):

(8) Для того, чтобы установить, что некто (PERSON) не находится в месте (LOC),

надо выяснить, где находится PERSON, и назвать это место X.

Если X=LOC, теорема ложна, выдать ответ ’’нет". Если X является частью LOC, выдать ответ ’’нет". Если LOC является частью X, попытаться найти другое значение X.

Если другое значение X не найдено, выдать ответ ”да“.

Для примера (7) аппарат упорядочения фактов во времени попытается доказать, что Джек не находится в магазине, с помощью использования (8) и утверждения, что Джек на­ходился в доме. Затем первая из двух фраз будет отмечена как относящаяся к более раннему времени. Теоремы типа

(8) мы будем называть аппаратом "поиска фактов". Они будут представлены в форме консеквентных теорем языка

MICRO-PLANNER. (В частности, это касается (8), которая упоминалась в нашей первой статье, правда, в форме ан­тецедентной теоремы.)

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

(7) нежелательно вводить факт "Джек не находится в доме" наряду с фактом "Джек находится в магазине". Аппарат по­иска фактов отвечает и за умозаключения типа "(лицо) знает (факт)", выводимые через посредство вопросов типа "находилось ли (лицо) в том месте, где произошел (факт), или присутствовало при его упоминании?" Подобная инфор­мация может легко быть выведена, и в то же время она не слишком важна, поэтому ее не следует непосредственно записывать в базу данных.

Таким образом, наша модель имеет следующий вид:

пять ВОПРОСОВ

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

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

Итак, принимая во внимание названное разраничение, попытаемся ответить с позиций рассмотренной теории на наши вопросы.

СЕМАНТИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ. О нем наша теория говорит весьма немногое. В сущности, единственное позитивное утверждение состоит в том, что не следует огра­ничиваться лишь небольшим набором семантических эле­ментов. Например, в модели используются такие специфи­ческие, неэлементарные понятия, как "дождь", "копилка", "подарок". Может показаться, что это противоречит под­ходу. Шенка и Уилкса, которые используют семантические элементы (см. вторую статью Уилкса). Однако требование разложения единиц на семантические элементы, выдвигае­мое этими исследователями, не исключает использования инструментов более высокого уровня. Фактически эти ав­торы не отрицают, что применение инструментов более вы­сокого уровня может оказаться полезным.

ПРИМЕНЕНИЕ УМОЗАКЛЮЧЕНИЙ. Модель осу­ществляет только ненаправленный вывод во время обра­ботки входного текста. Мотивировка такого подхода была дана выше, при описании аппарата умозаключений. Такой подход является единственно возможным в модели, ис­пользующей демоны.

ОРГАНИЗАЦИЯ. Теория, представленная выше,— это прежде всего теория организации. Она утверждает, что при наличии некоторого утверждения факты, необходимые для построения умозаключений, связанных с этим утвер­ждением, выводятся в следующей последовательности: сначала с использованием базовых стандартных подпро­грамм, а затем — с использованием демонов, активизиро­ванных базовыми подпрограммами. Иначе говоря, в нашей системе важный' для языка PLANNER принцип вызова процедур по образцу диктует способ расположения фактов.

МЕХАНИЗМ ВЫВОДА УМОЗАКЛЮЧЕНИЙ. Со­гласно рассматриваемой теории, механизмом вывода слу­жат демоны, записанные на языке MICRO-PLANNER (или их эквивалент на другом языке программирования). В даль­нейшем мы укажем на недостатки такого подхода, равно как и на недостатки принятого способа организации.

СОДЕРЖАНИЕ. Модель в своем настоящем виде не содержит требований о том, что в точности мы должны знать о тех понятиях, которыми манипулируем, таких, как, например, "копилка". В принципе можно использовать модель для формулирования подобных требований, но пока никаких шагов в этом направлении не делалось.

НЕДОСТАТКИ МОДЕЛИ

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

Рассмотрим такой факт:

(9) Umbrellas are used to keep rain off one’s head. ‘Зонты используются для того, чтобы уберечь от дождя голову человека.’

Для введения этого факта в модель мы должны представить его следующим образом:

(10) Базовая стандартная подпрограмма, которая акти­визирует демон: "Возможность дождя". Образец: Человек достает зонт.

Программа: Если человек может попасть

под дождь, он достает зонт, чтобы не промокнуть.

Такая процедура будет хорошо работать для примеров типа:

It looked like rain. Jack got his umbrella. ‘Казалось, что должен начаться дождь. Джек достал свой зонт.’

Используя механизмы модели, о которых мы не упоминали, можно справиться и с такими примерами, как

As Jack was leaving the house he heard on the radio that it might rain. He went to the closet.

‘Когда Джек выходил из дома, он услышал по радио, что может пойти дождь. Он пошел в кладов­ку.’

На вопрос о том, зачем Джек пошел в кладовку, система ответит, что, возможно, он это сделал, чтобы достать зонт. (Другой возможный ответ состоит в том, что он хотел взять плащ, но для нас это не существенно, поскольку плащ также связан с дождем.) Для этого требуется дополнитель­ный механизм, обладающий способностью объединять ожи­дание "доставания зонта" с нашими знаниями о том, где обычно зонты хранятся, для вывода о том, что Джек со­бирается достать свой зонт, хотя слово umbrella ‘зонт’ в тексте и не упоминалось.

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

(11) Jack began to worry when he realized that everyone on the street was carrying an umbrella.

‘Джек начал волноваться, когда заметил, что у всех прохожих есть зонты.’

Вопрос: What was Jack worrying about?

‘Почему волновался Джек?’

Ответ: That it might rain, and he was without an

umbrella.

‘Мог пойти дождь, ay него не было зонта.’

Интуитивно совершенно очевидно, что здесь следует ис­пользовать факт типа (9), однако его формулировка (10), в том расплывчатом виде, как она записана, ничего не даст для понимания примера (И). Трудность состоит в том, что, поскольку (И) не содержит упоминания о дожде, демон, сформулированный в (10), не будет активизирован. Другими словами, наличие в (10) указателя, направленного от понятия "дождь" к понятию ’’зонт", не означает, что су­ществует и указатель, направленный в обратном направ­лении — от понятия ’’зонт" к понятию ’’дождь", в связи с чем из (11) нельзя перейти к утверждению о возможности дождя. На самом деле найти решение для подобной

проблемы не сложно, например так: (12)

ЗОНТ ----------

Основные способі

Нажать на кноп

использования:*

(Защита человека от дождя)

ч.

Размер:-------

Цель*

Форма: —«— —

Плащ

В (12) утверждается следующее. Имеется заголовок, от­носящийся к понятию "зонт", который характеризует спо­собы использования зонта с помощью указания на набор фактов такого использования. Использование зонта имеет указатель, направленный к понятию "зонт", поскольку для использования зонта необходимо иметь сам зонт. Отмечает­ся также, что цель использования зонта — защита от дождя, а защита от дождя в свою очередь может осущест­вляться с помощью использования зонта. Подобные сведе­ния, за исключением фактов, перечисленных под рубрикой "использование зонта", вовсе не напоминают программы, или демоны. Скорее, это сложный набор указателей, или, другими словами, "структура данных". Более того, как показано в работе (Charniak, 1975а), даже "использо­вание дождя" нельзя рассматривать как программу, это скорее фрагмент данных.

Нельзя не признать, что наша аргументация носит спе­кулятивный характер. Прежде всего, мы утверждаем, что надлежащее представление факта (9) имеет форму фрагмен­та данных, а не программы, и это указывает на определен­ный недостаток системы PLANNER и процедурного под­хода (см. статью Скрэгга в наст, сб.) вообще. Обе части на­шего утверждения открыты для критики. Прежде всего можно представить себе такое видоизменение демона (10), которое позволило бы использовать его и при упомина­нии единицы umbrella ‘зонт’. Это видоизменение не являет­ся простым, поскольку программа должна принимать во внимание ряд условий, при которых следует активизи­ровать этот демон, но в принципе оно возможно. В ответ на возражение такого рода мы можем повторить то, что мы говорили относительно исчисления предикатов первого порядка: если использование аппарата вступает в проти­воречие с внутренними свойствами самого аппарата, то это с большой вероятностью прогнозирует ошибочность такого подхода. (Справедливо и то, что четкой границы между про­граммой и данными не существует. Одним из факторов, позволяющих судить о том, является ли некоторая струк­тура программой или данными, служит степень детерми­нированности способов использования этой структуры. Если программу можно использовать более чем одним спо­собом, то это ставит под сомнение сам ее статус программы. Попытавшись же модифицировать некоторую программу таким образом, чтобы она включала структуры типа (11), можно незаметно для себя превратить эту программу в набор данных.)

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

Но когда мы говорим, что (9) следует представлять в формате данных типа (12), а не в формате демона типа (10), мы вовсе не утверждаем, что знания вообще не следует представлять на языке PLANNER. Как было отмечено вы­ше, PLANNER — это язык программирования, в связи с чем он обладает значительной гибкостью. Так, один из путей обхода рассматриваемой трудности состоит в том, чтобы не выделять утверждения (9) в качестве отдельного демона, а включить его в программу, содержащую всю информацию из (12), но записанную на языке PLANNER. Тогда возражения сведутся к неоднократно повторяемой нами формуле: вызывает подозрения необходимость пре­одолевать свойства, внутренне присущие некоторому фор­мализму.

<< | >>
Источник: В.А. ЗВЕГИНЦЕВ. НОВОЕ В ЗАРУБЕЖНОЙ ЛИНГВИСТИКЕ. ВЫПУСК XII. ПРИКЛАДНАЯ ЛИНГВИСТИКА. МОСКВА «РАДУГА» - 1983. 1983

Еще по теме УМОЗАКЛЮЧЕНИЯ И ЗНАНИЯ (ЧАСТЬ II)[59] СИСТЕМА, БАЗИРУЮЩАЯСЯ НА ’’ДЕМОНАХ":