티스토리 뷰
Chatbot Development Challenges - Part 1
What to expect when you start building your first chatbot
hackernoon.com
파파고 번역입니다.
Last October, virtual assistants were placed at the Peak of Inflated Expectationsin 2017 Gartner Hype Cycle for Emerging Technologies. It was a substantial jump from the middle of the Innovation Trigger part of the cycle in 2016. Around the same time in October, conversational platforms were named as one of 10 strategic technology trends for 2018 by Gartner. From my subjective point of view, chatbots indeed generated a lot of hype this year, surpassed only by cryptoassets, machine learning in its general sense and IoT.
지난 10월, 가상의 보조자들은 이머징 테크놀로지스를 위한 2017년 Gartner의 하이페 사이클에서 인플레이션 기대의 정점에 배치되었다. 2016년 이노베이션 트리거(innovation Trigger) 부분에서 크게 뛰어올랐다. 10월경에는 가트너에 의해 2018년 10대 전략기술 트렌드 중 하나로 대화플랫폼이 선정되었다. 나의 주관적인 관점에서 보면, 채팅봇은 올해 암호 해독, 기계학습, IoT에 의해서만 능가하는 많은 과대광고를 만들어냈다.
For a technology, being at the Peak of Inflated Expectations and heading towards the Trough of Disillusionment certainly entails something. Too many unsupported claims and promises multiplying each day, inadequate developer tools, roadblocks in fundamental research supporting the technology, the list can go on; as any technology reaches a certain level of public attention, more people will actually use it and see the real state of affairs.
기술적으로, 인플레이션 기대의 정점에 있고, 혼란의 고비를 향해 가는 것은 확실히 어떤 것을 수반한다. 매일 너무 많은 지지받지 못하는 주장과 약속, 불충분한 개발자 도구, 기술을 뒷받침하는 기초 연구의 장애물, 목록은 계속 될 수 있다. 어떤 기술이 대중의 특정 수준에 도달하면, 더 많은 사람들이 실제로 그것을 사용하고 실제 상황을 보게 될 것이다.
Going towards a Trough of Disillusionment on a hype cycle doesn’t mean no one will be working on chatbots once we get there. There will be less interest from the public, the media and the investors; but there will also be many developers and researchers quietly building chatbots. Those developers and researchers will make sure that once promising tech delivers useful results, albeit many challenges along the way.
과대 선전 사이클을 통해 장애의 고통을 겪는다고 해서, 우리가 일단 그곳에 도착하고 나면 아무도 채팅방에 대해 작업하지 않을 것이라는 것을 의미하지는 않는다. 대중, 언론, 그리고 투자자들의 관심은 줄어들 것이다; 하지만 많은 개발자들과 연구자들이 조용히 챗봇을 만들 것이다. 이러한 개발자들과 연구원들은 일단 유망한 기술들이 비록 많은 난제들이긴 하지만 유용한 결과를 제공하도록 확실히 할 것이다.
I wanted to take a stab at laying out some of the challenges with chatbots. I will not be talking about the fundamental difficulties facing fields of traditional natural language processing (NLP) and deep learning, the two research disciplines standing behind today’s chatbots’ ability to understand human speech. Instead, I will share some challenges that I encountered when working on chatbots as a developer. It’s important for new chatbot developers to be aware of these things, as I felt they were very general challenges not specific to my projects.
나는 챗봇을 가지고 몇 가지 도전에 대해 생각해 보고 싶었다. 나는 전통적인 자연 언어 처리와 깊은 학습이라는 분야에서 직면하고 있는 근본적인 어려움에 대해 이야기하지 않을 것이다. 이 두 연구 분야는 오늘날의 채팅봇들의 인간 말 이해 능력 뒤에 서 있다. 대신, 나는 개발자로서 채팅봇을 다룰 때 마주친 몇 가지 도전들을 공유하겠다. 새로운 챗봇 개발자들은 이러한 것들을 인지하는 것이 중요하다. 왜냐하면 나는 그것들이 내 프로젝트에 특정되지 않은 매우 일반적인 도전이라고 느꼈기 때문이다.
My experience with chatbots
I wanted to share some bits of my background that are relevant to the topic of chatbots. This is done solely to make you aware of some of the biases that I might have.
나는 채팅봇 주제와 관련된 내 배경의 일부를 공유하고 싶었다. 이것은 단지 내가 가질 수 있는 편견의 일부를 당신에게 알리기 위해서 행해졌다.
Over the last 8 months I worked on several chatbot projects and had an opportunity to chat with quite a few teams about their experiences with building chatbots.
지난 8개월 동안 나는 여러 개의 챗봇 프로젝트를 작업했고 꽤 많은 팀들과 채팅봇을 만든 경험에 대해 이야기를 나눌 기회를 가졌다.
My experiences with different chatbot frameworks:
- Dialogflow: 2 projects
- Rasa Stack: 3 projects
- Microsoft LUIS: saw a demo at a sales presentation :)
다양한 Chatbot 프레임워크에 대한 내 경험:
- Dialogflow: 2개의 프로젝트
- Rasa 스택: 3개의 프로젝트
- Microsoft LUIS: 세일즈 프레젠테이션에서 데모 보기 :)
This write-up is based on the part of the presentation on chatbots that I gave while working as a software developer intern at Telus, a Canadian telco. You can view the deck used in that presentation in my LinkedIn profile (it’s named Chatbots: Lessons Learned).
이 작성은 캐나다 텔루스에서 소프트웨어 개발자 인턴으로 일하면서 내가 준 채팅봇에 대한 프레젠테이션의 한 부분을 바탕으로 한 것이다. 내 LinkedIn 프로필에서 해당 프레젠테이션에 사용된 데크를 볼 수 있다(Chatbots: 교훈을 얻었다.)
Since I had the most experience developing with Rasa Stack, some of the examples will mention Rasa-specific concepts. I will also touch on Dialogflow a little. Otherwise, I try to talk about chatbot development in general but my generalizations may be wrong given my limited exposure to other frameworks.
내가 라사 스택과 함께 발전한 경험이 가장 많았기 때문에, 몇몇 예들은 라사 특유의 개념을 언급할 것이다. 나는 또한 Dialogflow에 대해 조금 언급할 것이다. 그렇지 않으면, 나는 일반적으로 챗봇 개발에 대해 이야기하려고 노력하지만, 다른 틀에 대한 나의 제한된 노출로 볼 때 나의 일반화는 틀릴 수 있다.
Conceptual Challenges
This section features a couple of conceptual challenges (also known as common misconceptions). It’s important that all stakeholders in a chatbot project overcome these challenges in order to have more realistic expectations about the chatbot and the project’s timeline.
이 절에는 몇 가지 개념적 과제(일반적인 오해라고도 함)가 있다. 챗봇 프로젝트의 모든 이해 당사자들이 챗봇과 프로젝트의 타임라인에 대한 보다 현실적인 기대를 가지기 위해서는 이러한 과제를 극복하는 것이 중요하다.
Self-improvement capabilities
A misconception that a piece of technology with self-improvement capabilitieswill readily deliver substantial time savings for an organization is common among those who are just starting out with any project that uses machine learning (ML), not just chatbots. I guess the thinking in this case is that you only need to bootstrap a chatbot so that it can handle basic interactions; after that it will be able to learn more complicated interactions by itself over time.
자기 계발 능력을 가진 기술이 조직에 상당한 시간을 절약해 줄 것이라는 잘못된 생각은 단순한 채팅봇이 아니라 기계학습(ML)을 사용하는 어떤 프로젝트에서 막 시작한 사람들 사이에서 흔하다. 나는 이 경우에 여러분이 기본적인 상호작용을 다룰 수 있도록 챗봇만 부트랩하면 된다고 생각한다. 그 후에는 시간이 지남에 따라 더 복잡한 상호작용을 스스로 배울 수 있을 것이다.
Over-optimistic thinking about new technologies, especially the AI, is really common and unsurprising given the mainstream media coverage of the topic.
신기술, 특히 AI에 대한 지나치게 낙관적인 사고는 이 주제에 대한 주류 언론의 보도 내용을 감안할 때 정말 흔하고 놀랍지 않다.
Exaggerated claims in the press about the intelligence of computers is not unique to our time, and in fact goes back to the very origins of computing itself.
(quoted from the article linked above)
컴퓨터의 지능에 대한 언론의 지나친 주장은 우리 시대만의 것이 아니며, 사실 컴퓨터 자체의 기원으로 거슬러 올라간다.
(위에 링크된 글에서 인용)
In just a matter of few days of actual hands-on development experience, most people start understanding the limitations of the technology and realize a few things about self-improvement in the context of chatbots:
실질적인 개발 경험의 며칠 만에 대부분의 사람들은 기술의 한계를 이해하기 시작하고 채팅봇의 맥락에서 자기 계발에 관한 몇 가지 사항을 깨닫는다.
- Any degree of self-improvement requires a good natural language understanding (NLU) pipeline.
- Even fully-automated NLU feedback pipeline requires constant supervision (all chatbot frameworks use supervised learning models)
- You need to develop really good admin UI for an efficient and painless supervision process (more on this in part 2)
-어떤 정도의 자기계발에도 훌륭한 자연어 이해(NLU) 파이프라인이 필요하다.
-완전히 자동화된 NLU 피드백 파이프라인도 지속적인 감독을 필요로 함(모든 Chatbot 프레임워크는 감독된 학습 모델을 사용함)
-효율적이고 통증이 없는 감독 프로세스를 위해 정말 좋은 관리 UI를 개발해야 함(2부 참조)
After all, a supervised ML model doesn’t really have self-improvement capability as its intrinsic property. It’s up to the developers to build tools and pipelines around the model that will make it seem like the model can learn new things with very little effort from its human supervisors.
결국, 감독된 ML 모델은 사실 자체 개선 능력을 가지고 있지 않다. 모델을 중심으로 도구와 파이프라인을 만드는 것은 개발자들에게 달려있다. 그것은 모델이 인간 감독자들로부터 아주 적은 노력으로 새로운 것들을 배울 수 있는 것처럼 보이게 할 것이다.
Viability of leveraging existing data
This misconception is another common one among those who haven’t had practical experience with ML beforehand. In my experience the thought process goes like this: “My organization has lots of data. It’s widely known that data is fuel for ML, therefore having lots of data will make it easy to create a successful ML-enabled application.”
기존 데이터 활용 가능성
이런 잘못된 생각은 ML에서 실제적인 경험을 하지 못한 사람들 사이에서 또 다른 흔한 생각이다. 내 경험상 사고 과정은 다음과 같다: "우리 조직은 많은 데이터를 가지고 있다. 데이터가 ML의 연료라는 것은 널리 알려져 있기 때문에 많은 데이터를 보유하면 ML이 지원하는 성공적인 애플리케이션을 쉽게 만들 수 있을 것이다."
The problem with this line of reasoning is, of course, that simply having some data that is semi-related to your project is far from enough. I’ve read somewhere that more than half of a data scientist’s work day is spent preprocessing the data (I don’t have sources to back this up but the figure seems about right in my experience). While preparing existing data for use in a chatbot project is not exactly the same as data preparation for a data science analysis, it’s still very time consuming.
물론 이러한 추론의 문제는 당신의 프로젝트와 반 관련되는 데이터를 단순히 갖는 것만으로는 충분치 않다는 것이다. 나는 데이터 과학자의 하루 중 절반 이상이 데이터를 처리하는 데 소비된다는 것을 어디선가 읽은 적이 있다. 챗봇 프로젝트에서 사용하기 위해 기존 데이터를 준비하는 것이 데이터 과학 분석을 위한 데이터 준비와 정확히 같지는 않지만, 여전히 시간이 많이 소요된다.
To illustrate difficulties with leveraging existing data more concretely, let’s assume that the chatbot project we are working on is some enterprise help desk chatbot (that was the application of my very first chatbot project). There are two major ways you can go about chatbot NLU training data preparation.
기존 데이터를 보다 구체적으로 활용함에 있어 어려움을 설명하기 위해, 현재 진행 중인 챗봇 프로젝트는 엔터프라이즈 헬프 데스크 챗봇(내 첫 번째 챗봇 프로젝트의 적용이었습니다)이라고 가정해 봅시다. 챗봇 NLU 교육 데이터 준비에는 크게 두 가지 방법이 있다.
Existing data in different format
Assume that your current help desk operates via email. You have lots of training data in the email form. You figured out how to do bulk exports from Outlook (or any other email client), how to convert exported files to plain text, how to strip headers and other fluff, like “Hi …”, “Thanks, …” or super long signatures containing company’s entire policy on email communications.
다른 형식의 기존 데이터
현재 헬프 데스크가 전자 메일을 통해 작동한다고 가정하십시오. 당신은 이메일 양식에 많은 교육 자료를 가지고 있다. Outlook(또는 다른 전자 메일 클라이언트)에서 대량 내보내기를 수행하는 방법, 내보낸 파일을 일반 텍스트로 변환하는 방법, 헤더 및 기타 작업(예: "Hi ...", "Thank, ..." 또는 이메일 통신에 대한 회사의 전체 정책을 포함하는 수퍼 롱 서명)을 알아낸 경우.
What you have left is still relatively long messages, sometimes multiple paragraphs long, that are definitely not chatbot training data material; the way people communicate in a chat environment is very different from email communications.
당신이 남긴 것은 여전히 상대적으로 긴 메시지, 때로는 여러 단락의 긴 메시지로서, 이것은 확실히 챗봇 훈련 데이터 자료가 아니다; 사람들이 채팅 환경에서 의사소통하는 방식은 이메일 통신과 매우 다르다.
There are two ways to go from here:
- One, you take note of common problem types from those emails and use them as a foundation when coming up with the chatbot-appropriate training data yourself; you would have to think of the ways people could’ve asked their emailed questions in a chat environment. In this case the existing data only helped you to define the initial domain of your chatbot’s NLU capabilities. The bulk of data preparation work is still on you or your team.
- The other way is to ditch the chatbot project idea altogether and go with an automated email response system. This approach is not in the scope of this article.
여기서부터 갈 수 있는 두 가지 방법이 있다.
- 첫째, 이러한 이메일의 일반적인 문제 유형에 주목하여 직접 챗봇에 맞는 교육 데이터를 작성할 때 기본으로 활용하십시오. 사람들이 채팅 환경에서 이메일 질문을 할 수 있었던 방법을 생각해 보아야 할 것이다. 이 경우 기존 데이터는 챗봇의 NLU 기능의 초기 도메인을 정의하는 데만 도움이 되었다. 대부분의 데이터 준비 작업은 여전히 당신이나 당신의 팀에 있다.
- 다른 방법은 챗봇 프로젝트 아이디어를 완전히 버리고 자동화된 전자 메일 응답 시스템으로 가는 것이다. 이 접근방식은 이 글의 적용범위가 아니다.
Existing data in same format
Assume that your current help desk operates via a chat system (e.g. Slack, Google Hangouts or similar). You export all the dialogue data and take only user utterances without help desk agent responses. You examine all the utterances and go through the process of data labelling, assigning the correct category (intent) to each utterance. You’ve successfully leveraged your existing data!
동일한 형식의 기존 데이터
현재 헬프 데스크가 채팅 시스템(예: 슬랙, Google Hangout 등)을 통해 작동한다고 가정하십시오. 모든 대화 데이터를 내보내고 헬프 데스크 에이전트의 응답 없이 사용자 말만 실행하십시오. 모든 설명을 검토하고 데이터 레이블링 프로세스를 수행하여 각 표현에 올바른 범주(입력)를 할당하십시오. 기존 데이터를 성공적으로 활용하셨습니다!
It seems that this was as easy as it could get for a ML project: you just get your raw data and make it suitable for supervised learning algorithms by labelling it. Well, assigning intents to utterances is actually much more complicated than data labelling for something like computer vision datasets (e.g. ImageNet). I will touch more on reasons for this in part 2 of the series. In general, attaching labels to human speech is a much more subjective process than labelling images with concrete objects.
이것은 ML 프로젝트에서 얻을 수 있는 최대한 쉬웠던 것 같다. 즉, 원시 데이터를 가져와 라벨을 붙임으로써 감독되는 학습 알고리즘에 적합하게 만든다. 음, 발음에 정보를 할당하는 것은 컴퓨터 비전 데이터 세트(예: ImageNet)와 같은 것에 대한 데이터 라벨링보다 실제로 훨씬 더 복잡하다. 나는 이 시리즈의 2부에서 이것에 대한 이유를 더 많이 다룰 것이다. 일반적으로 인간의 언어에 라벨을 붙이는 것은 구체적인 물체로 이미지를 표시하는 것보다 훨씬 더 주관적인 과정이다.
Development challenges
Challenges presented in this section are, in my opinion, special to chatbot development. Though, I feel like these challenges may also be true for other machine learning application development processes, I can speak with certainty only about chatbot development.
개발 과제
이 섹션에서 제시된 도전은, 내 생각에, 챗봇 개발에는 특별하다. 비록, 나는 이러한 도전들이 다른 기계 학습 응용 프로그램 개발 과정에서도 사실일 수 있다고 생각하지만, 나는 챗봇 개발에 대해서만 확실하게 말할 수 있다.
ML model nondeterminism
To clarify this subsection’s title, I will talk about how ML models can be nondeterministic when comparing same models (same architecture and same hyperparameters) between different training sessions, and how this affects chatbot development.
ML 모델 비결정론
본 하위섹션의 제목을 명확히 하기 위해, ML 모델이 다른 교육 세션 간에 동일한 모델(동일한 아키텍처와 동일한 하이퍼 파라미터)을 비교할 때 어떻게 결정적이지 않을 수 있는지, 그리고 이것이 챗봇 개발에 어떻게 영향을 미치는지에 대해 이야기하겠다.
First, it’s important to note that every model’s weights will be different between training sessions even when a model architecture and hyperparameters are unchanged. This happens due to random weight initialization and data shuffling. But this shouldn’t introduce any noticeable effects to your model’s performance, given your training dataset is not very small.
첫째, 모델 아키텍처와 하이퍼 파라미터가 변경되지 않은 경우에도 모든 모델의 가중치는 훈련 세션 간에 다를 것이라는 점에 유의해야 한다. 이는 무작위 체중 초기화 및 데이터 분쇄로 인해 발생한다. 그러나 교육 데이터 세트가 그리 작지 않다는 점을 감안할 때 이는 모델의 성능에 어떤 현저한 영향을 미치지 않아야 한다.
What can make variance in weight values have negative effects on a chatbot development process is errors in labelling or structuring of training data.
체중 값의 차이를 만들 수 있는 것은 챗봇 개발 프로세스에 부정적인 영향을 미칠 수 있는 것은 훈련 데이터의 라벨링 또는 구조화 오류다.
Errors in NLU data
Let’s use help desk chatbot example again. Imagine having a rather large intent mapping for your NLU model of about 300 intents. You are reviewing the latest chat logs and labelling new user utterances. You label “I recently lost my phone and can’t log to website X since I used the phone for 2FA” as a brand new intent help.smartphone.2fa, since your team recently came up with a process describing how exactly a problem with 2-FA should be handled by the bot. You finish labelling the rest of the data, retrain the model and quickly do some manual testing; you start with “I have problem with 2-FA on my phone”, the bot replies with something that is triggered by a more general intent help.smartphone. Hmm… You decide that maybe there are too few examples for help.smartphone.2fa, so you create some more. You retrain the model, test it locally and now “I have problem with 2-FA on my phone” maps to help.smartphone.2fa, just as expected. Well done!
헬프 데스크 chatbot 예를 다시 사용해 봅시다. 약 300 intent의 당신의 NLU 모델에 대해 다소 큰 의도적 매핑을 갖는다고 상상해 보라. 당신은 최신 채팅 로그를 검토하고 새로운 사용자발언에 라벨을 붙이고 있다. 당신은 최근 2FA를 위해 전화기를 사용했기 때문에 웹사이트 X에 로그인할 수 없다"라고 라벨을 붙인다.스마트폰.2fa는 최근 당신의 팀이 2FA의 문제를 봇에 의해 정확히 어떻게 처리해야 하는지를 설명하는 과정을 고안했기 때문이다. 나머지 데이터의 라벨링을 마치고, 모델을 재교육하고, 몇 가지 수동 테스트를 신속하게 진행하면, "내 전화기에 2FA에 문제가 있다"로 시작하면, 봇은 보다 일반적인 의도의 도움말.스마트폰에 의해 촉발된 것으로 응답한다. 흠... 당신은 아마도 도움이 되기에는 너무 적은 예시들이 있을 것이라고 판단한다.스마트폰.2fa. 그래서 당신은 더 많은 예시들을 만들어낸다. 모델을 재교육하고 현지에서 테스트한 후 "내 전화기에 2FA에 문제가 있어" 지도에서 예상대로 도움이 된다. 잘 했다!
You push the updates to the prod server and during the build process, the model is re-trained once again. In a couple of hours you get a message from your colleague saying that the model on the prod server maps 2-FA-related utterance to help.smartphone, not the newly added help.smartphone.2fa. You try the same utterance on your local copy of the model trained on exactly the same training data and it maps to help.smartphone.2fa as expected.
prod 서버에 업데이트를 푸시하면 빌드 프로세스 중에 모델이 다시 한 번 교육된다. 몇 시간 후에, 당신은 당신의 동료로부터 2-FA 관련 말을 도와달라는 메시지를 받는다.스마트폰은 새로 추가된 help.smartphone.2fa가 아니다. 당신은 정확히 동일한 교육 데이터에 대해 훈련된 모델의 로컬 사본에 동일한 문구를 적용하고, 그것은 스마트폰에 도움이 되도록 매핑한다.예상대로 2파.
So what might cause an issue like this? One possible cause for the example above is that a few months back when you had far fewer intents which were all very general, you labelled some utterances related to 2-FA on smartphones as help.smartphone. Back then it made sense since, at the time, your bot had a single response to all smartphone related troubleshooting, e.g. “Call this number and out team will help you with your smartphone problem.” Adding a new intent help.smartphone.2fa created a condition when utterances that are very similar lexically and syntactically map to two different intents. This caused the bot to behave differently between training sessions given the same input.
그러면 무엇이 이런 문제를 일으킬 수 있을까? 위의 예를 들 수 있는 한 가지 가능한 원인은 몇 달 전 매우 일반적인 직관이 훨씬 적었을 때 스마트폰에서 2FA와 관련된 몇 가지 문구를 help.smartphone으로 표시했기 때문이다. 그 당시 당신의 봇이 스마트폰과 관련된 모든 문제 해결에 단일 응답(예: "이 번호로 전화하면 외진 팀이 당신의 스마트폰 문제를 해결할 수 있을 것이다)"을 했기 때문에 그것은 일리가 있었다. 새로운 의도의 헬프.스마트폰 추가.2fa는 어휘적으로 매우 유사하고 통사적으로 두 개의 다른 직관에 매핑되는 말을 할 때 하나의 조건을 만들었다. 이 때문에 봇은 동일한 입력으로 주어진 훈련 세션 간에 다르게 행동하게 되었다.
A NLU model is reliable and predictable only when trained on many-to-one or one-to-one mappings, not one-to-many or many-to-many. So before introducing a new intent, always search for keywords that are relevant to this intent in your training data; if you find any training data that can create interference, reassign those examples to a new, more precise intent (a good NLU admin UI helps immensely with this process).
NLU 모델은 일대일 또는 다대일 매핑에 대해 훈련된 경우에만 신뢰할 수 있고 예측 가능하다. 따라서 새로운 의도를 도입하기 전에 항상 교육 데이터에서 이 의도와 관련된 키워드를 검색하십시오. 간섭을 일으킬 수 있는 교육 데이터가 발견되면 해당 예를 보다 정확한 새 의도에 재할당하십시오(좋은 NLU 관리 UI는 이 프로세스에 막대한 도움이 됨).
Errors in dialogue data (relevant to Rasa Core only)
Another mistake that can make a chatbot behave differently between training session is to create Rasa Core stories that have identical starting conditions but end differently. Quick example:
대화 데이터의 오류(Rasa Core에만 관련됨)
훈련 기간 동안 챗봇이 다르게 행동하게 할 수 있는 또 다른 실수는 출발 조건이 같지만 끝나는 라사 코어 스토리를 만드는 것이다. 빠른 예:
| > general computer problem - utter_confirm_need_help_now * yes - action_create_ticket - utter_expect_specialist_soon> general computer problem - utter_confirm_need_help_now * yes - utter_bring_device_to_helpdesk |
This example seems especially naive given the two conflicting stories are right beside each other. But believe me, when you have a lot of stories spread around many files and receive conflicting feature requests, it’s quite easy to make this mistake. And then it’s very nontrivial to debug this if you are not used to this kind of bugs: there’s no default checks in Rasa Core for conflicting stories, the problem may be invisible locally and will manifest itself on some other machine (e.g. your dev server) and finally, as a programmer, you may start looking for bugs in the code’s logic, not training data.
이 예는 두 개의 상반되는 이야기가 바로 옆에 있는 것을 볼 때 특히 순진한 것 같다. 하지만 내 말을 믿으세요, 당신이 많은 파일들에 많은 이야기를 퍼뜨리고 상충되는 기능 요청을 받았을 때, 이런 실수를 저지르기는 꽤 쉽다. 그리고 만약 당신이 이런 종류의 버그에 익숙하지 않다면, 이것을 디버깅하는 것은 매우 비합리적이다: 라사 코어에는 상충되는 이야기에 대한 기본 점검이 없고, 그 문제는 국지적으로 보이지 않을 수 있고, 어떤 다른 기계(예: 당신의 개발 서버)에서 나타날 것이다. 그리고 마지막으로 프로그래머로서 당신은 코드의 논리에서 버그를 찾기 시작할 것이다.ng 데이터
To verify that the chatbot’s dialogue model works as expected before deploying it, it’s helpful to write some test stories. One good package that contains a tool for automated Rasa Core testing is Rasa Addons (test feature is currently experimental).
챗봇의 대화 모델이 배포하기 전에 예상대로 작동하는지 검증하려면 몇 가지 테스트 스토리를 작성하는 것이 도움이 된다. 자동화된 Rasa Core 테스트를 위한 도구를 포함하는 한 가지 좋은 패키지는 Rasa Addons이다(테스트 기능은 현재 실험적이다).
Training time
Sometimes developing chatbots with Rasa Core feels how I would imagine software development felt 30–40 years ago when developers mostly used compiled languages and their computers were much worse performance-wise compared to what we have today. You would write a small piece of code, try to compile it, fix all the compilation-time warnings and errors and finally start the compilation process. Now you would switch over to finishing an email that you started earlier. Or take a coffee break. Or go for a walk (good thing there was no YouTube back then)… Depending on the code base size the compilation could have taken a while.
교육시간
때때로 Rasa Core와 함께 챗봇을 개발하는 것은 개발자들이 주로 컴파일된 언어를 사용하고 그들의 컴퓨터가 오늘날 우리가 가지고 있는 것과 비교했을 때 훨씬 더 성능적으로 좋지 않았던 30~40년 전에 소프트웨어 개발의 느낌을 내가 어떻게 상상할 수 있을지를 느낀다. 작은 코드를 작성하고, 컴파일을 시도하고, 모든 컴파일 시간 경고와 오류를 수정하고, 마지막으로 컴파일 과정을 시작하게 될 것이다. 이제 이전에 시작한 이메일을 완료하는 것으로 전환하십시오. 아니면 커피라도 마시던가. 아니면 산책을 가든지(그때는 유투브가 없어서 다행이었다)... 코드 베이스 크기에 따라 컴파일하는 데 시간이 걸릴 수 있었다.
Similarly, when you implement a new feature in Rasa Core (e.g. a new dialogue branch), you have to re-train the LSTM that is used by Rasa Core for handling different conversation scenarios to test it. As the training dataset for your chatbot grows, so does its training time.
마찬가지로, Rasa Core(예: 새로운 대화 지점)에서 새로운 기능을 구현할 경우, 이를 테스트하기 위해 다양한 대화 시나리오를 처리하기 위해 Rasa Core에서 사용하는 LSTM를 다시 교육해야 한다. 챗봇에 대한 교육 데이터 세트가 증가함에 따라 교육 시간도 증가하게 된다.
Of course you can play around with the number of epochs in order to optimize the amount of time it takes to train your model. For instance, stop training as soon as the rate of change of the loss is below certain threshold. Still, this only takes you so far.
물론 당신은 당신의 모델을 훈련시키는 데 걸리는 시간을 최적화하기 위해 에폭스의 수를 가지고 놀 수 있다. 예를 들어, 손실 변화율이 특정 임계값 미만인 즉시 훈련을 중단한다. 그래도, 이 일은 여기까지 밖에 안걸려.
I recently crossed the 7 minute train time mark with one of the chatbots that I am working on and this wait can be frustrating sometimes (especially if I get distracted on something unrelated while waiting) or it can be a good opportunity to take a short break (unless I’ve been re-training the model for 3 times in a row for some reason).
나는 최근에 내가 작업하고 있는 채팅봇 중 하나로 7분 기차 시간표를 넘었고 이 기다림은 때때로 좌절할 수도 있고(특히 기다리는 동안 관련이 없는 것에 정신이 팔리면) 짧은 휴식을 취할 수 있는 좋은 기회가 될 수도 있다(어떤 이유로 3번 연속으로 모델을 재교육하는 경우는 제외).
While it’s possible to isolate a single component that you are working on in case of regular software development in compiled language, and avoid recompiling an entire project each time, it is not possible with a ML model; it is an indivisible component of a project.
컴파일된 언어로 정규적인 소프트웨어 개발 시 작업 중인 단일 구성요소를 분리하고, 매번 전체 프로젝트를 다시 컴파일하는 것은 피할 수 있지만, ML 모델로는 불가능하며, 프로젝트의 분할할 수 없는 구성요소다.
I think the GPU is the limiting component in my personal case, thus the way to mitigate this problem would to buy an extra GPU or to get used to the long training time and match it with breaks.
나는 GPU가 내 개인적인 경우에 있어서 제한적인 요소라고 생각한다. 따라서 이 문제를 완화시키는 방법은 GPU를 추가로 구입하거나 긴 훈련 시간에 익숙해져 휴식과 일치시키는 것이다.
If you found what you’ve read so far interesting, continue reading part 2 of the series. In part 2 I go into in-depth discussion of common architectural challenges in chatbot projects. Challenges from that category are the most difficult in my opinion, so there is plenty to talk about :)
지금까지 읽은 내용이 흥미롭다면 시리즈 2부를 계속 읽어보십시오. 2부에서는 챗봇 프로젝트에서 공통적인 건축적 도전에 대해 심도 있게 논의한다. 그 범주의 도전은 내 생각으로는 가장 어려우므로 할 말이 많다 :)
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에 나열된 거의 모든 것에 대해 쓰고 있다.
'beginner > ChatBot' 카테고리의 다른 글
| Stanford CS230: Deep Learning | Autumn 2018 | Lecture 10 - Chatbots 강의 내용 정리 (0) | 2019.06.10 |
|---|---|
| Chatbot Development Challenges — Part 2 (1) | 2019.05.31 |
| Python과 Tensorflow를 활용한 Al 챗봇 개발 4강 (1) | 2019.05.27 |
| Python과 Tensorflow를 활용한 Al 챗봇 개발 3강 (1) | 2019.05.27 |