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

Город, который нужно не только строить, но и содержать

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

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

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

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

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

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

Знание о людях тоже нужно формализовать

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

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

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

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

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

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

Проблема не в том, что люди знают слишком много

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

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

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

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

Система, которая умеет вывести ответ из одного набора правил, не обязательно умеет определить, какие правила подходят. А система, которая выучила частую закономерность, не обязательно поймёт, когда данный случай исключительный. В обоих случаях ключевым становится знание об области применимости: что программа знает, чего она не знает и при каких условиях ей нужно остановиться.

Чей именно здравый смысл?

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

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

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

Правила, примеры и предел полноты

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

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

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

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

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

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

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

Как проверить то, что по определению выходит за рамки

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

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

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

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

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

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

Неизвестно — не значит «нет»

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

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

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

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

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

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

От здравого смысла к языку

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

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

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

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

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

Глава 9. Язык, который не помещался в правила

7 января 1954 года в Нью-Йорке перед журналистами и гостями IBM компьютер IBM 701 переводил русские предложения на английский. Это была публичная демонстрация, подготовленная совместно исследователями Джорджтаунского университета и IBM. На экране и в газетных отчётах появлялся результат, который прежде требовал человека: русские слова входили в машину, английские — выходили.

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

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

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

Перевод становится государственной задачей

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

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

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

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

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

До электронных компьютеров: механическая идея Троянского

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

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

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

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