Я: «Сири, перейдите к следующей песне, пожалуйста».

Siri: Воспроизведение« Next Please » Яна Гарбарека из Spotify »

Я: «Нет, нет, Siri, оставайся на этом альбоме, включи на нем следующую песню»

Siri: К сожалению, на Spotify нет песни« Stay Яна Гарбарека. Вы имели в виду Остаться, сказав Рианна? »

Я: * многократно стучит головой о столешницу

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

Я предпочитаю рассматривать этот вызов архитектуре звукового программного обеспечения через призму эргодичности, что означает просто количество шагов, которые вы можете пройти, прежде чем случится катастрофа. Пример, который часто использует Нассим Талеб, пытается найти средний выигрыш / проигрыш за сто ночей игры в карты в казино. Если вы дадите сотне людей сотню долларов на ночь, некоторые обанкротятся, некоторые заработают 3000 долларов, а большинство будет где-то посередине. Если вы затем подсчитаете среднюю потерянную сумму, вы обнаружите, что у казино есть небольшое преимущество, и что средний убыток составил, скажем, 12 долларов. Ни один игрок не должен знать другого игрока или заботиться о нем, чтобы это исследование прошло успешно; эти сто игроков никоим образом не зависят друг от друга, и ничто из того, что делает один, не должно влиять на производительность других.

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

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

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

Аудиопрограммы, такие как навыки Алексы или команды Сири, гораздо больше похожи на дядю Лео. Если один шаг идет не так, все идет не так, потому что нет четкого способа исправить это. Звуковой эквивалент вездесущих функций взаимодействия с пользователем в традиционном интерфейсном программном обеспечении, таких как «назад», «закрыть» или «выйти», непонятен с помощью голоса. Голос имеет низкую плотность информации, доступную пользователю о том, как на самом деле использовать вещь; тогда как веб-сайт будет иметь заголовки, ярлыки и кнопки, видимые пользователю, голосовой интерфейс ничего не может показать. Если пользователь не запомнил эти команды, ему может быть трудно узнать, что они существуют.

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

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

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