[NUGU Dev Days Advanced] NUGU Play Kit으로 Play 만들기 (Advacned)

NUGU Dev Days Advanced
NUGU Play Kit으로 Play 만들기
AI사업 Unit
Platform Evangelist 권세영

1
목차
I. 대화 흐름 디자인 하기
① Multi-turn 대화 유형 살펴보기
② 필수 Entity 정의하기 (Slot-Filling Prompt)
II. Action 정의하기
① Parameter 구성하기
② Response 사용하기
③ Branch Action 을 활용한 Multi-turn 대화 구성
④ 예외 상황 관리
III. Response Filter 사용하기
IV. 테스트 하기

2
 대화의 유형은 크게 ‘Single-turn 대화’ 와 ‘Multi-turn 대화’ 로 구분
 Single-turn 대화
 사용자가 발화한 요청에 대해 NUGU 에이전트가 답변한 대화가 종료되는 대화 유형
 Multi-turn 대화
 사용자와 NUGU 에이전트가 대화를 2회 이상 주고 받는 대화 유형

3
 Slot-filling
 사용자 의도 (Intent) 는 파악하였으나, 추가 정보가 필요해 다시 묻는 경우
 “언제로 할까요?” 보다는 “몇 시로 설정할까요?” 가 더 명확함
Multi-turn 대화 유형 살펴보기

4
 Slot-filling
 Slot-filling 시 누락된 Entity에 해당 하는 사용자 발화만 받아 드려야 하며, 그 외 발화에 대해서는 잘못된 명령 임을 안내
Slot-filling prompt 에 정의한 n회 연속 잘못된 명령이 입력되거나,
미발화 상태가 7초 간 유지 될 경우 대화 종료 (Play 세션 종료)

5
 Slot-filling
 문장 작성 시 고려 항목
사용자가 질문을 확실히 인지 할 수 있도록 문장을 구성
실행 가능한 기능에 대해서만 질문
사용자에게 얻고자 하는 답변이 ‘예 / 아니오’ 인지, 추가 정보 인지에 따라 질문을 구성
필수 Entity (Required Entity)에 대해서만 Slot-filling
선택적인 Entity (Optional Entity) 에 대해서는 기본값 설정  Slot-filling 횟수를 최소화

6
① Play Builder 좌측 메뉴에서 Actions > Custom Actions 을 선택한 후, Slot-filling Prompt를 사용할 Action을 선택합니다.
② [응답에 필요한 정보 가져오기] 에서 Slot-filling Prompt를 사용할 Entity의 ‘필수’ 체크
필수 Entity 정의하기 (Slot-filling Prompt)

7
③ 이후 Slot-filling Prompt 를 입력

8
 Slot-filling Prompt 는 다른 Prompt와 달리 마지막 발화부터 입력하는 스택 구조 LIFO (Last In First Out) 로 동작
 여러 개의 Prompt를 입력하면, 가장 마지막에 입력한 Prompt 부터 순서대로 응답
 입력한 첫번째 Prompt 는 종료 Prompt로 동작하여 Play 세션을 종료

9
 Slot-filling이 연속적으로 여러 번 반복되는 것은 지양
 필수 Entity (Required Entity)에 대해서만 Slot-filling 과정을 진행
 선택적 Entity (Optional Entity)에 대해서는 기본값을 설정
Slot-filling Prompt 작성 시 주의사항

10
 사용자가 답변해야 할 내용을 명확하게 안내
 사용자가 무엇을 답변해야 하는지 명확히 알 수 있도록 Entity의 유형을 포함시켜서 안내

11
 인식이 어려운 발화를 유도하지 않도록 함
 사용자가 발화해야 하는 Entity가 긴 경우에는 인식이 어려움

12
 사용자의 확인이 필요할 경우, 발화 예시를 제시
 확인 여부를 명확히 구분할 수 있도록 “예 / 아니오” 형식의 발화보다는 명확한 의도가 담긴 발화를 할 수 있도록 예시를 제시

13
 다음 명령 요청
 사용자 발화에 대한 동작 후, 다시 마이크를 열고 (Listening 상태) 사용자의 다음 명령을 기다리는 경우
 앞서 수행한 Context를 유지하고, Listening-passive 상태로 진입
 Fallback prompt 에 정의한 n회 연속 잘못된 명령이 입력되거나,
 미발화 상태가 7초 간 유지 될 경우 대화 종료 (Play 세션 종료)

14
 다음 명령 요청
 수행할 수 없는 명령을 한 경우, 한 번 더 사용자에게 묻는 것도 고려
 Intent 와 Entity 는 분석되었으나, 해당 데이터가 없는 경우

15
 Response는 사용자의 발화를 입력 받았을 때 Play의 응답을 의미
 Action이 Trigger에 의해 동작하게 되었을 때, 자신의 하위에 Branch Action이 없으면 결과로 Response를 반환
 다음과 같이 Action Tree의 끝에 위치한 Action만 Response를 가짐
Response 사용하기

16
 Response는 Prompt 와 Directive로 구분
 Prompt
 NUGU를 통해 음성 합성되어 발화되는 메시지
 Directive
 NUGU를 통해 디바이스를 제어하는 명령
 Capability Interface를 사용하는 Play의 경우만 사용 가능
Response 사용하기

17
 Prompt 구성 요소
구성 요소 특징 자동완성 단축키
일반 텍스트 '가나다'와 같은 일반적인 텍스트를 그대로 읽어 발화 지원 안 함
Parameter {{parameter_name}}와 같은 형태로 사용하며, Parameter에 담긴 값을 텍스트로 변형하여 발화 {{
Response Filter
NLG Translator Parameter와 항상 결합하여 사용되며, 단독으로 쓰일 수 없음 >
NLG Normalizer Parameter에 담겨 있는 값이 Filter의 Source와 100% 일치할 경우에만 동작 =
NLG Function :
조사
'을/를'과 같이 앞 음절에 따라 조사가 바뀌는 경우에 자동으로 변환하여 발화
조사 자동 변환은 Parameter와 함께 사용될 때만 동작
/
SKML 태그 TTS 엔진이 텍스트 혹은 Parameter의 값을 SKML 태그에 따라 발화 <
Prompt 사용하기

18
 Prompt 유형
유형 설명
대기 Prompt Prompt가 발화된 이후 Play의 세션이 유지
연속 Prompt 뒤이어 올 Prompt가 있는 경우에만 발화되며, 뒤이어 오는 Prompt와 더해져서 하나의 문장처럼 발화
종료 Prompt Prompt가 발화된 이후 Play의 세션이 종료
위치 특징
일반 Response의 Prompt
Welcome Action을 제외한 모든 Action
 대기 Prompt와 종료 Prompt가 사용
 여러 Prompt가 입력된 경우, 무작위로 선택되어 발화
Built-in Action > Welcome
 대기 Prompt와 연속 Prompt가 사용
 여러 Prompt가 입력된 경우, 무작위로 선택되어 발화
Slot-filling Prompt
 여러 Prompt가 입력된 경우, 위에서부터 순차적으로 발화
예외 상황 처리의 Exception Prompt
 여러 Prompt가 입력된 경우, 위에서부터 순차적으로 발화
Prompt 사용하기

19
 Silent Prompt
 사용자에게 빈 응답을 전달하고 싶은 경우 사용
 Prompt 입력 창 우측의 스피커 버튼을 눌러 설정 가능
 아무 발화 없이 대기 모드로 넘어가거나 세션이 종료
 모든 유형의 Prompt에서 사용 가능
Prompt 사용하기

20
 조사 처리하기
 국어의 조사 ‘이/가, 을/를, 은/는, 과/와, 로/으로’ 는 같은 형태소지만 앞 음절의 받침 유무에 따라 다르게 사용
 Parameter 뒤에 조사를 쓰는 경우, parameter 에 담긴 마지막 글자의 받침 유무에 따라 자동으로 조사 변환
 Parameter의 }} 기호 뒤에 / 를 입력하면 조사의 자동완성 창이 표시  원하는 조사를 선택
Prompt 사용하기

21
 조사 처리하기
 자동완성을 사용하지 않더라도 parameter 의 }} 사이에 조사를 직접 입력해도 동작
은/는 이/가 을/를 과/와 로/으로
받침이 없는 경우 는 가 를 와 로
받침이 있는 경우 은 이 을 과 으로
 조사 처리 시, 받침 유무 판정 규칙
 알파벳은 미국식 영어로 읽는 것을 한국어로 옮긴다고 간주하고 조사 처리
 10 g, 1 m 와 같이 숫자와 단위가 붙어서 조합되고, 발화 옵션 ‘Say 태그 (단위 속성)’ 를 처리하지 않는 경우, 10 그램, 1 미터와
같이 단위에 대한 표준어로 변화하여 조사 처리
 괄호나 특수문자가 포함된다면 제거한 후 처리
 단위, 한글, 영문, 숫자에 해당하지 않는 경우는 변환 하지 않음
Prompt 사용하기

22
 발화 옵션 사용하기
 입력한 Prompt 를 음성으로 변환시킬 때 개별적으로 튜닝을 하거나, 다르게 읽을 수 있는 ‘발화 옵션’ 기능을 제공
 발화 옵션은 Play의 모든 Prompt에 일괄 반영할 수도 있고, 특정 문장 별로 변경 가능
 문장 내 발화 옵션 태그를 사용하여 세밀한 설정 (Tuning) 도 가능
Prompt 사용하기

23
 전체 발화 옵션 변경하기
① Play Builder 홈 화면에서 모든 Prompt 의 발화 옵션을 변경할 Play 를 클릭하여 선택한 후 ‘General’ > ‘기본정보’ 를 클릭
Prompt 사용하기

24
 전체 발화 옵션 변경하기
② 기본 정보 페이지의 Prompt 발화 옵션에서 발화 속도, 음 높낮이, 문장 사이의 묵음 길이, 끊어 읽기 뒤 묵음 길이를 설정한 후
‘발화옵션 적용하기’ 버튼을 클릭
 발화속도 (speed) 재생 속도를 50 ~ 200% 사이에서 변경할 수 있습니다.(기본값: 100%) 최솟값이나 최댓값으로 설정할 경우에는 음질 열화가 발생할 수 있으므로 85 ~ 115 사잇값 사용을 권장
합니다.
 합성음 높낮이 (pitch) 합성음의 높낮이를 90 ~ 110 % 사이에서 변경할 수 있습니다.(기본값: 100%) 최솟값이나 최댓값으로 설정할 경우에는 음질 열화가 발생할 수 있으므로 95 ~ 105 사잇값 사
용을 권장합니다.
 문장 사이 묵음 길이 (pause1) 문장과 문장 사이의 묵음 길이를 300 ~ 900 ms 사이에서 변경할 수 있습니다.(기본값: 600 ms)
 끊어읽기 뒤 묵음 길이 (pause2) 문장 내 끊어읽기 후의 묵음 길이를 100 ~ 500 ms 사이에서 변경할 수 있습니다.(기본값: 300 ms)
Prompt 사용하기

25
 문장별 발화 옵션 변경하기
① Actions > Custom Actions 페이지에서 발화 옵션을 설정할 Prompt가 있는 Action 선택
Prompt 사용하기

26
 문장별 발화 옵션 변경하기
② Output 정의 영역에서 발화 옵션을 변경할 Prompt 의 우측 ‘조절’ 버튼을 클릭하여 옵션을 설정한 후 Play 저장
Prompt 사용하기

27
 문장 내 발화 옵션 태그 추가하기
 Prompt 내에서 특정 구간에 끊어 읽기를 추가하거나, 특정 단어를 읽는 방식을 조절하는 태그 제공
 태그들은 기본적으로 <태그 속성=“속성값”> 형태로 구성
 Prompt 문장 입력창에서 자동 완성 제공
 문장 입력 중 특수문자 < 를 입력한 뒤 자동완성창에서 세가지 기능 중 적용할 옵션 선택
Prompt 사용하기

28
 문장 내 발화 옵션 태그 추가하기
발화 옵션 설명
텍스트읽기
(say)
 한글이 아닌 문자들을 어떻게 읽을지 결정하는 태그
 '4-2'는 '사 다시 이'와 같이 주소처럼 읽거나, '사 대 이'처럼 경기 스코어로 읽을 수 있을 수 있기 때문에, 이것을 어떻게 읽을 것인지 태그로 정
해주는 기능
 태그를 적용할 텍스트의 끝에 </say>가 필수
변환하여 읽기
(sub)
 일반적이지 않은 발음변환 규칙을 통해 발음이 되는 텍스트인 경우, 속성으로 지정해준 텍스트로 변환하여 발화하도록 하는 태그
 예) Ronaldo → 'Ronaldo'를 태그 내 속성의 '호날두'로 변환
 예) 서프라이즈 → '서프라이즈'를 태그 내 속성의 '써프라이즈'로 변환
 태그를 적용할 텍스트의 끝에 가 필수
끊어읽기
(break, pause)
 문장을 읽을 때 내용상, 길이상 적절하게 쉬어서 읽어주는 곳을 결정하는 태그
 입력된 Prompt는 TTS 엔진이 끊어읽기 간격을 스스로 계산하여 발화
 TTS 엔진 합성음의 끊어읽기가 자연스럽지 않다고 판단될 경우에 끊어읽기의 위치 및 종류를 수동으로 설정
 이 태그는 적용할 어절의 뒤에 공백 없이 넣어야하고, 태그의 뒤에는 공백이 있어야 함
 예) 안녕하세요. <break type="weak"/>아리아에요.(X)
 예) 안녕하세요.<break type="weak"/> 아리아에요.(O)
Prompt 사용하기

29
 Directive 는 오디오 파일을 재생시키거나 멈추게 하는 명령어로 Backend proxy 가 Capability Interface 를 지원해야만 사용
 현재 제공되는 Interface : AudioPlayer Interface / Display Interface (only for T map)
 Directive 를 사용하여 디바이스를 제어하기 위해서는 다음과 같은 과정이 필요
 Backend proxy 에 Capability Interface 가 구현되어 있어야 함
 Play 의 설정 (General > 기본정보) 에서 Capability Interface를 사용함으로 설정되어 있어야 함
 Direcitve 를 사용할 Action 의 Response 가 Directive 또는 Directive + Prompt 로 선택되어 있어야 함
Directive 사용하기

30
 Backend proxy 에 Capability Interface 구현하기
 Directive 를 사용하기 위해서는 Backend proxy 에 Capability Interface 규격에 맞는 Directive를 구현
 사용자 발화가 어떤 디바이스 (스피커)의 기능을 요청하면 Play 는 Backend proxy 에 요청
 Backend proxy 는 요청에 맞는 Directive 를 Play 에게 전달
 따라서, Backend proxy 에서는 Play 의 Action 이 어떠한 Directive 를 사용하는지 확인하고 구현 필요

31
 Backend proxy 에 Capability Interface 구현하기
 AudioPlayer Interface 를 지원하는 디바이스에 Directive 가 전달되는 과정

32
 Capability Interface 를 사용함으로 설정하기
 Play Builder 홈 화면에서 Capability Interface 를 설정할 Play를 선택 한 후 General > 기본 정보 페이지의 ‘Capability
Interface 추가’ 에서 AudioPlayer Interface 제어 항목을 ‘ON’ 으로 설정

33
 Capability Interface 를 사용함으로 설정하기
 Built-in Intent 15개가 추가됨
 Built-in Intent 추가 여부는 User Utterance Model >
Built-in Intents 페이지에서 확인

34
 Action 에서 Directive 사용하기
 Capability Interface를 사용함으로 설정한 Play는 Response 유형이 다음과 같이 확장
 Directive 가 동작해야 할 Action 의 Response는 Directive 또는 Prompt + Directive 선택
 한 Play에서 여러 Directive를 사용하는 경우, Backend proxy 에서 Action 을 구분해서 Directive 전달

35
 Action 에서 Directive 사용하기
 Directive 는 Play 의 세션 밖에서만 동작
 Prompt + Directive 를 선택한 경우, Prompt 는 세션을 종료시키는 종료 Prompt 로만 구성
 Prompt 가 합성음으로 발화된 후 Directive 가 뒤이어 동작
 종료 Prompt 는 어떠한 기능이 동작할지 예고하는 용도로 사용하기를 권장
 Directive 만 단독으로 정의된 경우, 세션이 자동으로 종료된 뒤 Directive 가 동작
Response 유형 특징
Prompt
 Prompt만 합성음으로 발화
 Prompt의 유형을 선택 (대기/종료)
Prompt + Directive
 Capability Interface를 사용하는 Play에서만 선택할 수 있는 유형
 Prompt가 먼저 합성음으로 발화되며, Prompt 발화가 끝난 뒤에 Directive가 동작
 Prompt 유형을 선택할 수 없으며, 종료 Prompt로만 동작
Directive
 Capability Interface를 사용하는 Play에서만 선택할 수 있는 유형
 Directive만 동작

36
II. Action 정의하기 Response + Branch Action (Multi-turn 대화 구성하기)
 Action Tree 를 복잡하게 구성하여도 Tree 의 끝 Action 만 Response 를 갖기 때문에, 결국은 Single-turn 의 대화만 이루어 짐
 세션 안에서 여러 번의 Single-turn 대화를 반복할 뿐 기존 대화의 컨텍스트는 이어갈 수는 없음
 그러나, Output의 세번째 유형 Response + Branch Action 을 통해서는 컨텍스트를 이어 가는 Multi-turn 대화를 구성
 Response + Branch Action 이 선택된 Action 은 Response 를 내보낸 뒤에 사용자의 발화를 다시 듣고, Branch Action 중
조건을 만족시키는 Action 으로 이동
 Response + Branch Action 는 세 요소로 구성
 Response
 Branch Action
 Reprompt

37
 Response 의 특성
 Response + Branch Action 의 Response 는 대기 Prompt 만 사용
 대기 Prompt 발화 후에는 세션 초기로 돌아가지 않고,
 직전 사용자 발화 정보를 유지한 채 사용자 발화를 다시 듣는 대기상태로 이동
 대기 상태에서 사용자가 새로운 Intent 를 발화하거나 Entity 만 발화 하는 경우,
 해당 Intent/Entity 가 precondition 으로 지정된 Branch Action 이 있는 지 순차적으로 탐색하여 조건을 만족시키는
Action 으로 이동
Response + Branch Action (Multi-turn 대화 구성하기)

38
 Branch Action 의 특성
 Response + Branch Action 의 Branch Action 은 Default 지정이 필수가 아님
 Branch Action 의 precondition 을 하나도 만족시키지 못한 경우 Default Branch 로 이동
 Default Branch 가 없을 경우, Reprompt 를 발화

39
 Branch Action의 특성
 Branch Action 을 만들 때, precondition 으로 사용할 Entity 가 첫 Intent 에 없으면 Branch Action 의 precondition 을
정의할 수 없음
 이 경우, Utterance Parameter 의 Entity mapping 팝업 창에서 ‘다른 Intent의 Entity Type 더 불러오기’ 버튼 을 눌러, Play
내 모든 Entity Type 을 가져 온 다음 원하는 Entity Type 을 Utterance Parameter 에 매핑하여 사용

40
 Reprompt 의 특성
 Default Branch 를 지정하지 않은 경우, Reprompt 1개 이상 정의 필요
 Reprompt 는 마지막 발화부터 입력하는 스택 구조이며 LIFO (Last In First Out) 로 동작
 여러 개의 Prompt 를 입력하면 가장 마지막에 입력한 Prompt 부터 차례대로 사용자에게 응답
 Reprompt 를 2개 이상 입력한 경우, 두번째 Prompt 부터는 대기 Prompt 로 지정
 대기 Prompt 가 발화된 후에는 Multi-turn 시작 Response 후의 대기 상태로 이동하여 다시 사용자의 발화를 들음
 이동한 대기 상태도 기존의 컨텍스트를 유지한 채 다시 사용자의 발화를 듣는 대기 상태

41

42

43
II. Action 정의하기 예외 상황 관리
 Play 가 동작하는 과정에서 정상적인 응답을 하지 못하는 경우가 발생
 ‘예외 상황 관리’ 는 이렇게 정상적인 응답을 못하는 경우를 별도로 관리하는 공간
 Exception Code 와 그 상황에 나가게 될 메시지를 Prompt로 작성
 어떠한 상황이 예외 상황에 해당한다는 판단은 Backend proxy 에서 하며,
 Backend proxy 에서 Exception Code 를 전달 받으면 Action은 동작을 멈추고 Exception Prompt 를 사용자에게 전달
 예외 상황 관리는 Play 의 모든 Action 에 자동으로 적용되게 하거나, 각 Action 별로 설정할 수 있음
 각 Action 별로 정의한 Exception Code 는 해당 Action 에서만 유효
 예외 상황 관리는 Backend proxy 의 URL 이 등록되어 있어야 하고,
 Action 의 Backend proxy 사용여부가 On 되어 있어야 함

44
II. Action 정의하기 예외 상황 관리
 예외 상황 등록 방법
① Backend proxy 의 URL 을 입력 (http:// 또는 https:// 입력 필요)
② Backend proxy 사용 여부를 ‘ON’ 으로 설정
③ 예외 처리 영역에서 Exception Code 를 작성

45
④ Exception Prompt 필드에 응답할 Prompt 를 입력
Exception Code 하나 당 Exception Prompt 는 총 2개 입력 가능
처음 입력하는 Prompt 의 유형은 종료 Prompt로, 두번째로 입력하는 Prompt 는 대기 Prompt 로 자동 설정
예외 상황의 Prompt 는 스택으로 구성되어, LIFO (Last In First Out) 로 동작
예외 상황 관리

46
 예외 상황은 일반적으로 두 가지 종류
① 서버 장애, 네트워크 문제 등으로 인해 서비스 제공이 불가능한 경우
 사용자에게 서비스 제공이 불가능한 이유를 간단히 설명하고 세션을 종료해야 함으로 종료 Prompt 만 등록
② 사용자의 발화에서 분석된 Entity 에 문제가 있거나 Entity 간 정합성 문제 등으로 기능 동작이 불가능한 경우
 사용자에게 Entity 에 대해 문제가 있음을 안내하고 종료 Prompt 를 통해 세션을 종료할 수도 있으나,
 사용자로부터 정보를 입력받도록 대기 Prompt 를 추가 할 수 있음
 Exception Prompt 에서는 무엇이 문제인지를 간단하게 안내한 뒤, 해결 방법을 제시하여 사용자의 올바른 응답을 유도
 만약 세션 종료를 하는 경우 이를 안내해야 함

47
 라디오 스트리밍을 재생해주는 Play 를 만드는 경우
 Play 외부에 존재하는 스트리밍 서버의 장애가 발생할 가능성이 있음  예외 상황 ① 번에 해당
 해당 장애 발생 시 사용자에게 정상적인 서비스가 불가능한 이유를 간단히 안내하고 세션을 종료
 Exception Prompt 는 종료 Prompt 하나만 등록

48
 사용자 요청한 채널이 미지원 채널인 경우  예외 상황 ② 번에 해당
 이러한 경우, 종료 Prompt 만 사용하여 미지원 채널임을 안내하고 세션 종료
 또는 대기 Prompt 를 하나 더 추가하여 사용자에게 Entity 를 다시 입력 받도록 대기 상태로 이동

49
 사용자로부터 목적 시간이나 날짜를 입력 받는 Play 에서는,
 ‘2월 31일’ 과 같이 특정 월을 나타내는 Entity 와 특정 일을 나타내는 Entity 의 조합이 맞지 않는 경우가 발생  예외
상황 ② 번에 해당

50
 사용자 발화의 Entity 를 체크하는 예외 상황을 등록한 경우, Exception Code가 동작하는 과정

51
 Exception Prompt 를 통해 이동한 대기 상태 특정
 대기 Prompt 에 의해 활성화되는 대기 상태는 사용자가 발화한 Intent 에 포커스 를 둔 상태에서 추가로 발화를 듣는 상태
 대기 상태에서는 사용자의 추가 발화로부터 Entity 를 신규로 입력 받거나, 업데이트 할 수 있음
 이 Entity 는 해당 Action 의 Utterance Parameter 에 연결된 Entity Type 일 때만 유효
 예를 들어, “2월 31일 날씨 알려줘” 라고 하여 예외 상황으로 체크하고 대기 상태로 이동 시,
 사용자가 “2월 28일 금요일 날씨 알려줘” 라고 다시 발화했다면, 특정 일을 의미하는 ’31일’ 은 ’28일’ 로 업데이트
 ‘금요일’ 은 신규로 입력 받아 Parameter 에 담아 Backend proxy 로 다시 전달

52
 Exception Prompt 를 통해 이동한 대기 상태 특정
 즉, 정의되어 있으나 비어 있는 Utterance Parameter 가 있다면 해당 Parameter 를 Entity로 채울 수 있고,
 이미 Parameter를 채운 Entity 와 같은 Type 의 값이 있다면 기존 Parameter 의 값을 새로운 Entity 로 대체
 Exception Prompt 를 통한 대기 상태에서는 이와 같이 Entity 만 추가로 받을 수 있음
 추가 발화를 입력 받아도 Entity 를 채울 수 없는 경우에는 두번째 Exception Prompt 를 내보내고 세션이 종료

53
II. Action 정의하기 Response Filter 정의하기
 Response Filter 는 Action 의 Prompt 입력 시 사용 가능
Response Filter 종류 특성 기호
NLG Translator
 정해진 규칙에 의해 값을 변환
 1이 들어오면 'a'로, 2가 들어오면 'b'로 변환
>
NLG Normalizer
 정해진 규칙에 의해 값을 변환
 한번에 여러 가지 값을 일괄 변경
 1,2,3이 들어오면 'a'로, 3,4,5,6,7이 들어오면 'b'로 변환
=
NLG Function  정해진 규칙에 맞게 값을 변환 :

54
III. Response Filter 정의하기
 NLG Translator
 날씨 안내 시, “오늘 날씨는 {{status}}” 같이 기상 정보 API에서 날씨 상태 값을 체크한 뒤 Backend proxy 에서 “맑겠습니다”,
“눈이 올 예정입니다” 와 같이 Prompt 의 일부를 처리하는 것도 가능
 이렇게 Play 를 만들 경우, 최종적으로 나갈 Prompt 의 내용을 Play Builder 에서 확인하기 어렵고, Backend
proxy에서도 별도로 관리해야 함
 문장 하나를 수정 하려고 해도 외부 연동 서버 개발자가 함께 Prompt 수정해야 하기 때문에 수시로 응답을 바꿔가며 Play
를 운영하기 어려움
 이러한 경우, Parameter {{status}} 에는 날씨 상태를 나타내는 코드를 담고, 이 Parameter 에 NLG Translator를
사용하여 각 코드 별 응답을 입력하여 처리하면, 조금 더 유연한 대응이 가능
Response Filter 정의하기

55
 NLG Translator
① Play 를 선택한 후 Response Filter > NLG Translator > NLG Translator 추가
② Translator 의 Filter 명을 입력하고, 변경 전의 값을 Source 에 바뀔 값을 Target 에 각각 입력

56
 NLG Translator
 이렇게 Translator 가 적용된 {{status}} Parameter 에 “01” 이라는 값이 들어오면 Translator 가 “맑겠습니다.” 라는
텍스트로 변환
 Parameter 에 담긴 값이 Filter 의 Source 와 정확히 일치할 때만 동작 (String match)
 Response Filter 를 쉽게 입력할 수 있도록 자동완성 기능 지원
Parameter 의 끝의 기호 }} 뒤에 특수기호 > 를 입력하면 앞서 정의한 NLG Translator 의 리스트가 표시되며, 원하는
Filter 선택 가능

57
 NLG Normalizer
 Translator 와 기능이 유사하지만, 여러 개의 Source 를 하나의 Target 으로 변경
① NLG Normalizer 를 추가할 Play 를 클릭하여 선택한 후, Response Filter > NLG Normalizer > NLG Normalizer 추가
② Normalizer 의 Filter 명을 입력하고, 변경 전의 값을 Source 에 바뀔 값을 Target 에 각각 입력

58
 NLG Normalizer
 자동 완성 기능으로 적용하기 위한 기호는 = 이며, 사용 방법은 NLG Translator 와 같음

59
 NLG Function
① NLG Function 를 추가할 Play 를 클릭하여 선택한 후, Response Filter > NLG Function 선택
② NLG Function 타입을 선택 및 이름을 입력하고, 변경 전의 값을 Source에 바뀔 값을 Target 에 각각 입력
 NLG Function 은 날짜 형식에 사용하는 DATE 타입을 제공
 날짜 형식에 맞는 문자열이 있다면, 보다 더 적합한 날짜 형태로 변경
③ NLG Function 의 자동완성을 위한 기호는 : 이며, 사용 방법은 NLG Translator와 같음

60
IIV. 테스트 하기
 Play 가 제대로 동작하는지 테스트 하는 방법은 크게 두가지
 Play Builder 에서 채팅으로 테스트
 Play Builder 를 통해 직접 학습 시킨 Intent 에 대해 어떻게 분석이 되고 어떻게 동작하는지 확인 할 수 있는 테스트
 NUGU 디바이스에서 음성으로 테스트
 실제 사용자에게 제공될 서비스 그대로를 점검할 수 있는 테스트
 NUGU Play Kit 에서 사용할 NUGU 디바이스 등록 필요

61
IIV. 테스트 하기
① Play Builder 우측 상단에 있는 테스트 버튼을 클릭하여 채팅창에 발화 내용을 입력한 후 버튼 클릭
 단축키 Ctrl + D 를 눌러 실행
 사용자의 실제 발화를 어떻게 분석할지 확인할 수 있으며, 이 분석 결과를 바탕으로 실제로 의도한 대로 Prompt 가 나가는지
확인 가능
Play Builder 에서 채팅으로 테스트하기

62
IIV. 테스트 하기 Play Builder 에서 채팅으로 테스트하기
② 분석 결과를 확인하려면 입력 문장 바로 아래의 ‘NLU 분석 결과 열기’ 를 클릭

63
 NLU 분석 결과는 문장을 직접 입력하여 학습시킨 Custom Intent 에 대해서만 분석
 Custom Intent 를 Trigger 로 사용하는 Custom Action 에 대해 Response 중 Prompt 만 확인 가능
 Built-in Intent (그만, 다시 등) 은 테스트 내에서 분석되지 않으며, NUGU.ACTION.fallback 에 등록된 Prompt 응답
 다만 응답을 Directive + Prompt 로 정의한 경우에는 Prompt 만 나가게 됨
 Directive 만 등록한 경우에는 빈 칸으로 응답이 나가게 됨
 Backend proxy 사용 시, Backend proxy 가 처리하는 항목들 (Backend Parameter, 예외 상황 처리) 도 테스트 가능
 그러나 Backend proxy 가 Oauth 를 통해 사용자를 특정하여 서비스를 제공하는 경우에는 테스트 불가능

64
 테스트 가능 항목
 직접 등록한 Custom Intent
 Custom Intent 를 Trigger 로 하는 Custom Action 의 Prompt 결과
 테스트 불가능 항목
 Built-in Intent (NUGU.INTENT.stop / NUGU.INTENT.rewind) 의 테스트
 Directive
 Backend proxy 에서 Oauth 를 통해 사용자를 특정하여 제공하는 기능
 테스트 시 Wake-up word (아리아, 팅커벨), Play 호출 이름을 붙여서 발화한 것 처럼 동작
 테스트 시 SKML 태그는 결과창에 그대로 나오나, 실제로 발화되지는 않음

65
IIV. 테스트 하기 NUGU 디바이스에서 음성으로 테스트 하기
 Play 의 상태가 등록중 / 심사대기 / 심사반려 / 심사중 / 심사완료 / 배포대기 중인 경우 스피커에서 테스트 가능
 NUGU 디바이스에서 테스트는 Play 의 상태가 테스트 가능해 진 후, 다음날부터 가능
 하루가 지나도 NUGU 디바이스에서 Play 테스트할 수 없다면, Support > 문의 사항으로 문의

66
IIV. 테스트 하기 테스트용 디바이스 설정하기
 개발한 Play 를 테스트해 보기 위해서는 NUGU developers 의 사용자 계정에 NUGU 디바이스를 테스트 기기로 등록
 테스트 디바이스를 등록하기 전에 확인 해야 할 사항
NUGU 디바이스에 연결된 계정이 NUGU developers 에서 사용하는 계정인지 확인 (NUGU App 에서 로그인 후 디바이스 연결)
테스트 기기를 등록할 NUGU 디바이스의 전원 확인
테스트 기기는 최대 10대까지 등록 가능

67
① NUGU developers > 회원 정보 관리 (우측 상단) 를 클릭하여 회원 정보 페이지로 이동
② 테스트 기기 등록 메뉴에서 ‘디바이스 검색’ 버튼을 클릭

68
③ 테스트 기기 추가 팝업에서 등록할 디바이스를 선택한 후 ‘확인’ 을 눌러 테스트 기기를 등록
 테스트 기기 등록이 완료되면 테스트 기기 등록 메뉴의 등록된 기기 목록에 등록된 디바이스가 표시
 NUGU 디바이스 테스트를 중지하려면, 등록된 디바이스 우측의 – 버튼을 클릭하여 디바이스를 삭제

[NUGU Dev Days Advanced] NUGU Play Kit으로 Play 만들기 (Advacned)

[NUGU Dev Days Advanced] NUGU Play Kit으로 Play 만들기 (Advacned)

Recommended

Recommended

More Related Content

Similar to [NUGU Dev Days Advanced] NUGU Play Kit으로 Play 만들기 (Advacned)

Similar to [NUGU Dev Days Advanced] NUGU Play Kit으로 Play 만들기 (Advacned) (20)

More from NUGU developers

More from NUGU developers (20)

[NUGU Dev Days Advanced] NUGU Play Kit으로 Play 만들기 (Advacned)