에서 (단일 제품을 읽고 PHP와 문법 생성)의 VoiceXML 얼마나 많은 단어 문법
내 질문에 어떤 조언이나 경험이 얼마나 많은 말을해야하는 경우,이다 제품을 읽은 곳의 출처로 writte하십시오. 나는 단어의 구조 나 발음에 대해 많이 알고, 그래서 말을하지 않는
가) 단어는 단어가 아니라 같은 structre 또는 발음 C) 혼합이) 서로 B에서 오히려 다른 의 a)와 b)는 당신이 VoiceXML을위한 동적 문법을 표시 할 때 SRGS의 문법을 의미 있으리라 믿고있어 사전
에서
감사합니다.
불행히도, 실제로 알기 위해 합리적인로드로 성능 테스트를 수행해야합니다. 특정 조건에서 1M 문법을 성공적으로 전송했습니다. 또한 10,000 개의 이름 목록을 작성했습니다. 또한 수십 개의 항목 만 활용할 수있는 플랫폼을 발견했습니다.
음성 인식 (ASR) 및 VoiceXML 플랫폼은 결과에 중요한 영향을 미칩니다. 또한이 문법을 사용하는 동시 인식 수는 전체 인식 부하와 관련이 있습니다.
언급 한 요인은 인식 성능 및 CPU 부하에 영향을 미치지 만, 일반적으로 문법 크기와 항목의 길이/변동성이 더 중요합니다. 예를 들어, 예/아니오 문법은 일반적으로 복잡한 메뉴 문법보다 훨씬 높은 CPU로드를 갖습니다 (짧은 문구는 더 많은 패스가 필요하고 처리 할 때 더 많은 가능성을 열어주는 경향이 있습니다). 저는 다양한 숫자의 문법 (9-31 자리 문법)에서 끔찍한 숫자를 보았습니다. 소리는 짧고 모호하지 않습니다. 구성 요소의 가변성은 다시 솔루션을 위해 지속적으로 검사해야하는 수많은 경로를 만듭니다. 대부분의 메뉴 또는 자연스러운 말하기 구에는 많은 소리가 크게 다른 긴 단어가 있으므로 많은 경로를 빠르게 제외 할 수 있습니다.
몇 가지 팁 :
대부분의 엔터프라이즈 급 ASR 시스템은 캐시를 지원합니다. URL 매개 변수로 문법을 식별하고 ASR이 필요로하는 HTTP 헤더 정보를 설정하면 (표준을 따르지 않는다고 가정) 상당한 성능 향상을 볼 수 있습니다.
프롬프트는 종종 문법로드/컴파일 단계를 숨길 수 있습니다. 사람들이 잠입하는 경향이있는 비교적 긴 프롬프트가있는 경우 상당히 큰 문법 인출을 숨길 수 있습니다. 모든 플랫폼이 이러한 작업을 병렬로 처리하는 것은 아닙니다. 대부분의 ASR 엔진은 오디오를 수집하고 문법을 페치 및 컴파일하면서 엔드 포인팅을 수행 할 수 있습니다. 이것은 당신에게 더 많은 시간을 주지만 더 긴 대기 시간에 영향을 볼 것입니다.
대부분의 ASR 엔진은 샘플 오디오로 문법을 분석 할 수있는 도구를 제공합니다. 도구는 일반적으로 당신에게 CPU 리소스 지표를 제공합니다. 필자는 인식 동시성에 대한 복잡성으로 인해 전반적인 성능을 계산/예측할 수있는 경우는 드물지만 다른 문법과 비교할 때 상당한 영향을 줄 수 있습니다. 문법 처리 시간을 쉽게 추적 할 수있는 엔진을 아직 찾지 못했고, 동시성 문제를 대략적으로 추측하기 란 어려울 수 있습니다. 대부분의 경우 대규모 테스트가 필요했습니다.
문법로드/컴파일 시간이 지나면 인식 동시성이 가장 중요한 성능 영향입니다.호출 초반에 매우 복잡한 문법을 사용하는 몇 가지 응용 프로그램을 보았습니다. 캐시 할 기회없이 높은 수준의 인식 동시성 (당시 플랫폼 문제)이 발생하여 스케일링 문제 (인식 처리에서 간헐적 인 대기 시간이 길어짐)가 발생했습니다.