외부 음성 문법 사용

IVR(대화형 음성 응답) 애플리케이션 및 음성 애플리케이션에 대한 광범위한 음성 인식 작업의 경우 제한된 목록 또는 "문법" 기반 인식은 상당한 이점을 제공합니다. 정확도, 성능 및 비용 측면에서 최신 STT(음성 텍스트 변환) AI 엔진에 사용되는 기존 의미 체계 기반 음성 인식을 훨씬 능가합니다. 이러한 성능 향상은 문법 기반 인식이 인식 출력을 미리 정의된 규칙 집합으로 제한하여 정확도를 강화할 수 있기 때문입니다.

문법은 W3C 사양에 자세히 설명된 대로 SRGS(Speech Recognition Grammar Specification)를 따릅니다. 요청이 엔진에 들어오면 음성 오디오("발화")를 텍스트로 변환합니다. 그런 다음, 엔진은 인식된 텍스트를 문법과 발음 어휘집과 같은 연결된 아티팩트와 비교합니다. 이 프로세스는 문법 내에서 제공된 정보로 문법이 제한하는 리터럴 전사 또는 해석을 제공합니다. 문법에 기본 제공되는 ECMAScript와 같은 추가 논리는 해석을 더욱 구체화할 수 있습니다.

제한된 음성 인식은 다음을 위해 적합합니다.

• 제한된 목록(주소, 주식 시세, 우편 번호, 부서 이름 등)을 인식합니다.

• 영숫자 문자열 인식(추적 숫자, 계정 번호, 확인 코드 등).

  • 위치 제약 조건 포함 예를 들어 멤버 ID의 처음 두 문자는 AN, FD, NT로 시작합니다. 위치 제약 조건의 또 다른 예는 차량 식별 번호입니다.

• 체크섬 또는 이와 유사한 제약 조건이 있는 영숫자 또는 숫자 인식입니다. 예를 들어, Luhn 체크섬이 적용된 신용 카드 번호의 경우입니다.

• 특정 단어 또는 구를 발화해야 하는 지시된 대화 응용 프로그램입니다.

음성 문법 작성

GrXML(Grammar XML)을 사용하여 제한된 음성 문법을 작성합니다. 다른 XML 문서와 마찬가지로 문법 파일은 문법의 특정 특성을 지정하는 헤더로 시작해야 합니다. 문법 파일의 본문은 문법에서 인식되는 음성 단어와 인식된 항목이 반환하는 해당 변수 값을 정의하는 문법 규칙으로 구성됩니다.

문법 파일 헤더

문법 파일의 헤더는 XML 선언과 문서 언어, 루트 및 <grammar> 네임스페이스를 지정하는 요소로 구성됩니다.

<?xml version="1.0" encoding="UTF-8" ?>

<grammar xmlns="http://www.w3.org/2001/06/grammar"

version="1.0" xml:lang="en-US" root="YesNo"

tag-format="swi-semantics/1.0">

XML 선언 및 인코딩 형식

헤더의 첫 번째 요소는 항상 XML 선언입니다. 이 요소는 문서에 사용되는 XML 버전(1.0 또는 1.1)을 지정합니다. 또한 문서에 적용되는 인코딩을 지정하여 사용할 수 있거나 사용할 수 없는 언어를 결정합니다.

버전 및 인코딩은 필수 특성입니다. 기본 설정에 적합한 인코딩을 사용합니다(예: 컴퓨터 설정, 텍스트 처리 애플리케이션 등). 제한된 음성 인식 엔진은 사용하는 인코딩을 신경 쓰지 않습니다.

다음 표에는 다양한 언어에 대한 일반적인 인코딩의 짧은 목록이 나와 있습니다.

대부분의 언어는 둘 이상의 인코딩으로 나타낼 수 있습니다.

런타임에 시스템은 ICU(International Components for Unicode) 라이브러리를 사용하여 문법 파일 인코딩을 UTF-16 형식으로 자동으로 변환합니다. 유니코드 컨소시엄 http://site.icu-project.org/의 공식 웹 사이트는 .

언어, 네임스페이스 및 의미 체계 태그 형식

머리글의 두 번째 요소는 해당 특성이 문서에 대한 기본 정보를 지정하는 요소입니다 <grammar> . 필요한 특성은 다음과 같습니다.

• xml:lang: IETF 웹 사이트의 RFC(메모 요청) 문서 RFC 3066 에 정의된 대로 사용할 기본 사용자 언어의 식별자를 지정합니다.

• Microsoft는 다양한 언어를 지원합니다. 선택한 언어는 문법 인코딩 형식과 호환되어야 합니다.

• version: GrXML(1.0)의 버전을 지정합니다.

• xmlns: 문법 네임스페이스를 지정합니다. GrXML 문법의 경우 이 지정은 항상 http://www.w3.org./2001/06/grammar.

• tag-format: 값을 할당하기 위해 문법 본문의 요소 내에서 <tag> 스크립트에 사용되는 형식을 정의합니다.

태그 형식은 다음 문자열 중 하나여야 합니다.

Dictionaries

경우에 따라 문법은 제한된 음성 인식 엔진이 정상적으로 구문 분석할 수 없는 단어 또는 구를 포함해야 할 수 있습니다. 예를 들어 이름이 다르게 표시되고 철자가 다를 수 있습니다(예: "wih-sta"로 발음될 수 있는 도시 "Worcester").

<lexicon> 요소를 사용하여 발화를 문법 파일의 일치하는 텍스트와 연결하는 사전을 가져옵니다.

문법 파일 본문

문법 파일의 기본 섹션에는 문법을 실제로 정의하는 규칙, 즉 인식할 음성 단어와 구 및 인식된 각 항목에 대한 기본 애플리케이션으로 돌아갈 값이 포함됩니다.

Rules

문법 파일의 본문은 GrXML <rule> 요소를 사용하여 정의된 규칙으로 구성됩니다. 각 규칙에는 고유 식별자가 있습니다. 각 규칙은 <item> 또는 <token> 요소 내에서 텍스트로 인식하는 단어와 구를 나열합니다. 이러한 요소는 다른 GrXML 요소 내에 중첩될 수 있습니다.

• 요소는 <one-of> 허용 가능한 대안 목록을 표시하며 규칙을 활성화하려면 하나의 대안만 필요합니다.

• 요소는 <ruleref> 서브루틴과 관련된 다른 규칙을 참조합니다.

• 요소는 <tag> 수행할 작업 또는 변수에 할당할 값을 지정합니다. 태그 형식 언어로 작성된 스크립트를 포함할 수 있습니다.

사용자가 규칙에서 다루는 단어 또는 구를 발화하면 규칙은 해당 발화에 대해 정의된 작업, 값 할당 또는 기타 코드를 실행합니다.

루트 규칙

헤더가 달리 지정하지 않는 한 루트 규칙은 파일의 첫 번째 규칙입니다. 기본 운영 수준 규칙으로 사용됩니다. 조회할 규칙을 지정하지 않고 문법을 참조하는 경우 이 루트 규칙이 처음 참조됩니다.

규칙 범위

문법 파일의 본문 내에서 각 규칙을 범위로 할당합니다. 범위는 외부 파일(공용)과 독립적으로 또는 동일한 문법(프라이빗) 내의 다른 규칙에서만 규칙을 참조할 수 있는지 여부를 나타냅니다. 공용으로 정의하지 않는 한 모든 규칙은 기본적으로 비공개입니다.

규칙이 공용인 경우 해당 ID 특성을 다른 문서의 참조에 대한 앵커로 사용할 수 있습니다. 예를 들어 다음 구문을 고려합니다.

<grammar src="../grammars/universals.grxml#YesNo"/>

이 문법 요소를 호출하면 파일의 루트 규칙인지 여부에 관계없이 universals.grxml 파일 내에서 공용 "YesNo" 규칙을 직접 참조합니다.

의미 추출 및 결과 반환

SWI_meaning 키에는 인식된 구의 의미가 포함됩니다. 루트 규칙에 대해서만 설정할 수 있습니다. 이 키는 기본적으로 목록에 포함 swirec_extra_nbest_keys 되므로 문법에서 이 키를 설정하면 XML 결과에 표시됩니다.

SWI_meaning 는 n-best 목록의 항목이 진정으로 구별되도록 중복 답변을 필터링합니다. 중복성을 제거하면 신뢰도 점수와 n-best 목록의 유용성이 향상됩니다.

인식된 한 구가 문법의 다른 구와 비슷한 경우 제한된 음성 인식 엔진이 어떤 구가 올바른지 잘 모르기 때문에 신뢰도 점수가 낮은 경우가 많습니다. SWI_meaning을 올바르게 사용하는 경우 제한된 음성 인식 엔진은 n-best 목록의 동일한 슬롯에 중복 해석을 그룹화합니다. 다음 예제에서 SWI_meaning 는 인식된 구가 "전화 직통 집으로" 또는 "제 전화를 집으로 연결해 주세요"인지에 관계없이 "전화 직통 집으로"로 설정됩니다.

SWI_meaning 없이, 문법은 다음과 같은 n-best 목록을 생성할 수 있을 것입니다.

사용하는 SWI_meaning경우 제한된 음성 인식 엔진은 정확한 구문이 아닌 해석의 의미에 따라 n-best 목록을 정렬하므로 n-best 목록의 항목은 진정으로 구별됩니다.

문법 내의 스크립트에서 명시적으로 설정하지 않더라도, 제한된 음성 인식 엔진에 의해 SWI_meaning가 자동으로 설정됩니다.

루트에서 명시적으로 정의 SWI_meaning 하지 않으면 루트에 정의된 모든 키와 해당 값을 연결하여 생성됩니다. 그러나 이 구성은 SWI_로 시작하는 키(예: SWI_literal)에는 적용되지 않습니다. 키/값 쌍은 먼저 사전순으로 정렬됩니다. 애플리케이션에 관한 한 반환되는 키 집합이 문장의 의미라고 볼 수 있는 이유는 이렇습니다.

키가 없는 경우 결과는 SISR 또는 SWI 의미 체계를 사용하는지 여부에 따라 달라집니다. SISR을 사용할 때, 키가 없으면 SWI_meaning 키가 설정되지 않습니다. 반면 SWI 의미 체계는 SWI_meaning 다음으로 설정됩니다.

{SWI_literal:<literal>}

개체인 경우 SWI_meaning 문자열 표현으로 변환됩니다.

애플리케이션은 SWI_meaning에 접근할 수 있지만, 따로 정의된 다른 키/값 쌍을 사용하는 경우가 많습니다.

Azure Storage를 통해 음성 문법 호스트

Copilot Studio는 음성 문법을 통해 제한된 음성 인식을 지원합니다. 그러나 이러한 문법을 직접 작성, 테스트 또는 호스팅하는 것은 지원되지 않습니다. 문법 호스팅의 경우 Microsoft Azure Storage를 사용하여 음성 지원 에이전트와 문법 스토리지 간에 신뢰할 수 있고 안전한 연결을 만듭니다.

Azure 스토리지 계정 설정

Azure 스토리지 계정을 만듭니다. 새 스토리지 계정의 구독, 리소스 그룹, 지역 및 리소스 이름이 조직의 정책을 따르는지 확인합니다. 다음 설정을 사용합니다.

• 기본 서비스의 경우 Azure Blob Storage 또는 Azure Data Lake Storage Gen 2를 선택합니다.

• 성능에 대한 프리미엄 을 선택합니다.

Azure Storage 계정 만들기에 대해 자세히 알아봅니다.

스토리지 컨테이너 설정

정적 웹 사이트를 업로드된 문법 파일의 스토리지 컨테이너로 사용합니다. 스토리지 컨테이너는 웹 사이트에 대한 기본 엔드포인트 및 보조 엔드포인트를 제공합니다.

문법 파일을 업로드한 후 디렉터리에서 파일을 선택하여 파일의 속성과 세부 정보를 봅니다. 다음 형식이어야 하는 파일의 URL을 저장합니다.

https://{resourceName}.blob.core.windows.net/\$web/{grammarFileName}

컨테이너 만들기에 대해 자세히 알아봅니다.

제한된 음성 인식 엔진 인증

제한된 음성 인식이 음성 지원 에이전트 내에서 작동하려면 시스템에서 이전 단계에서 만든 스토리지 계정을 신뢰할 수 있는 위치로 사용하여 인증해야 합니다. 이 인증에는 Storage Blob 데이터 판독기 역할이 필요합니다.

Azure Portal 사용하여 Azure 역할 할당에 대해 자세히 알아봅니다.

Azure Portal에 로그인하고, Azure Cloud Shell 세션을 열고, 다음 명령을 실행하여 테넌트에 제한된 음성 인식 엔진 서비스 주체를 만듭니다.

az ad sp create --id e0e7bef0-777c-40ef-86aa-79d83ba643c7

Copilot Studio에서 제한된 음성 사용

외부 엔터티 만들기

Copilot Studio 내의 엔터티는 특정 유형의 실제 주제를 나타내는 정보 단위로 생각할 수 있습니다. 예를 들어 전화 번호, 우편 번호, 도시 또는 사람의 이름이 있습니다. 에이전트는 엔터티를 사용하여 사용자 입력에서 관련 정보를 인식하고 나중에 사용하기 위해 저장할 수 있습니다. 이 시나리오에서는 제한된 음성 문법이 인식을 수행합니다.

외부 엔터티를 사용하여 음성 문법을 참조합니다. 외부 엔터티를 만들려면 음성 지원 에이전트를 열고 설정>엔터티>엔터티 추가>외부 엔터티 등록으로 이동합니다.

다음 정보를 입력합니다.

• 이름: "https://{resourceName}.blob.core.windows.net/\$web/{grammarFileName}?constrainedrequired=true" 형식의 문법 URL

  메모

  URL은 대/소문자를 구분합니다.

기본 인식 모드는 Speech Only입니다. 대체 문법 구성은 다음 표를 참조하세요.

예를 들어 영어와 스페인어에 각각 다른 하위 디렉터리에 저장되는 두 개의 동일한 문법 집합이 있다고 가정해 보겠습니다. 다국어 에이전트는 영어와 마찬가지로 스페인어로 대화할 때 영어 문법을 사용할 수 있어야 합니다. 이 경우 문법 URL은 다음과 같습니다. {Env.BaseURL}/common/**{System.User.Language}**/{grammarFileName}?

System.User.Language가 en_US 또는 es_US이고, 에이전트의 언어가 전환될 때 변경됩니다.

• 설명: 캔버스의 선택기가 엔터티 이름으로 참조하는 문법에 대한 간단한 설명입니다. 예를 들어 "신용 카드 번호"입니다.

• 데이터 형식: 레코드 데이터 형식을 선택하고 응답에서 예상 태그의 스키마를 정의합니다. 예를 들어, 문법이 SWI_meaning 및 city를 반환하는 경우, 레코드 스키마는 다음과 같습니다.

  kind: Record
  properties:
  city: String
  SWI_meaning: String
  

저장을 선택하면 엔터티가 목록에 표시됩니다. 제작 캔버스에서 질문 노드로 이동합니다. 기존 엔터티와 마찬가지로 에이전트가 프롬프트에 대한 사용자의 응답의 결과로 인식할 외부 엔터티(문법에 연결됨)를 선택합니다.

런타임 동작

음성 지원 에이전트가 실행되고 외부 문법을 사용하는 논리가 발견되면 음성 지원 에이전트가 Azure Storage 계정에 연결하고 해석을 위해 문법을 검색합니다. 그런 다음 에이전트는 사용자가 문법 내에 적용된 제약 조건에 대해 말한 내용과 일치합니다. 일치가 성공하면 시스템은 외부 엔터티에 정의된 스키마에 따라 레코드 변수의 응답을 반환합니다.

캔버스 논리

노드의 변수에 저장된 결과는 항상 외부 엔터티의 스키마에 정의된 레코드 형식입니다 . 작성자는 이 레코드 변수를 사용하여 점 표기법과 variableName.SWI_meaning 같이 variableName.city 스키마에 정의된 키에 액세스할 수 있습니다.

디버깅

오류 코드

SWI_리터럴

제한된 음성 인식 엔진에서 작동하는 많은 문법의 SWI_Literal 경우 이 기능은 해석된 결과가 아니라 사용자가 발화한 리터럴 문을 반환합니다. 이 값을 Copilot Studio의 출력 중 하나로 기록하여 디버깅을 지원합니다.

알려진 제한 사항

솔루션에는 다음과 같은 제한 사항이 있습니다.

• 개별 문법 파일의 최대 크기이며 현재 100MB로 제한됩니다.
• 변수 전달은 지원되지 않습니다.
• 스토리지 계정은 에이전트와 동일한 테넌트 내에 있어야 합니다.
• URL의 크기는 500자를 초과할 수 없습니다.
• Azure Storage 계정 엔드포인트만 허용됩니다.
• 하위그램은 동일한 스토리지 계정에서만 호스팅할 수 있습니다(권한 부여에 동일한 FPA 사용).
• 보안 XML 파서(즉, DTD는 허용되지 않으며 SRGS/SISR 스키마에 대해 유효성을 검사해야 합니다).
• NLSML 출력 형식만 내부적으로 지원됩니다.
• 레거시 swirec_simple_result_key 매개 변수는 효과가 없으며 모든 태그가 반환됩니다.

법적

Microsoft Dynamics 서비스는 제한된 음성 인식 시스템을 처리합니다. 이 환경을 사용하면 Dynamics 약관에 동의합니다.