сов колледжей, примерно как это делают монорельсы в аэропортах). Но вождение автомобиля во всей его полноте – социальная активность, которая испытывает влияние всего разнообразия географических, экономических, культурных и других факторов. Google ничего не говорит о том, как их программный код должен учитывать это чудесное многообразие. И, более того, просто потому, что в машинах будут ездить люди, встают непростые вопросы о допустимом риске, надежности и степени вины той или иной стороны в происшествии, на которые необходимо отвечать. У инженеров Google есть привычка постоянно хвалить друг друга за то, что они берутся за самые трудные задачи, но в этом случае они закрыли глаза на все важные и социально значимые проблемы и сделали выбор в пользу узких алгоритмических решений.
И, конечно, даже в случае автономных «гугломобилей» человеческий фактор не теряет своей значимости, просто проявляется по-другому и в другое время. Давайте заглянем внутрь алгоритма, чтобы на примере понять, насколько по-человечески может быть скроен код, который, на первый взгляд, является автономным. Рассмотрим историю первого задокументированного столкновения между автономными автомобилями. В 2007 году в результате Большого технического соревнования, профинансированного Агентством по перспективным оборонным научно-исследовательским разработкам, возник ряд технологий, на которых ныне основывается идея автомобиля от Google. Крис Армсон, инженер Google, был главным инженером победившей тогда команды, и многие из других участников соревнования сейчас тоже работают в Google.
В том происшествии автомобиль Массачусетского технологического института под названием «Талос»[22] обгонял автомобиль Корнеллского университета, который именовался «Скайнет»[23] – у этой машины были проблемы с алгоритмом планирования, и она медленно тарахтела вдоль обочины. Компьютеры на борту «Талос» классифицировали «Скайнет» как «скопление статических объектов», а не как движущийся транспорт, и приняли решение выполнить поворот, объехав это «скопление». Но корнеллская машина на самом деле не стояла на месте, а двигалась, выписывая «кренделя», схему которых «Талос» распознать не сумел. «Скайнет» рванул вперед как раз в тот момент, когда «Талос» начал поворачивать перед его носом, в результате чего оба автомобиля столкнулись, получив незначительные повреждения. Ни та, ни другая команда не выиграла соревнование.
Надо отдать должное командам, которые совместно разобрались с происшедшим и опубликовали все подробности аварии. Повинны были многочисленные алгоритмы и датчики, но ключевую роль сыграла ошибка компьютера массачусетского автомобиля, «не узнавшего» в корнелльской машине движущийся объект и не сумевшего предсказать его возможный путь. По иронии судьбы, стратегия Массачусетского института состояла в том, чтобы избегать предметной классификации дорожных объектов (например, «автомобиль» или «дорожный отбойник»), что сулило множество вероятных ошибок, а взамен лишь делить их на движущиеся и неподвижные. Но правильному анализу данных о скоростях от датчиков машины мешал случайный шум (который бывает в любых данных), поэтому, чтобы фильтровать данные об объектах, компьютер из Массачусетса использовал пороговое значение 3 м/сек. Все, что двигалось быстрее, считалось «движущимся», а все, что медленнее, – «неподвижным».
Откуда взялось это значение порога? Просто один инженер так оценил разницу между движением и неподвижностью и внес это значение в алгоритм. Я спросил моего коллегу Джона Хау, одного из авторов проекта, много ли таких пороговых чисел запрограммировано в системах вроде этой. Он ответил мне: «Очень, очень, очень много…» На самом деле «конфигурационный файл» для автомобиля «Талос» содержал примерно тысячу строк текста, которым устанавливались значения сотен переменных: расположения и данные калибровки датчиков, поправочные коэффициенты для взаимного сопоставления данных датчиков, настройки для борьбы с засветкой от солнца и т. д. Технология машинного обучения может снизить зависимость от предустановленных параметров, но и она зависит от людей-программистов, определяющих ее базовую структуру. Хау отмечает, что действие основных алгоритмов в целом сильно зависит от того, насколько верны модели неопределенности внешних факторов. По его словам, «проблема автономии в своей основе – проблема существования в неопределенном мире».
Этот краткий экскурс в код раннего образца автономной машины раскрывает, насколько глубоко такая «автономность» пронизана результатами человеческих решений в бесчисленных мелких деталях, как, например, то пороговое значение, которое мы наблюдали, а также и в более глубоких аспектах, в частности в используемых моделях неопределенности. Вспомним нашу исходную картину автономности как набора путей передачи входных данных от датчиков, которые трансформируют их в целевые действия. Чудесно наблюдать за тем, как работает такая технология, но ведь за созданием этих путей передачи информации и трансформаций стоят люди.
Именно эти люди, если вы поедете в созданной ими машине, могут вас убить.
Юристы и законоведы лишь начинают изучать проблемы ответственности, связанные с эксплуатацией автомобилей без водителей. Если в вашем понимании автономность – это когда транспортное средство само принимает решения, то цепочка ответственности может оказаться прерванной. Кто будет виноват, если ваш «гугломобиль» свалится вместе с вами в кювет? Этот вопрос касается не только того, что именно юристы пропишут в контрактах, он касается фундаментального понимания автономности: если некая система действительно работает самостоятельно, то как ее производитель может быть виноват, если что-то пойдет не так? (Некоторые полагают, что традиционное понимание ответственности производителя применимо и здесь: если компания выпускает продукт, она же и несет за него ответственность.) С практической точки зрения как можно выдать сертификат безопасности на программное обеспечение для машины без водителя?
Подход к сертификации программного обеспечения систем, от которых зависят жизни людей, наподобие авиалайнеров, хорошо отлажен, но является довольно громоздким и дорогим: он включает тщательное тестирование, при котором каждый элемент кода выполняется хотя бы один раз, и это совмещается с тщательным контролем за изменениями. Те же стандарты применяются при сертификации выполняемых людьми процессов планирования, проектирования и создания кода, удовлетворяющего тщательно продуманным требованиям, и они же распространяются на этапы контроля качества и улучшений кода после его внедрения в действующие системы. Но в своем нынешнем виде эти процедуры неприменимы для систем, которые считаются полностью автономными и где число возможных вариантов действий стремится к бесконечности. И, кроме того, как и системы технического зрения в авиации, автономные машины вроде создаваемых Google должны полагаться на высоконадежные базы данных, которые часто обновляются. Если вы пропустите установку еженедельного обновления, то можете въехать прямо в стройплощадку или кучу снега.
Как же мы можем сертифицировать предлагаемые Google модели риска и неопределенности? Любой автоматический алгоритм планирования пути включает тот или иной вариант этих неизвестных величин. Само планирование работает путем оптимизации так называемых «функций издержек», то есть заключается в постоянном поиске ответа на вопрос «Какой путь из этой точки в ту наиболее оптимален?» в отношении времени, затрат энергии, риска или какой-то другой переменной. Но сама функция издержек заключает в себе результат расстановки приоритетов людьми. В одной поездке, допустим, вы везете на заднем сиденье детей и вам хочется ехать осторожно, соблюдая все правила: в этом случае чаша весов должна склоняться в сторону безопасности, а не скорости. В другой раз вы можете путешествовать в одиночку и куда-нибудь спешить и вам захочется ехать побыстрее за счет увеличения риска. Или же у вас окажется мало топлива, и вам потребуется сделать приоритетным его экономию.
В качестве мысленного эксперимента давайте подумаем, не должен ли ваш автономный автомобиль быть оборудованным регулятором с надписью «риск»? Хотите попасть домой поскорее? Выкрутите регулятор «риск» до упора! Система переключится в режим более агрессивного вождения, вы попадете домой быстрее, и дополнительная сумма страховки автоматически спишется с вашего банковского счета. (А как насчет других водителей, которые при таком раскладе тоже рискуют больше? Повышение страховой ставки для них оплатите вы?) Или вы едете вместе с детьми? Тогда уверните регулятор риска обратно, и ваша машина будет следовать правилам дорожного движения со всей дотошностью.
Сознательно мы это делаем или нет, но именно такие решения мы принимаем каждый раз, садясь за руль. В случае автоматизированной машины от Google эти решения примет за вас некий инженер, размышляющий над ними в своем конструкторском бюро. Если мы все же хотим оставить возможность решения за собой, тогда нам необходим интерфейс. Как выглядит карта вашего города с отмеченными зонами риска? Вы когда-нибудь видели своими глазами трехмерные участки автономности?
Эти мысленные эксперименты подсказывают нам подход, альтернативный тому, который предлагает компания Google, – не устранять водителя, а заново продумать его роль. Странно манящие, призрачные картинки сканированного лазером ландшафта, которые позволяют увидеть, что собой представляют внутренние модели автомобиля без водителя, теперь становятся основой нового интерфейса и нового процесса вождения. Как любил говорить мой коллега Билл Митчелл, «приборная доска должна быть интерфейсом города, а не интерфейсом двигателя».
Представьте: больше нет ограниченных, стесняющих циклов обратной связи по поддержанию движения строго по полосам и скоростного режима. Теперь мы сами – в определяющей роли, мы являемся теми, кто задает высокоуровневую стратегию поведения для автомобиля, но и органы управления остаются в наших руках. Мы используем модели среды, обогащенные алгоритмически обработанными данными датчиков, чтобы передвигаться в разные части спектра автоматизации в разные моменты времени, то оказываясь на участках автономии и риска, то покидая их.