[WK10] P-Stage level 2 - NLP KLUE-RE 대회 회고

프로젝트 목표 & 이를 위해 한 일

• 프로젝트 협업에 익숙해지기
  • 팀 Notion 개설 및 관리를 담당함
  • Github issue와 PR message 활용
• 문제에 대한 파악, 가설 수립 및 해결 과정을 남기기
  • Relation Extraction은 subject entity와 object entity간의 관계를 파악하는 문제, 외부 데이터셋은 활용 불가
  • PLM은 문장내 주어와 목적어 사이에 위치한 단어들의 나열을 통해 두 단어의 관계를 학습했을 것이므로, Prompting method를 통해 PLM의 prior knowledge를 fine-tuning 방식보다 적극적으로 활용하면 외부 데이터 사용이 제한된 상황에서도 높은 성능을 얻을 수 있을 것이라 가설 수립
• 추후 확장 및 재사용이 가능한 NLP Task 템플릿 작성하기
  • Ray Tune과 Optuna를 활용한 hyperparameter search 코드 작성
  • 모델 분석을 위한 문장 임베딩 시각화 코드 작성
  • 팀 공유 템플릿 분석 및 기능 추가
• 취업을 위한 프로젝트 포트폴리오 남기기
  • 포트폴리오 PPT 작성

프로젝트 주요 단계별 회고

• EDA: Embedding Visualization & Validation set alignment

  • 팀 전체를 위한 베이스라인 코드 구현에 hyperparameter search 코드 개발을 맡았고, 개발에 난항을 겪으면서 상대적으로 EDA에 신경쓰지 못함

  • 첫 주말 동안 모델 분석을 위한 문장 임베딩 시각화 코드를 작성하여 모델이 분류에 어려움을 겪는 샘플을 확인.

    • 코드

      Model_Analysis-EmbVis.ipynb

    • 모델의 오분류율이 높은 3가지 클래스(per:origin, per:place_of_birth, per:place_of_residence)에 대한 3D embedding visualization.
      

    • no_relation을 제외한 29개 클래스 클래스의 2D embedding visualization.
      

  • 위에서 더 나아가 DBSCAN을 이용해 각 군집별 이상치를 추출하여 리더보드의 점수와 비슷한 validation set 구축 시도. 그러나 기존 실험 결과와의 비교를 위해 최초에 구축한 validation set 계속 사용함.

    Model_Analysis-ValsetAlign.ipynb

• Baseline: PLM Baseline Hyperparameter Search

  • 높은 성능을 내는 PLM을 확보하기 위해 단순히 PLM의 hyperparameter만을 바꿔가며 최적의 조건을 탐색

    

  • 탐색을 자동화하기 위해 ray tune과 optuna 각각을 사용하여 hyperparameter search 코드 작성

    

  • 아이디어 구현 전, 각 모델의 성능이 대략 어느정도 나오는지 가늠하기 위한 것으로, 근본적인 문제 해결책은 아니었음

• Hypothesis and strategy formulation

  • Relation Extraction은 subject entity와 object entity간의 관계를 파악하는 문제, 외부 데이터셋 활용 불가
  • 데이터셋에는 entity type 정보 또한 함께 주어지며(PER, ORG, DAT 등), 이 정보는 relation label와 밀접한 관련이 있음(e.g. per:parent_of label의 경우 subj, obj entity type은 각각 PER로 제한됨)
  • Entity type 정보를 활용하여 성능을 향상시킨 방법론을 조사한 결과 다음 2가지가 존재함
    1. RECENT: Relation Classification with Entity Type Restriction
       • 각 relation label를 entity type 쌍을 기반으로 연관있는 것끼리 묶어 해당하는 것끼리 예측하는 방법
    2. PTR: Prompt Tuning with Rules for Text Classification
       • Entity의 type을 분류하는 prompt와 relation label을 분류하는 prompt를 결합하여 관계 분류
  • 두 가지 방법 각각을 시도해보기로 함. 본인은 PTR 적용을 시도하였으며 그 이유는
    • PLM은 문장내 주어와 목적어 사이에 위치한 단어들의 나열을 통해 두 단어의 관계를 학습했을 것, 따라서 이를 나타내는 적절한 프롬프트를 활용하면 PLM의 prior knowledge를 fine-tuning 방식보다 적극적으로 활용(MLM Head 활용)할 수 있어 외부 데이터를 활용하지 않고도 높은 성능을 낼 것이라 판단함

• Method: PTR

  • Prompt Engineering을 Relation Extraction Task에 활용한 방법론으로, 인간의 논리 추론 방식을 모방하여 각각의 entity type을 분류하는 prompt와 relation label을 분류하는 prompt의 조합으로 prompt를 구성

    

  • Issue: prompt template & answer engineering

    • prompt template: entity type 분류와 relation label 분류를 위한 적절한 prompt template을 구축해야함
    • answer engineering: prompt engineering에서는 task에 대한 label 별로 이에 해당하는 vocab 내 token이 매칭되어야함. 해당 방법론에서는 entity type에 대한 label과 relation label에 대한 label words가 구축되어야 한다.

• Solution: 한국어 prompt template 탐색, 및 answer engineering

  • Model: KLUE-RoBERTa-large

  • Prompt Template 탐색과 Answer Engineering을 동시에 진행함

  • Fine-tuning하지 않은 PLM에 prompt template과 label words 후보 조합을 입력했을 때 [MASK]의 위치에 올 token을 적절하게 예측하는지 확인

  • entityp type 분류를 위한 prompt template 후보 선정 과정: 최종적으로 2번을 선택. 조사에 대한 처리가 불필요하고 다른 후보에 비해 몇 가지 테스트 케이스를 수행해 봤을 때 양호한 성능을 보이기 때문에 선택하였다.

    1. {entity}은는 + [MASK]로 분류

       

    2. x + [MASK]:{entity} , x는 입력 문장

       

       

       

• entity type을 나타내는 label words 후보 선정([MASK] 토큰이 예측할 token 목록)과정: 위에서 선택된 template 에서 {entity}를 빈칸으로 두었을 때 [MASK]의 출력 확률 분포가 고르게 나오는지, 그리고 상위 3개 예측 결과에 해당 type이 포함되는지를 기준으로 선정한 결과 *로 표시된 단어들을 선택하였다.

  • PER : 사람, 인물*
  • ORG : 기관, 단체*
  • DAT : 일자, 날짜*
  • LOC : 위치, 장소*
  • POH : 별명, 사물, 명칭*
  • NOH : 숫자, 수치, 수*

• relation label 분류를 위한 prompt template 후보 선정 과정: 아래 그림에서 rel_token01 ~ 03에 해당. 해당 부분은 구현을 위한 시간이 부족하여 각 label의 설명을 참고하여 작성하였고 성능에 대한 검증을 미처 하지 못하였음. 단, 영어로 작성된 prompt처럼 rel_token01, 03은 접미사 또는 조사가 오도록 구성함.

  

• Result:

  • 최종 성능은 Micro F1 Score 65.708, AUPRC 68.163으로 매우 저조했다. Prompt 구성에 따라 성능에 크게 영향을 받는데, 이에 대한 검증이 제대로 이루어지지 않은 점이 저조한 성능의 원인으로 보인다. 또한 구현시 PLM의 MLM Head를 가져와 사용하지 않고 단순히 token간 cosine similarity를 이용한 분류기를 사용한 점도 좋은 성능을 내지 못했던 원인으로 추정된다.

  • 아래는 최종 리더보드, Micro F1 Score, AUPRC

    

  • 같은 데이터 KLUE-RoBERTa-large baseline의 성능

    

이전과 비교해서 새롭게 시도한 변화 및 효과

• 이전 대회 회고시 기억해두었던 매일의 할 일 목록 공유 및 체크를 시도했다. 프로젝트 진행 상황 관리 및 각자의 업무 추적에 매우 효과적이었다.

마주한 한계는 무엇이며, 아쉬웠던 점, 그리고 다음에 시도할 것은?

• PTR 코드 구현: 템플릿 코드와 호환되게끔 작성하고 싶었지만, huggingface transformes 라이브러리와 호환을 고려한 구현에 어려움을 겪어 결국 호환시키지 못한 점이 아쉽다. 이후 PTR에 대해 호환이 되는 코드를 작성하고 대회때 성능을 올리지 못헀던 부분을 개선하여 다시 시도해보려 한다.
• 깃헙 코드 관리: 마지막 팀 코드 정리에서 태욱님, 하람님, 명훈님이 각 코드를 정리하는데, 아직 관리 절차에 익숙하지 않아 도움이 되지 못 하였다. 다음 대회때는 해당 업무에 자원하여 코드 관리를 배울 예정.