🗂️ 팀 구성 및 역할

💬 프로젝트 개요

• 프로젝트 전체 기간 (2주) : 12월 1일 (월) 10:00 ~ 12월 11일 (목) 19:00
• 프로젝트 목적: 방대한 Wikipidia 문서를 기반으로 Question에 대한 Answer span을 예측하는 Open-Domain Question Answering (ODQA) 모델을 구현하는 것

🧑🏻‍💻 Task 이해 및 코드 Refactoring

Task 분석, 평가지표 분석, Baseline 분석 및 리펙토링

Task 이해

Gemini가 생성해준 그림

• 사용자의 질문에 대답을 하는 Task → 더욱더 정확한 답변을 얻기 위해서 관련 문서를 찾아서 답변하기
• 일반적인 Open-Domain Question Answering (ODQA) 파이프라인
  1. 사용자의 질문을 바탕으로 지식 베이스(Knowledge Resource)에서 관련 문서들을 탐색
  2. 탐색된 문서들을 바탕으로 MRC Reader 모델이 질문에 맞는 답변을 추출

<aside> 💡

Retriever가 못하면? → 엉뚱한 문서를 Reader에게 전달하여 답을 찾을 수 없음!

Reader가 못하면? → 제대로된 문서에서도 답을 추출하지 못하여 정답을 내놓을 수 없음!

⇒ 점수 = Retriever 성능 X Reader 성능

Retriever의 성능과 Reader의 성능을 모두 끌어 올려야 하는 과제로 해석됨 제한된 자원(제한된 GPU, 2주 간의 대회 기간) 속에서 치뤄지는 점을 고려할 때, Retriever/Reader 간 리소스 분배가 중요

</aside>

평가 지표 분석

1. [리더보드 반영 지표] Exact Match (EM): 모델의 예측과, 실제 답이 정확하게 일치할 때만 점수가 주어짐 (띄어쓰기 및 ‘.’ 과 같은 문자는 제거 후 채점)

   <aside> 💡

   Encoder 모델

   • Context내 정답의 시작 위치와 끝 위치를 찍어서 가져오기 때문에, 본문을 그대로 가져옴.
   • 정답의 위치를 맞추도록 학습

   Decoder 모델

   • Context를 읽고, 이전까지의 토큰을 기반으로 답을 새로 작성
   • 다음 토큰을 맞추도록 학습

   EM은 '토큰 하나 틀리지 않음'을 요구하기 때문에, Encoder모델이 보다 유리할 수 있음

   단, 현재 Encoder 모델에 비해 Decoder 모델의 규모가 매우 커졌으며, 문맥 이해 능력이 뛰어난 모델들이 개발되었기에 이에 대한 실험을 필요로 함

   </aside>

2. [보조지표] F1 Score: EM과 다르게 부분 점수를 제공 (정답은 "Barack Obama"지만 예측이 "Obama” 일 때, EM은 0점이지만, F1 Score는 겹치는 단어의 존재를 점수에 반영함)

   <aside> 💡

   • F1 score가 리더보드의 반영지표는 아니지만, robustness를 나타내는 지표일 수 있음
   • 토큰 단위의 일치도를 평가하기 때문에 모델의 사소한 실수를 고려한 실질적인 정보 추출 능력을 반영
   • EM 상에서는 해당 모델이 아예 엉뚱한 대답을 내놓았는지, 아깝게 틀렸는 지 알 수 없지만, F1 Score를 통해 정답에 근접해가는 능력 파악 가능 </aside>