的VoiceXML多少單詞語法

Question

有一個動態語法在我的VoiceXML文件（閱讀單品，並創建PHP語法）

我的問題是，如果有任何建議或經驗多的話應該怎麼寫入我讀取產品的來源。 我不很瞭解的話，結構或發音，讓我們說

一）的話是相互 b而不同）的話，而具有相同的結構法或發音 C）的混合的）和b）

在此先感謝

Answer 1

我假設你的意思SRGS語法，當你表示VoiceXML的動態語法。

不幸的是，你將不得不在合理的負載下進行性能測試，才能真正知道。我已經在特定條件下成功傳輸了1M個文法。我也做了10,000個名單。我也遇到過只能使用幾十個條目的平臺。

語音識別（ASR）和VoiceXML平臺將對您的結果產生重大影響。並且，使用該語法的併發識別的數量也將與整體識別負載相關。

您提到的因素確實會影響識別性能和cpu負載，但我通常發現語法的大小和條目的長度/可變性更重要。例如，是/否語法通常具有高得多的cpu負荷，然後是複雜的菜單語法（短語往往需要更多的通行證並且在處理時留下更多的可能性）。我看到了一些來自廣泛的數字語法（9-31數字文法）的可怕數字。聲音很短，難以消除歧義。組件的可變性同樣會產生大量必須連續檢查解決方案的路徑。大多數菜單或自然語音短語有較長的單詞，這些單詞聽起來明顯不同，因此很多路徑可以很快排除。

一些提示：

大多數企業級ASR系統支持的高速緩存。如果您可以使用URL參數識別語法並設置ASR需要的任何HTTP頭信息（不要假定它們遵循標準），您可能會看到顯着的性能提升。

提示可以經常隱藏語法加載/編譯階段。如果你有一個相對較長的提示，人們會傾向於插入，你會發現你可以隱藏一些相當大的語法提取。同樣，並非所有平臺都能並行處理這些任務。請注意，大多數ASR引擎可以收集音頻並執行結束指向，同時仍然獲取和編譯語法。這會給你帶來更多的時間，但是你會看到延遲更長的影響。

大多數ASR引擎提供的工具可以讓你用樣本音頻分析語法。這些工具通常會給你一個cpu資源指標。由於識別併發性的複雜性，我很少發現可以計算/預測整體性能，但它們可以給您與其他語法的比較影響。我還沒有找到能夠輕鬆地跟蹤語法處理時間的引擎，甚至可以很難粗略地猜測併發性問題。在大多數情況下，大規模測試是必要的。

語法加載/編譯時間之後，識別併發性是最重要的性能影響。我已經看到幾個在通話開始時具有高度複雜語法的應用程序。沒有機會緩存​​（當時的平臺問題），導致縮放挑戰（識別處理中的間歇性，大延遲），識別併發性水平高。