저번엔 SDS에 대한 전반적인 부분들에 대해 살펴 보았다. 다시 언급을 하자면, SDS, Spoken Dialog System은 사용자의 대화의도를 정의하는 DA(Dialog Act)와, 사용자와 대화를 위한 정보를 저장하는 Slot으로 이루어진 대화 시스템 중 하나로써, 제작자가 시나리오를 설계하여 사용자와 시스템간 대화를 주고받을 수 있는 시스템 이다. 학습부분과 처리부분으로 나뉘어 시스템이 진행되며, 코퍼스라는 학습을 위한 말주머니를 만들어 고객의 발화를 Data화 한뒤 태깅(Tagging)작업을 통해 분류된 결과를 처리하였다. 이번엔 SDS를 어떻게 제작하는지, 또 SDS가 챗봇 내에서 어떻게 작동하는 지 살펴보자.
먼저 챗봇은 SDS 내에서 어떻게 작동 될까? 아래의 그림을 보자.
이는 MindsLAB 에서 사용하는 MAUM System의 SDS 구성도 이다. 먼저 대화가 들어오면, 1번 Front Service과정이 시작된다. 이는 대화가 이루어지는 과정이며, 여기서 진행된 대화의 이력이 로그 형태로 DB에 저장된다. 두번째, Unified Classifier에서 고객의 의도가 분류된다. 형태소 분석, 대화의도, 카테고리등 여러가지 분류작업이 이루어진다. 그 작업은 Deep Analysis Server 에서 이루어진다. 6번에 Automated Training System에서 분류가 끝난 Data들이 학습되기 시작한다. 이 학습과정이 끝나면 DA Provide API에(4번) 대화가 넘어가 서비스에 맞게 대화를 매칭시켜준다. 그리고 이 작업의 결과를 Console(7번)에서 확인하고 제어 할 수 있다.
사용자의 대화에 따른 SDS의 작동 방식에 대해서 잠시 알아보자. 예를 들어 기상상황에 관련된 챗봇을 만들었을 때, 이 챗봇의 기능을 크게 두가지로 만들어보자. 하나는 현재 날씨가 어떤지 물어보는 것이고, 다른하나는 현재 기온이나 습도 등을 물어보는 기능을 만든다면, 이 챗봇의 SDS는 날씨SDS와 기온SDS로 나누어 볼 수 있다. 사용자의 대화의도를 파악하여 시스템은 사용자가 날씨를 물어보는 것인지, 기온을 물어보는 것인지 분류해야한다. 여기에는 두 가지 분류법이 있다. 하나는 확률로 분류하는 DNN Classifier 이고, 정해진 규칙으로 분류하는 (Rule-Base 방식) Sample Classifier 가 있다. 사용자의 발화가 들어오면, 먼저 Sample Classifier에서 정해진 규칙대로 사용자의 대화의도를 분류한다. 그리고 Sample Classifier에 규칙이 존재하지 않은 발화가 들어온다면, 확률적으로 DNN Classifier 가 사용자의 발화를 분류하여, 날씨SDS로 발화의도(DA)를 보낼지, 기온 SDS로 발화를 보낼지 결정하게 된다.
다음은 SDS의 제작방법에 대해 알아보자. 총 8단계로 분류하여 볼 수 있다.
5. Transaction/ Response 설정
6. Task_goal 및 Condition 지정
위의 순서는 저번에도 말했듯이, Mindslab에서 챗봇을 제작할 때, 사용하는 웹워크벤치를 토대로 작성된 것이다. 계속 설명을 하자면, 먼저 시나리오를 계획하고 설계해야 한다. 챗봇에서 시나리오 제작은 사용자와의 대화에서 자유도를 조절할 수 있는 하나의 키가 된다. 이를 테면, 금융에 관련된 챗봇의 첫번째 발화가, "안녕하세요?" 라고만 시작된다면, 이 반응에 대해 사용자들은 아주 많은 다양한 답변을 할 것이다. 챗봇에 대해 안녕하다고 답변하는 사용자, 자기의 요구사항을 바로 말하는 사용자 등 여러가지 답변을 함으로 자유도가 높아질 것이다. 그러나 "안녕하세요. 금융담당 봇입니다. 오늘 환율에 대해 알아볼까요? 아니면 주식시장에 대해 알아볼까요?" 라고 챗봇이 첫 발화를 시작한다면 (물론, 첫번째 발화가 치곤 너무 길지만) 사용자는 금융에 대해 물어볼 것인지, 주식에 대해 물어볼 것인지 답변이 두 분류로 한정되어 진다. 이처럼 시나리오 구상을 최대한 구체적으로 작성하면, 대화의 자유도를 낮춰 사용자와 챗봇의 원활한 대화를 진행 할 수 있다.
두번째로 Slot을 정의해야한다. Slot은 사용자가 말한 내용을 저장하거나, 대화를 다음 턴으로 진행할지 결정하는 역할을 하기 때문에 Slot을 잘 정의해야 한다. 저번에 예로 들었던 그림을 보자.
여기서 '고객의 이름' 과 '거래 은행' 을 Slot으로 지정할 수 있다. Slot을 지정하지 않는다면, 고유 명사 간 충돌이 일어날 수 있다. 고객의 이름을 물어보았는데, 고객의 이름을 거래은행으로 인식을 해버린다면, 대화자체가 불가능 해 질것이다.
DA도 역시 정의를 해주어야 한다. 계좌를 변경하려고 할 때와 계좌를 해지 할 때 제공되는 서비스가 다르기 때문에, 먼저 고객이 원하는 의도를 파악해야 하므로 DA를 정의해야 한다. DA가 정의되고 나면, 고객의 의도대로 서비스를 제공 할 수 있다.
그리고 Task 구축을 해야하는데, Task는 여러 상황에 대해 대화를 관리해 주는 역할을 한다. 여러개의 Task를 만들어 대화를 입체적으로 구조화 할 필요가 있다. 고객과 시스템의 대화도중 고객이 원하지 않는 서비스 Task에 들어왔을 때, 시스템의 처음 발화문으로 돌아가는 조건들과 연결을 만들어 고객이 대화 내에서 여러가지 서비스를 요구할 경우 유연하게 반응할 수 있다. 또 Task를 잘 구성하면 제작자가 원하는 흐름대로 대화를 유도할 수 도 있다.
Transaction 과 Response 는 하나의 Task 내에 작동 되는 기능이다. Transaction은 Task에 사용자가 진입할때, 시작되는 발화를 지정할 수 있다. Response는 사용자의 응답에 따라 대답을 하는 발화문을 지정할 수 있다. 위의 사진을 예를들면, 첫번째 Task 에 Transaction은 "안녕하세요? 마인즈 은행입니다. 무엇을 도와드릴까요?" 가 될 것이다. 그리고 사용자가 응답을 한 뒤, 시스템이 "본 서비스에 앞서 고객님의 고객정보가 필요합니다. 고객님의 이름을 입력해 주시기 바랍니다"가 이 Task의 Response가 될 것이다. 이 Task는 고객이 어떤 서비스를 원하는지 결정하는 Task 가 될 것이고 이 곳에서 고객의 DA는 "계좌변경"이 될 것이다. 그리고 Slot은 "홍길동" 이라는 고객의 이름이 될 것이다.
또한 Task 사이간 연결 조건이 필요하다. Task_goal은 Task의 종료시점을 정해주며, Condition은 다음 Task로 넘어가기 위한 연결 조건을 말해준다. 이를 통해 Task 의 위치를 파악할 수 있다. 그리고 위의 Task 의 전체적 작업이 끝나면, 학습 코퍼스를 제작해야 한다. 고객의 발화는 사람마다 천차만별이다. 챗봇에게 대답하는것도 "응", "그래", "맞아", "맞아요", "네", "좋아요" 등 하나의 의도나 표현을 여러가지로 할 수 있기 때문에, 사용자가 응답할 수 있는 대답들을 미리 각각의 Slot으로 지정해서 분류해 놓아야 한다. 그래서 학습코퍼스를 만드는 과정이 가장 복잡하고 시간이 오래 걸린다. 주의해야 할 것은 학습코퍼스가 무조건 많다고 해서 좋은 것은 아니라는 것이다. 너무 많은 코퍼스를 만들어 놓으면 Overfitting 현상이 발생하여 챗봇이 사용자의 발화를 잘못 이해할 수도 있다. 적당한 량의 코퍼스를 제작해야하며, 이것은 시나리오 설계와 Task 구성을 통해 조절할 수 있다.
이 모든과정이 끝나면, 디버깅을 통해 오류가 발생했는지, 확인해 보아야 한다. 여기까지가 SDS의 제작 방법이며, 이제 내가 Mindslab에서 진행한 프로젝트를 살펴 보면서 챗봇을 어떻게 만들었는지 확인해 보자.
* 사진자료 출처 : MindsLAB Academy
