Я предполагаю, что вы имеете в виду грамматики SRGS, когда указываете динамическую грамматику для VoiceXML.
К сожалению, вам придется проводить тестирование производительности при разумной нагрузке, чтобы действительно знать наверняка. Я успешно передал 1M + грамматики при определенных условиях. Я также сделал 10000 списков имен. Я также сталкивался с платформами, которые могут использовать только несколько десятков записей.
Распознавание речи (ASR) и платформа VoiceXML окажут значительное влияние на ваши результаты. И число одновременных распознаваний с этой грамматикой также будет иметь отношение к общей нагрузке распознавания.
Факторы, которые вы упомянули, влияют на производительность распознавания и загрузку процессора, но я обычно считаю, что размер грамматики и длина / изменчивость записей имеют большее значение. Например, грамматики да / нет, как правило, имеют более высокую загрузку процессора, чем сложные грамматики меню (короткие фразы, как правило, требуют больше проходов и оставляют открытыми большее количество возможностей при обработке). Я видел несколько ужасных цифр в широком диапазоне грамматик (9-31 цифр). Звуки короткие и их трудно понять. Изменчивость компонентов, опять же, создает большое количество путей, которые необходимо постоянно проверять на наличие решения. Большинство фраз меню или естественных слов содержат более длинные слова, которые звучат значительно по-разному, так что многие пути можно быстро исключить.
Несколько советов:
Большинство систем ASR корпоративного класса поддерживают кэш. Если вы можете идентифицировать грамматики с параметрами URL и установить любую информацию заголовка HTTP, необходимую ASR (не предполагайте, что они соответствуют стандартам), вы можете увидеть значительное повышение производительности.
Подсказки часто могут скрывать фазы загрузки / компиляции грамматики. Если у вас будет относительно длинная подсказка, куда люди будут стремиться ворваться, вы обнаружите, что можете скрыть некоторые довольно большие грамматические выборки. Опять же, не все платформы хорошо справляются с параллельной обработкой этих задач. Обратите внимание, что большинство механизмов ASR могут собирать аудио и выполнять наведение на конечную точку, в то же время выбирая и компилируя грамматику. Это сэкономит вам больше времени, но вы увидите влияние в более длительные задержки.
Большинство механизмов ASR предоставляют инструменты, позволяющие анализировать грамматику с помощью образца аудио. Инструменты обычно дают вам индикаторы ресурсов процессора. Я редко обнаруживал, что вы можете рассчитывать / прогнозировать общую производительность из-за сложностей, связанных с параллелизмом распознавания, но они могут дать вам сравнительный эффект с другими грамматиками. Я еще не нашел движок, который позволял бы легко отслеживать время обработки грамматики, может быть трудно даже приблизительно угадать проблемы параллелизма. В большинстве случаев необходимы масштабные испытания.
После грамматической загрузки / компиляции параллелизм распознавания является наиболее значительным влиянием на производительность. Я видел несколько приложений, которые имеют очень сложные грамматики в начале вызова. Был высокий уровень параллелизма распознавания без возможности кэширования (проблема с платформой в то время), что приводило к проблемам с масштабированием (прерывистые, большие задержки при обработке распознавания).