Peer_Session_Week_3

Day12🌧

2021.05.10 (월)

대회 토크

❤️Retriever

• 논의 사항 없음

💙Reader

• 수지 : KoElectra 돌리는 Code 완성함! 자잘하고 사소한 문제가 있는데, 해결할 수 있을 듯.
• 수지 : 정답으로 Unknown Token이 출력되는 경우가 있음.
  • 태양 & 현규 : Vocab에 추가해야 한다.
  • 종헌 & 재희 : Vocab에 새로운 Token을 추가하는 것이 좋을지 모르겠다

💚 Baseline

• inference.sh에 --do_predict 추가해야 함.
• sh를 실행 시킬 때, 주석처리 하지 않거나, 할거면 맨 뒤로 빼기.
• sh 실행 시 seed 설정하기.

---

Day13😴

2021.05.11 (화)

대회 토크

❤️Retriever

• 논의 사항 없음

💙Reader

• 익효 : k를 엄청 늘렸다. 20개로 늘렸더니 바로 올랐다. k가 많아질수록 선택하기 힘들어 지는 것이 맞을 텐데 왜 더 성능이 오르는 걸까?? test dataset에서 train dataset에 포함된 데이터들이 점점 많이 포함되어 지는 것이 아닐까? 그래서 이 방법이 맞는 방법인지 고민이다. k가 9개일 경우와 20개일 경우를 비교해보았는데 retrieval에서 오른 약 2% 정도 올랐는데 reader에서 오른 성능도 약 2% 정도라서 trade off 없이 동일한 성능 향상을 가지는 것이 좀 의문이다.
  • 한 줄 요약: 61.25 성능이 나왔던 모델에서 k를 늘렸을 뿐
• 익효 : wiki 자르는 거 ⇒ validation set 기준 성능 향상 (EM 기준 2%, F1 스코어 기준 3%) ⇒ 근데 테스트 데이터에 한해선 떨어짐 (56 정도...)
  • 왜인지 모르겠음
  • KSS(korean sentence splitter) 사용해서 문장을 자름
  • context를 문장단위로 나누고 전체 context의 절반 길이에 가깝도록 문장들을 part 1, 2로 나누는 방법
  • 여기서 GT answer은 raw context의 answer index와 가장 가까운 answer로
  • overlap은 활용하지 않음
• 익효 : Conv Layer Model 구현(Concat Version)

---

Day14😀

2021.04.28 (수)

대회 토크

❤️Retriever

• 논의 사항 없음

💙Reader

• 익효 : 쏘타 논문 해보려고 했는데 허깅페이스에 있어서 가져오려고 불렀는데 안불러와져서 버전을 업데이트해야되나 했는데 이미 최신버전이고 혹시 XLN이 roberta 모델인가요?? https://arxiv.org/pdf/2010.01057v1.pdf
  • 태양 : 저희가 사용하는 tokenizer는 word piece tokenizer인데 XLN은 sentence piece tokenizer라고는 나와있네요.
  • 현규 : 사실 지금 사용하는 XLM Roberta도 어떻게 동작하는지 잘 모르겠더라고요...
• 수지 : HanBERT 사용 예정
• 익효 : convolution 사용한 모델은 성능이 조금 떨어졌어요...
• 현규 : max sequence length를 512로 늘려서 실험해봄. batch를 8로 줄여야 했고, 어떤 이유인지는 알 수 없으나, 결론적으로 성능이 떨어짐.
• 태양 : validation set에 조사버리기를 적용했더니 다른 분들보다 비교적 score가 높게 나온다.
• 태양 : korquad 학습할때는 learning rate를 크게 해서 빠르게 학습해주고, 대회 dataset을 사용할 때는 작은 learning rate를 사용하여 학습해주면 좋을 것 같다.

멘토링(with 조용래 멘토님)

1️⃣ 최고 성능 모델 공유 및 개선점 도출

현재 팀이쿄 최고 성능 모델(1등😎)의 구현 디테일은 아래와 같습니다. *혹, 멘토님의 시선에서 조언해주실 만한 개선점이 있다면 조언 부탁드립니다*‼️ (최대한 자세히 작성한다고 써봤는데.. 아무래도 더 자세한 디테일은 만나뵙고 설명드려야 할 듯합니다..)

1) Retrieval Model

• Train : 정답(GT) context + Elastic search 상위 Top4 concat
• Inference : Elastic search 상위 Top20 concat
• Elastic search settings
  • Nori tokenizer(similarity measure: BM25) + 불용어 사전(조사 + 어미))
    • 불용어 사전 만들 때 한국어 조사 어미를 검색해서 만들었는데, 이래도 괜찮은지 아니면 위키 데이터셋을 고려해서 만들어야 하는지
    • 일반적인 불용어 사전을 만들어 넣어도 충분할 것 (위키가 특별한 언어로 구성된 글은 아니니까)
  • Elastic search 최적화 시도
    • BM25 : 어떤 것을 보고(기준) 어떤 것을 수정해야 하는지 모르겠습니다 BM25를 활용해서, 추가적인 성능 향상을 위해 어떤 형태의 실험이 가능할까요?
    • Elastic search를 더 잘 쓰기 위한 방법은 또 어떤 것이 있을까요?

🍯 멘토님 🍯

• Elastic Search는 기본값이 굉장히 좋은 상태이고, 직관적으로 더 좋아지는 방법은 없어서 다양한 방법을 시도해보는 것이 좋을 것 같다.
• BM25의 옵션을 바꾼다고 하더라도 드라마틱한 향상이 있지는 않을 것이다.
• 불용어 사전을 추가한 것은 매우 좋은 시도였다고 생각한다. 일반적인 불용어 사전을 추가한 사항도 충분히 좋은 것 같다.

2) MRC Model

• *KorQuAD pretrain* 후 KLUE data train* ( 두 훈련 모두 같은 모델을 활용했으며 모델의 디테일은 아래와 같습니다)
  • backbone network : xlm_roberta_large + conv1d + dense layer
  • *conv1d + dense layer* *conv1d(kernel size : 3, padding 1, output_dim : 256) + dense layer(256, 2)* ⇒ 현재 *multi_conv1d_layer + output concat* 하여 성능 검토 진행 중입니다. ⇒ *vanilla convolution layer* 외에 *residual, efficientnet, depthwise separable convolution* 등 Vision에서 핫한 개념을 활용해 볼 수도 있을까요? 관련 사례가 있는지도 궁금합니다.

🍯 멘토님 🍯

• Conv1D은 어쩌다가 쓸 생각을 했는가? Fine Tuning 방법 중 다양한 방법이 있는데, Conv는 오르기 어려울 것이라고 생각했다. (물론 상황마다 다르지만) FC Layer를 사용했었는데, Drop out을 쎄게 걸었을 때 잘 됐던 경험이 있다.

  • 레이어를 쌓는 것도 방법일 수는 있으나, 데이터가 작은 만큼 오버피팅을 조심해야한다.드랍아웃을 세게 거는 것이 좋을 수 있음. (0.5, 0.7 정도의 수치) 오버피팅을 막는 방향에 매우 관심을 가지는 것이 좋을 것 같다. (Weigth Decay, Batch Size 키우기 등)

• Post processing

  • *조사* 버리기(정답 마지막에 Macab 기준의 *조사* 포함 시 제거) + *후처리*
  • 후처리 디테일 (잘 처리되지 않는 조사 재처리)
    1. answer 마지막 글자가 "의"인지 확인 후 조사일 경우 제거
    2. answer의 마지막 token이 "에서", "는", "은", "에" 등 조사일 경우 제거

🍯 멘토님 🍯

• fine-tuning layer의 구성 실험을 해본 적이 있는데, 모델의 깊이 대신 너비를 키우고 드랍아웃을 세게(0.5보다 크게) 거는 것이 도움이 되는 경우가 있었습니다.

2️⃣ Modeling 관련(feat.리더보드)

1) K를 늘릴 수록 LB 성능이 올라가는 문제

Retrieval model의 top K를 늘리면 늘릴 수록 좋은데...(inference 과정에서 Top K를 9→20으로 늘리니 EM 기준 2% 상승) 혹, train과 public leader board 데이터 셋에 겹치는 context가 있는 것이 아닌지 의심됩니다. 이렇게 되면 처음 보는 context에서의 성능이 걱정되는데, private test data를 확인할 수 없으니 현재의 최고 성능을 신뢰해도 될지 모르겠습니다. 멘토님 생각은 어떠신지요?

위 질문과 관련하여 다음의 가설과 각각의 논리가 맞는지 궁금합니다. 검토 부탁드립니다!

• 가설 : Passage를 많이 볼 수록 정답을 찾을 확률이 오를 것이라고 생각한다.

  (정답과 무관한 Passage(Noise)에 의한 성능 감소보다, 많은 passage를 읽고 정답을 찾을 때의 성능 증가의 폭이 훨씬 클 것이라고 생각한다.)

  1. 어차피 상관 없는 Passage나 문장에 대해서는 어차피 output Logit 값이 낮게 나올 것이다.
  2. Noise에 해당하는 정보들은 자체적으로 거를 수 있을 것이라 생각한다.
  3. 많은 Passage를 다 검토하면, 정답이 있는 정답 Passage를 찾을 확률이 높을 것이다. (Top k를 본다고 할 때 k를 늘린다면 그 안에 정답 passage가 들어갈 확률이 높으니까)
  4. 즉, 많은 Passage에 대해 Reading을 하면, 결국 answer을 찾을 확률이 높아질 것이다.

🍯 멘토님 🍯

• Train과 Public의 Data가 겹치지는 않는 것으로 알고 있다. Top K가 높아졌을 때 Retrival의 Error가 적어져서라고 생각함.
  • 익효 : Retirval Error가 줄어드는 만큼, Reading Error도 동시에 줄어들어서, 걱정이 된다. (Public쪽에 Train의 Data가 Licking 됐을까봐 걱정이다.)
    • 겹친다고 판단 되는 것는 Data를 Train에서 제외하고 학습 시키면, 위와 같은 문제를 검토해볼 수 있을 것 같다. 그리고, 최종으로 학습 및 제출 할 때에는, 이 데이터와 Val Data등을 추가해서 한꺼번에 학습시키는 것이 좋을 것 같다.
• (가설에 대해서는)네 제 생각에도 이 가설이 맞는 것 같아요. 다만 최적의 k를 찾아야 할 것.
  • 현규 : Top K를 무조건 올리면 좋은게 맞을까?
    • Retrieval이 Reader에게 부담을 전가하는 것이다. Reader가 소화할 수 없는 수준의 K를 전달하면, 성능이 떨어질 것이다. 그러니, 적정선을 찾는게 중요할 듯 하다.
    • Reader의 성능을 확인해보고 싶으면, 출력해서 보는 것도 좋을 것 같다.

2) Wiki Data를 Passage로 나누어서 Elastic Search

wiki context를 passage단위로 나누어 Elastic search data 구성하여 적용했을 때 validation score는 더 좋았는데(EM 기준 2%, F1 스코어 기준 3%), public leader board에서는 너무 떨어졌습니다(EM기준 50%대, 최고 성능 대비 13% 하락).. 버리긴 아까운데.. 어떤 방식으로 개선하면 좋을까요? 아래는 wiki context를 passage단위로 자른 방법에 대한 디테일(참고용)과 저희가 생각해본 해당 접근의 개선 방법입니다. 추가로 의견이 있으시다면 조언 부탁드립니다.

retriever 성능이 1% 떨어지고(top1 기준), reader 성능은 validation set 기준으로 많이 오름 ⇒ validation set ≠ public 리더보드 dataset 문제 ⇒ passage로 나누고 나서 train(top5) & inference(top12) 단계에서 top-k 어떻게 했는지? ⇒ 기존과 똑같이 줌 (짧은 단위로 봤을 때 reader에서 더 좋은 성능을 보이지 않을까 하는 생각으로 자른 거라) ⇒ 확신은 안 가지만 실험은 해보길.. ⇒ 최대 2개로 나눔 (별로 안 나눴네요...) ⇒ 지금까진 계속 promising한 결과를 보였으니 계속 탐구해보는 걸 추천 (top k를 바꿔보는 것 등...) ⇒ 수지님 힘들면 그만 써요! 나중에 영상으로 보고 todo에 정리하면 될것 같음!(그리고 현규님이 써주고있음)ㅎ

• wiki context를 passage단위로 나누어 Elastic search data 구성

  

  ※ 적용 근거 및 배경 : 위 figure는 Top N개의 context를 뽑은 후 paragraph level에서 query와의 유사도를 고려하여 선별적으로 MRC를 수행하는데, 이를 우리 모델에 더 쉽게 적용하기 위해서 Wiki data 자체를 각 paragraph(passage)로 나눠서 Elastic Search에 적재하여 활용하기로 함

  1. passage를 자르는 기준은 [Korean Sentence splitter(KSS)](https://github.com/likejazz/korean-sentence-splitter) 사용, overlap은 활용하지 않음
  2. context length가 1,000이 넘는 context에 대해 문장 단위로 나누고 전체 길이의 절반에 가깝도록 문장들을 part 1, 2로 나눔
  3. 여기서 train 및 validation의 GT answer index가 약간 변형됨 (KSS의 특성에 의해 문장 사이 공백이 사라지거나 생김) ⇒ raw context의 index와 위치상 가장 가까운 answer을 GT로 처리 ⇒ 여기서 GT index가 오염될 가능성이 있어서 더 좋은 방법이 있으면 바꿔주고 싶음 ⇒ 혹, offset mapping 등을 활용할 수 있을지 고려 중

• passage 단위 접근 개선 방안

  1. (epoch을 줄여서 실험했는데) 이전 최고 기록과 똑같이 맞춰서 비교해야 할 것 같다
  2. context를 passage 단위로 나누고, retrieval 결과를 Top K 기준으로 concat하게 되면 raw context의 문장 순서가 달라질 수 있는데, 이 부분도 고려하면 좋을 것 같다. raw context를 활용하되 inference시에만 자른 passage를 활용하여 MRC model에 태우는 것은 어떨지?
  3. 현재 retrieval에서 뽑아오는 context 혹은 passage 들을 concat하여 사용함으로써 Elastic search에서의 similarity를 전혀 활용하고 있지 않은데, 이를 활용하면 더 좋은 모델이 될 수 있지 않을까?
  4. 현재처럼 concat하여 활용하는 것이 아니라, 따로 MRC하되, 위 figure의 Answer aggregation을 적용해보면 어떨지? 아래 해당 문헌 *2.2 Answer Aggregation 부분* Ranking Paragraphs for Improving Answer Recall in Open-Domain Question Answering.pdf

🍯 멘토님 🍯

• Retrieval 성능 or Reader의 성능 중 어디에서 하락이 있었는지 확인해보았는가?
  • 익효 : Retireval의 성능은 Top1 기준 1% 떨어지고(Top12 기준은 거의 동일), Reader의 성능은 Val 기준 3%올랐었다. Public LB에서는 결국 3~4% 떨어졌다.
    • 이러한 현상은 Val Dataset과, Public Dataset의 구성이 다르다는 의미이다.
  • 재희 : 학습 할 때 K를 더 높여서 학습해보는게 의미가 있을까?
    • 쉽게 답변하기는 어렵다.
• 중간 쪽에 정답이 있는 경우는 어떻게 하였는가?
  • 익효 : 문장 단위로 자르기 때문에, 정답이 잘리는 일은 없을 것 같다.
• 재희 : Concat보다는 Aggregation을 하던데, 이 방법이 더 맞을까요?
  • 일반적으로는 Aggregation을 하는 방법을 많이 사용한다. 이 경우 Score를 조합하는 경우도 있고, Reader만 사용하는 경우도 있다.
• 익효 : Score를 조합하는 경우에 성능이 떨어지는 경험이 있었다. 통상 어떻게 Score를 조합하는가?
  • 보통은 가중치를 넣고, 하이퍼 파라미터로 해서 최적의 값을 찾아나가는 것 같다. 통상 Reader쪽에 조금 더 힘을 주는 경우가 많은 것으로 알고 있다.
• 태양 : 지금 우리가 하는 Concat의 방식은 여러 Passage를 묶어서 하나의 Context처럼 생각하고 한번의 Reading을 수행하는 것이다. 그래서 그런지 정답이 아닌 Token에서도 Logit이 높게 나온다.
  • Softmax를 하는 경우, 오답이어도 Logit이 높게 나오는 경우가 많다. 지수적으로 값을 출력하기 때문에, 맥시멈 값이 다른 값에 비해 매우 높아지는 경우가 많다. (오답이더라도) 딥러닝 모델은 거의 전부 확률값을 높게 내는 경향이 있다. (오답이더라도)
  • (Softmax≠proba) out of distribution : 문어체로 학습 시키고, 구어체를 적용하는 경우 ⇒ 모델 성능이 좋지 않다는 것을 미리 예상하고 이를 detection (틀릴 것 같은 것의 confidence를 낮게 주는 것)
  • Temperature를 높이면 확률 값이 높은 것과 낮은 것의 차이가 더 벌어짐
    • 어느 정도 Temperature?
      • 높이면 높일 수록 성능이 좋아지는 경우가 있음
        • 성능 = OOD를 detect하는 성능
      • 일단 많이 높여보는 것 추천!
      • "많이"의 기준 = 10, 20, 30... 논문에선 백 단위까지 높였지만 그건 좀 비현실적이라고 생각
      • 시간 관계 상 대회 내에서 하는 건 무리일 거 같고 상식 정도로 참고하길!

3️⃣ 기타 질문

1) 새로운 시도에 대한 가능성 판단 기준

sparse retrieval로 top 20의 context를 고른 후 dense retrieval를 통해 GT context를 찾는 방식의 retrieval을 만들고 있지만 단일 sparse retrieval 보다 성능 개선이 안되고 있는 상황입니다. 하지만 retrieval 자체의 성능은 조금씩 개선되고 있어서 대회를 위해 계속해서 성능을 높이기 위한 노력을 하는 것이 맞는 건지 의문입니다. (소요 시간 : 약 2주) cf ) Top 1 accuracy → elastic search : 약 70% / proposed retrieval : 56%

• 덧붙여서, 꼭 위 사례가 아니더라도, 어떤 새로운 모델을 구현하거나 접근 방식을 시도할 때, (열심히 뭔가 한다고 항상 성능이 잘 나오는건 아닌지라) 어느 정도 투자하고 포기해야 하는지 '대회'라는 상황 특성 상 고려하면 더 좋을 부분이 있을지 어떤 기준으로 잘됐다, 안됐다를 판단 해야하는지 비단 성능뿐 아니라 다른 기준이 있을지 ⇒ 질문이 참 추상적인데 멘토님께서 떠오르시는 대로 답변해주시면 감사하겠습니다! ㅎㅎ

🍯 멘토님 🍯

• Deep Retrieval과 Elastic Search의 Score를 조합할 수 있는 방법은 없겠는가?
  • Elastic Search가 자주 틀리는 유형의 문제가 있다고 한다면, Deep Retrieval이 이 문제를 해결할 수 있을지도 모른다. 이런 식으로 앙상블을 해보는 것은 어떨까?
  • 파이프라인의 형태로 구성하는 것 보다, Elastic Search에 조금 더 무게를 두되, Deep Retrival을 얹는 형태로 사용하는게 어떨까 한다.
    • 재희 : 어떻게 앙상블하면 좋을까요?
      • 말씀하셨던 것 처럼, 유니온을 하는 것도 좋을 것이다. 두 방법은 Sparse와 Dense의 형태이기 때문에, 각각의 장점이 확실히 있다. Sparse는 단어가 겹치는 경우를 잘 찾고, Dense는 의미가 겹치는 경우를 잘 찾는다. 그렇기 때문에, 둘을 같이 확인하면 서로의 장점을 얻을 수 있을 것 같다.
        • 재희 : 그러면, 각각의 유형에 따라서 장점만 뽑아올 수 있게 하면 어떨까요?
          • 정말 베스트의 방법이지만, 적용하기는 어려울 것 같으니, 유니온의 방법으로 사용해보는 것이 좋을 것 같다.
        • 익효 : 각 Retrieval에서 출력되는 Score를 활용해서 Dense Layer와 연결시키는 방법을 해보는 건 어떨까요?
          • 이것도 하나의 방법이 될 수는 있을 것 같다. Score를 조합하는 방법이 이와 비슷한 방법으로 생각할 수 있을 것 같다. Elastic Search에 가중치를 높게 준다면, Elastic Search가 어려워하는 경우에 Dense에 의견대로 결정될 수 있을 것 같다. 단, 이 방법이 구현이 어려울 것 같아서, 간단하게 적용하는게 좋다고 생각한다.

2) 새로운 도전 or 하이퍼파라미터 search

약 4주간의 대회가 이제 3주차에 접어들면서, 저희 조의 경우 어느 정도 성능이 올라와서 안정화 되었다고(감히) 생각하고 있습니다. 지난번 멘토링에서 이미 이쿄님의 성적을 보고 upper bound라고 언급하셨지만 그 기록을 계속 깨고 있거든요(깨알 자랑) 이런 상황에서 아래와 같이 앞으로의 대회 기간 동안의 팀의 방향성에 대해 고민이 듭니다.

1. 최고 성능 모델 기준으로 하이퍼파라미터 바꿔가며 모델을 개선하는 게 맞는지
2. 새로운(적용해보지 않은) 기법들을 더 많이 찾아봐서 적용하는 게 맞을지

• 사실.. 정답은 둘 다겠죠?ㅎㅎ 팀원이 6명이라 다양한 시도가 가능하긴 하지만, 멘토님께서 저희의 입장이라면 지금의 상황과 시점에 어떤 부분에 우선순위를 두는 것이 좋을지, 그리고 어떤 식으로 역할을 분담하는 것이 좋다고 생각하시는지 의견이 궁금합니다.(competition에서의 효율적인 협업 방식)
• 추가로, AI 직무에서 현업에서의 협업과 competition에서의 협업이 다를 것 같은데, 어떤 부분이 다르고, 현재의 저희가 어떤 걸 배워두면 좋을 지에 대한 조언도 궁금합니다. (git, 역할 분담, 시간 배분 등)

🍯 멘토님 🍯

• 강화학습에서의 문제와 너무 유사하다. 새로운 길 or 찾던 길 선택
  • 정답은 없으나, 멘토님 본인이라면, 1등인 만큼 새로운 시도를 해볼 수 있을 것 같다. 과감한 시도는 굉장히 성적이 높거나 낮을 때 할 수 있다고 생각함. 2~3등이라면 그럴듯한 것만 찾아서 조금 더 높이려고 할듯 한데, 우리는 도전을 해도 좋을 듯. 가능하면, 몇번은 하이퍼파라미터를 바꿔서 제출해보고, 몇번은 시도해보고 하는 형태로 가는건 어떨까?

---

Day15🎤

2021.05.13 (목)

대회 토크

❤️Retriever

💙Reader

• TMI : 이 날은 페이스 조절을 위해 대회 토크를 하지 않았습니다.

---

Day16🍇

2021.04.30 (금)

대회 토크

• ❤️Retriever

  • 태양 : Dense Embedding은 PLM을 쓰는가?
    • 종헌 : 그렇다. bert-multil ingual 쓴다. roberta는 성능이 좋긴한데 2개 올릴 수가 없어서 못쓰고 있음.

  💙Reader

  • 현규 : Max Seq Length 여러가지 적용했으나, 기본값이 좋다
  • 수지 : HanBERT의 Tokenizer가 Fast Tokenizer가아니어서, 이전에 작성했던 코드를 활용할 수 있었음. 근데 뭔가 이상하게 Score가 매우 낮다.
  • 공통 질문 : 지금 불러오는 Model이 PLM인가?
  • 태양 : shuffle을 써봤는데, 성능이 많이 떨어지더라 왜 그럴까?
  • 태양 : KorQuAD로 Pre train을 하는 이유가 무엇인지 고민이 됐다.
  • 종헌 : 추가한 Layer가 초기화되어 있기 때문에, 오버피팅 되지 않도록 사전 학습을 하고나서 우리 데이터로 Fine Tuning을 하는 것이라고 생각함.

---