6. 대부분의 문의가
한정된 주제 안에서 이루어짐
그에 대한 답변도 비슷하다
Classification 문제로
접근해보자!
6
7. Classification 문제
- CS 담당자들이 20+ 개의 Class를 제공
(전체 데이터의 70% 차지)
- 목표 : 주어진 Class에 속하는 질문들을 자동으로 분류/답변
하자
- 질문을 vector로 ‘잘’ 만들고
좋다는 모델에 넣은 뒤
output vector로 분류하면 되겠다! (거저먹기네 이거!)
7
10. Preprocessing
- 제대로 붙어있지 않은 라벨
- 엉망으로 되어있는 맞춤법, 이모티콘
- 질문 내용 외의 메타 정보
(CS 양식에 포함되어 있는 유저ID, 구글ID, 영수증 정보 등)
- … 등등 말하자면 이야기가 길어지는 엄청난 노가다전처리
를 했음
10
11. Vectorize
Question text -> vector embedding
Question text 의 embedding vector 를 어떻게 계산할 것인가?
이미지는 그 자체로 embedding vector 인데.. text 는?
기억의 섬이 안들어가져요 ㅠㅠ
게임 빨리 하고 싶습니다아아아
고쳐주세요오 젭알
0.121 1.871 -0.882 -5.129 3.072 …
Natural language Vector
embedding
11
12. Vectorize
한 토큰의 벡터 학습
기억 0.699 -0.034 0.192 …
섬 1.002 0.433 0.202 …
들어가다 0.001 -0.090 2.192 …
CBOW
Skip-gram
GloVe
Swivel
다양한 기법을 통해 각 토큰과 벡터를 매핑
13
14. Vectorize
2. BoW (Bag of Words)
각 단어가 등장한 횟수가 question의 embedding vector
BoW
BoW
기억, 섬, 안, 들어가다, 게임, 빨리,
하다, 싶다, 빨리, 고쳐주다
Tokenized
환불 기억 빨리 게임 재미 …
0 1 2 1 0 …
15
15. Vectorize
3. TF-IDF
각 문장에서 단어가 갖는 중요도가 question의 embedding vector
BoW
TF-IDF
기억, 섬, 안, 들어가다, 게임, 빨리,
하다, 싶다, 빨리, 고쳐주다
Tokenized
환불 기억 빨리 게임 재미 …
0 0.83 0.01 0.18 0 …
16
16. 모델에 넣어보자!
- Naive Bayes를 먼저 돌린 결과 : 정확도 59%
여기서 멈추고 다시 돌아봤어야 했다
- 딥러닝은 훨씬 잘해줄거야!
- 5개의 모델을 사용해봤으나 정확도 최대 65%
17
17. 데이터를 더 깎자!
- 품사 분석을 통해 주요 품사만 남겨둠
- 전화번호, 주문번호, 숫자 등 특수 토큰으로 대체
- 너무 짧은 데이터 제거
- … 등등을 했으나 68%
18
18. 왜 안 될까?
- 구현해둔 Naive bayes를 사용해서 디버깅
뉴럴넷은 디버깅이 힘들다
dominant words confusion matrix
19
19. 왜 안 될까?
- 데이터를 좀 더 자세히 분석(또 노가다)
- ‘결제했는데 크리스탈이 안 들어왔어요’
서버 문제? 결제를 안 했나?
구글/애플 문제? 크리스탈이 실제로는 잘 들어
갔나?
- 질문만 보고 답변을 하나로 특정 지을 수 없음
20
20. 그렇다면…
- 하나의 질문에 대해 3가지 답변 후보를 예측 하는 모델을 만
들자!
- 정확도 95%
- 함정 :
Top 3 class를 잘 맞춰봤자
결국 담당자의 손을 한 번 더 거쳐야하기 때문에 무의미
21
21. Lessons
- Baseline의 중요성
디버그 가능한 고전적인 ML 기법들을 사용
- 데이터를 항상 꼼꼼히 살펴보자
문제 정의, 데이터 가공, 모델링 등 모든 과정에서 인사이트를 준다
- 문제의 본질을 기억하자
Top 3을 맞추는 모델로는 봇을 만들 수 없다
- 영향도 : 하이퍼파라미터 < 모델 < 데이터 가공 < 문제 정의
하이퍼파라미터나 세세한 모델 튜닝은 보통 퍼포먼스를 크게 향상시키지 않음
22
32. Autoencoder
<GO> 크리스탈 안 들어오다
* word embedding with swivel
<GO>
+ h
크리스탈
+ h
안
+ h
들어오다
+ h
h
코인 안 되다 <END>
33
33. Autoencoder
우리의 데이터에 맞는 여러가지 variation
1. 과거의 데이터와 최근 데이터는 분포가 다르다
: 전체 데이터로 pre-train한 뒤 최근 n개/n주 데이터로 다시 학습
2. 여러 문장으로 된 긴 CS가 들어온다
: 각 문장별로 loss를 구해서 mean(또는 max)
3. 키워드들의 순서가 크게 중요할까?
: max-pooling, conv 등이 들어간 다양한 모델 시도
34
35. Autoencoder
인코더만 사용하기
- loss와는 다르게 스칼라가 아닌 벡터값이므로 훨씬 풍부한 데이터를 가지고 있을 것
이다
- clustering을 시도
: 역시 잘 워킹하지 않음
- 일반 CS와 장애 CS가 정확히 다르지 않다
: ‘패키지가 안 사져요’ 는 장애 CS일 수도 있고 아닐 수도 있다
- ‘장애 상황’을 직접 추가/제거하고,
그 상황에 해당하는 소수의 샘플을 통해 걸러낼 수 있는 모델이 필요
: 장애 발생시 CS 담당자들이 케이스를 추가하고, 모델에게 맡길 수 있도록
36
45. 유사도 계산 (Similarity Calculation)
1. Matching Network
미분가능 KNN
뉴럴넷을 통해 support set 과 target 의
임베딩(embedding)을 계산한 후
유사도를 계산하자!
Support Set
Target
Embeddings
46
46. 실험.. 실험.. 실험.. 실험..
실험 환경
Question Embedding : BoW, TF-IDF, End-to-End LSTM
Word Embedding : 랜덤으로부터 학습, 랜덤 고정, Swivel, …
Normalization..
Dropout..
Total vocabulary size
Network size
47
68. 한계점
단어 단위 embedding 의 한계
새로운 단어에 대처하지 못함
버려지는 키워드들..
떼탈출 보상이 안들어와요 ㅠㅠ 보상, 안, 들어오다
기억의 섬 보상이 안들어와요 ㅠㅠ 기억, 섬, 보상, 안, 들어오다
69
69. 한계점
실제 데이터 사용의 한계
1. 오타를 완벽하게 고치기 힘들다
2. 클래스 분류가 어렵고 버려지는 샘플이 많
다
3. 비슷한 내용인데 다른 클래스인 질문들이
존재
애가 저 몰래 결제
했는데 환불 좀 해
주세요.
아 그리고 기억의
섬 보상 안들어오
던데 언제 고쳐주
시나요???
환불 문
의
기억의
섬
장애 문
의
70
데브시스터즈의 김동화입니다. 저는 데브시스터즈에서 쿠키런 서버 개발을 맡고 있고, 이번 CS 자동화 프로젝트를 리드하고 있습니다. 이 세션의 앞부분은 제가 발표를 맡고, 뒷부분은 저희의 머신러닝 엔지니어인 김범준님이 맡아주시겠습니다.
저희 데브시스터즈는 2013년부터 지금까지 약 4년 반동안 쿠키런 시리즈를 서비스해오면서
약 45만개의 고객 문의와 그에 대한 답변 데이터를 쌓아 왔습니다.
이렇게 쌓여있는 보석같은 데이터를 어떻게 잘 활용할 수 있을까 고민을 해봤는데요,
특히 프로젝트를 시작할 당시 챗봇에 관한 아티클이나 자료가 많이 올라오고 있어서 이 데이터를 학습해서 문의에 자동으로 답변을 하는 봇을 만들면 좋겠다는 생각이 들었습니다.
그런 시스템을 만들기 위해 저희가 처음으로 선택한 접근 방식은 Text classification인데요,
데이터를 좀 살펴보니, 대부분의 문의가 한정된 주제 안에서 이루어지고, 그에 대한 답변도 비슷하다는 사실을 발견했습니다. 그래서, 이 문제를 하나의 classification 문제로써 접근해보기로 결정했습니다
원활한 진행을 위해서 CS 담당자분들께 대표적인 답변 케이스를 요청드렸고, 전체 데이터의 70%를 커버하는 20개 정도의 class를 제공받았습니다. 저희는 이 20개 클래스에 속하는 질문들을 자동으로 분류하고, 답변할 수 있는 모델을 만드는 것을 목표로 삼았는데요,
당시에는 세상을 너무 쉽게보고, 그냥 질문을 잘 벡터화 해서, rnn을 비롯한 다양한 모델에 넣어보고, 그 결과로 나온 벡터에 softmax를 취하면 분류가 되겠다! 라고 생각했었습니다.
실제로 방금 제가 말씀드린 과정이 보통 논문에서 다루는 부분이고, ML공부할 때도 주로 신경쓰는 부분인데요, 실제 데이터를 가지고 ML 문제를 해결하려면 보통 하나의 고통스러운 과정이 더 필요합니다.
바로 전처리라는 건데요
저희 데이터는 특히 전처리해야할 요소들이 상당히 많이 있었습니다.
애초에 45만개의 데이터에 라벨이 제대로 붙어있는게 거의 없었고,
유저들이 모바일 환경에서 많이 보내다보니 맞춤법 오류나 이모티콘도 많이 있었으며,
유저 ID나 구글ID 등 질문 외적으로도 답변에 영향을 미치는 메타 정보들이 있었습니다.
이 외에도 엄청나게 많은 것들을 지저분한 방식으로 처리해야했고, 사실 프로젝트에서 시간상으로는 가장 많이 투자한 부분이기도 합니다.
다음 과정은 텍스트를 문장으로 만드는 작업입니다. 흔히 classification 연구에서 다루는 이미지들은 그 자체를 벡터라고 볼 수도 있지만, 텍스트는 그렇지 않기 때문에 따로 벡터화하는 과정이 필요한데요,
이런 작업을 위해서는 먼저 한 토큰, 즉 한 단어의 벡터를 학습해야합니다. 흔히 알려진 많은 기법들이 있지만, 저희는 구글에서 연구한 swivel이라는 모델을 사용했고, 굉장히 만족스러운 결과를 얻었습니다.
그 뒤 문장을 벡터화시키는 데는 LSTM이나
각 단어의 갯수를 세는 Bag of Words,
단어의 중요도를 사용하는 TF-IDF 등의 모델을 이용해서 벡터화시킬 수 있었습니다.
이렇게 데이터를 정제하고, 벡터화 시켰으니 모델에 넣고 돌리는 일만 남았습니다.
실제 딥러닝을 적용시켜보기전에 Naive Bayes 기법을 이용해봤는데요, 59%의 정확도가 나왔습니다. 사실 오래된 기법이기는 해도 Naive Bayes는 굉장히 좋은 베이스라인이기 때문에 정확도가 이정도밖에 안 나왔을 때 다시 한번 문제 정의나 자료를 돌아봤었어야 했는데요,
그 당시에는 딥러닝에 너무 취해있어서 그런 생각을 하지 못하고, 이런 저런 모델을 막 구현하고 돌려봤습니다. 하지만, 아무리 좋다는 모델을 사용하고 튜닝을 해도 정확도는 최대 65%에서 그쳤습니다.
데이터 전처리가 부족했던건 아닐까 싶어서 좀 더 처리를 해봤습니다. 한국어 분석기를 이용해서 의미없는 품사들을 걸러내기도 했고, 자주 등장하는 특수한 패턴들을 토큰으로 대체하기도 해봤으며, 너무 짧은 데이터는 제거하기도 했습니다. 그러나, 여전히 정확도는 68%정도에서 그쳤습니다.
왜 이렇게 정확도가 안 나왔을까요? 뉴럴네트워크라는게 사실 디버깅하기가 굉장히 힘들기 때문에 베이스라인으로 구현해둔 NB를 이용해서 결과를 뜯어봤습니다. 한 클래스를 결정하는 주요 단어들을 뽑아보기도 하고, confusion matrix를 살펴보기도 했는데요,
뭔가 이상한 점이 있어 데이터를 좀 더 자세히 분석해본 결과, 문제를 발견할 수 있었습니다.
결제했는데 크리스탈이 안 들어왔어요 라는 뉘앙스의 CS가 있을 때,
정말 서버에 문제가 있을 수도 있고,
구글이나 애플에 문제가 있을 수도 있고,
유저가 결제를 안 했을수도 있고,
크리스탈이 실제로 잘 들어갔을 수도 있습니다.
즉, CS 데이터만 보고는 답변을 하나로 특정지을 수 없는 질문들이 존재하는 거죠.
그렇다면, 하나의 질문에 대해 3가지 답변 후보를 예측하는 모델을 만들어보면 어떨까요? 이렇게 구현하면, 정확도는 95%가 나옵니다. 아까에 비해 훨씬 높아졌고 뭔가 성공한 것 같아 보이는데요, 사실 여기에는 함정이 있습니다. 3개의 답변을 내서 잘 맞춰봤자, 결국 담당자의 손을 한 번 더 거쳐야하기 때문에, 결국 봇이 봇이 아니게 되는거죠.
나이브하게 텍스트 classification으로 접근하려는 시도는 실패로 끝났지만, 아무것도 얻지 못한 건 아니었습니다.
베이스라인을 잘 잡아두면 프로젝트가 잘 흘러가는지 가늠할 수 있고, 디버깅이 용이하다는 레슨, 데이터를 항상 꼼꼼히 살펴봐두면 프로젝트 전반에서 많은 인사이트를 얻을 수 있다는 레슨, 항상 문제의 본질을 기억하자는 레슨, 하이퍼파라미터나 모델의 디테일은 생각보다 중요하지 않다는 레슨 등을 얻을 수 있었습니다.
이런 레슨은 레슨이고, 분명히 이 데이터들을 가지고 해볼 수 있는 일이 있다고 생각해서 문제를 다시 정의해보기로 했습니다.
먼저, 좋은 문제란 무엇인가에 대해 생각해봤습니다. 좋은 문제는, 해결 가능하면서 CS 담당자의 일을 줄여줄 수 있어야겠죠. 그런 일이 어떤게 있을까 데이터도 많이 살펴보고, 담당자들과 이야기도 나눠본 결과,
특정 업데이트에 문제가 있으면 수백건에서 수천건의 문의가 쏟아져들어온다는 것을 알게되었습니다. 그리고, CS 담당자는 그 질문에 대해 정확히 똑같은 답변을 계속 보내고 있다는 사실도요.
그래서, 특정 장애로 인해 쏟아지는 CS를 자동으로 분류하고, 답변해서 담당자들이 기계적인 일보다는 정말 사람이 해야하는 일에 집중하게 도와주자는 목표를 세우게 되었습니다.
이걸 보시면서, 아까와 똑같은 supervised classification 문제가 아닌가 싶은 분들도 계실 텐데요, 사실 이 문제는 조금 다른 문제입니다.
왜냐하면, 데이터를 다 보고 학습을 하면 의미가 없기 때문이죠. 이 문제를 해결하기 위해서는 적은 데이터만 가지고도 장애 문의인지 아닌지 판단할 수 있는 모델이 필요합니다.
저희는 이 문제에 대해 크게 두 가지방법으로 접근해봤는데요,
먼저 anomaly detection부터 살펴보겠습니다.
anomaly detection은, 수많은 데이터 속에서 비정상적인 데이터를 찾는 것입니다.
이 문제에 적용시키면, 일반적인 CS들 사이에서 장애 관련 CS를 찾는 것이 되겠지요.
이런 anomaly detection 문제를 해결하기 위해 많은 기법들이 존재합니다. 그 중에 저희는 오토인코더를 이용해서 문제를 해결해볼 건데요, 오토인코더를 선택한 이유는 구현이 쉽기도 하고, 모든 데이터에 대한 라벨이 필요 없기 때문입니다.
오토인코더란 뭘까요? 이름 그대로, 어떤 인풋 벡터가 들어왔을 때, 그 벡터보다 낮은 차원으로 인코딩하는 뉴럴 네트워크를 말합니다. 그림에서 보시는 것처럼 보통 학습은 디코더까지 뒷 레이어에 둬서 output과 원본을 비교해서 로스를 계산하는 식으로 학습을 합니다.
저희의 가설은, 일반 CS데이터로 학습시킨 오토인코더에 장애 데이터가 들어오면, 평소에 보지 못한 패턴의 CS일 것이기 때문에 로스가 높을 것이라는 가설이었습니다.
다만 인풋이 평범한 벡터가 아니라 문장이었기 때문에,
이런식으로 LSTM을 이용한 인코더와 디코더를 만들고, 아웃풋과 인풋을 가지고 sequence loss를 계산하여 학습시켰습니다.
여기에 저희의 데이터에 맞게 이런저런 튜닝도 했습니다.
시간에 따라 게임이 변하기 때문에 들어오는 CS의 패턴도 변하게 되서,
전체 데이터로 먼저 학습시킨 뒤 최근 데이터로 다시 학습을 시켜보기도 했고요,
여러 문장으로 된 긴 CS가 들어오는 것도 빈번했기 때문에 각 문장별로 loss를 구해서 합치기도 했습니다
또, 키워드들의 순서가 크게 중요하지 않다고 여겨 단순한 RNN이 아니라 다양한 모델을 통해 인코딩을 시도해 봤습니다.
사진은 저희 오토 인코더의 결과인데요, 빨간 점은 정상 데이터를, 파란 점은 장애 데이터를 나타냅니다. 보시면 loss의 분포가 무의미하지는 않지만, 일부 정상 데이터도 높은 loss를 가지고 있어 프로덕션에 적용시키기에는 꽤 불안정하다고 판단했고, 다른 접근이 필요하다는 판단을 내렸습니다.
바로 인코더만 사용하는건데요, loss와는 다르게 인코딩만 하면 그 장애CS를 표현하는 벡터가 나올 것이기 때문에 훨씬 풍부한 데이터를 가지고 있을 것이라고 예상했습니다.
하지만, 이 벡터를 이용한 접근 방식도 잘 워킹하지 않았는데요, 저희는 그 이유를 일반 CS와 장애 CS가 정확히 다르지 않기 때문이라고 판단했습니다. ‘패키지가 안 사져요’라는 CS는 어떤 상황에서는 장애CS고, 어떤 상황에서는 장애CS가 아니기 때문이죠.
즉 저희는, 매 장애 상황마다 우리가 직접 클래스를 추가/제거하고, 그 상황에 해당하는 소수의 샘플만을 이용하여 문제를 해결할 수 있는 모델이 필요했습니다. 이런 모델이 있다면 CS담당자들이 장애를 인지했을 때 해당 케이스를 추가한 뒤, 우리의 자동화 모델에게 맡길 수 있기 때문이죠.
이런 일을 해주는 방법이 few-shot learning인데요, 이 이후로는 앞서 설명드린 범준님께서 발표를 이어가시겠습니다.
자기소개
오토인코더의 한계
Few-shot learning
Zero, few shot 의미
- zero-shot learning
몇개의 샘플만으로 (5~10)
효율적으로 이용해야한다
유사도 계산
A,B 클래스에 대한 명확한 이해 없이도 단순 비교를 통해 판별
TF-IDF + cosine similarity baseline
예제 설명
우리가 만든 모델이 얼마나 잘하는지 판단하기 위해선 적절한 metric설정이 필요
우리 모델의 목표는 크게 두가지
장애CS를 잘 분류하지만 일반CS를 잘 분류하지 못한다면 불순물이 많이 섞인다
둘다 일정 수준 이상으로 잘하는 모델을 원함
- 민감도 설명
- 특이도 설명
metric을 설정했으니 이제 baseline이 얼마나 잘하는지 알아보자
전체 CS에 대한 정확도 82%
하지만 민감도는 높고 특이도는 낮다
편향된 선택을 하는 모델
딥모델을 적용했을때 단순히 정확도 뿐만 아니라 덜 편향된 모델
첫번째로 시도한 모델은 Matching Network
개 종류 분류 문제
미분가능 KNN
Pixel difference가 큰 같은 종류의 개가 비슷한 임베딩을 가져서
저희처럼 text에 적용할때에는 다른 단어들로 이루어진 비슷한 질문이 비슷한 임베딩을 가져서
Embedding만 배우면 되기 때문에 Simple
Few-shot learning 모델중 거의 유일하게 text에 적용된 예시가 있었던 모델
수많은 실험을 통해 성능 확인
실험 과정에서 수많은 그래프들을 보게되고..
그래프 지옥
모델이 제대로 동작하는지 확인하기 위해 수많은 디버깅
Tensor board text summary를 이용한 visualize
최고 결과는 Swivel과 BoW를 사용했을 때 Sensitivity 93%, Specificity 89%
전체적인 정확도도 올랐지만 특히 편향성이 많이 사라졌다
Swivel이 항상 좋은 성능을 냄
end-to-end로 word embedding이 학습되는것보다 미리 계산해놓는게 더 좋은 결과를 얻었다
Swivel의 경우 전체 데이터셋을 보고 학습하지만 end-to-end의 경우 데이터의 일부분(batch)씩 보며 업데이트되기 때문에 의미 학습이 더 어려운것 같다
실제 적용해볼만한 결과가 나왔지만 few-shot learning model이 text에도 reasonable한 결과를 얻는다는것을 알았기 때문에 SOTA급 model의 성능을 알고 싶었다
2017년 7월에 나온 논문 TCML
모델 간단 설명
Black box이기 때문에 어떤 비교연산을 배웠는지는 알기 어렵다
더 좋은 방법을 배웠다면 matching network보다 잘나올테고 아니면 반대
실제로 5-way, 5-shot Mini-ImageNet에서 테스트 시 MatchingNetwork보다 좋은 성능을 내게 된다
5-way란 5개의 클래스가 주어지고 어떤 클래스인지 맞추는 문제
- TCML도 매칭 네트워크와 마찬가지로 많은 실험과..
- 디버깅을 거쳐..
얻게된 가장 좋은 결과는 역시나 Swivel과 BoW를 썼을때
민감도는 비슷한 값을 가졌지만 특이도가 조금 더 올랐다
- TCML 코드 오픈소스
더욱 성능을 끌어올리기 위해 ensemble model 적용
실험 과정에서 얻게 되는 수많은 모델들
투표를 통해 결정 -> 모델들이 가지고 있는 편향성을 더 줄일 수 있다
64개의 모델을 사용하여 얻게 된 결과
baseline과 비교해보자면..
Ensemble model을 실제 적용은 안하고 있다 -> 무겁고 느리다
실제 적용을 하지 않는다면 모델은 무쓸모
무엇을 할 수 있을까요?
크게 3가지 아이디어
첫번째는 얻은 모델로 실제로 장애CS를 분류해주는 방법
실제 장애CS의 93%가 분류되고 비장애 CS의 9%가 불순물로 섞이게 된다
이렇게 분류기로 전체CS를 불순물이 어느정도 섞여있는 더 작은 subset으로 한번 걸러내준다
장애CS의 경우에는 유저 정보에 따른 편집이 따로 필요가 없기때문에 손쉽게 몇개의 일반CS만 체크해제하고 빠르게 처리가능
원래 전체CS에서 하나하나 클릭해서 복사붙여넣기 해야했던걸 생각하면 훨씬 빠르게 처리
CS팀의 반복적이고 소모적인 일을 덜어주고 사람만이 할 수 있는 일에 집중할 수 있도록
두번째는 장애CS에 대해 실제로 자동 답변하는 방법
신뢰도가 가장 중요하기 때문에 장애CS와 일반CS 샘플과의 유사도 차이값을 threshold를 취해 분류한다
원래대로라면 threshold = 0
threshold를 높게 잡으면 신뢰도가 높아지고, 반대로 전체 장애CS의 coverage는 낮아진다
현재 신뢰도 95%일때 약 68%의 장애CS를 커버할 수 있다
적은양은 아니지만 신뢰도를 아무리 높게 잡아도 항상 잘못보내는 답변이 존재
실제 적용은 안함
마지막은 처음 만들었던 top-3 classifier를 사용
실적용이 어렵다고 생각했지만 예상답변 제공에 사용 가능
예시 설명
유저가 만족한다면 CS팀에게 전달되지 않고 자동 해결
총 프로세스를 그려보자면..
이렇게 해서 총 3개의 적용방안중 리스크를 가지고 있는 자동답변을 제외한 두가지 모델이 개발중
빠르면 11월초에 실제 적용될 것 같다
이렇게 해서 문제 정의에서 시작해서 시행착오를 겪고 모델 퍼포먼스를 높혀서 실제 적용에 이르기까지의 스토리를 공유드렸다
하지만 저희 모델이 가지고 있는 한계 또한 분명하다
간단하게 짚고 넘어가보자
첫번째는 모든 text를 단어단위 embedding으로 다뤘다는 점
가장 큰 문제는 새로운 단어에 대처하지 못한다
두개의 비슷한 질문을 구별하는건 떼탈출, 기억의 섬이라는 키워드
떼탈출이란 키워드가 vocab에 없기때문에 unknown 토큰 처리되게 된다
큰 업데이트 시 새로운 키워드가 나타나게 되면 누락되기 때문에 주기적으로 학습해야한다
어느정도 커버 가능하지만 여전히 처음 등장하게 되는 단어를 놓치게 된다는 한계
두번째는 실제 데이터를 사용하기때문에 생기는 한계
오타가 너무 많은데 토큰화, 맞춤법검사기 등을 사용해도 완벽하게 고치기 어렵다
클래스 분류가 애매해서 버려지게 되는 샘플들이 많다
비슷한 내용의 질문인데 서로 다른 클래스인 질문들이 존재한다
클래스 분류가 어려워 버려지는 샘플의 예 설명
이러한 한계점을 가진채로 실적용한 후에 계속해서 두가지 방향으로 개선해나갈 예정
새로운 아이디어나 파라미터를 실험하여 앞서 언급한 한계점을 극복하거나 metric 값을 향상시키는 성능 개선
유저, 즉 CS팀분들과 문의를 넣은 고객들과 인터랙션 해가며 받은 피드백을 통한 기능개선
네 저희 발표는 여기까지이구요, 이상으로 데브시스터즈팀의 CS자동화 발표를 마치겠습니다. 감사합니다.