ИИ. История машины, которая научилась говорить
- -
- 100%
- +
Философ Джон Маккарти использовал подобные ограничения, чтобы показать, как специализированная компетентность отличается от здравого смысла. Программа может хорошо рассуждать о выбранном классе объектов, но не обладать самоочевидными для человека знаниями о пациентах, больницах, действиях и последствиях. MYCIN могла вести управляемую консультацию, не понимая свободный разговор и не представляя полную человеческую ситуацию. Её полезность зависела от того, что у пользователя есть собственное здравое суждение и понимание границ программы.
Это не опровержение MYCIN, а точное описание разделения труда. Врач предоставлял структурированные факты, понимал, в каких обстоятельствах применять систему, и мог оценить совет. Система выполняла специализированное рассуждение. Риск начинался, если забыть об этом распределении и начать воспринимать рекомендации как автономное решение.
В 1984 году Маккарти прямо писал, что экспертные системы могут впечатляюще работать в специализированной области и всё же быть хрупкими за её пределами. Они трудно расширялись на случаи, не предусмотренные разработчиками, и обычно не распознавали собственных ограничений. В этой критике заключён мост к следующей главе: за узкой компетентностью скрывалась проблема здравого смысла, то есть способности использовать фоновые знания, которыми люди обычно даже не считают нужным делиться.
Обычный человек знает, что если чашку отпустить в воздухе, она упадёт. Он предполагает, что дверь и комната продолжают существовать, даже когда на них не смотрят. Он понимает, что одно событие меняет часть мира, а не стирает всё остальное. Большую часть подобных ожиданий люди не формулируют. Экспертная система получает лишь те куски мира, которые её проектировщики успели выразить. Чтобы не выходить за границу, ей нужны дополнительные знания о том, что может произойти, что должно оставаться неизменным и когда ситуация перестала быть обычной.
Так правило «если эксперт не может описать опыт, нужны примеры» оказалось лишь частью ответа. Данные могли помочь в тех задачах, где есть много повторяемых случаев и можно определить, какой ответ правильный. Но за примерами тоже стоял человек, который выбирал их, размечал и объяснял, в каком мире они имеют смысл. А универсального набора примеров на все будущие обстоятельства не существовало.
Экспертные системы не провалились от того, что им недоставало одного волшебного правила. Они помогали там, где задачу можно было очертить, знания — добыть, входы — представить, а результат — проверить. За пределами этих условий их сильная сторона становилась уязвимостью. Нужна была либо ещё более тщательно собранная база знаний, либо другой способ получать и обновлять поведение, либо способность программы признавать неизвестность.
Проверка правил становится работой исследователя
Есть ещё одна часть этой истории, которую легко не заметить, если смотреть только на готовую рекомендацию: экспертную систему нужно проверять не только как программу, но и как формализованное знание. Если она выдала неожиданный результат, ошибка может скрываться в коде механизма вывода, в самом правиле, в том, как эксперт описал случай, или в том, как данные были представлены. Эти причины требуют разного ремонта.
Для этого разработчики собирали тестовые случаи, включая примеры, на которых система должна была дать известный результат. Затем они проверяли промежуточные выводы, задавали экспертам вопрос, почему правило сработало, и выясняли, не пропустила ли программа важное условие. Так тестирование становилось продолжением сбора знаний. Тестовый пример был не просто отметкой «верно» или «неверно», а поводом уточнить границу между двумя случаями.
Можно представить правило, которое правильно срабатывает на десяти примерах. Одиннадцатый случай показывает, что оно использует признак слишком широко. Разработчики добавляют условие; после этого двенадцатый пример перестаёт проходить, потому что условие перекрывает другое правило. Такая цепочка не означает, что подход бессмыслен. Она показывает, что формализовать компетентность — итеративная работа, где каждое улучшение должно быть проверено на соседних участках знания.
Особенно опасна «подгонка» базы только под известные примеры. Если правило становится всё точнее на небольшой подборке, но теряет устойчивость на новом случае, система запомнила особенности тестов, а не достаточно общее знание. Поэтому нужны были независимые проверки, разбор ошибок и обратная связь от людей, которые знают реальные условия работы. И даже после этого остаётся вопрос, насколько разнообразны проверенные случаи и где проходит граница применения системы.
В этом отношении экспертные системы предвосхитили современные споры о проверке ИИ. Разработчики уже тогда должны были спросить: на каких случаях измеряется качество, кто выбрал эталон, что значит приемлемая ошибка и каким образом обнаруживается выход за пределы задачи? Удобный показатель помогает сравнивать версии, но он не заменяет объяснения того, что именно система умеет. Без такой ясности цифра успеха может выглядеть надёжнее, чем сам продукт.
Что осталось после обещания заменить специалиста
Из сегодняшнего дня легко увидеть в тысячах вручную заданных правил архаичную предысторию современных моделей. Такое чтение теряет важные достижения. Экспертные системы создали практику инженерии знаний, показали ценность предметной компетенции, помогли выстроить отдельные методы вывода и заставили исследователей серьёзно обсуждать объяснение машинного результата. DENDRAL применяла знания к научным гипотезам; MYCIN исследовала консультационное медицинское рассуждение; XCON стала частью повседневной работы компании.
Они также изменили вопрос, который задавали разработчики. В ранних разговорах об ИИ часто звучало: «Как построить программу, которая сможет думать?» Экспертные системы предлагали спросить: «В каком конкретном деле человек принимает решение, какие сведения ему для этого нужны и как можно проверить, что компьютер помогает?» Вопрос стал более приземлённым и более продуктивным.
Узкая постановка задачи позволила получить результаты, которых было трудно добиться от универсальных обещаний. Но ограниченность не была случайным недочётом, который можно исправить несколькими дополнительными правилами. Она была частью модели. Чтобы расширить область, нужно было знать, какие новые факты значимы, как меняются правила и что делать с ситуацией, для которой в базе нет подходящего решения.
Проекты показали и цену человеческого знания. Оно не лежало в голове эксперта в готовом виде, ожидая загрузки в компьютер. Его приходилось извлекать через интервью и примеры, согласовывать между специалистами, переводить на формальный язык и сопровождать вместе с изменением самой области. «Автоматизация» не убирала людей из процесса. Она перераспределяла их усилия: одни помогали системе работать, другие поддерживали правила, третьи проверяли результат.
Успехи создали рынок, а рынок создал новые ожидания. Клиенты хотели, чтобы экспертная система была не только демонстрацией на нескольких случаях, но и устойчивым продуктом. Им требовалось, чтобы она работала с реальными данными, переживала изменения, объясняла ошибки и вписывалась в организацию. Обещание вышло из лаборатории, где допустимо остановиться после хорошей демонстрации, и встретилось с компаниями, которым нужно было платить за дальнейшее обслуживание.
И в этом столкновении было много ценного. XCON доказывала, что узкая программа может стать частью производства. MYCIN показывала, как машина может разбирать сложное медицинское рассуждение и предъявлять путь вывода. DENDRAL соединяла вычисления с научным опытом. Ни один из этих проектов не требовал верить, что компьютер стал человеком. Достаточно было заметить, что он научился выполнять часть человеческой работы в условиях, для которых его подготовили.
Но за каждым работающим правилом оставался вопрос: что делать с тем, чего эксперт не успел объяснить? Если область меняется, кто перепишет инструкцию? Если случай выходит за пределы базы, узнает ли программа об этом? А если требуемое знание проще показать на тысячах примеров, чем извлечь в форме правил?
К концу 1980-х интерес к экспертным системам столкнётся с новой волной разочарования. Системы были полезны, но их разработка и обслуживание оказывались дороже и сложнее, чем обещали оптимистичные презентации. Сложность корпоративного рынка, ожидания покупателей, специализированное оборудование и затраты на поддержку сошлись в отдельном кризисе. Это будет не простое повторение первой зимы: замёрзнут уже не только научные гранты, но и бизнес-модель.
Однако следующий поворот начнётся не с полного отказа от правил. Он начнётся с нового смещения внимания: вместо того чтобы описывать каждый шаг специалиста, исследователи попробуют учить программу на примерах. Данные обещали снять часть нагрузки с инженера знаний, но не могли объяснить, что значит правильный пример и почему знакомая закономерность должна сработать в новом случае.
Прежде чем эта ставка станет центральной, остаётся рассмотреть задачу, которую правила не смогли охватить. Человек постоянно использует фоновое знание о предметах, действиях, времени, причинах и других людях. Оно кажется таким простым, что его почти никогда не формулируют. Машине же нужно было сообщить всё это явно — или надеяться, что она каким-то образом догадается сама.
Так специализация привела к вопросу о мире за пределами специализации. Следующая глава начинается не с того, чего машина знает, а с того, что человек знает, даже не замечая этого.
Глава 8. Здравый смысл в коробке
Поставить красный куб на синий — простая задача. Человек обычно справляется с ней, не открывая учебник по механике и не выясняя, одинаковы ли у собеседника и у него самого понятия «верх» и «низ». Мы видим предметы, понимаем, что они занимают место, и ожидаем, что один предмет может поддерживать другой. Если куб слишком тяжёлый или стол шатается, мы замечаем это как часть ситуации. Если рука занята, задача требует дополнительного шага. Большую часть этих знаний никто не произносит.
Именно молчаливые знания и стали одной из главных трудностей искусственного интеллекта. Компьютер можно научить распознавать слова, применять правила и планировать последовательность действий. Но когда он встречает фразу «поставь это туда», ему нужно понять, что означает «это», где находится «туда», можно ли взять объект, не разрушит ли действие что-то ещё и что должно остаться неизменным после перемещения.
Взрослый человек отвечает на такие вопросы почти автоматически. Для программы каждый из них означает представление мира, правила вывода и иногда дополнительный вопрос пользователю. Слово «очевидно» не экономит вычислений. Оно только прячет работу, которую человеческий опыт давно проделал за нас.
В 1960-х и 1970-х эта проблема стала особенно заметна в исследованиях языка, планирования и робототехники. Компьютеры уже могли впечатляюще работать в маленьких, тщательно заданных мирах. Но попытка выйти из такого мира быстро приводила к вопросу: сколько всего нужно знать, чтобы машина не просто отвечала на предложение, а понимала его в обстоятельствах, которые человек считает обычными?
До комнаты блоков: советчик, которому давали сведения
Идея научить программу здравому смыслу появилась задолго до SHRDLU. В статье «Programs with Common Sense», представленной Джоном Маккарти в 1958 году и опубликованной в сборнике 1959 года, он описал гипотетическую программу, которую назвал Advice Taker — «принимающий советы». Это не была готовая система, которую можно было запустить на компьютере. Маккарти предложил направление: программа должна принимать сведения о мире в формальном языке, выводить из них следствия и выбирать действия, соответствующие поставленной цели.
Разница с обычной программой была принципиальной. Во многих программах знания о задаче скрыты в последовательности команд, написанной программистом. Если поведение нужно изменить, приходится менять саму программу. Advice Taker должен был получать новые факты и правила как утверждения о мире. Пользователь мог сообщить, что дверь заперта, что за ней находится комната и что цель — добраться до кухни; дальше система должна была рассуждать, какие действия допустимы.
Такой замысел связывал общий интеллект с тем, что программа знает, а не только с тем, какие вычислительные процедуры выполняет. Система должна была делать «достаточно широкий класс непосредственных выводов» из того, что ей сообщили и что она уже знает. На человеческом языке это напоминает способность понять простое объяснение и применить его к новой задаче. На машинном языке это требует формального представления фактов, логики вывода, описания действий и правил выбора.
В этой ранней идее уже заключена будущая проблема здравого смысла. Если системе сообщают, что дверь заперта, ей нужно знать, что запертую дверь нельзя открыть обычным способом. Если её просят пройти в другую комнату, она должна понимать, что такое перемещение, каким образом действие меняет положение человека и что при этом остаётся прежним. Нельзя просто добавить факт «дверь заперта» и ожидать, что всё остальное возникнет автоматически.
Advice Taker также показывает, что история здравого смысла не началась как реакция на одну неудачу машинного перевода или нейросетей. Уже в символическом ИИ было ясно: вычислительной системе мало знать алгоритм. Ей нужно представление о том, в каком мире она действует, и механизм для рассуждения о последствиях. Маккарти сформулировал задачу, а последующие проекты исследовали отдельные способы её решения — от формальной логики до микромиров и больших баз знаний.
Между гипотетическим советчиком и SHRDLU есть важное различие. Advice Taker должен был рассуждать о широком круге фактов и действий, но оставался программным предложением. SHRDLU стала работающей системой, которая решала реальную исследовательскую задачу, только в очень ограниченной области. В этом смысле она не исполнила мечту о здравом смысле, а превратила часть мечты в проверяемый эксперимент: можно ли связать язык, знания и действия так, чтобы машина поддерживала последовательный диалог?
SHRDLU: разговор в комнате с цветными блоками
В конце 1960-х аспирант Массачусетского технологического института Терри Виноград начал работать над программой, которая могла бы взаимодействовать с виртуальным миром блоков через английский язык. Проект описан в его диссертации и техническом отчёте MIT 1971 года под названием Procedures as a Representation for Data in a Computer Program for Understanding Natural Language. Программа получила имя SHRDLU.
Пользователь мог вводить команды и вопросы: попросить передвинуть предмет, уточнить положение фигур, спросить, что лежит на чём, или попросить объяснить, почему система выполнила действие. Программа разбирала грамматику предложения, связывала слова с объектами мира, строила план и меняла состояние виртуальной сцены. Затем она могла ответить на вопросы о получившемся расположении.
Для зрителя это было необычайно убедительно. Компьютер не просто повторял готовые фразы. Между текстом и ответом находился мир, в котором существовали красные и синие блоки, пирамиды, столы и действия вроде поднять, поставить или переместить. Если команда не могла быть выполнена сразу, программе требовалось определить препятствие и найти допустимую последовательность действий. Если вопрос ссылался на объект из предыдущей реплики, система использовала контекст диалога, чтобы понять, о чём речь.
В самой работе Виноград подчёркивал, что система использовала синтаксическую структуру, сведения о контексте и общие знания о своём мире. Эта комбинация была важнее одного удачного языкового трюка. SHRDLU должна была понять, какие слова относятся к каким объектам, что пользователь хочет сделать и как изменить описание мира, чтобы выполнить команду.
Возьмём простой пример. Если пользователь попросит переместить блок, который в данный момент накрыт другим предметом, система не может просто выдать команду «поднять». Сначала надо определить, что мешает. Затем освободить нужный объект, выполнить перемещение и учесть новое положение. Для этого нужны одновременно язык, планирование и модель физического мира. Ошибка в любом слое ломает всю цепочку: программа может неверно разобрать фразу, выбрать не тот объект или построить невозможный план.
Именно поэтому SHRDLU исторически интересна не только как демонстрация понимания языка. Она соединяла несколько задач, которые часто изучались отдельно. Языковой анализ связывался с тем, что система знала о предметах; знание влияло на план; действие меняло модель сцены; новая модель становилась контекстом для следующего вопроса. Пользователь получал целостный ответ, потому что несколько компонентов были согласованы вокруг одной ограниченной области.
Но граница этой области была очень чёткой. В мире программы находились только те предметы, свойства и действия, которые разработчики включили в описание. Слова «блок», «пирамида» и «на столе» имели конкретные значения. «Пирамида» не могла внезапно оказаться зданием, финансовой схемой или метафорой иерархии. Система не должна была разбираться в людях, погоде, расписаниях, собственности или политике. Любой смысл за пределами этого словаря оставался за пределами мира SHRDLU.
В этом нет научного обмана. Микромир — полезный способ изучать сложную проблему: исследователь контролирует объекты и условия, поэтому может выяснить, как программа разбирает фразы, планирует действия и отслеживает контекст. Лабораторный мир работает как модельный стенд для двигателя. Если двигатель на нём работает, это настоящее достижение. Но модельный стенд не доказывает, что автомобиль уже готов к любой дороге.
SHRDLU показывала не то, что компьютер почти научился понимать любой разговор. Она показывала, что сочетание языка с моделью мира может дать значительное поведение в пределах хорошо описанной ситуации. Именно это ограничение позволяет оценить результат честно: система была сильной там, где её знания и словарь совпадали с задачей.
Что скрывалось за простой командой
Снаружи SHRDLU выглядела как собеседник, который просто понял просьбу. Внутри команда проходила через несколько слоёв обработки. Программа анализировала предложение, строила его синтаксическую структуру, определяла значение слов в своём словаре, сопоставляла их с объектами и отношениями в блоковом мире, а затем передавала полученную цель планировщику. Если пользователь спрашивал о последствиях действия, система обращалась к представлению сцены и истории диалога.
Для обычного читателя важен не список компонентов, а то, что каждый слой менял смысл следующего. Глагол «поставь» требовал понимать, какой предмет перемещается и где он должен оказаться. Предлог «на» обозначал отношение опоры, а не просто направление движения. Местоимение могло ссылаться на объект, упомянутый раньше. Команда «убери блок» означала действие, которое нужно выполнить в мире, а не текст, который достаточно пересказать другими словами.
Планировщик раскладывал задачу на действия и проверял условия, при которых они возможны. Чтобы поставить один блок на другой, нужно было освободить нужную поверхность и убедиться, что верхний предмет можно поднять. Если он накрыт третьим предметом, сначала придётся переставить его. Такой план требует причинной модели: действие меняет положение объекта, а изменившееся положение влияет на то, что можно сделать дальше.
Именно связь между процедурой и описанием мира отразилась в названии диссертации Винограда. В его системе грамматические знания не были только статической таблицей правил; процедуры помогали обрабатывать фразы и соотносить их с действиями. Мир тоже не был пассивной картинкой. Его состояние обновлялось, когда программа выполняла команду, а новые вопросы опирались на обновлённое состояние.
Подобная интеграция была сильной и одновременно хрупкой. Если команда содержала незнакомое слово, внеплановый тип объекта или действие, которого нет среди допустимых операций, программа не могла компенсировать пробел «интуицией». Человек может догадаться, что «убери вот эту штуку» значит переместить предмет подальше, даже если не знает его точного названия. SHRDLU нуждалась в том, чтобы нужный объект и действие были представлены в её модели.
Ограниченность позволила Винограду проверить, как язык может управлять планом и как план возвращается в язык в виде объяснения. Это куда интереснее, чем просто сказать, что в системе был маленький словарь. Область была небольшой, но внутри неё программа должна была соединить грамматику, объекты, причины, действия и разговорный контекст. Именно это сделало демонстрацию сильной и породило вопрос, можно ли расширить такой способ работы на более богатую среду.
Почему маленький мир так легко принять за большой
Причина привлекательности SHRDLU была в том, что программа отвечала на несколько запросов подряд и учитывала уже сказанное. Это выглядело естественно для человека: мы тоже поддерживаем разговор, помним, что обсуждали только что, и не начинаем каждую реплику с нуля. Когда система поняла «тот блок» как конкретный объект из сцены, она словно разделила с пользователем общий контекст.
Но общий контекст у них был разным. Человек приносит с собой огромный запас фоновых ожиданий; у SHRDLU были геометрия блоков, набор допустимых действий и сведения о предыдущих репликах. Система могла разрешить неоднозначность, потому что набор кандидатов был мал, а все релевантные отношения уже находились в модели. Если в сцене всего несколько блоков и один красный куб, понять «красный куб» сравнительно легко. В обычной комнате красных предметов может быть несколько; в разговоре речь вообще может идти не о вещи, а о сообщении, решении или человеке.
Представим ресторан с пятью блюдами. Клиенту достаточно сказать «то острое, которое я брал в прошлый раз», и официант может найти подходящий вариант. Теперь заменим меню всем содержимым супермаркета, библиотеки, вокзала и семейной переписки. Вопрос «то, о чём мы говорили вчера» получает бесконечно больше возможных отсылок. Ограниченное пространство смыслов позволяет системе делать то, что в открытом разговоре потребовало бы гораздо большего знания о людях и мире.
Из этого не следует, что ограниченная система лишь имитирует понимание и потому неинтересна. Она показывает, какой именно вклад в понимание вносит контекст. Грамматика помогает определить структуру фразы, но сама по себе не сообщает, к какому предмету относится местоимение, какой смысл слова важен и какое действие возможно. Чтобы связать предложение с миром, нужно знать хотя бы некоторые свойства мира.
Виноград построил не готовую теорию всего человеческого понимания. Зато SHRDLU наглядно показала, почему языковая система, оторванная от предметов и действий, быстро упирается в пределы. Смысл фразы возникает не только из слов и их порядка. Он зависит от ситуации, предыдущего разговора, ожиданий и предположений о том, что обычно бывает.
Это наблюдение стало особенно важным, когда исследователи пытались перейти от маленьких искусственных областей к повседневным задачам. Утверждение «машина разобрала английскую команду» звучит одинаково, но за ним могут стоять совершенно разные возможности: разбор фразы в словаре из двухсот терминов или работа с произвольными отсылками в неизвестных обстоятельствах. Продемонстрировать первое можно в лаборатории. Второе требует общего знания, которое трудно даже перечислить.
SHRDLU стала для ИИ одновременно достижением и предупреждением. Она дала исследователям конкретную работающую систему, где язык и действие были связаны. И вместе с тем заставила смотреть внимательнее на сцену: какие части мира уже были заданы, какие вопросы исключены, сколько свободы оставалось пользователю. Вопрос «что программа сделала?» пришлось дополнить вопросом «какие предположения сделали это возможным?»
Что человек знает, не замечая
Проблема здравого смысла не сводится к словарю бытовых фактов. Если бы нужно было только записать, что стул обычно имеет сиденье, а птица обычно умеет летать, задача оставалась бы большой, но конечной. Трудность в том, что знания должны не просто присутствовать в памяти машины. Система должна понимать, когда они применимы, как они связаны с другими сведениями и что делать, когда они конфликтуют с наблюдением.
Допустим, программа знает, что стеклянные чашки хрупкие. Если человек спрашивает, сколько такая чашка весит, эта информация может не иметь значения. Если робот собирается смахнуть её со стола, она становится критичной. Если чашка специально изготовлена из ударопрочного стекла, общее знание требует оговорки. Значит, системе необходимо не только хранить факт, но и оценивать его отношение к текущей цели и ситуации.