네이버 부스트캠프 2번째 ODQA 프로젝트를 마치면서

프로젝트를 시작하면서 세운 목표

지난 문장간 유사도 문석(STS)프로젝트에서는 베이스라인 개발, 모델리서치 및 실험, 앙상블 파트에 집중하였다. 프로젝트 시작 후 베이스라인 개발을 우선시하다 보니, 데이터분석과 활용에는 많이 신경 쓰지 못했던 아쉬움이 있었다. 그래서 이번 프로젝트는 데이터 분석과 데이터기반 성능향상에 초점을 맞추고자 했다.

프로젝트에서 시도한 것에 대한 설명

제공 데이터 분석

우선 제공된 데이터분석을 진행하였다. 그 과정에서 그래프를 그릴 때 데이터의 분포와 데이터간 상관관계를 직관적으로 파악하기 위해 seaborn라이브러리를 사용하였고, 최대한 분석 목적에 맞는 그래프의 종류를 사용하려고 노력했다.

우선 데이터의 구조를 판단하고, train, validation, test 데이터들의 분포를 확인하고 비교하였다. 이는 train 데이터와 validation, test 데이터 간의 분포 및 논리적 유사성이 높아야 모델이 올바르게 학습하고 일반화된 추론을 할 수 있다고 판단했기 때문이다. 만약 train 데이터가 특정 패턴이나 주제, 분포에 집중되어 있는데 validation, test 데이터가 그렇지 않다면 모델이 그 차이를 제대로 학습하지 못해 오차가 커질 있기 때문이다. 히스토그램과 KDE 곡선을 함께 사용하여 train, validation, question 데이터셋의 context, question, answer의 text 길이분포를 비교하였고, 결측치와 중복치 같은 특이사항까지 확인하였다.

Wikipedia 데이터셋 역시 동일한 방향성으로 분석을 진행하였다. 추가로 train과 validation 데이터셋의 context가 Wikipedia 데이터셋에서 가져온 데이터셋이 맞는지 확인하는 과정을 거쳤다. 이때 train, validation 데이터셋의 context와 Wikipedia 데이터셋의 text간 정확히 일치하는 것을 확인하였지만, title과 같은 요소는 다른 경우가 있었다. 하지만 실제 학습시에는 title을 제외한 context만을 사용하기 때문에 추가적인 처리는 진행하지 않았다.

데이터기반 성능향상 전략

성능을 향상시키기 위해 데이터 증강 및 클렌징, train-validation 데이터 재배치 등 다양한 성능향상 전략을 진행했다. 그 중 성능에 향상이 있었고, 신경을 많이 쓴 항목은 GPT API 기반 데이터 증강이다. context데이터 갯수를 증강시키는 것은 retriever의 성능을 낮출 수 있기 때문에 question과 answer에 대한 증강을 진행하였다.

추가 질의를 생성하기 위해 GPT API를 불러온 뒤 few-shot learning을 진행했을 때 문제가 발생하였었다. GPT가 생성형 모델이기 때문에, context안에 없는 answer을 생성하는 문제가 있었다. 이를 해결하기 위한 방법으로 question과 answer을 동시에 만드는 것이 아니라 context의 핵심 키워드를 추출한 후 이를 정답으로 지정, 이 정답을 도출할 수 있는 question을 생성하는 방식을 사용하여 문제없는 question-answer 데이터셋을 추가적으로 생성할 수 있었다. 또한 동의어 증강기법도 고려하였다. 간단히 question의 동의어교환과 문맥변경을 진행하는 것 이였고, 이 역시 GPT API를 사용하여 진행하였다.

초반에 계획은 있었으나 진행하지 못한 것도 있는데, 로컬 LLM기반 데이터분석 및 클렌징이다. 데이터가 매우 많아지면 일일이 눈으로 모든 데이터를 확인하는 것은 불가능에 가까워진다. 하지만 모든 데이터를 고성능 LLM에 API형태로 확인시키는 것은 비효율적이라고 생각했다. 오류를 확인하는 것은 생성하는 것에 비해 쉽고, 성능이 부족하더라도 여러 번의 반복으로 이를 보완할 수 있기 때문에 로컬 LLM을 통해 진행해보면 어떨까 하는 생각을 했고, LlaMa모델의 작동까지 확인하였다. 하지만 시간적 여유가 부족하여 우선순위가 밀려 진행하지 못한 아쉬움이 있다.

앙상블

앙상블 전략을 고도화하는 방법에 대한 고민이 많았다. 앙상블은 어떤 모델의 결과를 얼마나 섞을지 고민하는 weighted voting 방법론을 많이 썼었는데, 이로 인해 단순히 리더보드의 public 성능만을 성능지표로 보고 파라미터를 변경하는 반복적인 작업이 이루어지는 것이 과정이 아니라고 아니라고 생각했다. 따라서 좀 더 고도화된 방법을 고민하다 LLM을 적용하는 방법을 시도해보았다. MRC의 Q-A과정에 LLM을 사용하는 것은 생성형 모델 특성상 EM성능이 높지 않아 부적합하다고 생각했지만, 각각의 질문에 대한 여러 모델의 출력을 기반으로 LLM이 최적의 답변을 선택하도록 하는 앙상블 전략을 고려해 보았다. 이를 통해 단순히 가중치 기반의 합산보다는 보다 정교하고 상황에 맞는 답변을 생성해낼 수 있을 것이라고 판단했다. 예를 들어, 각 모델이 제공한 답변을 LLM에 입력하여 최종적으로 가장 적합한 답변을 선택하는 방식이다. 이러한 방법은 단순히 특정 모델의 결과에 의존하는 것이 아니라 다양한 모델의 강점을 활용하여 최적의 성능을 얻을 수 있다는 점에서 의미가 있다고 생각했다. 높은 성능이 나왔지만 실제 제출에는 반영하지 않았다. 금지된 가중치인 MRC_KLUE 데이터셋을 반영하지 않았다고 보장할 수 없기 때문이다. 

아쉬운 점 및 다음대회에 시도할 것

프로젝트 초반에는 데이터를 중점적으로 분석하다 보니 베이스라인 코드에 소홀했던 부분이 아쉬움으로 남았다. 특히, 팀원들이 각자 베이스라인 코드를 디벨롭해 나가는 과정에서 코드의 복잡도가 증가했고, 그 결과 후반에 실험을 진행하기 전에 코드의 동작 원리를 이해하는 데 많은 시간이 소요되었다. 이러한 문제로 인해 실험 진행 과정에서 효율성이 떨어졌던 점이 아쉬웠다.

따라서 다음 프로젝트에서는 데이터 분석과 베이스라인 코드의 이해를 나눠서 동시에 진행하는 것을 목표로 하고 있다. 데이터를 깊이 이해하는 동시에 코드의 구조와 기능도 철저히 이해하는 과정을 병행함으로써 팀원 간의 이해도 차이를 줄이고, 실험의 일관성과 효율성을 높이고자 한다.