Asr

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

Прошло некоторое время и пора обновить наше исследование, сделав его по-настоящему ультимативным. По сравнению с прошлыми исследованиями изменилось или добавилось следующее:

• Добавилось много валидационных сетов из разных реальных доменов;
• На рынок вышел Сбер, в первую очередь интересно протестировать именно его;
• Для чистоты эксперимента, мы не предупреждали разработчиков систем о доменах и факте проведения тестов;
• Мы также попробовали немного протестировать пропускную способность сервисов (понятно, что мы не знаем какое железо и ограничения стоят в облаке);
• Мы рассматриваем только коммерческие системы, к которым у нас получилось получить доступ и которые показали хоть какой-то намек на "всеядность", работу с холодного старта и "энтерпрайзность";

Методология

Мы старались следовать нашей стандартной методологии (см. ссылки выше) с небольшими изменениями:

• Тестируем одни и те же данные в формате wav (или просто PCM);
• Мы слали запросы во все системы в 8 параллельных потоков (если было очень много таймаутов или все было медленно, то снижали);
• Расчет скорости делался отдельным небольшим прогоном без всяческой пред- или пост-обработки, чтобы не "загрязнять" метрики, допустим, нормализацией или ресемплингом;
• Считаем основную метрику WER. Не пугайтесь высоких показателей в районе 20% WER, нужно понимать что в самой разметке заложено порядка 5% WER и что иногда система получает штраф за неверную форму слова (но корень сохраняется, подробнее писал по ссылке в начале статьи);
• По причине большого количества доменов в этот раз на каждый домен случайно выбрали по 1 часу аудио. Стабильные результаты как правило получаются с 2-3 часов аудио (поэтому некоторые метрики могут визуально быть "хуже" прошлых тестов). За тесты в Гугле нам пришлось заплатить почти 500 долларов!;
• Метрики считаются на нормализованных текстах (то есть без цифр, "как слышится так и пишется"), так как системы нормализации могут быть разными и строго говоря к качеству распознавания имеют непрямое отношение и зачастую делаются под домен;
• Если у системы нет такого функционала, то мы нормализуем тексты самостоятельно. В любом случае это влияет в рамках 1 п.п. WER, мы проверяли;
• Сначала мы пробовали слать ogg/opus в системы, которые его поддерживают, но потом отказались от такой идеи, потом что резко вырос процент "пустых" ответов;
• Все данные по умолчанию отправляются с родной частотой дискретизации (8 или 16 kHz), но мы не записывали исходную частоту дискретизации всех оригинальных аудио до обработки;

Сухие метрики

Все модели, кроме Silero bleeding egde, это модели упакованные в production сервисы.

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

Качественный анализ и интерпретация метрик

Неудивительно, что каждый силен в том домене, на котором фокусируется. Tinkoff на звонках в банк, справочную, финансовые сервисы. Сбер имеет ультимативно лучшие результаты на своей "умной колонке" (спекулирую, что они поделились в лучшем случае 1/10 своих данных) и в среднем неплохие показатели. IVR модель Сбера на доменах, где оригинальные данные лежат у нас в 8 kHz, показывает себя достойно, но она не ультимативно лучшая. Приятно удивил Яндекс в прошлых рейтингах их модели были не в списке лидеров, а сейчас точно лучше, чем в среднем по больнице. Другой сюрприз Google, который является аутсайдером данного исследования вместе с Ашмановым.

Также интересно посчитать количество доменов, где production модели поставщика лучшие / худшие (допустим с неким "послаблением" в 10% от лучшего или худшего результата):

Как и ожидалось наша модель показывает в среднем неплохие показатели на всех доменах, заметно отставая на банках и финансах. Также если смотреть по формальной метрике "на каком числе доменов модель лучшая или почти лучшая" то наша модель как минимум лучше всех генерализуется. Если включить в забег нашу bleeding edge модель (мы пока не выкатили ее еще), то она отстает только на "умной колонке" и банковских датасетах, лидируя уже на 17 доменах из 21. Это логично, так как у нас нет своей колонки и банки очень неохотно делятся своими данными даже приватно.

Удобство использования

У Сбера на момент тестирования было только gRPC API. Это не самое удачное решение для SMB клиентов с точки зрения удобства, имеющее более высокий порог на вход. Также в их реализации вообще не прокидываются важные ошибки (или отсутствуют в принципе, чем часто грешат корпоративные сервисы). Документация запрятана внутри портала их экосистемы, но в целом кроме лишней "сложности" проблем особо там нет, читать приятно. 40 страниц на два метода это конечно сильно (мы читали сначала в PDF), но документация хотя бы подробная и с примерами и пояснениями.

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

У Tinkoff само распознавание работает по умолчанию также через gRPC, а поверх написаны клиенты (в тех, которые мы разбирали было много лишнего). С учетом фокуса на enterprise (оставим за скобками этические, правовые и финансовые последствия монетизации банком ваших данных без явного согласия и возможности отказаться) это имеет больше смысла, чем то, что сделал Сбер. Это уже мои спекуляции, но скорее всего это в первую очередь артефакт разработки решения под свои нужды.

У сервиса Ашманова вообще нет документации, примеры не работают из коробки, пришлось немного позаниматься перебором для запуска. Отдельно отмечу, что обычно b2b сервисы не славятся читаемыми ошибками и читаемой документацией, но тут вообще не было ни ошибок, ни документации. Или 500-я ошибка или 200 с пустым ответом. Это создает легкий когнитивный диссонанс с учетом проработки анимации девушки-маскота, количества маркетинговых материалов и "успешных" кейсов.

У нашего сервиса само публичное АПИ весьма минималистичное и состоит из 2 методов (синтеза и gRPC нет еще в публичной документации) с примерами. Есть также gRPC АПИ, которое сейчас проходит обкатку. Наверное я тут не лучший судья, но основная ценность как мне кажется состоит в радикальной простоте для публичного АПИ и детальных инструкциях / сайзингах / опциях конфигурирования для более крупных клиентов.

Пропускная способность

Все АПИ, которые мы протестировали (кроме Ашманова) показали себя довольно бодро по скорости (это баг или фича решать вам). Для измерения пропускной способности мы считаем показатель секунд аудио в секунду на 1 поток распознавания (RTS = 1 / RTF):

Поскольку никто не публикует сайзинги облачных и даже иногда коробочных (тут поправьте меня, если пропустил) версий своих систем публично (кстати прошлая версия нашего сайзинга например доступна по ссылке), то довольно сложно оценить адекватность работы систем по ресурсам. Ведь за АПИ может скрываться как одна VDS, так и сотни карт Nvidia Tesla, которыми любят хвастаться корпорации в своих пресс-релизах (что кстати частично подтверждается результатами Сбера пропускная способность там не падает от роста нагрузки совсем). Расчеты выше не являются заменой полноценным сайзингам.

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

Вообще меня очень приятно удивили результаты Сбера. На текущих версиях моделей у нас например сайзинг на 12 ядерном процессоре + GPU рассчитан на ~150 RTS. По идее это означает, что если мы поднимем тестовый и сервис на 12+ ядрах процессора на чуть более новой карточке, мы должны получить результаты более близкие к Сберу. У нас все равно не получается получить такие же высокие показатели без просадки от нагрузки, но какие-то выводы уже можно строить и получается все равно весьма достойно. Снимаем шляпу перед инженерами Сбера и ставим aspirational цель сделать наш сервис еще в 2-3 раза быстрее.

На цене мы останавливаться особо не будем (большая часть серьезных клиентов все равно не использует облако), но в очередной раз неприятный сюрприз преподнес Гугл выставив круглый счет за смешной (как нам кажется) объем. А ответ прост зачастую облачные корпоративные сервисы распознавания имеют не только крутой ценник (и в случае Гугла еще и в долларах), но и неочевидные системы округления вверх. В начале своего пути мы тестировали какой-то сервис из Великобритании который округлял до 60 секунд!

Небольшая ложка дегтя

Довольно приятно, что наш публичный некоммерческий датасет Open STT, неоднократно обсуждавшийся на Хабре, был предвестником релизов публичных данных, например от Сбера. Но долгосрочно все равно хотелось бы видеть хотя бы какую-то соразмерность вклада госкорпораций количеству вложенных в них публичных денег. В сравнении с похожими релизами на западе, мы пока сильно отстаем. Да и Яндекс традиционно не публикует ничего полезного в сфере распознавания речи, интересно почему.

Нам приходилось слышать абсолютно разные оценки скорости (ну или наоборот оценки потребности в железе) систем распознавания речи, отличающиеся даже на порядок. Особенно радует, когда указаны системные требования из которых следует, что метрики сильно лучше, чем лучшие state-of-the-art системы из bleeding edge статей, а на практике иногда оказывается, что метрики рассчитаны в надежде, что "покупают для галочки и никто пользоваться не будет и так сойдет". Также не помогает то, что некоторые системы работают на GPU, а некоторые нет, равно как и то, что ядра процессоров могут отличаться в разы по производительности (например старые серверные процессора с тактовой частотой 2 2.5 GHz против современных решений от AMD с 4+ GHz на ядро имеющие до 64 ядер). Давайте в этом вместе разберемся, на самом деле, все не так уж и сложно!

Как правило люди начинают задумываться о скорости в 3 случаях:

• Когда ее не хватает или когда она является узким горлышком;
• Когда со скоростью нет проблем, но есть проблемы с ценой железа;
• Когда есть жесткое SLA по качеству сервиса от конечного заказчика;
• Когда есть жесткие требования по скорости "первого ответа" от конечного заказчика;

В этой статье мы постараемся ответить на несколько вопросов:

• Что вообще значит скорость?
• Какой скорости можно добиться в теории?
• Какой скорости можно добиться на практике и желательно без потери качества?

Определения

Но давайте для начала определимся с понятиями. Такой пример скорее является исключением в западном STT комьюнити, но лаборатория Facebook AI Research в последнее время активно наращивает свои позиции в распознавании речи и зачастую публикует интересные исследования, а в частности в качестве отправной точки по скорости интересна относительно недавняя статья, где они публикуют кроме всего прочего оценки скорости работы своих систем распознавания речи. Но как вы понимаете, обычно в таких статьях очень мало пишут про скорость и все всегда в духе "как все классно".

В частности, в статье приводятся 3 основные метрики, которыми обычно оценивается "скорость":

• Throughput (пропускная способность) сколько потоков распознавания система может обрабатывать параллельно. Для простоты назовем это "потоками";
• Real Time Factor (RTF) (на знаю как кратко перевести) насколько каждый поток распознавания распознается быстрее, чем реальное время. Давайте также для простоты определим Real Time Speed (RTS) как 1 / RTF, то есть количество секунд аудио, которое можно обработать за 1 секунду;
• Latency (задержка) какую реальную задержку чувствует конечный пользователь прежде чем ему начинают приходить какие-то ответы системы;

Еще прежде чем оценивать скорость от FAIR, нужно понимать ряд вещей:

• Все тесты FAIR гоняют на процессоре Intel Skylake c 18 физическими ядрами (информации о тактовой частоте и наличии 2 потоков на ядро нет, но по числу ядер попробую предположить это какой-то мощный топовый процессор);
• Это результаты end-to-end алгоритма реализованного на C++ с "встроенным" декодингом;
• Скорее всего вероятно используются кастомные низкоуровневые реализации из wav2letter++;
• Важно понимать, что такие статьи это в первую очередь пиар и результаты тут пере-оптимизированы на маленькие чистые академические датасеты;

Интересные моменты:

• Общая "скорость" (RTS * число потоков) быстро выходит на плато. Также видно, что для получения гарантий по скорости работы системы нужно снижать размер чанка;
• FAIR потратили существенное время на оптимизацию своей нейросети, т.к. этой статьей они продолжают по сути целое направление своих исследований, где они пиарят так называемые TDS-слои;
• В этой статье их ноу-хау по сути является несколько технических оптимизаций по скорости и квантизация;
• С определенной натяжкой, можно сказать, что они сделали что-то близкое к state-of-the-art для быстрых и практичных сетей (конечно как обычно близко без гарантий, что вы сможете это повторить и что это пошло в реальный продакшен);
• В статье FAIR пишут, что их "оптимальные" характеристики это 40 потоков, 0.26 RTF и задержка в районе одной секунды (вообще на самом деле можно выбрать любые точки на графиках выше). Понятное дело, всегда можно перенастроить такую систему допустим на больше потоков ценой задержки, ну или допустим на меньшую задержку ценой общей пропускной способности;
• Быстро на коленке Пересчитаем 40 * 1 / 0.26 и разделим на 18 физических ядер процессора. Получаем, что за 1 секунду на 1 ядре серверного процессора они могут распознать где-то в районе 8-9 секунд аудио;

Выпишем теперь самое важное для сравнения:

• Чанки: равные чанки длиной в районе 750 мс (оптимальное значение);
• Пропускная способность: Оптимальные метрики 8-9 секунд аудио на ядро процессора, 40 потоков на 18 физических ядер процессора;
• Задержка: от 500 мс до 1000 мс, для заявленного оптимального чанка в 750 мс скорее ближе к секунде;
• Низкоуровневая реализация на C++ со встроенным пост-процессингом;

Скорость Других Решений

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

Теоретические Лимиты

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

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

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

Тут не надо ходить к бабке, чтобы понять, что миниатюризация и квантизация модели очень сильно докидывает. Докидывает настолько, что задержка перестает быть критичной даже для CPU модели. Этого к сожалению нельзя сказать про пропускную способность. В сравнении с FAIR или другими системами может показаться, что последние цифры нереалистичны, но тут надо понять ряд вещей:

• Это только одна часть пайплайна без пост-процессинга;
• Это не включает потери в реальной жизни на транспорт, сериализацию, коммуникацию, итд итп;
• Мы не знаем являются ли цифры FAIR сугубо теоретическими, или туда уже включены потери на оборачивание алгоритмов в продакшен сервис;

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

Практические Сайзинги

Мы потратили довольно много времени на оптимизацию гипер-параметров для продакшена и пришли к следующим цифрам.

Пара слов о методологии:

• Метрики рассчитаны для файлов длиной 1 7 секунд, которые "кормятся" в сервис в 4 8 16 потоков;
• Распределение длин файлов соответствует распределению длин файлов в реальных диалогах людей по телефону;
• Метрики рассчитаны для многопоточного веб-сервиса, что немного абстрагируется от сценария реального использования. Ну то есть если мы можем держать условно 8 потоков с условной гарантией в latency в 500 мс, то это значит, что правильно настроив конечную бизнес-логику, можно обрабатывать сильно больше, чем 8 одновременных звонков;
• Реальные люди не говорят одновременно, пока человек заканчивает вторую фразу мы уже успеваем обработать первую итд итп. Поэтому на реальном проекте можно опять же держать еще более высокую нагрузку. Но это уже сильно зависит от реального бизнес-кейса;

Сайзинги для GPU

Есть 3 типа подходящих GPU:

• Любые игровые GPU Nvidia выше чем 1070 8+GB RAM с турбиной;
• Любые однослотовые GPU Nvidia серии Quadro 8+GB RAM (TDP 100 150W) с турбиной или пассивные;
• Nvidia Tesla T4, пассивная, TDP 75W;

Мы часто сталкиваемся с тем, что заказчики не понимают и иррационально боятся использовать GPU в продакшене мотивируя это все разного рода отговорками (типичное "отдел закупок не одобрит"). Приведем топ мнений, которые мы слышали:

• "Карты слишком мощные (300 ватт) и горячие". Это не так. У игровых и карт для исследований TDP реально такой. Но TDP решений для продакшена в пике от 75 до 150 ватт, а на практике с нашими сетями будет где-то 50-75% от пиковых значений;
• "Карты очень греют сервер и серверную". Это конечно зависит от их количества, но с нашими сайзингами даже на крупные проекты хватит 2 карт (+ резерв);
• "Карты нарушают идеально продуманную циркуляцию воздуха в серверной". В идеальном мире вообще для серверных "предназначены" только пассивные карты Tesla согласно SLA от Nvidia. Но понятно почему монополист в SLA указывает это, т.к. карты Tesla в 2-3 раза дороже. Но если вам так надо "гарантий" просто купите пассивные карты и оптимизируйте воздушные потоки сколько угодно;
• "Карты занимают только 2+ слота и не влазят в серверные шасси". Это не так. Карты Quadro и T4 занимают 1 слот;
• "Карты слишком дорогие". Топовые карты Tesla A100 действительно стоят US$12,500 в России. Но карты Quadro и T4 (я уже молчу про игровые) в рамках крупных проектов стоят уже вообще копейки;
• "Карты недолговечные и ломаются". Как и любой "силикон" если карта не бракованная она будет служить 3-4 года, плюс никто не отменял гарантию. Если не хочется иметь точку отказа в виде охлаждения всегда есть пассивные карты. Тут отмечу, что карты Nvidia с пробегом купленные с Авито прекрасно служат несколько лет в режиме 24/7 и сказки про "майнеров" это просто сказки, майнеры очень бережно относятся к технике. Знакомый майнер давно купил 100 карт Nvidia и AMD и за 3 года из строя не вышла ни одна зеленая карта;

Одна из целей данной статьи развеять эти заблуждения. Забегая вперед деплой на GPU примерно в 2-3 раза дешевле.

Сайзинги для CPU

Комментарии по Cайзингам

• В реальности со всем фаршем даже у сервиса с GPU получается только 10 15 RTS на одно ядро процессора (хотя теоретический RTS самой модели на GPU находится где-то в районе 500 1,000). В теории число воркеров CPU на 1 GPU можно наращивать больше (тем самым наращивая нагрузку на карту и пропускную способность), чем мы пробовали, но мы упираемся в удорожание процессоров. В какой-то момент горизонтальное резервирование становится важнее;
• CPU-версия сервиса показывает только в районе 5 честных RTS, что немало, но она скорее оптимизирована как баланс между гарантиями по latency и throughput;
• Метрики настоящие и честные и подбор параметров стоил много боли и страданий. Если честно я вообще не видел, чтобы кто-то вообще показывал перцентили реальных систем;
• Многие крупные проекты просят 50 одновременных разговоров, поэтому иметь возможность покрыть такой проект используя всего 2 GPU (+ резервирование) это довольно круто;
• Использование GPU сервиса где-то в 2-3 раза дешевле, чем если считать все только на CPU;

Выводы

Если статья от FAIR показывание реальные продакшен показатели, то у нас получилось используя только открытые и свободные библиотеки достичь 50% их показателей. Но скорее всего конечно цифры там теоретические. Это конечно не 20-30 RTS как у акустической модели, но как правило после упаковки в дистрибутив где-то теряется 40-50% показателей. В таком случае мы показали ряд вещей:

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

А что дальше? У нас большие планы на релиз некоторых комплиментарных распознаванию голоса технологий под довольно свободной лицензией MIT.

Введение

Аналитики, исследующие сервисы чат-ботов и виртуальных ассистентов, обещают рост рынка как минимум 30% в год. В абсолютных цифрах, по состоянию на 2019 год, рынок оценивался более чем в 2 миллиарда долларов в год. Виртуальных голосовых помощников выпустили практически все ведущие мировые IT-компании, а основную работу по их популяризации уже провели Apple, Google и Amazon.



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

В общем, то, что рынок голосовых ассистентов интересная ниша, сомневаться не приходится. И первая идея, которая приходит в голову взять любой из доступных сервисов ASR (Automatic Speech Recognition) и TTS (Text To Speech), связать их с конструктором ботов, имеющим поддержку NLU (Natural Language Understanding), и все! Тем более что все это довольно легко и быстро можно реализовать в облачных платформах, таких как Twilio и VoxImplant.

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

Как работает типичный голосовой ассистент

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


Рис. 1. Речевой сигнал

Алгоритм работы ассистента:

1. Первым делом поток, содержащий речь, разбивается на небольшие фрагменты фреймы. Причём фреймы должны идти не строго друг за другом, а внахлёст, т.е. конец одного фрейма должен пересекаться с началом другого.
   
   После этого начинается процесс распознавания, и первой задачей, которую приходится решать, является разбиение всего аудио-фрагмента на отдельные слова. Речь содержит в себе некоторые паузы (промежутки тишины), которые можно считать разделителями слов. В итоге получается, что нам необходимо найти некоторое значение, порог значения выше которого являются словом, ниже тишиной. Вариантов тут может быть несколько, но это уже детали реализации, которые нам сейчас не особо интересны. Важно только понимать, что это не константа, а динамически вычисляемая величина, например, на основе анализа энтропии.
   
   Далее происходит выделение фонем, работа с фонетическом алфавитом и в общем много чего еще, включая работу с вариантами произношения, морфологией и семантикой, причем исходя из контекста и статистики. Итогом становится то, что сервис ASR переводит набор фонем в слово.
   
   Выделение набора слов в предложения и целые смысловые фразы, происходит аналогично делению речи на слова по интервалам между словами. Только в этом случае величина интервала принимается большей, чем в случае деления на слова.
   
   На выходе данного шага мы имеем фрагмент речи, преобразованный в текст и готовый для дальнейшей обработки.
2. Результат работы голосового ассистента, полученный на первом этапе передается боту, с поддержкой NLU для выявления интентов (intents), сущностей (entities), заполнения слотов (slots) и формирования текста ответа.
   
   В итоге, на выходе у нас получается тестовое представление ответной фразы, являющейся реакцией нашего голосового ассистента на полученный запрос.
3. Ответ голосового ассистента передается в сервис синтеза речи, который в дальнейшем озвучивается человеку.

Возникающие проблемы

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

1. Задержки
2. Задержки
3. Задержки
   
   Я не просто так на первые три места поставил одну и туже проблему. Считается, что для комфортного общения ответ должен быть озвучен, примерно через 500 миллисекунд после того, как собеседник закончил формулировать свое сообщение.
   
   Исходя из реальной практики по реализации голосовых ассистентов, в случае задержки более чем в 1 сек. голосовой ассистент довольно часто будет слышать от собеседника-человека характерные для проверки связи фразы: Алло! или Меня слышно?. Это особенно свойственно для случаев, когда разработчики пытаются скрыть тот факт, что с человеком общается робот, особенно при исходящих телефонных обзвонах, используя вместо синтеза речи набор заранее предзаписанных аудио-файлов, сделанных реальным человеком.
   
   Основная сложность здесь состоит в том, что в указанный интервал времени должно уместиться выполнение следующих действий:
   
   
   • Выделение смысловой фразы. Величина задержек здесь как палка о двух концах: увеличение задержек позволяет более точно выделять законченные предложения и целые смысловые фразы, а значит повысится точность ответов ассистента, уменьшение же данной задержки увеличивает количество ошибок в его работе.
   • Перевод набора фонем в текст.
   • Обработка текста с формированием ответного сообщения.
   • Синтез речи по тексту ответа.
   
   И все это должно быть сделано за минимальный интервал времени!
   
4. Перебивание голосового ассистента пользователем и попытки уточнить в процессе прослушивания ответа. В текстовых чатах эта ситуация невозможна, т.к. доставка контента осуществляется практически мгновенно. При работе же голосовых ассистентов это вполне обычная ситуация. Более того, к моменту окончания озвучивания ответа, собственно сам ответ может быть уже совсем не актуален, т.к. собеседник успел проговорить дополнительную уточняющую информацию.
5. Единая длинная смысловая фраза может быть разорвана на несколько фрагментов. В текстовых чатах такая ситуация встречается довольно редко и характера только для стиля письма, когда каждое словосочетание или даже каждое отдельное слово отправляется отдельным сообщением. В работе голосовых ассистентов, особенно при попытке решить проблему с минимизацией задержек, данная ситуация довольно обычное дело.
6. Обратная ситуация одна фраза может содержать несколько интентов и сущностей. Причем сущности могут относиться к разным намерениям. В текстовых чатах это встречается, но реже.
   
   Пример:
   
   В каком отделении Банка вам будет удобно забрать готовую кредитную карту?
   На Ленинском проспекте. А кстати, когда оно работает? Там далеко от остановки?
   
   В приведенном примере пользователь указал значение сущности Отделение банка в качестве значения слота и сразу же выдал два интента: Время работы отделения и Детали расположения отделения. Причем сущность Отделение банка относится как к исходному слоту, так и к интентам Время работы отделения и Детали расположения отделения.
7. В устной речи присутствует большое количество слов-паразитов. В текстовых чатах они практически отсутствуют.
   
   Пример:
   
   А-а-а-а ну-у-у-у
   Ну, как бы вам сказать, типа того как э-э-э
   Сейчас, одну минутку, да-а-а Надо подумать, сразу так и не скажешь
   
   По этой причине одним запросом обрабатывать открытые вопросы становится довольно непростой задачей, т.к. человек, вместо четкого и конкретного ответа, в этом случае обычно начинает довольно долго и пространно рассуждать. Т.е. вести себя именно так, как он обычно делает в естественной речи.
8. Различные тембра, интонаций и скорости подачи при комбинировании предзаписанных фраз и синтеза речи через TTS-сервисы.

Что же делать?

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

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

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

Если вернуться к алгоритму, который должен реализовывать голосовой виртуальный ассистент, то он может выглядеть следующим образом (для иллюстрации рассмотрим входящий вопрос: Где находится ближайший банкомат?):

1. Сервис ASR анализирует речь в потоковом режиме, отдавая на следующий шаг результат по отдельным словам. На выходе данного шага мы всегда имеем одно единственное слово.
   
   Результат:
   
   a) где
   b) находится
   c) ближайший
   d) банкомат
2. Происходит накопление слов, поступивших на вход, во входном буфере
   
   Результат:
   
   a) где
   b) где находится
   c) где находится ближайший
   d) где находится ближайший банкомат
3. Накопленный результат передается на обработку текстовому ассистенту, с поддержкой NLU, для выявления интентов и сущностей.
   
   Результат:
   
   a) Запрос: где. Результат: намерение не определено
   b) Запрос: где находится. Результат: интент Расположение отделения с вероятностью 50%, Расположение банкомата с вероятностью 50%
   c) Запрос: где находится ближайший. Результат: интент Расположение отделения с вероятностью 50%, Расположение банкомата с вероятностью 50%, сущность Точка привязки = Текущее местоположение
   d) Запрос: где находится ближайший банкомат. Результат: интент Расположение банкомата с вероятностью 100%, сущность Точка привязки = Текущее местоположение
   
   
   Рис. 2. Алгоритм работы голосового ассистента
   
4. Если добавление нового слова, полученного на 1 шаге, не просто изменяет веса вероятности определенных ранее интентов, а меняет их состав либо за счет увеличения количества выявленных интентов, либо за счет полной замены их набора, то выполняются следующие действия:
   
   
   • из набора интентов предыдущей итерации выбирается вариант с наибольшей вероятностью и соответствующий ответ добавляется в выходной буфер;
   • входной буфер сбрасывается и туда заново вносится только это новое слово;
   • делается новый анализ, т.е. снова переходим на шаг 3.
   
   Всегда, по мере добавления слов в накопленное для анализа сообщение, должно изменяться значение вероятностей в уже выявленных интентах (фактически исключение интента из списка равноценно заданию ему вероятности = 0%).
   
   Это значит, что постоянно должно происходить уточнение запроса. Если же наблюдается обратная ситуация, то это значит, что во входном сообщении есть несколько интентов, которые необходимо обрабатывать по отдельности, и мы сейчас перешли к слову, которое относится к новому интенту.
5. Как только будет выявлено, что пользователь закончил свое сообщение (определяется по задержке во входном потоке), сбрасываем в выходной буфер ответ, соответствующий наиболее вероятному выявленному интенту.
6. Озвучиваем пользователю содержимое выходного буфера.

Способы повысить качество работы ассистента

Давайте рассмотрим какие есть методы, что бы еще больше повысить качество работы нашего голосового виртуального ассистента:

1. Пересортировка ответов в выходном буфере
   
   Можно ввести параметр очередности интентов и соответственно вариантов ответа по приоритетам. Это значит, что сообщения из выходного буфера озвучиваются в порядке приоритета. Например, запрашиваемое местоположение банкомата следует озвучить до информации о доступном в нем операциях (снятие/внесение наличных, открытие депозита и т.д.) или наоборот.
2. Настройки перебивания
   
   Под этим усовершенствованием понимается возможность определять для некоторых интентов включение перебивание собеседника, когда содержимое выходного буфера начинает озвучиваться до того, как пользователь закончил свой рассказ. Данная настройка хорошо работает с предыдущей опцией, когда перебивающий ответ получает максимальный приоритет для озвучания из выходного буфера.
   
   Важно отметить, что режим перебивания следует включать не для всех интентов, а лишь для некоторого, достаточно ограниченного набора.
3. Настройки категоричности
   
   Возможно, что имеет смысл выделить некоторые интенты, которые имеют признак максимальной категоричности. Т.е. в случае обнаружения категоричного интента, ответы для остальных интентов удаляются из выходного буфера, оставляя в нем только этот, категоричный ответ. Возможно, что при этом дополнительно еще включается режим перебивания, когда ассистент начинает озвучивать ответ, не дослушав до конца сообщение пользователя. Примером могут выступать высказывания, которые система классифицирует как нарушающие моральные нормы и т.п.
4. Выявление противоречивых ответов
   
   Очень желательно выявлять в выходном буфере ответы, которые противоречат друг-другу. В этом случае следует ответ с меньшим приоритетом просто удалять из выходного буфера.
   
   Дополнительно имеет смысл при выявлении подобной ситуации, в сообщение, которое было оставлено в выходном буфере добавить предсообщение Если я Вас правильно понял. Причина желательности такого добавления наличие противоречивых данных в выходном потоке, как правило всегда является следствием противоречивости данных во входном потоке. Поэтому имеет смысл дать человеку понять, что присутствует некоторый элемент неуверенности, который может подтолкнуть его к необходимости дать дополнительные уточнения.
5. Определение пола собеседника
   
   Если наделить ассистента возможностью определения гендерной принадлежности по голосу, то это позволит реализовать более близкий к естественному сценарий обработки. Таким образом появляется возможность реализовать различные ветки обслуживания, в т.ч. используя различную лексику при формировании одних и тех же ответов.
6. Анализ эмоционального состояния
   
   В обычном разговоре двух и более людей, собеседники, как правило довольно точно могут определить эмоциональное состояние друг друга. Причем делается это не только по содержанию используемой лексики, например, факту наличия или отсутствия в речи ругательств, но и по тембру и скорости речи. Будет просто отлично, если ассистент сможет особым образом обслужить рассерженного пользователя.
   
   Современные системы речевой аналитики достаточно хорошо справляются с задачей определения гендерной принадлежности и эмоционального состояния человека. Осталось только приспособить их к анализу разговора в режиме online.

Особенность реализации бизнес-кейсов

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

Знаете, есть такое правило, справедливое для менеджеров по продажам То, что нельзя продать по телефону, не следует продавать по телефону. По этой самой причине ответ вида Ближайший банкомат находится по адресу является не информативным для человека. Если бы он хорошо знал район где сейчас находится, т.е. знал бы названия всех близлежащих улиц и номера домов, то скорее всего он и так бы знал где здесь находится ближайший банкомат. Так что такой ответ скорее всего сразу вызовет формирование другого вопроса: А где тогда находится названный только что адрес?. Гораздо более информативным ответом будет вариант: Ближайший банкомат находится примерно в ста метрах от вас по направлению на юго-восток, а еще лучше так же дополнительно отправить человеку сообщение типа location на Yandex или Google карты.

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

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

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

Совершенству нет предела

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

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

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

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

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

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



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

Какая задача стояла

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

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

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

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

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

Как это выглядит со стороны пользователя

Тут все просто.

1. Человек звонит на горячую линию, ему предлагают выбрать между разговором с оператором и Лилией. На любом этапе можно переключиться на живого оператора.
2. Лилия предлагает озвучить свой вопрос и человек его задает.
3. Лилия отвечает и спрашивает, смогла ли она ответить на вопрос. Если ответ нерелевантный или Лилия не знает ответа на этот вопрос, то она просит его повторить или сформулировать по-другому.

Как обрабатываются звонки

Для приема звонков и реализации сценариев использовали платформу Voximplant: написали скрипт и подключали сигнал автоответчика. Лилия приветствовала человека и спрашивала, чего он хочет.

Звонящий задает вопрос по телефону. Затем Лилия начинала слушать. У VoxImplant мы использовали модуль ASR для перевода речи в текст, он под капотом вызывает модель Yandex.SpeechKit. Таким образом, аудиопоток переводится в текст, который потом проходит токенизацию и стемминг. Мы попробовали также извлекать признаки: NER, POS и Chunk для базовых методов ML, но все это занимало очень много времени.



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

Дальше возможно несколько вариантов в зависимости от уровня уверенности (confidence):

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

Для таких вопросов мы использовали обученную на дампе Википедии модель BERT для задачи knowledge base question answering.

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

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

Суммарно проект занял две с половиной недели с учетом датасетов: возникла идея, обсудили проект с министром и, как говорят у нас, алга. Неделя ушла на прикидку и исследование, еще дней 10 заняла разработка, затем мы дорабатывали и прикручивали дополнительные функции. Основными лошадками были Nvidia RTX2070. Для BERT'ов требовалось около 12-16 ГБ видеопамяти.

От LSVM и catboost до DeepPavlov

В процессе разработки мы использовали разные модели классификаторов. Сначала мы попробовали такие модели машинного обучения, как random forest, LSVM, catboost, logreg. Вообще точность моделей машинного обучения была не очень высокой. Почему так? Потому что многие вопросы пользователей очень похожи друг на друга: вопрос у меня ребенок заболел коронавирусом что делать достаточно похож на вопрос можно ли гулять с ребенком во время коронавируса, хотя это разные категории и требуются разные ответы.

Мы могли бы заняться извлечением сущностей, увеличением выборки, исследования. Но мы торопились. Поэтому мы решили использовать в работе библиотеку DeepPavlov от МФТИ, давшую точность 78% с логистической регрессией и BERT 84%.



Точность ответов зависит от разметки датасетов. У нас был список из 200 вопросов, которые люди задают на горячей линии, но они были неправильно разделены. Например, люди спрашивали, что делать, если у них заболел кто-то из родственников, и был вопрос, какие симптомы у коронавируса. Модели ML путались.

Результаты и планы на будущее

Лилия проработала 2 недели и обработала 5000 звонков. За это время Лилия существенно облегчила работу операторам горячей линии им не приходилось отвечать на банальные и повторяющиеся вопросы. Благодаря Лилии пользователи получали пропуска, ответы на вопросы и просто разговаривали. Конечно, были пользователи, которые ругались на нее и просили перевести на оператора.

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

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

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

Пока что Лилия может подсказать, до скольки работает ЗАГС, а в будущем мы планируем, что она сможет принимать показания счетчиков (но это только тогда, когда мы решим вопрос с безопасностью передачи этих данных). В общем, мы превращаем Лилию в отдельный продукт.

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

Почему это важно?

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

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



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

Научите ассистента говорить правильно

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

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

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

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

Понимание состояния собеседника

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

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

Существуют три типа восприятия:

1. Визуальный, зрительный тип. Человек этого типа воспринимает и организует свой опыт и мышление в основном посредством зрительных образов (Лучше один раз увидеть, чем сто раз услышать). В его лексике представлены слова зрительного ряда: имена существительные, глаголы, наречия и прилагательные, которые как бы описывают картину увиденного. Примеры: прозрачный намек, перспективная мысль, впечатляющий удар.
2. Аудиальный (слуховой) тип. Он представляет мир в аудинальных (слуховых) образах. В лексике это представлено соответствующим рядом слов. Примеры: кричащая идея, оглушительный удар, немой намек, шумная или тихая фигура.
3. Кинестетический тип. Это тип, который воспринимает и оценивает мир, прежде всего, с помощью ощущений и чувств. Ему присуща своя лексика: тяжелый или легкий вопрос, мощная идея, жесткий намек, сильная или слабая мысль, давящая фигура, скользящий или уверенный удар.

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

Использование речевых стратегий

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

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

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

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

Итак, рассмотрим самые распространенные речевые техники.

Закон причины и следствия

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

Пример:
Что посеете, то и пожнете.

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

Трюизмы

Трюизм (англ. truism) банальность. Это общеизвестное утверждение, не требующее доказательств и воспринимаемое как истина. Например:
Все мы иногда ошибаемся.

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

Еще один способ использования трюизма вызвать доверие к последующим утверждениям. То есть подстроиться:
Мы постоянно меняемся. Тариф Индивидуальный меняется вместе с тобой.

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

Предположения

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

Если произойдёт одно событие (придёте на приём), то после него произойдёт и другое (почувствуете лучше). Получается, что отказаться от приёма нельзя, потому что с ним связана вторая часть фразы о хорошем самочувствии.

Другой очень распространенный пример из жизни:
Будешь гулять купи хлеба.

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

Противоположности

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

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

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

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

Наглядные примеры:
Чем больше вы отвлекаетесь, тем внимательнее слушаете.
Чем внимательнее вы прочтёте договор, тем быстрее вы примете решение.
Чем сильнее болит голова, тем быстрее боль проходит.
Насколько больше ты потратишь времени на изучение, настолько лучше ты будешь знать этот предмет.

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

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

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

Двойные вопросы

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

Примеры:
А вы заметили, как вам идёт этот костюм?
Чувствуете, как с каждым моим словом вам становится всё лучше?



Несмотря на кажущуюся простоту, считается, что данный приём обладает достаточно мощным эффектом.

Ложный выбор

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

Все выборы

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

Оценка

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

В этой стратегии чаще всего используются оценочные слова:

• важно
• нужно
• странно
• нравится
• любопытно
• раздражает
• удивляет
• сомневаюсь
• уверен
• хотел бы

Пример:
Хотел бы я принимать решения, так же быстро, как ты.
Скрытый смысл: вы принимаете решения быстро, особенно, когда это нужно мне.

Всех удивляет качество этого фотоаппарата.
Скрытый смысл: качество этого фотоаппарата это истина.

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

Отрицания в командах

Это техника, которая оперирует с тем, что человеческое бессознательное не умеет работать с отрицаниями. Оно их просто игнорирует. И на использовании этой возможности все и основано.
Пример:
Не спешите начать всё заново.
Скрытый смысл: спешите начать всё заново

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

Конструкция этой речевой стратегии крайне проста: вы определяете команду, а потом ставите перед ней частицу не.

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

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

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

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