Peer_Session_Week_1

Day01🍔

2021.04.26 (월)

Ground Rule

Peer Session

• 35분 전까지 입장 완료
• 불참 사유 발생 시 ? 미리 팀 카톡에 알리기

Notion

• *게시물 올릴때 태그, 작성자 달기*
• 태그 자주 쓰이는 요소: link, paper, pen, pencil

Code Review

• 코드를 공유할 땐, **코드에 대한 설명(발표)**를 함께! + *QnA Time*
• *7강까지는 베이스라인 코드에 대한 이해로 다 함께 가기 ⇒ 먼저 가셔도 됩니다...*

Github

• branch를 씁시다!
• 지옥에서 온 Git - 수업소개 : (생활코딩 지옥에서 온 git)

---

Day02🍟

2021.04.27 (화)

Baseline code review

• retrieval이 어떻게 되는 건가
• loss가 어떻게 구현되어있는 건지 모르겠다..NLL, cross entropy?
• ouput 구성 : loss + index
• max train length를 넘어가는 sample의 경우 overlap 되면서 train instance가 늘어남..⇒ 이 결과를 어떻게 집계하는지 코드 레벨에서 찾기 어렵다..
• 각 token에 대해 start point / end point의 확률 값(softmax, cross-entropy 각각)이 output
• 데이터 추가(KorQuAD) 해야할 듯!
• public : train과 context 공유, private : 새로운 (학습에 사용하지 않은) context 일듯

그냥 우리 팀 베이스라인을 따로 만드는 게 낫겠다

---

Day03🍕

2021.04.28 (수)

대회 토크

• Mission 1 中 Pre-processing data : offset mapping과 doc stride

❤️Retriever

• 평가지표가 필요할 것 같다.

• retrieval의 성능을 높이는게 급선무인 것 같다.

• 두 가지 모델을 만들어야 하는데 둘 간의 성능 차이가 있다면 최종적으로 성능이 안 좋아질 위험이 있지 않을까

  • Retrieval을 뺄 수 있는 방법은 없을까? → Testset은 해당 정보가 없어서 해당 모델은 필요한 Task인 것 같다.

• Graph에서 배운 내용을 적용할 수 있으면 좋겠다.

  • 문서간의 관계를 구축할 수 있지 않을까?
  • GNN을 적용할 수 있지 않을까?

• 추천시스템 적용 여부 고민

  • 고민: 질문에 대한 keyword들로 유사도를 구한다고 할 때, top-k를 적용할 수 있을까?

• Retrieval과 MRC를 합쳐서 End To End 형태로 Model을 구성할 수 있지 않을까?

  • Retrieval을 Neural Network에 의한 방법으로 개선하면 가능할 것 같다.
  • 사례를 찾아서 적용하면 좋을 것 같다.

• NDCG

  정보 검색(Information Retrieval) 평가는 어떻게 하는 것이 좋을까?(2/2)

• 재희님의 TF-IDF 강의

  • Baseline은 Mecab을 쓰고 있다. 이 부분도 다른 Tokenizer를 쓸 수 있다.
  • 태양님 의견 : Tokenizing 했을 때 1개짜리 단어는 고려하지 않는게 좋다.

• 문서 자체에 대한 Embedding 방법은 없을까?

  • Sent2Vec?
  • 문서 하나를 Embedding하는 것은 어떤 의미일까?
  • Stopword와 같은 정보를 빼고 Embedding하는 방법을 사용해도 좋을 것 같다.
  • Context 전체 말고, Sentence 단위로 Embedding하는 방법을 쓰는건 어떨까?
    • Branch 글 추천 대회에서 사용된 방법론을 참고해보자!

• 태양님 의견 : Word2Vec에 대한 TF-IDF를 가중치로 활용해서 Weighted Average하여 Document의 Dense Vector를 구할 수 있을 것 같다.

  • 익효님 의견 : 고차원 연산에서 문제가 생길 수 있을 것 같다는 생각이 듦.
  • 재희님 의견 : Word의 Vector에 Scalar 값을 곱하는 Weighted 형태이므로, 고차원 문제는 해결할 수 있을지도
  • 이현규 의견 : Word2Vec이 각 Word에 대한 Vector인 만큼, 문장 전체의 의미를 담기 어려울수도 있다.
  • 수지님 의견 : Doc2Vec이 문서 전체의 의미를 담는 Vector를 얻을 수 있을 것이다.
  • 태양님 의견 : Doc2Vec과 TF-IDF를 Concatenation해서, 활용하는 것도 좋을 것 같다.

• Doc2Vec의 장점

  • Dense Vector를 얻을 수 있다.
  • 50차원을 사용했는데, 더 큰 차원을 사용해도 좋을 듯
  • 태양님 의견 : Concatenation을 사용하는 아이디어를 적용하면 좋을 것 같다. Doc2Vec과 Word2Vec 방법 모두를 사용해서 Inference하고 Ensemble의 형태로 사용하면 좋을 것 같다.

💙Reader

• Post-process 단계에서 조사를 뗄 수 있는 방법도 사용할 수 있을 것 같다.
  • Mecab을 활용해서 조사를 뗄 수 있다!

ETC

• 익효님이 참고한 Links
  • huggingface/transformers
  • monologg/KoELECTRA

---

Day04🌭

2021.04.29 (목)

대회 토크

❤️Retriever

• 추천 시스템과 유사하게 생각할 수 있을 것 같다

  • 질문과 가장 유사성이 높은 문서 top 1 을 찾는 식으로....?

• Document Embedding The Best Document Similarity Algorithm in 2020: A Beginner's Guide TF-IDF가 가장 성능이 좋았다고 한다..

• doc2vec

• SIF : "A Simple but Tough-to-Beat Baseline for Sentence Embeddings" PrincetonML/SIF 단순하지만 강력한 Smooth Inverse Frequency 문장 임베딩 기법

• Sentence-BERT Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks

  • BERT랑 RoBERTa가 semantic textual similarity 같은 sentence-pair regression task에서 SOTA 달성!
    • 근데 문장이 둘 다 network에 들어가야 하므로 큰 연산 오버헤드 발생
  • Sentence-BERT
    • 코사인 유사도를 이용하여 의미있는 문장 임베딩을 얻기 위해 siamese & triplet network 구조를 가짐
    • 가장 유사한 쌍을 찾기 위한 시간 65 시간 → 5초로 감소 & 정확도는 그대로 유지

• 다양한 sentence embedding 방법론 비교 https://www.oxinabox.net/publications/White2015SentVecMeaning.pdf

• 태양님 질문 : 왜 질문과 지문을 Embedding하는 Model을 따로 사용해야 하는가?

  • 재희님 의견 : 질문과 지문의 길이가 다르기 때문에 다른 모델을 사용하는게 좋은 것 같다. 담고있는 정보의 양(길이)과 뉘앙스도 다른 것 같다
    • 익효님: tokenizing할 때 truncation 넣었냐 문장 중에 제일 긴 token 길이가 3100 → truncation 하게 되면 대부분의 정보가 날라가게 되니까 성능이 안 나온 것이 아닐까.
  • 구간을 나눠서 각각의 유사도를 구해서 합산하면
  • Document의 길이가 매우 긴 경우에는 특정 구간으로 나눠서 Embedding을 구하고 합산해야 하지 않을까?
  • 익: KoElectra로 돌리기만 해도 70% 정확도가 나온다고 하지 않나? → 우리 데이터로 하면 낮음 ⇒ 왤까...
    • KoQUAD로 학습하고 우리 데이터에 넣어봤는데 정확도 그대로임.. 데이터가 정제가 안 되어 있는 것 같다 → 전처리를 해봐야 할 듯
    • 전처리하면 좀 짧아질 거 같다 → 짧게 만드는 게 우선시 되어야할 듯

• 태양 : 더 어려운 문제를 만들기 위한 Ideas

  1. Top-k를 뽑은 이후에 이를 학습 Sample로 사용하기
  2. 군집의 방법을 이용해서, 유사한 애들끼리 묶어서 학습 Sample로 사용하기

• BERT만 쓸 것이 아님. Top-k 뽑을 때 다양한 모델을 사용해서 후보를 사용하면 좋을 것 같다.(koelectra 같은)

• 언어의 특성을 고려해서 각 POS를 고려하거나, TF-IDF를 사용할 수도 있을 것 같다.

• PCA 등으로 차원을 축소한 다음에 Sparse Embedding의 약점을 보완할 수 있지 않을까?

💙Reader

• 재희님 의견 여러 지문에서 MRC를 수행하는 방법은 어떨까?
  • 태양 : 답 선택 기준을 어떻게? 나머지 후보들은 의미가 없는 건데 마지막에 답으로 나오는 게 확률 값이라고 하면 확률이 가장 높은 걸로 선택하게 되면 좀 위험
  • (한 걸음 더 간 ) 현규 : 최종 확률 값 * 유사도로 최종 선택을 하면 되지 않을까?
  • 종헌 : 길어도 안 잘릴 수 있게 할 수 있을 것 같음 → 나눠서 넣게 되는 경우 문제가 되는 게 다른 애처럼 연산이 되는 건데, 포지셔널 임베딩을 순서대로 넣어주게 되면 여러번 연산을 하게 되도 하나의 문장인 것처럼 연산이 되지 않을까
• 종헌 : 매우 긴 Document를 잘 Embedding하기 위해서 Positional에 관련된 정보를 넣자.
  • 여러 Feature로 나눠서 Embedding을 구하고, 해당 Embedding Vector를 Concatenation한 다음에 Dense Layer를 태우자.
• 재희 : NER을 통해서 질문의 의도에 대한 정보를 찾고자 한다. 질문의 의도를 분류해보자. Ex) '누구'라는 Keyword가 들어가면, Person에 대한 NER Token을 찾아온다.
• 태양 : Data를 확인하다보니, 따옴표와 같은 정보가 포함된 게 Gold Text인 경우가 있다. 이를 없애야 할까?
• 익효 : \n나 '날짜' 와 같은 정보들은 전처리로 없애주는게 좋지 않을까 생각한다.
  • 태양 : 건드리려면 Answer의 위치 등을 고려해야 한다.
  • 종헌 : 안건드리는 것도 방법일 수 있다. 무엇을 제거해야 할지 등 고려하는게 어려울 수 있다.
  • 익효 : Retrieval쪽에서는 확실히 개행이나 불용어는 제거하는 것이 좋을 것 같다.
  • 재희 : Extract MRC라 원본 문서 안건드는 편이 맞는듯 ⇒ Retrieval만 진행합시다
• 수지 : Mecab 등을 사용해서 단어를 분리하고, Tokenizer를 태우면 위 문제를 해결할 수 있지 않을까?
  • 재희, 종헌 : Mecab을 먼저 태운 다음에 Tokenizing 하면 될듯?

---

Day05🍿

2021.04.30 (금)

대회 토크

❤️Retriever

• 익효 : Elastic Search가 잘 돌아가는 것 같다. Score도 사용하기 편해보인다. 인덱스 기반으로 찾아서 오는 것 같다. type을 바꾸면 Search 방법도 달라지는 것 같다.
• 종헌 : Dense Embedding의 Measure의 기준을 어떻게 할 지 고민중이었다. Keyword가 얼마나 등장 하는가에 대한 정보를 기준으로 생각하고 있었다.
  • 익효 : 강의에서 기준에 대한 언급이 있던 것 같다.
  • 재희 : 완화된 기준일 수 있을 것 같다. 예를 들어 '책의 명칭'이나, '미국'과 같은 단어도 고려한 기준을 세워야 할 것 같다.
• 태양 : Retriever의 Metric을 정해야 할 것 같다.
  • 익효 : Recall이 괜찮을 것 같다.
  • 재희 : Recall, Precision 설명 → 구글 검색 우리는 1:1 매칭을 생각하고 있으니, Precision보다는 Recall이 더 적합한 것 같다. 우리의 예측이 얼마나 정밀하게 맞추는가에 대한 정보니까
  • 수지 : 논문에서도 Recall을 평가 지표로 사용했다.
  • 종헌 : 가장 높은 문장만 사용한다고 하면 Recall이 적합하지만, 여러 문장을 사용한다고 하면 Precision도 고려해볼 필요가 있다.
    • 재희 : 정답이 문서 내에 있는가에 대한 정보가 암시적이기 때문에, 이에 대한 의사결정도 부가적으로 결정해야 한다.
• 수지 : 논문을 보니, Sim Score를 보간법으로 해서 사용하는 것 같다.
  • 종헌 : 저 보간법이 정확하게 뭔지 모르겠는데, 선형은 식이 선형인 것 같다. Anserini가 어떤 개념인지 알아봐야 할 것 같다.
  • 재희 : 가중치를 활용해서 선형적인 변환과 Score를 얻는 것이 아닐까? Anserini는 추가 정보가 필요할 것 같다.
  • 수지 : BERT를 썼다는데, Final Softmax Layer를 제거했다는 것 같다.
• 익효 : Dense Embedding은 Batch Size가 클 필요가 있다고 생각한다. 경험적으로 성능도 그랬던 것 같다.
  • 종헌 : 동감함. but, 엄청 늘리지는 못할 것 같다.
  • 태양 : Question 1개, Positive 1개, Negative 여러개를 사용해야 할 것 같다.
  • 익효 : GPU 고려해서, 각 Batch의 크기를 조정할 필요가 있던 것 같다.
  • 태양 : 어려운 문제를 만드려면, Train Batch를 더 크게 잡아야 하는가?
• 태양 : TF-IDF에서 Max Length를 조정했던 게 생각보다 큰 효과가 있었다.
  • 태양 : BM-25를 엄청 많이 쓰는 것 같다. 유용한 것 같다. Sentence Transformer도 실험해보려고 한다. Document Similarity에 대해 좀 더 알아보고 있다.
  • 익효 : 생각보다 괜찮은 알고리즘인 것 같다는 생각이 들었다. 생각보다 확률 기반이 좋은 것 같다.
  • 종헌 : 학습 기반이 좋을 것이라고 생각했는데, 아닌게 신기하다.
  • 재희 : 네트워크 기반은 데이터의 양에도 큰 영향을 받아서 그런 것 같다.
  • 태양 : 전체 Wiki Data에서 Validation Context를 찾는 것으로 성능 체크를 했는데, 약 30%의 성능을 보였다.
  • 익효 : Dense Embedding할 때는 어쩔 수 없이 불용어 제거하고 돌려봤었다.
  • 재희 : 영어 기준으로 불용어를 제거하고, 엘라스틱 서치를 돌려보면 어떨까?
  • 재희 : 검색은 명사의 형태로 이루어 지니까, 명사로 구분하고 이를 기반으로 Retrieval을 수행하는건 어떨까? 지프의 법칙을 적용해보면 좋을 것 같다. EDA를 해보면, 전체 Doc에서 단 한번만 등장하는 단어도 있다. Top 100이든, 1~5번 등장하는 단어든, 이 정보들을 통해서 검색 성능을 올릴 수 있지 않을까? 이와 같은 정보들로 TF-IDF Score에 도움을 줄 수 있지 않을까?
    • 태양 : 어제 비슷한 걸 했다. 각 단어만 뽑아서 TF-IDF를 돌려봤다. 경험 상 성능에 큰 의미가 없었다. 형태소로 분리해서 수행할 때 조사와 같은 정보를 자체적으로 중요도를 낮게 잡고 하는 것 같다. 성능이 떨어지지는 않고, 비슷하게 나왔다.
    • 익효 : Top 100을 뺴고 돌려봤었는데, 1~5번 등장한 단어는 중요한 것 같다.
    • 재희 : 근데 15번 등장 단어는 Keyword로 보기 어려울 수도 있을 것 같다는 생각이 들었다. 왜냐면 Wiki가 워낙 큰 Corpus인데, 이 중에서 15번..?
    • 태양 & 수지 : 1~5번 등장 단어가 Keyword일 확률도 있을 것 같다.
• 태양 : 연속 단어는 하나로 보는 아이디어는 어떨까? ex) '국가 기관'
  • 재희 : bi-gram으로 해결할 수 있지 않을까?
  • 태양 : 2개만 놓고 보는게 아니라 연속되는 단어들을 하나의 의미로 파악하는 방법을 의미함. ex) '대통령 포함', '미국 행정부 견제', '국가 기관'
  • 수지 : 국어사전을 사용해서 이 안에서 등장하는 단어라면 위와 같은 아이디어에 활용할 수 있지 않을까?

💙Reader

• End-to-End Open-Domain Question Answering with BERTserini

  • BERTsirini = BERT + Anserini IR toolkit
    • Anserini가 머죠 → 오픈소스 retriever toolkit castorini/anserini castorini/anserini-notebooks
  • Article vs Paragraph vs Sentence
    • 결과적으로 다 비슷한 text 양이 되도록 k를 선택
    • Article → 5, Paragraph → 27, Sentence → 78
    • Paragraph 단위가 가장 성능 좋음

• 익효 : 강의에서 Sentence 단위로 Embedding하는 방법에 대해 얘기해줬는데, 이걸 어떻게 적용해볼 수 있을지 고민이다.

  • 수지 : 이 논문을 기반으로 강의에서 말씀하신 것 같은데, Sentence 단위를 꼭 고려하지는 않아도 될 것 같다.
  • 태양 : 오늘 강의를 듣고 k값이 중요하다고 생각이 들었다.
  • 익효 : 여태까지의 방법은 Retriever 성능이 매우 떨어졌기 때문에 고려하고 있었다.
  • 재희 : WIKI는 정제된 TEXT라 '.'과 같은 Split을 활용하면 Sentence로 나눌 수는 있을 것 같다.
  • 익효 : Context마다 Sentence가 다른데, 이를 어떻게 적용할 수 있는지에 대한 고민이 있다.
  • 수지 : Document를 포함할 수 있는 Paragraph에 대한 k를 선택해야 한다고 나와있는 것 같다.
  • 재희 : 여러 Sentence에 대한 Aggregation을 어떻게 할 것인가에 대한 방법론에 대한 물음인가?
  • 익효 : Average의 방법을 사용해 볼 수 있지 않을까?
  • 태양 : 정답에 관련된 문장은 몇 문장 안될 것 같은데, 모든 문장에 대한 Average를 수행하는 것은 유의미 할까? 아무튼 Context 안에 정답이 있는 것은 자명한 것 같다.
  • 익효 : 문장 단위로 쪼개서 답을 찾아나가는 과정이 더 좋지 않을까? Context를 다 Sentence 단위로 쪼개서 답을 찾아나가는 방식을 사용하자.
  • 태양 : 평가 단계에서 Negative한 Sentence에 대한 것을 어떻게 처리하는게 좋을까?
  • 재희 : Sentence로 나누게 되면, 더 많은 Sample에서 선택을 하는 형태가 될 수 있다. 계층적으로 접근하는 방법을 적용해보면 좋을 것 같다.
  • 익효 : Retriever 단계에서는 전체 Context를 살펴보고, MRC 단계에서는 Sentence로 나누는 방법을 적용해보면 어떨까? 확실히 Retriever 단계에서, Sample이 많아지면 성능이 떨어지는 것처럼 느꼈다.
  • 수지 : Simple and Effective Multi-Paragraph Reading Comprehension 논문을 적용해보면 좋을 것 같다. k는 Random이 아니라 평균과 같은 상수값을 곱하는 형태로 사용한다.

• 익효 : Random Masking을 적용해서 학습하는 아이디어를 또 사용해보는 건 어떨까? => 좋아요!

• 수지 : KLUE에서 영어로 번역했던 분이 Score를 높이셨었는데 이걸 적용해볼 수 있지는 않을까?

  • 재희 : 다양한 언어로 번역해서 사용하는 아이디어가 Retrieval 단계에서는 유용할 듯? 번역의 성능은 괜찮을 것 같고, 다만 시간이 조금 걸릴 것 같다.

• 익효 : Test Set에 대한 Prediction을 살펴보면, 굉장히 성능이 떨어져보임. Validation에 대해서는 깔끔해보이는데 왜 차이가 날까?

  • 현규 : Retrieval 단계에서 문제가 생겼을 것 같다.
  • 익효 : Post Process를 통해서 출력이 잘 됐는지를 검증할 수 있지 않을까?
  • 태양 : Output의 형태가 어떻게 되는가?
  • 재희 : Retrieval의 Score와 MRC의 Logit과 어떻게 연결시킬 것인가에 대한 것에 관심 가져야 할 듯함.
  • 태양 : 가중치를 $\mu$로 활용할 수 있을듯?
  • 종헌 : $\mu$도 학습할 수 있지 않을까?
  • 태양 : $\mu$가 다른 형태에서 앙상블 방식으로 수행하는 것도 방법일 듯하다.
  • 종헌 : Text에 대한 Prediction을 Hard Voting할 수 있을듯 이 방법대로 하면, 다른 Document로 부터 나온 Text에 대해 Voting할 수 있을 것 같다.
  • 재희 : Logit으로 Soft Voting 하면 되지 않을까?

    • Start position, end position으로 voting

  ---