# ODQA

tri2601

DPR 논문 리뷰 Abstract 기존 검색 방법인 Sparse embedding을 사용한 검색 방법인 TF- IDF 또는 BM25 처럼 Lexical한 방법이 아닌 Dense embedding을 사용한 Semantic한 방법 성능이 좋다. Dense embedding은 적은 수의 question and passages 로 학습을 시킬 수 있다. Dense embedding을 위해 Question encoder와 Passage encoder 2개가 존재 여러 QA 데이터셋에 적용해보니까 실제 BM25를 사용한 방법보다 약 9% ~ 19% 성능 향상이 있었다. multiple ODQA benchmarks에도 도움을 준다 1. Introduction QA task는 보통 two stage framework 구조를 가짐. retriever : 정답이 있을만한 후보를 가져오는 모델 reader : retrieved contex

tri2601

아래 링크는 현재 공부하고 있는 논문 공부 링크입니다. > https://acoustic-basin-638.notion.site/Densephrases-Too-740193fc663e450f90688988e46ee8ed?pvs=4

tri2601

아래 링크는 위 논문을 리뷰하며 공부하고 있는 내용입니다. > https://acoustic-basin-638.notion.site/Learning-Dense-Representations-of-Phrases-at-Scale-e73e5b2ff6404f45ac270ad7f6924cf7?pvs=4

ivorrr987

어제자(22.06.17)로 부스트캠프 AI Tech 3기 과정이 모두 종료되었다. 과정 회고는 추후 작성하도록 하고 밀린 프로젝트를 하려고 한다. (사실 프로젝트가 끝난 후 했어야 하는데 부캠 과정은 프로젝트가 끝나고 바로 프로젝트가 시작되는 구조였어서 그러지 못했다. 그냥 내가 게으른 탓인가) 프로젝트 개요 부캠 과정에서 정의된 ODQA(Open Domain Question Answering)는 다음과 같다. QA(Question Answering)는 다양한 종류의 질문에 대답하는 인공지능을 만드는 연구이다. 다양한 QA 시스템 중 ODQA(Open Domain Question Answering)는 주어지는 지문이 따로 존재하지 않고 사전에 구축되어 있는 Knowledge Resource에서 질문에 대답할 수 있는 문서를 찾는 과정이 추가된다. 사실 팀 내부에서 ODQA의 정의에 대해 의견이 분분했다. 팀원 중 한분은 면접을 보고 왔는데 거기

idj7183

목적 ODQA(Open-Domain Question Answering)은 질문이 주어지면 그 질문에 가장 적절한 Document를 찾고, 그 Document에서 정답을 찾는 Task이다. 우리 조는 팀원끼리 회의하여 이 Task를 Retrieval과 Reader 부분으로 나누기로 하였고, 나는 이 중 Reader Model의 성능 향상을 담당하게 되었다. 결과 리더보드 GitHub 링크 https://github.com/idj7183/level2-mrc-level2-nlp-08 시도했던 것에 대한 결과 klue/roberta-large Model 이 모델을 Default로, 아래 시도했던 결과들에 대해 Private과 Public 점수의 상승폭을 입력하였다.

idj7183

오늘 할 것 HyperParameter Tuning Batch-Size Decay 증가 leraning rate () 지우기 오늘 한 것 HyperParameter Tuning Batch Size 최근 모델에는 Batch Size를 크게 하는 것이 좋다고 하여 Batch Size를 증가시켰다. 그런데, Batch Size를 16보다 크게 설정하면 OOM 에러가 발생하는 것을 알 수 있었다. 따라서, Gradient Accumulation을 활용해 총 4번 Gradient값을 축적하여 Batch Size가 64인 실험과 매우 유사하게 진행되도록 하였다. 먼저, Batch Size를 키웠으니 Step은 당연히 작아질 것이다. EM적으로는 점수가 높지 않지

idj7183

오늘 할 것 질문 형식 변경 답을 내기 쉬운 데이터 먼저 학습 Title과 유사도를 가진 질문이라면 조금 더 답을 내기 쉽지 않을까? 쉬운 데이터부터 학습을 먼저하면 모델 입장에서도 학습하기가 더 쉽지 않을까? 오늘 한 것 질문 형식 변경 수행 이유 저번 대회에서 느꼈지만, 모델 변경보다는 데이터를 학습하기 쉬운 형태로 바꾸는게 점수 향상에 더 많은 기여도를 지녔다는 것이 생각났다. 내가 현재 수정할 수 있으며 Model의 EM에 영향을 끼치게 할 수 있는 것은 "title, Context, Question"이다 이 중 Title은 직접적으로 Model에 영향을 끼치지 않기 때문에 후순위로 밀렸으며, Context 또한 \n 같은 HTML에 활용되는 문자를 지

idj7183

오늘 할 것 Korquad 데이터를 활용하여 Train Data를 증강시키기 오늘 한 것 Korquad 데이터 활용 수행 이유 어떤 논문에서는 아래와 같이 말했다 "슬프게도, 모델이 커지고 데이터가 많아질수록 그냥 모델의 Accuracy는 높아진다" 이런 말을 생각해 볼 때, 데이터를 증강하면 자연스럽게 EM도 높아질 것이라고 생각하였다. QA(Reader)에 대해서는 매우 좋은 Train Data인 "Korquad" Data가 존재하고, 이번 대회에서는 외부 데이터의 활용이 허락되었기 때문에 Korquad Data라는 Quality 높은 데이터를 활용하면 무조건 점수가 높아질 것이라고 생각하였다. 수행 결과 먼저, Korqud 데이터가 많기 때문에 자연스럽게 학습 S

idj7183

오늘 할 것 Tokenizer를 변경시키기 Kobert Tokenizer klue/bert-base tokenizer KKma 오늘 한 것 배운 것 한국어 Tokenizer 한국어는 다른 언어와는 다른 형태를 지니고 있기 때문에, Tokenizer도 살짝 다른 방식으로 tokenizing을 수행한다. 기본적으로 POS Tagging을 활용하는데, 이런 방식으로 한국어 Tokenizing을 할 수 있게 도와주는 대표적인 패키지가 KoNLPy이다. KoNLPy는 아래 사이트에 매우 좋은 설명이 되어 있기 때문에, 아래 블로그에서 이해하도록 하자 https://han-py.tistory.com/283 Tokenizer 변경 Huggingfacec에 존재하는 수많은 Tokenizer를 활용해보았다. 하지만, 어떤 방식을 쓰더라도 좋은 점수가 나오진 않았다. 배운 점 Model에 변경된 Tokenizer 적용

idj7183

오늘 할 것 Classifier로 LSTM 활용해보기 Bidirectional LSTM과 일반 LSTM 모두 Classifier로 활용해보기 BiLSTM Output 전체를 활용할 것인지, 아닌지에 대해 확인해보기 2-Layer로 Classifier 변경해보기 CNN Layer 활용해보기 오늘 한 것 2-Layer로 Classifier 변경시키기 수행 이유 Model이 커지면 커질수록 Accuracy가 높아지는 것으로 알고 있었다. Huggingface에서 활용하는 AutoModelForQuestionAnswering에서 Classifier는 오직 1개의 Layer로만 구성되어 있고, nn.Linear을 활용하는 것을 알 수 있었다. 그렇다면, `nn.

idj7183

오늘 할 것 Huggingface에 존재하는 여러 Pretrained Parameter 활용해보기 오늘 한 것 klue/roberta-large 실험 이유 저번 대회에서도 klue/roberta-large를 활용한 것이 가장 점수가 높았고, 이번 Data도 한글 데이터이기 때문에 한글 Data에 적합한 Pretrained Model인 klue/roberta-large Parameter를 활용하였다. 결과 아래에서도 비교하겠지만, 모든 Model 중에서 가장 점수가 높았다. 앞으로는 klue/roberta-large 활용하는 것을 Base로 두어야겠다 klue/bert-base ![](https://velog.velcdn.com/images/idj7183/post/de

idj7183

오늘 할 것 Model의 큰 틀을 이해하고, 어떤 부분을 수정하면 좋은 결과를 낼지 생각해보기 Hyperparameter 값을 대충이라도 정하기 오늘 한 것 문제점 내가 Baseline Code를 잘 이해하지 못했어서 오류가 왜 발생했는지도 알 수 없었으며, 결과가 나왔을 때 제출했을 때도 EM이 0이 나오는 엄청난 사건을 경험했다. 그래서 하려고 했던 것을 모두 취소하고 Line by Line으로 코드 이해를 우선적으로 하기로 했다. Baseline Code 변경 현재 Baseline Code의 핵심 부분을 보니, metric이 eval/이 아닌 train/ 부분으로 Wandb상에 들어감을 알 수 있었다. Huggingface Code를 뜯어보니 self.log 명령어를 통해 내가 원하는 방식으로 Wandb상에 Metric 결과를 보낼 수 있음을 알게 되었다. 따라서, trainer_qa.py파일 중 evaluate 메서드를

idj7183

오늘 할 것 Baseline Code 읽어보기 Baseline Code를 협업하기 쉬운 형태로 변경하기 오늘 한 것 Baseline Code 읽기 Baeline Code가 상당히 까다로운 대회인 것 같다. 한 번 훑어봤는데 이해가 안되서 다시 읽어본 부분을 셀 수 없었다. 이번 짧은 대회에서는 모든 코드를 이해하긴 어려울 것 같고, 내가 담당하는 부분의 코드라도 완벽히 이해하도록 노력해야겠다. Baseline Code를 협업하기 쉬운 형태로 만들기 먼저, 모듈화를 조금이라도 시켜 놓고, Preprocessing하는 Function을 다른 Directory에 포함시켰다. 그런데, 원래 코드가 Huggingface 방식의 코드라고 알려주셔서 조금 놀랐다. 내 입장에서는 보기가 너무 어려워서 일부러 수정한건데, 이것이 현재 방식이라고 하면 이런 방식에도 익숙해질 필요성이 있어 보인다. 또한, Config파일을 json 파일로 하려 했으나, yaml