Джеймс Уиттакер известен прежде всего как автор книг и визионер в тестировании. Одна из самых известных его книг — «Как тестируют в Google». Помимо Google, он работал в других гигантах вроде Microsoft. В общем, этого человека интересно послушать, о чём именно он бы ни говорил.
Недавно Джеймс выступал у нас на конференции Heisenbug, где говорил не столько о тестировании, сколько о более общих вопросах. По мнению Джеймса, уже приходит эпоха ИИ, отличающаяся от эпохи традиционного программного обеспечения, и это скажется на тестировании. По-прежнему нужно будет проверять, что технологии работают как должны и радуют пользователей — но способы проверки изменятся.
Какие скиллы нам понадобятся, чтобы успешно работать в таком мире? Узнаем под катом — мы выложили видео доклада и подготовили его текстовый перевод. Далее повествование будет от лица спикера.
Как появилось тестирование
В течение следующего часа я предлагаю вместе со мной пройти тот путь, который проделала наша отрасль за последние 30 лет, чтобы понять, как она приняла свою сегодняшнюю форму. А затем мы попробуем взглянуть на то, что нас ждёт в будущем, потому что я убеждён, что будущему нужны тестировщики.
Всего каких-то 30 лет назад мы жили в мире бумаги. Вся коммерция велась на бумажной основе. Чтобы сделать любую работу, нужно было взять бумагу, написать на ней чернилами значки, потом эту бумагу люди переносили с места на место, и так велись дела. Всё делалось вручную, и для любой работы требовались люди. Эта эпоха была очень длинной, и человечество неплохо научилось обращаться с чернилами и бумагой. Были целые склады этого добра, они назывались архивами. Документы из этих архивов иногда фотографировали, и эти фотографии хранились на микроплёнке. Для организации всего этого колоссального количества бумаги создавались библиотеки и карточные каталоги.
В 1980 — 1990-е начался переход в другую эпоху. Возникла новая технология, которая называлась ПО. Далеко не все верили в неё — хотя, конечно, до наших дней такие компании не дожили. Приходу новой технологии сопротивлялись, в особенности медленно этот процесс шёл в малом бизнесе. Для него мейнфреймы были чем-то гигантским, подозрительно связанным с корпорациями и государством. А потом появились персональные компьютеры, на которых были приложения для небольших компаний и домохозяйств. Затем широкое распространение получил интернет и, наконец, мобильные устройства.
Но давайте вернёмся к девяностым, это был ключевой период в развитии ПО. В эти годы все постепенно стали осознавать, насколько большой потенциал у этой технологии, хоть далеко и не все разбирались в ней. Потенциал же этот заключался в том, что она могла заменить собой работу огромного количества людей, производивших различные действия с бумагой. Наиболее монотонные и рутинные задачи стали автоматизироваться. Количество людей, необходимых для ведения бизнеса, резко сократилось. Если раньше главными были те, кто хорошо разбирался в бумаге, то теперь ими стали те, кто разбирался в софте.
Этот переход не был гладким. В девяностые разработчики ещё сами плохо понимали, что они делают, поскольку технология была совсем новой. Вполне закономерно, что отрасль ждали катастрофы. Баги были везде и приводили к огромным затратам. Ведь софт тогда поставлялся на дисках, с которых пользователи устанавливали его себе на компьютер. Если в программе были баги, то все диски приходилось отзывать и выпускать новые. Такие ошибки стоили очень дорого. Тогда и была изобретена роль тестировщика ПО.
Я неслучайно сказал «изобретена». До этого не существовало специально нанятых людей, ответственных только за тестирование. Во времена мейнфреймов им попросту не занимались. Если у пользователя падала программа — значит, пользователь сам виноват. На все проблемы был один ответ: обучайте пользователей. У IBM, DEC и подобных им корпораций были огромные ресурсы, и они специально занимались этим обучением.
Всё изменилось с приходом персональных компьютеров. Теперь софт поставляли тысячам, десяткам тысяч, миллионам людей. Нельзя же их всех обучить? Возникла потребность в более качественном ПО. И удовлетворить эту потребность смогла только что возникшая профессия тестировщиков. Возникли технологии, которые позволили сделать разработку софта более контролируемой, предсказуемой, и качественной, об этих технологиях мы поговорим чуть ниже.
Новые баги
А потом мы столкнулись с проблемой Y2K. Многие из вас, наверное, тогда еще не родились, или же были совсем маленькими. Когда все часы перешли с 1999 года на 2000, тестировщики внезапно оказались у всех на виду, все заговорили о «баге тысячелетия», хоть это был и не баг, а конструктивный недостаток. Создатели ПО в своё время приняли сознательное решение использовать для хранения даты две цифры, поэтому 2000 год компьютеры принимали за 1900. Мы сейчас не будем подробно обсуждать это событие, для нас сейчас важно вспомнить, что тестирование софта в тот момент внезапно оказалось в центре внимания всего общества и попало в новости. К тому времени бумага и чернила остались в прошлом, данные либо проходили оцифровку, либо возникали уже в цифровом виде. В соответствии с этим выросла и роль тестирования.
Процесс перехода на новую технологию был далеко не гладким. Возникли целые категории багов, которые были настолько новыми, что для них пришлось создавать специальные термины.
На слайде можно увидеть два таких бага. Тот, который слева, назывался The Brain. Он считается первым вирусом для MS-DOS. Он перезаписывал загрузочный сектор и замедлял компьютер до невозможности. Создатели этого бага — два пакистанских программиста. Им не нравилось, что их софт копируют пираты, и в отместку они решили испортить компьютеры пользователей. Их программа была сознательно создана с целью не дать людям работать. Произошло это в 1986 году. Именно тогда стала очевидной возможность существования вирусов, уязвимостей и прочих вещей, которые сейчас кажутся данностью. Как с этим стали бороться? Вирус The Brain попал в десятки стран и заразил тысячи компьютеров. Он был доказательством того, что софт мог быть написан злоумышленниками и быть вредоносным.
Второй вирус на слайде — AOHell. В сущности, это был первый случай фишинга. Пользователя приглашали в чат, и если он туда заходил, то вирус пытался захватить компьютер пользователя. Кстати, ещё один новый термин: фишинг. Хороший показатель того, что явление оказалось в центре внимания людей, это когда для этого явления начинают придумывать новые слова.
Если я не ошибаюсь, то AOHell возник в 1994 году. Вообще, в 1990-е годы появился целый ворох новых злонамеренных штук: вирусы-черви, вредоносные программы, программы-шантажисты, интернет-травля, порноместь и многое, многое другое. А причина этого была в том, что при разработке софта не учитывались соображения качества и безопасности. Софт писали для того, чтобы с его помощью делать деньги. И именно тестировщики первыми в 1990-е годы сказали: чёрт возьми, нам всем нужно остановиться, отдышаться, и разобраться в том, что происходит — технология явно развивается как-то неправильно. Конечно, остановиться и отдышаться нам никто не дал. Но возникло и стало бурно развиваться новое поле деятельности — тестирование и исследование тестирования. Возникли инструменты, в которых отрасль остро нуждалась. Люди вроде меня стали писать книги и создавать новые технологии. Моя первая компания занималась именно тестированием ПО. Мы пытались убедить мир в том, что, во-первых, софт изменит планету, а во-вторых, у него есть серьёзные недостатки. Мы выступали на конференциях, которые превращались в площадки для споров, и с некоторыми из тогдашних оппонентов я спорю до сих пор. Мы понимали, что дело того стоит.
От софта к ИИ
Сегодня мы стоим на пороге ещё одного перехода: от софта к ИИ. Я думаю, что он будет не менее важен, чем переход с бумаги на софт. Сейчас повторяются многие процессы, которые уже произошли 30 лет назад. В те годы многие считали, что софт глобально ничего не изменит. IBM продолжали выпускать печатные машинки — и где теперь эти машинки? DEC вообще сошли со сцены из-за своей недальновидности. Сколько было компаний, которые продолжали полагаться на старые технологии и не предвидели грядущих изменений? Sun Microsystems, Unisys, Sperry Rand.
Важно понять, что ИИ принципиально отличается от софта. Софт сделал ненужным труд огромного количества людей, занятых в бумажной экономике. ИИ делает ненужным труд ещё большего количества людей как раз благодаря своему принципиальному отличию от софта. И мы, как разработчики, должны очень хорошо это понимать. ИИ может взять на себя не только рутинные задачи, как софт; он способен мыслить, как человек. Повторю: ИИ эмулирует человеческое мышление, причём настолько хорошо, что мышление и ИИ рано или поздно становятся неразличимы. В некоторых случаях человеческое мышление сохраняет преимущества, в других ИИ уже превосходит или скоро превзойдёт человека.
ИИ настолько сильно отличается от софта, что методики тестирования софта неприменимы к ИИ точно так же, как методики тестирования бумажных систем не работают для софта. Поэтому сейчас в ИИ можно увидеть зачатки тех же проблем, от которых страдал софт на ранних стадиях своего развития; уже произошли или скоро произойдут те же самые катастрофы — к ним мы ещё вернёмся. И перед нами, тестировщиками софта, встают те же вызовы, которые стояли в девяностые. Давайте попробуем разобраться, в чём же заключается это принципиальное отличие ИИ от софта. В нашей отрасли наработаны навыки тестирования софта, созданы инструменты, достигнуто понимание основных процессов. Мы научились помогать программистам. Теперь нам нужно взяться за ИИ. А ИИ значительно сложнее, чем софт.
В определённый момент мы, тестировщики, поняли, что софт, в сущности, устроен довольно просто. У него четыре основных компонента:
входные данные
выходные данные
структуры данных
вычисления
Больше ничего в софте нет. Нам понадобились годы, чтобы это сформулировать, но когда это произошло, начался настоящий бум.
Я написал целых пять книг об этих вещах:
How to Break Software Security
Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design
Как тестировщики анализируют область входных данных? Как тестировщики изменяют входные данные? Как они угадывают, какие из возможных входов могут привести к сбою в софте? Как они определяют, какие из возможных входов, наиболее вероятно, будут применяться в определённых условиях? Как они добиваются нужного выхода или того, чтобы произошли нужные вычисления? Об этом и написаны эти книги. Самая последняя из них вышла в 2011 году, то есть почти десятилетие тому назад, самая первая — в 1999, и она по-прежнему переиздаётся. Эти книги такие долгоиграющие, потому что они представляют из себя фундаментальный анализ того, как работает софт, а следовательно и того, как он перестаёт работать.
Устройство ИИ
Существует ли на сегодняшний день подобный анализ ИИ? Ведь проделать такую работу — это редчайшая возможность! Я начал заниматься софтом на такой ранней стадии, когда ещё можно было написать книгу, которая продолжала бы издаваться через 20 лет. Если бы это был автомобиль, то за ним охотились бы коллекционеры, и за него платили бы в 10 раз больше изначальной цены. Аналогичного фундаментального анализа ИИ пока нет. Давайте попытаемся к нему приступить. Давайте применим к ИИ те же методы, которые мы применили в своё время к софту.
Чем является ИИ на наиболее фундаментальном уровне? Вначале я постараюсь дать краткую формулировку, а потом приведу два примера того, как устроен ИИ.
Мы знаем, что софт принимает входные данные, хранит их во внутренних структурах данных, делает вычисления на основе хранимых данных, и даёт некоторые данные на выход. Что бы тут могло пойти не так? Это и есть задача, которую мы решаем последние тридцать лет.
Как же дело обстоит с ИИ? В каком-то смысле ИИ, возможно, и является софтом — это бинарный код, он выполняется на микропроцессоре; но уже здесь мы сталкиваемся с принципиальным отличием. Если спросить у прохожего на улице, как вы себе представляете ИИ, то обычно у людей возникает образ чего-то человекоподобного. Но сейчас у нас перед глазами есть значительно более реалистичные примеры: Siri, Alexa, Google Home. И первое, на что мы обращаем внимание, это отсутствие пользовательского интерфейса. У ИИ нет GUI, который можно было бы протестировать. Мы разговариваем с ИИ. Компания, в которой я сейчас работаю — DefinedCrowd — занимается созданием наборов данных для ИИ, переводом текста в речь и взаимодействием ИИ с речью. ИИ начинается с данных.
И здесь кроется принципиальное отличие: если софт программируется строчка за строчкой, то ИИ обучается. Попробуйте написать код, который управлял бы автомобилем на перекрестке. У вас ничего не выйдет. Вы не сможете исчерпать все возможные сценарии операторами if-else, case и switch. Управлять автомобилем с помощью софта невозможно; а вот обучить автомобиль езде можно. Можно показать автомобилю сотни, тысячи, миллионы наборов данных, представляющих ситуации на перекрестке, и дать ему разобраться в них. Обучение ИИ похоже на обучение людей. Как научить человека водить машину? Нужно вместе сесть в автомобиль и дать возможность попрактиковаться.
Итак, первый компонент работы ИИ — это данные. Второй — метки на данных, помогающие машине понять эти данные. Мы даём ИИ 10 000 изображений кошек и помечаем каждое — на этом изображении есть кошка. А потом мы даём 10 000 изображений без кошек, и помечаем их — на этом изображении кошки нет. Со временем ИИ начинает отличать одни от других.
Основной продукт в софте — это код. Если вы умеете писать код, вы будете зарабатывать значительно больше денег, чем те, кто писать его не умеет. В 1990-е программирование было довольно редким навыком, но даже сейчас хорошие программисты ценятся очень высоко. В ИИ код не является основным продуктом. Да, для создания ИИ необходим код. Но помимо этого необходима работа с данными. Именно данные являются основным продуктом ИИ. Это фундаментальное отличие.
Методы, которыми мы пользуемся, кодоцентричны; с ИИ они не работают. ИИ требует сфокусировать основное внимание на данных. Поэтому я хотел бы сделать следующий прогноз: в то время как в современной команде, занимающейся разработкой софта, ключевыми фигурами являются программисты, в проектах, основанных на ИИ, наиболее важной ролью будет data scientist. Потому что важно уметь отличать качественные данные от некачественных, ставить правильные метки; эти метки помогают алгоритмам правильно проанализировать данные.
Мы подошли к следующей составляющей ИИ: алгоритмам. Я думаю, что в будущем в университетах будут изучать не языки программирования, а алгоритмы. Некоторые из этих алгоритмов существуют уже столетия. Всем алгоритмам, относящимся к байесовской статистике, уже 200 лет, и они относятся к наиболее фундаментальным из тех, которые используются для обучения ИИ. Аппроксимация кривой, метод наименьших квадратов, регрессия — всё это довольно простые алгоритмы, которые уже давно себя зарекомендовали. Я думаю, что в будущем уже не будут важны навыки работы со структурами данных, контрольными структурами, операторами if, switch, lookup table, умение выбрать между циклом while и for. Гораздо большим спросом будут пользоваться теория вероятности и статистика. Если бы вы спросили, какая именно теория является основополагающей для ИИ, то я бы ответил — статистика и стохастические процессы. У истоков истории исследования ИИ стоят имена вроде Маркова и Байеса.
Итак, работа ИИ начинается с данных, данным присваиваются метки, а затем эти данные передаются алгоритмам. Алгоритмы — третий компонент работы ИИ. Я сейчас не буду подробно рассказывать об алгоритмах, потому что всё-таки мы обсуждаем тестирование, а не теорию ИИ. Скажу лишь, что есть статистические алгоритмы, и есть стохастические (то есть статистические со структурой). Ваш соотечественник Марков является одним из основателей теории стохастических процессов. Кроме того, существуют модели с уровнями, модели глубокого обучения. О них мы поговорим чуть позже. Это — три основные класса моделей. И в них нужно будет очень хорошо разбираться. Умелому специалисту по анализу данных достаточно одного взгляда на данные, чтобы выбрать правильный алгоритм для них.
Всё, что мы обсуждали до сих пор, касалось процесса работы с данными. Если всё идёт хорошо, то результатом этого процесса становятся обнаруженные алгоритмом паттерны. И именно здесь обнаруживается отличие талантливого специалиста от заурядного. Мы знаем, что есть ситуации, в которых легко можно отличить умелого программиста от посредственного — например, программирование в режиме ядра. В ИИ аналогичной лакмусовой бумажкой является подбор правильных алгоритмов, понимание паттернов и комбинирование алгоритмов. Если прогнать достаточное количество изображений кошек через множество алгоритмов, рано или поздно будет найден тот алгоритм, который сможет находить на изображении кошку.
Наконец, последний компонент работы с ИИ — цикл обратной связи. Здесь мы подходим к ещё одному фундаментальному отличию ИИ от софта: софт не изменяется. Если мы написали и выпустили программу, то она будет снова и снова повторять одно и то же. Да, она будет делать свою работу быстро, точно и качественно, но если работа над программой завершена, то она никак не изменится, если только люди специально её не обновят.
А вот ИИ изменяется. Автомобиль, управляемый ИИ, может обнаружить что-то кардинально новое для себя, например, увидеть на развязке машину, едущую по встречной полосе. ИИ продолжает обучаться даже после того, как он выпущен. Мы, тестировщики софта, к такому не привыкли. Мы всегда могли полагаться на то, что тестируемый нами софт — это тот же софт, который поступит пользователям. Структуры данных, с которыми мы работали, никогда не менялись.
Софт не может в один прекрасный день встать не с той ноги, послать всех куда подальше и заняться чем-то новым. А ИИ может. ИИ совершенствуется. Машины, снабжённые ИИ, постоянно обмениваются данными друг с другом и учатся на этих данных. Это значит, что весь описанный выше процесс у них повторяется снова и снова.
Обучение ИИ
Как тестировать такие системы? Мы очень хорошо научились работать с неопределённостью во входных данных и в среде, возникающей, например, из-за различий между пользователями или между офисом и лабораторией. Все эти методы применимы и к ИИ, но не напрямую. Я очень рекомендую об этом задуматься, эта область открывает огромные возможности для тестировщиков софта. Только это уже не тестирование софта, а нечто новое, и названия для этого я не знаю. И где взять технологии, я тоже не знаю, их пока не существует.
В DefinedCrowd у нас есть команда QA, очень способная, но их деятельность ещё не прошла ту стадии документации, которую в своё время прошёл софт. Каждый день мы решаем новые проблемы и изобретаем новые способы мышления. И это очень похоже на то, что происходило в девяностые. Тогда существовало две важных конференции: Quality Week (она прекратила своё существование, кажется, в 2000 после пузыря доткомов), и STAR (она сменила собственников, но по-прежнему существует). Сейчас STAR выглядит довольно стандартно: эксперты поучают чайников. Но в девяностые всё было не так. Тогда мы постоянно делали открытия. Мы приходили на конференции со сложнейшими проблемами, и существовали специальные семинары, на которых мы совместно их решали. Мы рассказывали о чём-то, что не могли решить самостоятельно, делились опытом, а по результатам писали статью. Такие же конференции нужны сейчас в ИИ.
Давайте рассмотрим два примера ИИ. На мой взгляд, очень важно понимать на фундаментальном уровне, чем именно ИИ отличается от софта. Я предлагаю рассмотреть подход ИИ к управлению автомобилем и подсчёту числа людей в комнате. Обе эти проблемы крайне сложные, с помощью софта их решить невозможно. Беспилотных автомобилей раньше не существовало как раз потому, что ИИ не достиг ещё соответствующего уровня, а софт управлять автомобилем не может.
А вот собирать данные софт вполне может. И именно это является первым шагом в развитии ИИ. Ведь мы с вами устроены точно так же: у нас есть сенсорные устройства, наши органы чувств. У автомобилей есть микрофоны, камеры, лидары, радары. И они умеют интерпретировать своё окружение. Итак, первый шаг — это сбор данных. Связанные с ним процессы в общем-то попадают под категорию Интернета вещей (IoT). IoT очень трудно отделить от ИИ; первое является средством сбора данных для второго.
Получив доступ к данным, ИИ начинает учиться. Управляющая автомобилем система учится поворачивать направо, налево, ездить по прямой, распознавать знак «STOP», светофор, различать красный и зелёный свет. Это происходит благодаря паттернам, которые формируются на основе данных. После тысячного раза на тысяча первый раз система понимает, наконец, что перед ней, чёрт возьми, «STOP», даже если он покосившийся или погнутый.
В этом ключевое отличие: софт программируется, а ИИ обучается, как человек. Как учится читать ребенок? Ему снова и снова показывают карточки с буквами, если он угадывает правильно, ему говорят — молодец! Если ошибается, просят попробовать снова. Так же и с ИИ. Ему показывают ряд примеров, и если он совершает ошибку, то меняют метку, чтобы он знал, что произошла ошибка. Это обучение с подкреплением.
Другая технология, сделавшая беспилотные машины возможными сегодня, и отсутствие которой не давало создать их 10 или 20 лет назад — это облака. Облачные технологии перевернули всё вверх дном в мире ИИ. Сами по себе облака существуют уже довольно давно, просто раньше они назывались дата-центрами. У Google было проприетарное облако, которое занималось одним только поиском, у Amazon — коммерцией, у Facebook — хранением социальных данных. И именно в этих облаках родился современный ИИ.
Облачные хранилища смогли удовлетворить ненасытную потребность ИИ в данных. Представьте систему, которой для обучения нужно 100 миллионов изображений кошек. Или ей нужны видеозаписи со множества камер, на которых записаны автомобили на перекрестках. До появления облачных технологий алгоритмам просто негде было взять все эти данные для обучения. Поэтому неудивительно, что первыми ИИ, вошедшими в широкое употребление, были ИИ Google, Facebook и Amazon. Причём тогда никто не знал, что это ИИ, все думали, что это просто софт. Amazon были первыми, кто решил, что ИИ можно использовать не только для их специализированной области, но и для решения других проблем. Так и вышло, что они сделали первый шаг в будущее. За это нам следует быть благодарными им. Без облачных технологий ИИ бы не существовало, потому что негде было бы хранить данные.
Давайте теперь поговорим о проблеме подсчёта числа человек в комнате. Мне кажется, что решение этой проблемы во многом показательно. Я работал над ней в прошлом году в стартапе Biscuit Labs, занимающемся IoT. Сейчас эта проблема привлекла особенное внимание из-за пандемии, потому что были введены ограничения на допустимое количество человек в помещении. Давайте подумаем, как бы мы использовали ИИ для решения этой проблемы — мне кажется, это очень полезное упражнение.
Как распознать человека в комнате? Можно проанализировать запись с камеры и попытаться распознать на ней лицо. Можно проанализировать данные датчика движения — это будет дешевле. Можно установить точку доступа беспроводной сети и считать попытки подключения к ней. Можно установить в комнате микрофон и распознавать на его записи голоса. В итоге мы создали устройство, которое обрабатывало все эти сигналы.
Проблема в том, что все эти источники данных имеют свои изъяны. Нельзя просто написать код, который при обнаружении голоса увеличивал бы счётчик людей на 1. Как отличить этот голос от другого? Как убедиться, что это не голос из телевизора или радио? Как удостовериться, что это не голос человека, доносящийся из другой комнаты? Мы имеем дело с полезным источником данных, который, однако же, недостаточен для решения проблемы.
То же самое с датчиком движения. Предположим, он распознал движение. Человек ли это? Возможно, это два человека, идущие рядом, а датчик распознаёт только одного? А может, это просто крупная собака? Опять-таки, это полезные данные, но неполные. Если я нахожусь в комнате, то мой телефон будет пинговать точку доступа беспроводной сети. Но телефон можно и выключить, тогда сигнала не будет. Или наоборот, сигналов может быть несколько, если помимо телефона у меня есть часы и ноутбук. Все эти неопределённости делают проблему нерешаемой для софта. А вот ИИ с ней отлично справляется.
Выглядело это следующим образом. Мы передали алгоритму данные датчика движения, и сказали: в этот момент в комнате было 4 человека; передали данные точки доступа и сказали: 18 человек; передали запись с микрофона и так далее. В качестве данных мы также использовали показания из мест, где собираются тысячи человек, и в качестве меток использовали число проданных билетов. Другие данные мы собирали в офисах, где редко было больше 12 человек, и где люди постоянно перемещались с места на место. И на размеченных таким образом данных мы обучали систему.
И система становилась всё более точной, настолько точной, что нам самим становилось немного страшно. Причём мы использовали самые простые алгоритмы, статистические. Нам не понадобились ни стохастические процессы, ни глубокое обучение. Достаточно было регрессии. Наконец, настал ключевой момент. Мы установили систему в комнате, которую она ещё ни разу не обследовала, и попросили подсчитать число человек в ней. И система дала правильный ответ. Мы проверили её на другой комнате, и она снова дала правильный ответ. А потом ещё один. Дальше было несколько ошибок, мы её поправляли: нет, в этой комнате не 19, а 18 человек. Чем дальше, тем она становилась всё точнее. В определённый момент она научилась считать лучше нас — что неудивительно, попробуйте-ка пересчитать 75 человек в одном помещении.
В Америке мы иногда развлекаемся тем, что пытаемся на спор как можно точнее угадать число, скажем, конфет в банке. Если вы когда-нибудь пытались это сделать, то знаете, что для человека это не так-то просто. Машины же идеально подходят для решения этой проблемы. Это фундаментальная проблема, проблема мирового масштаба. Если бы существовала Нобелевская премия по тестированию софта, её дали бы за решение этой проблемы. Проблемы возможности проверки (auditability).
Как этому алгоритму удалось, чёрт возьми, определить, что в комнате 19 человек? Лично я понятия не имею. Тут дело не в коде, а в данных, потому что это ИИ, а не софт. Я не могу указать на определённый участок в коде и сказать: вот что позволило ему решить проблему. С софтом это всегда можно сделать. Всегда можно найти определённое место, в котором возник баг. Можно понять, почему именно алгоритм работает, или не работает. С ИИ мы пока так делать не умеем. Но, если я не ошибаюсь, 25 лет тому назад мы этого не умели делать и с софтом. С того времени возникли соответствующие инструменты. Такие же инструменты, обеспечивающие контролируемость, нам теперь необходимо разработать для ИИ. Потому что ИИ уже демонстрирует те же симптомы, что и софт в 1986 году, когда появился вирус Brain.
Проблемы ИИ
Приведу два примера этих симптомов.
На слайде вы видите заголовок газетной статьи: «Официальное исследование обнаружило, что система распознавания лиц работает с существенным искажением по признаку расы». И с такого рода проблемами тестировщики софта будут сталкиваться регулярно. Это ещё одна потенциальная Нобелевская премия.
История здесь следующая. В некоторых офисных зданиях была установлена систему распознавания лиц для ограничения доступа. Вы смотрите в камеру, и если ваше лицо распознаётся, дверь открывается. Но когда система начала работать, оказалось, что она пропускает только белых людей. Выяснилось, что ИИ был обучен только на белых людях. Лица из Южной Азии он тоже неплохо распознавал. Потому что данные были ограничены. Это значит, что теперь нам нужно принимать во внимание, есть ли систематические ошибки в данных; нужно уметь добиться отсутствия этих ошибок.
Если честно, мы пока не можем ответить на эти вопросы. ИИ сейчас находится ещё на самых ранних этапах своего развития. Так что такого рода ситуации вполне ожидаемы, в этих ошибках нет ничего предосудительного. Ну то есть как, пускать в здание только белых людей, конечно, нельзя. Представьте, что такого рода система работает на пожарном выходе, и люди с определённой внешностью не смогут покинуть горящее помещение.
Тут непочатое поле работы для тестировщиков. Мы, тестировщики, по природе своей люди с деструктивными наклонностями. Мы ищем прорехи, уязвимости, о которых никто другой ещё не подумал. Именно поэтому мы идеально подходим для этой работы. Наше воображение настроено на то, чтобы генерировать сценарии подобного рода катастроф. Мы прекрасно умеем разматывать клубки причинно-следственных связей, чтобы понять, почему, чёрт возьми, они происходят. Нам это нужно как воздух; я до сих пор помню первый найденный мною баг и первый написанный мною код. Я был рождён, чтобы ломать вещи. Итак, как определить, есть ли систематическая ошибка в данных? Пока что я не могу дать вам ответа на этот вопрос, точно так же, как в начале девяностых я не мог бы ответить на фундаментальные вопросы о тестировании софта.
Взглянем теперь на второй пример на слайде. Ещё один заголовок: «Чатбот от Microsoft пропагандирует расизм и геноцид в Twitter». Бот называется Tay, создан в Microsoft Research. Здесь мы сталкиваемся с другой проблемой. Tay обучался на человеческой речи. Он учился не просто говорить, а вести диалог с людьми. То есть это чертовски сложная система, гибрид стохастического процесса и алгоритма глубокого обучения. На её тренировку было потрачено очень много времени. И всего через 20 минут после того, как боту дали в распоряжение аккаунт в Twitter, он объявил, что Гитлер был героем, и стал пропагандировать расизм и геноцид.
В случае с системой распознавания лиц баг был в том, как эту систему обучали; здесь искажения в исходных данных не было. Проблема крылась в цикле обратной связи. Видите ли, ИИ продолжает обучаться после того, как работа над ним завершена. Этот процесс похож на воспитание ребенка — если у вас есть дети, вы поймёте, о чём я. Вы можете пытаться привить ребёнку какие-то ценности, научить делать правильный выбор, но после того, как ваше чадо покинуло дом, вы его уже не контролируете. Оно попадает под воздействие своих сверстников, телевизора, чёртовых Кардашьян и иже с ними. Как вы думаете, чему человек у них научится? В общем, выяснилось, что Tay, несмотря на хорошее воспитание, вырос порядочным негодяем, и его пришлось отключить.
А ведь мы сталкиваемся с подобного рода проблемами при тестировании софта. Например, в одной из моих книг говорится об атаках, манипулирующих состоянием (stateful attacks). Софт со временем может накапливать определённое состояние. Все мы пользовались сочетанием Ctrl+Alt+Delete, сбросом системы. Аббревиатура SRE означает simply reset everything (просто всё сбросить). Таким образом мы избавляемся от текущего состояния.
Есть атаки определённого типа, которые манипулируют состоянием, приводя таким образом к перегрузке и сбою. О таких атаках нужно помнить при написании, скажем, софта, управляющего атомной электростанцией. ИИ нуждается точно в такой же защите — но я пока не знаю, как её обеспечить. Нам нужно переосмыслить то, как мы взаимодействуем с софтом, и как мы его тестируем.
Где используется ИИ
ИИ сейчас проникает во множество областей. Быстрее всего он развивается в юриспруденции и медицине (по крайней мере, так дело обстоит в США). Почему? Из-за обилия там данных. Право — это вообще одни сплошные данные. Законы, нормы, судебные решения. Попробуйте найти хоть одну фотографию юриста без здоровенной полки с книгами на фоне. Системы ИИ сейчас тренируются на этих данных и учатся выполнять функции помощника юриста; в ближайшем будущем они станут обучаться работе собственно юристов. Потому что ИИ никогда не прекращает учиться, ему не нужно спать, есть, он не стареет, он бессмертен. Далеко ли в будущем тот день, когда ИИ сможет выполнять работу адвоката? Или прокурора? А может, судьи? Будут ли нужны люди в верховном суде, если ИИ способен будет принимать более справедливые решения?
Поговорим о медицине. Представьте, что Гиппократ имел бы возможность продолжать учиться в наше время, продолжать совершенствовать свои навыки, обладал бы фотографической памятью. Именно это ждёт нас в будущем. Ведь люди умирают, опытные доктора сменяются более молодыми. И это повторяется снова и снова. А ИИ не стареет. Он с годами только совершенствуется. Уже появились системы, которые умеют находить паттерны на рентгеновских снимках. Ведь это тоже данные. ИИ уже изобретает новые лекарства, комбинируя уже известные молекулы. ИИ уже изобрёл новые вакцины. ИИ добился больших успехов в борьбе с раком, чем люди. Далеко ли тот час, когда ИИ достигнет такого уровня, при котором людям заниматься медициной попросту не будет смысла?
Что дальше?
На дворе 2020 год. Мы уже давно должны были научиться тестировать системы ИИ. Нам нужно уметь обеспечивать справедливость, этичность и точность искусственных адвокатов. Мы должны уметь проверять квалифицированность искусственных врачей, проверять, что они знают что делают. До 2030 года всего 10 лет. К этому времени ИИ достигнет такого уровня, на котором возникнут качества, до сих пор принадлежавшие только людям. Ведь мы сознательно приближаем ИИ к человеку, учим выполнять работу человека.
Настанет день, когда мы не сможем отличить людей от ИИ. Alexa, Google Home и подобные им системы достигнут небывалого уровня, потому что каждую минуту они совершенствуются. И все эти бесчисленные Алексы, Сири и прочие «умные колонки» обладают единым мозгом. Они все взаимосвязаны. Что знает одна система, то знают все. Далёк ли тот день, когда мы не сможем отличить голос «умной колонки» от голоса реального человека? Думаю, этот день настанет где-то в 2030-е годы.
А самое интересное, как мне кажется, произойдёт ещё позже, в 2040-е. Быть может, настанет день, когда эта сеть, этот искусственный мозг, станет настолько сложным, что он обретёт сознание. На мой взгляд, из всех существующих в нейробиологии теорий о том, как и почему существует сознание, наиболее убедительной является та, которая связывает сознание со сложностью нейронных связей. Когда целое становится больше суммы составляющих его частей, возникает сознание. Может ли это произойти с машинами? Будут ли эти машины выглядеть, как мы? Будут ли они обладать правами? Правом голоса? Такие машины будут бессмертными. Это будет новый вид, который превзойдёт людей. Признают ли они в нас своих создателей? Станут ли поклоняться нам? Лично я в этом сомневаюсь. Скорее всего, они будут обладать самостоятельным разумом.
Меня зовут Джеймс Уиттакер. Это был необычный опыт. Представьте: говорить с маленьким огоньком в камере, и знать, что вас слушает множество людей в России и по всему миру. Но я надеюсь, вам понравилось. Мир вам.
Мы сейчас выложили на YouTube видеозаписи не только этого выступления, а вообще всех докладов с последнего Heisenbug — так что, если вы связаны с тестированием, наверняка найдете в плейлисте что-то подходящее вам. А следующая конференция Heisenbug 2021 Piter пройдет с 6 по 9 апреля.
