Возможны ли динамические n-граммы в CMU sphinx?

[w3264]

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

[nsh]

Встроить несложно, нужно модифицировать функцию ngram_ng_score, она простая. На входе n-грамма, на выходе - вероятность. Если сочетаемости нет, вероятность можно понижать.

[w3264]

Спасибо, теперь буду знать где смотреть.

Чтобы не плодить темы буду в этой ветке писать вопросы)

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

Построили свою модельку, в ней около 5 тысяч словоформ, 500 лексем,
правда в ней в основном просто слова, 2-грамм и 3-грамм совсем мало...
Работа декодера даже по ней пока тоже не приводит в восторг.

1) 'как дела' - выдает как 2ю-3ю альтернативу, на первом месте слово 'дела', хотя фраза есть как явная 2-грамма.
в какую сторону копать, чтобы это починить?

2) при построении модели idngram2lm выдает кучу предупреждений, которые привожу ниже.
что они означают, насколько серьезны и как это победить?)

n : 3
Input file : corpus.idngram (ascii format)
Output files :
ARPA format : corpus.lm
Vocabulary file : corpus.vocab
Cutoffs :
2-gram : 0 3-gram : 0
Vocabulary type : Closed
Minimum unigram count : 0
Zeroton fraction : 1
Counts will be stored in two bytes.
Count table size : 65535
Discounting method : Good-Turing
Discounting ranges :
1-gram : 1 2-gram : 7 3-gram : 7
Memory allocation for tree structure :
Allocate 100 MB of memory, shared equally between all n-gram tables.
Back-off weight storage :
Back-off weights will be stored in four bytes.
Reading vocabulary.
read_wlist_into_siht: a list of 5445 words was read from "corpus.vocab".
read_wlist_into_array: a list of 5445 words was read from "corpus.vocab".
WARNING: <s> appears as a vocabulary item, but is not labelled as a
context cue.
Allocated space for 5000000 2-grams.
Allocated space for 12500000 3-grams.
Allocated 50000000 bytes to table for 2-grams.
Allocated 50000000 bytes to table for 3-grams.
Processing id n-gram file.
20,000 n-grams processed for each ".", 1,000,000 for each line.

Calculating discounted counts.
Warning : 1-gram : Discounting range of 1 is equivalent to excluding
singletons.
Warning : 2-gram : GT statistics are out of range; lowering cutoff to 6.
Warning : 2-gram : GT statistics are out of range; lowering cutoff to 5.
Warning : 2-gram : GT statistics are out of range; lowering cutoff to 4.
Warning : 2-gram : Some discount values are out of range;
lowering discounting range to 3.
Warning : 2-gram : GT statistics are out of range; lowering cutoff to 2.
Warning : 3-gram : GT statistics are out of range; lowering cutoff to 6.
Warning : 3-gram : GT statistics are out of range; lowering cutoff to 5.
Warning : 3-gram : GT statistics are out of range; lowering cutoff to 4.
Warning : 3-gram : Some discount values are out of range;
lowering discounting range to 3.
Warning : 3-gram : GT statistics are out of range; lowering cutoff to 2.
Unigrams's discount mass is 0.332518 (n1/N = 0.332518)
Unigram was renormalized to absorb a mass of 0.332518
prob[UNK] = 1e-099
Incrementing contexts...
Calculating back-off weights...
Warning : P( 2633 ) == 0
Warning : P( 1 ) == 0
Warning : P( 2 ) == 0
Warning : P( 3 ) == 0
Warning : P( 4 ) == 0
Warning : P( 5 ) == 0
Warning : P( 6 ) == 0
Warning : P( 7 ) == 0
Warning : P( 8 ) == 0
Warning : P( 9 ) == 0
Warning : P( 10 ) == 0
Warning : P( 11 ) == 0
Warning : P( 12 ) == 0
Warning : P( 13 ) == 0

Сообщение отредактировано: w3264 - 26.11.15, 13:52

[nsh]

Цитата

'как дела' - выдает как 2ю-3ю альтернативу, на первом месте слово 'дела', хотя фраза есть как явная 2-грамма.
в какую сторону копать, чтобы это починить?

В работе системы распознавания речи на первом плане акустические детекторы, они фильтруют гипотезы распознавания, затем уже подключается языковая модель. Если акустические детекторы не работают, языковая модель не поможет, до неё нужные слова просто не доходят. Есть много причин, по которым распознавание неточно. Например, в словаре неправильно указано произношение. Довольно часто встречается проблема распознавания коротких фраз. В декодере используется нормализация по громкости, которая для коротких фраз в начале распознавания не даёт точных результатов. Необходимо правильно задавать параметры канала с помощью ключа -cmninit, чтобы первая фраза распознавалась корректно. Начиная со второй фразы распознавание будет гораздо более точным.

Цитата

при построении модели idngram2lm выдает кучу предупреждений, которые привожу ниже.
что они означают, насколько серьезны и как это победить?)

Сглаживание Good-turning разработано для больших объемов текстов. Оно подразумевает тренировку для обычного языка. Для небольших текстов лучше использовать абсолютное сглаживание.

Для тренировки моделей рекомендуется использовать srilm. Абсолютное сглаживание делается с помощью команды

ngram-count -cdiscount 0.1 -text text.txt -lm text.lm

[w3264]

Цитата nsh @ 26.11.15, 14:48

ngram-count -cdiscount 0.1 -text text.txt -lm text.lm

спасибо)

srilm скачал, скомпилился без проблем, чем неожиданно порадовал)

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

потестирую, пока оценить какчество не могу)

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

они разбились на двуграммы или это какой-то косяк?

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

Сообщение отредактировано: w3264 - 26.11.15, 15:59

[nsh]

Триграммы учитываются, если встречаются больше 3 раз. -gt3min параметр за это отвечает.

[w3264]

Цитата nsh @ 25.11.15, 22:12

нужно модифицировать функцию ngram_ng_score, она простая.

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

Сообщение отредактировано: w3264 - 01.12.15, 19:01

[nsh]

Для контекста можно подключить несколько моделей и переключаться между ними с помощью ps_set_search.

[w3264]

можно ли сказать, почему неодинаковые результаты детекта?

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

слово не детектится, даже нет в кандидатах
походу что-то с акустикой

можно ли это починить?

Сообщение отредактировано: w3264 - 05.12.15, 19:30

[w3264]

вопрос снимается)

все-таки в список кандидатов попадает, пролетает в last_phone_transition, когда кандидаты меряются своим весом из модели языка ...

иными словами с акустикой в этом случае проблем нет, что очень здорово, нужно делать нормальную модель языка

[w3264]

при просчете решетки строятся пути из dag->start в dag->end, а вот этот последний dag->end заменяется на наилучшее слово, окончившееся в последнем фрейме, если в последнем фрейме в явном видне нет </s>

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

фу, надеюсь понятно изложил)

если я прав, то как вариант решения можно в случае отсутствия </s> в последнем фрейме добавлять его в новый последний фейковый фрейм

если я правильно все понял)

[nsh]

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

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

[w3264]

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

[nsh]

Лучше тут или на нашем форуме https://sourceforge.net/p/cmusphinx/discussion/

[w3264]

ок, почитаю форум, спасибо)

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

это специальная фича или нет? это важно, так как такой размазанный конец слов приводит к дополнительным ошибочным путям в решетке

[nsh]

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

[w3264]

спасибо за ответ)

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

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

Сообщение отредактировано: w3264 - 21.12.15, 20:22

[w3264]

добрый день,
меня глючит или это косяк,
ngram_search.c, строка 394, отсутствует проверка на path != -1

[nsh]

Прошу прощения, не сразу понял. В какой версии это строка 394?

Сообщение отредактировано: nsh - 25.01.16, 20:29

[w3264]

в последней, 5prealpha

void ngram_search_save_bp(ngram_search_t *ngs, int frame_idx, int32 w, int32 score, int32 path, int32 rc)
...
if (bp != NO_BP) {
if (frame_idx - ngs->bp_table[path].frame > NGRAM_HISTORY_LONG_WORD) {....

Сообщение отредактировано: w3264 - 26.01.16, 05:55

[w3264]

интересно, в параллель можно запустить несколько процессов декодинга с одним ps_decoder_t?
т.е. если есть одновременно несколько микрофонов и стоит задача одновременного декодинга, то надо для каждго микрофона поднимать свой ps_decoder_t или достаточно одного?

[nsh]

Цитата

в параллель можно запустить несколько процессов декодинга с одним ps_decoder_t?

Нет

Цитата

то надо для каждго микрофона поднимать свой ps_decoder_t

Да

[w3264]

иными словами облачный сервис из сфинкса без доработки сделать не получится? ведь старт каждоного нового ps_decoder_t - длительная процедура, поэтому если для каждого запроса стартовать новый ps_decoder_t то будет значительная задержка

Сообщение отредактировано: w3264 - 31.01.16, 11:38

[nsh]

Для этих целей применяется шаблон Объектный_пул

[w3264]

иными словами делается массив ps_decoder_t -ов ...

в плане памяти это доп расходы ... интересно, большие?

с другой стороны добавить многопоточность дело не сложное, вытащить в отдельную структуру потоко-зависимые данные, типа звуковой поток, круговые сеп-фич-буферы, битовые буфера для расчета сенонов, буфера активных слов, bptbl + сопуствующие, dag ... может еще че забыл ... стоит овчинка выделки?

Сообщение отредактировано: w3264 - 31.01.16, 18:16

[nsh]

Цитата

с другой стороны добавить многопоточность дело не сложное, вытащить в отдельную структуру потоко-зависимые данные, типа звуковой поток, круговые сеп-фич-буферы, битовые буфера для расчета сенонов, буфера активных слов, bptbl + сопуствующие, dag ... может еще че забыл ... стоит овчинка выделки?

Это не нужно.

[w3264]

согласен гемор, двойная инициализация на порядок проще

[w3264]

добрый день)

терзают смутные сомнения)

в декодере акустика начинает работать с фейкового слова <s>, пропуская 3 фрейма перед началом полноценного распознавания слов ... 3 фрейма, насколько я понимаю, это 30 мс, время сопоставимое с с длительностью согласных ...

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

не связано ли плохое распознавание первых слов с этим моментом?

довольно часто выходят на первое место слова, созвучные с исходным с откинутыми первыми звуками :
кухня - идет по акустическому скорингу после - уху, луку, руку

Сообщение отредактировано: w3264 - 03.02.16, 11:36

[nsh]

Цитата

в декодере акустика начинает работать с фейкового слова <s>, пропуская 3 фрейма перед началом полноценного распознавания слов ... 3 фрейма, насколько я понимаю, это 30 мс, время сопоставимое с с длительностью согласных ...

В начале декодирования оценивается большое число параметров - уровень шума, например. Затем идёт оценка CMN. Для этого нужно гораздо больше времени, чем 30мс. Детектор речи передаёт данные на распознавание, начиная с некоторого буфера. Поэтому <s> в начале это не проблема. Но декодирование лучше начинать со значительного куска без речи.

[w3264]

вот об этом и говорю, что лучше брать небольшой запас фреймов перед официальным началом аттеранса,
т.е. сейчас считается, что аттеранс начинается там, где встречаются N фреймов, которые превышают заданный порог snr ... может быть стоит брать небольшой запас фреймов перед этими N фреймами ... вроде не сложно сделать, попробую на досуге

пс. кстати, что такое CMN?

Сообщение отредактировано: w3264 - 03.02.16, 14:02

[w3264]

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

[w3264]

а нет, нормальненько так какие-то лишние 5-6 фреймов спереди улучшают детект первого слова на порядок ...

вы собираетесь фиксить это в ближайшее время или мне самому у себя подкрутить?

Сообщение отредактировано: w3264 - 13.02.16, 06:58

[w3264]

добрый день)

есть ли где-нибудь описание маркеров фонем?
типа чем отличается а от aa, от ay ... чем отличается r от rr ...

[zamir]

Добрый вечер

https://github.com/zamiron/ru4sphinx/blob/m...istic_questions
https://en.wikipedia.org/wiki/Formant
https://ru.wikipedia.org/wiki/%D0%A0%D1%83%...%B8%D0%BA%D0%B0

[w3264]

спасибо)

[w3264]

добрый день)

как можно оптимизировать детект ключевых слов?

одно ключевое слово, задается через ключ -keyphrase
при -kws_threshold 1e-10 много пропусков слова, которое есть в потоке - много несрабатываний
при -kws_threshold 1e-30 много ложных детектов
середина указанного диапазона не приносит морального удовлетворения тоже)

что можно сделать?

пс. тестирование ведется в зашумленной обстановке

Сообщение отредактировано: w3264 - 10.03.16, 11:41

[nsh]

Ключевое слово подлиннее придумать

[w3264]

Цитата nsh @ 11.03.16, 08:20

Ключевое слово подлиннее придумать

могу скинуть .wav, около 3 секунд, в тишине очетливо произносится слово, kws не детектится

[nsh]

Это можно было сделать ещё 10 марта.

[w3264]

10 марта я надеялся на лучшее), а только уже сегодня решил поплотнее глянуть на внутренность kws_search.c и то что там творится

https://yadi.sk/d/nvkFC8EqqATo5

[nsh]

pocketsphinx_continuous -infile robot_failed.wav -keyphrase "робот" -kws_threshold 1e-10 \
-hmm zero_ru_cont_8k_v3/zero_ru.cd_cont_4000 -dict zero_ru_cont_8k_v3/ru.dic  -samprate 8000
..
INFO: cmn_prior.c(131): cmn_prior_update: from < 11.64  0.15 -0.04  0.17 -0.40 -0.03 -0.50 -0.13 -0.33 -0.11 -0.19 -0.10 -0.24 >
INFO: cmn_prior.c(149): cmn_prior_update: to   <  8.24  0.41 -0.08  0.02 -0.21 -0.10 -0.29 -0.17 -0.22 -0.11 -0.14 -0.07 -0.05 >
INFO: kws_search.c(658): kws 0.12 CPU 0.045 xRT
INFO: kws_search.c(660): kws 0.13 wall 0.045 xRT
робот
INFO: cmn_prior.c(131): cmn_prior_update: from <  8.24  0.41 -0.08  0.02 -0.21 -0.10 -0.29 -0.17 -0.22 -0.11 -0.14 -0.07 -0.05 >
INFO: cmn_prior.c(149): cmn_prior_update: to   <  8.24  0.41 -0.08  0.02 -0.21 -0.10 -0.29 -0.17 -0.22 -0.11 -0.14 -0.07 -0.05 >
INFO: kws_search.c(467): TOTAL kws 0.12 CPU 0.045 xRT
INFO: kws_search.c(470): TOTAL kws 0.13 wall 0.045 xRT

[w3264]

извиняюсь, сразу не сказал

тестирую без параметра kws_threshold, т.е. с его значением по умолчанию равным 1

наговариваю последовательно слово, детект идет с таким значением порога вполне нормальный, в какой-то момент он пропадает, совершенно необъяснимым образом

попробую тоже самое сделать с порогом 1e-10, возможно получится воспроизвести поток с недетектом

пс. недетектов при пороге 1e-10 на порядок меньше, да, и что самое плохое - они плохо воспроизводятся если из поток поднимать из записанного файла - ибо конечно кое-что уже меняется, подстройки того же cnm ... погоняю еще, если получится воспроизвести - отпишусь

в любом случае - спасибо за ответы)

Сообщение отредактировано: w3264 - 14.03.16, 13:50

[w3264]

увеличил на слог ключевое слово, стал хороший детект почти без ложных срабатываний даже на 1e-20, спасибо), правда нужно еще поглядеть на работу в разных акустических условиях ...

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

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

[w3264]

добрый день)

есть ли в планах на текущий момент интеграция dnn?

[nsh]

Цитата

есть ли в планах на текущий момент интеграция dnn?

Нет

[w3264]

если не секрет, в плане повышения правильности распознавания сфинкса, какое самое перспективное направление разработки? языковая модель и адаптация акустики - это понятно)

Сообщение отредактировано: w3264 - 29.03.16, 14:19

[nsh]

Цитата

в плане повышения правильности распознавания сфинкса, какое самое перспективное направление разработки?

Более точная акустическая модель.

Цитата

языковая модель и адаптация акустики - это понятно)

Мне не понятно.

[w3264]

Цитата nsh @ 29.03.16, 16:10

Более точная акустическая модель.

имеется ввиду большая выборка обучения акустики, 400 часов, 1000, 2000 и тд?

Сообщение отредактировано: w3264 - 29.03.16, 19:31

[nsh]

Цитата w3264 @ 29.03.16, 19:30

имеется ввиду большая выборка обучения акустики, 400 часов, 1000, 2000 и тд?

Имеется ввиду более точная модель, сегодняшние распознавалки с DNN гораздо более точно описывают речь. Объём базы тоже влияет на точность распознавания, но не так сильно. Текущий объём английской базы около 1000 часов уже.

[w3264]

-- сегодняшние распознавалки с DNN гораздо более точно описывают речь.

если судить по научным статьям, то на одной и той же базе обучения днн-ки дают прибавку в точности 5-10%, не более

опять же возникает вопрос, почему днн-ки не стоят в очереди на реализацию в сфинксе?

Сообщение отредактировано: w3264 - 30.03.16, 08:04

[nsh]

Цитата

если судить по научным статьям, то на одной и той же базе обучения днн-ки дают прибавку в точности 5-10%, не более

50%.

Цитата

опять же возникает вопрос, почему днн-ки не стоят в очереди на реализацию в сфинксе?

Мы не гоняемся за модными технологиями.

[w3264]

-- 50%
если судить по википедии, то точность сфинкса около 80%, улучшения на 50% быть не может)

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

[w3264]

снова вопрос по kws

если за ключевым словом идет тишина, то детект хороший
если за ключевым словом идет слитная речь, то детект хреновенький, надо специально делать короткую паузу после ключевого слова, что не здорово
как это можно полечить?

[w3264]

только что обратил внимание ...
16 кгц русской модели нет?

Сообщение отредактировано: w3264 - 27.04.16, 10:27

[nsh]

Есть такая

https://sourceforge.net/projects/cmusphinx/...x-ru-5.2.tar.gz

[w3264]

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

в общем респекты разработчикам сфинкса)


*** на правах рекламы)))

[nsh]

Спасибо