Алиса, скажи что-нибудь: как устроена голосовая помощница Яндекса и чему ей еще предстоит научиться

В октябре прошлого года Яндекс представил своего голосового помощника (а точнее, помощницу) — Алису. Она работает в поисковом приложении и в мобильном браузере компании, умеет выполнять все привычные для голосового помощника задачи (подсказывать погоду и маршрут, выдавать поисковые запросы, играть в игры), а также кое-что еще: поддерживать разговор с пользователем практически на любые темы. О том, как устроена Алиса, что она умеет и в каких направлениях компания планирует ее развивать, мы побеседовали с руководителем группы диалоговых систем Борисом Янгелем и руководителем отдела разработки голосовых и диалоговых технологий и продуктов Денисом Филипповым.

1 марта состоялось специальное событие под названием «Яндекс изнутри: от алгоритмов до измерений — в Переводчике, Алисе и Поиске», на которое приглашались специалисты в области машинного обучения и опытные разработчики. На этой встрече можно было узнать о последних наиболее интересных разработках Яндекса, которые, в частности, касаются и алгоритмов работы голосового помощника (точнее, помощницы). Редакция журнала "N + 1" решила задать свои вопросы, чтобы получить ответы, понятные не только программистам.

N + 1: Расскажите, с чего начинается путешествие пользовательского запроса «под капотом» Алисы?

Борис Янгель: У нас в Яндексе есть специальная общая точка входа для всех голосовых запросов, и она же является точкой выхода. Туда стри́мится звук от пользователя, и она же стри́мит звук обратно. Первым делом запрос отправляется в сервера распознавания речи, откуда уже он передается в «мозги Алисы».

Денис Филиппов: Да, этот блок называется SpeechKit. Это клиентская библиотека, через которую, как через единую точку входа, звук идет на сервер, обрабатывается и возвращается в интерфейс Алисы в виде текста и звука.

Для распознавания речи необходимо делить слова на звуковые сегменты — фонемы. Академическая наука понимает под фонемами минимальную смыслоразличительную единицу языка, по которым одно слово может отличаться от другого. Носители языка слышат и узнают именно фонемы, например, первый гласный в слове «молоко» и «молочный» для нас звучит одинаково, хотя звуки разные. Разные фонологические школы используют немного разные определения фонемы, поэтому и число их различается. Специалисты Яндекса в качестве основы использовали подход Ленинградской фонологической школы, но в отличие от ученых, считали за разные фонемы звуковые варианты гласных. Всего у них получилось 48 фонем. Система автоматического распознавания речи делит звук на пересекающиеся отрезки по 20 миллисекунд шагами по 10. Такие отрезки называются сенонами: всего их выделяют около 4000, и они составляют начало, середину и конец определенной фонемы. Выделение фонем — контекстно зависимое: это означает, что на каждом этапе анализа последующей фонемы модель распознавания речи определяет вероятность ее появления, исходя из фонотактических правил языка.

Описания SpeechKit, которые мы видели, выглядят очень похоже на то, что происходит в Alexa (голосовой помощник, разработанный Amazon), с точностью до длительности фонем. Есть ли у вас какие-то свои ноу-хау в этой области?

Денис Филиппов: С точки зрения ASR (Automatic Speech Recognition, автоматическое распознавание речи — прим. N + 1), Alexa, Siri, Google Assistant используют примерно один и тот же пайплайн (pipeline, буквально «трубопровод» — последовательность этапов обработки — прим. N + 1). Основное отличие с точки зрения акустики, наверное, заключается в том, что в России очень много акцентов и очень много людей, которые говорят на «разных» русских языках. И здесь у нас вариативность звучания той или иной фонемы выше, чем, например, в английском языке. Поэтому в русском мы затачиваем определенным образом акустическую модель на знание разных акцентов, говоров и так далее.

А как же разновидности английского? Шотландский, ямайский…

Денис Филиппов: Да, там это есть, но, как правило, пользователю дают возможность выбрать явным образом, например, «английский» или «американский». У нас такой возможности нет: не предложишь же выбрать «русский рязанский», «русский вологодский» или какой-то еще. Поэтому у нас задача немного сложнее, так как мы пытаемся это все в одном русском языке уместить.

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

Денис Филиппов: Просто очень много данных. Благо у нас хватает сервисов, тот же Яндекс.Навигатор, и с этим проблем нет. В случае Алисы есть, конечно, и нюансы. Например, в том, что раньше распознавание речи мы использовали в Поиске, в Картах и более-менее понимали контекст этих областей, на какую тему люди нас будут сейчас что-то спрашивать: в Картах это организации и адреса, в Поиске было чуть сложней, но все равно мы обладаем огромным количеством логов и достаточно хорошо справляемся с этими задачами.

Денис Филиппов

Яндекс

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

Борис Янгель: Запрос дробится на токены, как правило на отдельные слова или, может быть, какие-то пунктуационные знаки, например арифметические операции или дефисы. Но ниже этого уровня в этом модуле мы не спускаемся. А дальше для всех этих токенов мы применяем эмбеддинги (embedding, букв. «вложение» — тот или иной метод представления данных в определенном стандартном виде — прим. N + 1), обученные на наших больших данных. 

Один из самых простых методов эмбеддинга слов — это контекстные вектора. Строятся они так: для данного текстового корпуса составляется словарь, из которого каким-то способом выбираются n слов. Например, самых часто встречающихся. Далее подсчитывается, сколько раз каждое слово из словаря встречается в контексте выбранных n слов, таким образом получается вектор. Например, слово «котик» 3 раза встречалось рядом со словом «подушка», 1 раз — со словом «нейросеть» и ни разу — со словом «совесть». Вектор слова «котик» будет выглядеть так: [3;1;0]. В зависимости от выбранного словаря, текстового корпуса, ширины контекстного «окна» можно получать самые разные векторные представления слов. Часто такой подход называют word2vec по названию популярной библиотеки с реализацией этого метода.

Что это за эмбеддинги? Контекстные вектора?

Борис Янгель: Ну, смотря что вы называете «контекстными векторами», есть же очень много разных способов их построения. Если речь про word2vec, то да, в том числе мы пользуемся и ими. Вообще на этом этапе запрос очень активно обогащается самыми разнообразными признаками. Это и эмбеддинги, и результаты синтаксического разбора предложения, и поисковая информация. Например, мы знаем, что по какой-нибудь части нашего поискового запроса, например «Адель», часто находится музыка в Поиске. Мы это учтем. И это будет очень сильным сигналом того, что это музыкальный интент.

Откуда берется список возможных интентов? Вы просто кластеризовали «без учителя» все возможные запросы или составили список, опираясь на те сервисы, в которые дальше придется отправлять запрос?

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

Сколько обычно хватает слов, чтобы один конкретный интент подобрать? Ну, то есть, допустим, мы спросим Алису: «Как будет «погода» по-вьетнамски?» Она посмотрит на слово «погода» и сразу решит, что это погодный сценарий, или все-таки вспомнит и про другие слова и решит, что от нее хотят перевод?

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

Метод ближайших соседей по праву считается одним из самых простых, но в то же время мощных методов машинного обучения. Задача классификатора на ближайших соседях формулируется просто: в выборку из большого числа объектов нескольких классов помещают еще один объект. Как отнести его к какому-то из классов? Для этого надо посчитать, соседей какого класса больше среди k ближайших. Пусть мы выбрали k = 5, и среди ближайших пяти соседей три принадлежат к классу «котики», и два — к классу «собачки». Тогда классификатор отнесет новый объект к классу «котики». Несмотря на кажущуюся простоту, этот метод не только показывает хорошие результаты, но и обладает удобными преимуществами. Например, при увеличении вашей выборки метод не нужно целиком переучивать, как это происходит, например, при использовании нейросетевого классификатора.

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

Борис Янгель: Да, у нас есть функция, которая получает на вход два предложения и говорит, насколько они близки или далеки. На самом деле эта функция переводит предложение в вектор: это просто рекуррентная сеть. В каждом запросе есть глобальные признаки, которые описывают все предложение целиком, например «Как часто вообще про это спрашивали?», есть фичи от отдельных токенов, например часть речи каждого слова. Нейросеть все это агрегирует и получает в конце один вектор в евклидовом пространстве. А поскольку это рекуррентная сеть, ей все равно, какой длины был исходный запрос.

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

А что происходит, если запрос не подошел ни под один из сценариев?

Борис Янгель: Тогда мы отдаем его в бинарный классификатор (такой, у которого есть всего два возможных исхода — прим. N + 1), и он уже решает, отправить запрос в поиск или в «болталку».

А как реализуется составление ответа в режиме «болталки»?

Борис Янгель: Какая задача ставится перед «болталкой»? У вас есть nпредыдущих реплик в диалоге, и нужно выбрать n + 1 реплику, которая и послужит ответом. Соответственно, к решению этой задачи есть два подхода: генеративный, когда ответ создается посимвольно или собирается из небольших кусочков слов или фраз, и ранжирующий, когда у нас есть какой-то набор ответов-кандидатов и надо просто выбрать из него подходящий. Мы давно пришли к выводу, что методы генерации реплик пока далеко не так развиты, как методы ранжирования. Во-первых, они не позволяют достичь такого же качества, во-вторых, их сложнее контролировать, чтобы они не выдавали откровенную чушь или, например, грубые ответы. А при наличии списка реплик его можно заранее отфильтровать. Вот почему мы используем ранжирующие методы, и «болталка» — это большая нейросеть, которая видит контекст диалога, ответ-кандидат и некоторое число, которое характеризует, насколько этот ответ подходит в данной ситуации.

А как формируется база ответов-кандидатов?

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

Зная Яндекс, хочется сказать, что где-то здесь под капотом прячется МатриксНет или CatBoost?

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

Если все ответы подобраны заранее, как вам удается разнообразить речь Алисы?

Борис Янгель: Например, в «болталке» мы стараемся сэмплировать ответы: то есть если мы знаем, что, скажем, первые 20 ответов в списке кандидатов примерно одинаково хороши, то мы выберем из них случайный или такой, чтобы диалог выглядел разнообразнее.

Вы когда-то рассказывали, что некоторые ответы Алисы — редакторские, то есть целиком написанные человеком для определенных ситуаций. Где хватает редакторских ответов, а где нужно идти дальше? А если одно интегрировано в другое, то как?

Борис Янгель: Главная проблема с редакторскими ответами состоит в том, что формулировки, которые для них написаны, подразумевают определенную форму задаваемого вопроса. Допустим, мы хотим, чтобы Алиса любила собак, и добавляем соответствующий редакторский ответ. Если у нее спросят: «Ты любишь кошек?» или «Тебе нравятся кошки?» — она должна ответить: «Нет, я люблю собак». Соответственно, есть какая-то модель, которая смотрит на реплику пользователя, и если реплика близка по смыслу к реплике «Ты любишь кошек?», она говорит: «Нет, я люблю собак». Какая проблема может возникнуть? Пользователь может спросить: «Что ты думаешь о кошках?» Семантически это очень близко к «Ты любишь кошек?», но на это нельзя ответить: «Нет, я люблю собак», — форма вопроса другая. 

Как эту проблему решать? Можно составлять такие редакторские ответы на предполагаемые вопросы, которые будут уместны в максимальном количестве контекстов. Но тогда ответы перестанут быть интересными, не будут похожи на живое общение. И вот тут мы приближаемся к первому шагу, который собираемся сделать. У нас есть замечательная «болталочная» модель: использовать редакторские ответы, но выбирать еще и те, которые, с точки зрения «болталочной» модели, подходят под форму заданного вопроса.

Кстати, а как в «болталке» работает запоминание контекста?

Борис Янгель: С точки зрения «болталки», контекст — это те предыдущие n предложений диалога, в рамках которых нужно выдать ответ. И из этого сразу следует, что «болталка» никаким long-term (долгосрочным) контекстом не располагает, а оперирует только short-term (краткосрочным) контекстом диалога, то есть не знает, что пользователь сказал вчера или что ему в принципе нравится и интересно. Это большая, открытая исследовательская задача, над которой, в том числе, работают исследователи в Яндексе: как учесть такую информацию в нейросетевых моделях? И сложность ее решения, в первую очередь, связана с тем, что нет больших датасетов для обучения, в которых содержались бы диалоги, оперирующие именно long-term контекстом.

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

И еще про контекст: есть ли какой-то гиперпараметр того, сколько реплик запоминает Алиса? Допустим, можно ли у нее сначала спросить, какая погода в Москве, и потом еще 10 раз спросить: а в Лондоне, а в Париже? Поймет ли она, что ее спрашивают про погоду?

Борис Янгель: Такого числа нет, потому что этот модуль по-другому устроен. Грубо говоря, сейчас состояние диалога Алисы — это текущий диалоговый сценарий (в терминах form filling, то есть «сценарий», состоящий из слотов, которые должны быть заполнены для выполнения запроса). Пока мы можем связать то, что говорит пользователь, с текущим состоянием, мы всегда будем поддерживать контекст. Если вы спросили про погоду, то дальше, сколько бы вы ни говорили «а в Москве…», «а в Питере…», «а на завтра…», «а на выходные…», пока классификатор уверен, что это уточнение погоды, можно будет спрашивать вечно.

А кто классифицирует такие разновидности контекста как анафоры и эллипсисы? Это все тот же классификатор намерений или отдельный модуль?

Анафора — это использование языковых средств (например, местоимений), относящихся к уже упомянутой сущности:

Я позвонил маме. Она не взяла трубку.

Эллипсис — это пропуск слов, упоминание которых несущественно для смысла выражения:

Что купить в булочной? А в книжном [что купить]?

Борис Янгель: В нашем подходе это реализуется там же, где классифицируются намерения. Например, вы говорите «на завтра», и тот же классификатор намерений скажет, что это похоже на уточнение в сценарий «погода», но также это очень похоже на уточнение в сценарий заказа авиабилетов, если бы он у нас был. И говорит: «Веса 0,5/0,5». Так мы знаем состояние, в котором находится диалоговый движок. С учетом этого мы перевзвешиваем то, что сказал классификатор интентов: поскольку мы в состоянии заказа авиабилетов не находились, это не могло быть уточнением. Значит, это точно погода.

Хочется провести параллель с той же Alexa. Если у нее спросить: «В каком году Адель написала такой-то альбом?» — Alexa ответит целиком: «Она написала альбом такой-то в таком-то году». Алиса когда-нибудь будет уметь так же — не отправлять пользователя в поисковую выдачу, а составлять ответ в виде сложной конструкции?

Борис Янгель: Алиса и сейчас так умеет, правда, с ограничениями. На вопросы вроде «когда родился такой-то?» или «сколько ему лет?» она отвечает: «Ему вот столько-то». Это происходит, когда форма ответа зависит от того, как задан вопрос. Мы будем расширять этот формат, так как он больше похож на общение, и ищем для этого разработчиков.

Допустим, я спрашиваю Алису: «Кто написал “Войну и мир”?». Она мне отвечает: «Лев Николаевич Толстой». А потом, если ее спросить: «Сколько в нем томов?», — то она «растеряется» и решит, что ей надо определить, сколько томов в «мире», потому что анафорическое местоимение «в нем» — с точки зрения формальной логики — отсылает именно к «миру». Почему она не распознает «Войну и мир» как единую сущность, даже если отметить всю именную группу кавычками?

Борис Янгель: Поскольку мы должны работать и с голосовыми запросами, и с текстовыми, а голосовых сильно больше, то мы знаки препинания вроде кавычек вообще не используем и удаляем первым делом. Поэтому кавычки никак не влияют на ответ. В вашем примере система разрешения анафор немного ошиблась и решила, что раз местоимение в мужском роде, то, наверно, оно ссылается на слово «мир».

Почему Алиса ошиблась и привязывает ли она местоимения к отдельным токенам? Нет, не привязывает. Она находит всевозможные именные группы в тех предложениях, с которыми нужно связывать местоимение, и пытается для каждой пары «именная группа — местоимение» оценить, что будет, если ее туда подставить. Но в данном случае она ошиблась и предпочла слово «мир» всей группе «Война и мир». Хотя так делать не должна.

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

А как Алиса вообще понимает, какую содержательную информацию из запроса пользователя необходимо извлечь? Адреса, например, или конкретные названия?

Борис Янгель: Для этого есть специальный блок — семантический теггер. А у него есть список полей, которые имеют смысл в контексте каждого отдельного сценария. Например, сейчас Алиса учится заказывать такси, а мы знаем, что такси всегда заказывают откуда-то и куда-то. И настраиваем сценарий так, чтобы теггер больше ничего другого не выделял, потому что нас только эти вещи и интересуют.

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

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

А как быть, если теггер не нашел в запросе пользователя всей необходимой информации?

Борис Янгель: Тогда мы применяем ноу-хау, которое условно называется n-best hypotheses (подбор n лучших гипотез — прим. N + 1). Допустим, теггер не смог ничего выделить, это абсолютно реальная ситуация. Но иногда, по каким-то причинам мы знаем, что информация там скорее всего есть, просто надо «глубже копать».

Борис Янгель

Яндекс

Например, вы говорите: «Вызови такси» и… и все. В такой ситуации очень хочется спросить: «Куда?». Мы спрашиваем, вы что-то говорите, но теггер, допустим, считает, что в первой гипотезе адреса нет. Но мы-то знаем, что скорее всего есть, мы ведь только что вопрос задали! И вот, если там есть какая-нибудь гипотеза, в которой все же есть адрес, и у нее тоже немаленький вес, то, с учетом знания контекста диалога, мы должны этот вес должны увеличить. И в этом случае адрес мы все-таки вычленим.

Что происходит после того, как отработал теггер?

Борис Янгель: После теггера начинается form-filling, то есть, все, что произвел теггер, мы помещаем в соответствующие формы и дальше диалоговый движок смотрит, есть ли у него вся необходимая информация для данного сценария. В терминах  form-filling это значит спросить: «Заполнены ли все обязательные поля формы?» Если «да», то вызывается обработчик, связанный с этой формой, если «нет», то вызывается другой обработчик, который может задать вопрос пользователю про какое-нибудь из полей формы. То есть, как раз спросить: «Куда едем-то?»

И куда отправляется форма, которую заполнила Алиса?

Борис Янгель: Роль бэк-энда, который мы разрабатываем, в том, чтобы проинтерпретировать сказанное пользователем в контексте диалога, представить это в структурированном виде и отдать дальше. В этом «дальше» выполняется задача пользователя, и нам говорят что, собственно, надо сообщить пользователю в ответ. Мы превращаем это, скажем, в текст на естественном языке и отправляем в SpeechKit для выдачи.

Кстати, о SpeechKit: как вы добились такого естественного звучания Алисы?

Денис Филиппов: С помощью свежего взгляда на достаточно старый подход к синтезу речи, который называется Unit Selection, здесь никакого секрета нет. Нужно очень аккуратно записать десятки часов речи диктора, выдержав при этом интонацию и звучание голоса. На это ушло огромное количество времени, именно на работу в студии. Дальше мы режем весь этот массив на куски, из которых самый мелкий — это фонема или даже части фонемы, а самый крупный — это, допустим, готовая фраза. Например, «Сегодня в Москве погода такая-то». А дальше у нас есть нейросеть, которая на вход получает текст и для этого текста ищет в аудиобазе подходящие куски. Именно наличие нейронной сети, которая реализует выбор юнитов из аудиобазы, является главным отличием от канонического подхода Unit Selection, где юниты выбираются с помощью фиксированных формул и различных эвристик. В идеальном случае, если наш текст полностью совпадает с куском из базы, то мы получаем по сути готовую запись, именно такую, какой она была на студии.

Но бывает и обратная ситуация, когда больших кусков нет и нам приходится много склеивать. И иногда возникают проблемы на стыках, когда не удается подобрать правильные склейки. Или бывает совсем плохая ситуация, например, в случае с новостями, в которых могут возникнуть какие-то редкие сложные слова. И в этом месте мы хитрим: в Алисе новости озвучивает мужской голос. Почему? Потому что текст новостей заранее спрогнозировать нельзя и там Unit Selection вообще нормально не работает. Много склеек, текст начинает булькать, плавать и так далее. Там мы как раз применяем параметрический синтез, к которому собираемся прикрутить WaveNet — это одна из интересных и сложных задач нашей команды, на которую нужно больше  рук.

Можете на пальцах пояснить, в чем преимущество WaveNet по сравнению с Unit Selection?

Денис Филиппов: Ну, про основные минусы Unit Selection я уже рассказал: произвольный текст — любая книжка, любая новость, — на Unit Selection уже не работает. Возникает очень много склеек, и модель так или иначе ошибется. А в параметрическом синтезе никаких склеек нет вообще. Там есть акустическая модель, которая на выходе генерирует вполне определенное признаковое описание для звуковой волны. И дальше есть модуль (его обычно называют Vocoder), который принимает на вход вектор чисел и реализует саму волну.

Сейчас наш параметрический синтез имеет ряд недостатков: у нейронной сети недостаточно информации на входе для предсказания натуральных интонаций, поэтому интонация ровная, склеек нет, но голос немного дребезжит, у него такой железный призвук, и интонация достаточно роботизированная, нет яркости в голосе. Это, как правило, получается из-за слишком сильного сглаживания, когда теряются важные детали, передающие окраску речи. Так вот, WaveNet — это новая реализация этого модуля, которая, по нашим ощущениям — и не только нашим, решает эту проблему. То есть, голос начинает звучать естественно, без раздражающего дребезжания. Помимо реализации Vocoder на базе WaveNet мы активно реализуем новые акустические модели для синтеза речи, с целью генерации более ярких и естественных интонаций голоса, вдохновляясь end-to-end моделями типа Tacotron 2 и DeepVoice 3.

У Алисы есть некий эталон поведения, своя личность. Какой эталон поведения вы выбрали и почему именно его?

Денис Филиппов: В самом начале, когда еще не было никакой Алисы, стояла задача: надо сделать голосовой помощник. Первый вопрос: «Как назвать?» Так как команда большая, вариантов было предложено много, мы решили подойти к решению этой задачки системно и составили перечень характеристик, положительных и отрицательных, которыми должен обладать или не обладать наш виртуальный помощник. Например, отрицательные характеристики: грубить, оскорблять пользователей. А среди положительных: всегда готов помочь, вежлив и так далее. Полученные характеристики мы загнали в Толоку (краудсорсинг-платформа Яндекса — прим. N + 1): толокеры решили, что положительным характеристикам больше всего отвечает имя Алиса. Так она и появилась. А дальше эти положительные характеристики мы взяли за основу проработки характера: кто такая Алиса, как она себя ведет.

Затем последовала большая работа по проектированию, созданию персонажа. Например, Алиса не может позволить себе общаться с пользователем на «ты», она должна соблюдать некую дистанцию: здесь у нас был прототип — Мэри Поппинс. Такая воспитательница, которая держит дистанцию, не допускает панибратских отношений с пользователями. Поэтому Алиса и не любит, когда с ней начинают заигрывать или что-то еще, — она сразу пытается восстановить дистанцию. Или, например, готовность помочь в любой ситуации. Основная концепция Алисы — это как можно быстрее дать ответ пользователю, не тратить его время.

У Алисы как у персонажа есть и то, чего она любит. В концепции персонажа у нас было, что Алиса влюблена в Константина Хабенского. Но это мы просто так придумали, для себя. Там же появился и программист Алексей (Алиса в ответ на просьбу пользователя сделать что-то, чего она пока не умеет, иногда отвечает, что программист Алексей обещал «сделать это в скором времени» — прим. N + 1).

Если посмотреть на рынок голосовых помощников по всему миру, то в зависимости от конкретной компании предназначение каждого помощника понятно. Apple — компания, которая производит гаджеты, ей нужен помощник, который привязан к гаджетам. Amazon — компания, которая собирается продавать все на свете, поэтому ее помощник интегрируется со всем, что они хотят продать. А зачем Алиса Яндексу?

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

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

С помощью Яндекса пользователи также решают не только поисковые задачи, но еще и маршрутизацию. Скоро можно будет и такси вызвать, и маршрут уже можно построить, и карту посмотреть, и вообще спланировать, как добраться до какого-то места. Наконец, важная задача ассистента —  вовремя напоминать о разных мелочах. «Тебе, если ты собираешься на работу, надо выйти сейчас, чтобы успеть на остановку, чтобы автобус не ушел. А у тебя будет встреча, поэтому тебе надо быть на остановке в такое-то время. На метро это займет столько-то». Ну, то есть, помогать в тех вещах, которые трудно держать в голове или держать вообще не хочется: во сколько выходить, брать зонтик или нет — вот такие вещи. Всему этому Алиса активно учится, она становится полезнее с каждым месяцем, и это результат очень большой работы. Дальше будет еще больше точек применения, еще больше сервисов с Алисой, причем не только яндексовских.

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

Беседовали Тарас Молотилин и Елизавета Ивтушок

Кому интересно, полную запись семинара «Яндекс изнутри: от алгоритмов до измерений — в Переводчике, Алисе и Поиске» можно посмотреть ЗДЕСЬ