Звук.
1.1. Сколько часов аудио использовалось для тренировки акустической модели, чтобы достичь удовлетворительного результата?
1.2. Какая модель использовалась для акустической модели? Почему именно она?
1.3. Чем пользовались для создания разметки для звуковой модели?
Использовались все доступные данные с vox forge для русского языка.Это около 25 часов. В нашем случае акустическая модель — это скрытая марковская модель, обученная на трифонах (triphone). То есть такая модель обучалась не на отдельных фонемах, а на частях фонемы в контексте. Например, в слове “кошка” первая гласная описывается не одной “о” в вакууме, а тремя: 1) предшествующий велярный звук “к”; 2) интересующая нас фонема “о”; 3) последующий фрикативный звук “ш”. Такой подход позволяет различать конкретные акустические реализации одной фонемы (их ещё называют аллофонами), а значит лучше соответствует реальному положению дел, чем монофонная модель. Подробнее можно почитать главу 10.3 «Speech and Language Processing, 2nd edition», Jurafsky & Martin. Предобработка данных производилась с помощью shell скриптов. С библиотекой идет много примеров, как подготовить данные для последующего обучения.
Языковая модель.
2.1. Как строили языковую модель?
2.2. Каков был объем датасета?
2.3. Почему не использовали большие корпусы типа википедии?
Языковая модель (в нашем случае это была n-gram модель) строилась с помощью инструмента SRILM. Что касается объемов: были задействованы транскрипты с vox forge и около тысячи предложений, содержащих спец.термины домена. Большие корпусы не пробовали по двум причинам. Во-первых, хотелось разработать первую версию помощника как можно быстрее. Во-вторых, не было уверенности в том, нужна ли нам общая языковая модель русского, так как пользователи ПО будут в основном использовать однотипные команды и нефтяные термины.
вам было необходимо использовать beam search(или что-то аналогичное), чтобы составить «решетку гипотез.»
Немного не так. “Решетка” (lattice), по которой нам надо пройтись и найти наиболее вероятную последовательность (это и будет искомый текст), представляет собой граф из всех составляющих системы: акустической модели, лексикона (словаря произношений) и языковой модели. Beam search — это алгоритм, проходящий по графу и отбрасывающий маловероятные пути. То есть, он используется, чтобы уменьшить граф и ускорить процесс поиска, а не создать его. Если захочется подробнее разобраться с теорией, рекомендую 9 главу у Jurafsky & Martin и учебник ИТМО «Автоматическое распознавание речи».
Выделение смыслов.
3.1 Почему вы использовали именно этот вариант ембединга StarSpace, почему не FastText или предтренированный BERT. Очень интересны мотивы вашего выбора.
3.2 В классификации намерений, немного странным выглядит, то что метрики для классов: «Приветствие», «Отрицание», «Подтверждение» — ниже, чем для других. Как мне кажется, это наиболее простые классы для классфикации. Можете как-то прокомментировать?
3.4 Каковы мотивы выбора CRF для NER? Не самое популярное решение.
Как мы упоминали ранее, предобученные векторы для такого специфичного домена подходят мало, поэтому мы и обучали свои. Что касается распознавания намерений, такие классы как “Приветствие” и подобные более вариативны с лингвистической точки зрения. К примеру, если в обучающей выборке не было примера прощания “Чао-какао”, то машина его верно не распознает. С другими намерениями системе справляться “проще”, ведь, если пользователю нужна информация по обводненности скважины, он хочешь-не хочешь да скажет что-то про “воду”, “водичку” и т. п. Для выделения именованных сущностей выбрали CRF, так как нужно было обучить свою кастомную модель. Насколько мне известно, предобученных NER моделей русского языка для выделения нефтяных месторождений нет.
Диалог с пользователем.
4.1 Насколько могу судить по картинке из статьи, ваша система поддержиает диалог с пользователем, а значит нужна отдельная модель для отслеживания статуса диалога. Можете рассказать что использовали, как тренировали, каков был объем выбрки итд?
Действительно, помощнику нужно поддерживать контекст, и в этом помогает фреймворк Rasa (Советую посмотреть их блоги на youtube и medium. Даже, если использовать либу не будете, рассказывают о чат-ботах очень интересно). Для отслеживания статуса диалога используется объект класса “Tracker”, позволяющий вытаскивать, к примеру, значение определенного слота.
Пример. Пользователь говорит: “Покажи погоду на завтра в Сочи”. В коде, отвечающем за обработку намерений класса “прогноз_погоды”, мы можем использовать Tracker для выделения города:
tracker.get_slot("city")
При условии, что наша NER модель сработала и верно выделила город, наш бот теперь будет знать контекст, и в следующем вопросе “А дождь сегодня будет?” уточнять локацию уже не нужно.
Утверждаю, что с калди на vox forge результата, годного для продакшен использования достичь очень трудно.
Спасибо за рекламу вашей системы. Мы хотели лишь поделиться с читателями своим опытом.
Использование калди также очень тяжело оправдать с точки зрения поддержки и развития в будущем.
Возможно, вы правы. Но достоинства у kaldi всё же есть. Как минимум, большое количество рецептов и обширное коммьюнити.
обратите внимание, что каких-то метрик которые как-то можно сравнить с чем-то общеизвестным в статье нет
Действительно, метрик в статье нет, поскольку распознавание на каких-то общеизвестных данных не проводилось. Тестировались мы на записях, содержащих специфичные термины, ведь именно ими будут оперировать пользователи ПО. Нам хотелось оценить, распознает ли модель этот самый нефтяной жаргон. Какой-то WER получили, но посчитали, что писать о метрике, полученной на тесте, который есть только у нас, нецелесообразно и лишь введет читателей в заблуждение. На лавры гугла или яндекса и их точность распознавания мы уж точно не заримся :)
Описанная выше задача решается тупо словарем (словарем, Карл!) или н-граммным поиском. Ну или комбинацией этих методов вместе с регулярками.
Мы пробовали подход “мешка слов” и частотный анализ (tf-idf), используя и не используя n-граммы. Они давали на тех же данных результаты гораздо хуже. Например, f1 не больше 66%.
надо попробовать готовые вектора, ну или на крайний случай потыкать FastText.
Готовые векторы мало подходят для такого специфичного домена, поэтому мы и обучали свои. FastText не пробовали применять к этой задаче. Возможно, стоит.
Мы искали библиотеку, способную одновременно решить задачу классификации намерения пользователя и выделения именованных сущностей. Подходящим решением оказалась библиотека Rasa, используемая для создания чат-ботов. Векторы в ней обучаются с помощью StarSpace.
Использовались все доступные данные с vox forge для русского языка.Это около 25 часов. В нашем случае акустическая модель — это скрытая марковская модель, обученная на трифонах (triphone). То есть такая модель обучалась не на отдельных фонемах, а на частях фонемы в контексте. Например, в слове “кошка” первая гласная описывается не одной “о” в вакууме, а тремя: 1) предшествующий велярный звук “к”; 2) интересующая нас фонема “о”; 3) последующий фрикативный звук “ш”. Такой подход позволяет различать конкретные акустические реализации одной фонемы (их ещё называют аллофонами), а значит лучше соответствует реальному положению дел, чем монофонная модель. Подробнее можно почитать главу 10.3 «Speech and Language Processing, 2nd edition», Jurafsky & Martin. Предобработка данных производилась с помощью shell скриптов. С библиотекой идет много примеров, как подготовить данные для последующего обучения.
Языковая модель (в нашем случае это была n-gram модель) строилась с помощью инструмента SRILM. Что касается объемов: были задействованы транскрипты с vox forge и около тысячи предложений, содержащих спец.термины домена. Большие корпусы не пробовали по двум причинам. Во-первых, хотелось разработать первую версию помощника как можно быстрее. Во-вторых, не было уверенности в том, нужна ли нам общая языковая модель русского, так как пользователи ПО будут в основном использовать однотипные команды и нефтяные термины.
Немного не так. “Решетка” (lattice), по которой нам надо пройтись и найти наиболее вероятную последовательность (это и будет искомый текст), представляет собой граф из всех составляющих системы: акустической модели, лексикона (словаря произношений) и языковой модели. Beam search — это алгоритм, проходящий по графу и отбрасывающий маловероятные пути. То есть, он используется, чтобы уменьшить граф и ускорить процесс поиска, а не создать его. Если захочется подробнее разобраться с теорией, рекомендую 9 главу у Jurafsky & Martin и учебник ИТМО «Автоматическое распознавание речи».
Как мы упоминали ранее, предобученные векторы для такого специфичного домена подходят мало, поэтому мы и обучали свои. Что касается распознавания намерений, такие классы как “Приветствие” и подобные более вариативны с лингвистической точки зрения. К примеру, если в обучающей выборке не было примера прощания “Чао-какао”, то машина его верно не распознает. С другими намерениями системе справляться “проще”, ведь, если пользователю нужна информация по обводненности скважины, он хочешь-не хочешь да скажет что-то про “воду”, “водичку” и т. п. Для выделения именованных сущностей выбрали CRF, так как нужно было обучить свою кастомную модель. Насколько мне известно, предобученных NER моделей русского языка для выделения нефтяных месторождений нет.
Действительно, помощнику нужно поддерживать контекст, и в этом помогает фреймворк Rasa (Советую посмотреть их блоги на youtube и medium. Даже, если использовать либу не будете, рассказывают о чат-ботах очень интересно). Для отслеживания статуса диалога используется объект класса “Tracker”, позволяющий вытаскивать, к примеру, значение определенного слота.
Пример. Пользователь говорит: “Покажи погоду на завтра в Сочи”. В коде, отвечающем за обработку намерений класса “прогноз_погоды”, мы можем использовать Tracker для выделения города:
При условии, что наша NER модель сработала и верно выделила город, наш бот теперь будет знать контекст, и в следующем вопросе “А дождь сегодня будет?” уточнять локацию уже не нужно.
Спасибо за рекламу вашей системы. Мы хотели лишь поделиться с читателями своим опытом.
Возможно, вы правы. Но достоинства у kaldi всё же есть. Как минимум, большое количество рецептов и обширное коммьюнити.
Действительно, метрик в статье нет, поскольку распознавание на каких-то общеизвестных данных не проводилось. Тестировались мы на записях, содержащих специфичные термины, ведь именно ими будут оперировать пользователи ПО. Нам хотелось оценить, распознает ли модель этот самый нефтяной жаргон. Какой-то WER получили, но посчитали, что писать о метрике, полученной на тесте, который есть только у нас, нецелесообразно и лишь введет читателей в заблуждение. На лавры гугла или яндекса и их точность распознавания мы уж точно не заримся :)
Мы пробовали подход “мешка слов” и частотный анализ (tf-idf), используя и не используя n-граммы. Они давали на тех же данных результаты гораздо хуже. Например, f1 не больше 66%.
Готовые векторы мало подходят для такого специфичного домена, поэтому мы и обучали свои. FastText не пробовали применять к этой задаче. Возможно, стоит.