문장 내 개체간 관계 추출 Relation Extraction

문장 내 개체간 관계 추출 Relation Extraction

2023.05.03 ~ 2023.05.18

Github: https://github.com/iamzieun/Boostcamp-LV2-RE

GitHub - iamzieun/Boostcamp-LV2-RE: [boostcamp Ai Tech] RE (Relation Extraction) 대회

---

💪🏻 1. 학습 목표

나의 학습 목표

• 아이디어와 근거를 바탕으로 다양한 실험 진행해보기 ⭕️
• 자동화 및 협업을 위한 tool들에 익숙해지기 🔺
• 각각의 task를 적절한 기간 내에 완수하기 ⭕️
• 공식 docs 및 논문과 친해지기 ⭕️
• 커뮤니케이션 시 의사 표현 및 자기 주장 확실하게 하기 ⭕️

지난 대회를 마무리하며 했던 다짐들

• 강의, 과제, 공지, 멘토링 내용 등을 꼼꼼하게 확인하고 프로젝트를 시작하자. ⭕️
• 효율적인 협업을 위하여 프로젝트 노션 템플릿을 쇄신하자. ⭕️
• 최대한 빠르게 파이프라인 설계를 끝내고, 많은 실험에 도전해보자. ⭕️
• 팀 전체가 루즈해지거나 방향성을 잃는 것을 예방하는 차원에서 회의 및 프로젝트를 주도할 PM 제도를 도입하자.
• 피어세션을 보다 구체화하여, 진행 상황을 공유하는 시간과 함께 디버깅하는 시간으로 나누어 진행하자. ❌
• ‘중요한 것은 꺾이지 않은 마음’임을 잊지 말고 적극적으로 실험하자. ⭕️

👩🏻‍💻 2. 프로젝트 진행 내용

main code refactoring

• 제공된 baseline code를 refactoring하였다. refactoring 시 신경 쓴 부분은 다음과 같다.
  • 실험 시 변인이 될 수 있는 설정은 모두 config.yaml에 연결함으로써 config.yaml만 수정하여 실험을 진행할 수 있게 하였다.
  • 한 단위의 역할을 함수들끼리 하나의 py 파일에 담길 수 있도록 하였다.
• 지난 대회를 통해 코드 독해력과 작성 속도에서 발전이 필요함을 느꼈고, 이에 스스로 많이 부족한 부분(=팀에 피해를 줄 수도 있는 부분)이라 생각했지만 용기를 내어 code refactoring에 도전해보았다. 막상 맡고 나서도 어디서부터 고쳐야 할 지 막막하고 어려운 부분이 많았지만 그 과정을 통해 배운 점도 많았다.
  • 각 함수들, 나아가 각 py 파일들이 어떠한 관계 속에 있는지 잘 와닿지 않을 때는 그림을 그려가며 파악해보자.
  • 함수를 파악할 때 가장 기본적으로 확인해야 하는 것은 parameter와 output, 그리고 그들의 type이다.
• 한 번에 완벽하게 refactoring을 하지는 못하여 프로젝트를 진행하며 많은 수정이 이루어지기도 했다.
  • 하지만 처음부터 완벽할 수는 없는 법 ! 이번 도전에 대해서는 성과에 상관 없이 ‘시도’를 한 나를 칭찬해주고 싶다.
  • 그럼에도 다음 시도부터는 보다 세밀한 작업 분리와 그에 따른 py 파일 분리, 동작 방식과 일치하도록 함수명 작성 등에 있어서 신경을 써야겠다.

Huggingface Datasets 연결 + 데이터 버저닝

• Huggingface Datasets repo를 생성하고 main code를 이와 연결하여 데이터 버저닝을 진행했다.
• 지난 대회 때 한 번 해본 내용이라 보다 빠르고 수월하게 진행할 수 있었다. 경험의 중요성을 다시 한 번 깨달았다.
• 다만 이번 대회에서는 augmentation이나 사전 preprocessing 등이 많이 이루어지지는 않았어서, 데이터 버저닝이 적극적으로 이루어지지는 않았다. 아마 Huggingface Datasets은 다음 대회인 Data Centric에서 더 빛을 보지 않을까 싶다.

KLUE 논문 분석

• task와 데이터셋에 대한 이해를 위해 KLUE 논문의 Relation Extraction 부분을 발췌하여 읽고 분석하였다.
• 데이터셋 생성 방식과 evaluation metric을 확인함으로써
  • KLUE RE 데이터가 가정하는 ‘현실의 RE 데이터’에 대해 파악할 수 있었고
  • micro f1 score 및 auprc의 이론적인 내용을 점검할 수 있었다.
• 어떤 task를 시작하기 전에 관련 논문이나 선행 연구를 찾아보는 것의 중요성에 대해 깨달을 수 있는 중요한 경험이었다. 또한 논문이라고 하면 일단 피하고 봤던(..) 지난 날의 모습에서 벗어나 논문과 조금 친해지는 계기가 되었다.

Validation Strategy

• Validation Set의 필요성과 그에 따른 ‘좋은 Validation Set’의 조건에 대해 고민하고, 직접 Validation set을 생성하여 이후 실험을 진행했다.
  • Validation Set은 학습 데이터를 벗어난 현실의 unseen 데이터에 대하여도 안정적인 성능을 낼 수 있게끔 모델을 학습시키기 위해, 학습 단계에서 모델에 대한 evaluation을 진행할 목적으로 생성하는 데이터이다.
  • 그렇기 때문에 Validation Set은 현실의 unseen 데이터와 닮을 수록 좋다. 본 대회에서 우리에게 현실의 unseen 데이터는 Test Set이다. 따라서 Test Set과 같은 분포를 가지는 Validation Set이 있으면 좋겠지만 Test Set의 분포를 알 수 없으므로, 차선책으로 Test Set에 대해 모델이 inference를 진행한 결과를 바탕으로 Validation Set의 분포를 설정하였다.
• Validation Set을 설정하기 전에 이것을 왜 필요로 하며, 그에 따라 어떤 조건을 갖춘 Validation Set을 설정하는 것이 좋을지에 대해 고민해본 시간이 비교적 좋은 품질의 Validation Set 생성으로 이어진 것 같다.

사후 분석 baseline 설정

• 모델이 Test Set에 대해 inference를 진행할 때 Validation Set에 대한 inference도 동시에 진행하는 코드를 작성하고, 그 inference 결과에 대한 confusion matrix나 heatmap 등을 통해 사후 분석을 진행할 수 있는 함수를 작성했다.
• 지난 대회에서 사후 분석을 통해 얻은 아이디어로 augmentation 했던 것들이 성능 향상에 도움이 되었던 기억이 있어, 이번 대회에서도 꼼꼼한 사후 분석을 통해 의사 결정을 하고자 했다.
  • 특히 이번에는 평가 기준인 micro f1 score과 auprc에 대한 이해를 바탕으로 사후 분석을 진행했던 것이 도움이 되었다.
• 다만 모든 실험에 대한 사후 분석을 진행하지는 못했는데, 다음 대회부터는 사후 분석에 조금 더 시간을 투자하여 견고한 근거와 논리를 가지고 대회를 이어가야겠다.
• 더불어 heatmap을 그릴 때 최대값 및 최소값을 가시적으로 확인할 수 있는 color map을 사용하는 것이 좋겠다는 피드백을 받았다. 처음에 그러한 color map을 사용했다가 이상치를 제외한 나머지 값들이 거의 표시되지 않는 문제를 겪어서 다른 방법을 사용했던 것인데, 두 가지 문제를 모두 해결할 수 있는 방법이 있을지 찾아보는 것이 좋겠다.

Prompt

• PLM의 input sequence에 sentence와 더불어 entity 및 task 정보를 강조하여 전달할 수 있는 prompt를 삽입했다.
  • 기존의 baseline code에 포함되어있는 prompt의 유무에 따라 실험을 해 본 결과 prompt가 성능 향상에 큰 영향력을 가짐을 알게 되었고, 논문을 참고하여 task의 의미를 담은 다양한 prompt로 실험을 이어가보았다.
• prompt의 유무에 따른 성능 차이는 분명했지만, prompt 간의 성능 차이에 대해서는 검증을 하지 못했다. 사후 분석과 동시에 seed를 바꿔가며 여러 번 실험을 하여 실험 결과의 신뢰성을 높여야겠다.

Entity Representation

• prompt로 인한 성능 향상을 확인하여, entity 정보를 더욱 강조해줄 수 있는 방법으로 논문을 참고하여 entity representation을 사용해보았다.
• entity representation 또한 prompt와 마찬가지로 확실한 성능 향상이 있었지만, entity mask를 제외한 나머지 방법론들 간의 유의미한 차이는 확인하지 못했다.
• prompt와 entity representation 부분에서 독립적으로 실험을 진행한 것에 대해 칭찬을 받았다 !

RoBERTa + BiLSTM

• 모델의 bluntness를 해결하기 위해 기존 architecture에 layer를 추가하는 방안을 고려해보았고, 이에 양방향에서 sequence의 문맥 정보를 파악할 수 있는 BiLSTM layer를 추가해보았다.
• 전에 작성해둔 사후 분석 함수를 통해 실험 결과를 꼼꼼하게 분석하는 시간을 가졌고, wandb나 리더보드 점수보다 사후 분석의 결과를 더욱 신뢰하는 계기가 되었다.
• architecture를 바꾸기 위해 custom model class를 작성해보았는데, 차원을 맞추지 못하여 결국 다른 팀원이 작성해준 custom model로 실험을 진행했다.
  • 혼자 새로운 class를 정의하며 huggingface와 pytorch 공식 문서와 친해지는 시간을 가질 수 있었다.
  • 코드 작성에 조금 더 익숙해져 다음에는 직접 architecture를 customizing 해보아야겠다 !
• 더불어 모델 architecture를 바꿀 때에는 현재 해당 task에서 SOTA인 모델의 architecture를 참고하는 것이 좋다는 피드백을 받았다. architecture를 바꾸는 것을 넘어서, 왜 이런 architecture로 바꿨어야 했는지에 대한 정당성을 확보하기 위해 다음 대회부터는 이와 같은 접근법을 적극적으로 활용해보아야겠다.

sweep

• 팀원을 도와 최적의 hyperparameter를 찾기 위한 sweep용 코드를 작성했다.
• 급하게 마무리했어야 하는 작업이라 일단 돌아가게끔은 만들었으나, 실험 결과를 원하는 경로에 저장되도록 하는 작업은 깔끔하게 마치지 못했다. 아직 sweep과 익숙하지 않아서 이러한 문제가 생겼기에 sweep github을 참고하여 문제를 해결해야겠다.

👨‍👩‍👧‍👦 3. 협업과 커뮤니케이션

• 말 그대로 ‘useful’한 노션 운영
  • 지난 대회 이후 피드백에서 작업 현황을 한 눈에 알아볼 수 있는 kanban board 형식의 대쉬보드를 제안받았고, 이를 반영하여 노션을 쇄신하여 운영했다.
  • 회의록 및 실험 보고서 등 각 문서에 따른 template을 작성해두어 의사소통의 효율성을 도모했다.
• 노션 광인에서 깃헙 광인으로의 탈바꿈을 다짐하게 된 사연.story
  • 대회 중간 진행된 멘토님의 github 특강을 듣고 팀원들과 많은 감명(팩폭)을 받아서 github을 더욱 적극적으로 활용하는 협업을 시작하게 되었다.
  • 이후 모든 작업은 1) issue 발생 2) feature branch 생성하여 작업 진행 3) PR 4) review 후 main branch에 merge의 flow로 진행했다.
  • branching 전략으로는 git flow를 채택했었는데, develop branch의 필요성을 느껴 다음 대회에서는 다른 전략을 채택할 것 같다.
• convention의 중요성에 대한 깨달음을 실천으로 연결
  • 노션에서 template과 column들을 정의해두듯이, 코드 작성과 git을 통한 협업에 있어서도 convention이 있으면 더욱 편리하다는 것을 깨달았다.
  • 이에 commit message, branch name, issue, pr 등에서 convention과 template을 적극적으로 활용해보았다.
• 하지만 나 조금은 불도저였을지도?
  • 특히 지난 대회의 피드백을 반영하여 의견이나 찬성 또는 반대 의사를 보다 분명하게 표현했던 것 같은데, 혹시나 이것이 과하지는 않았을지 걱정이 된다.. 모두의 기분을 상하지 않게 하면서 나의 의사를 잘 표현하는 방법을 더 연구해보아야겠다.

🔥 4. 한계와 교훈을 바탕으로 다음 프로젝트에서 시도해볼 점

• 논문과 SOTA를 근거로 삼는 실험의 비율을 높여보자.
  • 이는 정의한 문제에 대한 사전 조사를 전제로 한다.
• 점점 notion을 벗어나 git을 통한 협업에 익숙해져보자.
  • 그것이 엔지니어니까..
• 코드 작성과 사후 분석은 더욱 정진하자 !