Skip to content

Instantly share code, notes, and snippets.

@haje01
Last active June 15, 2022 09:33
Show Gist options
  • Star 43 You must be signed in to star a gist
  • Fork 17 You must be signed in to fork a gist
  • Save haje01/7fc9d1b1fc1b6c8c9b7918abf5407a86 to your computer and use it in GitHub Desktop.
Save haje01/7fc9d1b1fc1b6c8c9b7918abf5407a86 to your computer and use it in GitHub Desktop.
대화형 챗봇 설계의 과제

최근 인공지능을 활용한 챗봇에 대한 관심이 높아지고 있습니다. 챗봇 설계에 관한 좋은 글이 있어 번역을 해보았습니다. 이 글은 IBM DeveloperWorks에 기재된 Michael Yuan의 글을 번역한 것으로 의역이 있습니다. - 김정주(haje01@gmail.com)


대화형 챗봇 설계의 과제

사용자는 챗봇이 매우 간단하고 최소한의 요구만 하기에 좋아합니다. 그것은 대화식 문자 메시지처럼 간단해질 수 있습니다. 또한, 사용자는 자신이 선호하는 메시지 앱에 계속 머물기를 선호합니다. 앱, 웹 URL, 메뉴, 버튼, 광고, 크롬 및 기타 요소를 탐색하지 않고 바로 목표를 달성하고자 합니다. 그러나 이 단순성은 큰 설계 과제도 제시합니다. 챗봇은 사용자의 말을 정확하게 이해하고 적절히 행동해야 합니다. 이것은 오늘날 최고의 자연어 AI (인공 지능)에게도 매우 어려운 과제입니다.

현재 상태의 AI에서는, 대화식 문자 메시지 또는 대화식(Conversational) UI, 즉 CUI는 (안타깝게도) 거의 항상 잘 설계된 그래픽 UI(GUI)보다 열등합니다. GUI와 비교하여 CUI는 초기 단계에 있습니다. 커뮤니티로서 우리는 여전히 CUI의 디자인 패턴과 우수 사례를 모색하고 있습니다. 이 튜토리얼에서는 챗봇이 왜 실패하고 성공할 수 있는지 설명합니다.

참고: Dr. Robert Kosara는 최근에 "개인화된 사용자 인터페이스의 함정"이라는 제목의 블로그 게시물을 게시했습니다. 그는 1997년 Shneiderman과 Maes의 "직접 조작"에 대한 논쟁을 UI의 "인터페이스 에이전트" 스타일과 비교하여 설명했습니다. 그는 20년 전의 교훈은 오늘날에도 여전히 적용된다고 결론을 내렸습니다. 그것은 "에이전트"가 사용자의 요구를 완벽하게 확신할 수 있는 경우 (완벽한 AI)가 아니라면, 사용자에게 GUI 윈도우를 제시하는 것이 더 좋다는 것입니다. 왜냐하면, 그것이 더 (많은 정보를)발견 가능하고 상호 작용에 "문법"이 필요하지 않기 때문입니다. 그러나 사용자가 좋아하는 메시징 응용 프로그램 내에서 최소한의 UI를 선호한다는 사실은 여전히 무시할 수 없습니다.

챗봇이 실패하는 이유

페이스북이 2016년 4월에 봇 플랫폼을 출시 한 후, 많은 사람들이 주요 "출시 파트너"를 시험해 보았고 매우 부족한 것을 알게 되었습니다. 챗봇은 응용 프로그램 도메인 내에 있는 기본적인 질문 (예: 날씨 또는 꽃 배달 확인)조차 이해할 수 없었습니다. 사용자가 챗봇이 원하는 기계적인 질문에서 벗어나 "자연스럽게" 말하려고 할 때 챗봇이 혼란스러워하는 것을 보는 것은 특히 더 고통스러웠습니다.

페이스북 메신저 제품 관리자인 Mikhail Larionnov는 페이스북 플랫폼에서 많은 챗봇을 검토한 결과, 일부 챗봇의 견인력 부족에 대한 세 가지 이유를 확인했습니다:

  • 이용을 시작할 때 챗봇의 기능에 대한 설명이 거의 없다
  • 단일 챗봇에서 너무 많은 작업을 시도해 목표가 불명확
  • 자연어 처리에 지나치게 의존

성공적인 챗봇을 만드는 방법

그러나 Larionnov는 이러한 문제를 해결하기 위한 구체적인 조언을 제공했습니다.

첫째, 챗봇은 매우 제한된 범위를 가져야합니다. 챗봇은 좁은 주제에 대한 가치를 제공하고, 그것을 잘 해내야 합니다. 더 중요한 것은 챗봇이 무엇을 하는지 한두 문장으로 설명할 수 있어야 합니다.

둘째, 각 메시징 플랫폼의 내장 기능을 사용하여 사용자가 이용을 시작할 때 챗봇의 기능을 잘 전달해야 합니다. 페이스북 메신저의 경우 잘 만들어진 인사말 창과 동작 유도 문을 활용할 수 있습니다. 슬랙(Slack)의 경우 봇 저장소의 설명을 이용할 수 있습니다.

셋째, 가능한 구조화된 버튼을 사용해야합니다. 자유로운 사용자 입력이 정말 필요한 경우 AI가 입력을 이해할 수 없는 경우를 처리하고, 구문을 올바르게 사용하는 방법에 대한 도움말을 제공해야 합니다. 챗봇의 구문은 작업을 트리거(trigger, 시작)하는 명령과 키워드입니다.

네 번째 항목을 추가하면, 스팸처럼 불필요한 정보를 제공하면 안됩니다. 챗봇은 중지, 탈퇴 및 취소와 같은 명령을 이해하고 응답해야합니다. 그리고 즉시 메시지 전송을 중단해야 합니다. 봇이 과도하게 원치 않는 메시지를 사용자에게 보내면 사용자는 챗봇을 차단할 수밖에 없습니다. 4%의 사용자가 챗봇을 차단하면 페이스북은 사용자의 챗봇을 오프라인으로 전환시키는 것으로 알려져 있습니다.

커맨드(Command, 명령)와 제어(Control) CUI 디자인

CUI는 종종 DOS 및 UNIX 시대의 오래된 컴퓨터 명령 줄을 사람들에게 상기시킵니다. 사실 챗봇이 처음으로 인기를 얻었을 때 개발자가 고도로 기술적인 작업을 수행하는 데 널리 사용되었습니다. 예를 들어 GitHub의 HUBOT은 많은 작업을 관리하기 위해 내부적으로 커맨드를 사용했습니다. 이 사용 사례에서 "대화"는 개발자가 채팅 창에 직접 커맨드를 입력하는 것과 봇이 해당 명령을 실행하는 것이었습니다. 이 사실이 사용자가 암기해야하는 미리 정의된 커맨드에 응답하는 챗봇을 만들만 하다는 것을 의미합니까? 많은 경우에 대답은 '그렇다' 입니다.

몇 가지 사용 예를 살펴 보겠습니다:

  • 작업 및 생산성을 위한 챗봇은 커맨드에 보다 관대할 수 있습니다. 그 챗봇 사용자는 일반적으로 컴퓨터에 숙련된 전문가이며, 그들은 직장에서 커맨드로 일하는데 익숙합니다. 실제로 많은 고급 사용자는 느린 GUI 대신, 명령 줄 프롬프트와 키보드 바로가기를 마스터하여 반복적인 작업을 처리합니다. 따라서 이런 경우 매우 효율적인 "커맨드 라인" 봇이 수다스러운 봇보다 선호될 것입니다.

  • 컴퓨터와 함께 성장한 젊은 사용자는 문자 메시지를 전 생애에 걸쳐 사용합니다. 느린 GUI 보다 커맨드를 통해 효율성을 높이는 경향이 있습니다.

커맨드와 제어 CUI를 설계하는 경우, 다음과 같은 특정 설계 고려 사항이 있습니다:

  • 사용자가 커맨드의 철자를 정확하게 입력 할 수 있도록 자동 완성 또는 다른 형태의 도움말을 제공하십시오. iOS 및 Android 기기의 자동 수정 기능에 특별한 주의를 기울이십시오. 커맨드가 비 통상적 철자를 갖는 경우 사용자 입력을 변경할 수 있기 때문입니다. 내장 커맨드 도움말의 좋은 예가 슬랙의 슬래쉬 커맨드입니다. 슬랙 애플리케이션 UI는 올바른 철자를 제안하고 사용자가 입력할 때 커맨드에 대한 설명을 제공합니다.

  • 챗봇에 일반적인 맞춤법 오류나 동의어를 허용하도록 프로그래밍하십시오. 예를 들어 "도움"은 "어떻게 해야합니까?"로 대체될 수 있습니다. 이 시나리오는 동의어 목록을 만드는 과정을 수반하며, 그 중 다수는 정규식이 될 수 있으며 런타임에 사용자 입력과 모두 일치 할 수 있습니다.

슬롯 채우기(Slot Filling)를 위한 짧은 대화 설계

명령 줄의 반대는 평문으로 사용자와 자연스러운 대화를 유지할 수 있는 챗봇입니다. 그러나 자연어 AI의 현재 상황을 고려할 때, 사용자와 자유롭게 대화하는 것은 거의 불가능합니다. 그리고 당신은 그럴 필요도 없습니다. 챗봇을 유용하게 하려면, 대개 미리 고도로 스크립팅된 대화만 있으면 됩니다. 예를 들어 챗봇에 날씨 정보를 요청하려면 다음과 같이 말하면 됩니다:

내일 텍사스 오스틴의 날씨는 어때? 

여기에는 다음과 같은 정보가 있습니다:

  • 의도 : 일기 예보
  • 위치 : 텍사스 오스틴
  • 시간 : 내일

챗봇은 이제 날씨를 쿼리 할 수 있습니다. 그러나 때때로 사용자는 모든 정보를 한 번에 제공하지는 않습니다. 사용자가 의도만으로 시작하면 챗봇은 슬롯(slot)이라고 하는 필수 매개 변수 채우기(filling)를 사용자에게 요청할 수 있어야 합니다. 대화 내용은 다음과 같습니다.

사람: 날씨는 어때?

챗봇: 날씨를 찾아보겠습니다. 현재 위치의 날씨가 필요하신가요? 아니면 다른 지역의?

사람: 다른 지역

챗봇: 알겠습니다. 어느 지역인가요?

사람: 텍사스 오스틴

챗봇: 감사합니다. 현재 날씨를 원하시나요? 아니면 예보를 원하시나요?

사람: 예보

챗봇: 알겠습니다. 언제의 예보가 필요하신가요?

사람: 내일

챗봇: 내일 텍사스 오스틴의 날씨는 맑으며, 최고 온도 28 최저 온도 24도입니다.

대충 아이디어를 아실 겁니다. 이러한 유형의 스크립트로 작성된 대화는 여러 시나리오에서 발생할 수 있습니다. 일반적으로 봇에게 작업 수행을 요청하면, 봇은 필요한 모든 슬롯을 채우기 위한 짧은 대화를 할 수 있어야 합니다.

이러한 대화를 수행하는 데 도움이 되는 도구가 제공됩니다. 예를 들어 IBM Watson Conversation 서비스는 대화 스크립트 내 슬롯 채우기를 지원할 수 있습니다.

상호 작용적 대화를 위한 설계

커맨드 및 슬롯 채우기 대화는 진정한 대화형 AI의 부족을 해결하는 효과적인 방법입니다. 그러나 좀 더 직접적인 접근 방법이 있습니다. 특정 응답이 필요한 메시지 뒤에 버튼을 표시하는 방법은 어떨까요? 이렇게 하면 사용자에게 기대되는 응답을 명확하게 전달할 수 있습니다. 다음은 페이스북 메신저 채팅 세션의 버튼 예제입니다.

이러한 버튼이 없으면 챗봇은 일반적으로 번호 목록 또는 키워드 옵션을 제공합니다 (예 : "더 읽으려면 1, 모든 이야기를 보려면 2로 응답하세요"). 이러한 유형의 상호 작용은 종종 로봇처럼 느껴집니다. 그럼에도 불구하고 챗봇이 사용자에게 번호 목록에서 선택하도록 요청할 때 1, 일, 하나, 첫 번째 같은 사용자의 동의어 입력을 처리해야 합니다.

제공하는 버튼 또는 번호 목록을 사용자가 이용하지 못할 수도 있습니다. 사용자는 버튼을 건너 뛰고 다른 것을 입력 할 수도 있습니다. 일반적인 예는 사용자가 일련의 버튼을 보고도 응답하는 방법을 모르고, '도움말' 또는 '메뉴'를 입력하는 경우입니다. 챗봇은 사용자의 자유 입력형 응답을 파싱해서 요청한대로 입력했는지, 또는 제공한 선택지에서 선택했는지, 또는 유저가 새로운 세션을 시작하기 원하는지를 다 대응해야 합니다.

물론 버튼이 있다면 다른 대화식 컨트롤도 사용할 수도 있습니다. 예를 들어 페이스북 메신저는 가로로 스크롤할 수 있는 캐러셀(carousel)을 지원합니다. 아주 긴 목록으로 전체 창을 가리지히 않고 항목 목록을 표시하는 좋은 방법입니다.

다양한 종류의 사용자 입력을 활용

최신 메시징 응용 프로그램의 가장 큰 특징은 이미지, 오디오, 비디오, 이모티콘, 위치 및 기타 입력을 보낼 수 있다는 것입니다. 페이스북의 메신저는 이러한 풍부한 채팅 기능의 좋은 예입니다.

일부 사용자는 음성을 사용하여 의사 소통하려 하고, 다른 사용자는 사진을 보내려는 경향이 있습니다. 그리고 "당신은 어디 있습니까?"라는 질문의 대답은 위치 정보를 통해 가장 잘 대답됩니다. 페이스북의 메신저는 모든 사용자 생성 애셋을 챗봇에 제공합니다. 그러나 그 의미 (예 : 말하기 -> 텍스트, 이미지 인식, OCR, 주소에 위도 및 경도 매핑 및 기타 입력)를 파악하는 것은 사용자의 챗봇에 달려 있습니다.

참고: 다양한 메시징 응용 프로그램은 다양한 종류의 사용자 생성 멀티미디어 입력을 지원하며, 이 데이터를 챗봇으로 보내는 서로 다른 방법이 있습니다. 따라서 모든 메시징 응용 프로그램에서 일관되게 작동하는 일반적인 교차 플랫폼 챗봇을 만드는 것은 매우 어렵습니다.

무례한 사용자, 그리고 UI 디자이너로서의 작가

챗봇을 프로그래밍 할 때 사용자가 말할 수 있는 모든 종류의 것을 예상해야 합니다. 경우에 따라 사용자가 의도적으로 챗봇에 무례한 행동을 하는 식으로 한도까지 밀어 붙여 챗봇의 반응을 확인할 수도 있습니다. 무례한 댓글을 처리하기 위해 여러가지 재치있는 답변을 준비해야합니다.

일반적으로 모든 응답에 대해 사용자의 의도를 먼저 감지 한 다음, 동일한 의도에 대해 다양한 응답을 시도해야 합니다. 챗봇에서 매번 동일한 응답을 다시 보는 것보다 로보트같은 느낌은 없습니다. API.ai 및 IBM Watson Conversation 또는 Dialog 서비스와 같은 대화 관리 도구를 사용하면 각 시나리오에서 준비된 응답 목록에서 무작위로 선택할 수 있습니다.

챗봇에 대한 재치있는 반응과 개성의 필요성은 "UI 디자이너로서의 작가" 운동으로 이어졌습니다. 실리콘 밸리의 기업들은 신생 챗봇을 향상시키기 위해 문학 전공 및 시인을 고용하고 있다고 합니다.

사례 연구: 위챗(WeChat)의 교훈

위챗은 월간 7억 명이 넘는 활성 사용자를 보유한 중국 최대 메시징 플랫폼입니다. 2013년에는 "공공 계정"이라는 매우 성공적인 봇 프로그램을 개척했습니다. 위챗은 챗봇 상호 작용 측면에서 무엇을 하고, 또 무엇은 하지 않았을까요?

위챗은 현재 두 가지 유형의 공개 계정 봇(구독 및 서비스)을 지원합니다. 두 유형 모두 챗봇으로 시작했지만 "인공 지능 채팅"에 집중하지 않도록 천천히 발전했습니다. 두 유형의 공공 계정 모두 CUI를 지원합니다.

구독 계정은 콘텐츠 게시자가 구독자에게 새 콘텐츠를 알리는 데 사용됩니다. 일반적으로 게시자는 하루에 한 번 오늘의 새 콘텐츠 기사 목록을 모든 구독자에게 보냅니다.

사용자는 특정 기사를 가져 오거나 특정 작업을 수행하기 위해 텍스트를 다시 입력할 수도 있습니다. 예를 들어:

  • 기사는 "본문에서 언급 한 파워포인트 슬라이드를 다운로드하려면 42를 입력하세요" 라고 언급할 수 있습니다.
  • 사용자는 "목록"를 입력하여 최근에 게시된 기사의 목록을 가져올 수 있습니다.
  • 사용자는 "연락처"라고 입력하여 계정 관리자에게 연락 할 수 있는 웹 링크를 얻을 수 있습니다.

그것들은 모두 매우 간단한 커맨드이거나 트리거 키워드라는 것을 주목하십시오. 웹 페이지 또는 다운로드로 빠르게 안내 할 수 있도록 설계되었습니다. 매우 적은 구독 계정만이 사용자와의 긴 자연어 대화를 시도합니다.

서비스 계정은 고객 서비스 조직이 위챗에서 고객과 상호 작용하는데 사용됩니다. 항공사, 호텔 또는 전자 상거래 상점을 예로 들 수 있습니다. 초기에 위챗은 AI 자동화된 챗봇이 인간 고객 지원을 처리 할 수 없다는 것을 깨달았습니다. 따라서 페이스북 페이지와 마찬가지로, 각 서비스 계정은 하나 이상의 지정된 사용자 계정을 "지원 인력"으로 가질 수 있습니다.

다음 화면 캡처는 항공사 및 신용 카드 회사의 실제 고객 서비스 채팅 세션을 보여줍니다. 텍스트가 중국어이지만, 당신은 그곳에서 무슨 일이 벌어지고 있는지 상상할 수 있습니다. 다시 말하지만, 이것은 간단한 트리거 단어와 커맨드들입니다.

일부 고객 서비스 계정의 경우 계정 소유자는 사용자와 더 긴 대화를 시도합니다. 그러나 대화는 처음에는 자동으로 수행되며, 봇이 사용자의 의도를 파악한 후에는 채팅이 관련 웹 페이지 (예 : 비행기 티켓 재예약) 또는 관련된 사람에게 신속하게 전달됩니다.

위챗의 고도로 발전된 봇 생태계의 핵심 요소는 다음과 같습니다:

  • 서로 다른 봇 응용 프로그램에는 다른 스타일의 대화식 UI가 필요합니다. 많은 봇의 경우 웹뷰로 연결되는 간단한 커맨드나 트리거 단어로 충분합니다.
  • 더 긴 봇 대화는 특정 제품에 대한 고객 지원과 같이 고도로 스크립팅된 사례에 적합합니다. 그렇지만 필요에 따라 사용자를 웹 앱이나 인간 에이전트 쪽으로 유도하는 것이 현명합니다.
  • 많은 경우 메시징 봇의 가치는 봇이 사용자의 ID, 지불 정보 및 기타 정보에 원활히 접근할 수 있도록 플랫폼과 통합되는 것에 있습니다.

정리

이 글에서는 챗봇의 대화식 디자인이 직면 한 주요 문제에 대해 설명했습니다. 귀하의 챗봇을 성공적으로 만들 수 있는 방법을 열거했으며, 그 점은 위챗의 메시징 플랫폼을 통해 설명되었습니다. 필자는 커맨드와 제어, 슬롯 채우기 및 상호 작용 대화의 세 가지 유형의 상호 작용을 제안했습니다. 또한, 다양한 종류의 사용자 입력 및 창조적인 응답 제공 방법을 다루었습니다.

@statkclee
Copy link

좋은 글 번역해 주셔서 편히 잘 읽었습니다.

@jonnung
Copy link

jonnung commented Jan 4, 2017

잘 읽었습니다. 감사합니다. ^^

@channprj
Copy link

좋은 글 고맙습니다.

@doogie0212
Copy link

좋은 글 감사합니다! 현재 진행되는 프로젝트에 반영해보도록 하겠습니다~

@nicewook
Copy link

nicewook commented Jun 2, 2017

감사히 잘 읽었습니다. 전반이 머리속에서 잘 정리됩니다.

@cxr542
Copy link

cxr542 commented Jul 28, 2017

좋은 글 잘 읽었습니다.

@kuris
Copy link

kuris commented Jan 20, 2019

좋은글 감사드립니다. 방향성 때문에 고민했는데 큰 도움이 되었어요...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment