Компания
870,78
рейтинг
22 октября 2013 в 15:57

Разработка → Распознавание речи от Яндекса. Под капотом у Yandex.SpeechKit

imageНа Yet another Conference 2013 мы представили разработчикам нашу новую библиотеку Yandex SpeechKit. Это публичный API для распознавания речи, который могут использовать разработчики под Android и iOS. Скачать SpeechKit, а также ознакомиться с документацией, можно здесь.

Yandex SpeechKit позволяет напрямую обращаться к тому бэкэнду, который успешно применяется в мобильных приложениях Яндекса. Мы достаточно долго развивали эту систему и сейчас правильно распознаем 94% слов в Навигаторе и Мобильных Картах, а также 84% слов в Мобильном Браузере. При этом на распознавание уходит чуть больше секунды. Это уже весьма достойное качество, и мы активно работаем над его улучшением.

image

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



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

I. Основы

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

Предположим, что речь человека состоит из фонем (это грубое упрощение, но в первом приближении оно верно). Определим фонему как минимальную смыслоразличительную единицу языка, то есть звук, замена которого может привести к изменению смысла слова или фразы. Возьмем небольшой участок сигнала, скажем, 25 миллисекунд. Назовем этот участок «фреймом». Какая фонема была произнесена на этом фрейме? На этот вопрос сложно ответить однозначно — многие фонемы чрезвычайно похожи друг на друга. Но если нельзя дать однозначный ответ, то можно рассуждать в терминах «вероятностей»: для данного сигнала одни фонемы более вероятны, другие менее, третьи вообще можно исключить из рассмотрения. Собственно, акустическая модель — это функция, принимающая на вход небольшой участок акустического сигнала (фрейм) и выдающая распределение вероятностей различных фонем на этом фрейме. Таким образом, акустическая модель дает нам возможность по звуку восстановить, что было произнесено — с той или иной степенью уверенности.

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

Теперь у нас есть все инструменты, чтобы сконструировать одну из главных «рабочих лошадок» автоматического распознавания речи — скрытую марковскую модель (HMM, Hidden Markov Model). Для этого на время представим, что мы решаем не задачу распознавания речи, а прямо противоположную — преобразование текста в речь. Допустим, мы хотим получить произношение слова «Яндекс». Пусть слово «Яндекс» состоит из набора фонем, скажем, [й][а][н][д][э][к][с]. Построим конечный автомат для слова «Яндекс», в котором каждая фонема представлена отдельным состоянием. В каждый момент времени находимся в одном из этих состояний и «произносим» характерный для этой фонемы звук (как произносится каждая из фонем, мы знаем благодаря акустической модели). Но одни фонемы длятся долго (как [а] в слове «Яндекс»), другие практически проглатываются. Здесь нам и пригодится информация о вероятности перехода между фонемами. Сгенерировав звук, соответствующий текущему состоянию, мы принимаем вероятностное решение: оставаться нам в этом же состоянии или же переходить к следующему (и, соответственно, следующей фонеме).

image

Более формально HMM можно представить следующим образом. Во-первых, введем понятие эмиссии. Как мы помним из предыдущего примера, каждое из состояний HMM «порождает» звук, характерный именно для этого состояния (т.е. фонемы). На каждом фрейме звук «разыгрывается» из распределения вероятностей, соответствующего данной фонеме. Во-вторых, между состояниями возможны переходы, также подчиняющиеся заранее заданным вероятностным закономерностям. К примеру, вероятность того, что фонема [а] будет «тянуться», высока, чего нельзя сказать о фонеме [д]. Матрица эмиссий и матрица переходов однозначно задают скрытую марковскую модель.

Хорошо, мы рассмотрели, как скрытая марковская модель может использоваться для порождения речи, но как применить ее к обратной задаче — распознаванию речи? На помощь приходит алгоритм Витерби. У нас есть набор наблюдаемых величин (собственно, звук) и вероятностная модель, соотносящая скрытые состояния (фонемы) и наблюдаемые величины. Алгоритм Витерби позволяет восстановить наиболее вероятную последовательность скрытых состояний.

Пусть в нашем словаре распознавания всего два слова: «Да» ([д][а]) и «Нет» ([н'][е][т]). Таким образом, у нас есть две скрытые марковские модели. Далее, пусть у нас есть запись голоса пользователя, который говорит «да» или «нет». Алгоритм Витерби позволит нам получить ответ на вопрос, какая из гипотез распознавания более вероятна.

Теперь наша задача сводится к тому, чтобы восстановить наиболее вероятную последовательность состояний скрытой марковской модели, которая «породила» (точнее, могла бы породить) предъявленную нам аудиозапись. Если пользователь говорит «да», то соответствующая последовательность состояний на 10 фреймах может быть, например, [д][д][д][д][а][а][а][а][а][а] или [д][а][а][а][а][а][а][а][а][а]. Аналогично, возможны различные варианты произношения для «нет» — например, [н'][н'][н'][е][е][е][е][т][т][т] и [н'][н'][е][е][е][е][е][е][т][т]. Теперь найдем «лучший», то есть наиболее вероятный, способ произнесения каждого слова. На каждом фрейме мы будем спрашивать нашу акустическую модель, насколько вероятно, что здесь звучит конкретная фонема (например, [д] и [а]); кроме того, мы будем учитывать вероятности переходов ([д]->[д], [д]->[а], [а]->[а]). Так мы получим наиболее вероятный способ произнесения каждого из слов-гипотез; более того, для каждого из них мы получим меру, насколько вообще вероятно, что произносилось именно это слово (можно рассматривать эту меру как длину кратчайшего пути через соответствующий граф). «Выигравшая» (то есть более вероятная) гипотеза будет возвращена как результат распознавания.

Алгоритм Витерби достаточно прост в реализации (используется динамическое программирование) и работает за время, пропорциональное произведению количества состояний HMM на число фреймов. Однако не всегда нам достаточно знать самый вероятный путь; например, при тренировке акустической модели нужна оценка вероятности каждого состояния на каждом фрейме. Для этого используется алгоритм Forward-Backward.

Однако акустическая модель — это всего лишь одна из составляющих системы. Что делать, если словарь распознавания состоит не из двух слов, как в рассмотренном выше примере, а из сотен тысяч или даже миллионов? Многие из них будут очень похожи по произношению или даже совпадать. Вместе с тем, при наличии контекста роль акустики падает: невнятно произнесенные, зашумленные или неоднозначные слова можно восстановить «по смыслу». Для учета контекста опять-таки используются вероятностные модели. К примеру, носителю русского языка понятно, что естественность (в нашем случае — вероятность) предложения «мама мыла раму» выше, чем «мама мыла циклотрон» или «мама мыла рама». То есть наличие фиксированного контекста «мама мыла ...» задает распределение вероятностей для следующего слова, которое отражает как семантику, так и морфологию. Такой тип языковых моделей называется n-gram language models (триграммы в рассмотренном выше примере); разумеется, существуют куда более сложные и мощные способы моделирования языка.

II. Что под капотом у Yandex ASR?

Теперь, когда мы представляем себе общее устройство систем распознавания речи, опишем более подробно детали технологии Яндекса — лучшей, согласно нашим данным, системы распознавания русской речи.
При рассмотрении игрушечных примеров выше мы намеренно сделали несколько упрощений и опустили ряд важных деталей. В частности, мы утверждали, что основной «строительной единицей» речи является фонема. На самом деле фонема — слишком крупная единица; чтобы адекватно смоделировать произношение одиночной фонемы, используется три отдельных состояния — начало, середина и конец фонемы. Вместе они образуют такую же HMM, как представлена выше. Кроме того, фонемы являются позиционно-зависимыми и контекстно-зависимыми: формально «одна и та же» фонема звучит существенно по-разному в зависимости от того, в какой части слова она находится и с какими фонемами соседствует. Вместе с тем, простое перечисление всех возможных вариантов контекстно-зависимых фонем вернет очень большое число сочетаний, многие из которых никогда не встречаются в реальной жизни; чтобы сделать количество рассматриваемых акустических событий разумным, близкие контекстно-зависимые фонемы объединяются на ранних этапах тренировки и рассматриваются вместе.
Таким образом, мы, во-первых, сделали фонемы контекстно-зависимыми, а во-вторых, разбили каждую из них на три части. Эти объекты — «части фонем» — теперь составляют наш фонетический алфавит. Их также называют сенонами. Каждое состояние нашей HMM — это сенон. В нашей модели используется 48 фонем и около 4000 сенонов.

Итак, наша акустическая модель все так же принимает на вход звук, а на выходе дает распределение вероятностей по сенонам. Теперь рассмотрим, что конкретно подается на вход. Как мы говорили, звук нарезается участками по 25 мс («фреймами»). Как правило, шаг нарезки составляет 10 мс, так что соседние фреймы частично пересекаются. Понятно, что «сырой» звук — амплитуда колебаний по времени — не самая информативная форма представления акустического сигнала. Спектр этого сигнала — уже гораздо лучше. На практике обычно используется логарифмированный и отмасштабированный спектр, что соответствует закономерностям человеческого слухового восприятия (Mel-преобразование). Полученные величины подвергаются дискретному косинусному преобразованию (DCT), и в результате получается MFCC — Mel Frequency Cepstral Coefficients. (Слово Cepstral получено перестановкой букв в Spectral, что отражает наличие дополнительного DCT). MFCC — это вектор из 13 (обычно) вещественных чисел. Они могут использоваться как вход акустической модели «в сыром виде», но чаще подвергаются множеству дополнительных преобразований.

Тренировка акустической модели — сложный и многоэтапный процесс. Для тренировки используются алгоритмы семейства Expectation-Maximization, такие, как алгоритм Баума-Велша. Суть алгоритмов такого рода — в чередовании двух шагов: на шаге Expectation имеющаяся модель используется для вычисления матожидания функции правдоподобия, на шаге Maximization параметры модели изменяются таким образом, чтобы максимизировать эту оценку. На ранних этапах тренировки используются простые акустические модели: на вход даются простые MFCC features, фонемы рассматриваются вне контекстной зависимости, для моделирования вероятности эмиссии в HMM используется смесь гауссиан с диагональными матрицами ковариаций (Diagonal GMMs — Gaussian Mixture Models). Результаты каждой предыдущей акустической модели являются стартовой точкой для тренировки более сложной модели, с более сложным входом, выходом или функцией распределения вероятности эмиссии. Существует множество способов улучшения акустической модели, однако наиболее значительный эффект имеет переход от GMM-модели к DNN (Deep Neural Network), что повышает качество распознавания практически в два раза. Нейронные сети лишены многих ограничений, характерных для гауссовых смесей, и обладают лучшей обобщающей способностью. Кроме того, акустические модели на нейронных сетях более устойчивы к шуму и обладают лучшим быстродействием.

Нейронная сеть для акустического моделирования тренируется в несколько этапов. Для инициализации нейросети используется стек из ограниченных машин Больцмана (Restricted Boltzmann Machines, RBM). RBM — это стохастическая нейросеть, которая тренируется без учителя. Хотя выученные ей веса нельзя напрямую использовать для различения между классами акустических событий, они детально отражают структуру речи. Можно относиться к RBM как к механизму извлечения признаков (feature extractor) — полученная генеративная модель оказывается отличной стартовой точкой для построения дискриминативной модели. Дискриминативная модель тренируется с использованием классического алгоритма обратного распространения ошибки, при этом применяется ряд технических приемов, улучшающих сходимость и предотвращающих переобучение (overfitting). В итоге на входе нейросети — несколько фреймов MFCC-features (центральный фрейм подлежит классификации, остальные образуют контекст), на выходе — около 4000 нейронов, соответствующих различным сенонам. Эта нейросеть используется как акустическая модель в production-системе.

image

Рассмотрим подробнее процесс декодирования. Для задачи распознавания спонтанной речи с большим словарем подход, описанный в первой секции, неприменим. Необходима структура данных, соединяющая воедино все возможные предложения, которые может распознать система. Подходящей структурой является weighted finite-state transducer (WFST) — по сути, просто конечный автомат с выходной лентой и весами на ребрах. На входе этого автомата — сеноны, на выходе — слова. Процесс декодирования сводится к тому, чтобы выбрать лучший путь в этом автомате и предоставить выходную последовательность слов, соответствующую этому пути. При этом цена прохода по каждой дуге складывается из двух компонент. Первая компонента известна заранее и вычисляется на этапе сборки автомата. Она включает в себя стоимость произношения, перехода в данное состояние, оценку правдоподобия со стороны языковой модели. Вторая компонента вычисляется отдельно для конкретного фрейма: это акустический вес сенона, соответствующего входному символу рассматриваемой дуги. Декодирование происходит в реальном времени, поэтому исследуются не все возможные пути: специальные эвристики ограничивают набор гипотез наиболее вероятными.

Разумеется, наиболее интересная с технической точки зрения часть — это построение такого автомата. Эта задача решается в оффлайне. Чтобы перейти от простых HMM для каждой контекстно-зависимой фонемы к линейным автоматам для каждого слова, нам необходимо использовать словарь произношений. Создание такого словаря невозможно вручную, и здесь используются методы машинного обучения (а сама задача в научном сообществе называется Grapheme-To-Phoneme, или G2P). В свою очередь, слова «состыковываются» друг с другом в языковую модель, также представленную в виде конечного автомата. Центральной операцией здесь является композиция WFST, но также важны и различные методы оптимизации WFST по размеру и эффективности укладки в памяти.

image

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

В заключение коснемся вопроса о метриках качества систем распознавания речи. Наиболее популярна метрика Word Error Rate (и обратная ей Word Accuracy). По существу, она отражает долю неправильно распознанных слов. Чтобы рассчитать Word Error Rate для системы распознавания речи, используют размеченные вручную корпуса голосовых запросов, соответствующих тематике приложения, использующего распознавание речи.

Литература по теме:

1. Mohri, M., Pereira, F., & Riley, M. (2008). Speech recognition with weighted finite-state transducers. In Springer Handbook of Speech Processing (pp. 559-584). Springer Berlin Heidelberg.
2. Hinton, G., Deng, L., Yu, D., Dahl, G. E., Mohamed, A. R., Jaitly, N. et al. (2012). Deep neural networks for acoustic modeling in speech recognition: The shared views of four research groups. Signal Processing Magazine, IEEE, 29(6), 82-97.
3. Jurafsky D., Martin J.H. (2008) Speech and language processing, 2nd edition. Prentice Hall.
Автор: @iliia
Яндекс
рейтинг 870,78

Комментарии (60)

  • +8
    Ну наконец-то, в первый раз на хабре вижу в ссылках имя Mohri, написанное не мной :). Риспект. Но все же яндекс очень отстает в ASR. Во-первых, ничего не сказано про языковые модели. Скорей всего вы делаете это старыми добрыми n-gramm'ами, но RNN-модели работают гораздо лучше. Во-вторых, после RBM уже появилось довольно много способов тренировки «глубокой» нейронной сети. Странно что у нас почти нет статей на эту тему. В тетьих — появляются медоды получения фич минуя MFCC и прочие костыли. Вы это пробовали?
    Спасибо.
    • +5
      Спасибо за комментарий!

      Действительно, про языковые модели в статье сказано мало. В качестве основной используется n-gramная модель (потому что легко трансформируется в WFST), но для рескоринга применяются более сложные модели, одна из них, действительно — рекуррентные нейросети.
      Что до RBM, то это, понятно, только инициализация. Собственно детали тренировки касаются как структуры нейросети, так и параметров обучения (momentum, dropout, и т.д.). Мы сейчас активно работаем над оптимизацией этих параметров, но текущая реализация, разумеется, включает в себя все эти детали.
      Что до фич, то в принципе можно использовать просто Mel-filterbank'и. И даже есть много статей, что они не уступают по качеству MFCC, если использовать DNN. Но наши эксперименты показывают, что наоборот, более сложные фичи (поверх MFCC) дают определенное преимущество.

      И да, по качеству распознавания мы уже не отстаем ;) Можете сами проверить в Навигаторе или Мобильном Браузере.
      • +3
        По качеству, вы бы меня убедили, участвуюя в соответсвующих контестах.
        Но в любом случае, из вашего ответа, все не так уж плохо. Удачи в вашем деле!
      • +3
        Еще добавлю, что RNN работают довольно хорошо, как по качеству, так и по скорости декодинга. Если интересно, могу опубликоват свою модель на github (тренировал на википедии). Минус в том, что тренируются очень медленно, но если задействовать GPU, то все не так уж плохо.
        • +5
          Очень интересно. А у вас реализация с LSTM или без?

          Не обещаю, что мы воспользуемся вашими наработками (и в любом случае свяжемся с вами отдельно, если захотим), но уверен, что сообществу пойдет на пользу публикация кода. Поэтому идею вашу целиком и полностью поддерживаю :)
          • +2
            Я пробовал LSTM для сглаживания градиента. Но эффект был незначительный. Не исключаю, что я где-то ошибся :). Но гораздо более интересно, что методы ESN работают очень неплохо. Попробуйте в рекуррентной сети нормализовать hidden-to-hidden matrix на спектральный радиус. Наверняка произойдет прирост в качестве.
            • +2
              Спасибо за совет, подумаем в этом направлении :)
  • +2
    А как насчет немобильных приложений?
    • +5
      Мы думаем об открытии HTTP API.
      • +2
        Какие сроки ожидать? Сейчас реинженерить компоненты под андроид и iOS не стоит? Быстрее не получится?
        • +1
          HTTP API находится в закрытом тесте. Если хотите присоединиться, пишите на speechkit@yandex-team.ru. Пожалуйста, укажите ожидаемый объем запросов в сутки, а также для каких целей планируете использовать.
      • 0
        а что-нибудь офлайновое не планируется?
        А то я тут, вот, например, строю умный дом, а у CMU-Sphinx с русским как-то хреновато :(
        У гугла — тоже только HTTP API (плюс андроидоприложение так же). А хотелось бы что-нибудь линуксооффлайновое. Вообще, в идеале — опенсорсное, но все всё понимают, что корпорациям нет мотивации отдавать подобные наработки в опенсорс :(
  • 0
    А планирует ли Яндекс выпустить движок для воспроизведения речи на русском? Ведь Speech — это не сколько распознавание, сколько сама речь.
    • +2
      конкретные детали раскрывать не могу, но идея хорошая :)
      • +1
        Еще нужно помнить, что генератор русской речи встроен в базовую Windows 8.1 и доступно даже на WinRT (если не ошибаюсь), а в ближайшем будущем будет доступен на WinPhone.

        ИМХО, Яндекс просто обязан сделать себе голосовой движок. Таков тренд поисковиков — переход на голосовой диалоговый интерфейс.
  • +1
    Насчет лучшей системы распознавания русской речи, вопрос спорный. Чтобы так заявлять, нужны конкретные цифры в сравнении с другими системами. Мне например, нравятся как работают на новостях вот эти ребята — voxaleadnews.labs.exalead.com/. Надо выбрать русский язык, и поискать по ключевым словам. Вот пример — bit.ly/H83HhS
    • +1
      Разумеется, мы сравниваем по нашей тематике — поиск в интернете (Мобильный Браузер) и геозапросы (Карты и Навигатор). Цифры для нашей системы приведены в посте; что касается других систем, то открытые данные, которые можно найти в статьях, сообщают о WER в диапазоне 15-20% для общего поиска (для английского языка). Видно, что мы как минимум попадаем в этот диапазон.

      Распознавание новостей — конечно, тоже интересная и важная задача, но, как вы понимаете, там используется адаптированная именно к новостям языковая модель, да и акустика имеет свои особенности (относительно мало внешнего шума, большинство говорящих — профессиональные журналисты или дикторы).
  • +3
    Молодцы, конечно, но.
    Мне вот всегда было интересно, с чего собственно взяли авторы подобных алгоритмов, что задача распознавания голоса в общем случае вообще имеет годное для практики решение?
    Люди тоже распознают далеко не 100% сказанного: часто переспрашивают, часто понимают неверно, часто просто пропускают мимо ушей, ещё очень часто ошибки распознавания приходятся на несущественные детали, которые просто опускаются. Собственно, именно из-за этого голосовое общение людей между собой на 99.9% — это малозначимый трёп. Все более-менее важное, значимое и/или требующее точного восприятия передается письменно.
    В случае же распознавания голоса машиной юз-кейс совершенно иной: человек отдает команды или запросы, которые обязательно должны быть распознаны идеально точно. Люди не привыкли терпеть ошибки тупой железки, скорее наоборот, привыкли не терпеть.
    • 0
      Конечно, вы отчасти правы. Есть приложения, где необходима стопроцентная точность: например, диктовка юридических документов. Вероятно, там мы увидим распознавание речи нескоро.

      Вместе с тем, есть очень много практических приложений, когда распознавание речи очень полезно: простейший пример — использование автомобильного навигатора, когда руки заняты. Другие известные приложения — системы «умный дом», автоматические колл-центры; нет никаких препятствий, чтобы использовать эту технологию для заказов в магазинах или ресторанах (и мы будем рады, если наш SpeechKit поможет реализации такой идеи).

      И, конечно, совершенно отдельный разговор — люди с ограниченными возможностями по зрению. Для них технологии распознавания и синтеза речи буквально открывают новый мир.
      • 0
        Навигация и умный дом — сильно ограниченные подзадачи, там всего десятки подлежащих распознаванию фраз (по сравнению с десятками тысяч в общем случае). Но и тут шутки про качество распознавания уже пополнили арсеналы комиков. Все эти игры будут продолжаться, пока какого-нибудь производителя систем распознавания для навигации не засудят за ошибку этого распознавания, повлекшую смерть какого-нибудь американца.
        Автоматические кол-центры ознаменуют окончательный конец эпохи телефонии (начало этого конца ознаменовано IVR).
        Инвалиды по зрению — да, но им многократно важнее синтез, который в общем-то задача давно решенная с достаточным качеством. Почти на всех нормальных клавиатурах есть пупырки, позволяющие вводить текст «слепым десятипальцевым» методом даже действительно слепым людям.
        В-общем, 15 лет назад Dragon Dictate так же рапортовал об over 85% точности и совершенно ничего не добился.
        • 0
          Ваши аргументы вполне разумны. Тем не менее, нашей системой пользуется много людей (делаются миллионы запросов в неделю), а значит, она удовлетворяет реальную потребность :)

          Что до систем пятнадцатилетней давности, то они решали совсем другую задачу — распознавание команд из весьма ограниченного набора, а не распознавание спонтанной речи со словарем в сотни тысяч слов.
    • 0
      Совсем необязательно команды или запросы. Это могут быть заметки или напоминалки для самого человека. Точно распознать нужно только «хидеры» — это команды, а для остального особая точность не нужна — напишет «карова» и так понятно будет. Или «итак» вместо «и так».
    • 0
      Насчёт 99.9% — полная чушь. Или Вы инвалид по слуху или намеренно сгущаете краски. В чём то я с Вами согласен — процентов 20 — 30 куда ни шло, но 99.9% — явный перебор! Опять же, малозначимый трёп уже неплохо, ибо означает, что нет острых углов и информация худо-бедно распознаётся корректно, иначе люди давно поубивали бы друг друга за простые слова приветствия или вопрос о времени думая, что слышат угрозы или оскорбления.
  • +2
    Интересно, а есть уже доступный сообществу софт, реализующий DNNs вместо GMMs?
    А то HTK и Sphinx такой фичи не предлагают, к сожалению.
    • +1
      Странно, что уважаемый автор поста, очень технически грамотного, проигнорировал такой простой вопрос.
      Ведь ему совершенно точно должно быть известно про open-source проект Kaldi, в котором реализованы все без исключения вышеперечисленные технологии и еще масса всего нового.
      Более того, после пары недель возни с документацией и скриптами любой, у кого есть аналогичная база для обучения, способен построить с помощью Kaldi акустические модели сравнимого качества.
      Конечно, реализация собственного декодера на базе технологии WFST требует определенных усилий, но такой декодер в Kaldi тоже присутствует, и сделать свой по образу и подобию технически продвинутой компании большого труда не составит.
      • 0
        О, Kaldi! Что-то о нем слышал.
  • +2
    А как насчет других платформ? Планируется ли выпуск библиотеки, например, под Linux?
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Ну как вам сказать. В части HMM практически не устарел. В остальных — к сожалению, да, хотя книга остается хорошим, основательным, вводным пособием.

      С другой стороны, хороший неустаревший учебник сходу я даже не назову. Неплохой обзор от 2008 года есть в Jurafsky&Martin, но там всего 4 главы посвящено собственно речи, да и такие ключевые на сегодняшний день технологии, как WFST и DNN, в контексте распознавания речи не упоминаются.

      Вообще, в целом область сейчас развивается очень быстро, очень сложно зафиксировать state of the art. Думаю, учебники появятся, когда будет очередное затишье :)
  • 0
    А появится ли всё это в ваших приложениях для windows phone?
    • +1
      Да, конечно. Скоро все будет, в том числе SpeechKit.
  • 0
    Яндекс, сделай мне бутерброд!
    • +4
      Без sudo не работает.
      • 0
        sudo сделай мне бутерброд!
  • 0
    Скажите, ну почему что Яндекс, что Гугль, что Эппл — все делают голосовой ввод, и хоть бы один сделал переделку MP3 в текст. В чем принципиальная разница?
    • 0
      гугл точно умеет — у меня в приложении используется. Правда не мп3, а флак
    • 0
      В смысле просто распознать речь, записанную в файл? Конечно, разницы нет; как правильно говорят ниже, вопрос в наличии HTTP API.
      • +1
        Я как-то уже выкладывал на Хабрахабр пример использования Google Voice Search c обычными wav-файлами.
  • +1
    Очень интересует реализация HTTP API, а еще больше — качественный синтез русской речи
  • –1
    Сколько ни пробовал Яндекс-навигатору голосом адрес сказать — ни единого раза не сработало. При этом гугл-навигатор обычно работает (на том же телефоне) прекрасно. Можете пояснить, в чем проблема?
    • +1
      Можно попробовать. Пожалуйста, опишите симптомы: какое у вас устройство, какую версию Навигатора вы используете, что говорите в микрофон, и что вам возвращает наше распознавание. Можно в личку. Спасибо.
      • +1
        Galaxy Nexus. Версию последнюю, надо полагать. Говорю адрес (улица, дом), либо ключевое слово (например, «лукойл»). В более чем половине случаев до распознавания дело даже и не доходит — телефон сообщает мне что я не был услышан и должен повторить свою фразу. Быть может, ему мешает уличный шум.

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

        PS: Как забавно реагируют тут на баг-репорты, в этом топике добра мой комментарий единственный удостоился минусов.
        • +1
          Да, странное поведение. Шум не должен мешать, по крайней мере, настолько (мы проводили тесты в разных условиях). Похоже, дело именно в специфике вашего устройства (или, что менее вероятно, интернет-соединения). А какая у вас локаль, кстати?

          Пожалуйста, пришлите в личку ваш e-mail. Мы свяжемся с коллегами из Навигатора и постараемся вместе решить вашу проблему.

          И спасибо за багрепорт :)
          • 0
            Локаль? Интересная мысль, ибо оно у меня английское (так компактнее) и я был несколько удивлен когда после недавнего обновления навигатор со мной начал разговаривать исключительно на английском (до обновления он говорил по русски безотносительно локали), при этом не имея возможности переключения языка внутри приложения. Теперь загадка (русский навигатор в россии разговаривает исключительно по английски) похоже разрешилась.
            • +1
              Тогда, кажется, все понятно. Ваши голосовые запросы до нас просто не доходят (на английской локали сейчас включается встроенное андроидное распознавание). Если на русской локали все равно не будет работать, пишите, будем разбираться.
  • +1
    Пробовал ваш движок в Яндекс навигаторе. Распознаёт очень хорошо.

    Жаль только на ходу шум машины мешает распознаванию — как определению конца фразы, так и самому анализу. Но это ни в коем случае не жалоба, это может быть вообще недостаток телефонного микрофона, из которого любой фильтрацией не вычленишь достаточно полезной информации при шуме, а в хороших и средних условиях всё работает отлично.
    • +2
      Спасибо! По поводу распознавания в условиях очень сильного шума — мы знаем об этой проблеме и уже в определенной степени продвинулись в ее решении. Конечно, это затрагивает пограничные случаи, когда и человек не всегда справляется с задачей распознавания.
    • 0
      Насчёт шума машины могу подсказать хоть и не решение, но некоторый обход проблемы — использовать гарнитуру.
  • 0
    А как насчет офлайн распознавания? Планируется ли реализовать такое, как например в Android?
    • +2
      Мы думаем об этом.
      • +1
        Если бы его реализовали под Linux и Windows — то отбоя бы не было от желающих им воспользоваться или даже купить, если цена будет не такая как у компании Nuance.
        • 0
          Поддерживаю предыдущего оратора. Особенно хочется консольную либу для linux.
  • 0
    Тренировка итоговой нейросети градиентным спуском (где на входе поданы фичи полученные от MFCC) требует соответствующей разметки, т.е. гигантской базы данных — со звуковым потоком, размеченным на эти 4000 сенонов.
    Собственно, основная проблема — это не обучение нейросетей (или других алгоритмов), а собственно создание и корректная разметка такой БД. Это как раз и есть ключевой этап, и если он выполнен хорошо — то даже посредственные алгоритмы дадут приемлемый результат, а если выполнен плохо — то не помогут никакие ухищрения.
    Какой размер (т.е. какое кол-во размеченных сенонов) используется при тренировке градиентным спуском итоговой нейросети? Если сенонов 4к, то БД должна быть как минимум на 3 порядка больше (т.е. 1000 образцов каждого сенона), т.е. это минимум — миллионы размеченных фреймов… Вы эту БД вручную размечали, или как? )))

    Вопросы вызван тем, что есть у меня в загашнике разработанный алгоритм, который по сути формирует нейросеть — но такую, что ей не важна размерность входных данных (входной вектор может быть хоть в 10 000 цифр, не существенно — и отсутствует пресловутое «проклятие размерности»), и такую, у которой принципиально нет проблем с локальными экстремумами — гарантированно сходится в глобальный экстремум. Так что и нет необходимости в костылях типа MFCC, и как следствие — нет потерь информации (при редуцировании размерности входных данных — чему и служит MFCC), так что качество распознавания приближается к теоретическому пределу. Но всё это — требует соответственно гигантского набора размеченных образцов (иначе обобщение может носить произвольный характер — далекий от реальности). Так что в своё время я этим алгоритмом наигрался (на базе TIMIT — получал отличные результаты, но база явно была слишком мала для меня), понял что потребные мне БД размеченных образов просто не существуют в природе, и забросил эту тему… Но вы как-то решили проблему разметки гигантской БД для обучения сети. Как, если не секрет?
    • +2
      Expectation-M aximization как раз и нужен, чтобы вручную все не размечать. Действуем итеративно: начинаем с reasonable guess (например, равномерного выравнивания), дальше на каждом шаге делаем realignment. Начинаем с простых GMM моделей для простых фонем, потом постепенно усложняем модель и целевые параметры. В итоге получаем выравнивание приемлемого качества, выбрасываем все остальное и переходим на нейронки.

      Размер тренировочной базы — порядка 300 часов.
      • 0
        По идее, чисто автоматическая разметка может дать лишь вероятности того, что фрейм принадлежит тому или иному сенону.

        Правильно ли я понимаю, что в качестве целевого выхода нейросети (при итоговом обучении градиентным спуском) подается не конкретный сенон (единичка на одном выходе, и нули на всех остальных 4-х тысячах выходов), а вероятности для каждого сенона (полученные на базе статистического моделирования)? Т.е. по сути производится не дискретная — а вероятностная разметка сенонов (точнее даже не разметка — а статистическое предположение о принадлежности данного фрейма к тому или иному сенону)?

        Или всё-таки целевой выход бинарный — единичка для конкретного сенона, нули для всех остальных?
        Если второе — то интересно, насколько качественной получилась автоматическая разметка. Т.е. вы же в таком случае наверняка проверяли качество (выборочными проверками), каков де-факто получился % ошибочной разметки сенонов (т.е. по сути — каков теоретический предел результата работы нейросети при такой разметке)? На моём опыте, автоматическая разметка работает относительно неплохо, пока речь идет про десятки объектов с резко различными фичами. А когда их 4к — качество автоматической разметки по идее будет весьма посредственным, что ессно резко лимитирует качество обучения/работы нейросети — а, значит, и работы всей системы.
        • 0
          Можно и так, и так. Если делать Forward-Backward, будет оценка вероятности для каждого, если Viterbi, то бинарно. На практике Viterbi обычно вполне достаточно, есть соответствующие статьи. Конечно, ошибки случаются (хотя измерить точную величину здесь очень сложно, это отдельная большая задача). Но при наличии достаточного объема данных их можно победить.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка