Комментарии 15
Тоже обратил внимание на этот момент, задумался каковы же kpi у разработчиков и эксплуатации, как измеряется любовь )
1) У нас есть и такое ПО, которое продаётся вовне, конкурирует на открытом рынке, и да, хочется, чтобы оно покупалось не просто потому что дешевле, чем у расслабившихся на олигопольном рынке конкурентов, а потому что лучше. И оно покупается теми, кому не обязательно к применению.
2) У нас есть такое ПО, которое не продается (пока) вовне, но и для него любовь пользователей тоже важна. У нас такой подход: мы с самого начала вокруг разработки ПО пытаемся сформировать целевую активную группу пользователей, которые будут нам говорить, что мы сделали удобно, а что неудобно. Если у них горят глаза, они могут генерировать предложения, которые нам самим и в голову не пришли бы. Если мы будем делать невоодущевляющее ПО, у группы активных пользователей глаза потухнут, пройдет любовь и завянут помидоры, а без любви, из-под палки, редко рождаются ценные идеи и предложения. Так что любовь пользователей нужна для вовлечения в процесс.
3) Банальную вещь скажу, но любовь пользователей — это мощная нематериальная мотивация, которая реально работает. Очень многим людям важно понимать, что они делают полезный продукт, который будет облегчать инженерам жизнь.
В качестве данных для обучения акустической модели использовался свободно распространяемый аудио датасет VoxForge. Языковая модель обучалась как на транскриптах аудио с VoxForge, так и на созданном нами датасете, содержащим термины нефтегазовой отрасли, названия месторождений и добывающих обществ.
Из нашего опыта в создании Open STT и нашей системы Silero могу сказать, что что-то из Калди можно выжать и на паре сотен часов на VoxForge. Да на более мелких языках даже наша гибридная модель будет показывать что-то, если правильно подобрать словари и вторичные языковые модели. Но!
Но реальные моменты тут будут такие:
- Скорее всего модель не будет генерализоваться как по вокабуляру, так и по голосам. По доменам скорее всего тоже, но это не нужно. Примеры выше явно были cherry-picked;
- Мы видели как примерно похожие модели подгоняют показывать "метрики" на конкретных доменах, например если взять языковую модель и вокабуляр ТОЛЬКО из слов своего датасета, это сразу докидывает 5-10 WER. Но когда люди скажут слова, которых не было в вокабуляре… ну вы поняли. Немного ситуацию упрощает то, что это фонемные модели, но постоянно искать ошибки и добавлять новые слова это муторно. Но с учетом поставновки задачи, вряд ли кто-то нормально снимает метрики;
- Скорее всего будут вопросы с поддержкой;
Это все конечно, если авторы говорят правду или правда прошла через пиар сито без искажения.
Изобретать велосипед и писать с нуля библиотеку для распознавания речи было бы нецелесообразно, поэтому наш выбор пал на фреймворк kaldi. Несомненным плюсом библиотеки является её гибкость
Утверждаю, что с калди на vox forge результата, годного для продакшен использования достичь очень трудно. Использование калди также очень тяжело оправдать с точки зрения поддержки и развития в будущем. Поэтому такие статьи можно и нужно воспринимать или как браваду / оголтелый пиар (обратите внимание, что каких-то метрик которые как-то можно сравнить с чем-то общеизвестным в статье нет). Тренировать свою STT систему в рамках нефтяной компании — это и есть как раз изобретение велосипеда.
Соответственно это или оно, или на самом деле используют другие датасеты или модели.
На российском рынке часто встречаются такие ситуации:
- Коммерческие компании строят все "с нуля сами" не имея соответствующей экспертизы, нанимают команды, тратят время, а в итоге получается как пресловутое"отечественное ПО";
- "Исследовательские" организации показывают "демо"-решения на базе систем и датасетов, на которые у них нет ни лицензий ни банальной технической экспертизы и понимания как оно работает;
Чтобы решить первую задачу, необходимо представить текст в виде числового вектора, который может быть обработан машиной. Для подобного преобразования использована нейронная модель StarSpace, позволяющая «вложить» текст запроса и класс запроса в общее пространство.
Меня всегда радует, когда берется огромная стеклянная пушка (которая кстати не особо пошла в массы), чтобы забить микроскопический гвоздь. Да эмбеддинги это классная штука, но:
- Описанная выше задача решается тупо словарем (словарем, Карл!) или н-граммным поиском. Ну или комбинацией этих методов вместе с регулярками. Сетки и вектора оправданно тащить уже когда корпуса состоят из сотен тясяч или миллионов примеров;
- Даже если вектора это почему-то must-have (как недавно был перл в приватной беседе — мы готовы покупать работающее решение для решения реальной проблемы — ой, там нет нейросетей, тогда не готовы! верните нейросети), то как минимум не надо сразу брать starspace, а надо попробовать готовые вектора, ну или на крайний случай потыкать FastText. Как правило основной вопрос тут — чистка текста и кастомная токенизация. Как правило результаты со 100% метриками — это или плохие метрики, или неправильно поставленная задача;
Утверждаю, что с калди на vox forge результата, годного для продакшен использования достичь очень трудно.
Спасибо за рекламу вашей системы. Мы хотели лишь поделиться с читателями своим опытом.
Использование калди также очень тяжело оправдать с точки зрения поддержки и развития в будущем.
Возможно, вы правы. Но достоинства у kaldi всё же есть. Как минимум, большое количество рецептов и обширное коммьюнити.
обратите внимание, что каких-то метрик которые как-то можно сравнить с чем-то общеизвестным в статье нет
Действительно, метрик в статье нет, поскольку распознавание на каких-то общеизвестных данных не проводилось. Тестировались мы на записях, содержащих специфичные термины, ведь именно ими будут оперировать пользователи ПО. Нам хотелось оценить, распознает ли модель этот самый нефтяной жаргон. Какой-то WER получили, но посчитали, что писать о метрике, полученной на тесте, который есть только у нас, нецелесообразно и лишь введет читателей в заблуждение. На лавры гугла или яндекса и их точность распознавания мы уж точно не заримся :)
Описанная выше задача решается тупо словарем (словарем, Карл!) или н-граммным поиском. Ну или комбинацией этих методов вместе с регулярками.
Мы пробовали подход “мешка слов” и частотный анализ (tf-idf), используя и не используя n-граммы. Они давали на тех же данных результаты гораздо хуже. Например, f1 не больше 66%.
надо попробовать готовые вектора, ну или на крайний случай потыкать FastText.
Готовые векторы мало подходят для такого специфичного домена, поэтому мы и обучали свои. FastText не пробовали применять к этой задаче. Возможно, стоит.
Спасибо за статью, интересный опыт!
Есть желание построить аналогичную систему, но пока нет опыта работы со звуком, поэтому очень интересно изучить чужой end-to-end опыт.
Пока читал возник ряд вопросов, возможно раскроете тему чуть подробнее.
Звук.
1.1. Сколько часов аудио использовалось для тренировки акустической модели, чтобы достичь удовлетворительного результата?
1.2. Какая модель использовалась для акустической модели? Почему именно она?
1.3. Чем пользовались для создания разметки для звуковой модели?
Языковая модель.
2.1. Как строили языковую модель?
2.2. Каков был объем датасета?
2.3. Почему не использовали большие корпусы типа википедии?
2.4. Насколько могу судить для того, чтобы составить окончательный текст по звуку, вам было необходимо использовать beam search(или что-то аналогичное), чтобы составить "решетку гипотез." Можете это подтвердить или опровергнуть? Очень интересно, что именно вы для этого использовали и почему.
Выделение смыслов.
3.1 Почему вы использовали именно этот вариант ембединга StarSpace, почему не FastText или предтренированный BERT. Очень интересны мотивы вашего выбора.
3.2 В классификации намерений, немного странным выглядит, то что метрики для классов: "Приветствие", "Отрицание", "Подтверждение" — ниже, чем для других. Как мне кажется, это наиболее простые классы для классфикации. Можете как-то прокомментировать?
3.4 Каковы мотивы выбора CRF для NER? Не самое популярное решение.
Диалог с пользователем.
4.1 Насколько могу судить по картинке из статьи, ваша система поддержиает диалог с пользователем, а значит нужна отдельная модель для отслеживания статуса диалога. Можете рассказать что использовали, как тренировали, каков был объем выбрки итд?
За ранее спасибо, если ответите хотя бы на часть вопросов!
Звук.
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 модель сработала и верно выделила город, наш бот теперь будет знать контекст, и в следующем вопросе “А дождь сегодня будет?” уточнять локацию уже не нужно.
Как создать голосового помощника на основе технологий с открытым кодом, не передав вовне ни байта секретной информации