현재 계속 실험중이기 때문에 내용이 바뀔 수 있습니다.
데이터셋을 한국어 위키, 모두의 말뭉치 데이터(문어, 일상대화) -> 나무위키 데이터로 변경을 검토 중입니다.
T5 논문에서 언급된 C4의 데이터셋의 형식을 생각할 때 적당한 길이에서 내용이 끝나는 형식의 데이터가 비슷하다고 생각을 하고 있습니다. 모두의 말뭉치의 경우에는 데이터의 길이 자체가 길고 그걸 적당한 단위로 끊는 것에 어려움이 있고, 일상대화의 경우에는 회화의 내용이다보니 표현이나 전개가 중구난방이거나 정리가 되지 않은 느낌이 있었습니다. 문어의 경우에도 상대적으로 해당 분야에 대한 내용들이 많아 애매하다고 생각 중입니다. 물론 PLM 데이터가 일반적이어야하고 전문적인 내용이나 고유명사 등이 들어가면 안된다는 것은 아니지만 일반적인 표현이나 내용에 대한 비중이 상대적으로 너무 적기 때문에 우선 순위를 좀 낮추는 것이 필요하다고 생각하였습니다.
나무위키 데이터의 경우, 항목 별로 내용을 자를 경우 적당한 길이가 되는 경우가 많고, 긴 경우에 앞 부분만 자르더라도 해당 항목에 관한 것으로 내용이 어느정도 일관성을 유지합니다. 또한 wiki 등에 비하여 더 일반적인 내용과 표현들이 많이 나옵니다. 때문에 나무위키 덤프를 전처리하여 사용하는 쪽으로 검토 중이고, 지금은 전처리를 하면서 데이터를 살펴보고 있습니다.
환경
GPU V100 * 1
프레임워크
Pytorch, Pytorch lightning
데이터
한글 wikipedia, 모두의 말뭉치 중 문어, 일상대화 말뭉치 약 11GB text 이중 wkipedia데이터는 너무 마이너한 내용들이 많아 제외하는 것을 고려 중
토크나이저
BPE 사용. unigram, wordpiece까지 3개의 토크나이저를 실험했지만 BPE가 가장 잘 나뉘어진다고 판단하여 BPE사용.
Text에 바로 토크나이저를 적용하지 않고 Mecab의 morphs를 이용하여 형태소로 먼저 나눈 후 공백을 두고 join한 후에 저장하고 토크나이저를 학습시킴.
데이터 전처리
한자 제거, 괄호 안에 들어가는 알파뱃, 한글, 숫자 이외의 글자가 들어가는 경우 괄호까지 포함하여 제거(wiki 데이터를 위한 전처리)
모델 구조
추후 배포시의 편의를 위해 허깅페이스의 T5 사용
모델 설정값
T5-base의 파라미터를 사용. 생성시의 첫 토큰만 T5-base에서 사용하는 0(PAD)를 1(BOS)로 변경
pre-train 데이터 파라미터
masking비율 15%, 평균 span길이 2 사용. 3을 사용할 경우 학습이 너무 더디고 전처리한 데이터를 봤을 때 너무 긴 Span이 나오게 됨. 영어에 비해 한국어는 해당 Span의 길이나 정답을 맞추는 것이 더 어려워 길이를 2정도로 낮추는 것이 적절하다고 판단. 또한 참고한 코드의 MLM collator가 Span의 최대길이에는 따로 제약이 없어서 길이 5,6 이상의 Span이 나오기도 해서 수정하여 사용. Span의 평균 길이는 2 Span의 길이는 1~3의 범위가 되도록 조정해서 사용했다.
-> UL2 논문을 보면 일부러 어려운 Task도 Objective로 넣기도 하는데, 그런 측면에서 본다면 긴 Span이 섞이더라도 span길이에 대한 특별한 제약 없이 mean span length만을 설정하는 게 더 좋을 수 있을 것 같다.
Optimizer
Adafactor, AdamW 실험 중. Distributed shampoo도 자주 언급되긴하지만 우선 GPU 1장으로 실험을 하고 있고 앞의 두 Optimzier에 대한 실험이 끝나지 않았으므로 추후 고려.
AdamW는 1e-4~3e-4 사이 정도의 lr, Adafcator는 1e-3~5e-3 정도의 lr을 고려.
학습 모니터링
wandb
실험 중 느낀 것들에 대한 메모
TRC 이용해서 하려고 했는데 세팅 중에 VM을 한 번 지웠더니 해당 Zone에 쓸 수 있는 리소스가 없다고 VM을 더 못 만들게 돼서 V100으로 실험 중. TPU를 사용하면 훨씬 빠르게 학습을 할 수 있을 것 같다.
Optimizer에 warm up step을 수동으로 주고 학습을 하면 로스가 크게 올라간 후에 잘 떨어지지를 않는다. warm up 없이 적절한 lr을 설정할 경우에는 초기에 loss가 빠르게 감소하지만 그 이후에 너-무 느리게 감소해서 이 부분도 실험이 필요할 것 같다. 우선 Adafactor에 lr을 주지 않고 wamp up을 True로 했을 때는 그래도 Train loss 그래프가 정상적인 흐름으로는 나온다. -> Pytorch Lightning을 사용할 시 나타났던 문제. amp를 포함하여 여러가지 옵션으로 실행을 했으나 결과가 좋지 못함. TPU 사용도 고려하여 Pytorch Lightning을 사용했었음
Pytorch로 Trainer를 새로 짜서 실험했을 때 더 좋은 Train Loss 커브를 보여줌. 특히 Pytorch Lightning을 사용했을 때는 wamp up때 초기 Loss가 높게 설정되고 이후 Loss가 너무 떨어지지 않았는데 Pytorch로 할 때는 wamp up 단계에서도 조금씩 Loss가 줄어드는 정상적인 모습을 보임. Pytorch로 바꾸면서 gradient accumulation을 적용하기도 했는데 Lightning에서는 gradient accumulation적용시 wandb log가 정상적으로 찍히지 않는 문제가 있었음.
1epoch에 대한 학습 시간도 amp 미적용 lightning -> amp 적용 lightnining-> pytorch순으로 pytorch가 가장 짧게 걸림. 이 부분은 학습 추이를 지켜보면서 더 실험을 해봐야할 듯
같은 Span 처리라고 하더라도 영어에 비해 한국어가 Span의 내용을 예측하는 게 더 어려운 것 같다. MLM 데이터셋을 만들 때 적절한 파라미터 값에 대해서도 생각을 해봐야할 것 같다.
생각보다 pre-train 데이터로 쓸 corpus가 품질이 좋지 못한 것 같다. 특히 대화 데이터 같은 경우에는 음~ 어~ 같은 경우가 들어가 있는데 이게 또 span으로 묶여버리는 경우가 있다. 이렇게 쓰고보면 어~ 음~ 같은 경우는 전처리로 어느정도 제거할 수 있을 것 같다. 조금 더 생각해보자.
Reference
https://huggingface.co/transformers/v4.1.1/model_doc/t5.html
https://github.com/paust-team/pko-t5
https://junbuml.ee/KcT5-Pretraining-on-TPU-with-flax