Connect with us

Разработка

Грозит ли нам абсолютная власть искусственного интеллекта?

Летом этого года бурную дискуссию о развитии искусственного интеллекта начали Илон Маск и Марк Цукерберг. С развитием методов машинного обучения и нейронных сетей вопрос о будущем искусственного интеллекта обсуждается все чаще, и мнения технологических лидеров в этом вопросе различаются.

Анна Гуляева

Опубликовано

/

     
     

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

Летом этого года бурную дискуссию о развитии искусственного интеллекта начали Илон Маск и Марк Цукерберг. Маск ещё с 2014 года высказывает громкие опасения о “роботах, убивающих людей” и о том, что искусственный интеллект является главной угрозой для человечества.

Об обоснованности этих опасений Марка Цукерберга спросили в одной из его трансляций на Facebook, на что он ответил неожиданно резко и прямо:

У меня довольно четкое мнение насчет этого. Я настроен оптимистично. […] люди, которые пытаются привлечь внимание апокалиптическими сценариями – я не понимаю этого. Это действительно плохо и в какой-то степени безответственно.

Конфликт продолжился и дальше, когда Маск сказал об ограниченном понимании области Цукербергом. Кто из них имеет более весомые доводы и что думают об этом другие эксперты?

Критики

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

Потенциальная польза создания искусственного интеллекта огромна… Мы сможем уничтожить заболевания и бедность, каждый аспект нашей жизни изменится. Создание ИИ может стать крупнейшим событием в истории нашей цивилизации. Но оно может стать и последним событием, если мы не научимся избегать рисков. Вместе с пользой ИИ принесет такие опасности, как мощное автономное оружие или новые способы подавления большинства. Вкратце, создание искусственного интеллекта станет либо лучшим, либо худшим событием в нашей истории. Мы пока не знаем наверняка.

Билл Гейтс изначально поддерживал точку зрения Маска и Хокинга. В своей AMA-сессии на Reddit основатель Microsoft сказал, что “сначала машины начнут выполнять часть работы за людей”, но через несколько десятилетий ИИ станет достаточно мощным, чтобы превратиться в проблему. Гейтс также сказал, что “не понимает людей, которые не обеспокоены”. Но в недавнем споре Маска и Цукерберга Билл Гейтс не поддержал Илона.

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

Главная проблема, которая беспокоит критиков искусственного интеллекта, это вопрос регуляции. При отсутствии плана создание сильного ИИ (или artificial general intelligence) может действительно стать катастрофой. Для того, чтобы предотвратить концентрацию власти и силы у ограниченного круга людей и компаний, Илон Маск совместно с президентом Y Combinator Сэмом Альтманом создали некоммерческую компанию OpenAI. Её цель – максимально прозрачная работа над дружественным искусственным интеллектом. Первые успехи OpenAI связаны с обучением алгоритмов прохождению игр, в частности, созданному организацией боту уже удалось обыграть профессиональных игроков в Dota 2.

Энтузиасты

Гораздо больше технологических лидеров стремятся к быстрому развитию систем машинного обучения. По прогнозам Tractica, доходы отрасли вырастут от $1.4 миллиарда в 2016 до $59.8 миллиардов к 2025. Неудивительно, что многие компании хотят быстрее получить преимущества искусственного интеллекта.

Крупнейшими игроками здесь являются Google и Facebook. Создание искусственного интеллекта в Google видят в качестве расширения поискового опыта на весь веб. Компания усиленно вступила в борьбу с Apple и Amazon, представив своего голосового помощника Google Assistant. 90% дохода Google составляет текстовая реклама, и развитие нового медиума критически важно для сохранения лидерства компании на рекламном рынке. Эта позиция напрямую соотносится с личным мнением со-основателя Google и CEO Alphabet Ларри Пейджа:

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

Развитие искусственного интеллекта является одним из главных приоритетов Facebook: с 2013 года лабораторию по изучению ИИ возглавляет Ян Лекун, один из самых авторитетных ученых в этой области. Сам Марк Цукерберг крайне позитивно относится к перспективам машинного обучения:

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

Цукерберг доказывает свою позицию личным примером. В 2016 году его целью стало создание личного помощника для управления домом, основанного на системах распознавания лиц и речи и обработки языка. Результатом работы стал Джарвис, система, которая понимает голосовые запросы, может узнавать и автоматически впускать в дом гостей, а также поддерживает общение через мессенджер.

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

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

Как лучше всего реагировать на искусственный интеллект и роботов?

 

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Дизайн и прототипирование

Hyperion

Hyperion – встраиваемый в iOS-приложения плагин, помогающий контролировать верстку.

Леонид Боголюбов

Опубликовано

/

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

  

 

 

Комментарии
Продолжить чтение

Новости

Интересные материалы: 07.12

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

Опубликовано

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Программирование

Правила, которые я выработал по результатам 1000 code review

Леонид Боголюбов

Опубликовано

/

Во время работы в LinkedIn большая часть моей работы состояла из проверки кода. Были определенные ситуации, которые постоянно возникали снова и снова, поэтому я решил составить список, которым и поделился с командой.

Вот мои 3 (+1 бонус) наиболее распространенных правки, которые я делал во время code review.

Правка 1: Генерирование исключения, когда что-то идет не так

Обычно я видел такое:

List<String> getSearchResults(...) {
  try {
    List<String> results = // make REST call to search service
    return results;
  } catch (RemoteInvocationException e) {
    return Collections.emptyList();
  }
}

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

Если бы вместо этого API выбросил исключение, то наша система мониторинга немедленно подобрала бы его, обработала и мы ошибку исправили.

Во многих случаях возникает соблазн просто вернуть пустой объект после того, как вы поймали исключение. Примерами пустых объектов в Java являются Optional.empty(), нулевой или пустой список. Хорошим примером того, где это все встречается постоянно, является парсинг URL. Вместо того, чтобы возвращать null, если URL-адрес не может быть получен из строки, спросите себя: «Почему URL-адрес неправильно сформирован? Является ли это проблемой данных, которую мы должны исправить где-то выше?».

Пустые объекты не являются подходящим инструментом для работы. Если случилось что-то исключительное, то вы должны выбросить исключение.

Правка 2: Использование наиболее конкретного типа

Это предложение в основном противоречит строгому типизированному программированию.

Слишком часто я видел код, подобный этому примеру:

void doOperation(String opType, Data data); 
// where opType is "insert", "append", or "delete", this should have clearly been an enum

String fetchWebsite(String url);
// where url is "https://google.com", this should have been an URN

String parseId(Input input);
// the return type is String but ids are actually Longs like "6345789"

Использование наиболее конкретного типа позволяет избежать целого класса ошибок и, в основном, является основной причиной выбора строго типизированного языка, такого как Java.

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

  • параметры запроса и пути в URL-адресах
  • JSON
  • Базы данных, которые не поддерживают enum
  • Плохо написанные библиотеки

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

// Step 1: Take a query param representing a company name / member id pair and parse it
// example: context=Pair(linkedin,456)
Pair<String, Long> companyMember = parseQueryParam("context");
// this should throw an exception if malformed

// Step 2: Do all the stuff in your application
// MOST if not all of your code should live in this area

// Step 3: Convert the parameter back into a String at the very end if necessary
String redirectLink = serializeQueryParam("context");

Это дает ряд преимуществ. Неправильные данные немедленно обнаруживаются; в случае возникновении проблем приложение падает раньше. Кроме того, вам не нужно сохранять исключения для парсинга по всему приложению, так данные проверяются один раз. Кроме того, сильные типы сами по себе более полно описывают методы и вам не надо писать javadocs для каждого метода.

Правка 3: Использование Optionals вместо null

Одна из лучших функций Java 8 – это класс Optional, который представляет собой объект, который может существовать или не существовать.

Вопрос на миллион долларов: какое единственное исключение имеет собственную аббревиатуру? Ответ: NPE или Null Pointer Exception. Это, безусловно, самое распространенное исключение в  Java и, конечно, ошибка, которая стоит миллион долларов.

Optional позволяет вам полностью устранить NPE. Однако его следует использовать правильно. Вот некоторые советы по работе с Optional:

  • Не надо просто называть .get () в любое время, когда вам надо использовать Optional. Вместо этого внимательно подумайте о том случае, когда Optional не представлен, и придумайте разумное значение по умолчанию.
  • Если у вас еще нет разумного значения по умолчанию, тогда такие методы, как .map () и .flatMap (), позволяют отложить это решение.
  • Если внешняя библиотека возвращает значение NULL, чтобы указать на пустой случай, сразу же оберните значение с помощью параметра Optional.ofNullable (). Поверьте мне, вы поблагодарите себя позже. Нули имеют тенденцию «всплывать» внутри программ, поэтому лучше остановить их в первоисточнике.
  • Используйте Optional как возвращаемый тип в методах. Это здорово, потому что вам не нужно будет читать javadoc, чтобы выяснить, возможно ли, чтобы значение было пустым.

Бонус: Использование Unlift методов, когда это возможно

Вы должны избегать методов, которые выглядят следующим образом:

// AVOID:
CompletableFuture<T> method(CompletableFuture<S> param);
// PREFER: 
T method(S param);

// AVOID:
List<T> method(List<S> param);
// PREFER:
T method(S param);

// AVOID: 
T method(A param1, B param2, Optional<C> param3);
// PREFER:
T method(A param1, B param2, C param3);
T method(A param1, B param2);
// This method is clearly doing two things, it should be two methods
// The same is true for boolean parameters

Что общего у всех этих методов? Они используют контейнерные объекты, такие как Optional, List или Task как параметры методов. Еще хуже, когда  возвращаемый тип является тем же самым (т.е. метод принимает Optional и возвращает Optional).

Почему это плохо?

  1. Promise<A> method(Promise<B> param)
    менее гибко, чем просто
  2. A method(B param)

Если у вас есть Promise <B>, вы можете использовать 1, или вы можете использовать 2 путем «подъема» функции с помощью .map. (т.е. promise.map(method)).

Однако, если у вас есть только B, вы можете легко использовать 2, но вы не можете использовать 1, что делает 2 гораздо более гибким вариантом.

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

 

Комментарии
Продолжить чтение

Новости

Интересные материалы: 06.12

Лучшие материалы о разработке и маркетинге технологических продуктов.

Леонид Боголюбов

Опубликовано

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Популярное

X

Спасибо!

Теперь редакторы в курсе.