На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Модераторы: RaD, nsh
Страницы: (2) [1] 2  все  ( Перейти к последнему сообщению )  
> Странное поведение Pocketsphinx
    Сегодня провел пару экспериментов по распознаванию команд с помощью Pocketsphinx. Сначала была составлена простая грамматика для установки громкости по шкале от 1-го до 9-ти:
    ExpandedWrap disabled
      #JSGF V1.0;
      grammar command;
      public <command>    = установить громкость <number>;
       
      <number> = один | два | три | четыре | пять | шесть | семь | восемь | девять;

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

    Все хорошо, но хочется, чтобы система могла отличить целевую команду от некоторой произвольной фразы. Для этого можно расширить грамматику, добавив в нее нецелевые слова.
    ExpandedWrap disabled
      #JSGF V1.0;
      grammar command;
      public <command>    = (установить громкость <number>) | <garbage>;
       
      <number> = ноль | один | два | три | четыре | пять | шесть | семь | восемь | девять;
      <garbage> = (январь |
          февраль |
          март  |
          апрель |
          май |
          июнь |
          июль |
          август |
          сентябрь |
          октябрь |
          ноябрь |
          декабрь |
          сегодня |
          вчера |
          завтра |
          утро |
          день |
          вечер)*;

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

    Теперь, самое интересное.
    Тестирование на корпусе с произвольными фразами, в ~95 % случаев возвращало гипотезы из мусорных слов. Т.е. вероятность ложного срабатывания системы на произвольную фразу снизилась до ~5%.

    Тестирование на корпусе с целевыми командами дало 8% ошибок, но странно, не то, что стали возникать ошибки, а то какие это ошибки:

    ExpandedWrap disabled
      Вход:   установить громкость три.wav
      Выход:  установить громкость один
       
      Вход:   установить громкость ноль.wav
      Выход:  установить громкость восемь
       
      и т.д.


    То есть, декодер отработал целевую грамматику, но ошибся в распознавании последнего слова.

    Я могу понять, если бы вместо сказанной команды декодер выдавал гипотезу, построенную из цепочки мусорных слов, но почему он стал ошибаться, когда происходит распознавание по грамматике целевой команды? Разве дополнительные слова оказывают влияние на процесс распознавания, когда рассматривается гипотеза "установить громкость X"?
      Цитата
      Все хорошо, но хочется, чтобы система могла отличить целевую команду от некоторой произвольной фразы. Для этого можно расширить грамматику, добавив в нее нецелевые слова.


      Для этого в Pocketsphinx есть режим обнаружения ключевого слова -kws. Список слов можно передать в файле. Примеров работы много, хотя бы тут: https://mattze96.safe-ws.de/blog/?p=640

      Цитата
      Я могу понять, если бы вместо сказанной команды декодер выдавал гипотезу, построенную из цепочки мусорных слов, но почему он стал ошибаться, когда происходит распознавание по грамматике целевой команды? Разве дополнительные слова оказывают влияние на процесс распознавания, когда рассматривается гипотеза "установить громкость X"?


      Да, так работает алгоритм. Скорее всего задана слишком узкая ширина поиска (-beam, -wbeam, -pbeam, -maxhmmpf) и дополнительные слова мешают найти наилучшее решение. Точность модели на это тоже влияет.
      Сообщение отредактировано: nsh -
        Цитата
        Для этого в Pocketsphinx есть режим обнаружения ключевого слова -kws

        Честно говоря был уверен, что такая возможность есть только в CMU Sphinx 4, видел примеры для Android. В pocketsphinx не нашел ни одного упоминания "kws" в исходниках. Использую Pocketsphinx 0.8, Sphinxbase 0.8.

        Цитата
        Примеров работы много, хотя бы тут: https://mattze96.safe-ws.de/blog/?p=640

        Тут вроде тоже kws'a нет:)

        Цитата

        Да, так работает алгоритм. Скорее всего задана слишком узкая ширина поиска (-beam, -wbeam, -pbeam, -maxhmmpf)

        Спасибо за объяснение, попробую поварьировать ключи
          Цитата
          Тут вроде тоже kws'a нет:)


          Вот тут есть:

          https://github.com/cmusphinx/pocketsphinx/b...est/kws_test.py
            Большое спасибо!
            А правильно ли я понимаю, что распознавание ключевой фразы реализовано только в Java версии библиотеки CMU Sphinx ?
              Цитата
              А правильно ли я понимаю, что распознавание ключевой фразы реализовано только в Java версии библиотеки CMU Sphinx ?


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

                Когда я писал выше:
                Цитата
                В pocketsphinx не нашел ни одного упоминания "kws"

                я имел в виду, что в исходниках библиотеки, которые у меня есть (PocketSphinx 0.8 на C) я не нахожу реализации kws. Вот, например, в документации приведены следующие функции:

                ExpandedWrap disabled
                  POCKETSPHINX_EXPORT int  ps_set_fsg (ps_decoder_t *ps, const char *name, fsg_model_t *fsg)
                    //Adds new search based on finite state grammar.
                   
                  POCKETSPHINX_EXPORT const char *  ps_get_kws (ps_decoder_t *ps, const char *name)
                    //Get the current Key phrase to spot.


                Однако, в распространяемой версии библиотеки, таких строк нет... Вообще документация имеет версию 0.6, но и в PocketSphinx 0.6 данных строк тоже нет?

                Если использовать ключи -keyphrase, -kws_threshold, то они игнорируются. Поведение программ совпадает с тем, как если не указывать данные ключи. В консольном выводе конфигурации данные ключи отсутствуют, т.е. они не то, что не заданы, а их нет совсем.

                Пожалуйста, помогите разобраться. Что я делаю не так? :wall:
                  Поправка. В предыдущей сноске была ошибка:
                  ExpandedWrap disabled
                    POCKETSPHINX_EXPORT const char *  ps_get_kws (ps_decoder_t *ps, const char *name)
                      //Get the current Key phrase to spot.
                     
                    POCKETSPHINX_EXPORT int  ps_set_kws (ps_decoder_t *ps, const char *name, const char *keyphrase)
                      //Adds new keyword to spot.
                    Цитата
                    Пожалуйста, помогите разобраться. Что я делаю не так? :wall:


                    Устаревшую версию программы используете.
                      Большое спасибо, я понял свою ошибку.

                      А каким образом, можно совместить активацию по ключевому слову и распознавание по грамматике? Если подключить грамматику, то декодер уже не обращает внимания на указанное ключевое слово, а мне бы хотелось сначала распознать ключевое слово, а уже за ним некоторую команду, описанную грамматикой.
                        Функция ps_set_search переключает между поиском по ключевому слову и поиску по грамматике. Пример можно посмотреть в

                        https://github.com/cmusphinx/pocketsphinx-a...nxActivity.java
                          Цитата
                          Функция ps_set_search переключает между поиском по ключевому слову и поиску по грамматике

                          Действительно, как я сразу не заметил :blush:

                          Сейчас, я настроил pocketsphinx_continuous на работу по схеме:
                          ExpandedWrap disabled
                            <Ожидание ключевого слова>  =>  <Распознавание команды по грамматике>

                          Причем для определения конца фразы используется встроенный VAD детектор. Тут есть нюансы. В новой версии Pocketsphinx появились ключи по-умолчанию:
                          ExpandedWrap disabled
                            -remove_noise yes
                            -remove_silence yes

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

                          Флаг -remove_silence несколько меня озадачил. Фактически он указывает - будет ли применен VAD для определения речевых кадров, или все кадры будут считаться таковыми по-умолчанию. Но хотелось бы уточнить, правильно ли я понимаю, что в отличии от флага -remove_noise, флаг -remove_silence не влияет на извлеченные признаки, что дает возможность использовать данный флаг как с новыми, так и со старыми акустическими моделями без ущерба качеству распознавания?
                            Цитата
                            Флаг -remove_silence несколько меня озадачил. Фактически он указывает - будет ли применен VAD для определения речевых кадров, или все кадры будут считаться таковыми по-умолчанию. Но хотелось бы уточнить, правильно ли я понимаю, что в отличии от флага -remove_noise, флаг -remove_silence не влияет на извлеченные признаки, что дает возможность использовать данный флаг как с новыми, так и со старыми акустическими моделями без ущерба качеству распознавания?


                            Если remove_silence выключить VAD вообще перестанет работать, лучше его оставить. -remove_noise тоже лучше использовать даже для новых моделей, точность в хороших условиях он не сильно уменьшает, а в присутствии шума помогает.
                              nsh,
                              не могли бы вы дать совет, какие из параметров (-beam, -wbeam, -pbeam, -maxhmmpf) следует менять(увеличивать или уменьшать?) чтобы, оптимизировать распознавание для небольшой грамматики.
                              Ведь изначально они отрегулированы для распознавания произвольных предложений на большом словаре?
                              В каком диапазоне должны лежать их значения?
                              Сообщение отредактировано: AndKy -
                                Цитата
                                не могли бы вы дать совет, какие из параметров (-beam, -wbeam, -pbeam, -maxhmmpf) следует менять(увеличивать или уменьшать?) чтобы, оптимизировать распознавание для небольшой грамматики.


                                Эти и ещё -lw, -silprob, -wip.

                                Цитата
                                >Ведь изначально они отрегулированы для распознавания произвольных предложений на большом словаре?


                                Да

                                Цитата
                                В каком диапазоне должны лежать их значения?


                                +- 50% от значения по умолчанию.
                                1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
                                0 пользователей:


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0421 ]   [ 14 queries used ]   [ Generated: 21.05.24, 12:14 GMT ]