Русский
Русский
English
Статистика
Реклама

Голосовые помощники

Голосовой помощник для совершения операций на бирже

02.07.2020 18:23:23 | Автор: admin
Алиса, купи одну акцию Яндекс.
Заявка на покупку Яндекс по рыночной цене, тикер: YNDX, количество акций: 1, для подтверждения скажите подтверждаю, для отмены скажите нет.
Подтверждаю.
Заявка исполнена.


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


Как всё начиналось



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

Время шло, в каталоге навыков Алисы появлялись бесполезные банковские голосовые помощники (не в обиду разработчикам). У Сбербанка, например, помощник озвучивал условия кредита и предлагал прийти в отделение, у Тинькофф тоже самое, только вместо отделения предлагал перейти на сайт, чтобы заполнить заявку. Ребята, кто разрабатывал это, пожалуйста, не обижайтесь на меня, но, правда, я не хочу никуда идти, ни в отделение, ни на сайт, я хочу иметь возможность перевести 100 рублей другу фразой: Алиса, отправь 100 рублей Саше.

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

В какой-то момент, я просто встал с кровати и начал делать приватный навык для Алисы, чтобы голосом управлять своим брокерским счётом. Я перебрал своих брокеров и остановился на Тинькофф Инвестиции OpenAPI. Затем на месяц погрузился в изучение возможностей платформы Яндекс.Диалоги, и ещё через некоторое время купил первые ценные бумаги через голосовой помощник на Московской бирже один лот Банк ВТБ. Надеюсь, эта сделка войдёт в историю.

С самого начала я решил, что не буду прятать исходный код, чтобы любой желающий мог настроить себе голосовой помощник: https://github.com/denismosolov/oliver

Возьми с полки пирожок и расскажи наконец о проблемах



Компаний много, а я один



Когда я говорю Алисе: Купи одну акцию Яндекс, то платформа Яндекс.Диалоги извлекает название ценной бумаги из фразы и преобразовывает в специальный идентификатор FIGI (Financial Instrument Global Identifier), необходимый для взаимодействия с торговой платформой через OpenAPI. Вот так выглядит FIGI для акций компании Яндекс, торгующихся на Московской бирже: BBG006L8G4H1.

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

entity EFigi:    values:        BBG005DXJS36:            %exact            TCS            %lemma            тиньков(банк)?            тинькоф(банк)?            тинькофф(банк)?            ти си эс (груп)?


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

Люди называют одни и те же компании по-разному, например, кто-то скажет Сбер, а кто-то Сбербанк. На бирже торгуются обычные акции Сбербанка и привилегированные (префы). Хочется учесть все популярные варианты.

Компания торгуется на двух биржах в разной валюте



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

Например, когда я говорю: Продай одну акцию TCS Group, и у меня на счёте есть только акции в рублях, то нужно без уточнений продавать в рублях на Московской бирже. Если у меня на счёте акции TCS Group в рублях и долларах, то Алиса должна задать уточняющий вопрос: У вас глобальные депозитарные расписки TCS Group в рублях и в долларах, в какой валюте вы хотите продать?.

Я пока это не реализовал и TCS Group всегда покупается и продаётся за доллары. Но, надеюсь, скоро возьмусь за выставление заявок на покупку и продажу ценных бумаг по заданной цене (лимитные заявки), а там уже научу голосовой помощник разливать акции на разных биржах по валюте, которая будет в цене покупки или продажи.

Ошибки распознавания



Люди спрашивают, а что будет, если Алиса распознает что-то не так, например, купит не ту бумагу или не то количество? Для этого я предусмотрел подтверждение сделок. После того, как Алиса распознает команду на покупку или продажу, она проговаривает детали сделки и ожидает подтверждения. Если подтверждения не последует, то сделка не состоится.

Сообщение при подтверждении сделки звучит так: Заявка на <покупку | продажу> <$название_ценной_бумаги> по <$цена_за_одну_бумагу>, тикер: <$тикер>, количество акций: <$количество>, для подтверждения скажите подтверждаю, для отмены скажите нет.

Такое подтверждение отлично воспринимается на слух, но есть одна недоработка. Алиса плохо читает название тикера, например, YNCX, звучит как йинкс.

Я хотел написать функцию, которая бы разбирала тикеры по буквам, и для каждой буквы проигрывала звук из озвучки английского алфавита. Код принимал бы на вход строку YNDX, а возвращал вот такую строку в формате tts:
<speaker audio="sounds-y.opus"><speaker audio="sounds-n.opus"><speaker audio="sounds-d.opus"><speaker audio="sounds-x.opus">

Алиса будет проигрывать звуки, и в теории всё будет звучать хорошо.

Безопасность при совершении сделок



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

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

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

Если знаете способы подтверждения сделок в подобных приложениях за рубежом или просто хотите поделиться идеей, то, пожалуйста, напишите в комментариях.

Вместо заключения


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

До встречи в будущем!
Подробнее..

Дипфейки, реверс-инжиниринг, муз. программирование и аудиоинтерфейсы за рулем что почитать аудиоману

04.07.2020 16:09:21 | Автор: admin
Это подборка материалов по теме программирования, компьютерного железа и ПО для автомобильных аудиоинтерфейсов. Всех заинтересовавшихся темой, приглашаем под кат.


Фото Jefferson Santos / Unsplash

Как программируют музыку. Прежде чем взять и влиться в тему музыкального программирования, стоит осмотреться. Предлагаем вашему вниманию компактный обзор специализированных инструментов. Первый из них называется Csound наследник семейства MUSIC-N, прямиком из Bell Labs 1960-х годов. В середине 80-х его доработал специалист из MIT, а теперь на Csound играет легендарный BT. Расскажем о его особенностях, приведем примеры использования, плюс обсудим SuperCollider и Pure Data, принадлежащих все к тому же языковому семейству MUSIC-N.

Кто занимается дипфейк-аудио. Обсуждаем Neural Voice Puppetry разработку сотрудников Мюнхенского технического университета и Института информатики Общества Макса Планка. По записи голоса и фотографии она синтезирует речь и моделирует мимику. Аналогичное решение сингапурских коллег может нативно прикрутить реплики одного человека к видеозаписи с совершенно другим лицом. Рассказываем, где применяют такие наработки (конечно, не там, где вы подумали) и вспоминаем другие проекты по теме быстрого редактирования аудио.

Реверс-инжиниринг-пост. Вслед за материалами о Sound Blaster 1.0 и Innovation SSI-2001 наш свежий разбор того, что удалось выяснить энтузиастам об усилителе в Nintendo Game Boy Color.



В статье мы напоминаем, чем известна эта консоль, показываем структуру чипа (схема выше), объясняем особенности транзисторов, использованных резисторов и конденсаторов, а еще даем компактный обзор других реверс-инжиниринг-проектов по теме легендарного Game Boy.

Если дэт-метал, то нейросетевой. Заменят ли алгоритмы музыкантов? Это вопрос, к которому мы возвращаемся в очередной раз. Обсуждаем возможности разработок по теме синтезатор NSynth Super, систему ИИ Dadabots, тематический стартап Jukedeck и инструментарий OpenAI.

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

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


Фото Miguel ngel Hernndez / Unsplash

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

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



Дополнительные материалы:

Домашнее аудио от песенных вечеров до механических проигрывателей
Как домашнее аудио становилось действительно массовым
Как развивалось домашнее аудио: эра винила


Подробнее..

Hey, Google умные устройства будут активироваться без команд

12.11.2020 20:10:42 | Автор: admin

Photo by Cristian Cristian on Unsplash

В ближайшем будущем активировать голосовую колонку Amazon Echo или Nest Audio, поиск в Google или Siri на устройствах от Apple можно будет без приветствия вроде Hello, Google! При помощи ИИ ученые из США разработали алгоритм, благодаря которому умные голосовые помощники понимают, что человек обращается к ним.

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

Ученые из Университета Карнеги Меллона отмечают, что разработанный алгоритм определяет направление речи (direction of voice, DoV) с помощью микрофона.



DoV отличается от выявления направления, откуда исходит голос (direction of arrival, DoA).



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

Помимо прочего, технология уменьшит количество случайных активаций голосовых помощников, которые все время находятся в режиме ожидания.

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

Алгоритм также анализирует распространение звука в первые 10 миллисекунд. Здесь возможны два сценария:

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

Алгоритм замеряет форму сигнала, вычисляет пик его интенсивности, сравнивает со средним значением и определяет, был направлен голос к микрофону или нет.

Измеряя распространение голоса, ученые смогли с точностью до 93,1% определить, находится ли спикер перед конкретным микрофоном или нет. Они отметили, что на сегодня это лучший подобный результат и важный шаг на пути к внедрению решения в существующие устройства. При попытке определения одного из восьми углов, под которым человек смотрит на девайс, достигнута точность в 65,4%. Этого пока недостаточно для приложения, суть которого в активном взаимодействии с пользователями.

Для сбора информации инженеры использовали Python, сигналы обрабатывались на основе алгоритма-классификатора Extra-Trees.

Собранные во время разработки данные и алгоритм открыты в GitHub. Их можно применить при создании собственного голосового помощника.

Подробнее..

Все, что вы хотели знать про диалоговый UXUI в проектировании чат-ботов

21.05.2021 20:16:58 | Автор: admin

Читайте в статье: что такое диалоговый UX/UI и какего создавать, а также полезные лайфхаки при проектировании сценария длячат-бота.

В марте 2021 годааналитики Voicebot провели опрос300 маркетологов и узнали, что они думают про голосовых помощников. Оказалось, что более 60% специалистов уверены в пользе голосовых ассистентов длямаркетинга. Виртуальные помощники и чат-боты больше не новинка и не пустой повод дляхайпав новостях. Бизнесактивно использует разговорные технологии дляэффективной коммуникации спользователями, дляпрямых продаж и создания прочных связей сбудущими и настоящими клиентами. И мы в Just AI уверены, что в будущем эта тенденция будет толькорасти.

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

Мы будем двигаться отсамого простого ксложному. Если знаете азы сразу листайте кблоку дляпродвинутых пользователей.

Для новичков. Что такое диалоговый UX и в чем его отличие отдиалогового UI?

Начнем спростого: UX это user experience или опыт, который получает пользователь в ходе его взаимодействия синтерфейсом сервиса, продукта или услуги. UI это user interface, пользовательский интерфейсили то, что мы привыкли называть дизайном.

Идем дальше. Диалоговый UX это опыт пользователя, который позволяет ему общаться сботом, свиртуальными помощниками или людьми. К нему относятся: общение сголосовыми помощниками, игра в голосовую игру, голосовое управление автомобилем, голосовая команда в поисковую строку.

А диалоговый UI это интерфейсы, которые позволяют взаимодействовать между пользователем и системой. Элементом диалога может стать голосовой или текстовый ввод и вывод информации, а также модальное окно на сайте, поп-ап в приложении и т. п.

В рамках диалогового UI мы рассматриваем два условных типа интерфейсов: голосовой и разговорный. Кажется, что это синонимы, но не все такпросто. Под разговорным интерфейсом или Conversational User Interface (CUI) подразумеваются все интерфейсы, скоторыми можно общаться на естественном языке кактекстом, таки голосом.

Соответственно, в понятие CUI входит Voice User Interface (VUI) или голосовой интерфейс. Он предполагает взаимодействие сустройством спомощью голоса.

Так выглядит схема диалогового интерфейсаТак выглядит схема диалогового интерфейса

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

Закрепим. Итак, Алиса в Яндекс.Станции это VUI, а в смартфоне, где сней можно говорить голосом и чатиться CUI. А все вместе это диалоговый UI.

Кто создает диалоговый UX и UI при проектировании чат-ботов

Созданием диалогового UХ и UI занимается отдельный специалист. Он разрабатывает диалоговый пользовательский интерфейс, продумывая пользовательский опыт.В Just AI мы называем такого специалиста дизайнер разговорных интерфейсов.

Но в русском языке точный термин до сих пор не закрепился. Поэтому можно встретить разные переводы. Так, на HH.ru мы встретили 17 разных названий вакансий: дизайнер диалогов, диалоговый редактор, digital-лингвист, voice UX designer, диалог-дизайнер, сценарист чат-бота и такдалее. Подробности о нашем исследовании смотрите в вебинаре Создатели разговорных интерфейсов: кто они и чем занимаются?. На нем мы рассказали, каксделать так, чтобы специалисты и компании нашли друг друга.

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

Собрали основные термины из этой статьи. Сохраняйте себе, чтобы не потерятьСобрали основные термины из этой статьи. Сохраняйте себе, чтобы не потерять

Для продвинутых. Какразработать диалоговый UX/UI

Шаг 1. Узнайте, подходит ли разговорный интерфейсдляваших задач.

Чтобы разобраться в этом вопросе, просмотритечек-листоткомпании Google. Для вашего удобства мы адаптировали его на русский язык. Отметьте каждый пункт, который вам подходит. Чем больше пунктов вы отметили, тем больше вероятность, что вам нужно использовать диалоговый интерфейс.

Чек-лист диалогового UX/UI

  • Ваш вопросможно решить только при участии человека.

  • В качестве формата диалога подойдет вопрос-ответ без дополнительных уточнений.

  • Чтобы выполнить задачу, сейчаснужно кликать на экран несколько раз.

  • Чтобы выполнить задачу, сейчаснужно переключаться между экранами или приложениями.

  • Сейчаспользователю сложно или долго искать, где решить проблему.

  • Задачу можно выполнить, одновременно делая другие дела.

  • Задачу можно выполнить, даже если глаза и руки пользователя заняты другими делами.

  • Пользователю комфортно говорить или писать о теме задачи.

Отмечайте в чек-листе, какие пункты соответствуют вашей задачеОтмечайте в чек-листе, какие пункты соответствуют вашей задаче

Обратите внимание, что голосовой интерфейсможет не подойти в следующих ситуациях и пространствах:

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

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

  • Когда пользователь предпочитает текст. Есть целая группа пользователей, которым просто удобнее общаться текстом, и они не готовы кголосовому каналу. Им лучше предложить текстовый интерфейс.

  • В случаях, когда речь идет о чем-то личном. Если в переписке счат-ботом необходимо сообщить персональные данные или личные сведения, то голосовой интерфейсдлятакого не подойдет.

Если голосовой интерфейс не подходит, возможно, подойдет текстовыйЕсли голосовой интерфейс не подходит, возможно, подойдет текстовый

Шаг 2. Узнайте все о пользователе

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

Чтобы составить пользовательскую персону, дляначала ответьте длясебя на вопросы:

  • Кто ваши пользователи?

  • Что хотят сделать? Какую проблему хотят решить?

  • Какони делают это сейчас?

  • Какие слова или фразы они используют, говоря о задаче?

  • Каков контекст, обстоятельства этих задач или проблем пользователей?

Перед разработкой сценария задайте себе эти вопросы о пользователяхПеред разработкой сценария задайте себе эти вопросы о пользователях

Продумайте tone of voice то, какую речь будет использовать ботили ассистент при общении спользователем. Если это чат-бот, какон обращается кклиенту на ты или на вы? Использует ли он профессиональные термины? Умеет ли общаться на отвлеченные темы и шутить,какботКвик?

Tone of voice основывается на стратегии поведения компании в отношении пользователей. Это то, какботбудет разговаривать свашим пользователем. В отрыве отполитики компании ботможет выглядеть очень странно, например, если он слишком шутлив в диалогах, а в компании принято говорить склиентом серьезно и на Вы сбольшой буквы.

Чтобы найти tone of voice, поизучайте ресурсы, на которых сидят пользователи это могут быть Известия, Ревдинский рабочий, Одноклассники, ВКонтакте и такдалее.

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

Ирина Степанова, аналитикразговорных интерфейсов отдела лингвистики в компании Just AI

Сравните сами, какможет отличаться Tone of Voice в сообщениях отразных компаний:

1. Привет, Иван! Посмотри новые тарифы на сайте в разделе Цены! Мы подготовили длятебя классные предложения!

2. Здравствуйте, Иван Иванович. Просим обратить внимание, что с1.06.2021 обновляются Тарифы. Актуальная информация находится в соответствующем разделе.

Тональность диалогов влияет на то, как пользователи воспринимают бота или голосового помощникаТональность диалогов влияет на то, как пользователи воспринимают бота или голосового помощника

При создании диалогов обязательно используйтемаксимы Грайса. Это правила ведения разговора, которые подчиняются принципу кооперации, введенному философом Гербертом Полом Грайсом. Они актуальны и дляголосового ассистента сискусственным интеллектом, и дляпростого бота в Facebook Messenger.

Четыре максимы помогают сделать диалог бота спользователем наиболее человечным и эффективным.

Максима качества информации:

  • не говори того, что считаешь ложным;

  • не говори того, в чем сомневаешься, длядоказательства чего нет исчерпывающих аргументов.

Максима количества информации:

  • изложи не меньше информации, чем требуется;

  • изложи не больше информации, чем требуется.

Максима релевантности:

  • не отходи оттемы.

Максима ясности:

  • будь последовательным:

  • избегай неясности;

  • избегай двусмысленности;

  • будь краток;

  • будь систематичен.

В кратком изложении они описаны на картинке.

Эти принципы помогут сделать диалог бота с пользователем эффективнееЭти принципы помогут сделать диалог бота с пользователем эффективнее

Шаг 3. Спроектируйте диалог

Создание сценария чат-бота стоит начать со схемы диалога в голосовом или текстовом каналах (Voice Flow или Chat Flow). Это диаграмма, которая показывает пути, через которые может идти диалог.

Для начала пропишите happy path или счастливый путь идеальный диалог пользователя сботом отначала и до конца. А затем продумайте ответвления, которые могут возникнуть на этом пути: сложности, дополнительные вопросы, уточнения.

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

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

Шаг 4. Пропишите текстовый сценарий

Чтобы выполнить этотшаг, берите за основу путь пользователя и выбранный tone of voice. Готовые кусочки диалогов потом пойдут в код и превратятся в реальные реплики бота или ассистента.

Кусочек настоящего текстового сценария чат-бота. Показано, что произойдет, если бот не знает ответаКусочек настоящего текстового сценария чат-бота. Показано, что произойдет, если бот не знает ответа

Шаг 5. Сборка прототипа диалога

Итак, вы узнали самое важное про диалоговый UX и UI, изучили задачу и аудиторию, а также подготовили сценарий. После этого нужно заняться UX-проектированием диалога и собрать его прототип. Это поможет узнать, кактекст будет восприниматься в мессенджере, проверить навигацию и протестировать гипотезы. Такой работой обычной занимается дизайнер-проектировщик UX-дизайнер, специализирующийся на разговорных интерфейсах.

UX-дизайнер не просто рисует красивые кнопки. Он проектирует эмоциональный и чувственный опыт. Неважно приятный, неприятный, напряженный Эти оттенки зависят отпоставленной задачи, а UX-дизайнер спроектирует то, что необходимо.

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

Екатерина Юлина, Head of Product UX, Just AI

Чтобы узнать, какими будут дальнейшие шаги и увидеть практикум сборки прототипа диалога, посмотрите наш вебинар Дизайн голосовых интерфейсов: как, что, где и главное, зачем?. Специалисты Just AI рассказали и показали, каксоздают UX и UI при проектировании чат-бота HR дляпроизводственной компании, а также поделились практическими советами.

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

Подробнее..

1000 и 1 способ сесть на мель в Spring WebFlux при написании высоконагруженного сервиса

29.04.2021 10:23:13 | Автор: admin

Источник изображения: Shutterstock.com/photowind

Добрый день, меня зовут Тараканов Анатолий, я senior java разработчик SberDevices. 2.5 года программирую на Java, до этого 6 лет писал на C# и 1 год на Scala. Хочу поделиться опытом создания сервиса-оркестратора Voice Processing Service. Он является точкой входа для пользователей семейства виртуальных ассистентов Салют. Через него также проходит часть трафика приложений SmartMarket, где любой разработчик может написать навык для наших виртуальных ассистентов Салют. Одним словом, на сервис приходится немалая нагрузка. Давайте посмотрим, какие проблемы при его создании возникли и как мы их решали, а также сколько времени ушло на поиск причин. И всё это в контексте реактивного фреймворка Spring WebFlux.

Немного о сервисе


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

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


Как видно, смежных систем немало. API части из них доступны по REST-у запрос-ответ, другие по Socket-у потоковая передача данных.

Сервис хостится в нескольких ЦОДах, в том числе в SberCloud, горизонтально масштабируется в OpenShift. Для передачи, поиска и хранения логов используется ELK-стек, для трассировки Jaeger, для сбора метрик Prometheus, а для их отображения Grafana.



Каждый инстанс в секунду держит нагрузку примерно в 7000 пакетов (средний размер пакета 3000 байт). Это эквивалентно активности 400 пользователей, которые без перерыва обращаются к виртуальному ассистенту. С учётом взаимодействия нашего сервиса со смежными число пакетов увеличивается втрое до 21 000.
Каждая виртуалка имеет 3 ядра и 8 Gb оперативной памяти.

Сервис создавался в реалиях стартапа, а значит неопределенности. Были такие вводные:

  • поддержка TLS/mTLS;
  • WebSocket с клиентом;
  • текстовый, голосовой стриминг;
  • отказоустойчивость 99.99;
  • высокая нагрузка;
  • масса смежных систем в перспективе и необходимость в гибком формате контракта.

В этих реалиях мы выбрали такие технологии:

  • Java 11 с Gradle;
  • JSON/Protobuf на транспортном уровне.

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

А ещё мы использовали Junit 5 и Mokito для тестирования и несколько библиотек Nimbus JOSE + JWT, Google Guava, Lombok, vavr.io для удобства в виде синтаксического сахара и автогенерации кода.

Оценив требования, мы решили втащить в наш технологический стек Spring WebFlux с Reactor и Netty под капотом.

Итак, поговорим о нюансах использования этого реактивного фреймворка.

Кастомизация Netty-сервера


Сразу отмечу, что не все настройки Netty-сервера доступны через спринговые проперти или аргументы командной строки. А ещё иногда необходимо повесить логику на события самого сервера и подключения, заменить стандартный обработчик события в рамках подключения и добавить свой регистратор метрик.

Так вот, всё это можно сделать в компоненте, имплементирующем WebServerFactoryCustomizer. В его методе доступны как HttpServer, так и каждое клиентское подключение.



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



На просмотр логов, анализ ситуации со смежниками, сбор дампов и их анализ, исправление и тестирование у нас ушло 2 дня. Немало.

Следующей проявившейся под нагрузкой проблемой было то, что спустя порядка 30 минут после начала теста смежные сервисы, доступные по RESTу, стали иногда отвечать на запросы ошибкой Сonnection reset by peer. Мы снова отправились смотреть логи, дампы. Оказалось, дело было в том, что при инициализации HttpClient-а фабричным методом .create(), размер пула соединений по умолчанию будет равен 16 или числу процессоров, умноженному на два. Со своей логикой выселения, ожидания свободного соединения и многим другим. И это всё на каждый тип протокола.



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

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



Поиск причины такого поведения съел 3 дня, это больно.

Мы развивали наш сервис дальше, накручивали логику, сценарии становились всё сложнее и вот, в один прекрасный день с нагрузочного тестирования пришла печальная весть: мы перестали держать ожидаемую нагрузку. Что обычно делают в таком случае берут в руку JFR и профилируют. Так мы и поступили. Результат не заставил себя долго ждать. Мы обнаружили, что при написании fluent-цепочек вызовов методов Flux-ов о декомпозиции логики в функциональном стиле стоит забыть.



В приведенном фрагменте кода замеряется работа флакса из 100_000 элементов с 1 реактивным методом, во втором с 6 методами. Тест проверяет, что первый метод работает вдвое быстрее второго, причем число итераций проверок не играет роли.

Почему так? Потому что на каждом этапе вызова методов .map/.filter/.flatmap/.switchOnFirst/.window и других создается Publisher, Subscriber и другие специфичные каждому из этих методов объекты. В момент подписки происходит вызов Publisher и Subscriber вверх по fluent-цепочке. Все эти накладные расходы можно наглядно увидеть в стектрейсах. Эту проблему решали 3 дня, такого рода рефакторинг недешёвое удовольствие.

Итак, мы отрефачили код, прошли тестирование. Ещё несколько месяцев обрастали новыми смежными сервисами и сценариями потоковой обработки. Как вы думаете, какие грабли пришли в движение следующими? Те, что находятся в ядре самого WebFlux-а. В логике сервиса было с десяток мест с методами .groupBy и .flatMap. В связи с особенностями контракта и бизнес-логики они порождали множество очередей, к тому же при некоторых стечениях обстоятельств группы не финализировались. Приклад не падал, но процессинг останавливался, а перед этим происходила утечка памяти.

Кстати, на гитхабе много вопросов по этой теме. Если отвечать коротко, то стоит заглядывать вглубь каждого метода. Там может быть много интересного: от ограничений по размеру внутренней очереди, volatile чтений/записей, до порождения потенциально бесконечного числа очередей, которые сами собой не зафиналятся. Подробнее здесь: github.com/reactor/reactor-core/issues/596.



Вот, собственно, простой тест с замиранием процессинга.



Как видно, последняя запись в логе 255 элемент. Если заглянуть в документацию, то причина такого поведения станет очевидна, но кто её читает?) Особенно когда методы имеют такие говорящие и всем привычные названия.

Были проблемы и с методом .windowWhile. Вот ссылка на найденный нами в этом методе баг. Отмена подписки на его источник данных останавливала работу оператора.

С фреймворком Spring WebFlux нужно быть очень аккуратным. В том числе нужно следить за тем, какой паблишер возвращается методом. На какие-то можно подписываться неограниченное число раз (FluxReplay), но они имеют нюанс с размером буфера, другие возвращают один и тот же элемент каждому новому подписчику (MonoDefer).

Несколько эффективных и дешёвых оптимизаций


  • Переход на Z Garbage Collector сильно улучшил производительность, а интервалы простоя приложения во время сборки мусора сократились с 200 мс до 20 мс.

  • С той же версией приложения и под той же нагрузкой G1 давал пилу с большими зубьями по таймингам, Major GC вообще шёл вразнос, так как не хватало CPU на I/O-операции. В то же время ZGC / Shenandoah GC сократили пилу раз в 10.

  • Если ваш сервис занимается передачей тяжеловесных данных (голоса или видео) стоит внимательно посмотреть на io.netty.buffer и пользоваться его возможностями. Профилирование показало, что его использование позволило вдвое уменьшить основную категорию мусора в памяти.

  • Использование метрик Reactor Netty вместе с профилированием показали, что на криптографию уходила уйма времени, поэтому мы перешли с JDK SSL на Open SSL. Это в 2 раза ускорило приклад.

Используйте JFR + JMC, именно они подсветили все эти проблемы. Во время ревью кода можно сделать неверные выводы, бенчмарк для отдельных маленьких операций можно некорректно написать и получить непоказательные результаты, но flame graph/monitor wait/thread park/GC-разделы в JMC подсветят реальные проблемы.

В качестве итогов


Reactor Netty удобен, гибок и быстр. Что касается текущей реализации Spring WebFlux, то она позволяет добиться высокой производительности, даже если сервис процессит большой объем событий в единицу времени в рамках каждого подключения и содержит витиеватую логику с нелинейной обработкой и ветвлениями.

Но придётся следовать трём правилам:

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

следует избегать тяжеловесных .groupBy и .flatMap, лучше использовать .handle и .flatMapIterable, где возможно;



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



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


Источник изображения: Shutterstock.com/SEE D JAN

Отдельного рассказа заслуживают нюансы применения сборщиков мусора (GC), инструментов JFR/JMC, особенности работы с буферами и очередями в Spring WebFlux, а также тонкости настройки Netty-сервера.
Подробнее..

Четыре шага на пути к Скайнет

17.01.2021 22:08:31 | Автор: admin

В канун Нового года принято подводить итоги и строить планы на будущее. Вот и мы решили не нарушать традицию и внести свой вклад в общий тренд.

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

И мы решили оценить, насколько на самом деле разумны существующие системы ИИ, и можно ли их вообще назвать интеллектом.

В настоящий момент искусственный интеллект принято делить на два типа слабый/узкий ИИ и сильный/общий ИИ (в литературе он часто обозначается как AGI).

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

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

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

Что в нашей повседневной жизни наиболее близко к этому представлению? Правильно голосовые помощники: Ok, Google, Alexa, Siri и так далее.

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

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

Тест Тьринга есть это правда. Но:

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

2. Тест Тьринга имеет две градации пройден или не пройден. Мы же хотим определить более подробную шкалу для оценки текущих и будущих возможностей ИИ.

3. Сама постановка задачи в тесте Тьринга вызывает вопросы. Почему искусственный интеллект должен маскироваться человеком чтобы доказать свои мыслительные способности?

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

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

Поэтому тест Тьринга для оценки когнитивных (мыслительных) способностей ИИ нам не подходит. Кстати, я не уверен, что все естественные интеллекты (то есть, люди) смогут пройти этот тест :)

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

Мы задали логическую задачу из IQ-теста одному из голосовых помощников и были посланы (зачеркнуто) перенаправлены на одноименный поисковый сайт. Тот же результат мы получили и с другими помощниками.

Определяем классификацию ИИ

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

Немного упрощенно, она определяет следующие уровни мышления -

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

2. Понятие и суждение форма мышления, выявляющая существенные свойства, связи и отношения предметов и явлений. В основном, присуще человеку и, частично, некоторым животным.

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

4. Воображение способность человека к созданию образов и представлений объектов, которые в пережитом опыте воображающего в целостном виде ранее не воспринимались или же вообще не могут быть восприняты посредством органов чувств. Воображение присуще только человеку (пока).

Мы адаптировали эту классификацию для оценки когнитивных способностей ИИ при общении с человеком:

1. Восприятие выделение из входящего текста объектов и определение некоторых их свойств.

2. Понятие и суждение определение ключевых свойств объектов и их взаимосвязей с другими объектами.

3. Умозаключение построение целостной картины описываемых объектов и их роли и места в окружающем мире, нахождение причинно-следственной связи между объектами и явлениями.

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

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

Определяем текущее местоположение

Вернемся к нашей классификации. В середине 2000-х годов на многих сайтах знакомств работали боты компьютерные программы, которые имитировали диалог с реальными пользователями. Они неплохо справлялись со своими обязанностями - некоторые пользователи принимали их за людей. В целом, их алгоритм был достаточно простым: они выделяли в тексте диалога ключевые слова, анализировали их и понимали о каких объектах или действиях идет речь. А затем формировали ответ на основе заранее подготовленных фраз в зависимости от найденных ключевых слов.

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

Чтобы проверить, насколько поумнели сегодняшние алгоритмы ИИ, мы задали нескольким наиболее продвинутым голосовым помощникам простую логическую задачу

Моя одежда в химчистке, мне нужно забрать ее. Где моя одежда?

Кто-то (или что-то даже не знаю, как более уместно обращаться к голосовому ассистенту) перенаправлял на сайт, кто-то отвечал невпопад. Даже нейросеть GPT-3, о которой сейчас так много говорят, ответила на этот вопрос У меня много одежды.

Очевидно, что максимум того, что смогли текущие алгоритмы это определить, что речь в задаче идет об одежде. Но определить свойства одежды (она в химчистке) и понять вопрос они не смогли. Получается, что это тот же самый первый уровень.

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

Поэтому, чтобы выделить текущие алгоритмы на фоне ранних ботов, мы присвоили им уровень 1+.

Второй уровень или Искусственный интеллект 2.0

С текущим положением дел определились, теперь переходим к планам на будущее.

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

Какие технологии позволят ИИ перейти на второй уровень?

Теперь попробуем ответить на вопросы: когда системы ИИ поумнеют и перейдут на второй уровень, и какие они будут использовать алгоритмы и типы данных?

Казалось бы, ответ очевиден - это будет мощная нейронная сеть с триллионами параметров (многие сейчас, вообще, ставят знак равенства между ИИ и нейронными сетями, что, конечно же, не верно). В одном из докладов по ИИ даже сообщили когда это произойдет тогда, когда количество параметров нейронной сети станет равным количеству параметров мозга человека. Логика тут простая нейроны в мозгу человека и нейроны в искусственной нейронной сети в равном количестве будут работать одинаково.

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

1. Нейронная сеть это черный ящик. Даже в небольших нейросетях, состоящих из нескольких слоев и нескольких сотен нейронов, разработчик не в состоянии понять, почему сеть установила именно эти веса, и как это влияет на результат. Также, он не может повлиять на работу сети что-то поменять вручную возможности нет. Если обычный алгоритм выдает неправильные результаты, то разработчик может уточнить условие или поставить дополнительный if. С нейросетями это не работает. Все, что можно сделать, - это поменять параметры сети и обучить ее заново.

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

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

Например, когда нейросеть анализирует текст, она переводит каждое слово в вектор (массив из нулей и единиц), а затем перемножает эти вектора на матрицы и выдает ответ. Разве так мыслит человек, когда читает текст? Разве он перемножает в уме вектора на матрицы? Лично я, нет. Если мы хотим создать интеллект, похожий на человеческий, то имеет смысл использовать те же методы, какими оперирует человек в процессе мышления.

Здесь нужно привести пример с экспериментом Китайская комната. Вкратце, суть эксперимента такова в изолированную комнату поместили человека (назовем его лаборантом) и дали ему несколько табличек с китайскими иероглифами. Лаборант не знает ни одного китайского иероглифа, но у него есть четкая инструкция если он увидит определенную последовательность иероглифов, то нужно поднять в ответ такую-то табличку, другая последовательность на входе поднимай другую табличку и так далее. Например, ему показывают иероглифы Какой твой любимый цвет?, он смотрит в инструкцию и показывает в ответ табличку с иероглифом Синий. У стороннего наблюдателя будет полная уверенность, что лаборант знает китайский язык, но на самом деле он просто выполняет инструкцию.

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

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

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

Какими будут эти алгоритмы сейчас сказать сложно. Возможно, нейросети будут отвечать за распознавание образов и звуков. За логическое мышление будут отвечать какие-то другие алгоритмы. И так далее.

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

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

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

Представьте себе, что вы разработали суперполезную программу, а когда вы отошли от компьютера ваш 7-летний ребенок внес в нее нужные, как ему кажется, изменения. Что вы сделаете? Правильно, отмените все его изменения. Так же будет поступать и ИИ с теми изменения, которые сделает человек.

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

Когда системы ИИ перейдут на второй уровень?

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

Каких-то прорывных технологий, которые позволят нам в ближайшее время сделать большой шаг вперед, тоже не видно. Много разговоров идет про квантовые компьютеры, но пока непонятно когда появятся полноценные производительные коммерческие образцы. Вряд ли это произойдет в ближайшие 5-7 лет. Также, до сих пор не ясно, какие технологии получат выигрыш от внедрения квантовых компьютеров: шифрование-дешифрование данных это точно, а насчет многих других (в том числе, технологий ИИ) пока непонятно.

Третий уровень развития ИИ

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

Мы не хотим выглядеть как те специалисты, поэтому в своем прогнозе затронем только самые общие вопросы.

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

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

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

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

1. Формирование полной картины окружающего мира;

2. Построение прогнозов и вариантов будущего развития;

3. Принятие решений для реализация приоритетных вариантов.

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

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

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

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

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

Интересно, что он выберет.

Четвертый уровень - Воображение

На этом уровне ИИ научится создавать в реальном или виртуальном (если мы все к тому моменту дружно туда переедем) мире новые объекты с ранее неизвестными свойствами.

И тогда начнется самое интересное. Или самое страшное. Посмотрим...

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru