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

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

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

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

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

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

Оболочка без медицинского содержимого

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

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

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

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

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

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

Что знает эксперт, когда не может объяснить

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

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

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

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

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

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

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

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

Когда исключение рождает новое исключение

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

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

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

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

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

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

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

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

XCON: когда правила попали в производственный процесс

Если MYCIN показала, насколько серьёзной может быть экспертная система в лабораторной консультации, то проект R1/XCON показал, что правила могут войти в работу большой компании. Digital Equipment Corporation, или DEC, продавала компьютеры семейства VAX. Заказчик мог выбирать множество компонентов, которые нужно было соединить в работающую конфигурацию. Одних заказов недоставало необходимых частей; другие включали несовместимые сочетания.

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

В конце 1970-х Джон Макдермотт из Университета Карнеги — Меллона начал разрабатывать систему R1 для помощи в конфигурации компьютерных заказов. Имя XCON закрепилось за системой в DEC и расшифровывалось как Expert CONfigurer. Задача была хорошо ограничена: на входе — описание заказанной машины и набор доступных деталей; на выходе — проверенная конфигурация с размещением компонентов по стойкам. Требования были конкретными, а неправильный результат можно было обнаружить до сборки.

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

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

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

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

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

Первоначальную версию XCON доставили в DEC в 1980 году. В описании проекта начала 1980-х речь шла примерно о 750 правилах в ранней системе. Но переданной версии было недостаточно, чтобы просто подключить её и считать задачу закрытой. Правила требовали расширения и уточнения, а сама компания должна была научиться их поддерживать. В дальнейшем, по опубликованным описаниям опыта DEC, система выросла примерно до тысячи правил, а затем до нескольких тысяч. Цифры менялись вместе с версиями и практикой, поэтому полезны прежде всего как показатель масштаба, а не как одна неизменная мера.

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

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

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

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

В компании обнаружилось второе производство — производство правил

XCON помогла обнаружить неожиданный факт: одной автоматизации недостаточно, если организация не умеет поддерживать знания, на которых она работает. В 1984 году инженер DEC Джудит Бачант описала, как компания училась сопровождать систему после передачи из университета. Ранний XCON требовал исправлений и расширения; сотрудникам приходилось осваивать язык продукционной системы и налаживать контакты с экспертами, чтобы поддерживать базу.

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

Когда DEC выпускала новые варианты оборудования, правила совместимости нужно было пересматривать. Старый компонент мог исчезнуть; новая модель — потребовать иных соединений; производственный процесс — поменяться. Иногда изменение касалось только одного участка. Но если оно влияло на базовые допущения, приходилось проверять, не сломало ли новое правило сотни других случаев.

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

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

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

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

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

Когда язык правил становится отдельным рынком

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

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

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

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

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

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

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

Узкая система и большая тень за её пределами

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