[eXERD] eXERD 설치

이번엔 DB에 Table을 구성하기 위해 DB Table 디자인을 간편하게 할 수 있는 eXERD를 설치해 보도록 하자. 먼저 eXERD를 검색해 아래의 링크로 들어간다.

설치 링크 : http://ko.exerd.com/

이곳에 접속해 스크롤을 아래로 내리면 다운로드 항목이 보일 것이다.

다운로드 페이지를 누르게 되면 아래와 같이 화면이 생기는데, 여기서 오른쪽 상단의 '개인 사용자 무료 다운로드'를 눌러보자.

누르면 파일이 자동으로 다운로드 받아지고, 다운이 완료되면, 설치 파일을 실행시킨다.

위의 그림처럼 설치화면이 나오는데, 쭉 '다음>' 버튼을 눌러 설치를 진행한다.

'동의' 를 눌러준다

무난하게 C 드라이브에 설치.

시작메뉴도 만들어 준다.

그럼 설치가 진행되며,

위와 같이 완료 되면 실행하기 박스를 체크해 설치를 끝냄과 동시에 eXERD를 실행한다.

그럼 위와같이 작업할 공간을 선택하라고 나온다. 작업공간을 따로 형성시켜야 할 프로젝트가 없는 경우, 아래 디폴트값에 체크해 준뒤 확인.

그럼 위와같은 화면이 뜨는데, 다 무시하고 'eXERD 지금 시작!' 버튼을 눌러준다.

그럼 이렇게 비어있는 화면이 뜬다. 여기서 작업창에 [파일] 메뉴 아래의 하얀색 아이콘 버튼을 눌러 새 프로젝트를 실행 시킨다.

그럼 새로 작성 이라는 창이 뜨는데, 여기서 [일반]-[프로젝트]를 선택한뒤 '다음'을 눌러준다.

여기에 자신이 작업할 프로젝트 이름을 입력한 뒤, '완료'버튼을 누른다.

그럼 프로그램 왼쪽 상단에 이렇게 프로젝트 파일이 형성 되었을 것이다. 여기서 저 프로젝트 파일에 커서를 갖다 대어, 오른쪽 키를 누르고, [새로작성(W)] -[eXERD File]를 눌러 새로운 eXERD 파일을 형성한다.

위와 같은 창이 뜨며, 파일이름만 프로젝트에 맞게 설정하고 완료 버튼을 누르면,

보는 것과 같이 eXERD를 사용할 수 있는 환경이 형성되었다. 다음엔 eXERD를 사용하는 법을 확인해보자.

[Chatbot] SDS Process (Spoken Dialog System)

저번엔 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단계로 분류하여 볼 수 있다.

1. 시나리오 계획 및 설계

2. Slot 정의

3. DA(Dialog Act) 정의

4. Task 구축

5. Transaction/ Response 설정

6. Task_goal 및 Condition 지정

7. 학습 코퍼스 제작

8. 테스트 및 디버깅 작업

위의 순서는 저번에도 말했듯이, 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

[Chatbot] 대화과정

출저 : MindsLAB Academy

작성 : jckim

챗봇은 사용자와 시스템간의 대화 라고도 볼 수있다. 이번엔 사용자와 시스템사이의 Input과 Output이 어떻게 이뤄 지는지, 대화시스템(Conversational System)에 대해 알아보자.

대화시스템은 자연어를 사용하여 사용자와 컴퓨터 사이에서 정보를 주고받는 시스템이라고 설명 할 수 있다. 사용자의 입력에 따라, 처리과정을 거친 후 사용자의 입력에 알맞은 답변을 내는 시스템이다.

대화시스템은 기본적으로 사용자의 Input이 Text로 변환되어야 처리가 가능하다. 변환된 input은 인식과 이해의 내부처리과정을 거쳐 대화관리시스템으로 들어간다. 여기엔 외부 Data Base와 내부 Data Base를 이용해 사용자가 원하는 Output을 추출하여 다시 언어생성 처리과정으로 넘어간다. 그리고 사용자가 알아들을 수 있는 언어로 대답을 하게된다. 이 대화시스템은 대화관리방법과 답변생성방법에 따라 크게 4가지로 분류가 된다.

먼저 대화관리방법에 따른 분류를 살펴보자. 대화관리방법은 두가지 방법이 있다. Open Domain 과 Closed Domain이 있는데, Closed Domain은 한정적인 주제에 답변이 가능한 형태이다. 대표적으로 FAQ나 Expert System등이 있다. 한정적 범위에 대해 답변을 처리함으로 인해 정확도가 매우 높고, 단순업무의 반복을 줄일 수 있는 특징이 있다. Open Domain은 다양한 형태의 주제에 대해 답변을 추출해 낼 수 있는 형태이다. 사용자의 질문에 대해 예측과 추론을 하여 답변을 준다. 이 형태는 가장 어려운 형태로 우리가 이상적으로 생각하는 미래의 AI모습에 가장 가깝다. 현재는 사람과 일반적 대화를하는 AI를 Open Domain 형식을 따른다고 말한다.

그 다음은 답변생성에 따른 분류이다. 하나는 미리 정해진 답변을 말하도록 하는 검색기반모델(Retrieval Based Model)이며, 다른 하나는 사용자의 Input에 따라 다양한 답변을 생성해내는 생성기반모델(Generative Based Model)이다. Retrieval Based Model은 기계학습 방식을 사용하지만, 새로운 문장을 생성하지는 않는다. 이 방식의 장점은 문법 및 내용상의 오류가 적고, 소량의 데이터로 학습이 가능하다는 점이 있다. 여기엔 대표적으로 규칙기반방식(Rule-Based), 슬롯필링방식(Slot-filling), 태스크방식(Task-Based)가 있다. Generative Based Model는 말뭉치 자체를 학습하여 각 의도에 따른 모델을 형성한다. 정해진 답변이 아닌 시스템이 답변을 만들기 때문에, 비교적 유연하며, 다양한 주제에 대해 시스템과 사용자가 대화할 수 있다. 그러나 시스템이 발화문을 만들기 때문에, 문법상 오류나 문맥적 오류가 발생할 가능성이 높다. 보통 20%정도의 오류가 발생한다고 한다. 대표적으로 기계학습기반방식과 학습과 규칙을 함께 사용하는 하이브리드 방식이 있다.

위에 설명한 여러가지 방식을 자세하게 살펴보자. 먼저 검색기반모델의 Rule-Based 방식은 단순한 if-else의 조건문 규칙을 따른다. 미리 정의한 규칙과 자연어 처리 과정을 통해 발화를 이해하고 그에 맞는 정해진 대답을 한다. 한정적 기능을 제공하지만, 단순한 챗봇을 만드는데에는 매우 효과적이다.

그 다음은 Slot-filling 방식이다. 이 방식은 Slot에 들어온 값의 유무에 따라서 대화의 흐름이 결정된다. 대화가 오가가는 과정을 Slot으로 인식하여 대화가 진행되고, Slot이 채워지면 다음대화로 진행이 된다.

Task-Based 방식도 검색기반모델 중 하나인데, 이것은 대화의 시나리오를 예상하여 구축하고, 제작자의 의도대로 Task를 분류하여 대화를 진행시킬 수 있다. 기존의 Rule Based 방식과 Slot filling 방식을 모두 결합한 형태이다.

생성기반모델에 따른 방식 중 하나인 Encoder-Decoder Model이 있다. Encoder는 입력문장의 길이 값의 특징을 벡터로 추출해 내는 것이고, Decoder는 길이 값에 맞게 문장을 생성해 낸다. 문장 길이에 따라 성능이 결정되며, 문장이 길어질 수록 성능이 현저히 낮아진다. 이 점을 보완하기 위해 RNN이나 LSTM방식을 사용하기도 한다.

2016년에 구글은 위의 Encoder-Decoder Model을 보완한 새로운 기계번역 모델을 만들어낸다. (Google Neural Machine Translation) 이 방식은 8개의 Encoder와 Decoder로 구성되어 있고, LSTM Layer가 존재한다. 또 Wordpieces개념을 도입하여 신조어가 들어왔을때, 대응할 수 있는 환경도 갖추었다. 대이터 주도의 학습효율을 극대화 하였으며, 단어 단위에서 문장단위로 앞뒤문맥을 확인후 번역하는 특징이 있다.

마지막으로 생성적적대모델(Generative Adversarial Network)이 있다. 이 방식은 비지도 학습의 한 종류이며, 알고리즘이 두 부분으로 나뉘어 비교를 통해 최상의 결과를 도출해 내는 방법이다. 비교과정을 통해 학습데이터와 생성데이터간의 차이를 최소화하는 특징이 있다. Generator 부분은 데이터분류에 맞춰지기 위해 생성되는 모델이며, Discriminator는 샘플이 학습데이터로 부터 추출될 확률을 계산한다.

이로써 챗봇의 대화과정에 대해 알아보았다. 다음엔 실제로 챗봇을 만들기 위해 사용하는 SDS 에대해 알아보고 본격적으로 MindsLAB에서 제공하는 워크벤치와 플랫폼을 통해 챗봇을 만들어 볼 것이다.

사진 및 자료제공 : MindsLAB Academy