Возможны ли динамические 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) после первого детекта завершения ...

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