링크

에이전트

Dialogflow CX 에이전트는 끝단의 사용자와의 대화를 처리하는 가상 에이전트이다. 이것은 인간 언어의 미묘한 차이를 이해하는 자연어 이해 모듈이다. Dialogflow는 대화로 이루어진 사용자의 텍스트나 오디오를 앱과 서비스가 이해할 수 있는 구조화된 데이터로 변환한다. 시스템에 필요한 대화 유형을 처리하도록 Dialogflow 에이전트를 직접 설계하고 빌드할 수 있다. 이거는 MS chatbot과 다름이 없어보인다.

Dialogflow 에이전트는 콜센터 상담원과 비슷하다. 둘 다 예상되는 대화 시나리오를 처리하도록 학습해야 하며, 학습이 지나치게 명시적일 필요는 없다. 즉 대화 플로우(다이얼로그)는 정의해놓긴 하되 자연어 처리 학습을 통해 우리가 잘 해줄테니까 너무 명시적으로 대화를 정의하지는 말아라 이소리 같기는 하다.

흐름

복잡한 대화상자에는 여러 가지 대화 주제가 포함되는 경우가 많다.(다이얼로그를 여러개 가질 수 있다.) 피자 배달 에이전트는 음식 주문, 고객 정보, 확인을 별도의 다이얼로그로 가질 수 있다. 각 주제마다 에이전트가 끝단의 사용자에세 정보를 얻기 위해서는 여러 번 번갈아가며 대화를 해야 한다. 아마 flow는 ms chatbot을 개발할 때 사용했던 step과 비슷한 개념인 것 같다.

흐름(Flow)는 이런 주제와 연결된 대화 경로를 정의하는 데 사용된다. 모든 에이전트에는 기본 시작 흐름이라는 흐름이 있다. 간단한 에이전트는 이 단일 흐름만 사용할 수도 있다. 복잡한 에이전트에는 추가적으로 flow가 더 많이 필요할 수 있으며, 이런 흐름을 빌드하고 유지 관리할 수 있다. 흐름은 추가 비용을 요구하지 않는다.

페이지

Dialogflow CX 대화(세션)을 상태 머신으로 설명하고 시각화할 수 있다. CX 세션의 상태는 페이지로 표시할 수 있다.

각 흐름에 대해 여러 페이지를 정의하면 조합된 페이지에서 흐름이 설계된 주제에 대한 완전한 대화를 처리할 수 있다. 특정 시점에 정확히 하나의 페이지는 현재 페이지이고, 현재 페이지는 활성 페이지로 간주되고, 해당 페이지와 연결된 흐름은 활성으로 간주한다. 모든 흐름에는 특수한 시작 페이지가 있다.

처음에 흐름이 활성화되면 시작 페이지가 현재 페이지가 된다. 각 대화 차례에서 현재 페이지는 동일하게 유지되거나 다른 페이지로 전환된다. 아마 페이지가 다이얼로그의 개념일 것 같다.

페이지가 나타내는 대화 상태와 관련된 정보를 사용자로부터 수집하도록 각 페이지를 구성한다. 즉 여러 흐름들로 페이지를 구성하라는 것 같다.

항목 유형(Entity types)

(원래 한국어 버전의 문서가 있는데, 너무 번역기로 돌린 것 같아 내가 그냥 번역했다.)

Entity type은 끝단 사용자의 입력에서 어떻게 데이터가 추출되는지 제어하기 위해 사용된다. CX entity type은 ES entity type과 굉장히 유사하다.

Dialogflow는 다양한 일반적인 타입의 데이터에 맞출 수 있는 미리 정의된 시스템 엔티티를 사용한다. 예를 들어, 날짜, 시간, 색, 이메일 주소에 맞출 수 있는 시스템 엔티티들이 있다. 또한 커스텀한 데이터에 맞는 자신만의 커스텀데이터를 만들수도 있다. 예를 들어, 채소 가게 에이전트에서 결제를 할 수 있게 야채의 종류에 맞는 야채 엔티티를 만들 수도 있다.

Parameters

Patameter는 한 세션에서 사용자가 제공한 값들을 캡쳐하고 참조하기 위해 사용된다. 각 파라미터들은 이름을 가지고 있고 얘네들은 각각 엔티티 타입이다. 날 것의 사용자 입력과는 달리, 파라미터들은 특정 로직을 수행하거나 일반적인 응답에 쉽게 사용할 수 있도록 구조화된 데이터들이다.

CX 파라미터들은 ES 파라미터와 비슷하지만, 성능과 스코프가 확장되었고, 파라미터를 참조하는 문법이 바뀌었다.

Forms

각 페이지마다 페이지에서 사용자들에게서 받아야 하는 파라미터의 리스트인 form을 정의할 수 있다. Agent는 모든 요구되는 page parameter라고 알려진 form parameter 들을 모두 가져오기 전까지 사용자와 상호작용한다. 각 form parameter들에 대해, 당신은 그 정보를 사용자에게 요청하기 위해 에이전트가 사용할 prompt를 제공할 수 있다. 이 프로세스는 form filling이라 불린다.

예를 들어, Collect Customer Info 페이지를 위한 사용자 이름과 전화번호를 받는 form을 만들 수 있다.

Intents

Intent는 한 대화 턴에서 사용자의 의도를 카테고리화 한다. ES intent과는 다르게, CX intent는 그것을 더 재사용이 가능한 리소스로 만들 수 있게 단순해졌다.

intent는 아래의 데이터를 포함한다. (약간 QnA Maker와 비슷한 것 같다)

training phrases	트레이닝 문구는 사용자가 입력하거나 말하는 것- 즉 end-user input의 예시 문구이다. 이 중 하나를 사용자가 말할 경우, Dialogflow는 intent와 매칭시킨다. 물론 이걸 가능한 모든 답변을 정의할 필요는 없다. 왜냐하면 Dialogflow안에 내장된 머신 러닝이 비슷한 답변들을 매칭시켜줄 것이기 때문이다.
Parameters	사용자의 입력의 특정한 부분에서 값들을 추출하기 위한 파라미터를 사용하기 위해 training 문구를 정의한다.

Webhook

Webhook은 비즈니스 로직을 운영하는 서비스이다. 세션 중에, 웹훅은 다양한 답변과 추출된 유효한 데이터, 혹은 백엔드에서 특정 행동을 실행시키기 위한 다이얼로그 플로우의 자연어처리 프로세싱에 의해 추출된 데이터를 사용하게 해준다.

Fulfillment

에이전트의 대화 턴에서 에이전트는 질문을 하거나, 정보에 대한 쿼리를 하거나, 세션을 종료하기 위해 사용자에게 응답을 해야 한다. 에이전트는 다양한 응답을 생성하거나 특정 행동을 하기 위해 서비스와 연결해야 할 수도 있다. Fulfillment는 이 모든 것을 가능하게 하기 위해 사용된다.

Fulfillment는 다음의 것을 포함할 수 있다:

• 정적 응답 메시지
• 다양한 응답/액션을 하기 위한 웹훅 call
• 파라미터 값들을 덮어쓰거나 설정하기 위한 파라미터 프리셋

Agent의 턴에서, 각각 응답 메세지를 만들 수 있는 fulfillment들을 여러개 부를 수 있다(어떤 때는 이것을 하는 것이 필수적일 수 있다). Dialogflow는 이 응답들을 response queue에 유지한다. Agent의 턴이 끝나면, Dialogflow는 이 정렬된 응답들을 사용자에게 보낸다.

State Handler

간단히 handler라고 불리는 State handler들은 사용자에게 응답할 메세지를 만들거나 현재 페이지의 상태를 변경해서 대화를 통제한다. 각 대화 턴에서, handler들은 평가되고 세션에 영향을 줄 수 있다. Handler들은 세개의 일반적인 데이터 타입을 가진다.

Handler requirements	이것은 세션에 영향을 주기 위해 핸들러가 충족해야 하는 요구사항이다. 핸들러는 요구사항을 충족하고 세션에 영향을 줬을 때 called되었다고 말한다.
Handler fulfillment	만약 핸들러가 불러졌다면, 사용자에게 답을 할 응답을 만들기 위해 선택적으로 fulfillment가 사용될 수 있다. 이런 응답들은 정적 에이전트 데이터나 웹훅 서비스에 의해 동적으로 가져와진 형태로 정의될 수 있다.
Handler trasition target	핸들러가 불러졌다면, 현재 페이지를 바꾸기 위해 선택적 transition target이 사용될 수 있다. 다음 페이지는 flow start page가 현재 활성화된 플로우가 동작하는 페이지만 올 수 있다.

아래는 handler requirements 를 달리 갖고 있는 두 타입의 상태 핸들러이다.

Routes	Routes는 사용자 입력이 intent와 일치하거나 세션 상태의 어떤 조건과 일치할 때 불려진다. intent requirement를 갖고 있는 route를 intent route라고도 부른다. Condition requirement만 갖고 있는 route를 condition route라고도 부른다.
Event handlers	Event handler들은 이벤트가 발생했을때 불려진다. 이미 내장된 이벤트들은 예상치못한 사용자의 입력이 들어왔거나, 웹훅 에러가 발생했을 때 발생한다. 대화 밖에서 어떤 일이 발생했을 때 불러올 커스텀 이벤트도 정의할 수 있다.

아래는 상태 핸들러를 작동시키기 위한 세가지 단계이다.

1. Scope handler는 세션에 영향을 미치기 위해 무조건 scope안에 있어야 한다.
2. Evaluation 스콥에 있는 각 핸들러들은 우선순위가 있다. 만약 핸들러 요구사항이 충족되었을 경우에 evalutation을 넘긴다.
3. Call 만약 스콥에 있는 핸들러가 evaluation을 넘겼다면, 이것은 called된 것이다.

Console

Dialogflow는 Dialogflow CX Console이라는 웹 유저 인터페이스를 제공한다. 이 콘솔을 이용해서 CX agent들을 만들고, 빌드하고, 테스트해볼 수 있다.

CX Console은 ES Console과 비슷한 목적을 갖고 있지만, CS Console 유저 인터페이스가 더 시각적으로 보기 좋다. 각 플로우를 대화 상태 머신으로 그래프를 그려 복잡한 agent들 디자인하고 이해하기 쉽게 만든다.

Dialogflow CX Console은 GCP 콘솔과는 다르다. Dilogflow CX Console은 Dialogflow CX agent를 관리하기 위한 것이고, GCP console은 GCP 특정 다이얼로그 플로우 CX setting과 다른 GCP 자원들을 관리하기 위해 사용된다.

대부분의 상황에서 Dialogflow CX Console를 agent를 만들기 위해 사용하지만, 더 복잡한 시나리오를 위한 agent를 만들기 위해 Dialogflow CX API를 사용할 수도 있다.

사용자의 API와의 상호작용

CX를 위한 API를 사용하는 것은 ES를 위한 API를 사용하는 것과 비슷하지만, 몇 resource path과 자원이 새로운 타입, 함수, 필드를 수용하기 위해 수정되었다.

시스템은 아래의 것을 다뤄야 한다.

• Dialogflow CX는 현재 제한된 수의 integration만을 지원하므로, 시스템은 사용자와 직접적으로 소통할 수 있는 유저 인터페이스가 필요할 것이다.
• 사용자 입력을 API에 보내기 위해 DialogflowAPI를 각 대화 턴마다 불러야 한다.
• agent 응답이 정적이지 않다면, webhook-enabled fulfillment를 다루기 위해 웹훅 서비스를 호스팅해야 할 것이다.

아래의 다이어그램은 세션의 한 대화 턴에서 이뤄지는 단계를 보여준다.

1. 끝단의 사용자가 어떤 것을 타이핑하거나 말한다(end-user input)
2. 사용자 인터페이스 시스템은 입력을 받고 그것을 detect intent request로 Dialogflow API에 넘긴다.
3. Dialogflow API는 detect intent request를 받는다. 입력을 intent나 form parameter와 매칭시키고, 파라미터를 필요할 경우 설정하며, 세션 상태를 업데이트 한다. 만약 webhook-enabled fulfillment를 부르는 것이 필요하다면, 웹훅 서비스에 웹훅 요청을 보낸다. 아니라면 스텝 6로 바로 간다.
4. 웹훅 서비스는 웹훅 요청을 받는다. 서비스는 외부 API를 부르거나 데이터베이스를 쿼리하거나 업데이트 하는 것과 같은 행동들을 필요할 경우에 수행한다.
5. 웹훅 서비스는 응답을 만들고 Dialogflow에 웹훅 응답을 전송한다.
6. Dialogflow는 detect intent response를 만든다. 만약 웹훅이 불러졌다면, 웹훅 응답에 제공되는 응답을 사용한다. 만약 ㅏ움런 웹훅이 불러지지 않아다면, 에이전트에 이미 정적으로 만들어져 있는 응답을 사용한다. 다이얼로그플로우는 유저 인터페이스 시스템에 detect intent response를 보낸다.
7. 유저인터페이스 시스템은 detect intent response를 탐지하고 이것을 텍스트나 오디오 응답으로 사용자에게 보낸다.
8. 끝단의 사용자는 응답을 보거나 듣는다.