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

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

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

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

ИМХО, Яндекс просто обязан сделать себе голосовой движок. Таков тренд поисковиков — переход на голосовой диалоговый интерфейс.
Так русский TTS уже есть в Windows Phone 8. Другой вопрос — его качество.
Вообще я встроенное имел ввиду :)

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

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

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

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

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

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

Вообще, в целом область сейчас развивается очень быстро, очень сложно зафиксировать state of the art. Думаю, учебники появятся, когда будет очередное затишье :)
Скажите, ну почему что Яндекс, что Гугль, что Эппл — все делают голосовой ввод, и хоть бы один сделал переделку MP3 в текст. В чем принципиальная разница?
гугл точно умеет — у меня в приложении используется. Правда не мп3, а флак
В смысле просто распознать речь, записанную в файл? Конечно, разницы нет; как правильно говорят ниже, вопрос в наличии HTTP API.
Очень интересует реализация HTTP API, а еще больше — качественный синтез русской речи
Сколько ни пробовал Яндекс-навигатору голосом адрес сказать — ни единого раза не сработало. При этом гугл-навигатор обычно работает (на том же телефоне) прекрасно. Можете пояснить, в чем проблема?
Можно попробовать. Пожалуйста, опишите симптомы: какое у вас устройство, какую версию Навигатора вы используете, что говорите в микрофон, и что вам возвращает наше распознавание. Можно в личку. Спасибо.
Galaxy Nexus. Версию последнюю, надо полагать. Говорю адрес (улица, дом), либо ключевое слово (например, «лукойл»). В более чем половине случаев до распознавания дело даже и не доходит — телефон сообщает мне что я не был услышан и должен повторить свою фразу. Быть может, ему мешает уличный шум.

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

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

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

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

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

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

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

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

Или всё-таки целевой выход бинарный — единичка для конкретного сенона, нули для всех остальных?
Если второе — то интересно, насколько качественной получилась автоматическая разметка. Т.е. вы же в таком случае наверняка проверяли качество (выборочными проверками), каков де-факто получился % ошибочной разметки сенонов (т.е. по сути — каков теоретический предел результата работы нейросети при такой разметке)? На моём опыте, автоматическая разметка работает относительно неплохо, пока речь идет про десятки объектов с резко различными фичами. А когда их 4к — качество автоматической разметки по идее будет весьма посредственным, что ессно резко лимитирует качество обучения/работы нейросети — а, значит, и работы всей системы.
Можно и так, и так. Если делать Forward-Backward, будет оценка вероятности для каждого, если Viterbi, то бинарно. На практике Viterbi обычно вполне достаточно, есть соответствующие статьи. Конечно, ошибки случаются (хотя измерить точную величину здесь очень сложно, это отдельная большая задача). Но при наличии достаточного объема данных их можно победить.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

September 23, 1997

Location

Россия

Employees

свыше 10000 человек

Registered

9 August 2008