ИИ. История машины, которая научилась говорить

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

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

Этот выбор называется проблемой релевантности. Машина, которая хранит слишком мало, пропускает важные предпосылки. Машина, которая пытается учесть всё сразу, тонет в ненужных деталях. Человеку не приходится каждый раз анализировать все законы физики, потому что он умеет выделять то, что может изменить результат. В обычной беседе этот отбор кажется естественным; для программы он становится частью задачи рассуждения.

Другой невидимый компонент — знание о постоянстве. Если робот переместил чашку со стола на поднос, изменилось её положение. Цвет стены, имя владельца и форма ручки обычно не изменились. Человек не сообщает программе эти отрицательные факты после каждого действия. Мы предполагаем, что мир сохраняет большую часть своих свойств, пока что-то не дало основания думать иначе.

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

Фреймы: знакомая сцена с пустыми ячейками

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

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

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

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

Фрейм давал программе структурированный способ ожидать типичные детали. Он не избавлял её от необходимости иметь знания о мире. Он предлагал связать такие знания в более крупные блоки. Это важное различие: организация базы может уменьшить хаос, но не создаёт содержимое бесплатно. Чтобы фрейм «ресторан» был полезен, кто-то должен решить, какие участники и действия типичны, какие детали можно считать значениями по умолчанию и как описывать исключения.

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

Здесь легко перепутать два разных употребления слова «фрейм». Фреймы Минского — способ организовать знания о типичных ситуациях. «Проблема рамки», обсуждавшаяся Джоном Маккарти и Патриком Хейзом в 1969 году, — вопрос о том, как описать, какие свойства мира остаются неизменными после действия. Идеи связаны общей темой представления ситуации и её изменений, но это не одно и то же. Словарная похожесть не должна скрывать два разных инженерных вопроса.

«Обычно» не значит «всегда»

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

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

То же относится к чашке, двери и человеку, вышедшему из комнаты. Обычная чашка стоит на столе, пока нет признака, что она приклеена или закреплена. Дверь обычно можно открыть, если она не заперта. Человек не перестаёт существовать, уходя из комнаты, но его местоположение изменяется. Мы свободно сочетаем общие ожидания с частными наблюдениями; компьютерная программа должна определить, какой факт имеет приоритет и когда пересчитать прежнее заключение.

Исключения быстро образуют цепочки. Если птица ранена, она может не летать. Но некоторые птицы не летают и без травмы; другие умеют летать лишь на короткое расстояние; третьи могут летать, но не в данный момент. Добавление правил помогает конкретным примерам и одновременно создаёт новые вопросы. Что считать травмой? Как отличить «не может летать» от «не летает сейчас»? Как проверить, что новая оговорка не изменила слишком много других выводов?

У этой задачи есть человеческая сторона. Мы говорим «обычно» не потому, что в голове хранится полный каталог всех исключений. Мы можем опереться на одно общее ожидание, проверить его по ситуации и пересмотреть, если обнаружили несоответствие. Даже ребёнок в быту постоянно уточняет картину мира: увидел, что пингвин не летает, и не обязан после этого забыть, что воробьи летают. Отделить правило, исключение и область применимости — часть обыденного обучения.

Для формальной системы каждое такое различие требует представления. Значения по умолчанию экономят записи, но затем приходится описывать условия отмены. Число строк сокращается в одном месте и растёт в другом. Главное — не объём самой базы, а управление изменением вывода, когда появляются новые сведения.

Проблема рамки: что изменилось, а что осталось

В 1969 году Джон Маккарти и Патрик Хейз обсуждали трудности построения программ, которые рассуждают о мире и действиях. Одну из них назвали проблемой рамки. Представим формальную модель, где действие изменяет состояние мира. Если робот берёт чашку со стола, нужно описать, что чашка больше не стоит на столе и теперь находится в руке. Но также хотелось бы зафиксировать всё, что не изменилось: стол всё ещё на месте, стена сохранила цвет, ложка не исчезла.

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

Привычное описание задачи помогает увидеть масштаб. Человек говорит роботу: «Перенеси чашку на поднос». Роботу нужно узнать чашку, определить, где поднос, проверить, свободна ли рука, и решить, можно ли взять чашку. После выполнения он должен обновить её положение. Но не нужно менять цвет чашки, размер подноса, адрес комнаты или состояние окна — если, конечно, робот не задел их по пути. Как описать эту разницу так, чтобы программа не требовала полного списка всех неизменных фактов, но и не теряла важные изменения?

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

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

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

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

От базы фактов к карте понятий

Чтобы рассуждать о мире, программе нужна не только подборка предложений. Ей требуется карта того, о каких типах вещей идёт речь и как они связаны. Такая карта называется онтологией: формальным описанием классов объектов, отношений и понятий, используемых системой. Например, программа может различать людей, места, предметы, действия и свойства; знать, что один человек владеет объектом, что предмет находится в комнате, а действие меняет положение вещи.

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

Словарь сам по себе не равен онтологии. Словарь говорит, что слова могут означать; онтология описывает типы сущностей и допустимые связи между ними. А база знаний содержит конкретные утверждения, связанные с этими понятиями. Например, можно описать класс птиц, отношение «является экземпляром класса» и отдельное утверждение о пингвине. Чтобы получить вывод, системе нужно применить правила к этим представлениям.

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

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

Наивная физика: мир до учебника

Здравый смысл нужен не только в языке. Чтобы взять стакан с водой, человеку не приходится решать уравнения гидродинамики, но он пользуется ожиданиями о твёрдых предметах и жидкостях: стакан удерживает воду, если его не наклонить слишком сильно; жидкость перетекает в открытый сосуд; уровень зависит от количества воды и формы ёмкости. Эти знания не заменяют физику и не обязаны описывать движение каждой частицы. Они помогают ориентироваться в повседневной среде без точного расчёта на каждом шаге.

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

Этот пример показывает, почему понятия, привычные человеку, трудно превратить в базу знаний. В разговоре мы можем сказать «налей воду в чашку». Для программы надо уточнить, что считается жидкостью, как она соотносится с сосудом, почему поток прекращается, когда ёмкость заполнена, и что произойдёт, если сосуд перевернуть. Если задача требует только ответить на простую фразу, такой уровень деталей может быть избыточен. Если система управляет роботом, который переносит открытый стакан, это уже практические условия безопасности.

Можно попытаться дать системе подробную количественную модель, но для обычного действия это часто слишком дорого. Чтобы понять, что стакан нужно держать вертикально, роботу необязательно рассчитывать молекулярные силы. Ему достаточно качественного описания: жидкость удерживается стенками, но может вытечь через край; наклон меняет поверхность и направление движения. Качественные модели оперируют отношениями и типичными изменениями, а не точными числами для каждого параметра.

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

Наивная физика делает общую проблему здравого смысла более наглядной. Люди не только запоминают, что происходит, но строят рабочие причинные ожидания: если опрокинуть сосуд, жидкость может пролиться; если убрать опору, предмет упадёт; если сильно нагреть лёд, он растает. Эти ожидания позволяют предсказывать последствия новых действий. Для машины же «знать, что такое стакан» ещё не значит знать, что произойдёт при его перемещении.

Cyc: проект, которому досталась повседневность

В 1984 году Дуглас Ленат начал проект Cyc в Microelectronics and Computer Technology Corporation, известной как MCC, исследовательском консорциуме, созданном американскими технологическими компаниями. Это было время, когда отрасль внимательно следила за японским проектом компьютеров пятого поколения и за большими государственными вложениями в вычислительные технологии. MCC задумывалась как совместная исследовательская площадка; Cyc стала одной из самых амбициозных попыток превратить общий здравый смысл в инженерную программу.

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

Замысел Cyc был не в том, чтобы создать одну большую энциклопедию и научить программу читать статьи. Команде требовалась база, где знания записаны в форме, пригодной для машинных выводов. В обычном тексте фраза «если человек уронил стакан, тот может разбиться» соседствует с объяснениями, примерами и оговорками, смысл которых читатель достраивает. Для логической системы условия и связи должны быть выражены явно.

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

В статье 1995 года Ленат описывал масштаб проекта как около ста человеко-лет труда с 1984 года, примерно сто тысяч общих понятий и порядка миллиона вручную введённых аксиом здравого смысла. Он также отмечал, что система могла выводить и сохранять дополнительные утверждения. Эти числа были опубликованы руководителем проекта и показывают масштаб, которого достигла команда по собственному отчёту; они не означают, что база исчерпала повседневное знание или решила проблему общего интеллекта.

Сто человеко-лет — не сто лет календарного ожидания. Это условная сумма труда команды: несколько человек, работающих продолжительное время, в пересчёте на эквивалент полной занятости. Оценка всё равно поразительная. Она показывает, что «внести здравый смысл» оказалось не короткой настройкой программы, а долгой работой большого коллектива. База не появлялась от одного удачного алгоритма; она строилась запись за записью.

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

MCC: где повседневное знание стало долгим проектом

Cyc создавалась не в одиночной лаборатории одного профессора. Проект начался внутри MCC — консорциума крупных американских технологических компаний, основанного в Остине в начале 1980-х. Компании объединили ресурсы для долгосрочных исследований, в том числе на фоне опасений, вызванных японской программой компьютеров пятого поколения. В таком институциональном контексте идея вложить годы в общую инфраструктуру знания выглядела не отвлечённым философским хобби, а исследовательской ставкой на то, чего корпоративные вычислительные системы пока не умели.

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

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

В статье 1995 года Ленат описывал около ста человеко-лет работы над Cyc с момента старта в 1984 году. Эту оценку легко представить как коллективную смену: люди разбирали понятия, записывали утверждения, уточняли значения и следили за тем, как система их использует. Это не означает, что сто человек одновременно переписывали словарь. «Человеко-лет» — сумма усилий команды за годы проекта. Но сам масштаб показывает, как быстро задача «записать здравый смысл» перестаёт быть небольшим дополнением к программе.

Долгая продолжительность работы была одновременно достоинством и предметом вопросов. Нужна ли базе десятилетия, чтобы стать полезной? Как измерить прогресс, если полноту здравого смысла нельзя проверить конечным набором тестов? Может ли приложение получить пользу от неполной базы, пока работа продолжается? Ленат и коллеги стремились показать, что часть знания уже можно использовать, но само заявление о широкой компетентности было гораздо труднее доказать, чем успех в одной конкретной задаче.

К середине 1990-х Cyc стала примером альтернативного типа исследовательского вложения. Вместо краткого цикла разработки отдельного продукта — длительная работа над тем, что должно было помочь многим будущим системам. Такая инфраструктура редко производит один наглядный момент триумфа. Её ценность определяется тем, можно ли повторно использовать знания, согласуются ли они между приложениями и окупает ли общая база стоимость её построения.

Что делать с противоречивым миром

Даже большую базу нельзя считать единым набором безусловных истин. Мы без труда говорим, что Дракула — вампир, а затем отвечаем, что вампиров в действительности нет. Это не ошибка в обычном рассуждении, потому что мы понимаем, что одно утверждение относится к вымышленному миру, а другое — к реальному. Строго формальная база должна объяснить машине, почему эти фразы не опровергают друг друга.

В Cyc использовались контексты, называемые микротеориями: ограниченные области рассуждения, в которых связан набор утверждений и допущений. Контекст может относиться, например, к математике, к конкретной истории, к определённой модели мира или к иной области. Это позволяет системе не смешивать факт из одного набора допущений с утверждением из другого.

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

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

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

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