К.Ю. Дрыгин, Е.М. Кирьянов

kdrygin@voicelab.ru

     Технология автоматического распознавания речи уже давно вышла из научно-исследовательских лабораторий. На рынке присутствуют массовые программные продукты, которые позволяют интегрировать распознавание речи в Call-центр или IVR, более того, многие российские производители Call-центров заявили в своих решениях такую возможность. Но, несмотря на весьма высокий уровень качества, по оценкам экспертов точность распознавания речи в реальных приложениях доходит до 90%, массовых внедрений не наблюдается. В чем проблема? Почему перспективнейшее направление пока не признано рынком в России? Чтобы ответить на этот вопрос, для начала, нужно определиться, какой смысл мы вкладываем в понятие распознавание речи в телекоммуникационных системах и, далее, попытаться понять принципы разработки эффективных речевых интерфейсов и увидеть какие моменты упускают разработчики приложений при создании грамматик. Поддержка сервиса распознавания речи в платформе IVR, это не более чем потенциальная возможность, реализация которой в конкретной услуге может грешить ошибками и неточностями, что чаще всего и происходит в реальности. В доказательство этих слов, можно сказать, что за годы работы в сфере оказания автоматических телефонных услуг, авторы данной статьи познакомились со многими реализациями пользовательских интерфейсов с распознаванием речи, но ни одна из них, не использовала потенциал ядра системы распознавания более чем на 10-15%.

     Существующие в настоящее время варианты понимания словосочетания «автоматическое распознавание речи в телекоммуникационных системах» можно свести к трем наиболее популярным:

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

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

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

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

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

• Прокопьевск
• город Прокопьевск
• город Прокопьевск Кемеровской области
• Прокопьевск, Кузбасс
• Кемеровская область, Прокопьевск
• ...

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

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

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

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

1. Формирование грамматики распознавания речи.
2. Анализ грамматики.
3. Получение пользовательского ввода.
4. Построение фонемной транскрипции пользовательского ввода.
5. Сравнение пользовательского ввода с моделью, заданной грамматикой.
6. Выдача результатов распознавания.

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

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

     ак формат грамматики распознавания речи, так и результат проверки соответствия голосового ввода конкретной грамматике – грубо говоря, исполнения грамматики – для каждой конкретной системы может быть произвольным. Тем не менее, для облегчения переносимости приложений голосового ответа между различными системами распознавания речи предпочтительно пользоваться стандартными форматами. На сегодня к ним относятся описанный в спецификациях консорциума W3C формат грамматики распознавания речи SRGS (Speech Recognition Grammar Specification), а также его расширение, предназначенное для уточнения семантики и синтаксиса результата,– SISR (Semantic Interpretation for Speech Recognition).

     В спецификациях W3C определены две формы представления SRGS: ABNF (Augmented Backus-Naur Form) и XML (eXtensible Markup Language). Рассмотрим основные элементы грамматики, предусмотренные более удобной для восприятия XML-формой данной спецификации:

Тег	Описание
Grammar	Собственно грамматика распознавания. Синтаксис: <grammar version = "string" root = "string" / > Атрибуты: version – версия грамматики. Последняя из созданных W3C версий носит номер 1.0 root – корневое правило распознавания. Именно с него начинается распознавание после загрузки грамматики. Помимо указанных, элемент grammar может включать в себя множество дополнительных атрибутов, таких, например, как указание xml-схемы Родительские теги: xml Дочерние теги: rule, ruleref, tag
Rule	Определяет правило грамматики, то есть обособленный, относительно независимый, семантически значимый ее элемент. Синтаксис: <rule id = "string" scope = "string" / > Атрибуты: id - уникальный идентификатор правила в грамматике. Обязателен scope – область действия правила. Принимает одно из следующих значений: private – локальная область действия (только внутри грамматики, в которой правило определено); public – правило доступно для других грамматик. Родительские теги: grammar, rule, item Дочерние теги: rule, item, one-of, ruleref, tag
Ruleref	Определяет ссылку на правило. Ссылка может быть как внутренней (на правило, определенное в данной грамматике), так и внешней – на правило в другой грамматике, описанное с областью действия public. Синтаксис: <rule uri = "string" tag = "string" special = "string" / > Атрибуты: uri - указатель в формате URI на правило (rule) tag - значение, возвращаемое из системы распознавания special – необязательный атрибут, может принимать одно из следующих значений: NULL – правило, которое автоматически генерирует совпадение, даже если пользователь не произносит ни одного слова VOID – правило, с которым голосовой ввод никогда не может совпасть GARBAGE – правило, соответствующее любой фразе вплоть до совпадения со следующим правилом (используется для обозначения незначимых слов). Родительские теги: rule Дочерние теги: Нет
Example	Определяет пример фразы. Может использоваться как разработчиком для облегчения понимания, так и средствами проверки грамматик для оценки корректности правила. Синтаксис: <example / > Родительские теги: rule, item Дочерние теги: tag
Item	Определяет отдельное выражение, произносимое пользователем. Обычно используется для описания повторяющихся элементов фразы или выбора из нескольких возможных вариантов. Синтаксис: <item tag = "string" repeat = "string" weight = "string" xml:lang="string" / > Атрибуты: repeat - определяет количество повторений элемента. Любое целое неотрицательное число или диапазон (например, «7-11», «1-») weight - весовой коэффициент элемента. Показывает, насколько вероятно появление данного варианта в списке из нескольких взаимоисключающих элементов. Рациональное положительное число; значения меньше единицы соответствуют пониженной вероятности, больше единицы – повышенной xml:lang – язык, на котором произносится данное выражение. Данный атрибут полезен в тех случаях, когда отдельную фразу или ее элемент пользователь может произнести на языке отличном от языка грамматики. Родительские теги: rule, item, one-of Дочерние теги: ruleref, item, one-of, tag
One-of	Определяет множество взаимоисключающих альтернативных выражений Синтаксис: <one-of / > Родительские теги: rule, item Дочерние теги: item
Tag	Предназначен для расширения базового синтаксиса GRXML. Используется, в частности, для описания правил семантической интерпретации в формате SISR. Синтаксис: <tag / >

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

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

<rule id= "city">
    <one-of>
        <item>Прокопьевск<tag>$='City=Prokopevsk;LocID = RSXX0047;'</tag></item>
        <item>ПрокопЕвск<tag>$='City=Prokopevsk;LocID = RSXX0047;'</tag></item>
        <item>Новосибирск<tag>$='City=Novosibirsk;LocID = RSXX0077;'</tag></item>
        <item>Кемерово<tag>$='City=Kemerovo;LocID = RSXX0277;'</tag></item>
    </one-of>
</rule>

     Отдельно отметим наличие контейнера <tag></tag>: его содержание говорит о том, что в случае соответствия голосового ввода одному из вариантов результату, возвращаемому данным правилом (условно обозначаемому '$'), следует присвоить указанную строку (вида "City=A; LocID =B;"). Результат, необходимый для запроса прогноза в сети Интернет, интерпретируется приложением голосового ответа.

     Учтем, что пользователь в ответ на просьбу назвать населенный пункт может произнести не только название, но и тип последнего:

<rule id= "LocationWithPrefix">
    <item repeat = "0-1">
        <one-of>
            <item>город</item>
            <item>поселок</item>
        </one-of>
    </item>
    <item>
        <ruleref uri = "#city"/>
        <tag>$ = $$<tag>
    </item>
    <example>
        "[город] Прокопьевск"
    </example>
</rule>

     Элемент tag нового правила LocationWithPrefix указывает, что возвращаемому данным правилом результату ("$") нужно без изменений присвоить значение, возвращаемое правилом "city" ("$$").

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

<rule id= "Region">
    <one-of>
        <item>Кемеровская область<tag>$='Kuzbass'</tag></item>
        <item>Кемеровской области<tag>$='Kuzbass'</tag></item>
        <item>Кузбасс<tag>$='Kuzbass'</tag></item>
    </one-of>
</rule> <rule id= "Country">
    <one-of>
        <item>Россия<tag>$='Country=RU; Capital =Moskow; CapitalLocID=RSXX0063;'</tag></item>
        <item>КеГермания<tag>$='Country=DE;Capital=Berlin;CapitalLocID=GMXX0007;'</tag></item>
    </one-of>
</rule>

     Для удобства в возвращаемое правилом «Country» значение внесен не только идентификатор страны («Country=RU»), но и дополнительные параметры: «Capital» и «CapitalLocID»,– содержащие название и код столицы соответственно. Это позволяет добавлять к прогнозу для одного из городов страны информацию о погоде в столице, а также помогает в тех случаях, когда абонент забыл название последней. Кроме того, данная модификация может оказаться полезной, если голосовой ввод не был распознан.

     Собрав воедино все указанные выше правила, мы получим правило («fullCity» в приведенном ниже тексте), способное обрабатывать фразы вида «Россия, Кемеровская область, город Прокопьевск», «Германия», «Новосибирская область, Новосибирск» и им подобные:

<rule id= "LocationWithPrefix">
    <item repeat = "0-1">
        <one-of>
            <item>город</item>
            <item>поселок</item>
        </one-of>
    </item>
    <item>
        <ruleref uri = "#city"/>
        <tag>$ = $$<tag>
    </item>
    <example>
        "[город] Прокопьевск"
    </example>
</rule>

<rule id= "fullСity">
    <tag>$ = ""</tag>
    <item repeat = "0-1">
        <ruleref uri = "#Country"/>
        <tag>$ += "Country=" + $$+"; "</tag>
    </item>
    <item repeat = "0-1">
        <ruleref uri = "#Region"/>
        <tag>$ += "Region=" + $$+"; "</tag>
    </item>
    <item repeat = "1">
        <ruleref uri = "#LocationWithPrefix"/>
        <tag>$ += $$</tag>
    </item>
    <example>
        "[[Россия] Кемеровская область] [город] Прокопьевск "
    </example>
</rule>

<rule id= "fullСityR">
    <tag>$ = ""</tag>
    <item repeat = "1">
        <ruleref uri = "#LocationWithPrefix"/>
        <tag>$ += "Country=" + $$+"; "</tag>
    </item>
    <item repeat = "0-1">
        <ruleref uri = "#Region"/>
        <tag>$ += "Region=" + $$+"; "</tag>
    </item>
    <item repeat = "0-1">
        <ruleref uri = "#Country"/>
        <tag>$ += $$+"; "</tag>
    </item>
    <example>
        "[город] Прокопьевск, [Кемеровской области, [Россия]]"
    </example>
</rule>


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

• назван город/любой другой населенный пункт с произвольной детализацией его местоположения
• назван регион и, возможно, страна
• названа только страна

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

     Литература:

1. R. Pieraccini, J. Huerta. «Where do we go from here? Research and commercial spoken dialog systems». http://www.sigdial.org/workshops/workshop6/proceedings/pdf/65-SigDial2005_8.pdf
2. «Speech Recognition Grammar Specification Version 1.0»
   http://www.w3.org/tr/2004/REC-speech-grammar-20040316/
3. SpeechXpert for SpeechPearl. Version 6.2. "User’s Guide"