[Day 10 - 5/7] Special Mission & 오피스아워

[karim-moon]

전날 한 것

• 문종 - Gate + CHAN-DST 논문

• 유진 - 스페셜미션 + DS-Picklist 논문 보다가 코드 없어서 CHAN-DST 보는중

  EDA 결과에서 [관광-지역], [식당-지역] 문장에서 서울 중앙 이런식으로 나오는데 update를 안해서 dontcare로 나옴

  → 유저 발화에 weight를 좀 더 주면 성능이 높아지지 않을까?

• 재우 - 스페셜미션, 임베딩을 BERT 모델로 바꾸기

  git 너무 좋네용

• 창우 - 스페셜미션

• 희석 - git-slack 연결

---

Special Mission + baseline 질문

Q. encoder를 GRU → BERT 바꾸는 부분

huggingface bert

정답 코드에서는 간단하게 구현함

→ token_type_ids를 바꿔 줄 수도 있을 거 같다

→ history: 0, current: 1 이런 식으로 턴이 끝났다는 걸 알려주면 좋지 않을까?

→ Q. [0, 1] 밖에 값이 못들어가는데 어떻게 넣어줘야할까?

KLUE 오피스아워에서 0, 1, 2, 3 ... 이런식으로 해줘도 된다고 했던거같다

→ Q. [CLS] 토큰만 pooling을 해서 decoder에 가져다주는건가?

pooled output이 [CLS] 토큰과 관련된거라 전체 context를 포함하고있다고 가정해서 인코딩 하는 것 같다

Q. word dropout 아시는분 계신가요?

[PAD] 토큰 부분 마스크 씌워줌

→ [PAD] 토큰 부분은 어텐션 안되고 단어가 있는 부분에만 집중할 수 있게

[PAD] 토큰이 어텐션을 거치면 0으로 되고, 그 0을 -1e9로 치환

어텐션 마스크와 같은 기능을 하는 것 같다

Q. [something.ne](http://a.ne) 가 뭘까요?

발화 안에 있는 값이랑 같지 않으면 True 반환

→ input_ids에서 [PAD] 토큰 부분만 0으로 만들고 나머지는 다 1로 만들어서 [PAD] 토큰은 어텐션이 안되게 하는 용도

Q. forward - attn_e에서 something.masked_fill 이 뭘까요?

masked_fill(condition, value)

condition이 true인 곳들의 값을 value로 치환해줌

Q. K-fold 적용 관련

• 시간이 너무 오래 걸릴거같다
• 폴드 나눠서 1epoch 만 돌려보고 가장 좋은 validation set 찾기
• 적절한 hyper parameter 찾아서 전체 train set으로 학습
• 여러 모델을 앙상블 하는 방법도 있지만 모델간 성능차이가 많이 난다면 제일 좋은 모델 학습방법(ex. hyperparameter, seed) 바꿔가면서 앙상블 하는게 더 좋을수도 있음

Q. dev 데이터 비율 관련

default: 0.1

현재 방식은 train → train / dev로 나눔, eval: leaderboard 데이터셋 (label 없음)

• eval data를 labeling 후 학습을 시켜서 evaluation(결과 inference)하는건? (pseudo labeling)
• dev 데이터셋 나눠서 학습시키면서 hyper parameter 찾고 전체 train 데이터로 학습시키는건 어떨까
• 우선은 dev 데이터셋을 쓰는 방향으로 학습시키고, 학습 돌리는 도중 진짜 아니다 싶은 것들만 학습 중지, 웬만하면 다 돌리고 제출까지 하는 방향으로 하자

CHAN-DST 논문

이전 DST 모델들은 slot의 불균형한 분포를 따지지 않고 동일하게 두고 학습을하여 퍼포먼스 저하가 있었다

자기들은 이거를 고려했다?

Q. dev셋을 나눌 때 EDA 했을때 한번만 나오는 state에 대해서는 어떻게 해야할까?

한 dialogue에서 slot-value 페어가 여러번 나올텐데 dialogue별로 세야할지 turn별로 세야할지

Q. Loss 구할 때 $L_1, L_2$ 비율 관련

논문에는 $L = \alpha * L_1 + \beta * L_2$ 인데 baseline 코드에서는 1:1 비율로 최종 Loss를 구한다

→ 나중에 비율 바꿔볼까요?

Q. data_utils.py - load_dataset 저 부분에서 왜 3으로 나눠주는지

train / dev 데이터 간의 dialogue에서의 domain 개수를 맞춰주기 위해서인거같다

dom_mapper의 key들을 출력해보면 1, 2, 3이 나온다 (현재 가지고있는 dialogue 들은 1~3개의 domain을 갖고있다)

domain의 개수가 1개, 2개, 3개인 dialogue들의 비율을 train / dev 데이터에 동일하게 나눠주기 위함 인 것 같다.

---

문종님 Gate 관련

구현해보려했지만 생각대로 잘안되는 부분이 있다

원래 생각대로라면 저 밑줄 부분에서 none/not_none을 걸러내고 아랫줄에는 not_none인 것들만 들어가야 함

현재 코드에서는 밑줄 부분에서 none/not_none을 걸러내기는 하지만 아랫줄에 not_none만 들어가지 않고 none인 것들도 들어갈 수밖에 없다

→ none/not_none을 걸러내고 넣어주면 벡터 모양이 바뀌기 때문에 gate 2개로는 해결하기 힘들어서 3개로 구현

지금은 gate 3개로 구현해서 돌리고있지만 나중에는 gate 2개도 가능할 것 같다

• forward

  Linear 레이어 3개로 늘려줬다

• Loss

👀 오피스 아워

TRADE Baseline

Encoder

→ 각 토큰이 각 벡터로 바뀜.

→ 하나의 zero vector가 들어감. embedding과 hiddenstate를 통해 output(위)가 나옴.
→ 3개가 들어갔는데 왜 6개? → bidirectional이라서

→ 앞의 3개는 앞에서부터 진행되는 gru의 hidden output, 뒤의 3개는 뒤에서부터 진행되는 gru의 hidden output

→ 앞에서부터 진행한 hidden state와 뒤에서부터 진행한걸 합쳐서 output이 되는 것.

State Generator

• P_history

→ 전체에 대해 h~~를 내적한 후 softmax를 취해주면 확률이 나오고 이가 P_history.

→ 싶이 나올 확률이 가장 높은것을 확인할 수 있다. 

• P_vocab

→ 모든 후보값에 대한 확률이 나옴. 

• P_gen(softgated copy mechanism)

→ P_history가 10개밖에 안돼서 더해지는게 애매하다. 그래서 scatter_add를 사용. (35000의 space로 확장) → P_final에서 가장 높은 확률을 가지는 토큰이 3018인 "싶"이다.
→ P_history를 하나만 씀 : index based copying mechanism

→ 두개를 사용하는데 그 중 하나만 쓸거다 : hard copying mechanism
→ 두 확률분포가 섞이는것을 구해서 최종을 구하겠다 : softgated copying mechanism

Slot Gate

3번째인 ptr이 제일 높다.

• Teacher Forcing

조금 더 빠른 학습을 위한 방법

→ "싶"이 나오면 이상해서 줄여주기 위해 기존 정답을 다음 input으로 넣어주는 방식. 
→ 확률적으로 일부에 적용하는게 우리 baseline

→ 연산이 넘 많다!

연산량 해결방법

• bag of projection → base line의 Linear layer (768 to 768) → 연산량이 너무 많다 → 낮은차원으로 projection

• Parallel Decoding

slot의 개수만큼 다 복사해야함 → 메모리 펑펑

추가로 해볼 것

• Joint Goal Accuracy, Slot F1을 중점적으로 보기
• Open-vocab approach에서 다양한 아이디어를 적용
• 더불어 동시에 맞추지 못하는 케이스 턴이 길어지면서 틀리는 slot들을 세세하게 살펴보기

WOS 데이터 문제

sys 가 추천한 곳이 '서울 중앙' 이고, 이를 user 가 받아들였는데도 원래 state 인 'dontcare' 로 유지 되는게 옳은가요?

• 어노테이션 가이드를 빡빡하게 만들어도 놓치는 부분이 있을건데, 이게 그런 케이스일 것 같음 → 어노테이션 에러
• 하지만 이런 에러가 있다 하더라도 이제까지 모델들은 그냥 사용해서 성능 올렸으니 그냥 사용하자

사실 이게 데이터 그 멀티오즈 데이터셋을 보시면 아시겠지만 사람 둘이서 만드는 데이터셋이다보니까 어노테이션 가이드를 아무리 빡빡하게 드려도 대화에 대해서 완벽한 가이드를 제시할 수 없었고 사실 저희도 업데이트가 이뤄져야하는지 결정하는게 쉽지 않았어요.

어노테이션 에러로 보셔도 될거같은데 두가지 케이스가 있어요.
시스템이 제안을 하고 유저가 컨펌하면 업데이트 하는거는 모호한 지점
그간에 DST 모델들을 불안정한 상황에서도 충분히 성능 끌어올림
그래서 그냥 감안해도될거같다

정제해서 써서 올라가는지 봐도 되긴하는데 너무 노가다
하지만 이거는 어 예 데이터는 항상 이제 특히 대화 데이터는 어노테이션에 대한 에러가 많은수도 있다
아 진짜 이거는 어노테이션 틀려서 틀린건데 억울하다
기준이다보니까 마스터님도 억울한점이 많았다
저희 데이터셋에서도 이렇게 논란이 있을수도 있는 케이스들이 종종 있을거에요
이런 케이스가 예 돈케어가 많이 나온다