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

Химическая задача, которую нельзя было решить перебором

История экспертных систем начинается не с больницы и не с бизнеса, а с вопроса о молекулах. В Стэнфорде середины 1960-х исследователи работали на пересечении информатики, химии и генетики. Важную роль в проекте сыграл Джошуа Ледерберг — генетик, лауреат Нобелевской премии, который интересовался тем, как компьютеры могли бы участвовать в научном открытии. Рядом с ним работали химик Карл Джерасси, исследователь искусственного интеллекта Эдвард Файгенбаум, программист Брюс Бьюкенен и другие участники университетской команды.

Их проект получил имя DENDRAL. Название было придумано для программы, которая должна была строить возможные структуры органических молекул по измерениям масс-спектрометра. Это звучит так, будто прибор выдавал загадку, а компьютер должен был назвать ответ. На практике путь был длиннее: прибор предоставлял данные о массе молекулы и о фрагментах, на которые она распадалась при измерении. Эти фрагменты были уликами, но не готовым описанием строения.

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

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

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

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

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

Знание как способ не искать всё подряд

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

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

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

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

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

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

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

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

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

Meta-DENDRAL: можно ли получить правило из примеров?

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

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

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

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

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

У Meta-DENDRAL оставался предметный каркас: система работала с представлением химических структур и массовых спектров, в заранее определённой задаче и с определённым классом правил. Это не было современным обучением на огромном разнородном корпусе. Но проект показывал, что правила могут быть не только записаны заранее, но и предложены в результате анализа примеров. А значит, вопрос о будущем был уже не «правила или данные», а «какую роль играет эксперт на разных этапах получения, проверки и применения знания».

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

От молекул к инфекциям

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

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

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

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

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

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

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

Как работает правило, если показать его без жаргона

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

Каждая карточка — не полная медицинская инструкция. Это небольшой фрагмент знания, который система может применить к текущему случаю. В классической записи такое правило часто описывают конструкцией «ЕСЛИ условие, ТО действие или вывод». Например, в условном учебном примере: если у пациента обнаружен определённый тип инфекции и лабораторный анализ показывает такой-то признак, увеличить поддержку гипотезы о соответствующем возбудителе. Реальные клинические правила намного сложнее, и упрощённую формулу нельзя использовать как медицинский совет. Здесь важен принцип: правило связывает наблюдаемые факты с промежуточным заключением или следующим шагом.

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

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

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

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

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

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

Неопределённость без притворства точности

Одной из особенностей MYCIN стали коэффициенты уверенности, или certainty factors. Разработчикам требовался способ выразить, что свидетельство поддерживает гипотезу в определённой степени, но не доказывает её окончательно. Медицинская консультация часто начинается до того, как собраны все анализы, и разные признаки могут говорить в пользу разных объяснений.

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

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

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

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

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

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

«Почему вы спрашиваете?» — и «почему вы так решили?»

Одной из сильных сторон MYCIN было умение показывать ход работы. Врач мог спросить, почему система задаёт определённый вопрос или на чём основана рекомендация. Программа могла представить цепочку правил и фактов, которые привели к промежуточному выводу. В её терминологии объяснения типа WHY отвечали, зачем нужен вопрос; объяснения типа HOW — как система получила заключение.

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

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

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

Более того, объяснение машины может быть понятным только в рамках её собственной картины задачи. Если в базе знаний отсутствует важный факт, система не сможет объяснить влияние того, о чём она ничего не знает. Если правило слишком широко, цепочка применения может выглядеть стройной, хотя условие на самом деле не годится для конкретной ситуации. Читабельный след вывода — средство контроля, но не гарантия полного понимания.

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

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

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

Проверка системы — не только сравнение ответов

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

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

В другой, более узкой слепой оценке по десяти тестовым случаям менингита восемь независимых экспертов сравнивали варианты противомикробного лечения, предложенные MYCIN и врачами. Система получила приемлемую оценку в 65 процентах случаев; оценки схем, предложенных пятью врачами-специалистами, находились в диапазоне от 42,5 до 62,5 процента. Этот результат также требовал осторожного чтения: выборка была небольшой, оценивалась конкретная задача, а приемлемость лечения — не то же самое, что исход пациента в реальной клинической практике.