티스토리 뷰
대본은 토픽으로 구성되고 토픽은 룰로 구성된다. 최종 단위인 룰을 올바르게 작성하는 것이 중요하지만 그 룰을 담는 그릇으로서 토픽도 논리적으로 구성되어야 한다. 토픽의 논리적 구성을 머리 속에 담고 있어야 필요한 룰을 빠뜨리지 않고 포함시킬 수 있기 때문이다. 이번 절에서는 챗봇을 개발할 때 염두에 두어야 할 토픽의 논리적 구조에 대해 설명하기로 하겠다[1]. 토픽은 유형별로 Story topic, Reactor topic, Quibble topic으로 대별할 수 있는데 그 중 가장 중요한 Story topic부터 살펴 보기로 한다.
① Story topic의 구조는 3단 구성
가. 말걸기 : 대화를 시작하기 위해 사용자에게 던지는 질문. 화제에 대한 간략한 소개를 포함할 수도 있으며 이 질문하기가 많을수록 대화를 오래 이어나갈 수 있다.
나. 그 질문에 대한 봇의 대답 : 위 ‘가’의 질문을 사용자가 똑 같이 했다고 가정했을 때 챗봇의 답변
다. 말걸기의 질문을 사용자가 먼저 하는 경우 : 의미 상으로 ‘나’보다 앞에 기술해야 하지만 코드의 중복과 룰의 반복을 피하기 위해 맨 마지막에 작성
이제 아래의 예를 보면서 3단 구조를 확인하기로 하자.
룰A는 챗봇에게 대화의 통제권이 왔을 때 사용자에게 던질 질문으로 준비한 것이다. 이때 룰B와 룰C를 세트로 작성하는 것을 강력히 추천한다. 대화는 서로에게 비슷한 질문을 하는 것이 상례이기 때문이다. 내 휴가 계획을 말한 후에는 상대방의 휴가 계획을 듣고 싶고, 상대방이 감명깊게 본 영화를 얘기해 주면 나도 비슷한 경험을 얘기하는 것이 대화의 기본이기 때문이다. 따라서 챗봇의 대본을 작성할 때는 위와 같은 3단 구조를 먼저 작성한 후 각각에 살을 붙여 나가는 식으로 진행하면 룰을 누락하는 경우를 최소화 할 수 있을 것이다.
위의 3단 구성에서 특히 1단은 아래와 같이 좀 더 세부구조를 갖는다.
Story topic의 완성된 모습은 위와 같은데, 이를 작성하는 과정은 다음과 같이 먼저 질문을 하고 그 질문에 대한 챗봇의 답을 작성하고, 다시 질문을 하고 그 질문에 대한 챗봇의 답을 적고 하는 순서로 적어 나간 후 나중에 소팅을 하는 것이 효율적이다.
Topic: ~KPOP [ ~투애니원 ~티아라 ~맘마무 ~노래 ]
t: K-POP 좋아하세요?
t: 저는 K-POP을 좋아해요
t: 좋아하는 가수가 있어요?
t: 저는 투애니원을 좋아해요
t: 즐겨듣는 노래가 있어요?
t: 저는 I love you를 자주 들어요.
이때 소팅 순서는 이야기의 흐름에 맞도록 먼저 말할 내용을 앞쪽에 배치한다. 맨 위에서부터 차례로 사용자에게 전달될 것이기 때문에 이야기의 전개 순서에 맞춰 앞에서부터 배치해 나간다. 이 과정에서 Topic의 키워드 목록과 비교해 가며 키워드를 추가로 보완한다. 또한 어휘, 문장, 문체 등이 앞서 작성하였던 챗봇의 신상명세나 자기소개서 등과 부합하는지도 확인한다. 어느 정도 뼈대가 완성되면 이제는 내가 한 질문을 사용자가 질문하는 것으로 가정하고 응답 규칙을 작성한다.
Topic: ~KPOP [ ~투애니원 ~티아라 ~맘마무 ~노래 ]
t: 혹시 K-POP 좋아하세요?
t: 저는 K-POP을 좋아해요
t: 좋아하는 가수가 있어요?
t: 저는 투애니원을 좋아해요
t: 즐겨듣는 노래가 있어요?
t: 저는 I love you를 자주 들어요.
?: (K-POP 좋아하세요)
?: (좋아하는 가수가 있어요)
?: (즐겨듣는 노래가 있어요)
이렇게 3단 구조를 갖춘 후 이제 각각 세부 내용을 다듬는다.
Topic: ~KPOP [ ~투애니원 ~티아라 ~맘마무 ~노래 ]
t: 혹시 K-POP 좋아하세요?
A: 왜 물으세요?
A: 예
A: 아니요
t: FaveKPOP ()저는 K-POP을 좋아해요
t: 좋아하는 가수가 있어요?
왜요? 예, 아니요 등의 예상응답 작성
t: FaveSinger ()저는 투애니원을 좋아해요
t: 즐겨듣는 노래가 있어요?
왜요? 예, 아니요 등의 예상응답문
t: FaveSong ()저는 I love you를 자주 들어요.
?: (K-POP 좋아하세요) reuse(FaveKPOP)
?: (좋아하는 가수가 있어요) reuse(FaveSinger)
?: (즐겨듣는 노래가 있어요) reuse(FaveSong)
이때 응답(responder) 규칙을 배치하는 순서는 구체적이고 세세한 규칙을 먼저 적고 일반적이고 넓은 범위를 포괄하는 규칙은 뒤에 배치해야 한다. 예를 들면
u: (투애니원 음악 좋아하세요?)
u: (K-POP 좋아하세요)
u: (음악 좋아하세요)
의 순서로 적어야 올바르게 매치될 수 있다. 만약 반대 순서로 적으면 블로킹이 될 수 있는데 이에 대해서는 이 장의 (5)절에서 설명하기로 한다.
② Reactor topic
대화를 나누다 보면 음악, 영화, 애완동물, 연예인, 음식, 여행, 스포츠 등 상대방의 선호, 소유, 경험 등이 화제에 오르게 되는데, 이때 적절한 반응을 할 수 있도록 초점 맞춰 작성하는 토픽이 reactor topic이다. 예를 들어 영화배우에 대해 대화를 나눈다고 가정해 보자. 영화배우는 무척 많고(아마 톱스타만 꼽아도 수 백명 될 것이다.) 사용자가 이 중에 누구를 언급할 지 알 수 없으므로 가능한 많은 영화배우에 대해 준비해 두어야 하는데 이럴 때 reactor토픽을 사용하는 것이다. 예를 들면 영화 배우의 이름과 각각에 대한 적합한 멘트를 담은 ~movie_react topic을 작성할 수 있다. 나중에 영화를 주제로 대화를 나누다가 챗봇이 영화배우 이름과 함께 ~movie_react 토픽을 호출해서 만약 그 영화배우에 대한 멘트가 있다면 그 영화배우에 맞는 특별한 언급이 출력될 것이고 만약 없다면 일반적인 멘트, 예를 들면 “그 배우는 훌륭한 배우이지요” 또는 “최근 작이 무엇이지요?” 등을 내 보내게 될 것이다. 대화를 하는 상대방 입장에서는 일반적인 멘트보다는 딱 맞춘 멘트를 들었을 때 “말이 통한다”고 느낄 수 있을 것이기 때문에 CS에는 맞장구를 효율적으로 작성할 수 있는 reactor topic이라는 장치를 만들어 놓은 것이다. reactor topic을 사용하지 않아도 상관없으나 reactor topic을 사용하지 않을 경우 수 많은 영화배우에 관한 멘트를 본문에 일일이 작성하게 되어 줄거리를 파악하는데 방해가 될 수 있고, 다른 곳에서 재사용할 수 없게 되므로 reactor topic으로 모듈화해서 작성하는 것이다.
Reactor topic의 구조는 다음과 같다
l 우연히 호출되는 일이 없도록 키워드를 할당하지 않는다
l 다른 토픽에서 respond함수를 이용하여 호출하여 사용한다
l 가능한 선택지를 모두 나열한다.
l 보통 한 줄 정도 길이의 응답으로 구성한다
l NOSTAY로 선언하여 출력이 끝난 후 컨트롤을 호출한 토픽에 되돌려 준다.
예제를 보면서 위의 구조를 다시 한 번 확인하기로 하자.
#! 애완동물 키우기.
s: (~동물 * ~키우기) ^respond[2](~pet_react)
그리고 ~pet_react topic은 다음과 같이 작성되어 있을 것이다.
topic: ~pet_react nostay[ ]
#! 앵무새
u: ( ~새) 새는 기르기가 쉽지요. 저는 십자매를 키우고 있어요.
#! 뱀
u: ([ 뱀 도마뱀 악어 ] ) 도마뱀을 키우는 친구가 있어요. 근데 파충류는 좀 무서워요.
#! ant
u: (~곤충) 곤충은 시끄럽지도 않고 공간도 별로 차지 하지 않고. 기르기 좋죠.
…… (이곳에 훨씬 많은 사례를 쭉 열거할 수 있다)
위의 예에서 ~pet_react 토픽이 reactor topic인데, 특징을 보면 키워드 목록이 없고 nostay로 선언되었으며 응답(respond)만 가지고 있는 점을 확인할 수 있다. 수 십 개 이상의 예상 가능한 응답이 상관관계나 위계관계 없이 동등한 수준에서 나열되어 있다. 예상응답의 수가 풍부하게 준비되어 있을수록 사용자의 어떤 반응이라도 캐치해 낼 수 있을 것이고 “이런 것까지 알아 듣네”하는 느낌을 줄 수 있을 것이다. rector토픽을 사용하면, 스크립트의 줄거리를 읽는데 방해 받지 않으면서도 디테일한 답변을 작성할 수 있는 장점이 있다.
③ Quibble topic
사용자 입력문과 매칭되는 규칙이 없을 때 CS는 퀴블 토픽을 검토하게 된다. 퀴블 토픽이란 사용자 입력문의 한 두 단어에만 매칭되도록 작성한 룰들을 모아 놓은 토픽이다. 따라서 출력문은 모호한 답변이 될 수 밖에 없다. 사용자 입력문을 명확하게 파악하지 못한 상태이기 때문이다. 이에 따라 듣는 사람 입장에서는 챗봇이 얼버무리고 있다고 느끼게 된다. 그렇지만, 매칭되는 규칙이 없을 때는 사용자가 한 말의 한 두 단어와 만이라도 일치하는 규칙을 준비해서 모호하게라도 답변하고 다른 화제로 전환을 유도하는 것이 필요하다.
Quibble topic의 구조는 다음과 같다
l 우연히 호출되는 일이 없도록 키워드를 할당하지 않는다
l 다른 토픽으로부터 호출되어 사용된다
l 응답으로 구성되어 있다
l 출력문은 2개 이상의 다중으로 작성하는 것도 좋다 ([ ]을 이용)
l 매칭되는 룰이 없을 때 사용되는 룰이므로 사용자 입력문 중 한 두 단어라도 매치되도록 넓은 영역의 단어를 사용하여 작성한다. (예를 들면 누구, 어디서, 언제, 어떻게 등등)
얼버무림 토픽의 대표적인 예는 다음과 같다.
topic: ~quibblewho system []
?: (~누가 ~알다) [아는 사람 없을 것 같은데요…] [글쎄요…, 저는 모르겠어요]
?: (~누구 ~하다) [아무도 못 할 겁니다.] [누가 감히 해 보겠어요]
앞서의 반응전용 토픽과 차이점은 패턴에 있다. 반응전용 토픽은 패턴에 애완동물, 영화배우, 작곡가 등 특정 영역의 구체적인 단어가 포함되는데 비해 얼버무림 토픽은 패턴에 대명사나 의문사, 기본동사 등을 포함시켜 넓은 영역과 매칭되도록 한다는 점이다.
'7장. 나의 첫 챗봇 개발하기' 카테고리의 다른 글
5. 초보자가 흔히 저지르는 실수 (0) | 2016.06.09 |
---|---|
4. 스크립트의 대표적 유형 5가지 (0) | 2016.06.08 |
2. 대본 작성 가이드 (0) | 2016.06.03 |
1. 챗봇의 이력서 작성하기 (0) | 2016.06.03 |
- Total
- Today
- Yesterday
- 한글챗봇 우리말챗봇 인공지능챗봇 ai챗봇
- 한국어챗봇
- 챗봇개발 채팅로봇 한국챗봇
- Chatscript AI 인공지능 챗봇 chatbot
- chatscript chatbot 챗봇 한국어챗봇 ai 인공지능
- 소프트봇 채터봇
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |