회사에서 챗봇을 개발할 일이 생겼다.

여기서는 Dialogflow CX로 어떻게 겨츠 주문 에이전트를 만들고 테스트하는지 보여준다. 이 에이전트와 대화하면서, 상점 위치, 영업 시간, 주문을 할 수 있다.

다 만들어진 에이전트는 아래와 같이 그래프화 될 수 있다.

에이전트 만들기

1. Dialogflow CX Console을 연다.
2. GCP 프로젝트를 만들거나 고른다.
3. +Create를 누른다.
4. 폼에 기본 설정을 입력한다.
5. Save를 누른다.

기본 플로우와 의도

아래의 플로우와 의도는 새로운 agent를 위해 자동적으로 생성된다. Manage를 클릭하고, Intents를 클릭해서 intent를 찾을 수 있다. Build를 눌러서 플로우를 찾을 수 있다.

기본 환영 Intent	기본 환영 intent는 “Hi”나 “Hello”와 같이 초기 사용자를 환영하기 위한 학습 문구를 가지고 있다. 이런 문구를 원할 시에 수정할 수 있다.
기본 부정 Intent	기본 부정 intent는 부정적 예시와 같이 행동하는 intent에 학습 문장을 추가하는데 사용될 수 있다.
기본 시작 flow	기본 시작 flow는 유일한 flow로 사용될 수 있다. 더 복잡한 agent에서, 더 많은 흐름을 추가할 수 있다.

기본 환영 메세지 응답 테스트하기

기본 플로우와 intent는 환영 메세지로만 기본 대화를 다룰 수 있다. 테스트하려면 아래와 같이 하면 된다.

1. Test Agent 버튼을 클릭해서 시뮬레이터를 연다.
2. hello를 text entry에 입력하고 엔터를 눌러라.
3. Agent가 기본 환영 인사로 응답한다.
4. 시뮬레이터를 닫아라.

참 편리하다… MS bot framework에서는 이런 것들을 하려면 qna maker를 이용하거나 일일히 코딩해줘야 했는데…

그리고 역시 한국어다보니 존댓말이나 파생어에 대해서는 학습이 부족한 듯한 모습을 보였다.

아래의 단계들이 agent가 이 사용자 입력을 처리하기 위해 이루어졌다.

1. 내가 말을 입력했을때, Default Start flow가 활성화된 흐름이고, 흐름의 시작 페이지가 활성화된 페이지이다. 각 상태 핸들러들은 scope에 있는 활성화된 플로우에 적용되고, agent가 그것을 평가한다.
2. 평가된 루트 중 하나는 intent 요구사항으로 기본 환영 intent를 가지고 있다. 내 입력이 이 intent과 일치했기 때문에 이 route가 불려진 것이다.
3. 불려진 루트는 여러개의 fulfillment 응답 메세지를 가지고 있다. Agent는 그 중 하나를 골라서 response queue에 추가한다.
4. 불러진 루트는 전환 타겟이 없기 때문에 활성화된 플로우와 페이지는 변하지 않는다.
5. Agent는 response 큐에 있는 컨텐츠로 응답을 한다.

환영 응답 메세지 수정하기

이 환영 인사를 수정할 수도 있다.

1. Build 탭을 누른다.

2. Flow section에 있는 Default Start Flow를 선택한다.

3. 그래프에 있는 Start 노드를 클릭한다. 이것은 Default start flow의 시작 페이지이다.

4. Default Welcome Intent를 찾고 클릭한다. 이것은 intent route 정보를 수정하는 판넬을 띄운다.

5. Fulfillment section을 찾고 모든 응답 메세지를 지우고 Hello, this is a shirt ordering virtual agent. How can I help you?를 입력한다.

6. Save를 누른다.

와 근데 확실히 인터페이스가 있으니까 같은 작업을 해도 더 편하게 느껴지는 것 같다.

업데이트 된 새로운 응답 메세지 테스트하기

1. Test Agent를 클릭해서 시뮬레이터를 연다.
2. 똑같이 안녕이라고 쳐본다.
3. 내가 지정한 메세지로 응답이 올 것이다.
4. 시뮬레이터를 닫는다.

위치 페이지 저장하기

Dialogflow CX 대화(세션)은 상태 머신으로 시각화되어 설명될 수 있다. CX 세션의 상태는 페이지로 표현된다. 만약 오직 하나의 페이지만 갖고 있다면, agent는 별 쓸모가 없다. 이 파트에서, 가게의 위치를 물어보는 질문을 다루는 다른 페이지를 만들 것이다.

장소 intent 만들기

Intent는 한 대화 턴에서 사용자의 의도를 카테고리화 한다. Intent를 만들기 위해 아래의 단계를 수행한다.

1. Manage 탭을 선택한다.

2. Intent를 클릭한다.

3. Create를 클릭한다.

4. Intent 이름으로 store.location을 입력한다.
5. Training 문구를 아래와 같이 입력한다.

근데 웃긴건 내 컴퓨터 문제인지 뭔지 모르겠는데 한글을 입력하려고 하면 사진처럼 글이 엄청 이상하게 입력된다….

1. 저장을 누른다.

장소 페이지 생성

이제 새로운 페이지를 만들어보자. 페이지가 활성화되기만 하면 불려지는 entry fulfillment를 페이지에 추가할 수 있다. 이 entry fulfillment는 가게의 장소를 제공하는 응답 메세지를 갖고 있어야 한다.

1. Build 탭을 누른다.
2. Flow 섹션에 있는 Default Start Flow를 선택한다.

3. Pages 섹션에 있는 + 버튼을 클릭하면 이름을 입력하는 부분이 나올 것이다.

4. Store Location을 입력하고 엔터를 누른다.
5. 페이지 이름 옆에 있는 옵션 버튼(점 세개가 세로로 나열되어있는 버튼)을 누른다.
6. Edit을 선택해서 수정 패널 페이지를 연다.

7. Entry dialog를 찾고 Edit fulfillment를 클릭한다.

8. Our store is located at 1007 Mountain Drive, GOtham City, NJ를 Agent Says 필드에 입력한다.

9. 저장 버튼을 클릭한다.

10. 페이지 수정 판넬을 닫는다.

Flow에 장소 intent 루트를 추가하기

이제 transition target으로 설정할 가게 장소 페이지를 갖고 있는 루트를 만들어야 한다. 이 루트가 불려지면, 세션은 가게 장소 페이지로 전환된다. 이 루트는 Default Start Flow에 적용돼서, 흐름이 활성화되는 한 scope에 존재한다. 단일 플로우 agent에게 이것은 route는 항상 scope 안에 있다는 말이 된다. 대화의 어느 부분에서든, 사용자는 장소를 물을 수 있고, 이 루트가 불러와진다.

1. Build 탭을 누른다.
2. Flows 섹션에 Default Start Flow 를 선택한다.
3. Start 노드를 클릭한다. 이건 Default Start Flow르 위한 시작 페이지이다.
4. 아래의 intent route를 추가한다.
   • Intent: store.location

• Transition Page: Store Location

1. Save 버튼을 누른다.
2. 의도 루트 수정 판넬을 닫는다.

가게 장소 페이지 테스트

1. Test Agent 버튼을 클릭해서 시뮬레이터를 켠다.
2. Store location… 위에서 장소를 물어보는 질문을 입력한 후 엔터를 누른다.
3. Agent가 주소를 알려준다.
4. 시뮬레이터를 닫는다.

여기서는 아래와 같은 일들이 수행된다.

1. 입력을 하면, Default Start Flow가 활성화된 플로우가 되고, 플로우의 시작 페이지가 활성화된 페이지가 된다. 활성화된 플로우에 적용된 각 상태 핸들러들이 scope안에 있어서, agent는 그것을 평가한다.
2. 평가되는 루트중 하나가 store.location을 intent 요구사항으로 갖고 있다. 입력이 이 intent와 일치했기 때문에, 이 루트가 불려졌다.
3. 불려진 루트는 fulfillment 응답 메세지가 없었기 때문에, response 큐에는 아무것도 추가되지 않았다.
4. 불려진 루트는 transition target을 가지고 있었기 때문에, 활성화된 페이지가 store location 페이지로 넘어간다.
5. Store location 페이지는 entry fulfillment를 가지고 있었기 때문에, fulfillment를 위한 응답 메세지가 응답 큐에 추가된다.(주소)
6. Agent가 응답 큐에 있는 컨텐츠들을 응답한다.

inline creation을 이용한 가게 영업 시간 페이지

이 파트에서, 가게 시간에 대해 묻는 사용자의 입력을 다룰 것이다. 이전에는, Build와 Manage 탭에서 페이지와 intent를 만들었다. 이 탭은 이것을 inline creation으로 타이핑을 통해 더 빨리 만드는 것을 보여준다.

1. 그래프의 Start 노드를 클릭한다.
2. Intent route를 클릭하고 + 버튼을 클릭한다. Intent route 수정 패널이 열릴 것이다.

3. Intent 섹션에서, New Intent를 선택한다. Intent 수정 패널이 생긴다.

4. store.hours의도를 아래의 training 문구와 함께 생성한다.
   • What are your store hours?
   • What time do you close?
5. Save를 눌러 저장한다.
6. Transition 섹션으로 내려온다.

7. Page 부분에서 New page를 선택한다.

8. Store Hours를 입력한다.

9. 저장 버튼을 누른다. 전환하려는 페이지가 생겼기 때문에 이제 새로운 페이지가 그래프에 뜬다.

10. intent route 수정 판넬을 닫는다.
11. Store Location에서 했던 것과 비슷하게, 가게 영업 시간을 제공하는 entry fulfillment를 추가한다.

1. 모든 수정 패널들을 닫는다.

주문 페이지

다음에는, form 파라미터를 사용할 페이지를 만든다. 사용자가 새로운 셔츠 주문을 할때, 세션은 이 페이지로 이동한다. 활성화되면, 이 페이지는 사이즈와 색에 대한 정보를 받는다.

셔츠 사이즈에 대한 사용자 지정 엔티티 타입 생성

엔티티 타입 사용자의 입력에서 데이터가 어떻게 추출되는지 관리하는데 사용된다. Dialogflow는 많은 일반적인 데이터 타입에 매칭할 수 있는 이미 정의된 시스템을 제공한다. 예를 들어, 날짜, 시간, 색, 이메일 주소와 같은 것에 매칭할 수 있는 시스템 엔티티들이 있다. 또한 커스텀 데이터에 일치하는 커스텀 엔티티를 만들 수 있다.

이 agent에서 셔츠 색에 대한 시스템 엔티티를 사용할 수 있지만, 셔츠 사이즈에 대한 커스텀 엔티티를 만들어야 한다. 타입은 아래와 같은 엔티티 entry를 갖고 있어야 한다.

엔티티	동의어
small	small, tiny, little
medium	medium, regular, average
large	large, big, giant

1. Manage 탭을 선택한다.
2. Entity type을 클릭한다.

3. +Create 버튼을 누른다.

4. 이름을 size로 설정한다.
5. 위에 있는 엔트리 테이블을 입력한다.
6. 저장 버튼을 누른다.

Intent 파라미터를 가진 order intent 만들기

사용자의 요청이 새 셔츠 주문과 일치했을 때의 intent가 필요하다. 이 intent는 또한 필요한 셔츠 색와 사이즈를 사용자한테서 받아야 한다.

파라미터들은 세션 중에 사용자가 제공한 것에서 값들을 추출하고 참조하기 위해 사용된다. 각 파라미터들은 이름이 있고 엔티티 타입이다. 날것의 사용자 입력과 달리, 파라미터들은 특정 로직을 수행하거나 응답을 만들기 위해 사용될 수 있는 구조화된 데이터이다.

사용자가 제공한 데이터를 추출하는 방법을 학습 문장의 일부분에 annotating을 하고 관련된 intent 파라미터들을 구성함으로써 관리할 수 있다. 예를 들어, “What is the forecast tomorrow for Korea?”라는 학습 문장을 생각해보자. “tomorrow”를 날짜 파라미터, “Korea”를 지역 파라미터로 별명을 붙여야 한다. 학습 문장의 일부에 별명을 붙이면, Dialogflow는 이것들이 실행중에 사용자들이 제공하는 실제 값의 예시임을 알 수 있다.

1. 학습 문장에서 별명을 붙이고 싶은 부분을 선택한다.

2. 리스트에서 엔티티 타입을 선택한다.

3. 밑에 있는 파라미터 테이블에 파라미터가 생성된다.

order page 생성

아래의 설정으로 새로운 주문 페이지를 생성한다.

• Name: New Order
• Entry fulfillment: Ok, let's start a new order

order page에 form 추가

각 페이지에 대해서, 사용자에게 얻어야 하는 파라미터의 리스트인 form을 정의할 수 있다. Agent는 page parameter라고도 알려진 form parameter들이 모두 얻어질때까지 사용자와 계속 대화를 반복한다. 각 form 파라미터에 대해, 그 정보를 사용자에게 요청하기 위해 agent가 사용하는 prompt를 제공할 수도 있다. 이것을 form filling이라고 한다.

끝단의 사용자가 intent match를 위한 Intent 파라미터를 제공했을 때, Intent 파라미터는 세션 파라미터가 된다. 그래서 만약 끝단의 사용자가 order.new intent가 매칭되었을 때 사이즈와 색을 제공하면, 이런 값들이 form에 자동적으로 채워질 것이다.

새로운 order page에서, 두개의 form 파라미터를 정의해야 한다.

1. New order 페이지를 클릭한다.
2. Parameters의 + 버튼을 클릭한다.
3. 사진대로 테이블을 채운다.

flow에 주문 intent route를 추가

Default Start flow에 루트를 추가해라.

• Intent: order.new
• Transition Target page: New Order

확인 페이지

이제 마지막 페이지는 주문을 확인하고 세션을 종료할 것이다.

확인 페이지 생성

주문을 확인하기 위해 세션 파라미터를 사용하는 응답을 포함해 확인 페이지를 만든다.

• Name: Order Confirmation
• Entry Dialogue: You can pick up your order for a $session.params.size $session.params.color shirt in 7 to 10 business days. Thank you for buying our product.

주문 페이지에 condition route 추가

루트가 추가되었는지 판단하기 위해 conditions를 이용할 수도 있다. 조건들은 일반적으로 form이 완료되었는지 체크하기 위해 사용된다.

Order page form이 채워졌을 때 불러지게 하기 위해 아래의 루트를 주문 페이지에 추가해라. 이 condition route가 어떻게 사용자에게 응답하기 위해 파라미터 참조를 사용하는지, 그리고 order confirmation 페이지에 세션을 어떻게 전환하는지 기억해라.

• Condition: $page.params.status = "FINAL"
• Agent Says: You have selected a $session.params.size, $session.params.color shirt.
• Transition Page: Order Confirmation

또 order page에 아래와 같이 추가시켜주자.

• condition: true
• agent says: I’d like to collect a bit more information from you.

참고로 condition: true는 그냥 아래와 같이 설정해주면 된다.

또 confirm order 페이지에는 다음과 같이 condition rule을 추가해주자.

• condition: true
• transition target: Page: End Session

다 만들고 실행시키면 아래와 같이 대화가 이루어진다. ㄹㅇ 편하다…..

진짜 너무너무 편하다. 공부하면서 느꼈던 핵심적인 부분들을 정리하면 아래와 같다.

Page는 다이얼로그와 비슷하다. 다른 점은 다이얼로그는 그 안에서 step을 명시적으로 여러개를 구현하는데, 여기서는 parameter를 불러오기 위한 질문들을 페이지에서 설정할 수 있다.

intent는 특정 페이지를 실행시키기 위한 트리거로 사용된다. 사용자가 특정 질문을 던지면, 말 그대로 그 의도를 찾아 적당한 페이지를 실행시켜 주는 것이다.

Entity는 데이터를 다루기 위해 필요한 것이다. 여기서 임의의 데이터 타입을 카테고리화 시켜 저장할 수 있다.

conditional routes는 특정 컨디션이 해당 페이지에서 충족되면 할 행동이다.

사용하면서 느낀거는 ms의 챗봇과는 다르게 말도 안되게 편하다는 것이다. 그런데 문제는 정말 복잡한 챗봇을 개발하고 싶을때, ms 처럼 내가 정말 원하는대로의 커스터마이징은 힘들다고 느꼈다. 아무래도 하드 코딩으로 짜던 것이 인터페이스를 사용하며 생략되는 부분도 있고, 구글에서 딱 정해준 폼으로만 이용할 수 있기 때문에 사용자가 원하는 고도의 기능은 이용하지 못할 수도 있다.

만약 커스터마이징하거나 원하는 봇의 특별한 고도의 기능이 있을 때는 azure chatbot으로 개발하는 것이 좋아보이고 아니라면 gdf를 이용하는 것이 훨씬 좋아보인다.