Chatbot Development Challenges — Part 2

출처: https://hackernoon.com/chatbot-development-challenges-part-2-560bc4c169d0

Chatbot Development Challenges - Part 2

파파고 번역입니다.

 

 

In Part 1 of the series I talked about common conceptual and day-to-day development challenges in chatbot building. In this part I will discuss in detail some architectural challenges, which are the most difficult ones in my opinion.

 

이 시리즈의 제1부에서 나는 챗봇 건물에서 공통적인 개념과 일상적인 개발 도전에 대해 이야기했다. 이 파트에서 나는 내 생각으로는 가장 어려운 몇 가지 건축적 도전에 대해 상세히 논할 것이다.

 

Architectural Challenges

 

What is an architectural challenge in a general sense? Or better, how do you know that there’s an architectural challenge to be faced in your next project?

 

일반적인 의미에서의 건축적 도전은 무엇인가? 또는 다음 프로젝트에서 직면해야 할 건축적 과제가 있다는 것을 어떻게 알 수 있는가?

 

 

It can be really hard to know in advance. If you have little experience with the tech that is one of the main components of your next project you will most likely start with an iterative approach and slowly increase complexity over time as you get more comfortable. Sooner or later you will encounter a big problem that stems from the fact that the foundation of the project is very simple and not very well-thought-through. This usually happens when you get somewhere that wasn’t even considered at the starting stage, like scalability problems or widening of the scope, just to name a few. At those times you might have an Aha! moment, followed by these thoughts: “Why didn’t I think of this in the very beginning?”, “Now half of the project’s code has to be changed since my premise was wrong.”, “This is precisely why people hire domain experts instead of learning from tutorials and trying to implement everything themselves.” and so on.

 

미리 알기는 정말 어려울 수 있다. 다음 프로젝트의 주요 구성 요소 중 하나인 기술에 대한 경험이 거의 없는 경우, 반복적인 접근 방식에서 시작하여 시간이 지날수록 복잡성을 서서히 증가시킬 가능성이 높다. 머지 않아 프로젝트의 기초가 매우 단순하고 잘 생각되지 않는다는 사실에서 비롯되는 큰 문제에 직면하게 될 것이다. 이것은 대개 여러분이 단지 몇 가지 이름을 붙이기 위해서 확장성 문제나 범위의 확대와 같이 시작 단계에서 고려되지도 않은 곳에 갔을 때 발생한다. 그 때 여러분은 아하!라는 생각을 할 수 있을 것이다. "처음에는 왜 이런 생각을 하지 않았는가?" "이제는 내 전제가 틀렸기 때문에 프로젝트의 코드의 절반은 바뀌어야 한다." "이것이 바로 사람들이 튜토리얼에서 배우고 모든 것을 실행하려고 하는 것 대신에 도메인 전문가들을 고용하는 것이다..

 

 

Now that we have a general idea of what constitutes an architectural challenge, let’s consider four of them that I identified during my last 9 months doing chatbot development.

 

이제 우리는 무엇이 건축적 도전에 해당하는지에 대한 일반적인 생각을 갖게 되었으니, 내가 지난 9개월 동안 챗봇 개발을 하면서 확인한 네 가지를 생각해 보자.

 

 

Application Scope

I like the word “chatbot”. It’s short and most people will have some meaningful abstract concept connected to that word so it’s useful in everyday conversations. But it’s also pretty vague which can be harmful when it comes to people’s expectations about the technology.

 

응용 프로그램 범위
나는 "챗봇"이라는 단어를 좋아한다. 그것은 짧고 대부분의 사람들은 그 단어와 관련된 의미있는 추상적인 개념을 가지고 있을 것이다. 그래서 그것은 일상적인 대화에서 유용하다. 그러나 이 기술에 대한 사람들의 기대와 관련하여 유해할 수 있는 것은 매우 모호하다.

 

An image from  my first article on chatbots  from 9 months ago that got me started on this journey.9개월 전 첫 기사 챗봇에 대한 이미지를 통해 이 여행을 시작하게 된 겁니다.

A more appropriate name for a chatbot technology (it’s more of a definition) is the following:

programatically extensible interactive natural language FAQ system in a constrained domain

I know this definition is somewhat dense, but it gives a pretty accurate description of most chatbot projects out there.

 

챗봇 기술에 더 적합한 명칭은 다음과 같다.

제한된 도메인에서 프로그램적으로 확장 가능한 대화형 자연어 FAQ 시스템
나는 이 정의가 다소 조밀하다는 것을 알지만, 그것은 대부분의 챗봇 프로젝트에 대해 꽤 정확한 설명을 제공한다.

 

 

Let’s break down the definition:

 

정의를 세분화하자.

 

 

• Chatbots are programatically extensible since you can invoke arbitrary code in response to some user utterance. This is done with the help of Custom Actions in Rasa Core or Fulfillments in Dialogflow and is usually used to query a database or some external API and reply to a user using the returned information.

채팅은 프로그램적으로 확장 가능하다. 왜냐하면 당신이 어떤 사용자발언에 대응하여 임의 코드를 호출할 수 있기 때문이다. 이는 Rasa Core의 Custom Actions 또는 Dialogflow의 Fulfillments의 도움을 받아 수행되며, 일반적으로 데이터베이스 또는 일부 외부 API를 쿼리하고 반환된 정보를 사용하여 사용자에게 회신하는 데 사용된다.

 

 

• Chatbots are interactive since, unsurprisingly, they require input from a user in order to work. They don’t simply list all the information they know as regular FAQ pages do.

채트보트는 작업하기 위해 사용자로부터의 입력을 요구하기 때문에 당연히 상호작용한다. 그들은 단지 그들이 알고 있는 모든 정보를 일반적인 FAQ 페이지처럼 나열하지 않는다.

 

 

• Chatbots are not simply interactive. They accept input in the form of natural language so that the possible input space is extremely large.

챗봇은 단순히 상호작용이 아니다. 그들은 가능한 입력 공간이 극도로 넓도록 자연어 형태의 입력을 받아들인다.

 

 

• In my experience, the most popular (and easiest to implement!) use case for chatbots is as a FAQ system. Sure, you can make it possible to book tickets or order food via a chatbot. But in my experience the initial use case for people considering chatbots is to harness an endless stream of questions, that have been answered countless times in the past, bombarding their communication channels (email, Slack, Hangouts etc.)

내 경험으로 볼 때, 채팅봇에 가장 인기 있는 (그리고 가장 쉽게 구현할 수 있는!) 사례는 FAQ 시스템이다. 물론, 당신은 챗봇을 통해 티켓을 예매하거나 음식을 주문하는 것을 가능하게 할 수 있다. 그러나 내 경험으로 볼 때, 채팅봇을 고려하는 사람들의 초기 사용 사례는 과거에 수없이 답변된 끝없는 질문의 흐름을 이용하는 것이며, 그들의 통신 채널(이메일, 슬랙, 행아웃 등)을 폭격하는 것이다.

 

 

In many organizations email is overused and becomes very hard to manage.많은 조직에서 이메일은 너무 많이 사용되어 관리하기가 매우 어려워진다.

 

• Chatbots operate over a constrained domain. This is the most critical piece of the definition. It may be an interactive system accepting input in natural language, so, as a user, it’s tempting to subconsciously conclude that you can type anything to a bot and expect something useful to come out. But it’s just an illusion created by the fact that natural language is used as input format. By design, chatbots sacrifice explicitness of application’s capabilities in return for a more novel and intuitive user experience (arguably everyone knows how to use a chat system). As a side note, many existing user interfaces are just fine without being operated via a chatbot so it’s not always a more intuitive alternative.

채팅은 제한된 도메인에서 작동한다. 이것은 정의에서 가장 중요한 부분이다. 자연어로 입력하는 것을 받아들이는 쌍방향 시스템일 수도 있기 때문에, 사용자로서, 어떤 것이든 봇에 입력할 수 있다고 무의식적으로 결론을 내리고 유용한 것이 나오기를 기대하는 것이 유혹적이다. 그러나 그것은 자연어가 입력형태로 사용된다는 사실에 의해 만들어진 환상일 뿐이다. 설계에 따르면, 챗봇은 보다 새롭고 직관적인 사용자 경험을 제공하는 대가로 응용 프로그램의 기능에 대한 설명을 희생한다(논란적으로 모든 사람이 채팅 시스템을 사용하는 방법을 알고 있다). 부차적으로, 기존의 많은 사용자 인터페이스는 챗봇을 통해 작동되지 않아도 괜찮기 때문에 항상 더 직관적인 대안이 되는 것은 아니다.

 

 

The last part of the above definition brings us to the challenge of determining the scope of your chatbot application. It’s clear that the more conventional ways of restricting the scope of the application wouldn’t work. I.e. “everything available via the UI is within the scope”; this obviously works for most regular web apps and desktop apps, but it is not going to work for a chatbot, given the input, which is the only method to control the application, is in natural language and is not restricted in any way.

 

위의 정의의 마지막 부분은 당신의 챗봇 어플리케이션의 범위를 결정하는 도전에 이르게 한다. 응용 프로그램의 범위를 제한하는 좀 더 관습적인 방법은 효과가 없을 것이 분명하다. I.예: "UI를 통해 이용 가능한 모든 것은 범위 내에 있다"; 이것은 분명히 대부분의 일반 웹 앱과 데스크톱 앱에서 작동하지만, 응용 프로그램을 제어하는 유일한 방법인 입력이 자연 언어로 되어 있고 어떤 식으로도 제한되지 않는다는 점을 감안할 때, 챗봇에서는 작동하지 않을 것이다.

 

 

Thus, the scope of a chatbot application has to be restricted in a less direct way. There are mainly two approaches which can be combined, if desired:

 

따라서, 챗봇 어플리케이션의 범위는 덜 직접적인 방법으로 제한되어야 한다. 원하는 경우, 주로 두 가지 접근방식이 있다.

 

• It’s initially very tempting to make your bot seem like a real person (“I didn’t fill all those Small Talk templates for nothing!”*)and start the conversation with something like: “Hi, I am Super Help Bot. Ask me anything.” In my opinion, very few virtual assistants can make such a statement an really mean it (if Alexa or Siri were the ones starting a conversations, they could probably start it with that phrase). For all the other bots out there, stating the bot’s scope in detail up front is a much better approach: “Hi, I am Humble Help Bot. You can ask me about A, B and C. I may be able to help you with X, Y and Z. For all other questions please contact support@bigcompany.com”. This should help reduce a number of users trying to strike up a casual conversation with the bot and expecting complex conversations or asking about some obscure problem in 12 different ways.

처음에는 여러분의 봇을 진짜 사람처럼 보이게 하는 것이 매우 유혹적이다.*)그리고 다음과 같은 것으로 대화를 시작한다: "안녕, 나는 슈퍼 헬프 봇이야. 무엇이든 물어봐." 내 생각에는 아주 적은 수의 가상의 조수들이 그러한 진술을 정말 비열한 것으로 만들 수 있다(알렉사나 시리가 대화를 시작하는 사람들이라면 아마도 그런 문구로 시작할 수 있을 것이다). 다른 모든 보츠들에게 있어, 봇의 범위를 앞에서 자세히 말하는 것이 훨씬 더 나은 접근법이다: "안녕, 나는 허블 헬프 봇이야. A,B,C에 대해 물어봐. X, Y, Z로 도와줄 수 있을 것 같아. 다른 모든 질문은 support@bigcompany.com".으로 문의하십시오. 이것은 봇과의 일상적인 대화를 시도하고 복잡한 대화를 기대하거나 12가지 다른 방법으로 모호한 문제에 대해 질문하는 많은 사용자들을 줄이는 데 도움이 될 것이다.

 

• Once a user is in some conversation track that a bot understands, it is helpful to restrict the user’s input so that the user stays within the scope of the current track and don’t jump to a completely unrelated topic, thus confusing the bot. It can be done using the bot’s internal logic, e.g. if a user is asked for the quantity of the item they want to order, the user’s reply has to contain a number, otherwise the user will be asked the same question again (see Slot Filling with a FormAction) if you want to learn how to do this in Rasa). An even better approach would be to provide buttons with numbers that help the user with providing a valid reply. At the same time, it’s important to make it clear for the user how a conversation state can be “restarted”, so that the user doesn’t get stuck in a conversation branch that he doesn’t want to finish; keeping “cancel” button or making the bot capable of recognizing “stop”, “cancel” intents no matter what is the conversation state is helpful with that (use Intent Substitution rule in Rasa Addons to have a more fine-grained control over types of intents a bot can recognize at any point in a conversation).

일단 사용자가 봇이 이해하는 어떤 대화 트랙에 있으면, 사용자가 현재 트랙의 범위 내에 머무르고 전혀 관계없는 주제로 점프하지 않도록 사용자의 입력을 제한하는 것이 도움이 되므로 봇을 혼란스럽게 한다. 이것은 봇의 내부 논리를 이용하여 할 수 있는데, 예를 들어, 사용자가 주문하고자 하는 물품의 수량을 요구하는 경우, 사용자의 회신에는 숫자가 들어 있어야 한다. 그렇지 않으면 사용자에게 동일한 질문을 다시 하게 된다(Rasa에서 이것을 어떻게 하는지 배우려면 Slot Filling with a FormAction 참조). 더 나은 접근방식은 사용자에게 유효한 응답을 제공하는 데 도움이 되는 번호를 버튼에 제공하는 것이다. 이와 동시에, 대화 상태가 "다시 시작"될 수 있는 방법을 사용자에게 명확히 하는 것이 중요하며, 사용자가 끝내기 싫어하는 대화 분기에 갇히지 않도록 하는 것, 즉 "취소" 버튼을 유지하거나 봇을 "중지"할 수 있게 하는 것, 즉 대화 상태가 어떤 경우에 도움이 되는지에 상관없이 "취소" 직감을 주는 것이다.(Rasa Addons의 의도된 대체 규칙을 사용하여 대화 중 어느 지점에서나 봇이 인식할 수 있는 직관의 유형을 보다 세밀하게 제어하십시오.)

 

Woebot  is one of the most engaging and well-designed chatbots that I’ve tried. One of the reasons it does so well is because it provides buttons for ~80% responses to restrict user input and leads the conversation most of the time.Woebot은 내가 시도했던 것 중 가장 매력적이고 잘 디자인된 채팅창 중 하나이다. 이 프로그램이 잘 하는 이유 중 하나는 사용자 입력을 제한하기 위해 최대 80%의 응답 버튼을 제공하고 대부분의 시간을 대화를 이끌기 때문이다.

 

It’s important to clearly state the scope of your chatbot not only to the users but also to other stakeholders in the project.

 

챗봇의 범위를 사용자뿐 아니라 프로젝트 내 다른 이해관계자에게도 명확하게 기술하는 것이 중요하다.

 

 

Assume that your team has a member that dedicates some time each day to view chat logs, label and add user utterances to the training dataset. As was discussed above, it’s not easy to make the user understand and accept the scope of the bot, especially at the beginning of the conversation. Therefore, each day that team member will encounter user messages that are outside of the bot’s scope (they will usually be in the opening of the conversation). If it’s just one question like that, you can just skip it and do nothing. But what if there are ten messages within a day on the same topic that is currently outside of the bot’s scope. “It’s just a simple question, right? Why can’t we add it to the bot in the next release? We have all the training data available…” Things like this are a sure recipe for a scope creep in your project. Just adding new FAQ intents as the new questions come in without any proper planning will most likely result in an atrocious intent name structure that will confuse everyone in the future; I will talk more on this in the following subsection.

 

팀원이 매일 일정 시간을 할애하여 채팅 로그를 보고, 라벨을 붙이고, 교육 데이터 세트에 사용자 문구를 추가하는 경우를 가정해 보십시오. 위에서 논의한 바와 같이, 특히 대화의 시작에 있어서 봇의 범위를 사용자가 이해하고 받아들이도록 하는 것은 쉽지 않다. 따라서 매일 팀 구성원은 봇의 범위 밖에 있는 사용자 메시지를 접하게 된다(대개 대화의 시작에 있을 것이다). 그런 질문 하나면 그냥 건너뛰고 아무 것도 안 하면 된다. 그러나 현재 봇의 범위를 벗어난 동일한 주제에 대해 하루 안에 10개의 메시지가 있다면 어떨까. "단순한 질문일 뿐이지요? 다음 릴리스에서 봇에 추가할 수 없는 이유는? 모든 교육 자료를 확보해서..." 이와 같은 것들은 당신의 프로젝트에서 범위를 넓히는 확실한 비법이다. 적절한 계획 없이 새로운 질문이 나올 때 새로운 FAQ 정보를 추가하는 것 만으로도 미래에 모든 사람을 혼란스럽게 만들 수 있는 형편없는 의도적인 이름 구조가 될 가능성이 크다. 다음 절에서 이것에 대해 더 이야기하겠다.

 

 

Intent naming

It’s best to come up with a rough “schema” for your chatbot intents before the project starts. Otherwise over time you may end up having a large amount of similar intents that will make the training data labelling process very confusing. Here’s an example:

• help.smartphone.2fa for help requests related to general 2-FA issues on smartphone
• request.disable.smartphone.2fa for requests to disable smartphone-enabled 2-FA
• qa.disabling.2fa for general question on disabling 2-FA

의도적 명명
프로젝트가 시작되기 전에 챗봇의 직감에 대한 대략적인 "시체"를 생각해 내는 것이 가장 좋다. 그렇지 않으면 시간이 지남에 따라 교육 데이터 라벨링 프로세스를 매우 혼란스럽게 만드는 유사한 많은 양의 정보를 얻게 될 수 있다. 예를 들어보자.

- help.smartphone.2fa에서 스마트폰의 일반적인 2-FA 문제와 관련된 도움말 요청
- quest.disable.smartphone.스마트폰 지원 2FA 사용 안 함 요청 2fa
- qa.disable.2fa 2FA 비활성화에 대한 일반 질문

 

 

All of these intent names are fine on their own and probably made sense to the person that was coming up with each new intent name.

 

이 모든 의도적인 이름들은 그들 스스로도 괜찮으며 아마도 각각의 새로운 의도적인 이름을 생각해낸 사람에게 이치에 맞을 것이다.

 

 

But I see 2 problems with these. First, these intents are all describing a very similar concept and it’s really easy to mislabel a new smartphone-2-FA-related utterance when you are going through hundreds of new utterances in the logs. Second, all the training data that maps to these intents will be very similar syntactically and lexically, which is not good for the NLU model, unless you have a very large number of examples per intent and are very accurate during the labelling process.

 

하지만 나는 이것들에 두 가지 문제를 본다. 첫째, 이러한 사실들은 모두 매우 유사한 개념을 설명하고 있으며, 당신이 로그에서 수백 개의 새로운 말을 할 때 새로운 스마트폰-2와 관련된 말을 잘못 표기하는 것은 정말 쉽다. 둘째로, 이러한 사실에 매핑하는 모든 훈련 데이터는 의도별로 매우 많은 예시를 가지고 있고 라벨링 프로세스 중에 매우 정확하지 않다면 NLU 모델에 좋지 않은 동기식 및 어휘적으로 매우 유사할 것이다.

 

 

It’s much better to organize your intent names by the type of work the chatbot does when it actions on an intent. And don’t “hard code” the variables in those actions in intent names, use entities instead. Here’s how I would restructure the previous example:

 

챗봇이 의도대로 행동할 때 하는 일의 종류에 따라 당신의 의도 이름을 정리하는 것이 훨씬 낫다. 그리고 그러한 행동의 변수를 의도적인 이름으로 "하드 코드화"하지 말고 엔티티를 대신 사용한다. 이전 예를 재구성하는 방법은 다음과 같다.

 

• request.help would be used for creating all general help requests and placing them into the ticketing system. The fact that the user talks about 2-FA on a smartphone will be extracted as an entity and used to create a more specific help request for that case.

request.help는 모든 일반적인 도움말 요청을 작성하여 티켓팅 시스템에 배치하는 데 사용될 것이다. 사용자가 스마트폰에서 2-FA에 대해 말하는 사실은 실체로 추출되어 해당 사례에 대한 보다 구체적인 도움 요청을 만드는 데 사용될 것이다.

 

• request.disable would only be used if a chatbot can directly interact with the 2-FA system and unpair devices without any additional processes. In this case “2-FA on a smartphone” will be extracted as an entity so that the bot will know what to disable. And of course it should have access to some database to look up what devices the user has and clarify which one is used for 2-FA. If disabling 2-FA has to be handled by the help desk, I would go without this intent and make it so that users’ utterances asking to disable 2-FA will trigger request.help and create an appropriate support ticket using the information extracted as entities. Even better, it would log the entire user’s utterance that triggered the request.help intent to some “extra info” field of the support ticket, so that the support person viewing the ticket has more context on the request.

request.disable은 chatbot이 추가 프로세스 없이 2-FA 시스템과 직접 상호 작용할 수 있는 경우에만 사용될 수 있다. 이 경우, "스마트폰의 2-FA"는 봇이 무엇을 비활성화해야 하는지 알 수 있도록 엔티티로 추출될 것이다. 그리고 물론 그것은 사용자가 어떤 기기를 가지고 있는지 찾아보고 어떤 장치가 2FA에 사용되는지를 명확히 하기 위해 어떤 데이터베이스에 접근할 수 있어야 한다. 2-FA 비활성화가 헬프 데스크에서 처리되어야 하는 경우, 나는 이러한 의도 없이 2-FA를 비활성화하라는 사용자들의 말이 요청을 촉발하도록 할 것이다.엔티티로 추출된 정보를 사용하여 적절한 지원 티켓을 작성하고 지원 티켓을 작성한다. 더 좋은 것은, 요청을 촉발한 전체 사용자의 발언을 기록할 것이다.지원 티켓의 일부 "추가 정보" 필드에 대한 의도를 표시하여 티켓을 보는 지원 담당자가 요청에 대한 컨텍스트를 더 많이 가질 수 있도록 하십시오.

 

• qa.disabling.2fa, or anything starting with qa. in general, will be used to answer simple questions. The bot will simply look up an answer in some database storing intent-to-answer template mapping and utter the template contents.

qa.disable.2fa 또는 일반적으로 qa로 시작하는 모든 것이 간단한 질문에 대답하는 데 사용될 것이다. 봇은 단순히 답안지 템플릿 매핑을 저장하는 일부 데이터베이스에서 답을 찾아 템플릿 내용을 완성할 것이다.

 

 

As you can see, these 3 intents all require the bot to do a different type of action on the backend: creating a ticket, making changes to an external system or fetching a question-answer template. This is a pretty efficient way to keep your intents organized and makes development a bit easier when you scale to having a large number of intents. This approach also makes labelling easier since you can think the type of action that should be done by the bot to satisfy a certain user input and label it with an appropriate action-specific intent.

 

보시다시피, 이 3가지 사실들은 모두 봇이 백엔드에서 다른 종류의 행동을 하도록 요구한다. 즉, 티켓을 만들거나, 외부 시스템을 변경하거나, 질문-답변 템플릿을 가져올 수 있다. 이것은 여러분의 감각을 체계적으로 유지하고 여러분이 많은 수의 직관을 가질 때 개발을 조금 더 쉽게 할 수 있는 꽤 효율적인 방법이다. 또한 이 접근방식은 특정 사용자 입력을 만족시키기 위해 봇이 수행해야 하는 조치 유형을 생각할 수 있고 적절한 조치별 의도를 가지고 라벨을 붙일 수 있기 때문에 라벨 표시를 더 쉽게 해준다.

 

 

A few other things: be consistent whether you are using singular or plural nouns in your intent names. Otherwise every time you have to use the intent name in some other part of the application, you would have to come back to the NLU training data to see how exactly the intent name is spelled. Example: request.item.monitor and request.item.ethernet_cables.

 

다른 몇 가지 사항: 의도 이름에 단수 명사를 사용하든 복수 명사를 사용하든 일관성을 유지하십시오. 그렇지 않으면 애플리케이션의 다른 부분에서 의도 이름을 사용해야 할 때마다 NLU 교육 데이터로 돌아와 의도 이름의 철자를 정확히 확인해야 한다. 예: request.item.monitor 및 request.item.ethernet_cables.

 

 

Finally, be consistent with your verb conjugation: intents qa.disabling.2faand qa.disable.account shouldn’t be used together in the same training dataset, just stick to one conjugate form to avoid headaches.

 

마지막으로, 동사 결합: intent qa.disabled와 일관성을 유지하십시오.2fa와 qa.disable.account는 동일한 훈련 데이터 집합에서 함께 사용되어서는 안 되며, 두통을 피하기 위해 하나의 결합 형태를 고수하십시오.

 

 

Administration

Just like building any other type of software product, building a chatbot is a continuous process. An important part of building a good chatbot is to frequently monitor latest chat logs and use that data to improve the NLU model and take note which features are missing. This requires a well-designed administration tool.

 

행정부.
다른 종류의 소프트웨어 제품을 만드는 것처럼, 챗봇을 만드는 것은 연속적인 과정이다. 좋은 챗봇을 만드는 중요한 부분은 최신 채팅 로그를 자주 모니터링하고 이 데이터를 사용하여 NLU 모델을 개선하고 누락된 기능을 확인하는 것이다. 이를 위해서는 잘 설계된 관리 도구가 필요하다.

 

 

In my opinion, the main selling point of cloud chatbot solutions from companies like Google and Microsoft is their easy-to-use admin web UI for very small price (at a small scale). With a UI like that, a team member with any level of technical knowledge can easily contribute to the project by reviewing the latest conversation logs, labelling user utterances that weren’t recognized by the bot and creating new intents.

 

내 생각에 구글이나 마이크로소프트와 같은 회사의 클라우드 챗봇 솔루션의 주요 판매점은 아주 작은 가격으로 사용하기 쉬운 관리 웹 UI이다. 이와 같은 UI를 통해, 어떤 수준의 기술 지식을 가진 팀 구성원은 최신 대화 로그를 검토하고, 봇이 인식하지 못한 사용자 발언을 기록하고, 새로운 정보를 만들어냄으로써 프로젝트에 쉽게 기여할 수 있다.

 

One of the biggest advantages of using Dialogflow is being able to work on your bot using an interface like this.Dialogflow의 가장 큰 장점 중 하나는 이와 같은 인터페이스를 사용하여 당신의 봇을 작업할 수 있다는 것이다.

 

In the world of open-source chatbots, a good admin UI is arguably the most valuable asset to a chatbot consultant or an open-source chatbot framework developer. In fact, Rasa Technologies GmbH, the company behind Rasa Stackgenerates its revenue by providing technical support and selling licenses for Rasa Platform which is a suite of tools that help with development, support and administration of a Rasa Stack chatbot.

 

오픈소스 챗봇의 세계에서 훌륭한 관리 UI는 챗봇 컨설턴트나 오픈소스 챗봇 프레임워크 개발자에게 가장 귀중한 자산이다. 실제로, Rasa Stack의 뒤에 있는 회사인 Rasa Technologies GmbH는 Rasa Stack Chatbot의 개발, 지원 및 관리를 돕는 도구 모음인 Rasa Platform에 대한 기술 지원과 판매 라이선스를 제공함으로써 수익을 창출한다.

 

 

How the chatbot is going to be managed day-to-day is an important thing to consider when you are just starting out with the project and unsure which framework to consider.

 

챗봇이 어떻게 매일 관리될 것인가는 프로젝트를 막 시작할 때 고려해야 할 중요한 사항이며 어떤 프레임워크를 고려해야 할 지 확실하지 않다.

 

 

You can go with Dialogflow or Mircrosoft LUIS and be confident that managing your bot won’t become a huge hassle as it grows, thanks to a suite of admin tools with a good UI. You will also have it for free or at a very small cost if the number of users is small (perfect for PoCs!). The tradeoff is that all the infrastructure and user data will be in the cloud (which is not suitable for some organizations). Like with all other Google products, if you decide to use Dialogflow, you give an irrevocable right to use the data that goes through Dialogflow agent to Google forever.

 

Dialogflow 또는 Mircrosoft LUIS와 함께 사용할 수 있으며, UI가 좋은 관리 툴 제품군 덕분에 봇을 관리하는 것이 점점 더 복잡해지지 않을 것이라는 확신을 가질 수 있다. 또한 사용자 수가 적은 경우(PoCs에 적합!) 무료로 또는 매우 적은 비용으로 사용할 수 있다. 그 단점은 모든 인프라와 사용자 데이터가 클라우드에 있을 것이라는 것이다(일부 조직에 적합하지 않음). 다른 모든 구글 제품과 마찬가지로, 만약 당신이 Dialogflow를 사용하기로 결정한다면, 당신은 Dialogflow 에이전트를 통해 구글에 영원히 데이터를 사용할 수 있는 취소할 수 없는 권리를 부여한다.

 

 

Relevant section from the Google APIs Terms of Service.Google API 서비스 약관의 관련 섹션.

 

The other way is to use an open source framework, like Rasa Stack. Unless you are just playing around with the framework or your project is really small, you will soon understand the need for a good admin interface. After that, you need to perform a cost-benefit analysis of whether it makes more sense to roll your own admin tools and complementing UI (there’s a lot more depth to these than you might initially think and thus quite nontrivial to develop) or purchase them from Rasa or some other third-party provider.

 

다른 방법은 Rasa Stack과 같은 오픈 소스 프레임워크를 사용하는 것이다. 당신이 단지 프레임워크를 가지고 놀고 있거나 당신의 프로젝트가 정말로 작지 않다면, 당신은 곧 좋은 관리 인터페이스의 필요성을 이해할 것이다. 그 후에, 당신은 당신 자신의 관리 툴을 롤링하고 UI를 보완하는 것이 더 이치에 맞는지에 대한 비용 편익 분석을 수행할 필요가 있다(이것들은 당신이 처음에 생각할 수 있는 것보다 훨씬 더 깊어서 개발하기에 상당히 비개인적이다).

 

 

Replacing existing process with a chatbot

If you are developing a chatbot with the plan to replace some existing process, it will be an uphill battle.

 

기존 프로세스를 챗봇으로 교체
기존의 일부 프로세스를 대체하려는 계획을 가지고 챗봇을 개발하고 있다면, 그것은 힘든 싸움이 될 것이다.

 

 

As in the other parts of this article, I will take an IT help desk chatbot as an example. Assume that the current process to get IT help in the organization is to email the help desk, then someone reads the email and creates the support ticket manually. Now, since we are not considering automated email systems in this article, the chatbot project would, obviously, require us to select some communication channel for the chatbot. Let’s say that the organization is using Google Hangouts for chats so it makes sense to select it as a main channel for the chatbot. Then we tell the users to add the bot to their contact list and contact it with their IT support questions instead of using email. It’s easy to underestimate the difficulty of this pattern change for a lot of users. This change is difficult for several reasons:

 

이 글의 다른 부분처럼, 나는 IT 헬프 데스크 챗봇을 예로 들 것이다. 조직에서 IT 지원을 받기 위한 현재 프로세스가 헬프 데스크에 이메일을 보낸 다음 누군가가 이메일을 읽고 지원 티켓을 수동으로 생성하는 것이라고 가정하십시오. 이제, 이 기사에서 자동화된 이메일 시스템을 고려하지 않기 때문에, 챗봇 프로젝트는, 명백히, 우리가 챗봇을 위한 어떤 통신 채널을 선택하도록 요구할 것이다. 이 조직이 채팅에 구글 행아웃을 사용하고 있기 때문에 채팅봇의 메인 채널로 선택하는 것이 타당하다고 하자. 그런 다음 사용자에게 봇을 연락처 목록에 추가하고 e-메일을 사용하는 대신 IT 지원 질문으로 연락하도록 지시하십시오. 많은 사용자들이 이러한 패턴 변화의 어려움을 과소평가하기 쉽다. 이러한 변경은 다음과 같은 몇 가지 이유로 어렵다.

 

 

• Using a different channel, than previously, to contact support is hard to get used to; after years of emailing the help desk with the IT problems it’s just unnatural to message the bot on Google Hangouts about these issues. The problem is even worse if the channel selected for the chatbot is not used for anything else within the organization: e.g. an organization uses Microsoft Communicator for chats instead of Google Hangouts and email for IT support and chatbot is developed for Hangouts.

이전과는 다른 채널을 사용하여 지원에 연락하는 것은 익숙해지기가 어렵다. 수년 동안 IT 문제와 함께 헬프 데스크에 이메일을 보낸 후 이러한 문제에 대해 구글 행아웃에 메시지를 보내는 것은 부자연스럽다. 챗봇으로 선택된 채널이 조직 내 다른 어떤 채널에도 사용되지 않는다면 문제는 더욱 심각해진다. 예를 들어, 조직은 구글 행아웃 대신 채팅에 마이크로소프트 Communicator를 사용하고 IT 지원을 위한 전자 메일을 사용하고 챗봇은 행아웃용으로 개발된다.

 

Managing multiple chat apps is inconvenient. Don’t make this worse by putting a chatbot in yet another app.여러 개의 채팅 앱을 관리하는 것은 불편하다. 챗봇을 다른 앱에 넣었다고 해서 더 악화시키지 마라.

 

• A lot of people will miss the fact that IT support is now done via a chatbot altogether. Not everyone reads announcements on IT support webpage; most contact support only when they need help using the customary communication channel.

많은 사람들은 IT 지원이 이제 완전히 챗봇을 통해 이루어졌다는 사실을 그리워할 것이다. 모든 사람이 IT 지원 웹페이지에서 공지사항을 읽는 것은 아니며, 대부분의 연락처는 관례적인 통신채널을 사용하는 데 도움이 필요할 때만 지원된다.

 

 

• Most chatbots perform rather poorly right after initial release to the intended public. The reason is that before the release the only people who tested the chatbot are its developing team and some beta testers. It’s really easy to get entrenched into a particular way of interacting with the bot when you’ve been using it for so long during the development, thus it’s extremely hard to make sure the bot works well for all the possible inputs within its scope. Every chatbot needs to interact with real users to get the training data that will help improve it. At the same time, the first users may be reluctant to use the bot again, since it will not perform well initially due to the lack of the real training data. This is a “chicken-and-egg”dilemma of chatbot development.

대부분의 채팅창은 의도된 대중에게 처음 공개된 직후에 다소 형편없는 성능을 발휘한다. 그 이유는 출시 전에 챗봇을 테스트한 사람은 개발팀과 일부 베타 테스터뿐이기 때문이다. 개발 중에 너무 오랫동안 사용했을 때 특정 방식으로 봇과 상호작용하는 데 몰두하는 것은 정말 쉬우므로, 봇이 범위 내에서 가능한 모든 입력에 대해 잘 작동하도록 하는 것은 매우 어렵다. 모든 챗봇은 이를 개선하는 데 도움이 되는 훈련 데이터를 얻기 위해 실제 사용자들과 상호 작용해야 한다. 동시에, 첫 번째 사용자들은 봇이 실제 훈련 데이터가 부족하여 처음에는 성능이 좋지 않을 것이기 때문에 봇을 다시 사용하는 것을 꺼릴 수 있다. 챗봇 개발의 '닭과 달걀' 딜레마다.

 

 

The bottom line is: a team that undertakes a task of developing a chatbot that will eventually replace an existing process should try their best to integrate a chatbot with a chat platform that is already used the most within an organization. A mental switch required to become accustomed to communicating your problems to a programatically extensible interactive natural language FAQ system in a constrained domain (a.k.a. a chatbot) instead of a human being is already a large one. Don’t make it worse by changing the platform that enabled that communication, unless it’s absolutely necessary.

 

요컨대 결국 기존 프로세스를 대체할 챗봇 개발 과제를 수행하는 팀은 조직 내에서 이미 가장 많이 사용되는 채팅 플랫폼과 챗봇을 통합하기 위해 최선을 다해야 한다는 것이다. 인간 대신 제한된 도메인(예: 챗봇)의 프로그램적으로 확장 가능한 대화형 자연어 FAQ 시스템에 당신의 문제를 전달하는 데 익숙해져야 하는 정신적 스위치는 이미 큰 것이다. 꼭 필요하지 않는 한, 그 통신을 가능하게 한 플랫폼을 변경함으로써 상황을 악화시키지 마십시오.

 

 

Also do controlled releases to ever-increasing groups of users. This will help the bot learn from real data for as long as possible without compromising its reliability within a significantly large group of users. In the IT help desk chatbot context, this would mean making it available to one department within an organization at a time (after a substantial amount of beta-testing, of course).

 

또한 지속적으로 증가하는 사용자 그룹에 대해 제어된 릴리즈를 수행하십시오. 이것은 봇이 상당히 큰 사용자 그룹 내에서 신뢰성을 훼손하지 않고 가능한 한 오랫동안 실제 데이터로부터 배울 수 있도록 도와줄 것이다. IT 헬프 데스크 챗봇 컨텍스트에서 이는 한 번에 한 부서에서 사용할 수 있게 하는 것을 의미한다(물론 상당한 양의 베타 테스트 후).

 

 

Conclusion

Chatbots offer a novel way of creating an ever-expanding interactive FAQ system. They also enable users to use a familiar environment (a popular chat application) to interact with services like IT help desk, food delivery, appointment booking assistant or hotel concierge; all without a real person being actively engaged on the other side of the conversation. This results in significant time savings for a business, since workers that were busy handling basic customer interactions can now concentrate on less trivial conversations (which are definitely less numerous) or switch their attention to other work.

 

결론
채팅봇은 끊임없이 확장되는 대화형 FAQ 시스템을 만드는 새로운 방법을 제공한다. 또한 사용자는 IT 헬프 데스크, 음식 배달, 예약 안내원 또는 호텔 컨시어지와 같은 서비스와 상호 작용하기 위해 익숙한 환경(인기 채팅 응용 프로그램)을 사용할 수 있다. 이는 기본적인 고객 상호작용을 다루느라 바빴던 근로자들이 이제 덜 사소한 대화에 집중하거나(분명히 덜 많은) 다른 업무로 주의를 돌릴 수 있기 때문에 기업에 상당한 시간 절약을 가져다 준다.

 

Many people are very accustomed to a chat UI.

Chatbots also enable users to save their own time. An opportunity cost of contacting a chatbot is minimal. In the worst case, a chatbot won’t know an answer to a user’s inquiry and will handoff a conversation to a human agent; in such case a user wastes a few minutes, compared to if they contacted a human agent right away. In the best case scenario, a bot will be able to help with a user’s inquiry and will act on it immediately; a user will save time by not having to wait in a queue (or an email reply) and will receive response to any request in the matter of milliseconds.

 

채트보트는 또한 사용자들이 그들만의 시간을 절약할 수 있게 해준다. 챗봇에 연락하는 기회비용은 적다. 최악의 경우, 챗봇은 사용자의 질문에 대한 답을 알지 못하며 대화를 인간 에이전트에 전달한다. 이러한 경우 사용자는 즉시 인간 에이전트와 접촉했을 때와 비교하여 몇 분 동안 낭비한다. 최선의 경우, 봇은 사용자의 조회를 도울 수 있고 즉시 조치를 취할 것이다. 사용자는 대기열(또는 이메일 응답)에서 기다리지 않아도 됨으로써 시간을 절약할 수 있으며, 밀리초 이내에 어떤 요청에도 응답을 받을 수 있다.

 

 

Now, obviously I wouldn’t have written this article if it had been easy to reap the benefits of a chatbot without doing much work. Developing a good chatbot is a lot of work. It requires everyone undertaking the project to challenge some of the misconception people commonly have around the chatbot technology. It also poses some development challenges that are unique to ML-enabled applications (I imagine that for many a chatbot would be their first ML application development experience). Finally, developing a chatbot will require a great deal of planning. This planning involves everything from chatbot and auxiliary tools architecture to its integration with existing processes to strategies for making users accustomed to the chatbot faster. If your hope is to figure this out as you go, you will end up rediscovering a lot of problems that other chatbot developers have previously encountered. In the end, you might waste lots of time solving these problems when a solution was readily available. Chatbots are relatively new but there already exist best practices and essential tools for working with this technology.

 

자, 많은 일을 하지 않고도 챗봇의 이익을 얻는 것이 쉬웠더라면 분명히 나는 이 글을 쓰지 않았을 것이다. 좋은 챗봇을 개발하는 것은 많은 일이다. 그것은 모든 사람들이 챗봇 기술에 대해 일반적으로 가지고 있는 오해 중 일부에 도전하도록 프로젝트를 수행하는 것을 요구한다. 그것은 또한 ML 지원 어플리케이션에 고유한 몇 가지 개발 과제를 제기한다(많은 사람들에게 챗봇은 그들의 첫 번째 ML 어플리케이션 개발 경험이 될 것으로 생각한다). 마지막으로, 챗봇을 개발하려면 많은 계획이 필요할 것이다. 이 계획에는 챗봇과 보조 도구 아키텍처에서부터 기존 프로세스와의 통합, 챗봇에 익숙해지는 사용자를 더 빨리 만들기 위한 전략에 이르기까지 모든 것이 포함된다. 만약 여러분의 희망이 여러분이 나아가면서 이것을 알아내는 것이라면, 여러분은 결국 다른 챗봇 개발자들이 이전에 겪었던 많은 문제들을 재발견하게 될 것이다. 결국, 당신은 해결책을 쉽게 구할 수 있을 때 이러한 문제들을 해결하는 데 많은 시간을 낭비할 수 있다. 채팅봇은 비교적 새롭지만 이미 이 기술로 작업하기 위한 모범 사례와 필수적인 도구가 존재한다.

 

 

I hope that this article was helpful at raising awareness about common chatbot development challenges among those who are just starting out on this path. This article is far from providing silver bullets to the mentioned challenges; looking forward towards other people involved with the chatbots sharing their opinion on these challenges.

 

나는 이 기사가 이제 막 이 길을 시작하는 사람들 사이에서 흔한 챗봇 개발 도전에 대한 인식을 높이는 데 도움이 되었기를 바란다. 이 기사는 언급된 도전에 은빛 총알을 제공하는 것과는 거리가 멀다; 이러한 도전에 대한 자신의 의견을 공유하는 채팅봇들과 관련된 다른 사람들을 기대하고 있다.

 

 

You can find other articles by me either in my Medium profile or on my website (the website has slightly more content). I write about pretty much everything that is listed in my Medium bio: ML, chatbots, cryptoassets, InfoSec and Python.

 

당신은 내 중간 프로필이나 내 웹사이트에서 다른 기사들을 찾을 수 있다. 나는 ML, 챗봇, 암호 해독기, InfoSec, Python 등 나의 Medium bio에 나열된 거의 모든 것에 대해 쓰고 있다.