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

- -
- 100%
- +
В последующие годы машинный перевод не исчез, но менялись места, цели и форма работы. В Канаде, Европе, Японии и Советском Союзе продолжали создавать системы для отдельных пар языков и задач. Один из устойчивых сценариев — перевод технической или научной документации с участием человека. Машина предлагает черновик либо облегчает поиск, а специалист проверяет важные места. Такой подход не отменяет автоматизацию: он задаёт ей более скромную и проверяемую роль.
Практическая полезность могла заключаться и в масштабе. Даже если специалист должен просмотреть каждый машинный результат, система способна помочь быстро отделить явно нерелевантные документы от тех, которые стоит переводить полностью. В других случаях ограниченный словарь и повторяющиеся формулировки делали достаточно предсказуемыми большие потоки технического текста. Не всякая экономия видна в качестве отдельного предложения; иногда она проявляется в том, сколько материала организация вообще успевает обработать.
Вместе с тем компромисс требовал прозрачности. Пользователь должен знать, является ли результат готовым переводом или черновиком, где он может ошибаться и какие фрагменты требуют обязательной проверки. Если это не объяснено, читатель склонен принимать гладкий машинный текст за надёжный. Ранние системы могли выдавать связный английский даже тогда, когда неверно разрешили неоднозначность. Внешняя уверенность результата иногда маскировала ограниченность его основания.
ALPAC не поставил точку в исследовании языка. Он помог сделать цену обещания видимой. Систему следовало оценивать не по тому, что она однажды смогла сделать на сцене, а по устойчивости в ежедневной работе, качеству на незнакомых материалах и объёму помощи, которую по-прежнему оказывал человек. Именно такое более строгое понимание пользы помогло машинному переводу пережить период снижения ожиданий.
Машинный перевод не закрылся вместе с финансированием
После переоценки ожиданий исследования машинного перевода не исчезли. Изменились объём финансирования и цели; больше внимания стали уделять вычислительной лингвистике, помощи переводчику и практическим системам для ограниченных задач. Советские исследования продолжались в другом институциональном ритме; в некоторых центрах позднее пытались выдавать черновой перевод больших массивов текстов, даже если его качество оставалось умеренным.
Это важно потому, что слово «зима» может создать неверный образ полного прекращения работы. Проект, который больше не обещает универсальную замену переводчика, всё ещё может принести пользу как инструмент поиска или черновой обработки. Технология не исчезает; исчезает часть прежней уверенности в сроках и масштабе.
В 1980-х и 1990-х машинный перевод получит новый импульс через большие коллекции уже переведённых документов. IBM, в частности, исследовала статистические методы, при которых система оценивала вероятные соответствия на параллельных текстах вместо того, чтобы полагаться только на вручную написанные правила. Идея вновь сместила центр тяжести: не расписывать каждую языковую конструкцию заранее, а извлекать регулярности из примеров.
Затем нейронные модели изменят устройство переводчика ещё раз. Вместо цепочки отдельных словарных и грамматических компонентов система будет обучаться преобразованию целого предложения, используя большие массивы примеров и внутренние представления. Позднее механизм внимания поможет модели сопоставлять участки входного и выходного текста. Эти этапы относятся к дальнейшим главам книги; здесь достаточно заметить, что они не отменили вопросов, поставленных первыми переводчиками: что является контекстом, как измерять качество и кто отвечает за результат.
И сегодня кнопка «перевести» не означает, что язык стал простым. Машины покрывают больше языковых пар и жанров, чем их предшественники могли вообразить, но качество зависит от данных, предметной области, формулировки и назначения текста. Система может выдать убедительное предложение и перепутать важное имя, оттенок или отрицание. Этим она отличается от IBM 701 скорее масштабом и методом, чем отсутствием ограничений.
Язык потребовал разговора о понимании
Ранние эксперименты с переводом заставили исследователей уточнить, какой результат считать пониманием. Если программа верно преобразует предложение, нужно ли ей понимать мир в человеческом смысле? Если не нужно, достаточно ли статистической связи между формами? А если смысл зависит от ситуации, какие знания можно извлечь из текста, а какие требуется встроить отдельно?
В 1954 году публичная демонстрация ответила на узкий вопрос: компьютер может выполнить заранее определённые операции над предложениями и выдать приемлемый результат в рамках заданной системы. Следующие годы показали, что универсальное обещание требует намного больше: формальной лингвистики, контекста, словарей, знаний о предмете, человеческой оценки и масштабной работы по подготовке ресурсов.
Машинный перевод не проиграл одному набору правил. Он обнаружил, что естественный язык состоит из нескольких задач, переплетённых между собой. Правила помогли исследователям понять морфологию, синтаксис и структуру преобразования. Их предел проявился там, где значение зависело от знаний, которые люди обычно не проговаривают.
Именно поэтому заголовок этой главы говорит о языке, который не помещался в правила. Не потому, что правила были бесполезны, а потому, что язык каждый раз приносил с собой больше контекста, чем разработчики могли заранее перечислить. Ошибка не всегда находилась в грамматике. Иногда машине не хватало общего знания о мире; иногда человек ожидал слишком многого от демонстрации; иногда переводчику был нужен не автономный заменитель, а помощник, которого можно контролировать.
После истории языка книги пора вернуться к вопросу о том, что происходит, когда подобные ожидания становятся рынком. В 1980-х экспертные системы и специализированные компьютеры снова обещали практический искусственный интеллект. На этот раз у индустрии появились заказчики, поставщики и большие бюджеты. Зима, которая последует, будет не копией первой: уже существовали системы, за которые компании платили, и именно их стоимость и хрупкость станут частью следующего разочарования.
Глава 10. Вторая зима не была повтором первой
Представим обычный рабочий день в отделе, который готовит к отправке заказ на компьютер. Клиент выбрал процессор, память, диски и устройства ввода-вывода. Каждый пункт выглядит допустимым сам по себе. Вместе они могут оказаться несовместимыми: контроллер не поддерживает выбранный накопитель, памяти недостаточно для нужной конфигурации, а к одной модели нельзя подключить определённую периферию. Пока такие заказы проверяют вручную, поток ограничен временем и вниманием технических редакторов. Если ошибка обнаружится поздно, компьютер придётся пересобирать, а поставку — задерживать.
В начале 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 это не отменяло практическую пользу. Наоборот, процесс уточнения правил мог улучшать знания о самой конфигурации. Но тот же процесс создавал постоянные расходы. Успешную программу нужно было обновлять вместе с ассортиментом, обучать новых сотрудников и тестировать после изменений. Экспертная система не была покупкой «один раз и навсегда»; она напоминала инфраструктуру, которую надо обслуживать, как каталог или производственную линию.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.



