sangmandu commented 2 years ago

목표

다음을 수행해 성능을 비교하는 것이 실험의 목표입니다.

[x] KorQuAD-Question-Generation를 사용한 Augmentation
[x] Pororo를 사용한 Translation

결과

1차 시도

Basic	Gen	Pororo
LB	34.170	8.750	32.080

최후의 지푸라기

한글 70%	한글 80%	한글 90%	한글 80%	한글 80%	기본
특징	비율	비율	비율	생성 모델(GM) 전처리 X	평균 이상의 docs 길이	기본 데이터
데이터 수	6641	5570	2980	5570	1926	-
최종 데이터 수	5292	4439	2365	4385	1554	-
EV-EM	50.417	51.25	51.25	52.083	51.25	54.167
EV-F1	59.805	59.362	60.148	61.319	60.132	60.708
LB	-	-	-	20.830	-	34.170

결론

FINE TUNING시에 전처리 하지 않는 것이 좋음
데이터가 많다고 학습이 잘 되진 않음
augmentation 끝....

수행

1. KorQuAD-Question-Generation를 사용한 Augmentation

라이브러리

import json
import pandas as pd
import random
import numpy as np

transformers는 KorQuAD-Question-Generation에서 사용하는데, 이 때 버전이 최신버전이면 오류가 난다. 4.5.0으로 낮추어서 진행했음.

데이터 로드

df = pd.read_json('../data/wikipedia_documents.json', orient='index')
len(df)
>>> 60613

Wiki 중복 데이터 제거

현재 위키 데이터는 중복 데이터가 존재합니다. 이러한 중복 데이터를 제거하면 Sparse와 Dense의 Retrieval부담을 조금 줄여줄 수 있습니다. 현재 wiki도 중복을 제거해서 사용하는 것이 어떤지 제안합니다.

df = df.drop_duplicates(['text'], keep = 'first')
len(df)
>>> 56737

KorQuAD-Question-Generation 구성

원리는 저도 잘 모릅니다. 다만, GPT-2로 넘겨주는 인풋은 다음과 같습니다.

Context
Answer
Question [Optional]

Wiki 데이터는 Answer와 Question이 없습니다. 따라서 이 모델을 사용하지 못합니다.

😥😥😥😥 고생하셨습니다. 😥😥😥😥

로 끝나면 안되겠지요 ..🤣🤣

그래서, 문하겸님은 title을 answer로 하면 어떻겠냐는 idea를 사용합니다. 꽤 괜찮은 생각인 것이, 임의로 우리가 text속에서 단어를 뽑자니 그 기준이 애매하고 단순히, unigram word로 뽑을지, bigram이나 trigram까지 적용할 지도 고민해야 되는 부분인지라 그 과정이 복잡해질 것입니다. 제일 좋은 방법은, 해당 context의 주제가 되는 title을 answer로 간주하는 것이 제일 좋아보이죠.

특정 데이터 제거

모델은, context와 answer를 입력받을 때 context속에 answer가 존재해야합니다. 우리의 Competition이 Extraction 방식이기 때문에 answer가 text속에 없는 데이터를 학습하면 안되겠지요. 특정 데이터는 text에 title이 존재하지 않습니다. 이런 데이터를 걸러줍시다.

df2 = df.apply(lambda x: x if x.title in x.text else '', axis=1)
df2 = df2[df2.text != '']
len(df2)
>>> 26585

문하겸님은 28765의 데이터를 얻었는데, 저는 왜 인지는 모르겠지만 그보다 더 적은 데이터가 생성되었네요.
그래도, 현재 4천개의 데이터를 생각하면 7배나 되는 양입니다.

데이터셋 생성

path = './KorQuAD-Question-Generation/data/'
df2.to_csv(path+'data.csv')

csv 파일로 저장해주겠습니다.

GPT-2 origin dataset

문하겸님은 코드를 새로 짜셨는데, 저는 그냥 기존 코드를 이용했습니다. 하겸님은 실력이 없어서 새로 코딩하셨다고 했는데, 제 입장에서는 코딩하는 게 더 어려운게 아닌가 싶은데요.. ㅋㅋㅋ 🙄🙄😁

코드를 쭉 읽어보고 현재 우리 task와 호환되어야 할 부분은 데이터셋이었습니다. KorQuAD 데이터는 이런 형식으로 짜여있는데, 우리 데이터랑 너무 다르죠.. 그래서 우리의 데이터를 저 형태로 변경할까 했는데, 너무 복잡합니다... 그래서 데이터로더를 좀 변경했습니다.

이 부분은 간단하긴 한데 너무 low-level쪽이라 설명은 생략하겠습니다

Question Generation

기학습된 모델이 링크에 있습니다. 이를 다운받아 바로 적용해보려고 합니다. 그전에 성능부터 확인해볼까요?

기학습된 모델의 perplexity는 다음과 같은데요.

이 성능은 개발자가 업로드한 모델의 학습 과정입니다. 모델의 성능을 보니 perplexity는 15점 정도이고,, eval은 7점이네요! 매우 낮습니다.

저도 0.1 epoch정도 돌려보니까 eval은 7점 정도이고 train의 perplexity는 12점까지도 낮아지네요(점점 낮아지는 것 같습니다)

다만, run_evaluation 코드를 실행하면, 위처럼 좀 더 높은 점수 43점이 나옵니다. run_evaluation 코드는 eval 데이터에 대해서 evaluation 하는 코드인데요. 코드적으로 크게 다른 부분은 없는데도 불과하고 점수 차이가 있네요. 실제로 학습 과정에서 하는몇번을 돌려서 실험해봤지만 이 점수 차이는 잘 설명이 안됩니다.

일단 저는 이 run_evaluation으로 얻은 점수를 기준으로 판단하겠습니다! 몇번 코드를 돌려 학습을 해보니, train중에 하는 얻는 eval 점수가 굉장히 낮게 나오는 경향이 있어서 신뢰도가 부족하다고 판단했습니다.

한번, 우리 csv파일에 대한 성능을 확인해볼까요.

python -m scripts.run_evaluation --model-path QG_kogpt2.pth --batch-size 25

생각보다, 61점은 낮은 값은 아닙니다 ㅠㅠ

그런데도 불구하고 점수가 60점이 나온 이유는 기존 KorQuAD 데이터에서 보지 못한 특징이 위키피디아에 많았다는 것으로 판단할 수 있겠네요.

No pretrained	pre trained	reported
Perplexity	73.0679	43.0596	15.9896
Loss	4.2914	3.7626	2.7718

일단🎈, 여기서 생각해 볼 부분은 이겁니다. 현재 우리가 만들 수 있는 새로운 데이터는 대략 2.8만개입니다. 근데 이 데이터들의 품질이 안좋으면 어떻게 하면 좋을까요? 60점의 perplexity로 생성되는 데이터들의 품질이 좋을까요?? 만약 안좋다면 증강되는 데이터 수를 조금 포기하더라도, 친구들을 조금 fine-tuning에 사용해서 perplexity를 낮춰야 할 거 같아요! 일단 이 부분은 질문의 상태를 보고 또 이야기해보죠!

모델을 돌려서 질문을 생성해봅시다. 두근두근 Augmentation 😁

python -m scripts.run_generate --model-path QG_kogpt2.pth --output-path result.csv

MRC data 추가 학습

누군가 이런 이야기를 할 수 있겠죠?? MRC 데이터 놀고 있는데 fine tuning에 사용하면 안되냐!!? 잘 생각해보면 이 MRC 데이터들도 모두 위키에 존재한다는 것을 알 수 있습니다. 따라서 fine tuning에 데이터를 양보할 거라면 Wiki 전체에서 생각해봐야 겠네요.

Wiki data 추가학습

loss: perplexity:

No pretrained	No finetuning	ft 4m	ft 8m	ft 12m
Perplexity	77.6636	61.5445	37.1645	36.6392	33.1300
Loss	4.3524	4.1198	3.6154	3.6011	3.5004

중간결과

fine tuning을 한 모델의 결과가 참담했습니다. mrc 모델을 돌리지 않아도 알 수 있을 정도라, no finetuning 모델을 사용하기로 했습니다. 이 모델의 성적은 꽤나 준수했습니다.

꽤나 질문이 잘 생성된 것처럼 보이죠!??

본격적인 성능을 봅시다!! 에...? 기존 roberta-small (파랑) 보다 훨씬 낮네요...

리더보드는 과연!!? 예???????????????? 예?????????????? 예???????????

점검

성능이 나오지 않은 네 이유를 생각해보았습니다. 1) train dataset은 거대해졌는데, valid는 기존의 쓰던 300개를 그대로 쓰게 되면서 eval 점수를 잘 뽑지 못했다. train과 eval을 다시 나누어보자.

2) 현재는 start_answer를 마킹할 때, 휴리스틱하게 마킹하고 있는데 이 부분이 문제가 될 수도 있습니다. 무슨 말이냐하면, "상민이는 사과가 좋고 배도 좋다. 상민이는 파이썬 전문가이다" 라는 문장에서 "상민"은 두번 등장합니다! 이 때 "파이썬 전문가는 누구인가?" 라는 질문에 대한 답변으로는 첫번째 상민이보다는 두번째 상민이를 보고 말하는 것이 더욱 자연스럽겠지요. 그러나, 위키피디아 데이터를 모두 보면서 질문에 해당하는 답변이 어떤 위치에 있는 word인지 라벨링 하는것은 어렵습니다 ㅠ 그래서, 상민이가 두번 등장한다면 그 문장은 거르고, 한번만 등장하는 데이터만 사용하도록해보자!

3) 위키피디아에는 한글(+숫자)로 이루어지지 않은 데이터들이 종종 있는데, 이들을 걸러줘야한다.

4) 위키피디아 augmentation을 하다보니, 비슷한 내용이 있을 수도 있고 아예 지문만 다르고 title은 동일한 애들이 있을 수 있다. 따라서 title 하나당 text 하나

5) mrc데이터에 포함되어있는 title을 wiki에서 모두 제거했습니다.

1+2+3+4+5 다 적용

valid 성능이 너무 높게 나오네요.

리더보드 성능은 다음과 같습니다. 처참하네요..

마지막 발악입니다.

위키피디아 데이터
위키피디아 text 중복 데이터 제거
title이 text에 존재하는 데이터만 포함
train & valid data와 중복되는 데이터 제거
데이터 전처리(희락님 전처리 코드) + <br> </br> 제거
한글과 숫자를 포함한 문자가 전체의 85% 또는 90% 이상인 데이터만 포함
- 중국어, 아랍어, 일본어가 많을 수록 모델이 좋지 않은 질문을 생성한다고 판단
title이 context에 중복되어 있으면 제거
모델로 질문 생성 후, 답변이 질문에 포함되어 있으면 제거
- "전라북도에 있는 까치산 바위의 이름은?" : "까치산 바위" 등의 데이터 제거

결과는 위에 상단에 기록하겠습니다.

2. Pororo를 사용한 Translation

개요

pororo를 사용하는 이유는 성능이 제일 준수해보이기 때문입니다. 파파고나 구글 번역기는 성능이 애매했고 라이브러리화 되지 않아 접근성이 떨어집니다. 구글에서 지원하는 라이브러리도 존재하지만 em 성능이 더 높은 pororo를 사용하겠습니다.

계획은 pororo로 일본어, 영어로 translation후에 다시 한국어로 tranlsation 하는 과정을 거치는 것입니다. 일본어 영어의 선택 이유는 pororo가 3가지 언어만 지원하기 때문이며 이 중 중국어를 제외한 언어의 번역 성능이 준수하기 때문입니다.

처음 계획은 double translation 이후, pororo에서 지원하는 paragraph identification를 사용해 검증하는 과정을 거쳐서 augmentation을 진행하려고 했습니다. para idf는 두 문장 a와 b가 동일한지를 판별하는 task입니다. 다만 아래와 같은 경우들 때문에 para idf를 진행하지 않는 것으로 결정했습니다.

엄마와 어머니를 구별하지 못합니다.
옥새라는 단어는 모델이 처음 볼법한 단어입니다. 형태적으로 제일 유사한 옥수수와 매칭되었습니다.

성능

결과만 바로 이야기하겠습니다. 기존 성능보다 낮게 나오네요 ㅠㅠ (저의 34점 로버타와 비교해서) 다른 분들의 로버타랑은 비슷한 성능을 가집니다.

raki-1203 commented 2 years ago