Peer_Session_Week_2

Day06😥

2021.05.03 (월)

대회 토크

❤️Retriever

• 태양 : BM25 토크나이즈 아무것도 안 한 게 성능 가장 좋았음 (베이스라인 morphs 사용)
• 익효 Elasticsearch Guide 7.12
• 앙상블 시도 → 성능 하락
• 태양 : 앙상블을 어떻게 ?
  • 익효 : k=1로 해서 각 모델이 예측한 것을 Count 기준으로 앙상블 시도함. k의 값을 높게 주는 경우도 있는 것 같으나, 1개를 쓰는게 좋다는 글을 봤다.
    Evaluating QA: the Retriever & the Full QA System
• 종헌 : Voting할 때에는 k를 더 많이 쓰는게 좋지 않을까?
  • 익효 : 경험상 k가 올라갈수록 떨어지더라.
• 태양 : BM25가 더 좋다고 생각 BM25랑 Dense Embedding에서 각 예측을 내고, BM25에서 낸 예측을 기준으로 Dense Embedding과도 매칭이 되는지를 체크하는 형태를 구상중임.
• 종헌 : Dense Embedding에서 성능 향상 가능성이 보인다. 자꾸 Cuda Error가 나서 아직은 멈춰있다. 줄바꿈 문자와 같은 텍스트는 전처리로 지우고 사용했다.
• 종헌 : 오늘 강의 실습에서 사용할 때에는 학습에 대한 내용은 없고, 불러다 쓰는 것만 있더라.
• 익효 & 종헌 & 태양 : 아무튼 Dense Embedding도 활용해서 예측을 하는 것이 좋을 것 같다.

💙Reader

• 익효
  • Random Mask 씌워봤다 → validation에서 효과 有
  • but, 제출 시 성능 하락
  • 전처리는 무조건 필요할 듯(KorQuAD는 별다른 처리 없이 성능이 잘 나오는 것으로 봤을 때, 데이터 처리만 잘해도 좋은 효과가 있을 것 같다.)
    1. \n ⇒ 개행 문자 전처리
    2. 이모티콘 전처리
• 수지 : ElectraForQA를 하는 중임. monologg님이 KorQuAD에서 90몇%를 찍었다더라. 베이스라인 Tokenizer와의 차이가 있어서, 두 속성을 구현해야 함. 이걸 잘 어떻게 하면 구현할 수 있을 것 같다. 이 베이스라인에 맞도록 바꾸고, 우리 데이터로 재학습 시키는게 의미가 있을까? 이 작업을 하는게 효율적이긴 할까?에 대한 의문도 있다.
  • 익효 : Fast Tokenizer에만 해당 속성이 없는 것인가?
    • 수지 : 현재 사용하려는 Tokenizer는 Fast가 없고, 그러다보니 베이스라인에서 사용하는 속성이 없다.
  • 종헌 & 재희 : monologg님이 한 학습 방법을 알아보고 활용해 볼 수 있지 않을까?
  • 익효 : KoElectra로 돌릴때 돌아는 갔다.
    • 수지 : Fine Tuning된 Model이 안돌아가고 있다.
  • 재희 & 익효 : 일단 해보는 게 좋을 것 같다.
• 태양 : 조금 다른 Context를 넣고, 정답이 없다는 것을 학습시키면 좋지 않을까?
  • 재희 : 정답이 없다는 것을 학습시킬 수 있다면 좋을 것 같다.
  • 수지 : 종헌님께 읽어달라고 한 논문이 비슷한 내용이 담겨있다.

---

Day07☕

2021.05.04 (화)

대회 토크

❤️Retriever

• 태양 : 전처리를 어느 단계에서 활용했나?
  • 익효 : Retrieval 단계에서부터 활용했다. 이때 성능향상이 있지는 않았고, 이 전처리 된 Text를 Reader에서 활용하기 위해 이 단계에서부터 처리하고 사용함.
• 종헌 : 어제 말했던 Cuda Error의 원인을 찾았다. (학습 정리에 올려놨다.) 원래는 Context 전체에 대해서 Index를 잡아주려고 했음. 사전 학습된 모델은 512 Size이기 때문에, Index가 넘어가면 부를수가 없기 때문임. 그래서, 문장단위로 끊어서 512이내로 해결할 수 있도록 했음. 근데, 이 이후에 Cuda Error가 남. 한 문장인데도, 512를 넘어가는 문제가 있었기 때문이었음. 그래서 512가 넘어가는 문장에 대해서는 그 이후 Index를 동일하게 512로 처리함. 돌려보고 성능 체크를 하기 위해 임시방편에 가까운 처리를 한 상황임.
  • 익효 : 불용어와 같은 정보를 제거하고나면 모든 문장을 512 이내로 넣을 수 있을지도 !
• 익효 : Dense Embedding을 활용해보자. Elastic Search로 한 20개를 뽑고, 그 다음에 Dense Embedding을 통과해서 최종 N개의 Document를 찾는 것은 어떨까?
  • 종헌 : 상동한 생각을 했다. 다만, 순서는 어떤게 더 좋을지는 고민이 된다.
  • 익효 : Top20이면 거의 100% 정답에 해당하는 Document를 찾을 것 같다. 그럼, 이 중에서 Dense Embedding을 통과하면 좋을 것 같다는 생각이 들었다.
  • 태양 : 쿼리를 기반으로 전체 문장과의 유사도를 구하고 유사도가 높은 문장을 입력으로 사용하는 것은 어떨까?

💙Reader

• 익효 : 전처리랑, Concat 두개 써봤는데, 둘 다 성능 향상이 있었다.
• 태양: concat 한 거 써봤는데 5~7이 가장 적당했음
  • 익효: 5개 or 7개?
    • 태양: 7개 (10개는 확실히 아님 ⇒ EM은 올라갔는데 F1 스코어는 좀 떨어짐)
• 수지 : offset_mapping과 overflow_to_sample_mapping을 구현하려고 했는데, 결과론적으로 label에 해당하는 값만 찾으면 될 것이라고 생각함. 그래서, 형식에 맞게 만들어만 주면 될 것이라고 생각했음. Logic 기반으로 동일한 효과를 내도록 위를 구현할 수 있을 것 같다.
• 재희 : Span 단위 Random Masking 설명 (Notion 링크 참조) 단어의 시작을 찾는 Logic이 있고, Random한 길이만큼의 Token을 Masking하는 형태로 구성되어 있음. MLM과 SBO의 Task로 Loss를 구하는 형태로 학습을 시킬 수 있음. 이를 통해서, Token을 의미단위로 잘 구분하는 Model을 만들 수 있으리라 생각 됨.
• 익효 : Token 단위 Random Masking은 성능이 떨어졌다.
  • 종헌 : Question쪽에 Masking을 해보는 건 어떨까?
• 수지 : 태양님이 만든 Dataset 적용해보았는가? 익효님?
  • 익효 : 추가 데이터 쓰는 것을 다시 시도해보긴 해야할 것 같다. (토론 게시판에 올라온 것을 보니까, 길이와 같은 이슈가 있었을지도 모르겠다.)
• 익효 : 학습 할 때도 여러 Context를 Concatenate하고, 학습 시키니까 성능은 오르더라. 현재 k=5, 7까지도 해볼 예정
• 태양 : Question을 변형하는 방법은 어떨까?
• 재희 : 수지님이 준 논문 좋은듯 Top N의 Document를 가져와서, Noise를 제거한다. Document를 Paragraph로 나눠서 갖고오자. Paragraph내에서 Ranking을 매기고, 중요한 Paragraph만 가져오자. 상관이 없는 Paragraph는 Noise로 판단함.

---

Day08🎇

2021.05.05 (수)

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

1. 컴퍼티션을 진행하면서 주어진 테스크에 맞게 진행(전처리, 불용어 정의등등...) 하는게 중요하다는 말을 많이 들었는데 아직 경험이 적어 해당 말이 잘 와닿지 않습니다. 간단한 예시같은게 있을까요?? (기계독해부분이 아니여도 괜찮습니다)

   • 태스크를 생각하면 당연한 부분이 있을 것 같음. Task마다 다른 경우가 많음. wiki에서 가져오다보면 들어가는 표나, 이모티콘, HTML Tag 등 감정 Classification의 경우에는 이모지를 놔두는 경우도 있음. 예를 들면, 문장부호의 경우도 Task에 따라 처리 방법이 달라질 듯

   • 중요한 Input인가에 대한 여부로 생각해보면 좋을 듯하다. 영어의 경우 관사가 의미를 파악하는데 중요한가? 와 같이 생각할 수 있을듯. 불용어는 Named Entity로 인식하고 남겨두거나 처리하거나 하는 등 개행문자 제거 등은 성능 향상에 도움이 되는 것이 맞음. 특수문자 등 제거는 통상 많이 사용함. 원래는 정답의 배리에이션이 있는데, 이렇기 때문에 통상적으로는 지우는게 맞음. ex) 인물의 이름을 찾는 경우, 성이 있고 없고, 등과 같은 배리에이션이 있어야 함. but) 현재는 answer가 1개 밖에 없긴 함. → 문제 정의를 따라가는게 맞는 것 같다.

     • 종헌 : 만약 꺽쇠를 붙이는 식으로 Prediction을 변경하는 것은 어떨까요?

       멘토님 : 가능한 후처리 방법일 수 있음. but, 모든 Prediction에 붙여야 하는지에 대한 의사결정은 Data의 분포 등 확인 후에 하는 것이 중요할 듯

2. 베이스라인에서 사용하는 Tokenizer는 PreTrainedTokenizerFast (FastTokenizer) 기반인데 제가 사용하고 싶은 QA task에 fine-tune된 tokenizer는(monologg/koelectra-base-v2-finetuned-korquad) FastTokenizer 기반이 아니라 FastTokenizer에서 제공하는 몇몇 feature들이 없습니다. (ex. offset_mapping, overflow_to_sample_mapping 등) 지금으로선 저희 베이스라인에 맞게 해당 feature들을 직접 구현해보는 식으로 진행하고 있는데 혹시 이것 말고도 다른 방법이 있을까요?

   • 수지 : KorQuAD로 미리 학습한 Model을 활용해보려고 한 시도였다. KorQuAD에서 성능이 보장되어도, 우리 Data와 완전 맞지는 않았던 것 같다. 이런 접근 방법이 좋을까요? 멘토님 : KorQuAD와 우리의 Data는 분포가 다르기는 하다. 질문의 유형도 다르고, Context의 유형도 좀 다르다. Data의 분포가 다른 것은 맞다. 하지만, Data를 추가한다는 의미에서, 학습시에 도움이 될거라는 생각은 한다.
   • 익효 : KorQuAD를 사용해서 학습시켜봤는데, 실험적으로는 성능이 매우 떨어지더라. 그리고 길이도 매우 다른 것을 볼 수 있었다. Wiki Dataset과 KorQuAD Dataset의 길이를 비슷하게 맞추는건 어떨까하는 생각도 하고 있음. 그리고 이렇게 Data를 늘리면 Retrieval의 성능이 떨어지는 것도 우려가 된다. 멘토님 : KorQuAD로 학습을 진행한 다음에, 그 다음에 우리 Dataset (KLUE)를 학습해보는 것도 방법일 수 있다. 혹은 Oversampling을 해서 비율을 맞추는 형태로 학습시켜보는 것도 방법일 수 있다. 길이는 어차피 Reading할 때 잘라서 읽기 때문에, 크게 문제되지 않을 것이라고 생각한다.
   • 익효 : 왜 KorQuAD와 우리의 Data의 길이는 왜 차이가 큰가요? 멘토님 : KLUE Data가 KorQuAD보다 어렵게 설계했다. 왜냐면, KorQuAD와 다르게 만들어야 했기 때문에, 더 어렵게 만들었다. 그래서 더 어려울 것임.
   • 익 : 억지로 KorQuAD에 맞출 필요는 없는 것일까요? 멘토님 : 확답을 드릴 수는 없을 것같다. 근데 Model의 기준으로 생각해보면, 큰 의미는 없으리라 생각한다.

3. 리트리버 단계에서 elastic search(open source 검색 엔진)를 활용하고 있는데, 대체할 만한, 혹은 겸할만한 다른 예시가 있을까요?

   • Elastic Search는 매우 좋은 Choice라고 생각함. 왠만한 Search API 중에서는 가장 성능이 좋다고 알려져 있음. 하이퍼 파라미터만 잘 설정해주면 좋을 듯. 내부 알고리즘을 무엇으로 쓸지 등이 중요할 듯함. 이전에 회사에서 겁나 열심히 만들던 Search System보다 그냥 갖다 쓴 Elastic Search가 잘 동작했다. 최종적으로는 Retrieval을 벗어나는 형태로 됐고, 앙상블 형식으로 두 방향 모두 다 썼다. 아무튼 Retrieval 단계에서는 Elastic Search가 매우 좋다.
     • 재희 : Elastic Search와 Dense Embedding을 같이 써보려고 하는데, 이 접근 방법이 좋을까요? 멘토님 : 실제로 현업에서도 앙상블로 접근한다. Elastic Search와 Dense Embedding에서 Proba를 뽑아서 활용할 수 있음. 이를 합치는 방법도 다양함. Union Set으로 모두 뽑아서 본다든지, 현재는 시간이 중요치 않으니, 각 Retriever에서 나온 Context를 모두 활용해서 추론하는 방법으로 접근할 수도 있을 것 같다.

4. 음절단위 토크나이징 팁이 있을까요?

   • Pretrained Model을 활용하고 있는데, 동일한 Tokenizer를 활용해주는게 좋을 것이다. Tokenizer를 바꾸는 건 좀 어려운 접근방법인 것 같다. 해당 Tokenizer로 Tokenizing을 해야 Model이 이해할 것임. 하ㅇ+ㅝㄴ 과 같이 조합형 Tokenizing을 했음. 요새는 완성형으로 하고 있음. 이게 더 좋은 성능을 보이고 있음. 아마 KLUE 때 하셨던 말씀은 완성형으로 Tokenizing하라는 의미였으리라 생각함. 일단 어려운 문제인 것 같음. 당장 떠오른 아이디어는 POS Tagging을 해서 떼낼 수 있을지도 모르겠다. 그러면 떼는 방법으로 학습을 진행할 수 있을수도 있다. 이러면 학습단계에서 활용할 수 있지 않을까? 중간에 띄어쓰기를 넣는 형태로 하면, 의미상으로 크게 달라지지 않기 때문에, 해결할 수 있지 않을까 생각한다.
     • 재희 : Mecab으로 떼는 것도 생각은 했는데, 이 방법이 정상적인 접근방법일까요? A : 안쓰는 접근방법이 아니다. Pre Tokenizing이라는 방법을 사용하기도 한다. 이런 접근 방법은 자주 사용한다. Pretokenizer로 미리 Token들을 찢어놓고 Tokenizing을 수행함. 걱정되는 문제는, Pre-trained Model을 활용하고 있기 때문에, Model이 학습한 형태와 매우 다르게 될 경우에 Model 자체가 성능이 하락할 수 있다. (Tradeoff 有)

5. 리트리버 단계에서도 리트리버 모델끼리 앙상블하는 경우가 종종 있나요? (서로 다른 score 측정법을 사용하여 앙상블시 성능이 안 나왔습니다.)

   • 익효 : 다양한 조합으로 앙상블을 했는데, 경험적으로 성능이 떨어졌습니다. 왤까요? 멘토님 : Sparse 중에서는 BM25가 제일 잘한다. 다른 기법과 Correlation이 높은 애들과 묶어서 그런게 아닐까싶다. 또한, 각 모델의 성능차이가 있어서 일수도 있다.
   • 익효 : 성능 자체는 큰 차이가 없었다. 멘토님 : 그럼 아마 Correlation이 문제가 된 듯 하다.
   • 종헌 : Dense Embedding을 만들고 있는데, Context의 길이가 길어서, 문제가 생기고 있다. 어떻게 할까요? Baseline에서의 Code를 활용하자니, Retrieval 단계에서는 앞쪽 토큰만 들어가는 형태가 된다. 현재는 각 문장으로 짤라서 Average Pooling을 하는 형태로 하고 있음. 멘토님 : Context를 슬라이딩 하면서 자르고, 각각의 문장을 각각의 Context처럼 판단하면서, 하나라도 걸리면 뽑아오는 형태로 구현을 하는 것도 방법일 수 있음.
   • 종헌 : Inference Time에서는 어떻게 적용하면 좋을까요? 멘토님 : 동일한 방법으로 수행해도 될 것 같다. 그 중에 하나라도 걸리면 해당 Context의 ID 등을 이용해서 다 뽑아오면 될 듯하다. 오히려, Training할 때에는 Average 형태로 수행하는게 나을 것 같고, Inference에서 위 방법을 사용해보는 게 좋지 않을까 생각함. 추가적인 방법으로, 정답이 포함된 부분만 positive example로 활용하고 나머지는... 버리는 식으로(negative example로..?) 학습을 하는 것도 방법일 수 있다. 나머지는 버려서 아예 활용하지 않는 방법도 있을 수 있음.

6. MRC task에서 Masking을 적용할 때 어떤 식으로 수행하나요? 현재까지의 실험 결과로는 context에 랜덤 masking을 하는 것보다, 질문에만 masking을 하는 쪽이 성능이 좋았는데 이유가 궁금합니다.

   • Word Dropout이라는 방법이 있음. Context에 대한 Masking보다, Question에 Masking했을 때 좋았다는 것을 해석해보면, Context에는 쓸데 없는 Token이 많아서 효과가 미미했을 것임. Question은 훨씬 중요한 정보가 가려지는 형태임. 그래서 문제가 어려워지고 좋은 결과가 나왔다고 생각함. 추가로, 정답에 마스킹이 되는 경우에는 아예 문제를 틀렸을 것이다. 이 때문에 성능이 떨어졌으리라 생각함.
     • 재희 : 그럼 질문과 유사도가 높은 문장에 Masking을 하는 방법은 유효할까요? 멘토님 : 7번이랑 연결해서 설명하겠음. 걱정이 되는 것은, 마스킹이 헷갈리는 문장에 대한 표시처럼 이해될 수도 있을수도.

7. token 단위 랜덤 masking이 아닌, span 단위의 masking은 어떻게 생각하시나요? 관련 문헌

   • Span 단위로 Masking을 하는 것은 Pretrain 단계에서 했던 것 같기도 하다. 근데, 괜찮은 접근 방법인 것 같다. 의미가 있는 단위로(entity 단위) Span을 잡고 마스킹을 하는게 좋은 성능을 냈다는 결과가 있다.

     중요한건, 정답에 마스킹을 하면 안된다고 생각함.

     • 종헌 : 일반적으로 context 내에서 중요한 span을 찾아서 masking을 한다고 하셨는데 중요한 span을 어떻게 찾으면 될까요? 멘토님 : Fine Tuning의 단계와 Pre training 단계를 구분해서 생각해봐야 할 것 같다. Fine Tuning 단계에서 어디에 마스킹 해야하는가에 대한 것은 레퍼런스를 본 적이 없다. 정답 Context 내에 정답 주변의 Token을 마스킹 하는 방법은 어떨까하고 생각함. (정답 외 다른 엔티티) 정답이 들어있는 문장의 의미를 이해해야 하기 때문에, 해당 문장을 조금 더 이해하기 어렵게 만드는 것은 의미가 있을 것 같다. 꼭 Entity가 아니더라도, 동사와 같은 형태의 Token을 마스킹하는 것도 좋은 방법일 수 있다.
     • 재희 : Masking을 씌운 Data와 안씌운 Data를 여러번 학습시키면 문제가 생기지는 않을까요? 멘토님 : 오히려 말씀하신 방법이 더 좋을 것 같다.

8. XLM roberta large, koelectra 위주로 활용 중인데 추천해주실만 한 model이 있으신가요?!

   • XLM만큼 좋은게 없는 것 같다. Electra Model은 사실 성능을 엄청 올리려는 목적이 아니었다. 적은 리소스를 써서 Bert만한 성능을 내겠다고 한게 Electra의 목적이다. 현실적으로 Bert보다 작고, 빠르고 함. 근데 성능은 Bert가 더 좋음. (그래서 현업에서는 Electra를 자주 씀.) 근데, 성능면에서는 roberta가 짱이다. T5는 써봤는지? 이것도 실험해볼만한 가치가 있다고 생각함. 이 모델이 QA에 적합하게 되어있다고 생각한다. T5의 Encoder 부분만 떼어내서 쓰면 roberta처럼 쓸 수 있다.
     • 익효 : MRC에서 앙상블할 수 있는 방법은 무엇이 있을까요? 멘토님 : 일단 2스테이지로 간다는 것 같으니, MRC에서 앙상블에 대해 설명하겠음. 확률값으로 하기는 어려울 것 같고, 각 정답을 내고 Proba가 가장 높은 것을 찾는 방식이 될 듯함. 여러개의 MRC를 진행하고, 각 Model의 정답 Span을 확인하고, 이를 Voting하는 방법을 사용할 수 있을 것 같다. 각 모델이 출력하는 Span의 Score를 보고 최종 출력을 결정하는 식으로 사용 가능할 듯. Logit의 평균을 구해서 앙상블 할 수도 있을 듯. 만약 Scale이 다르면 Normalization을 하면 될 듯 함.

9. Query에 해당하는 Token의 Embedding Vector를 직접적으로 활용해보고 싶은데 관련 논문 있을까요?

   
   • 당장 기억나는 논문은 없다. 해볼만한 아이디어인 것 같다. 단순 Pooling보다, 학습할 수 있는 layer를 두고, 활용해보는 것은 어떨지? 추가적인 Information을 어떻게 더 줄 수 있을지? 백본 모델이 커버하지 못하는 의미를 추가하는게 좋은 아이디어 일 것 같다.
     • 재희 : 서민준 교수님이 참여한 논문에 보면, 질문을 히든 스테이트 벡터로 만들어서 활용하는 방법이 있더라. 질문이 중요할 것 같아서 적용하려는 시도임. 질문을 벡터화할 때 GloVe와 같은 Model을 사용하는 것은 어떨지? 영어로 번역해서 쓰는 것은 어떨지에 대한 생각도 들었다.
     • Q1 : 한국어로 GloVe를 태워도 될지? 그러는게 더 좋을 것 같다. 괜한 오류가 낄 수 있다.
     • Q2 : 서민준 교수님의 Real time 기반의 논문의 정보를 활용할 수 있을까요? 이건 관점 자체가 아예 다르다. 지금은 문서단위로 보고, 가장 좋은 문서를 찾고 리드하는 형태임. 이 논문은 문서를 미리 다 쪼개고, 각 모든 프레이즈를 임베딩 하는 형태로 진행함. 거기에 가장 적합한 프레이즈를 찾는 형태임.
     • Q3 : Ranking Paragraph 논문의 아이디어를 적용해볼 수는 없을까요? 각 Paragraph에 대해 ranking을 매기고 reading을 하는 것은 좋은 접근 방법인 것 같다.
     • 추가 답변 : BiDrectional은 MRC의 표준으로 사용될 정도로 매우매우매우 좋은 Model이다. BERT이후에 현재는 안쓰는 Model 구조이긴 하다. BERT의 Pretrain하는 것을 생각해봤을 때, 지금과 같은 형태로 진행되고 있기는 하다. 도전해볼만한 좋은 IDEA라고는 생각하나, 어떻게 보면 BERT 구조에 의해 이미 깨진 방법이라고 이해할 수도 있을 것 같다. 시도해볼만은 하나, 성능면에 있어서 장담할 수는 없다고 생각한다.
     • 종헌 : BiDirectional Attention Flow Model과 BERT를 조합하는 방법은 어떨까요? 멘토님 : Contextual Embedding을 BERT로 쓰고, Query와의 Attention을 내고, 이후에 Transformer를 활용하는 형태로 Embedding을 추가로 해서, 출력을 내는 것을 어떨까 생각이 듦.
     • 종헌 : Data 수에 비해 너무 학습되지 않은 Layer를 추가하는 것은 아닐지 걱정되기도 한다. 멘토님 : 동일한 걱정은 된다. Modeling Layer 부분이 제대로 학습 될지 걱정이 되긴 한다. 실제로 BERT 위에 Layer를 많이 쌓지 않으려는 이유도 동일한 이유다.
     • 재희 : KorQuAD로 사전학습 시키고 나서 사용하는 건 어떨까요? 멘토님 : 매우매우매우 핵심적인 접근이다. 이를 학습에 활용하고 접근하는 건 매우매우 중요하다.

10. 추가 질문 : 질문을 Paraprasing 해서 여러 질문을 만들고 더 많은 Sample을 만드는 접근 방법은 어떨까요?

    좋은 접근 방법인 것 같다. but, 인간 지능은 비추천함. 간단한 방법으로는 Rule Base로 할 수 있을 것 같다. 조금 다른 형태의 질문을 만들 수 있을듯 하다. Question 템플릿을 만들어서 질문을 생성해낼 수 있을 것 같다. 역번역이 패러프레이징에서 가장 많이 사용되는 방법이다. Text Data Augmentation으로 검색해서 다양한 방법을 사용할 수 있을 것 같다. PLM을 활용해서 가장 가까운 단어로 바꾸는 형태로 할 수도 있음.

    • https://neptune.ai/blog/data-augmentation-nlp
    • https://github.com/makcedward/nlpaug
    • https://github.com/dsfsi/textaugment

---

Day09😀

2021.05.06 (목)

대회 토크

❤️Retriever

• 논의 사항 없음

💙Reader

• 익효 : KorQuAD로 학습 시킨 후 우리 Data로 학습시키는 것 해봤다.
  • 익효 : Validation Set을 뭐로 할까요?
  • 재희 & 종헌 : KorQuAD로 쓰는게 좋을듯
• 태양 : Question에 Masking하는 방법 다른걸 해봤다. 단어 기준 Random Masking을 해서 학습을 진행해봤다. Original Question, Masking Question 여러개를 모두 학습에 활용해봤다.

코드 공유

종헌 : Dense Embedding

• Mecab으로 Pretokenizing함. 문장 단위로 잘라서 활용함. 학습 할 때 512 길이를 랜덤하게 사용함.
• 추론 할 때 절반씩 오버랩하면서 전체 Context를 사용함. 이후 전체 Average를 함. 매 배치마다 Context가 몇개로 잘릴지 모르는 것도 큰 문제였다. GPU가 터지지 않게 올리고 내리는 것을 콘트롤하는게 중요했다.
• Elastic Search Error로 현재 중단 상태임. (정확하게는 nori가 동작하지 않음.) → 해결함.

익효 : Elastic Search

• 설치 및 활용방법 설명
• Data 전처리 : 개행문자와 특수문자 등 지우기. → 줄바꿈 문자를 구분할 수 있는 방법도 있으면 좋겠다. → [SEP]는 성능이 엄청 떨어진다. DataDict 형태로 재저장함.
• 걱정되는 사항 : backbone name을 model name으로 설정해서 저장하고 있음. koelectra 사용할 때 monologg 디렉토리 형태로 접근함. (tokenizer를 전달해야할 듯)

태양 : Retrieval / Data Masking / 조사버리기

• Retrieval : bm25로 바꿔서 수행해봤다. BM250kapi라는 API를 사용해봤다.
• Data Masking : Question의 특정 단어들을 MASK로 바꾸고 Data를 늘려줌. 이 Data를 Dataset으로 다시 저장하고, 학습에 활용함. Masking할 때 Tokenizer를 전달해서 Token의 갯수를 맞추는 방법은?
• 조사버리기 : 후처리 이후 Last Processing 함수로, 재처리해서 조사와 특정 Tag를 버림. '의'와 같은 조사를 떼는게 어렵다. Mecab Tokenizer말고 다른 것도 써보는것도 방법일 듯.

---

Day10☔

2021.05.07 (금)

대회 토크

❤️Retriever

• 익효 : 구글에 한국어 불용어 어미 치면 엄청 많이 나옴 → 불용어 사전 추가 (Top1일때는 0.5오름, Top9은 동일한 수치)
  • 익효 : 여러 Context를 보는게 위험할 수도 있다는 생각이 들었다.
  • 종헌 : K가 늘었을 때 성능이 늘어나는게, 우려한 이유 때문이었다고 하더라도, LB기준으로 가는게 맞는 것 같다. 일반화 된 성능을 Check할 만한 수단이 마땅치 않고, 이것까지는 고려하지 않고 단일 기준으로 가는게 좋을 것 같다.
• 종헌 : Elastic Search로 20개의 Context를 찾았음. GT가 없는 경우에 GT를 추가해서 Positive로 사용하게 했음. 학습 할 때 Batch 2만 돼도 터짐. Batch는 1인데, 이 한 Batch내에 20개의 Pair가 들어있는 형태임. 학습하는데 너무 오래 걸리는 문제가 있다. 한 에폭에 1시간 정도 걸린다. 다른 모델도 학습시켜서 확인해봐야 할 것 같다. lr을 줄이고 epoch을 늘리니까 점점 더 학습이 잘 되는 형태를 보여주고 있음.
  • 익효 : KorQuAD도 학습하는데 오래 걸리긴 하는데, 여러 방법으로 재학습 시켜서 하는 형태는 어떨까 생각이 든다.

💙Reader

• 익효 : Conv Layer 추가, KorQuAD로 학습할 때 더 많이 돌림(3에폭→8에폭), 조사 버리는거 태양님거로 바꿈.

  • 태양 : 코드 개선됐으니, 적용해보자. (여러 토크나이저 사용해봄.)

• 현규 : 형태소 분석기별 prediction error rate 비교

• 수지 : prepare_train_dataset과 prepare_validation_dataset 함수를 새로 구현하고 있음. (엄청 고생함. 매우 많은 노력이 들어감.) offset_mapping을 결국 구현해야 할 것 같음. 나중에 validation data도 학습에 사용하면 좋겠다.

• 태양 : Scheduler 빼고 학습해보는 건 어떨까 생각이 든다. K에 따라 다른 Prediction을 Hard Voting 해보는건 어떨까 싶다.

• 태양 : 역번역으로 Question을 늘려서 학습해봤는데, 실험 상 성능이 내려감.

• 익효 : KorQuAD Data 등 외부 데이터를 사용할 때는, 사전학습 한 후에 KLUE Data로 재학습 시키는게 더 좋을 것 같다.

  • 태양 & 종헌 : 학습 Epoch는? 왜?
  • 익효 : KorQuAD는 8Ep, KLUE는 3Ep → KorQuAD는 더 학습해도 될듯, KLUE는 이 정도면 수렴하는 듯.

• 태양 : Context를 여러 개 갖고 와서, 문장 등으로 자르고, Question과 관련 있는 것들로만 학습을 하는 건 어떨까?

  • 익효 : 관련해서, 길이에 대한 이슈로 생각했었는데, 멘토님 말씀 듣고나서 길이에 대해 다시 고민하고 있다.
  • 재희 : Context를 Phasage로 잘라서 Wiki Data를 만들고, 각 Phasage에 대해 학습을 진행하면, 더 다양한 문장을 보고 학습이 될 것 같다.

• 문제시 하고 있는 사항 : 길이에 따라 성능이 달라질 것 같다.

확실하지 않은 사항 : -> 짧은 Phasage를 보는게 더 좋은 Logit이 나올까? -> 긴 Phasage를 보는게 더 좋은 Logit이 나올까?

가설 1. 짧은 Phasage가 좋을 것 같다. -> 정답과 무관한 Noise한 Data들을 무시할 수 있다. -> 짧게 자르는 만큼, 한 Context에 대해서 여러개의 Feature (Sample)로 학습할 수 있다.

가설 2. 긴 Phasage가 좋을 것 같다. -> 문맥을 파악해야 하는 Task인 만큼, 한 Sample에 포함된 문맥 정보가 중요할 것 같다. -> 한 Context에 대해 적은 Feature에 대한 Logit을 내기 때문에, 더 확실하게 Token을 잡을 수 있을 것 같다.

• 현규님 생각 : -> Retrieval은 관련있는 여러개의 Context를 던져주는게 맞는 것 같다. -> 문장을 자르거나 하는 것은, MRC Train 과정에서 이루어져야 하는 것 같다.

  • 태양님 생각 : -> 학습 쪽보다는, Inference할 때, 더 많은 Context에 대해서 추론을 하고자 했음. -> 더 많은 Context에 대해서 다 추론을 돌릴 수 없으니, 관련있는 문장들에 대해서만 하면 어떨까? 하는 아이디어였음.

• 종헌님 생각 : -> 짧을 수록 좋을 것 같다. -> Context를 10개 뽑아온다. -> 똑같은 크기로 자른다. (문장단위 등) -> 그리고 또 뽑는다. -> 여기서 뽑힌 Top N으로 학습하고, 추론하자.

  • 재희님 생각 : -> Elastic Search에서 불필요한 정보를 배제하면 더 좋은 Retrieval을 할 수 있을 것 같았다. -> MRC Task 자체도, 많은 문장을 봐야할 필요가 없을 것 같았다. -> 가설 1이 더 합당하다고 생각한다. -> Elastic Search를 한번만 태우는게 맞는 것 같다.

  지금 Retrieval 단계에서 Ground Truth를 Context 단위의 DocID를 쓰는게 아니고, 문장 단위로 Answer word가 있는 Phasage를 GT로 쓰겠다. -> 여기서 Doc stride overlab을 주면 이상해질 수 있다. -> answer의 text를 기반으로 하게 되면, 여러개의 phasage가 오면 ~~ -> 여기서 concat을 하면, MRC의 GT가 망가질 수 있다. -> 그럼 학습할 때는 각각 따로 phasage별로 학습하면 될 것 같다. -> 이쿄 의견은 학습할 때도 Concat을 해도 될 것 같다. -> 태양&종헌 의견, Overlab된 문장이 여러번 Concat된 형태의 sample이 만들어지면 이상해질 거 같다. => 멘토님께 질문 드리기로

---

Day11😊

2021.05.08 (토)

대회 토크

❤️Retriever

• 종헌 : Dense Embedding할 때 Model을 두 개 올려야하니, Cuda Error가 자꾸 터진다. 일단 2개로 해보고, 안되면 나중에 1개로 바꿔보자.

💙Reader

• 익효 : Context Concat하는거가 Public LB나 과적합 등의 문제가 있을까 걱정된다.
  • 태양 & 현규 : 문제 없을 듯 하다! 10개 이상으로 실험을 해보면 좋을듯!

---