Open Domain Question Answering

출처: https://lilianweng.github.io/posts/2020-10-29-odqa/

Open Domain Question Answering

2023.06.05 ~ 2023.06.22

Github Repository: https://github.com/iamzieun/Boostcamp-Lv2-ODQA

GitHub - iamzieun/Boostcamp-Lv2-ODQA: [boostcamp Ai Tech] ODQA (Open Domain Question Answering) 대회

---

💪🏻 1. 학습 목표

• git branching 전략으로 기존의 git flow가 아닌 github flow를 활용해보기
  • 프로젝트의 특성 상 git flow가 더 적절한 전략이기는 하지만, 최종 프로젝트때 보다 능숙하게 github flow를 활용할 수 있게 연습삼아 github flow를 사용해보기로 하였다.
  • main branch 이전에 예비 branch로 develop branch가 하나 추가된 것 외에 큰 차이는 없었지만, main branch 위에 develop branch를 올리고, 그 위에 feature branch들을 올려가는 과정을 연습해보았다는 점에서 의미가 있었다는 생각이 든다.
• 기존보다 체계적으로 실험 파이프라인 설계하기
  • wandb에 평가 metric의 log를 연결하고, validation set에 대한 inference 결과와 그를 이용한 사후 분석 코드까지 자동으로 실행되도록 하는 것이 목표였으나, baseline code에 대한 이해가 늦어져 validation set에 대한 inference 결과를 추출하는 것까지만 실천할 수 있었다.
  • 지난 대회들과 다르게 config.json, config.yaml로 실험과 관련한 인자들을 조절하는 것이 아닌, huggingface의 TrainingArguments와 유사하게 만든 class들을 통해 인자를 조절하는 방식으로 baseline code가 설계되어 있었는데, 이에 적응하는 것에 시간이 걸려 ‘실험명’과 관련한 자동 설정 없이 대회를 진행했다. 이로 인해 실험명을 수동으로 일일이 정리해두었어야 하는데, 이 점이 생각보다 시간과 에너지 소모가 컸던 것 같다. 이전에는 매번 시간이 조금 걸리더라도 실험을 위한 파이프라인을 꼼꼼하게 설계하고 실험을 시작했었기 때문에 오히려 그 중요성을 체감하지 못했었는데, 이렇게 당연했던 것을 당연하게 하지 않았던 경험을 통해 실험 파이프라인을 꼼꼼하게 설계하는 것의 중요성을 깨달을 수 있었다.
• 데이터와 모델 중 어느 쪽으로 치우치지 않는 다양한 실험 진행해보기
  • 이전까지의 대회에서 데이터와 관련한 부분을 많이 다뤄왔던 것 같아서 이번 대회를 진행하면서는 모델과 관련한 실험도 적극적으로 도전해보아야겠다는 생각을 했었다. 데이터에 비해서는 아직 논리적인 사고과정을 통해 모델을 선택하고, 코드를 작성하여 이를 활용하는 것이 부족하다고 생각했기 때문이다.
  • 이번 대회를 진행하면서도 아예 새로운 모델을 구현해보지는 못했지만, BM25를 적용하고 Trainer의 method를 override하여 curriculum learning을 실험하는 등 이전 대회에 비해서는 모델 쪽과 관련한 실험을 많이 해본 것 같다.
  • 모델과 엔지니어링 쪽에서 더 많은 기회가 주어질 파이널 프로젝트를 통해 이번 대회에서의 아쉬움을 메꾸어갈 예정이다.

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

• EDA
  • retrieval에 사용되는 wikipedia 말뭉치와, reader의 학습에 사용되는 데이터셋에 대한 EDA를 진행했다.
  • 전에 다루어보았던 범주형, 수치형 데이터를 거의 포함하고 있지 않은 데이터이다보니 어떤 식으로 EDA를 진행하는 것이 좋을지 고민하는 시간이 있었고, 대체로 text 길이의 분포에 대한 분석을 진행했다.
  • 전처리를 위해 데이터가 특수문자 및 외국어를 포함하는지 여부 및 그 비율에 대한 분석도 진행했었는데, 상당수의 정답에도 특수문자와 외국어가 포함되어있어 이를 단순히 제거해버리는 것은 올바른 방향이 아니라고 생각했다. 그래서 특별한 preprocessing 없이 모델링을 진행했었는데, 대회 막바지에 preprocessing을 한 데이터로 학습한 모델의 성능이 확 오르는 모습을 보면서 EDA 당시에 조금 더 꼼꼼하게 고민했어야 했다는 생각이 들었다. 더불어 EDA를 진행하고 공유했던 내용들을 팀원들이 기억하지 못하는 모습을 보며 조금 더 효과적으로 내용을 전달하는 방법에 대한 고민이 필요하다는 생각을 했다.
• BM25 retriever
  • 강의 내용에 포함되어있었던 BM25를 더 알아보고 TF-IDF의 수식과 비교해보면서, TF-IDF에 비해 BM25가 가지는 이점에 대해 생각해보는 시간을 가졌다. 단순히 좋은 알고리즘이라니까 가져다 써보기에 그치지 않고 알고리즘에 대한 이해를 바탕으로 task에 적용해보았다는 점에서 성장한 스스로의 모습을 체감할 수 있었다.
• Data Augmentation
  • 데이터도 기존 대회들에서는 주로 csv 형식의 파일을 huggingface datasets repo에 올려 사용했었는데, 본 대회에서는 json이나 .arrow 형식의 파일을 주로 다루게 되어 초반에 적응하는 시간이 조금 필요했었다.
  • 기존 데이터에 KorQuAD 데이터를 추가하는 식으로 augmentation을 진행할 때에도 파일 형식으로 인한 어려움을 겪었었는데, Datasets과 DatasetsDict 객체에 대한 이해를 바탕으로 문제를 해결해본 경험이 재미있었다.
• Curriculum Learning
  • 내 생각에는 논리적인 가설로 설계한 실험이었지만 생각한대로 성능이 개선되지 않아 그 이유를 찾아보는 일련의 경험을 해볼 수 있어서 유의미한 실험이었다. 경향성을 가지는 데이터로 학습한 모델이 가지는 편향성과 취약성에 대해 경험적으로 배워볼 수 있었다.
  • 또한 curriculum learning을 구현하기 위하여 공식 github, docs를 통해 Trainer class를 분석하고, 관련 method를 override해보는 경험을 해볼 수 있어서 좋았다.
• Training with Retrieved Context
  • training 과정과 inference 과정을 유사하게 맞춰주기 위하여 고안한 방법이었고, 성능 향상까지 이뤄볼 수 있었다.
  • 다만 reader 모델을 수정하여 training 과정과 inference 과정의 극간을 채워주는 것도 좋지만, retriever를 수정하는 접근 또한 시도해보았으면 좋았을 것이다.
    • 특히 retriever가 뽑아온 30개의 context를 단순히 concat해서 사용하는 것보다는 context를 각각 reader 모델에 전달하는 방법과, retriever가 추출한 context의 순위를 반영하는 방법을 시간 부족으로 실험으로까지 연결하지 못했던 점이 아쉽다.

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

• Github
  • 4번의 대회를 거치며 도입한 Github을 통한 협업 방식(issue, PR, branching 전략 등)에는 잘 적응했다.
  • 베이스라인 코드의 항상성 유지 여부를 체크하는 작업의 필요성을 깨달았고, 이에 따라 이후의 대회 및 프로젝트에서 코드의 유지/보수를 위하여 Github Action을 도입해보아야겠다는 생각을 했다.
  • issue와 PR을 통한 커뮤니케이션의 비율을 높여보면 좋을 것 같다는 피드백을 받아볼 수 있었다. 회의에서 직접적으로 공유할 내용을 최소화할 수 있도록 github을 적극적으로 활용하고 확인하는 습관을 들여야겠다.
• PM으로서의 나
  • https://iamzieun.tistory.com/79
  • 학교에서도 부스트캠프에서도 느끼지만 나는 어떤 팀의 리더가 가져야 할 커뮤니케이션 및 문제 해결 역량 면에서는 꾸준히 성장하고 있는 것 같은데, 리더로서 가지면 좋을 마음가짐에 있어서는 한참 부족하다는 생각이 든다. 아니면 어쩌면 리더가 마땅히 가져야 할 책임감이 아직 나에게는 너무 무겁게 느껴지는 것일 수도 있다. 이것도 노력하다보면 언젠가 편해지는 날이 올 것이라고 믿고 싶다!

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

• 이번 대회는 부캠에 들어와서 처음으로, 말 그대로 끊임없이 지치기만 하는 3주였다. 그 이유는 다음과 같다.
  • 베이스라인 코드를 이해하고, 실험을 위한 파이프라인을 구축하고, 실험을 설계하고 구현하고 사후 분석하는 모든 과정을 쉴새없이 이어가는데, 성취가 없었다. 보다 정확히 말하면 리더보드의 등수가 올라가지 않았다.
    • 나는 생각보다 ‘등수’에 미쳐있는 승부욕이 강한 사람이라는 점을 깨달았다..ㅎ 엄마가 어릴 때 1등 좀 많이 시켜볼 걸 그랬다고 하셨다 (!)
  • 위 과정을 진행하면서 팀원들 각자의 니즈가 너무나 다르다는 점을 깨달았다.
    • 나는 ‘분석과 공유를 바탕으로 성능 좋은 모델 만들기’라는 목표를 향해 모든 팀원이 다같이 달려가는 과정을 통해 유의미한 성취를 얻어내는 경험을 하고 싶었다.
    • 하지만 다른 팀원들이 모두 나와 같은 니즈를 가지고 있던 것은 아니며, 그렇기에 나는 내가 맞다고 생각하는 것에 대한 팀 전체의 공감대를 형성하는 것을 사실상 포기했다.
• 위와 같은 이유들로 매일 새로운 실험을 하고 분석을 해도 내가 원하는 목표에는 닿을 수 없었음을 매일 새롭게 깨달으며 무력한 3주를 보냈다.
  • ‘분석과 공유를 바탕으로 성능 좋은 모델 만들기’라는 목표는 애초에 혼자서 달성할 수 있는 것이 아니었기 때문이다.
  • 그래서인지 스페셜 피어세션 시간에 어떤 캠퍼분이 오늘부터는 중도하차해도 수료한 것으로 처리된다는 것을 알려주었을 때, 지금이라도 중도하차할까 하는 생각이 머릿속을 스쳐갔다. 그 순간에는 남은 한 달이라도 마음 편하게 내가 하고 싶은 공부를 하거나 아예 빨리 유럽으로 떠나버리고 싶었다.
• 이러한 과정을 통해, 프로젝트를 시작하기 전에 팀원들과 팀 전체의 ‘공동의 목표’를 설정해야 하며, 그 과정에서 다른 팀원들의 니즈를 파악하는 동시에 내가 원하는 바 또한 분명하게 표현해야 한다는 점을 깨달았다.