목적

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 점수의 상승폭을 입력하였다.

Bi-LSTM Classifier

설명

원래 Default Model의 Classifier은 nn.Linear(1024,2)밖에 없었다.

이 부분을 BiLSTM Classifier로 변경시킨 Model을 만들었다

Public

• EM : 0.83 $\downarrow$
• F1 : 0.36 $\downarrow$

Private

• EM : 1.39 $\uparrow$
• F1 : 1.36 $\uparrow$

Batch Size 64

설명

Batch Size가 16 이상이면 OOM을 발생시켰다.

하지만, Model에서 Batch Size가 증가하면 점수가 오를 거 같아 Gradient Accumulation을 활용하여 Batch Size가 64인 것처럼(4만큼 Accumulation 수행) 모델이 학습되도록 하였다.

Public

• EM : 0.83 $\downarrow$
• F1 : 0.07 $\uparrow$

Private

• EM : 5.72 $\uparrow$
• F1 : 4.05 $\uparrow$

() 지우기

설명

이번 Task가 EM인데, "트랜스포머(Transformer)"를 채점할 때 정답은 "트랜스포머" 혹은 "Transformer"여야지만 정답으로 취급되었다.

따라서, Train Data의 답을 "트랜스포머"로 설정하여 괄호 안의 대체 데이터를 없앰으로써 "트랜스포머"만 예측하도록 학습시켰다.

Public

• EM : 1.25 $\downarrow$
• F1 : 0.83 $\uparrow$

Private

• EM : 2.22 $\uparrow$
• F1 : 1.65 $\uparrow$

질문 형식 바꾸기

설명

질문 형식 중 "A를 발견한 사람은?" 같은 형식인 것이 많았다.
이 때, "A를 발견한 사람은 누구인가?"와 같이 의문문을 보충함으로써 질문 형식을 명확히 해주면 결과가 더 좋아질 것이라고 예측하였다.

Public

• EM : 1.25 $\downarrow$
• F1 : 0.35 $\uparrow$

Private

• EM : 1.39 $\uparrow$
• F1 : 1.57 $\uparrow$

---

잘했던 점

1. 생각했던 대부분을 구현한 이후 실험까지 해봄

처음 이 Task를 시작할 때 해야할 것 같다는 실험들의 List가 있었는데, 1개 빼고 모두 다 구현하여 실험까지 해보았다.

이전 대회들에서는 오류가 너무 많이 떠서 못 해본 실험들이 항상 있었는데, 이런 점에서 조금 성장했던 거 같아 기쁘다.

2. 협업
저번 대회를 반면교사 삼아 이번에는 칸반보드에도 항상 내 결과를 공유하고, Github도 어느정도 활용하였다.

또한, yaml 파일을 활용해 설정값들을 지정하여 Conflict가 많이 나지 않아 GitHub Push와 Pull이 매우 편해졌다는 점도 큰 장점인 것 같다.

3. 기록
이번 대회는 기록을 상당히 열심히 했다.
벨로그에 못할지라도 당일날 한 실험들은 메모장에라도 쓰거나 칸반보드에 입력하여 대회 끝나고 내가 무엇을 했고, 그 행동에 대한 피드백 및 고찰을 할 수 있게 되어 매우 좋았던 것 같다

---

아쉬운 점

1. 대회 일정
이번 대회는 일정이 Final Project 주제 정하기와 겹치기도 하였으며, 취업 시즌과도 겹치다 보니 대회에 온전히 집중할 수 없었던 것 같다.

특히, 이번 Task는 상당히 방대하다고 생각하는데(무려 2개의 Task가 합쳐진 큰 Task라고 생각한다) 이런 부분을 고려해봤을 때 너무 빡빡하지 않았나 생각이 든다.

저번 부캠 2기에는 7명이 4주를 진행했다고 알고 있는데, 아무래도 이번에는 5명 3주다 보니 모두가 약간 힘이 들지 않았나 싶다.
(특히 우리 조는 발표를 2번 연속하다보니 쉬는 날이 없어 마지막 즈음에 너무 힘들어보였다)

2. 너무 다른 Private과 Public 점수
사실 이번대회에서 너무 아쉬운 점이다.

나는 어느정도의 근거를 가지고 실험을 했었는데, 그 실험들이 모두 실패하여 자신감이 많이 떨어졌었다.

특히 이번 대회에서 우리 조끼리 가장 많이 한 말은 "왜 떨어졌는지 모르겠고, 왜 올랐는지 모르겠다"였었다.

실제로 Private 점수를 보니 각자 점수가 더 오를 것 같다고 생각한 Model들이 실제로 점수가 올랐었다.
(나는 내가 수행한 것들 대부분에 대해 점수가 올랐고, Retreival 쪽에서도 BM25가 Public에서는 좋게 나왔는데 Private에서는 Elastic Search가 좋게 나와 Elastic Search에 투자했던 것이 사실 올바른 선택이였다는 것을 알게 되었다)

물론 저번 대회로 Public이 Private 점수를 대표하지는 않는다는 것을 알고 있었지만, 그래도 어느 정도 경향성은 비슷해야 실험을 올바른 방향으로 진행할 수 있지 않았을까 아쉬웠다.

3. Curriculum Learning
위 2개 부분은 내가 어떻게 할 수 없는 아쉬움이라면, 이 것은 나의 능력부족으로 일어난 아쉬움이다.

위에서 내가 하고 싶던 List 대부분을 했다고 했는데, 유일하게 채우지 못한 List가 바로 이 Curriculum Learning이다.

중간에 결과가 계속 잘 안나오니까 솔직히 짜증도 좀 났었고, 그 와중에 일정도 바쁘다 보니 결국에는 Curriculum Learning에 대한 논문을 자세히 읽지는 못했다.

이것도 무조건 성능이 좋게 나왔을 방법론이였던 것 같은데, 많이 아쉬운 부분이다.

---

다음에 고칠 점

1. 내 선택에 자신감 갖기
이번 Task에서 결국 명확한 근거를 가지고 실험했다면, Public 결과가 어떻든지 간에 Private에서는 어느 정도의 성능을 나타낸다는 것을 알게 되었다.

즉, 만약 내가 명확한 근거가 있고, 그 근거에 의거했을 때 비슷하거나 좋은 점수가 Wandb 상에 찍힌다면 Public이 좋든 나쁘든 무조건 제출해보는 습관을 가져야 할 것 같다.
(이 부분은 내가 대회를 빨리 참가하여 제출 기회가 더 많았다면 좋았을텐데, ODQA라는 Task가 나한테는 너무 생소하여 강의를 주의 깊게 들어야 되었기 때문에 대회 참가까지 시간이 조금 더 소요된 이유도 있어 많이 아쉬웠다)

2. 논문 많이 읽고 직접 구현해보기
이제는 Source Code를 읽는 것, 그리고 읽은 Code를 활용하는 것 및 변경하는 것에 대해 많은 자신감이 생겼다.

실제로 이번에는 Error가 발생해도 1시간 내에 모두 처리하여 정상적인 Model 학습이 되도록 코드를 짤 수 있었다.

이제는, 논문을 많이 읽으며 내가 "어떤 방식으로" 모델링을 해야 좋은 점수를 내며, "어떠한 이유로" 그런 방식을 채택했는지 잘 파악하여 정확한 모델링을 위해 노력해야 할 것 같다