티스토리 뷰
[번역] 챗봇을 위한 딥러닝 - 개요
본 포스팅은 번역글입니다. 의역이 많이 포함되어 있을 수 있습니다.
대화형 에이전트 또는 다이얼로그 시스템이라고 불리는 챗봇은 최근 뜨거운 주제입니다. 마이크로소프트는 챗봇에 큰 투자(Big bets)를 했으며, 페이스북, 애플(시리), 구글, 위챗, 슬랙같은 회사들도 마찬가지입니다. 챗봇은 고객과 상호작용하는 방법를 바꾸려는 시도를 하는 스타트업들의 새로운 물결입니다. Operator, x.ai와 같은 앱이나, Chatfuel같은 봇 플랫폼, Howdy's Botkit같은 봇 라이브러리들이 있습니다. 여기에 마이크로소프트도 최근 Bot Developer Framework를 출시했습니다.
많은 회사들은 사람과 구별할 수 없을 만큼 자연스러운 대화가 가능한 봇을 개발하고 싶어합니다. 그리고 그들은 NLP와 딥 러닝 기술을 이용한다면 자연스러운 봇의 개발이 가능할 것이라고 주장합니다. 하지만 이것은 AI에 대한 과대 광고로, 때때로는 허구에서 사실을 말하기가 어렵습니다.
이 시리즈에서 대화형 에이전트를 구축하는데 사용되는 딥러닝 기술을 조사하고, 현재 우리가 당장 할 수 있는 부분이 어디인지, 무엇이 가능한지, 적어도 잠시 동안은 무엇이 불가능한 지에 대해서 설명할 것입니다. 이 포스트는 개요로써 작성될 것이고, 추후 포스트에서 상세한 구현 방법을 알아 볼 것입니다.
모델 분류 (A Taxonomy of models)
검색기반 모델 VS 생성 모델
검색기반 모델Retrieval-based models (쉬움) 미리 정해진 응답들의 데이터를 사용하며, 인풋과 문맥에 기반하여 적절한 응답을 휴리스틱적 방법으로 선택합니다. 휴리스틱 방법은 룰 기반 매칭만큼 단순하고, 머신 러닝 분류기의 조화만큼 복잡합니다. 이 시스템은 어떠한 새로운 문장을 생성하지 못합니다. 고정된 집합에서 응답을 선택할 뿐입니다.
생성 모델Generative models (어려움) 미리 정해둔 응답에 의존하지 않습니다. 스크래치부터 새로운 응답을 생성합니다. 생성 모델은 전형적으로 머신 번역 기술Machine Translation Technique에 기반을 둡니다. 하지만 우리는 어떤 한 언어에서 다른 언어로 번역하는 대신에, 인풋에서 아웃풋(응답)으로 "번역" 합니다.
두 접근법 모두 명확한 장단점이 있습니다. 수동으로 생성된 응답 저장소때문에 검색기반 모델은 문법적 오류가 없습니다. 하지만 적절한 응답이 존재하지 않는 경우에 대해서는 이를 처리할 수가 없습니다. 같은 이유에서 이 모델은 대화 초반에 언급된 이름같은 문맥적 엔티티Entity 정보를 재위탁할 수 없습니다. 생성 모델은 "더 영리"합니다. 인풋의 엔티티들을 재위탁할 수 있고, 사람과 이야기하고 있는 것 같은 느낌을 줍니다. 하지만 이 모델은 트레이닝시키기가 어렵고, 특히 긴 문장에서의 문법 실수가 꽤 많습니다. 그리고 전형적으로 트레이닝 데이터 셋의 양이 엄청나게 많습니다.
딥 러닝 기술은 검색기반 모델과 생성기반 모델에 모두 사용할 수 있습니다. 하지만 연구는 생성모델 방향으로 움직이고 있는 것 같습니다. Sequence to Sequence와 같은 딥 러닝 아키텍쳐는 유일하게 텍스트를 생성하는 것에 적합합니다. 그리고 연구원들은 이 영역에 더 큰 진보가 이루어지길 바라고 있습니다. 하지만 아직 우리는 합리적으로 동작하는 생성모델의 초기단계에 있습니다. 현재로서 제품 시스템은 검색기반이 더욱 많은 것 같습니다.
Long VS. Short Conversation (긴 VS 짧은 대화)
긴 대화는 자동화하기에 더 어렵습니다. 스펙트럼의 한 측면은 단일 인풋에 단일 응답을 만드는 목표를 가진 짧은 문장 대화Short-Text Conversations(쉬움)입니다. 예를 들면 어떤 유저로부터 특정한 질문을 받고, 적절한 답변을 되돌려주는 것입니다. 그리고 문맥이 여러번 전환되고 말하려 하는 것을 지속적으로 유지해야 하는 긴 대화Long Conversations(어려움)도 있습니다. 고객은 전형적으로 여러 개의 질문을 가진 긴 대화형 맥락의 문장을 말합니다.
Open Domain VS. Closed Domain
열린 도메인Open Domain(어려움) 유저는 아무렇게나 대화를 할 수 있습니다. 이것은 목표나 의도가 잘 정의되지 않아도 된다는 의미입니다. 트위터나 레딧같은 소셜미디어의 대화들이 전형적인 열린 도메인Open Domain 대화입니다. 그들은 자유롭게 대화를 이어갈 수 있습니다. 무한정의 주제에 유한의 특정 사실(지식)들을 연결해야 합리적인 응답을 만들 수 있다라는 점이 어려운 점입니다.
닫힌 도메인Closed Domain(쉬움) 시스템은 특정한 목표만을 수행하기 때문에 인풋과 아웃풋이 다소 제한적입니다. 고객 지원이나 쇼핑 어시스트들이 닫힌 도메인Closed Domain에 해당합니다. 이 시스템들은 이야기를 조리있게 만들 필요가 없습니다. 그냥 가능한 효율적으로 시스템의 특별한 테스크task를 이용하면 됩니다. 물론, 유저들은 여전히 그들이 원하는 대로 아무렇게나 대화를 합니다. 하지만 시스템은 모든 경우에 대해서 응답을 하지 않고, 유저 또한 기대하지 않습니다.
도전 과제
대화영 에이전트의 대부분 연구 분야를 진행할때 몇 가지 도전적인 과제들이 있습니다.
문맥 병합 (Incorporating Context)
자연스러운 응답을 만들기 위해서 시스템은 언어적 문맥linguistic context과 물리적 문맥physical context을 병합해야 합니다. 긴 대화에서 사람들은 말하는 주제와 서로 교환되는 정보들을 계속 인지합니다. 이것이 언어적 문맥의 예입니다. 가장 흔한 접근법은 대화에 벡터를 끼워넣는 것입니다. 하지만 긴 대화에서는 이것이 어렵습니다. Building End-To-End Dialogue Systems Using Generative Hierarchical Neural Network Models논문과 Attention with Intention for a Neural Network Conversation Model논문의 실험 모두 그런 실험을 진행합니다. 날짜, 시간, 지역이나 유저에 대한 정보같은 문맥적 데이터들을 통합하는 것이 필요할 수도 있습니다.
인격의 일관성 (Coherent Personality)
의미상 동일한 입력에 대한 응답을 생성할 때, 에이전트는 일관된 답변을 해야합니다. 예를 들어, "너 몇 살이니?"(How old are you?)와 "너 나이가 어떻게 돼?"*(What is your age?) 같은 질문에는 동일한 답변을 해야합니다. 이것은 단순한 얘기처럼 들리지만, 고정된 지식과 모델에 대한 "인격"을 하나의 모델로 만드는 것은 매우 도전적인 연구 과제 입니다. 많은 시스템들은 언어적으로 그럴듯한 응답을 만들어내는 것을 학습합니다. 하지만 의미적으로 동일한 응답을 생성하는 것은 학습하지 않습니다. 보통 여러 다른 사람들의 많은 데이터들을 가지고 학습하기 때문입니다. A Persona-Based Neural Conversation Model 논문에서 나오는 모델은 인격을 모델링하는 방향으로 개발하는 첫 모델입니다.
<일관되지 않은 인격>
Q: Were do you live now? - 지금 어디사니?
A: I live in Los Angeles. - LA에 살아
Q: In which city do you live now? - 지금 사는 도시가 어디야?
A: I live in Madrid. - 마드리드에 살아
Q: In which country do you live now? - 지금 사는 국가가 어디야?
A: England. you? - 잉글랜드. 너는?
모델의 진화
대화형 에이전트를 진화시키는 이상적인 방법은 대화를 통해 고객 지원 문제를 해결했는지와 같은 작업을 완수했는지 못했는지 측정하는 것입니다. 하지만 인간의 판단과 평가가 필요한 어떠한 작업은 측정하기가 어렵습니다. 때로는 열린 도메인 모델 같이 잘 정의된 목표가 없을 수 있습니다. 텍스트 매칭을 기반으로 기계번역을 위해 사용되는 BLEU 공통된 측정도 응답에 완전히 다른 단어와 절을 포함할수 있기 때문에 적합하지 않습니다. 사실, How NOT to Evaluate Your Dialogue System: An Empirical Study of Unsupervised Evaluation Metrics for Dialogue Reponse Generation(대화시스템을 평가하면 안되는 이유:대화 응답 생성을 위한 비지도적 평가 측정의 경험적 연구) 논문의 연구원은 흔히 사용되는 측정법이 인간의 판단과 밀접한 관련은 없다라는 것을 발견했습니다.
의도와 다양성
생성적 시스템이 가진 흔한 문제는 많은 입력들에 대해서 "훌륭해!"나 "나는 몰라" 같은 일반적인 응답을 생성하는 경향이 있다는 것입니다. 구글의 Smart Reply의 초기버전은 대부분의 질문에 대해 "사랑해"라는 응답을 하는 경향이 있었습니다. 이것은 데이터와 목적/알고리즘의 실제 학습 조건에서 시스템들이 학습한 방법에 대한 부분적인 결과입니다. 일부 연구원은 여러 목적 함수를 통해서 인공적으로 다양성을 활성화시키는 것을 시도했습니다. 하지만, 사람들은 일반적으로 입력에 대한 특정한 응답을 만들고 의도를 전달합니다. 생성 시스템(그리고 특히 열린 도메인 시스템)은 특정한 의도를 가지고 학습할수 없기 때문에 이러한 종류의 다양성이 부족하게 됩니다.
어떻게 실제 작업을 잘 하게 할 수 있을까?
현재의 모든 첨단 기술을 포함하여, 우리는 어디쯤 있을까요? 그리고 어떻게 시스템이 실제 작업을 잘 수행할 수 있게 할까요? 분류법taxonomy을 다시 생각해봅시다. 검색 기반의 열린 도메인 시스템은 모든 케이스를 커버할 수 있는 충분한 응답을 절대 수동으로 만들수 없기 때문에 명백하게 불가능합니다. 생성적 열린 도메인은 모든 가능한 시나리오에 대해서 다뤄야 하기 때문에 거의 일반 인공 지능Artificial General Intelligence(AGL)입니다. 해당 분야에 대해 매우 활발히 연구가 진행되고는 있지만 우리는 아주 멀리 떨어져 있습니다
이로인해 생성 및 검색기반 방법 모두 적절한 제한된 도메인에서 문제가 됩니다. 대화가 길어지고 문맥이 중요할수록 문제는 더욱 어려워 집니다.
바이두에서 일하고있는 앤드류 응(Andrew Ng)교수의 최근 인터뷰에서 잘 드러납니다.
오늘날 딥러닝에 대한 대부분의 가치는 많은 데이터를 얻을 수 있는 좁은 도메인에 있다. 여기 하지 못하는 것에 대한 하나의 예가 있는데, 그것은 의미있는 대화를 하는 것이다. 당신이 특정 대화를 선택(유도)한다면 그것은 의미있는 대화인것처럼 보이지만, 실제로 대화를 시도한다면 그 생각은 빠르게 사라질 것이다.
많은 기업들은 그들의 대화를 사람에게 아웃소싱하기 시작하여, 충분한 데이터를 수집하는 것을 "자동화" 할 수 있다고 기대합니다. 우버를 호출하는 것과 같은 채팅 인터페이스 같이 꽤 좁은 도메인의 환경에서라면 가능할 것 같습니다. 세일즈 이메일같은 보다 더 열린 도메인에서는 지금 우리가 할 수 있는 것들을 뛰어 넘어야 합니다. 하지만 우리는 응답을 제안하고 수집하는 것을 사람의 도움을 받아 이러한 시스템을 사용하고 있습니다. 이것은 실현가능할 것 같습니다.
생성 시스템에서 문법적 오류들은 매우 치명적이고 유저들을 멀리 떠나게 할 것입니다. 이것이 대부분의 시스템이 문법적 오류와 무례한 응답으로부터 자유로운 검색기반 방법의 사용을 선호하는지에 대한 이유입니다. 만약 기업들이 어떻게든 어마어마한 데이터를 손에 넣을 수 있다면, 생성 모델은 실현가능할 것입니다. 하지만 마이크로소프트의 Tay (인종차별을 학습한 bot)가 그랬던 것처럼 사람들이 떠나지 않도록 하는 다른 기술의 도움을 받아야만 할 것입니다.
- Total
- Today
- Yesterday
- git proxy
- git 설정
- 폰트 조정
- Zone.js
- 안시 컬러
- zone
- ECMA2015
- 리눅스 터미널 색상
- 안시 색상
- NgZone
- ZONES
- qemu linux arm
- Rx.js
- C언어
- 타입스크립트
- lua table
- 스위프트
- observable
- Swift
- angular2
- QT
- typeScript
- ansi color
- itoa
- JavaScript
- 우분투 16.04
- vim
- 챗봇
- terminal 색
- Angular
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |