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

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

В начале 1980-х Digital Equipment Corporation, или DEC, начала использовать программу, которая помогала проверять именно такие заказы. В университете Карнеги-Меллон её называли R1, в самой компании — XCON. Программа применяла правила к списку выбранных компонентов и строила согласованную конфигурацию. Это не было интеллектом общего назначения и не было компьютерным инженером, спрятанным в корпусе. Это была система для ограниченной, дорогой и достаточно хорошо описанной задачи. Её успех показал, что формализованное знание иногда можно превратить в рабочий инструмент, а не только в эффектную демонстрацию.

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

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

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

Специализированный компьютер для новой профессии

В лабораториях искусственного интеллекта в США одним из главных рабочих языков был Lisp. Его создавали в конце 1950-х для обработки символических выражений и списков. Это хорошо подходило для программ, которые манипулировали формулами, словами, правилами и структурами данных, изменявшимися во время выполнения. Lisp не был «языком ИИ» по своей природе, но многие ранние символические программы писали именно на нём.

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

В Массачусетском технологическом институте Ричард Гринблатт и Томас Найт создали CADR — Lisp-машину, которая стала важным прототипом для коммерческих систем. В начале 1980-х вокруг этих разработок появились компании Lisp Machines Inc. и Symbolics. Они предлагали не просто компьютеры, а связку оборудования, операционной системы, редактора, отладчика и языка. Для разработчика это могло означать более короткий цикл между идеей, запуском и исправлением программы.

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

Но коммерциализация лабораторной технологии изменила отношения внутри самой MIT AI Lab. Часть сотрудников ушла в Symbolics, другие поддержали проект Гринблатта, а между бывшими коллегами возникли споры о стратегии, ресурсах и том, кому принадлежит право развивать созданную в лаборатории систему. В этой истории не было простого конфликта между «учёными» и «бизнесменами». Многие участники хотели, чтобы их инструменты вышли за пределы университета; спорили они о том, как это сделать и что произойдёт с общей исследовательской средой.

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

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

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

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

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

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

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

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

XCON: полезная система, у которой появились обязанности

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

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

Первую версию R1 передали DEC в 1980 году. В описаниях участников проекта говорится о сотнях правил в начальной системе, затем база значительно расширялась. К середине десятилетия её объём измерялся уже тысячами правил. Эти числа характеризуют конкретную развивавшуюся программу, но сами по себе мало говорят о качестве. Тысяча правил не гарантирует ни правильности, ни полноты; небольшая база может быть достаточной для узкой задачи, если все важные варианты учтены и результат проверяется.

Для DEC XCON была не лабораторной игрушкой. Она включилась в производственный поток заказов на системы VAX. Система помогала снизить нагрузку на ручную проверку и обеспечивала повторяемый способ находить несовместимые комбинации. Экономическая ценность возникала не из таинственной способности «думать», а из сопоставления с прежним процессом: сколько времени уходит на проверку, сколько ошибок обнаруживают поздно, как часто возникает повторная работа и какой объём заказов отдел способен обработать.

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

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

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

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

DEC пришлось сформировать команду сопровождения. В начале передачи технологии многие сотрудники компании не знали в достаточной степени язык OPS-4, на котором была реализована система, и не имели опыта работы с экспертными программами. Исследователи из университета помогали коллегам в DEC освоить код и методы его изменения. Переход занял время: организация должна была вырастить не просто пользователей XCON, а специалистов, способных выяснить, почему система применила правило, где лежит нужное знание и как проверить, что новая версия не разрушила старые случаи.

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

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

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

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

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

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